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

[Michael B Greenwald]

   Thu, 11 Apr 2002 13:21:24 -0700
   Joe Touch <touch at ISI.EDU>

   David P. Reed wrote:
   > I am doing a very interesting app that does congestion control ...
   > in the app layer.  Why? ...
   >
   > Of course, the Internet that is being optimized by the "let's put all 
   > the intelligence in the routers or OS kernels" school will not support 
   > our application at all well.   :-)
   
   Why? Seems like that sort of coordinated congestion system could be 
   implemented as a service with a generic API for the application. That 
   would avoid reinventing it for each application, and further encourage 
   its coordination with other congestion control mechanisms in the kernel, 
   e.g., CM.
   
   The kernel is one place to implement generic, ongoing process services. 
   It is the place where shared services are typically placed.
   
   Reinventing all this at the application layer (ala peer nets) doesn't 
   make it more useful or more flexible; it just increases the number of 
   places to get it wrong.

Dave's claim (not to speak for him) is that (1) his CC
mechanism is *not* generic nor a service but
application-specific, (2) generic API's being advocated for
kernel and routers do not support his app (and if some future
supported API did, then some even farther-future app wouldn't
be supported by those, and so on) and, (3) he has little
interest in making this "more useful or more flexible" and
would not want such an API to be introduced in the routers and
OS.

The disagreement between you (and others) and Dave Reed (and
others) is philosophical.  I'm sure Dave will agree that it
"COULD be implemented as a service with a generic API ...",
his question will be "SHOULD it be?".

Although it may be true that "[the kernel] is the place where
shared services are _typically_ placed", some shared services
can be placed in libraries and end-nodes rather than kernels
and routers.  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.

I'm not trying to be disagreeable myself (really!) but it
seems as if this argument is rehashed again and again on
end2end-interest.  Each time it is almost as if we start over
from scratch.  It would be good if we had labels (it could be
a header field required on *all* mail to e2e-interest) so you
can skip the parts of the argument that we can all generate
mechanically if we know where on the spectrum you stand.

OK, got that off my chest.  Sorry for explaining what you
already know. :-{