(no subject)

This paper outlines and supports the class of "end to end arguments"
using a number of examples. The end to end arguments are, in
general, that for many classes of applications, there are potential
errors that can only be detected at the application level and for
which the detection of these errors will also result in the detection
of other errors that could be detected at lower levels, and as such
it is unnecessary to check for these errors at a lower level. The
paper suggests that these errors should only be detected (and fixed)
at lower levels when doing so will improve performance.

"Identifying The Ends" is perhaps the most complex and interesting
issue related to the end to end arguments (although this may stem
from reading the paper two and a half decades later), but the section
of that title seems incomplete, providing only an example of a system
where the "ends" are farther apart than what we commonly consider to
be the application level, while not discussing the opposite, cases
where ends may be closer. These issues really only come through in
section 5 of this paper, where we see some historical examples.

In the case of the Multics file backup system, this appears to have
been a part of the file system, based upon some quick online
research, and the file system would have been used by other
applications, so for this purpose the file system is the "end". In
the case of the RISC architecture, I believe feature implementation
is not really at the client level, as suggested by the paper, but
instead at the compiler level (or we could split the difference and
call the compiler the client).

The reality seems to be that at some point to reduce the burden on
application developers and to reduce unnecessary redundancy, error
checking (or in the case of RISC, feature implementation) needs to be
abstracted away from the application developer. This is not
incompatible with end to end arguments, provided one considers the
end to be the lowest level at which the end to end arguments apply.
This seems obvious, but I believe it is a somewhat subtle point that
is not made nearly explicit enough in the paper.

I would like to discuss the paper in the context of TCP vs. IP, but I
believe I may be violating the request to keep things short.
Received on Wed Sep 13 2006 - 22:03:58 EDT