Re: [Codel] [RFCv2 PATCH] codel: add ecn_target for when to drop rather than mark ecn packets

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

On Mon, Jun 25, 2012 at 10:48 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
> My impression is that ECN ignorant flows do exist, because of stupid routers rather than malice, and that Dave considers this a problem worth tackling in codel.

Malice will exist. It is easy to create a set of flows that will
overwhelm either codel or fq_codel, with ecn enabled.

fq_codel does respond well to udp flooding, I note, far better than pfifo_fast.

>
> However I would disagree that the problem needs tackling here, at least for fq_codel which already segregates non-responsive flows from others. The ignorant flows will experience higher latency if this link is a bottleneck for them, that is all.

the first version of fq_codel had a separate codel queue per flow,
which would behave as you say. The lastest version uses the global
drop probability, which makes more sense in the general case.

I continue to prototype with qfq+codel which has the first behavior,
presently. I like the idea of a more perfect fluid model, especially
at the bandwidths I operate at (2-30Mbit), with the cpu horsepower
available to make more better choices than fq_codel can.


> Plain codel might need a more robust defence, but I have a different suggestion for that. Determine whether a prolonged bout of marking is being caused by ECN ignorant flows, and if so disable ECN marking (just drop) until the ignorant flows have clearly gone away.

Well, an example algo for that would be helpful. SFB tried to do this.

I note that codel operates independently of RTT and I am thinking hard
that RTT related issues need to be explored overall.

> The key to knowledge is not to rely on others to teach you it.

I am an experimenter first and foremost. My inspirations are more from
edison than tesla. Queue behavior is rarely intuitive, and the only
way to build intuition, for me, at least, is to design an experiment
and observe what happens.

Kelly Johnson could "see air". Perhaps van and kathie can "see
packets". Me, on the other hand...

>
> On 25 Jun 2012, at 18:45, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> On Mon, 2012-06-25 at 08:30 -0700, Dave Taht wrote:
>>
>>> It was the way I was leaning until I observed me dropping ecn enabled
>>> mosh, ssh, and babel packets , which tend to be small, so I started
>>> thinking in terms of dropping ecn packets on a graduated packet size
>>> scale after exceeding target. ESPECIALLY in case of overload you want
>>> command and control packets to get through.
>>>
>>
>> Don't try to add in CoDel things that should be done at another layer.
>> There is no classification in CoDel : Its a FIFO.
>>
>> Only way is to prioritize control packets if you need to, and use
>> several queues.
>>
>> I dont understand... Are you saying that you feel the need to drop
>> packets instead of marking them in a 'good citizen world' (none of your
>> flow pretends to use ECN to avoid drops) ?
>>
>>
>>
>> _______________________________________________
>> Codel mailing list
>> Codel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/codel



-- 
Dave Täht
http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-6 is out
with fq_codel!"