Lecture Notes for Telecommunications

11 September 2004 - The End-to-End Argument

Outline

• An example service.

• The end-to-end property.

• Consequences of the end-to-end property.

• Counters to the end-to-end property.

• Telephone and high-speed networks.

Careful File Transfer

• Develop the careful file transfer (CFT) service

  cft(hostA:file1, hostB:file2)
  

  that (eventually) brings about the following conditions:

  • Host B has a file called file2.

  • file2 is a bit-by-bit exact copy of file1 on host A.

Designing CFT

• UnCFT is easy to design.

• CFT is considerably harder to design.

  • In fact, it's impossible; something can always go wrong.

• The objective is to minimize the probability of CFT failure.

  • And to minimize the cost of a given reliability level.

Making UnCFT Careful

• There are two extremes to making unCFT careful.

  1. Check every step of the way.

     • If there's a failure, try again.

  2. Send the file and check file2 against file1.

  • Approach 1 implies approach 2, but 2 doesn't imply 1.

  • Approach 1 is harder and costlier than is approach 2.

• Any design of CFT requires approach 2.

End-to-End CFT

• Approach 2 (send and verify) is necessary and sufficient.

• Implementing parts of Approach 1 (careful steps) has more effect on the cost of Approach 2 than on its reliability.

  • Implementing parts of Approach 1 is not the only way to provide these effects.

  • Break file1 into segments and do send and verify on the segments.

The End-to-End Property

• CFT requires end-point involvement; nothing else satisfies.

• A property that requires end-point involvement is an end-to-end property.

• Maintaining end-to-end properties at intermediate points may or may not be useful, depending on cost.

  • A careful network may improve reliability by detecting and correcting otherwise missed errors.

  • It may improve cost by aborting faulty transfers early.

  • But these are complications that could go wrong too.

The End-to-End Guideline

• Think carefully before maintaining end-to-end properties at intermediate points in a system.

  The function in question can completely and correctly be implemented only with the knowledge of the application standing at the end-points of the communication system.

  Therefore, providing the questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete implementation of the function provided by the communication system may be helpful as a performance enhancement.)

Encryption

• Consider encrypted communication between two end-points.

• Encryption is an end-to-end property.

• An encrypting network is of little help for end-to-end encryption.

  • The key distribution problem.

  • What happens outside the network?

  • No authentication at all.

• But encrypted networks may be otherwise useful.

TCP

• But what about TCP?

• First, TCP is an end-to-end protocol.

  • TCP is not implemented in the network.

• Second, explicit network assists haven't been successful.

  • Network congestion information is helpful, however.

    • Congestion control is not an end-to-end property; flow control is.

• Third, TCP is not end-to-end reliable.

  • It's only host-to-host reliable.

  • Delivery guarantees are end-to-end reliable.

Non-End-to-End Properties

• Is there anything that isn't end-to-end?

  • Network routing.

  • Maintaining network circuits.

• Both require end-point help (specifying the target address, specifying the circuit characteristics), but can't be implemented by end points.

  • Despite TCP's source-address routing.

  • Adding circuits (data flows) to TCP is a source of contention.

Some Problem Spots

• Is quality of service (QoS) an end-to-end property?

  • QoS specifies connection characteristics, such as bandwidth or acceptable delay.

  • The answer seems yes, except for adaptive end-points.

    • Low bandwidth? Compress the data.

  • This is a contentious issue.

• Is multicast an end-to-end property?

  • Multicast delivers a single source to multiple destinations.

  • Transmission seems so, but what about management?

End-to-End Consequences

• The end-to-end guideline resists moving function from the end-points to the intermediate points.

• The intermediate points are simple, which makes them efficient and flexible.

• Intermediate points are end-point neutral, supporting new services.

• The end-points are complex, but the complexity is directed to the task at hand.

  • End-point complexity can be encapsulated in libraries.

Bucking End-to-End

• Why not add end-to-end properties to intermediate points just to be sure?

  • Intermediate-point design and implementation effort increases.

  • Uninterested end-points may incur unneeded costs.

  • Interested end-points may not be served well.

• Homogeneous systems are more able to ignore end-to-end design than are heterogeneous systems.

  • Homogeneous systems have uniform and constrained requirements.

Threats to End-to-End

• Most threats to end-to-end design comes from the endpoints.

  • Non-conforming end-points; trust is an end-to-end property.

  • Demanding service models; tele-medicine.

  • Non-technical factors; network wiretapping.

The Telephone Network

• The Telephone network doesn't follow end-to-end guidelines. Why?

• It's a homogeneous, voice-traffic system.

  • Except for data traffic, which is a problem.

• Non-technological factors support smarts in the network.

  • Smart networks means dumb end-points.

• Historical momentum comes into play too.

  • Prior technology didn't support alternatives.

• It's hard to extract monopoly rent from commodities.

  • I'm still paying $1.35 a month for touch-tone service.

High-Speed Networks

• High-speed networks make a virtue of end-to-end design.

  • Calculating in high-speed optical nodes is hard.

  • There isn't a lot of time for calculations.

• High-speed networks have extreme characteristics.

  • They're very fast, very reliable, and crashes are spectacular.

Points to Remember

• The end-to-end argument is a design guideline.

  • Which functions go where in structured systems?

• Avoid imposing redundant or expensive functions.

  • "All things to all people" is the road to ruin.

Bibliography

• End-to-End arguments in System Design by Jerome Saltzer, David Reed and David Clark; ACM Transactions on Computing Systems; Vol. 2, No. 4; November 1984.

• Rethinking the Design of the Internet: The End to End Argument vs. The Brave New World by Marjory Blumenthal and David Clark; ACM Transactions on Internet Technology; Vol. 1, No. 1; August 2001.

• Some Internet Architectural Guidelines and Philosophy by R. Bush and D. Meyer; RFC 3439; December 2001.

  Simplicity is paramount because complexity is unscalable. The end-to-end guideline is derived from simplicity.

• The Rise of the Middle and the Future of End to End: Reflections on the Evolution of the Internet Architecture by James Kampf and Rob Austein; RFC 3724; March 2004.

  The motivations for moving function into the network is growing stronger, but the end-to-end guideline has served the Internet well and should not be ignored when considering changes to the Internet architecture.

This page last modified on 6 December 2004.