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
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
