[e2e] Does congestion control belong to The TransportLayer?

[Ping Pan]

We have just developed the GigE interface on a SONET switch. As we start
to test with other vendors, we noticed the following:
1. Ethernet Pause is nothing but a whining mechanism. It does not control
congestion (such as dropping etc.).
2. Most of the vendors do seem to respond (such as slowing down) to Pause
frames anyway. ;-)

- Ping

On Mon, 26 Apr 2004, 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.
>
>