Re: [Bloat] Jumbo frames and LAN buffers (was: RE: Burst Loss)

["Richard Scheffenegger" <rscheff@gmx.at>]

Jonathan,

> What I'd like to see is a complete absence of need for retransmission on a 
> properly
> built wired network.  Obviously the capability still needs to be there to 
> cope with
> the parts that aren't properly built or aren't wired, but TCP can do that. 
> Throttling
> (in the form of Ethernet PAUSE) is simply the third possible method of 
> signalling
> congestion in the network, alongside delay and loss - and it happens to be 
> quite
> widely deployed already.

Two comments: TCP can currently NOT deal properly with non-congestion loss 
(with
other words, any loss will lead to a congestion control reaction - reduction 
of sending
rate). TCP can only (mostly) deal with the recovery part in a hopefully 
timely fashion.
In this area you'll find a high number of possible approaches, none of which 
is quite
backwards-compatible with "standard" TCP.

Second, you wouldn't want to deploy basic 802.3x to any network consisting 
of more
than a single switch. If you do, you can run into an effect called 
congestion tree formation,
where (simplified) the slowest receiver determines the global speed of your
ethernet network. 802.1Qbb is also prone to congestion trees, even though 
the probability
is somewhat reduced provided all priority classes are being used. 
Unfortunately, most
traffic is in the same 802.1p class... Adequate solutions (more complex than 
the FCP
buffer-credit based congestion avoidance) like 802.1Qau / QCN are not 
available
commercially afaik. (They need new NICs +  new Switches for the HW support).

But I agree, a L3 device should be able to distribute L2 congestion 
information
into the L3 header (even though today, cheap generic broadcom and perhaps 
even
Realtek chipsets support ECN marking even when they are running as L2 
switch;
a speciality firmware (see the DCTCP papers) is required though.

Best regards,
   Richard