Editing End-to-end principle (section)

{{Short description|Design principle for computer networking}}
{{Net neutrality}}

The '''end-to-end principle''' is a design principle in [[computer network]]ing that requires application-specific features (such as [[Reliability (computer networking)|reliability]] and security) to be implemented in the communicating [[end node]]s of the network, instead of in the network itself. Intermediary nodes (such as [[Gateway (telecommunications)|gateways]] and [[Router (computing)|routers]]) that exist to establish the network may still implement these features to improve efficiency but do not guarantee end-to-end functionality.

The essence of what would later be called the end-to-end principle was contained in the work of [[Donald Davies]] on [[packet-switched network]]s in the 1960s. [[Louis Pouzin]] pioneered the use of the end-to-end strategy in the [[CYCLADES]] network in the 1970s.<ref name="Bennett2009">{{cite web |last1=Bennett |first1=Richard |date=September 2009 |title=Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate |url=https://www.itif.org/files/2009-designed-for-change.pdf |access-date=11 September 2017 |publisher=Information Technology and Innovation Foundation |pages=7, 9, 11 |quote=Two significant packet networks preceded the TCP/IP Internet: ARPANET and CYCLADES. The designers of the Internet borrowed heavily from these systems, especially CYCLADES ... The first end-to-end research network was CYCLADES, designed by Louis Pouzin at IRIA in France with the support of BBN's Dave Walden and Alex McKenzie and deployed beginning in 1972.}}</ref><ref name=":0" /> The principle was first articulated explicitly in 1981 by [[Jerome H. Saltzer|Saltzer]], [[David P. Reed|Reed]], and [[David D. Clark|Clark]].<ref name="SRC1981" />{{efn|The 1981 paper<ref name="SRC1981" /> was published in ACM's TOCS in an updated version in 1984.<ref name="SRC1984" /><ref name="SAL1980" />}} The meaning of the end-to-end principle has been continuously reinterpreted ever since its initial articulation. Also, noteworthy formulations of the end-to-end principle can be found before the seminal 1981 Saltzer, Reed, and Clark paper.<ref name="SRC1984" />

A basic premise of the principle is that the payoffs from adding certain features required by the end application to the communication subsystem quickly diminish.  The end hosts have to implement these functions for correctness.{{efn|The full quote from the Saltzer, Reed, Clark paper states:<ref name="SRC1984" /> "In a system that includes communications, one usually draws a modular boundary around the communication subsystem and defines a firm interface between it and the rest of the system. When doing so, it becomes apparent that there is a list of functions each of which might be implemented in any of several ways: by the communication subsystem, by its client, as a joint venture, or perhaps redundantly, each doing its own version. In reasoning about this choice, the requirements of the application provide the basis for the following class of arguments: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible, and moreover, produces a performance penalty for all clients of the communication system. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) We call this line of reasoning against low-level function implementation the end-to-end argument." (p. 278).}} Implementing a specific function incurs some resource penalties regardless of whether the function is used or not, and implementing a specific function ''in the network'' adds these penalties to all clients, whether they need the function or not.