From: Kate Everitt (everitt@cs.washington.edu)
Date: Tue Oct 12 2004 - 19:49:08 PDT
End-to-End Arguments in System Design
Review: Katherine Everitt
The main argument in this paper is that end to end design is better for
most situations than lower level implementations. When functionality
such as error checking, security, and duplicate suppression is
implemented at a low level, it is inefficient and may make decisions
that are not appropriate for some applications.
There are several convincing examples in the paper to support this
point. For example, voice packets care more about delay than
reliability, but many applications care more about reliability than
delay. If we try to implement a low level system that makes assumptions
about how it is used, we may preclude some uses. In many cases the end
application is best positioned to be making these kinds of decisions.
Although the authors mentioned that the end-to-end argument was a
guideline more than a rule, they did not really discuss when it would be
inappropriate. If you can make no assumptions about the reliability and
speed of the underlying network, it is difficult for the end-to-end
applications to make decisions about how they should send information.
Also, sometimes it is the routers within the network that are best
placed to find certain kinds of error and determine efficiency. If the
only checking that is going on is at the endpoints, it becomes difficult
to diagnose errors such as “your packet was two big / too fast for
midpoints” and “I never got your packet because the midpoint can’t
handle x”. I feel the need for lower level checking strongly depends on
the error rate.
The other disadvantage of this scheme is it involves more complexity at
the endpoints. This is fine, but if the endpoint has limited buffering
capability, processing resources or weak connectivity, this algorithm
does not work as well. In general, this paper presents convincing
arguments that end-to-end design is better in some situations but could
do a better job of showing when it is appropriate.
This archive was generated by hypermail 2.1.6 : Tue Oct 12 2004 - 19:49:14 PDT