[e2e] Does congestion control belong to The TransportLayer?

Cannara cannara at attglobal.net
Mon Apr 26 09:39:05 PDT 2004


See my response to Stephen, David.  Ethernet seems to offer more than you
expect.  On:

"> At best, some of these examples try to hide transient congestion, by
> introducing expandable buffering capacity.   But that just makes the
> inevitable result of congestion more catastrophic when it does happen."

All computing is done via dynamic allocation in a fixed space -- that's
reality.  The scales of time involved are what are relevant.  When the
shortest buffer driving the slowest link in a path fills (or reaches the
firmware's drop point) that's it -- new packets get dropped.  Having lower
layers do some flow/congestion control on individual subpaths helps, rather
than hurts this situation.  After all, a given router queue feeding a 10Gb/s
link has no idea what else is sharing that link inside the hardware that
drives the link.  If that hardware is careful to provide good datalink service
to all its inflows, great.  That's then a better situation for all the router
queues being fed in.

Alex


"David P. Reed" wrote:
> 
> At 01:30 AM 4/26/2004, Cannara wrote:
> >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.
> 
> Here I fail to see your point.  Encountering congestion is not controlling
> congestion.   Exactly how does Ethernet control congestion, for
> example?   As far as I can tell, it just arbitrates access to the medium
> (the switch fabric).
> 
> At best, some of these examples try to hide transient congestion, by
> introducing expandable buffering capacity.   But that just makes the
> inevitable result of congestion more catastrophic when it does happen.


More information about the end2end-interest mailing list