Lecture 3 Design Philosophy & ApplicationsLecture OverviewInternet ArchitecturePrioritiesSurvivabilityFate SharingTypes of ServiceVarieties of NetworksThe “Other” goalsAccountabilityFTP: The File Transfer ProtocolFtp: Separate Control, Data ConnectionsFtp Commands, ResponsesHTTP BasicsHow to Mark End of Message?HTTP RequestSlide 17Slide 18HTTP Request ExampleHTTP ResponseSlide 21HTTP Response ExampleCookies: Keeping “state”Cookies: Keeping “State” (Cont.)Typical Workload (Web Pages)HTTP 1.1 - new featuresPacket DelaySlide 28A Word about UnitsApplication-level DelaySome ExamplesSustained ThroughputOne more detail: TCPHTTP 0.9/1.0Single Transfer ExamplePerformance IssuesNetscape SolutionPersistent Connection SolutionSlide 39Persistent HTTPPersistent Connection PerformanceRemaining ProblemsBack to performanceBandwidth SharingFair Sharing of BandwidthBut It is Not that SimpleNetwork Service ModelsOther RequirementsReadings1Lecture 3Design Philosophy &ApplicationsDavid AndersenSchool of Computer ScienceCarnegie Mellon University15-441 Networking, Spring 2008http://www.cs.cmu.edu/~dga/15-441/S08/2Lecture OverviewLast time:»Protocol stacks and layering»OSI and TCP/IP models»Application requirements from transport protocolsInternet ArchitectureApplication examples.»ftp»httpApplication requirements.»“ilities”»Sharing3Internet ArchitectureBackground»“The Design Philosophy of the DARPA Internet Protocols” (David Clark, 1988).Fundamental goal: Effective network interconnectionGoals, in order of priority: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 accountability4PrioritiesThe effects of the order of items in that list are still felt today»E.g., resource accounting is a hard, current research topicLet’s look at them in detail5SurvivabilityIf 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.How to achieve such reliability?»Where can communication state be stored?Network HostFailure handing Replication “Fate sharing”Net Engineering Tough SimpleSwitches Maintain state StatelessHost trust Less More6Fate SharingLose state information for an entity if (and only if?) the entity itself is lost.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?–NATs and firewallsSurvivability compromise: Heterogenous network -> less information available to end hosts and Internet level recovery mechanismsConnection State StateNo State7Types of ServiceRecall 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, voice, etc.»These differences caused the layer split, added UDPNo QoS support assumed from below»In fact, some underlying nets only supported reliable delivery–Made Internet datagram service less useful!»Hard to implement without network support»QoS is an ongoing debate…8Varieties of NetworksDiscussed a lot of this last time - »Interconnect the ARPANET, X.25 networks, LANs, satellite networks, packet networks, serial links…Mininum set of assumptions for underlying net»Minimum packet size»Reasonable delivery odds, but not 100%»Some form of addressing unless point to pointImportant non-assumptions:»Perfect reliability»Broadcast, multicast»Priority handling of traffic»Internal knowledge of delays, speeds, failures, etc.Much engineering then only has to be done once9The “Other” goalsManagement»Today’s Internet is decentralized - BGP»Very coarse tools. Still in the “assembly language” stageCost effectiveness»Economies of scale won out»Internet cheaper than most dedicated networks»Packet overhead less important by the yearAttaching a host»Not awful; DHCP and related autoconfiguration technologies helping. A ways to go, but the path is thereBut…10AccountabilityHuge problem.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»Huge problem.»Worms, viruses, etc.–Partly a host problem. But hosts very trusted.»Authentication–Purely optional. Many philosophical issues of privacy vs. security.… Questions before we move on to the project?11FTP: The File Transfer ProtocolTransfer file to/from remote hostClient/server model»Client: side that initiates transfer (either to/from remote)»Server: remote hostftp: RFC 959ftp server: port 21file transferFTPserverFTPuserinterfaceFTPclientlocal filesystemremote filesystemuser at host12Ftp: Separate Control, Data ConnectionsFtp client contacts ftp server at port 21, specifying TCP as transport protocolTwo parallel TCP connections opened:»Control: exchange commands, responses between client, server.“out of band control”»Data: file data to/from serverFtp server maintains “state”: current directory, earlier authenticationFTPclientFTPserverTCP control connectionport 21TCP data connectionport 2013Ftp Commands, ResponsesSample Commands:sent as ASCII text over control channelUSER usernamePASS passwordLIST return list of files in current directoryRETR filename retrieves (gets) fileSTOR filename stores (puts) file onto remote hostSample Return Codesstatus code and phrase331 Username OK, password required125 data connection already open; transfer starting425 Can’t open data connection452 Error writing file14HTTP BasicsHTTP layered over bidirectional byte stream»Almost always TCPInteraction»Client sends request to server, followed by response from server to client»Requests/responses are encoded in textStateless»Server maintains no information about past client
View Full Document