[e2e] Does congestion control belong to The TransportLayer?

[Cannara]

As Stephen says, FDX, which is really not Ethernet, but Etherent framing with
other forms of contention/flow control added, has guaranteed-delivery control
frames, as do fabric protocols, like CSIX, SPIx...  Plain old Ethernet does
indeed achieve congestion control via exponential backoff on repeated
collisions, and reliability, by resend up to the 16th collision in a row. 
After that, the MAC reports "network not available" to the layer above, just
as TCP, after its 5th (or adjusted) timeout in a row will report to SMB or
whatever is above.  TCP was not the originator of flow/congestion control.

The purpose of any flow control at any layer is to match the buffering
capabilities with the responsiveness of the network piece under the influence
of the control system, to provide some reliability in the service delivered to
the next higher layer.  For Ethernet, this means a switched segment, with
micro to millisecond responsiveness.  For deep fabrics, as in metro switching
systems (that we all invisibly use), the speeds and buffering span even
broader realms.  No one claims that Ethernet/metro-fiber flow control will
make router buffering unnecessary at the network layer.

Alex

Stephen Suryaputra wrote:
> 
> Ethernet uses hop-by-hop flow control (pause frames) for congestion control. This is
> for full duplex. For half-duplex, it sends carrier on the congested input port (arbitrates
> access to the medium, like you said).
> 
> -----Original Message-----
> From: David P. Reed [mailto:dpreed at reed.com]
> Sent: Monday, April 26, 2004 7:15 AM
> To: cannara at attglobal.net; End-to-end
> Subject: Re: [e2e] Does congestion control belong to The TransportLayer?
> 
> 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.