END-TO-END ARGUMENTS IN SYSTEM DESIGN
📜 Abstract
This paper presents a design principle that helps guide placement of functions among the modules of a distributed computer system. The principle, called the end-to-end argument, suggests that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level. Examples discussed in the paper include bit error recovery, security using encryption, duplicate message suppression, recovery from system crashes, and delivery acknowledgement. Low level mechanisms to support these functions are justified only as performance enhancements.
✨ Summary
The paper argues that functions requiring application-specific knowledge for complete and correct implementation should generally be implemented at the system’s endpoints rather than exclusively within lower-level communication or operating-system modules. Lower-level mechanisms can still be justified as performance enhancements, but they do not eliminate the need for end-to-end validation. The authors illustrate this reasoning through reliable file transfer, delivery acknowledgements, encryption, duplicate suppression, message ordering, transaction management, and real-time voice communication. They emphasize that the principle is a design guideline rather than an absolute rule, since the appropriate placement depends on application requirements and performance tradeoffs.
The paper became a frequently cited foundation for Internet architecture discussions. The Internet Architecture Board’s Architectural Principles of the Internet identifies end-to-end functions as generally best realized by end-to-end protocols and cites this paper as a fundamental reference. (rfc-editor.org) Later IETF work used the principle to analyze Internet transparency, the increasing role of middleboxes, and the changing balance between endpoint and network functionality. (rfc-editor.org) Subsequent architectural proposals continue to cite the paper when arguing that application-specific semantics should remain at endpoints and that shared network substrates should remain comparatively simple. (datatracker.ietf.org)