[Codel] [PATCH 1/2] codel: Controlled Delay AQM
Andrew McGregor
andrewmcgr at gmail.com
Mon May 7 21:20:10 EDT 2012
On 8/05/2012, at 1:15 PM, Jim Gettys wrote:
> On 05/07/2012 04: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.
>
> Client initiated ECN may still be problematic. It is *fine* if a system
> responds to ECN that is sent to it. We know that is fine, as Linux has
> had the server side of ECN enabled for quite a few years, and those
> systems now are > 20% of servers on the internet.
>
>
> What we don't want is to get a pile of codel bug reports that are really
> ECN related problems, of which we know there are quite a few.
> - Jim
>
Sure... but making the Linux codel ECN capable, and even on by default with no configuration, will have no effect if the clients don't use ECN. So there's no need to even make it optional, let alone default to off.
That way, we don't get bug reports of 'codel doesn't do ECN'.
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2330 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/codel/attachments/20120508/a019bb8e/attachment-0002.bin>
More information about the Codel
mailing list