From: Kevin Wampler (wampler@cs.washington.edu)
Date: Wed Oct 13 2004 - 00:51:51 PDT
In "End-To-End arguments in System Design" the argument is presented that,
as much as is reasonably possible, the functionality of a network should
be implemented only by applications on its endpoints. The reasons for
this are many fold containing themes such as extensibility to future
applications, and the necessity of error checking at the application
level.
In general, I agree with the authors that putting functionality at the
ends of a network is a good design philosophy. Since it is generally much
easier to change functionality of applications at the endpoints, this
method is more flexible to future changes in demands made of network
transmissions, and can help to encourage (be necessity) a solid
transmission design at the endpoints. This gain is, however, not without
its risks. Putting functionality at the network level does have the
advantage in that since it is both uniform and difficult to change, it
imposes a standard on how communications are preformed. This may help
both to keep a massive soup of various communication protocols from
arising. It also would make sense for certain functions, such as perhaps
congestion control or accountability functionality, to exist on the
network level so that malicious or malfunctioning code could not as easily
harm the network. Putting responsibility at the endpoints also has the
disadvantage that it forces users to implement their own error checking
schemes to communicate over a noisy channel, where perhaps a network base
error correction scheme would suffice for the non-critical purposes of the
program. Similar arguments would apply to other cases such as out of
order transmission, though in both cases network APIs would with a doubt
be of great help. In either case the benefits of adopting in large a
endpoint oriented design likely outweigh the costs.
This archive was generated by hypermail 2.1.6 : Wed Oct 13 2004 - 00:51:51 PDT