[e2e] Multiple TCP-friendly Sessions and Cong. Control in
David P. Reed
dpreed at reed.com
Fri Apr 12 10:45:26 PDT 2002
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.
More information about the end2end-interest