“End-to-End Arguments in System Design”

Aside: I’m taking CS268 this semester, a graduate class in computer networking at UC Berkeley. We need to post biweekly paper summaries of the papers we read on our blogs, the first of which is below.

The “end-to-end argument” is a classic design principle for building distributed computer systems. Given a piece of functionality (e.g. reliable transmission), how should the system designer decide whether to implement that functionality in the application, or in the lower-level layers of the system? The “end-to-end principle” argues that to correctly implement most application requirements, both communication end-points need to be involved. Since the application must be involved to allow the functionality to be implemented correctly, implementing a redundant version of the functionality in the communications subsystem is not required for correctness. Therefore, implementing functionality in a lower level of the system can only be justified if:

  1. All network clients require the functionality, and it can be correctly implemented at that layer, OR
  2. A low-level implementation offers better performance, and that is judged to be worth the overall performance and complexity costs

For a particular problem, the performance improvement offered by a low-level implementation might be justified. As such, the E2E argument doesn’t condemn any particular design — it just provides a set of tradeoffs that system designers should consider when deciding how to divide a system’s functionality into layers.

The authors observe that implementing functionality in the communications subsystem can be actively harmful, because doing so can impose a performance or complexity cost on other applications that don’t require the functionality (applications that may not even be conceived of when the low-level network is deployed). For example, the ordering/reliable delivery guarantees offered by TCP can delay packet delivery substantially, making it a poor fit for real-time voice and audio applications. This is reminiscent of the C++ design philosophy, “if you don’t use it, you don’t need to pay for it.”

This paper is important because it addresses a fundamental question in the design of layered systems, and because its argument is largely reflected by the Internet architecture. Following the E2E argument leads to systems of many layers; the lowest layers should provide simple, general-purpose communication primitives that can be shared by all network clients. The higher levels provide more convenient features for certain classes of applications. The designer of a new application is free to choose to use high-level protocols if they match his requirements and offer acceptable performance, or to build upon low-level interfaces to implement the necessary functionality himself.

Another perspective on the E2E argument is that by pushing complex functionality into the communications subsystem, the communications subsystem is essentially being optimized for a single application. The E2E principle suggests that this is typically unwise, if the communications subsystem is intended to be general-purpose and might be used with a wide range of applications, including some that aren’t even known during the initial design phase. In contrast, the E2E argument is less relevant if the communications subsystem is being designed only for use by a closed set of applications. When building a system that is specialized for a particular application, pushing high-level functionality into low-level system components is easier to justify, because it can often offer enormous performance improvements.

For example, consider Kickfire, a startup company which builds specialized hardware “appliances” for analytic DB workloads. By pushing predicate evaluation down to specialized hardware components that run close to the I/O devices, a massive improvement in scan performance can be achieved — but this essentially specializes the I/O layer for a particular database application. This isn’t necessarily a violation of the E2E argument, because the system isn’t intended to be general-purpose and because the performance advantage it offers is presumably justified.

Related papers

A more recent comment (1998) by the authors discusses the application of the E2E argument to active networks.

An interesting application of the end-to-end argument can be found in “Understanding the Limitations of Causally and Totally Ordered Communication” by Cheriton and Skeen. They essentially argue that group communication systems violate the end-to-end argument. Ken Birman’s response to the Cheriton and Skeen paper is also worth reading.

Advertisements

2 Comments

Filed under Paper Summaries

2 responses to ““End-to-End Arguments in System Design”

  1. Pingback: Design Philosophy of the DARPA Internet Protocols « Everything is Data

  2. Pingback: “MACAW: A Media Access Protocol for Wireless LAN’s” « Everything is Data

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s