15-744: Computer NetworkingAnnouncementsLecture: Design ConsiderationsOutlineGoals [Clark88]Goal 0: Connecting NetworksChallenge 1: Address FormatsChallenge 2: Different Packet SizesGateway AlternativesIP StandardizationIP HourglassIP Layering (Principle 2)SurvivabilityPrinciple 3: Fate SharingPrinciple 4: Soft-statePrinciple 5: End-to-End ArgumentExample: Reliable File TransferE2E Example: File TransferDiscussionExamplesGoal 2: Types of ServiceTypes of ServiceGoal 4: DecentralizationThe “Other” goals7. AccountabilityOther IP Design WeaknessesChanges Over TimeNew Principles?Integrated Layer Processing (ILP)Application Lever Framing (ALF)Summary: Internet ArchitectureSummary: Minimalist ApproachSummarySlide 35FragmentationFragmentation is HarmfulPath MTU DiscoveryIP Address Problem (1991)IP Address Utilization (‘98)IPv4 Routing ProblemsSolution 1 – CIDRClassless Inter-Domain RoutingSolution 2 - NATNAT IllustrationSolution 3 - IPv6IPv6 ChangesSlide 48Summary: IP DesignNext Lectures: Routing15-744: Computer NetworkingL-2 Design ConsiderationsAnnouncements•Video on Web page•Project focus•Project ideas list – will update by next Wed•Meeting times on Thursday to discuss possible project ideas (will bring signup to Wed lecture)•Project proposal (~1pg – intro/related work/plan of work) – due by email noon 9/23•Project partners – several people are looking – we will try to help•Lecture signup see Web page•Discussion site focus23Lecture: Design 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•Optional Reading•[CT90] Architectural Considerations for a New Generation of Protocols•[Clark02] Tussle in Cyberspace: Defining Tomorrow’s Internet4Outline•Design principles in internetworks •IP design5Goals [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 accountability6Goal 0: Connecting Networks•How to internetwork various network technologies•ARPANET, X.25 networks, LANs, satellite networks, packet networks, serial links…•Many differences between networks•Address formats•Performance – bandwidth/latency•Packet size•Loss rate/pattern/handling•Routing7Challenge 1: Address Formats•Map one address format to another?•Bad idea many translations needed•Provide one common format•Map lower level addresses to common format8Challenge 2: Different Packet Sizes•Define a maximum packet size over all networks?•Either inefficient or high threshold to support•Implement fragmentation/re-assembly•Who is doing fragmentation?•Who is doing re-assembly?9Gateway 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 designIP Standardization•Minimum set of assumptions for underlying net•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•Also achieves Goal 3: Supporting Varieties of Networks10IP Hourglass•Need to interconnect many existing networks•Hide underlying technology from applications•Decisions:•Network provides minimal functionality•“Narrow waist”Tradeoff: No assumptions, no guarantees.TechnologyApplications email WWW phone...SMTP HTTP RTP...TCP UDP…IP ethernet PPP…CSMA async sonet... copper fiber radio...1112IP Layering (Principle 2)•Relatively simple•Sometimes taken too farRouterRouterHostHostApplicationTransportNetworkLinkSurvivability•If network disrupted and reconfigured•Communicating entities should not care!•No higher-level state reconfiguration•How to achieve such reliability?•Where can communication state be stored?13Network HostFailure handing Replication “Fate sharing”Net Engineering Tough SimpleSwitches Maintain state StatelessHost trust Less MorePrinciple 3: Fate Sharing•Lose 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 firewalls•Survivability compromise: Heterogeneous network less information available to end hosts and Internet level recovery mechanismsConnection StateStateNo State1415Principle 4: Soft-state•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 survivability16Principle 5: End-to-End Argument•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•Guideline not a law17Example: 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 BOKE2E 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•Does FTP look like E2E file transfer?•TCP provides reliability between kernels not disks•Is there any need to implement reliability at lower layers?1819Discussion•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
View Full Document
Unlocking...