END-TO-END ARGUMENTS IN SYSTEM DESIGN

In this paper, Saltzer et. al. present a design principle called “end-to-end argument” which should help designers with the placement of functionalities over a distributed computer system. Usually when the computer involves some kind of communication, a modular boundary is drawn between the part which is responsible for communication (called the communication subsystem in this paper) and the rest of system. The question is: when it is possible to implement a functionality at different levels what should be the choice of designer? One can choose to implement the target functionality at either one of the following ways:

1) by the communication subsystem

2) by the end clients

3) as a joint venture

4) all of the above (redundantly)

In brief, the “end-to-end argument” states that when the function under investigation can only be correctly and completely implemented with the help and knowledge of the end-user application, the communication subsystem can not provide this functionality to the application as a feature.

This does not mean that communication subsystem features and helper functionalities are not important but rather restates that one should look at them from an engineering tradeoff point of view and in support of (and not in parallel with) application required functionalities. The implementation of a functionality at lower levels can become too costly for two reasons. First, the commonality of lower level subsystems to many applications makes other applications also pay for the functionality. Second, the lower levels have access to less information and therefore might not be able to do the job efficiently.

Furthermore, the authors of the paper go over a series of examples that the “end-to-end argument” applies and gives insight to the designers of such systems including: delivery guarantees, secure transmission of data (end-to-end encryption), duplicate message suppression, guaranteeing FIFO message delivery and transaction management.

The most important point of this paper in my point of view is that do not expect a system to accomplish what is not possible! The description of the “end-to-end argument” as given in this paper seems trivial and still very important. As given by several examples in the paper, it is easy to confuse the scope of the required functionality.

I still have a point of disagreement with the authors. The “end-to-end argument” as stated in the paper only applies when it is not possible for the communication subsystem to provide the exact target functionality. In that case it is obvious that the end-to-end application needs to implement the target functionality. But if it is possible that certain functionality be implemented in end clients or communication subsystem or a mixture of both, then we are entering the world of engineering tradeoffs and no unique answer can be given to all systems. On case by case basis, according to the class of target applications and functionalities and system sub-elements, one will try to find the architecture which works close to optimal in some sense!

For example the authors have an example of automatic recovery which goes as follows: “ In telephone exchanges, a failure that could cause a single call to be lost is considered not worth providing explicit recovery for, since the caller will probably replace the call if it matters” which claim is an example of end-to-end argument. I would like to argue that since it is possible to implement this functionality by communication-subsystem or end-users, the end-to-end argument as given above does not hold. Rather the authors are implicitly solving an optimization problem which minimizes certain cost function. If one was designing this system for very lazy kind of people, he/she would probably design it differently.

I believe this is a good paper to be kept in the syllabus since it points to a very complex and confusing topic being the function placement.