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

[David P. Reed]

I don't know why I waste my time explaining to Richard Bennett what he 
misreads, but here goes:

On 10/24/2009 03:54 PM, Richard Bennett wrote:
>
>
> 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".
>
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.

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.

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.

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).

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.


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