15-744: Computer NetworkingDesign ConsiderationsOutlineGoals [Clark88]ChallengeChallenge 1: Address FormatsChallenge 2: Different Packet SizesGateway AlternativesEnd-to-End Argument (Principle 2)Example: Reliable File TransferE2E Example: File TransferDiscussionExamplesInternet & End-to-End ArgumentPrinciple 3Principle 4Principle 5Principle 6Principle 7IP Layering (Principle 8)IP Design WeaknessesChanges Over TimeTussle Design PrinciplesSlide 24How is IP Design Standardized?IPv4 Header – RFC791 (1981)IP Type of ServiceFragmentationFragmentation Related FieldsFragmentation is HarmfulPath MTU DiscoveryOther FieldsAddressing in IPAddressing ConsiderationsSlide 35IP AddressesIP Address Classes (Some are Obsolete)Some Special IP AddressesSubnet Addressing – RFC917 (1984)SubnettingSubnetting ExampleSubnet Addressing ExampleIPv4 ProblemsIP Address Problem (1991)IP Address Utilization (‘98)IPv4 Routing ProblemsSolution 1 – CIDRClassless Inter-Domain RoutingSolution 2 - NATNAT IllustrationSolution 3 - IPv6IPv6 HeaderIPv6 ChangesSlide 54Summary: Internet ArchitectureSummary: Minimalist ApproachSummary: IP DesignNext Lecture15-744: Computer NetworkingL-2 Design ConsiderationsL -2; 1-16-02© Srinivasan Seshan, 2002 2Design Considerations •How to determine split of functionality•Across protocol layers•Across network nodes•Assigned Reading•[SRC84] End-to-end Arguments in System Design•[Cla88] Design Philosophy of the DARPA Internet Protocols•[Cla02] Tussle in Cyberspace: Defining Tomorrow’s InternetL -2; 1-16-02© Srinivasan Seshan, 2002 3Outline•Design principles in internetworks •IP designL -2; 1-16-02© Srinivasan Seshan, 2002 4Goals [Clark88]0Connect existing networksinitially ARPANET and ARPA packet radio network1. Survivabilityensure communication service even in the presence of network and router failures 2. Support multiple types of services3. Must accommodate a variety of networks4. Allow distributed management5. Allow host attachment with a low level of effort6. Be cost effective7. Allow resource accountabilityL -2; 1-16-02© Srinivasan Seshan, 2002 5Challenge•Many differences between networks•Address formats•Performance – bandwidth/latency•Packet size•Loss rate/pattern/handling•Routing•How to internetwork various network technologiesL -2; 1-16-02© Srinivasan Seshan, 2002 6Challenge 1: Address Formats•Map one address format to another. Why not?•Provide one common format•Map lower level addresses to common formatL -2; 1-16-02© Srinivasan Seshan, 2002 7Challenge 2: Different Packet Sizes•Define a maximum packet size over all networks. Why not?•Implement fragmentation/re-assembly•Who is doing fragmentation?•Who is doing re-assembly?L -2; 1-16-02© Srinivasan Seshan, 2002 8Gateway Alternatives•Translation•Difficulty in dealing with different features supported by networks•Scales poorly with number of network types (N^2 conversions)•Standardization•“IP over everything” (Design Principle 1)•Minimal assumptions about network•Hourglass designL -2; 1-16-02© Srinivasan Seshan, 2002 9End-to-End Argument (Principle 2)•Deals with where to place functionality•Inside the network (in switching elements)•At the edges•Argument•There are functions that can only be correctly implemented by the endpoints – do not try to completely implement these elsewhere•Caveat: can provide a partial form as performance enhancement•Guideline not a lawL -2; 1-16-02© Srinivasan Seshan, 2002 10Example: Reliable File Transfer•Solution 1: make each step reliable, and then concatenate them•Solution 2: end-to-end check and retryOSAppl.OSAppl.Host A Host BOKL -2; 1-16-02© Srinivasan Seshan, 2002 11E2E Example: File Transfer•Even if network guaranteed reliable delivery•Need to provide end-to-end checks•E.g., network card may malfunction•The receiver has to do the check anyway!•Full functionality can only be entirely implemented at application layer; no need for reliability from lower layers•Is there any need to implement reliability at lower layers?L -2; 1-16-02© Srinivasan Seshan, 2002 12Discussion•Yes, but only to improve performance•If network is highly unreliable•Adding some level of reliability helps performance, not correctness•Don’t try to achieve perfect reliability!•Implementing a functionality at a lower level should have minimum performance impact on the application that do not use the functionalityL -2; 1-16-02© Srinivasan Seshan, 2002 13Examples•What should be done at the end points, and what by the network?•Reliable/sequenced delivery?•Addressing/routing?•Security?•What about Ethernet collision detection?•Multicast?•Real-time guarantees?L -2; 1-16-02© Srinivasan Seshan, 2002 14Internet & End-to-End Argument•Network layer provides one simple service: best effort datagram (packet) delivery•Only one higher level service implemented at transport layer: reliable data delivery (TCP)•Performance enhancement; used by a large variety of applications (Telnet, FTP, HTTP)•Does not impact other applications (can use UDP) •Original TCP & IP were integrated – Reed successfully argued for separation•Everything else implemented at application level•Does FTP look like E2E file transfer?•TCP provides reliability between kernels not disksL -2; 1-16-02© Srinivasan Seshan, 2002 15Principle 3•Best effort delivery•All packets are treated the same•Relatively simple core network elements•Building block from which other services (such as reliable data stream) can be built•Contributes to scalability of networkL -2; 1-16-02© Srinivasan Seshan, 2002 16Principle 4•Fate sharing•Critical state only at endpoints•Only endpoint failure disrupts communication•Helps survivabilityL -2; 1-16-02© Srinivasan Seshan, 2002 17Principle 5•Soft-state•Announce state•Refresh state•Timeout state•Penalty for timeout – poor performance•Robust way to identify communication flows•Possible mechanism to provide non-best effort service•Helps survivabilityL -2; 1-16-02© Srinivasan Seshan, 2002 18Principle 6•Decentralization•Each network owned and managed separately•Will see this in BGP routing especiallyL -2; 1-16-02© Srinivasan Seshan, 2002 19Principle 7•Be conservative in what you send and liberal in what you accept•Unwritten rule•Especially useful since many protocol specifications are ambiguous•E.g. TCP will accept and ignore bogus acknowledgementsL -2;
View Full Document
Unlocking...