CS 557 - Lecture 3 Network Architecture End to End Arguments in System Design Saltzer, Reed, Clark, 1984 Design Philosophy of the DARPA Internet Protocols Clark 1988 Spring 2013
Architecture Dictionary definitions A style and method of design and construction. Orderly arrangement of parts. The manner of construction of something and the disposition of its parts. Design, the way components fit together.
Architecture Principles Definitions are vague, so we need guiding principles but can people agree on what these are? The debate is raging on! Just browse www.ietf.org sometime Now: original principles End of class: look at current debate about Internet architecture
[SRC84] Main Points Need: Describe and justify the end to end principle Approach: Examine which layer should implement a service Argue many services should be implemented at the higher layers (eg on the end hosts) Benefits: Fits with the model of minimal network (IP) layer Provides guidance on what (not) to add to data link layers End to end principle is fundamental to Internet success.
Basic Assumptions Layered Network Architecture Divide complex system into logical layers Service at one layer is based solely on service provided by the lower layer Layering in the Internet Application layer, transport layer, network layer, data link layer. Note a transport layer service such as TCP is based solely on services provided by IP TCP does not know or care about ethernet (data link) details.
Basic Question Which Layer Should Implement a Service? reliable delivery Encryption duplicate message suppression FIFO ordering Transaction Management One approach: lower layer should help applications by implementing such services End2End: these service can only be implemented correctly at the end points. Implementations at lower layer are questionable
Example of File Transfer Errors can occur at many levels Transfer from sender disk to memory Transfer from sender OS to sender line card Transfer across network Transfer from receiver line card to receiver OS Transfer from receiver memory to disk What would be the effect of a perfectly reliable network on the above?
Example of File Transfer (2) Perfectly Reliable Network Not Ideal Does not recover from other errors Provides false sense of security Example: file transfer in paper, BGP routing today Can harm other applications Example: hard to send voice over this network Suggest this a service best implemented at the ends (end to end principle)
Fundamental Trade-Offs End systems have information on semantics and requirements Network has information on data transmission parameters (packet size, error rate) Assuming packets follow the predicted path
Rules of Thumb Consider Marginal Gain In Lower Layer: If you can achieve large impact with limited effort, may be worth implementing at the lower layer. Consider the Impact on Other Services Implement service at lower layer only if it has minimal impact on applications that don t use the service. General Result: implement services at the end, not inside the network.
[Cla88] Main Points Need: Previously we saw the specification of TCP and IP. This papers describe the reasoning that led to the design and specification of TCP/IP Approach: Clearly state and order the goals Benefits: One fundamental goal Several second level goals Ordering of the second level goals is essential
Fundamental Goal Goal: Effective technique for multiplexed utilization of existing interconnected networks. Some Important Assumptions Include Connect ARPANET with ARPA packet radio Networks represent administrative boundaries Rely on packet switching and store and foward Net Result of The Goal and Assumptions Packet switched network consisting of distinct networks with store and forward gateways between them.
Second Level Goals Function despite loss of networks/gateways Support multiple types of services Accommodate a variety of networks Distributed management of resources Cost effective Low level of effort to add a host Provide accounting of resources used. What else could a network designer ask for??
Fundamental Trade-Offs Paper recognizes this seems like a list of all important network design goals. But all of the goals cannot be satisfied equally (at least no one has been able to do this) Which goals win and which lose in the trade-off? The order of the goals is essential Very strong focus on first three Survive network and gateway failures Provide different types of services Accommodate a variety of networks A different order would produce a different design. Ex: accounting barely works at all in the Internet.
Survivability Links and Gateways will fail and stop working Note design did not anticipate misbehavior Two entities can continue communication Despite faults at any intermediate point Mask any transient failures (eg route changes) Break only if total network partition Source has no physical path to destination
Achieving Survivability Implications for Storing Network State Any state stored at intermediate nodes must be replicated (since node may fail) Difficult (at best) to replicate this state. Clever Solution: State only stored at edges State-less packet switches (middle of network) Consider TCP state: seqnum, acknum, window, etc are all stored at the edge. No TCP information is stored in the intermediate nodes Fate-Sharing: acceptable to lose the state if the host itself has failed
Types of Services Virtual circuit service (TCP) Bi-directional reliable delivery Differing goals even within this service High bandwidth, delay not so important Low latency, bandwidth less important Other services Low complexity, no reliability (ex: debugging) Predictable rate with minimal jitter (ex: voice) Reliability is counter-productive here Split TCP (transport) and IP (network) Datagram is basic building block No assumption desired service is present in underlying net Build services such as TCP or UDP at the end hosts
Variety of Networks Assumptions Regarding Underlying Network Transport a packet (datagram) Reasonable packet size (100 bytes) Reasonable (not perfect) reliability Reliability proved a problem for sending voice Assumptions That Were Not Used Reliable or sequenced delivery Network broadcast or multicast Priorities or services Failures, speeds, or delays Minimal set of functionalities Build other services at the host (eg TCP for reliablity)
Other Goals Distributed Management Success in allowing multiple domains (two tier routing) Failure in routing policies Cost Effective Longer headers reduce efficiency Retransmission at the ends reduces efficiency Adding Hosts Host software is complex (compare PC requirements with telephone requirements) Relies on correct implementations at the host Misbehavior is a real problem today Accounting Challenges of datagram model May prefer flows for accounting
Implementations Proven to meet goal of network variety Some high speed, some not Some highly redundant, some single point of failure Note this failure of the implementation, not the design Leaves Much of the Work for Implementation What bandwidth? What redundancy? Performance Goals Can confirm protocol logical correctness But not sufficient for implementation goals Little good guidance Limited effective simulation Specifying Performance Must specify it, or you won t get it Leave it to network administrators to specify performance goals
Datagrams Provide Several Key Advantages No state stored in the network (survivability goal) Building block for many services (type of service goal) Minimum network assumption (variety of networks goal)
TCP Provide Byte Stream Reliablity Dropped idea of packet reliability Claims this may have been error We will see much more on TCP later in the course.
Summary Identified and Prioritized Goals Top Three goals very succesful Bottom goals less successful Building Block: Datagram Very effective for top goals Suggests flows may be better (for different priorities of goals) Suggests Period Messages: Soft-State
Some Closing Notes Completed our look at Internet architecture Some Implications Diverse set of link layer protocols Minimal services at the IP layer Distributed Management And hence partial/incremental deployment Prefer End to End based implementations. Next consider a new architecture: Named Data Networking