[e2e] Protocols breaking the end-to-end argument

[David P. Reed]

On 10/24/2009 11:59 PM, Noel Chiappa wrote:
>      >  From: John Day<day at std.com>
>
>      >  It would be a little hard for the e2e paper in 1982 to be about the
>      >  CLNP/TP4 vs TCP/IP debate if half the debate didn't exist.
>
> Umm, I didn't say that the E2E paper was about the CLNP/TP4 vs TCP/IP 'debate'
>    
The end-to-end paper was not written to be a part of any war 
whatsoever.   I say that with knowledge of all of the 3 co-authors' 
intents and motivations.

I *now* am beginning to understand what mentality seems to be behind 
Bennett's informants' views of history.

It's an oddly American cultural thing to identify evolutionary and 
economic competitions as "wars".  We have the "war on drugs", for 
example.  Somehow the "wars" become ends in themselves: winnning vs. losing.

But studying the competitions rarely provides insight into real issues.  
Did the Battle of Gettysburg really tell us anything about either the 
causes: an economy based on human slavery and "free market" ideals (the 
American plantation south) vs. an economy based on industrialization, 
internal market growth, and protectionist/imperialist approaches (the 
American northeast)?   (who won that battle didn't even stop the 
argument...)  Did the Battle of Gettysburg predict the creation of "Jim 
Crow laws"?  Did it prevent them?

I do remember a wide variety of battles about elements of networking, 
including implementations of architectures.  I briefly was involved in 
the "token ring" vs. "bus" argument about physical infrastructure for 
LANs - not as an advocate of either side - and I found it completely 
bizarre.  The idea on the "token ring" side was that somehow its 
puissant "quality of service" would make the end-to-end communications 
work, while the "unreliable" CSMA/CD would never be "carrier grade". 
Bushwah - and I gently pointed that out in my portion of the original 
paper I wrote about LANs with Clark and Pogran for IEEE Proceedings: 
LANs would be parts of internets, and the QoS properties of a single LAN 
would not transcend that LAN's scope.

That argument was an implied end-to-end argument: if you want to get a 
specific service quality goal satisfied, putting the implementation of 
that function in (every part of every one of the) subnetworks is not a 
good design.

However, one can imagine achieving it that way.  The resulting 
architecture would be very inflexible, and costly to all of those who 
*don't* need that particular extreme service quality goal.   It would, 
for example, make it hard to migrate the path of any communication while 
it is happening.

In any case, the rather silly battle over CSMA/CD vs. token-controlled 
access was pretty meaningless in the context of any kind of 
internetworking: PUP or TCP or even the Cyclades thing.

But the "QoS" logic of that day pervades the debate even now.   It's so 
easy for those who don't build networks to wave their hands and say that 
(for example) Verizon can provide QoS on the Internet, when what is 
meant is that Verizon provides some latency control on *it's small 
segment of the path* to all interesting endpoints.

This is a rhetorical device called synecdoche - in which the attributes 
of a part are assumed to carry through to the whole.   The idea that 
Verizon can create QoS for the Internet by creating QoS for its part is 
a logical fallacy.  But it is one that humans continue to fall prey to.

So to summarize this longer diversion: the war between token ring and 
bus-Ethernet teaches us little, and subsequent success of Ethernet as a 
term teaches us very little about architecture: in fact, by shrinking 
the collision domain to a hub, and then later replacing it with a switch 
in the core, the Ethernet has moved towards the deterministic arbitrated 
structure of the token ring, along with the manageability of the 
"star-shaped" ring concept that Saltzer promoted as the topology.

So let's not study wars and battles.  Let's study architectural 
principles and their application.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091025/63404022/attachment.html