End-to-End Arguments in System Design

J. H. Saltzer, D. P. Reeed, D. D. Clark, "End-to-End Arguments in System Design," 2nd International Conference on Distributed Computing Systems, Paris, (April 1981), pp. 509-512.

One line summary: This paper presents the “end-to-end argument,” a design principle for guiding placement of functions in a distributed system that argues for moving function implementation upward and closer to the application level in certain scenarios to avoid redundancy and added cost.

Summary

The end-to-end argument with respect to communications systems can be summarized as follows: most functions can only be “completely and correctly” implemented with the knowledge of the end-point applications, so providing such functions at the lower layers below the application is not sufficient. Such functions will usually have to be re-implemented in some form at the application level, resulting in redundancy and potentially decreased performance. The authors provide several example functions in communication networks to which the end-to-end argument can be applied, including end-to-end reliability, delivery acknowledgment, secure data transmission, duplicate message suppression, and FIFO message delivery. They also provide both current and historical instances in which the end-to-end argument has been used outside of communication networks, including in transaction management, in support of RISC computer architecture and in OS “kernalization” projects.

The authors are careful to point out that the end-to-end argument is not an absolute rule that can be applied in all situations. To illustrate they give the example of a computer communication network that caries voice packets. In the first scenario, these voice packets are being carried between two users on telephones in real-time conversation. If in this case, reliability is implemented at the lower layers via the usual means of retransmissions and acknowledgments, this will likely introduce unacceptable delays into the application, rendering conversation difficult. Instead, the application would do better to accept damaged or missing packets and rely on higher-level mechanisms to achieve the needed reliability, such as one user asking the other to repeat something if it was unintelligible. In this scenario the end-to-end argument clearly applies. In the second scenario, voice packets are being transmitted from the sender to storage for later listening, like in voicemail. In this case, delays are no longer disruptive, and in fact reliability and message correctness gain importance, since the listener can’t ask the speaker to repeat something. Thus, in this case, low-level implementation of reliability would be acceptable, and the end-to-end argument does not necessarily hold.

Critique

The important contribution of this paper is its identification and articulation of a central theme that has guided designers of many varieties of computer systems up to today. An extension of this approach is a layered architecture design, although the end-to-end argument is arguably more general than that. As the authors themselves point out, this principle has provided important guidance and support in not only networks, but also operating systems and hardware design, among others.

One question that came to my mind as I read the paper are: what is the counter-argument to the end-to-end argument? Are there certain functions or situations for which implementation of the function at the low levels, or redundantly at a number of levels, is called for? I haven’t thought of any particular examples yet but I’ve been pondering.