[e2e] Multiple TCP-friendly Sessions and Cong. Control in user-mode?

[David P. Reed]

At 12:19 PM 4/12/2002 -0400, Michael B Greenwald wrote:
>   Dave [and other advocates of the strong
>end-to-end argument] believe[s] that only the minimal
>necessary mechanism should be put in the routers/kernels and
>everything else implemented "at the ends".  I doubt he'd be
>sympathetic to, for example, fears about "increasing the
>number of places to get it wrong."
>
>You two can agree on all the facts; where you disagree is on
>the *criteria* for placement of functionality in the
>kernel/routers.  The end2end argument is such motherhood now
>that everyone agrees with it on paper (or won't admit to
>disagreeing with it); now the camps distinguish themselves by
>whether they hold it strongly or weakly.

Thanks for pointing out that this needs clarifying.

1. The only end-to-end argument I know of is the one discussed in my 
ancient paper.  If that is the "strong end-to-end argument", could somebody 
please write the paper that defines and justifies the "weak" one?   I hope 
it doesn't turn out that the "weak" one is defined to be "whatever it takes 
to justify what I'm doing, because it is taboo to disagree with the 
end-to-end argument."  If there is a "weak end-to-end argument", could 
someone lay it out in such a way that one can compare it point-by-point 
with the "end-to-end argument" I wrote about?   And having done so, show 
how it would apply in some real situations, just as we did in our 
paper?   Otherwise, I'll start calling it the "faux end-to-end argument", 
vs. the "real end-to-end argument."

2.  The reason we called a specific class of design arguments "end-to-end 
arguments" is because they are indeed "arguments".   They must be invoked 
in context, and with clarity about what they mean and why they mean 
that.  And then the designer should weigh that argument's impact on the 
design.   When we wrote the paper, Jerry and I (and I think Dave Clark) 
were trying to point out that this was an important way to think about 
modular and layered designs.  We expected that *every* design problem would 
result in one or more applications of the end-to-end argument, and that it 
would indeed have required that the argument be argued!

Not surprising that I and others still bring it up as new problems are 
worked, because each new problem deserves such discussion, and apparently 
only a few of us have been trained to see the tradeoffs involved. [I call 
the contra-end-to-end class of arguments the "focused-optimality arguments" 
- which roughly say, we know what the system will be used for, and over 
that class of uses, we know how to implement the function much cheaper and 
perhaps even more effectively, if we break down all the modular barriers 
and implement large common parts of the limited applications "in the 
system"]   Baldwin and Clark in their book "Design Rules" show the positive 
economic value of modularity that arises when a system is expected to 
evolve to support unanticipated applications, and that tradeoff is one of 
the key issues behind the end-to-end argument and other arguments for 
modularity.  But those arguments for modularity and end-to-end design are 
easily ignored by people who think as Voltaire put it "we live in the best 
of all possible worlds" and that the future holds no new possibilities.

3. It may seem like I'm a broken record, but the best way to shut me up is 
to start thinking through the impact of the end-to-end arguments as you 
deal with new problems.  Not just as a check-box "we thought about it for 
two seconds, but decided we didn't want to worry about it" followed by the 
fun of throwing another middlebox or ill-thought out "optimization" into 
the network because, well, because we can and we're smarter than the people 
who are trying to build useful stuff on top of our network.   Remember, a 
Sr. VP of NYNEX told me in 1992 that they had surveyed all their customers 
and there was no demand for high-speed networking from people's 
homes.   I'm sure you've surveyed all the people who might build 
interesting real-time or massively scalable collaborative applications and 
concluded that all of those applications behave like FTP, the favorite 
benchmark for "TCP tuners" and queueing modelers.

I've been having an interesting discussion offline with Joe Touch, which I 
would be happy to share with the list if you like.