To help guide placement of functions among the modules of a distributed computer system.
This paper presents a general design principle, end-to-end argument.
The author 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.
The "care file transfer" problem is proposed as an example to show the advantage of end-to-end approach. The performance analysis and other examples of the end-to-end argument are given after that.
- Specific application-level functions usually cannot, and preferably should not, be built into the lower levels of the system.
- 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 communications system. Therefore, providing that questioned function as a feature of the communications systems itself is not possible.
- Significance rating: 4
Very general principle, not only for distributed systems, but also
for other system design contexts, e.g. OS. (5)
Put everything in the application level is not always feasible nor always leads to a better performance. It seems that end-to-end approach is a good choice only for certain context. (-1)
- Convincing rating:
The author cites many examples to show the advantage of the end-to-end
approach, and shows the main reasons of taking this approach:
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 communications system. Therefore, providing that questioned function as a feature of the communications systems itself is not possible.
If we put the functions at the low level, it's object to the design philosophy of the Internet architecture at that time: the low level subsystems shold provide a simple and flexible network for the applications.
While the author mentions the need for identifying the ends, is it always a easy task? It seems that applications with different requirements share the same low level part sometimes.
Although it is plausible to take some functions in a particular layer of a system, sometimes the analysis of the application and the structure of the system can help the designer to find alternatives which lead to a better overall performance.
The open question is, in what degree should the designer take the functions in her own layer of the system, especially before the applications that use the subsystem are known.