Re: [Codel] [PATCH 1/2] codel: Controlled Delay AQM

[dave taht <dave.taht@gmail.com>]

On 05/07/2012 01:03 PM, Eric Dumazet wrote:
> On Mon, 2012-05-07 at 15:36 -0400, Jim Gettys wrote:
>
>> I think it is safe for it to behave the rest of the way Linux ECN
>> support does right now: it only gets used if the peer requests it.
>>
>> Not clear to me there needs to be/should be any option at all: the last
>> conversation I had with Steve Bauer was that something north of 20% of
>> conversations were ECN capable. Is there one for the other instances of
>> ECN support in Linux?  If so, it should be keyed by the same variable,
>> and not be a one-off for codel.
>>
> SFB, one of the latest qdisc added in linux has ECN support enabled.
>
> There is no option to disable it, because I felt it was safe. Maybe I
> was a fool, but problem is I am not sure SFB is even used.
My own testing with SFB as done was simultaneously with
the "GSO by default" change to linux in Febuary of last year.

The results were dismal.

But: At the time I was unaware of the GSO change.

I only stumbled across that commit months later, and I made
sure all future testing disabled all offloading of any kind via
the debloat script.

At that point I'd thrown out all the data and started looking at
other alternatives. I no longer feel Blue works worth a darn
in the first place, anyway. The bloom filter is neat, and
I like the idea of punishing unresponsive flows (particularly
packets marked ecn but not responding to ecn indicators),
but it just plain doesn't work.

My low opinion of TSO/GSO/UFO GRO etc is well known,
although I'd not mind them at all so long as
a working AQM was in place on the card itself.

I am glad to see that these offloads have improved a lot
over the past year, however.

>> If you wanted to test ECN separately from drop with codel, then you'd
>> just request ECN in the conversation (by default, OS's don't normally
>> request ECN today, as the remaining brokenness gets sorted out).
> Since ECN is not mentioned in Codel paper, this means no simulation was
> done to study the possible effects.
Yes, I'd like simulations with long RTTs.
> So its probably better to leave ECN as an option. We can change the
> default later.
The incremental approach has been tried re this option for
a decade. I'd prefer "on by default", and then find more ways
to make ECN work, to automagically detect and workaround
problems, but I realize I'm in a minority here, and am not going to
push the point for mainline. CeroWrt, yes. On by default,
and pursue this goal.

>
>