<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
There's no doubt about the fact that Saltzer was and still is regarded
as one of the brightest lights in the system architecture firmament,
and that in particular his seminal paper on naming and addressing was
one of the most cogent pieces of its kind ever written. It's
unfortunate that the structure of Saltzer's thinking isn't reflected in
the organization of Internet protocols, naming, and addressing and that
he wasn't able to pass his brilliance along to all of his students.<br>
<br>
RB<br>
<br>
David P. Reed wrote:
<blockquote cite="mid:4AE38220.7010202@reed.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<font face="Helvetica, Arial, sans-serif">I don't know why I waste my
time explaining to Richard Bennett what he misreads, but here goes:</font><br>
<br>
On 10/24/2009 03:54 PM, Richard Bennett wrote:
<blockquote cite="mid:4AE35B6E.1080801@bennett.com" type="cite"><br>
<br>
Noel Chiappa wrote: <br>
<blockquote type="cite"> > From: Richard Bennett
<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:richard@bennett.com"><richard@bennett.com></a> <br>
<br>
> Moors shows that the Saltzer, Reed, and Clark argument for
end-to-end <br>
> placement is both circular and inconsistent with the FTP
example that <br>
> is supposed to demonstrate it. <br>
<br>
I didn't see that at all. <br>
</blockquote>
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. <br>
<br>
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". <br>
<br>
</blockquote>
OK. This is incredibly simple to understand. In the end-to-end
argument paper, we describe a program called "careful file transfer",
whose goal is to ensure that the file received is a proper copy of the
source. We use this "careful file transfer" example as a pedagogical
device.<br>
<br>
The paper carefully does not claim that TCP or FTP over TCP satisfy the
end-to-end argument required for the function "careful file transfer".
There was a reason: FTP/TCP does not do so.<br>
<br>
Now, RB claims that Moors's paper somehow says the argument is
inconsistent with the FTP example. Well, no. It is consistent with
the actual example we use, which is not FTP/TCP.<br>
<br>
Bennett may have joined late this particular discussion. If so, he
missed my earlier posting that said that the end-to-end argument did
not say "TCP is best". It was not a defense of TCP at all (unless you
accept his mind-reading of the authors' intent to somehow write the
paper to be part of some fight that Bennett imagines was going on).<br>
<br>
The end-to-end argument paper was not a paper about TCP or IP or any
particular implementation of any protocol, except insofar as it was
inspired by architectural discussions in the design, and was cited
quite frequently by IETF architects later as they considered designs
happening afterwards. It was about a way to think about architectural
questions - one that was used frequently and heavily in the original
TCP and IP design process, and as noted in the paper, in a number of
other processes we were aware of and had been involved in.<br>
<br>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC</pre>
</body>
</html>