[e2e] Does congestion control belong to The TransportLayer?

[Cannara]

David,

Let's start with the first misinterpretation...

"> Pretending that all traffic on the network consists of infinite-sized file
> transfers is intellectually ignorant.  It's about as informed as thinking
> that a 1/4 mile drag race in a "funny car" is an effective simulation of
> commuter traffic."

I don't believe anyone said that.  Why the straw men?

Now...

"> Doing this at the datagram level means throwing away all the information
> about the relationships between datagrams that is known at the application
> level."

Substitute "TCP/Transport" for "datagram" and explain how the application
level is involved with TCP other than Rx/Tx buffer delivery at the API?

Ethernet itself does congestion control on a LAN segment.  TCP does it above
that.  NetBIOS/SMB/Samba do it above that.  Ethernet's congestion control acts
at the micro- to milli-second scale.  TCP's is far slower, of necessity. 
Application level is slower still.  What most of us don't see is what goes on
continually in metro boxes (ADMs...) and their chassis.  There various forms
of control occur as well, also acting at very high speed, but obviously with
larger RTDs than LANs, and smaller ones than continental nets.  

My point is that the control needs to suit the environment.  The IP
environment typically extends end-to-end, as TOS intended, MPLS implements,
etc.  There's no fundamental reason for UDP, ICMP... to get less congestion
management than TCP.  There's no reason why any layer can't tell the other
side at that layer to stop sending -- it's done all the time at the DLC level,
can be done at IP with Source Quench, can be done at TCP, with Window=0, FIN,
or Reset, and is done at the app level.

No one disputes the plain fact that the application ends of a conversation
generate the traffic.  All Transports recognize that and provide what they
should -- windowing, retransmission and backoff.  TCP has a theory for
congestion management that differs from any other transport due to the panic
in the '80s about network collapse.  The solution to collapse prevention could
have been made more generally, even after the rush kludge to TCP.  But various
factors, including politics, forestalled that.  Since then many ideas for
improvement have been raised, many are being raised now, so all that happens
by delaying open research & testing, as ARPA effectively did, is to make the
problem harder logistically, rather than intellectually, because of the huge
installed base.  The result will be continual workarounds in various
applications, rather than a coherent protocol- development effort.  

Alex


"David P. Reed" wrote:
> 
> At 03:42 PM 4/25/2004, Cannara wrote:
> >If, as you suggest, the network incorprated management of its own congestion,
> >even if only at ends, but with good information from the interior, that would
> >be better.  That would indeed be an example of a network "service" -- datagram
> >carriage with congestion management.
> 
> Doing this at the datagram level means throwing away all the information
> about the relationships between datagrams that is known at the application
> level.   For example, some datagrams may be controlling other flows (such
> as datagrams that are used to tell the other end to stop sending!)
> 
> The whole reason that congestion control is end-to-end is because the
> ultimate causes of traffic are end-point algorithms, and it's those
> algorithms (and their human users) that need to adapt.   The multiplexing
> of independent streams happens at each OS's applcation API - so
> implementing ths "service" would have to reach back at least to that
> definition of the entry point into the network.
> 
> Pretending that all traffic on the network consists of infinite-sized file
> transfers is intellectually ignorant.  It's about as informed as thinking
> that a 1/4 mile drag race in a "funny car" is an effective simulation of
> commuter traffic.