[e2e] Does congestion control belong to The TransportLayer?
pingpan at cs.columbia.edu
Mon Apr 26 10:14:17 PDT 2004
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. ;-)
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.
More information about the end2end-interest