review 1

End-to-End Arguments in System Design

Within the context of communication networks, the end-to-end argument
states that there are several classes of functionality that can only be
fully and correctly implemented and provided at the application level of
the endpoints. It follows then, that implementing this functionality in
lower levels would not relieve the application of the same duty and may
only result in that functionality being paid for twice. It is only for
the sake of performance, and not correctness, that lower-levels should
provide any features from these particular classes of functionality.
Applications generally have the most information available to them at the
highest level, and can thus make the most informed decisions.

This paper states and clarifies the end-to-end argument so that system
designers can think about it more clearly in order to make intelligent
decisions or when discussing layered architecture. The classes of
functionality are defined by example. Communication networks in
particular give rise to several classes of applications and functions to
which the end-to-end argument applies. Reliable communication, including
guaranteed message delivery and acknowledgement, encryption, message
ordering, and duplicate message supression are discussed as part of an
exemplar about file transfer. In all cases, the "correct" application
must re-provide these capabilities, since the network module either can't
be trusted, or can't fully provide the features. This is the case of
reliable delivery, where application state cannot be asserted by the
network module -- and that's what we really want to know about.

This paper also suggests many other examples of systems that employ the
same end-to-end methods effectively, including: Banking systems, backup
systems, RISC architectures and operating systems. The paper is
well-written and uses convincing examples to support the argument. The
optimal performance question is left somewhat unanswered and vague, in
that it's not clear how to actually decide how much of a feature should be
pushed lower. In this case, the general message seems to be that
flexibility is golden.
Received on Thu Sep 14 2006 - 01:24:22 EDT