How about trying to push for a default, that the logical egress buffers are
limited to say 90% of the physical capacity, and only ECN-enabled flows may
use the remaining 10% when they get marked...
Someone has to set an incentive for using ECN, unfortunately...
Richard
----- Original Message -----
From: "Fred Baker" <[email protected]>
To: "Richard Scheffenegger" <[email protected]>
Cc: "Stephen Hemminger" <[email protected]>; "bloat"
<[email protected]>
Sent: Thursday, March 17, 2011 1:18 PM
Subject: Re: [Bloat] Random idea in reaction to all the discussion of
TCPflavours - timestamps?
On Mar 17, 2011, at 5:05 AM, Fred Baker wrote:
I'm very much in favor of ECN, which in all of the tests I have done has
proven very effective at limiting queues to the knee. I'm also in favor of
delay-based TCPs like CalTech FAST and the Hamilton and CAIA models; FAST
tunes to having a small amount of data continuously in queue at the
bottleneck, and Hamilton/CAIA tunes to a small bottleneck. The problem
tends to be that the "TCP Mafia" - poorly named, but a smallish set of
people who actually control widely-used TCP implementations - tend to very
much believe in the loss-based model, in part because of poor performance
from past delay-based implementations like Vegas and in part due to IPR
concerns. Also, commercial interests like Google are pushing very hard for
fast delivery of content, which is what is behind Linux' recent change to
set the initial window segments.
I didn't say, and should have said: I'm also in favor of AQM in any form; I
prefer marking to dropping, but both are signals to the end system. The
issue is that we need the right mark/drop rate, and the algorithms are
neither trivial nor (if the fact that after 20+ years Van and Kathy haven't
yet published a red-lite paper they're happy with is any indication) well
documented in the general case.=
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
