END-TO-END ARGUMENTS IN SYSTEM DESIGN

END-TO-END ARGUMENTS IN SYSTEM DESIGN paper is one of the classic papers written by J.H. Saltzer, D.P. Reed and D.D. Clark. This paper discusses one of the design principles, called end-to-end argument, which provides guidance about where to place a function in layered systems. The paper argues that function implementation should be moved upward in layered systems - closer to the application that uses the function. Paper examines the end-to-end argument in detail using reliable data transmission in a communication system.

"The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)."

This paper examines the end-to-end argument using careful file transfer - move a file from source computer storage to destination computer storage without damage using a data communication network. The file can be corrupted due to various issues at various points - hardware or software issue at source or destination or communication system. The authors argue that correct file transmission can be only guaranteed by checks (checksum) and retry made at end points i.e at file transfer applications running at source and destination - whether or not the data communication system is especially reliable.

The paper also discusses that having function implementation at local level may enhance or hurt the performance of an application. For example - in the file transfer application, if the communication system is too unreliable, the file transfer application performance will suffer because of frequent retries. However, implementing a function at a lower level may hurt performance because of 2 reasons -

“First, since the lower level subsystem is common to many applications, those applications that do not need the function will pay for it anyway. Second, the low-level subsystem may not have as much information as the higher levels, so it cannot do the job as efficiently.”.

According to the authors the end-to-end argument is not an absolute rule, but rather a guideline that helps in application and protocol design analysis; one must use some care to identify the end points to which the argument should be applied.

The paper has also presented a few other examples of end-to-end arguments. One of the examples the authors discussed is Guaranteeing FIFO message delivery. FIFO ordering of delivered messages can only be guaranteed by some mechanism at the higher level because messages sent along independent virtual circuits, or through intermediate processes outside the communication subsystem may arrive in an order different from the order sent. 

However a follow on paper, A critical review of End-to-end arguments in system design by Tim Moors, highlights how some of the examples like integrity check, security, routing and congestion control have already been challenged and the function implementation have been migrated to lower levels. For example in case of integrity checks, the paper “A critical review of End-to-end arguments in system design” states:

“Trust of the network is not a characteristic of current Internet protocols, since they originated in a military environment and grew in a research and development environment, where network components often fail, are compromised, or perform erratically. However, the Internet is now becoming a mature operational commercial environment, and this need for end to-end checks may be weakened.”

End-to-end arguments applicability is found in other system areas too. Similar arguments as End-to-end is made in support of RISC architecture.

“The RISC argument is that the client of the architecture will get better performance by implementing exactly the instructions needed from primitive tools; any attempt by the computer designer to anticipate the client's requirements for an esoteric feature will probably miss the target slightly and the client will end up reimplementing that feature anyway”.

Lampson in his paper An open operating system for a single-user machine uses a similar argument.

“Lampson argues against making any function a permanent fixture of lower-level modules; the function may be provided by a lower-level module but it should always be replaceable by an application's special version of the function”

As per this paper - “A great deal of information about system implementation is needed to make this choice intelligently”. The paper concludes that End-to-end arguments are a kind of "Occam's razor" when it comes to choosing the functions to be provided in a communication subsystem.