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
Recommend
More recommend
