Although this paper (Saltzer, End) is useful in helping distributed systems developers understand the complexities of application and protocol design it is not recommended for publication. The paper rightly argues that careful consideration should be given to the placement of functions within the layers of a software system, however, the paper is riddled with poor examples and the authors fail to identify the benefit of their design principle when examined from a software design perspective.
One need only look at the first example in the paper to see the flaws mentioned above. In the example the authors describe a careful file transfer application, which is designed to move files from one host to another across a data communications network without damage. The authors identify that the dropping, modification or loss of packets by the communications network is an obstacle to the application, and they proceed to describe how the data communications network might transparently deal with such situations. Interestingly, the authors then claim that such effort to ensure reliability on behalf of the data communications network is without value. Indeed they are correct in stating that "[the effort] has not effect on [the] inevitability or correctness of the outcome", but their claim that it "does not reduce the burden on the application" is bogus. In providing transparently reliable data communications the network improves the efficiency of the application by reducing retries, and removes the onus on the application developer to determine whether or not a problem is caused by an unreliable network or unreliable file system. What the authors fail to realize is that software design involves developing useful abstractions, a reliable data communications network being one of them. The effort to develop reliability in the communications network was not made to ensure reliable file transfer but simply to ensure a reliable communications network. Useful abstractions, like a reliable communications network, are designed to satisfy the needs of a wide array of expected applications. Take for example TCP, which has become such a useful abstraction that many thousands of applications have come to depend on it. And when existing useful abstractions fail developers are not locked into them as the authors suggest. Rather, new useful abstractions are created and are utilized alongside the older ones. Again, we can point to TCP and its peaceful coexistence with UDP.
Finally, although the authors are making conclusions about how to proceed with software design, they fail to describe the benefits of the "end-to-end" design principle in common software engineering terms such as complexity, reusability, and developer time. In not making concerned arguments for reusability the authors are in essence trading away developer time, yet they do not provide a qualitative analysis of the cost. Also, in discouraging the development of common pieces of functionality the authors are pushing complexity into applications.
Citations
Saltzer, J., Reed, D., and Clark, D. End-to-End Arguments in System Design
ACM Transactions on Computer Systems, Vol. 2, No. 4, 1984.