CS 557 - Lecture 3 Network Architecture End to End Arguments in - - PowerPoint PPT Presentation

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