[e2e] Clarifying the End-to-End Principle

[David P. Reed]

The end-to-end argument is a design principle, not an outcome.   Thus, 
problems with TCP or IP are not proof that the end-to-end argument has 
failed.  Instead, the end-to-end design approach is called for in 
discussing solutions to those problems.

Yes, some of the terminology in the original paper is only loosely 
defined.  That's appropriate for a design principle because one presumes 
that humans use principles in conjunction with their domain knowledge to 
generate solutions.

It's easy to resolve some of the confusions.  Two are: what about servers 
that are owned by the network provider, and what about multipoint 
protocols.   Well, the end-to-end principle never talked about 
ownership.  So "economic bundling" has nothing to do with a service being 
"provided by the network" - the server is not "in the network".   The 
end-to-end argument talked about "endpoints" - some people read the paper 
as about circuits or sessions - but they would be wrong.  One can discuss 
the ensemble of endpoints (even heterogeneous classes like SMTP relays 
union SMTP UAs) as the set of endpoints treated by an end-to-end argument 
used in the design process.

One of the main conclusions of the end-to-end argument is usually to point 
out the inflexibility or difficulty of evolution of a design to incorporate 
requirements not known at the time of system design.  Non-end-to-end 
designs usually fail to meet future needs quickly.  That's the point.

No one would make an end-to-end design if they had a fully specified 
problem and were searching for the absolute optimum performance where all 
conditions are known.

Yet many of the "let's rewrite end-to-end" arguments are based on some 
person's urgency to deliver the maximum performance possible in the 
shortest possible time, evolvability-be-damned.

Designing a protocol that knows it is running over today's fiber net and 
today's 802.11 at the endpoints lets you invent really cool optimized 
solutions.  If anyone thinks that those architectures will be the same in 2 
years when the protocol is deployed worldwide, or in 5 years when their is 
a next generation of technology and applications, I can sell you my old set 
of Bell System Technical Journals that optimized the POTS system for 30 
years of unchanging technology.