[e2e] 10% packet loss stops TCP flow

[David P. Reed]

Just a comment on the Saltzer, Reed, and Clark paper's dates, from one 
of the co-authors.  It's very misleading to compare dates of publication.

It was first drafted in late 1978/early 1979, based on my work on my 
Ph.D. thesis completed that year plus my work on TCP in 1976-1977.   In 
those days it was not atypical to submit a paper for publication in the 
systems literature and have it take 3 or more years in the pipeline 
before acquiring a pub date.  I gave visitor talks on some of the ideas 
in 1978 and 1979 as I visited many colleagues around the world, for 
example at IBM Zurich, Caltech, etc.

The genesis of the paper was in my collaborations with my mentor Jerry 
Saltzer, Dave Clark, and other MIT systems faculty focusing on 
architectural principles relating to OS's (my S.m. thesis on processor 
multiplexing in a layerd OS), security (the Multics security kernel 
work),  and network layering choices...  In particular it was that Jerry 
Saltzer, my advisor said to me: David, throughout your thesis and in 
your reports of the arguments being made about layering in TCP and IP, 
you keep making the same sort of argument - move the function to the 
edges of the network, and avoid putting function in the network itself, 
even when it feels a bit "unnatural".  The common argument made by most 
designers in system design (OS and networks) is to move everything into 
the common OS and network.   So this is really an underappreciated and 
new design/architectural principle.   We should write a paper about it, 
because it really is not intuitive to many in the field, but it seems 
important.

We did, and since it was such a nice simple example, we used end-to-end 
reliable delivery as our iconic example, but pointed out how general the 
idea was and that it was a general form of argumentation that made sense 
in the systems design world that has to deal with pragmatics of systems 
that must have a long life, scale across a wide range, and accomodate 
new, unanticipated applications.

Many people read and commented on it in draft form, and it was presented 
and published in several places.

Note that we didn't invent the instances of the end-to-end argument (in 
fact we took the name from the common terminology in the TCP design team 
of TCP as an end-to-end protocol, overlaid on a heterogeneous set of 
networks).   We just pointed out that many of the design arguments that 
we and others in the community were making had that form, and tried to 
elucidate the benefits of following the argument (primarily in the form 
of design in the face of unknown and unknowable future needs).