Summary of 'End-to-End Arguments in System Design' by Saltzer, Reed and Clark

This paper describes the end-to-end argument, which states that functionality of a network system should be pushed as close to the endpoint, i.e. the application that uses it, instead of putting much functionality in the lower level of the system. If functions are placed at lower levels of the network, all applications that use the network use the functions redundantly, even if they don't need them.

A simple example application Saltzer used was the secure file transfer example. The task is simple: from machine A transfer file x to machine B securely. There are several things that can go wrong such as machine B receiving an incorrect file due to hardware faults on the way, host failure, mistakes in buffering on either end or dropped or duplicate packets. These problems can be addressed by implementing the checksum functionality in the application level. It is more efficient, since the application knows best how to check for correctness and this also reduces redundancy in the network's lower levels.

There are a few other applications Saltzer cites as examples to the end-to-end argument such as duplicate suppression, delivery guarantee, secure data transmission and guaranteeing FIFO order in packets delivery.

This paper sets the basics for TCP/IP networks. Instead of the traditional encapsulation of functionality in the network systems, they argue to leave the network as simple as possible and push all the functionality to the ends (or as close as possible). In most cases this introduces great reduction in complexity and redundancy of operations. However, this principle does not work for all applications. One example they use is the voice data transfer. If the data needs to be securely and correctly tranferred right away, then we do need the functionality of checking for correct packets to be lower in the system, allowing for delays of course.

The question arises then of where to draw the line between simple network systems with no functionality, to complex networks with encapsulated functionality on all levels. This is where much experimentation would shine some light on this issue and in particular by applying it to various scenarios. This is a very good paper, and describes with good arguments the basics of the network systems used today. It is interesting to read from the first source as to why and how these principles were invented and widely spread.