On Mar 18, 2011, at 11:30 AM, Richard Scheffenegger wrote:
>
> 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...
Lots of questions in that; 90% of the buffers in what? In a host, in a router,
on a card in a router, in a queue's configured maximum depth, what? One would
need some pedagogic support in the form of simulations - why 90% vs 91% vs 10%
vs whatever?
> Someone has to set an incentive for using ECN, unfortunately...
Yes. From my perspective, the right approach is probably more like introducing
a mark/drop threshold and a drop threshold. Taking the model that every M time
units we "do something" like
if queue depth exceeds <toobig>
reduce M
drop something
else if queue depth exceeds <big>
reduce M
select something
if it is ECN-capable,
mark it congestion-experienced
else
drop it
else is below <hysteresis limit>
increase M
the advantage of ECN traffic is that it is less likely to be dropped. That
might be a reasonable approach.
> 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
