Lecture 4 Design Philosophy & ApplicationsLecture OverviewInternet ArchitecturePrioritiesSurvivabilityFate SharingTypes of ServiceVarieties of NetworksThe “Other” goalsAccountabilityProject 1Project 1 goalsFTP: The File Transfer ProtocolFtp: Separate Control, Data ConnectionsFtp Commands, ResponsesHTTP BasicsHow to Mark End of Message?HTTP RequestSlide 19Slide 20HTTP Request ExampleHTTP ResponseSlide 23HTTP Response ExampleCookies: Keeping “state”Cookies: Keeping “State” (Cont.)Typical Workload (Web Pages)HTTP 1.1 - new featuresPacket DelaySlide 30A Word about UnitsApplication-level DelaySome ExamplesSustained ThroughputOne more detail: TCPHTTP 0.9/1.0Single Transfer ExamplePerformance IssuesNetscape SolutionPersistent Connection SolutionSlide 41Persistent HTTPPersistent Connection PerformanceRemaining ProblemsBack to performanceBandwidth SharingFair Sharing of BandwidthBut It is Not that SimpleNetwork Service ModelsOther RequirementsReadings1Lecture 4Design Philosophy &ApplicationsDavid AndersenSchool of Computer ScienceCarnegie Mellon University15-441 Networking, Spring 2005http://www.cs.cmu.edu/~srini/15-441/S05/2Lecture OverviewLast time:»Protocol stacks and layering»OSI and TCP/IP models»Application requirements from transport protocolsInternet ArchitectureProject informationApplication 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?11Project 1Out today, due 2/24»Intermediate validation deadline for basic functionsGet started early. Get started early. Get …Project partners»Choose very soon»Mail to David Craft, [email protected]Project is an IRC server (Internet Relay Chat)»Text-based chat protocol. Features, in order:1. Basic server (connect, channels, talk, etc.)•can do now2. Link-state routing to send messages to users across servers1. OSPF lecture (2/10). Book: Chapter 4 (4.2)3. Multicast routing to let channels span servers1. MOSPF lecture (2/15). Paper: Deering “Multicast Routing”12Project 1 goalsSkill with real network applications»Select, dealing with multiple streams of data, remote clients and servers»Protocol “grunge” - headers, layers, packets, etc.»Be able to implement a [whatever] server.Meet a real protocol»Create it from the specFamiliarity with routing protocols and techniquesDon’t be dismayed by the size of the handout. It breaks down into reasonable chunks.13FTP: 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 host14Ftp: Separate Control, Data ConnectionsFtp client contacts ftp server at port 21, specifying TCP
View Full Document