[e2e] Protocols breaking the end-to-end argument
richard at bennett.com
Sat Oct 24 12:54:22 PDT 2009
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
> 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.
Information Technology and Innovation Foundation
More information about the end2end-interest