End-to-End Arguments in System Design

Summary

This paper explains the "end-to-end principle" as it is used in system design, with many examples of its current use in communication networks.

The end-to-end principle states that many functions are best implemented at the higher layers because implementing them in the lower layers is redundant and lowers overall performance. Redundancy comes from the fact that a function provided at the lowest level does not meet all the needs of every application - therefore, the application will have to implement that function at the highest level as well, rendering the lower-level function unnecessary. Another argument for end-to-end is that if everything is implemented at the lower levels, all applications whether or not they need them will be forced to use them, hindering their performance.

The authors illustrate the concept with a "careful file transfer" example, which I think did a great job of explaining when to and when not to put some functionality in the lower layers. The authors suggest that the only time functionality should be added to the lower layers is if it improves the application's performance in a manner that cannot be done by the application. However, this should still not be a full implementation of that functionality - the application will still be expected to implement it. The authors also provide an example (real-time voice communication) of where including functionality in the lower levels would actually hinder an application.

Criticisms & Questions

One thing I would have liked to see in the paper were the drawbacks to the end-to-end argument. The authors briefly touch on the fact that end-to-end may increase overall cost because each application would have to implement their own reliability mechanisms. However, I would have liked to see more discussion on the potential drawbacks. Possibly in a future paper, it would be interesting to see if end-to-end could be modified to address those drawbacks.

I see how the end-to-end argument applies in many situations, but I would think that there are sets of applications that all require the same mechanisms, and in that case, each application programmer would have to re-implement those mechanisms, leading to redundancy at the application level. I wonder if it's possible to add in some way for these applications to share these more common mechanisms.

Feedback

I enjoyed reading this paper - it was clear and easy to understand. I especially liked all the examples - they helped me to understand the different applications of the end-to-end argument. Therefore, I would argue that this paper should be kept in the syllabus.