End-to-End Arguments in System Design

(link to paper)

The recurring argument/theme in this paper is that lower-level layers of system design are often not the best place to provide functionality like encryption, guaranteed message delivery, etc. because higher-level applications have more knowledge and may therefore need to replicate the functionality. In addition, the cost of providing some of these services at a low level is higher than building them at the application ("end") level.

As an example, a banking application may need to know that a withdrawal message was received by the server; the best way to do this is probably not through a low-level guaranteed message layer, since the message could be corrupted or tampered with in between the time it reaches the low-level messaging system of the server and the time the application receives it. What really needs to occur is that the application must acknowledge receiving (and acting on!) the withdrawal message.

I believe the general principle the paper espouses. However, I think (and the paper acknowledges this) the difficulty is in figuring out the "ends." How do we determine what they are? In addition, what is the argument in the context of layered messaging such as that in TCP/IP? Does it make sense to, instead of treating applications as the ends, treat layers as ends and build applications on top of the layers? When should a layering be used?

I think the paper leaves the determination of ends up for discussion, but as a discussion tool, it is perfect for the syllabus because it opens up space to discuss which functionality is essential and whether the cost of providing further features is worth the cost at each level. In that sense, the goal of the paper is to push designers to examine the costs of each function and whether it must be replicated before implementing it into the lower-level layers of the design.