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

[Richard Bennett]

Noel Chiappa wrote:
>     > From: Richard Bennett <richard at bennett.com>
>
>     > Moors shows that the Saltzer, Reed, and Clark argument for end-to-end
>     > placement is both circular and inconsistent with the FTP example that
>     > is supposed to demonstrate it.
>
> I didn't see that at all.
>   
Moors points out that TCP error detection and recovery is an end-system 
function, but not really an endpoint function in the file transfer 
example. The file transfer *application* is the endpoint, so placing the 
error detection and recovery function in TCP is actually putting it in 
an intermediate system level. This becomes clear when we recognize that 
TCP is often implemented in hardware or in firmware running on a CPU 
that lives on an interface card. The paper goes to great lengths to show 
that host-based TCP is immune to problem induced at MIT by a bad 1822 
interface card, but it was very common engineering practice in the 
mid-80s to implement TCP on an interface card that had the same 
vulnerability as the 1822 card. Excelan and Ungermann-Bass built these 
systems and they were very popular. They designed in a competent level 
of data integrity at the bus interface, so it wasn't necessary to rely 
on software to detect bus problems. So it's at least ironic that the 
end-to-end argument on the data integrity basis was mooted by practice 
by the time the 1984 version of the paper was published.

Because the file transfer program doesn't do its own data integrity 
checking but relies on TCP to do it, it's not really an example of 
endpoint placement at all; in fact, it's a "partial implementation".
>
>     > One of the more interesting unresolved questions about "End-to-End
>     > Args" is why it was written in the first place. Some people see it as a
>     > salvo in the ISO protocol wars, others as an attack in BBN's ARPANET,
>     > some as an attempt to criss the divide between engineering and policy
>
> I don't know whether to be amused or outraged by this nonsense.
>   
I don't know why this question should get anybody upset, it's just a 
question about the context and motivation of the paper in the first 
place. None of the authors was part of the inner circle of the Internet 
protocol design at the time the paper was written, although Clark was 
either the Chief Architect of the Internet or on his way to becoming 
same. I would have expected Cerf and Kahn to write something explaining 
the architectural decisions they made in adapting the  framework to 
their system, but their failure to do so meant someone else had to do 
it. Why these three people and why this particular time? It's never been 
explained.
> I will settle for observing that you probably haven't interacted much with
> Jerry - because had you done so, it would have been utterly obvious to you
> that overwhelmingly his most important motivation in writing the paper was
> his deep commitment to improving the art of system architecture.
>
> Dave Reed is here to defend himself, and as to Dave Clark, I would be prepared
> to bet pretty much any stakes that he'd be in the front rank in acclaiming the
> ARPANet as a huge step forward in information networking.
>
> The reference to the "ISO protocol wars" is completely mystifying, as the
> architecture of the ISO stack (at least, the CLNP/TP4 flavour, which was the
> subset which gave TCP/IP the best 'run for their money') is basically
> identical to that of TCP/IP (modulo disagreements on certain arcane points,
> such as exactly what kind of abstract entities the names at the various levels
> refer to - a subject wholly unrelated to the end-end debate).
The "ISO protocol wars" I am referring to took place within the context 
of the ISO development community between the CLNP that the datagram 
people wanted and CONS, the connection-oriented service that was 
proposed by the European PTTs. CONS was an extension of the line of 
development that went from ARPANET to X.25, which CLNP was on the line 
that went from CYCLADES through DECnet. The naming and addressing logic 
in CLNP and its predecessors was very different from TCP/IP but 
consistent with these others. The reasons that ISO didn't succeed are 
well-documented in John Day's "Patterns in Network Architecture."

Like it or not, Noel, there was a lot of friction between the Network 
Working Group and BBN over the control BBN had over the ARPANET 
protocols inside the IMP. The interesting problems of the day in 
protocol design were all behind the curtain to the people who used the 
ARPANET, and that's frustrating to engineers. Nobody disagrees that 
ARPANET was a huge first step in packet switching; but by 1981, people 
were well into the second step, and the closed implementation of the 
lower three layers was a problem.
> 	Noel
>   

-- 
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC