CS640: Introduction to Computer NetworksThe Road AheadInternet ArchitecturePriorities: How Important Can they Be?SurvivabilityFate SharingTypes of ServiceVarieties of NetworksThe “Other” goalsAccountabilityApplications FTP: The File Transfer ProtocolFTP: Separate Control, Data ConnectionsMore on FTPFtp Commands, ResponsesHTTP BasicsTypical HTTP Workload (Web Pages)Non-Persistent HTTPIssues with Non-Persistent HTTPThe Persistent HTTP SolutionHTTP RequestSlide 21Slide 22HTTP Request ExampleHTTP ResponseSlide 25HTTP Response ExampleCookies: Keeping “state”Cookies: Keeping “State” (Cont.)Packet Delay: One Way and Round TripIgnoring processing and queuing…Slide 31Some ExamplesBandwidth-Delay ProductTCP’s view of BW-delay productSustained Application ThroughputBandwidth SharingFair Sharing of BandwidthSummary and Key ConceptsNext ClassCS640: Introduction to Computer NetworksAditya AkellaLecture 4 -Design Philosophy,Application Protocols and PerformanceThe Road Ahead•Design Philosophy•Application protocol examples–ftp–http•Performance–Delay–Bandwidth-delay product–Effective ThroughputInternet Architecture•Background–“The Design Philosophy of the DARPA Internet Protocols” (David Clark, 1988).•Fundamental goal: “Effective techniques for multiplexed utilization of existing interconnected networks”•“Effective” sub-goals; in order of priori ty:1. Continue despite loss of networks or gateways2. Support multiple types of communication service3. Accommodate a variety of networks4. Permit distributed management of Internet resources5. Cost effective6. Host attachment should be easy7. Resource accountabilityPriorities: How Important Can they Be?•The effects of the order of items in that list are still felt today–E.g., resource accounting is a hard, current research topic!•Let’s look at them in detailSurvivability•If network disrupted and reconfigured–Communicating entities should not care!–No higher-level state reconfiguration–Ergo, transport interface only knows “working” and “not working.” Not working == complete partition.–Mask all transient failures•How to achieve such reliability?–State info for on-going conversation must be protected–Where can communication state be stored?•If lower layers lose it app gets affected•Store at lower layers and replicate–But effective replication is hard•Internet clumps all state and stores it in end-points–At least that was the goal!Fate Sharing•Lose state information for an entity if (and only if?) the entity itself is lost–Protects from intermediate failures–Easier to engineer than replication–Switches are stateless•Examples:–OK to lose TCP state if one endpoint crashes•NOT okay to lose if an intermediate router reboots–Is this still true in today’s network?•Survivability compromise: Heterogenous network less information available for error recovery slow and erroneousConnection StateStateNo StateTypes of Service•Recall from last time TCP vs. UDP–Elastic apps that need reliability: remote login or email–Inelastic, loss-tolerant apps: real-time voice or video–Others in between, or with stronger requirements–Biggest cause of delay variation: reliable delivery•Today’s net: ~100ms RTT•Reliable delivery can add seconds.•Original Internet model: “TCP/IP” one layer–First app was remote login…–But then came debugging, real-time voice, etc.–These differences caused the layer split, added UDP•No QoS support assumed from below–Hard to implement without network support–In fact, some underlying nets only supported reliable delivery (X.25)•Made Internet datagram service less useful for other services!–QoS is an ongoing debate…Varieties of Networks•A lot of different types of networks…–Interconnect the ARPANET, X.25 networks, LANs, satellite networks, packet networks, serial links…•Mininum set of assumptions for underlying net–Network can support a packet or a datagram–Minimum packet size–Reasonable delivery odds, but not 100%–Some form of addressing unless point to point•Important non-assumptions:–Perfect reliability–Broadcast, multicast–Priority handling of traffic–Internal knowledge of delays, speeds, failures, etc.The “Other” goals•Management–Today’s Internet is decentralized – BGP management is decentralized and hard–Very coarse tools. Still in the “assembly language” stage•Cost effectiveness and efficiency–E.g. headers fairly long for small packets–But economies of scale won out–Packet overhead less important by the year–Also, Internet cheaper than most dedicated networks•Attaching a host–Not awful; DHCP and related autoconfiguration technologies helping.Accountability•Huge problem.–Not an initial focus of the military network•Accounting–Billing? (mostly flat-rate. But phones are moving that way too - people like it!)–Inter-provider payments•Hornet’s nest. Complicated. Political. Hard…•Accountability and security–Big issue–Worms, viruses, etc.•Partly a host problem. But hosts very trusted.–Authentication•Purely optional. Many philosophical issues of privacy vs. security.•Still an on-going debateApplicationsFTP: The File Transfer Protocol•Transfer file to/from remote host•Client/server model–Client: side that initiates transfer (either to/from remote)–Server: remote host•ftp: RFC 959•ftp server: port 21file transferFTPserverFTPuserinterfaceFTPclientlocal filesystemremote filesystemuser at hostFTP: Separate Control, Data Connections•Ftp client contacts ftp server at port 21, specifying TCP as transport protocol•Two parallel TCP connections opened:–Control: exchange commands, responses between client, server.“out of band control”–Data: file data to/from serverFTPclientFTPserverTCP control connectionport 21TCP data connectionport 20More on FTP•Server opens data connection to client–Exactly one TCP connection per file requested.–Closed at end of file–New file requested open a new data connection•Ftp server maintains “state”: current directory, earlier authentication–Why is this bad?Ftp Commands, ResponsesSample Commands:•sent as ASCII text over control channel•USER username•PASS password•LIST return list of files in current directory•RETR filename retrieves (gets) file•STOR filename stores (puts) file onto remote hostSample Return
View Full Document
Unlocking...