Re: [Codel] [RFC PATCH] codel: ecn mark at target

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

On Mon, Aug 6, 2012 at 1:01 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2012-08-06 at 12:09 -0700, Andrew McGregor wrote:
>> On 6/08/2012, at 10:50 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> > This discussion is getting mildly off-track. My intent in posting this patch
>> > was to prove how wrong the "ecn mark at target" idea was by example,
>> > and in doing so, shed light on those new to codel, on how the algorithm
>> > actually works, and to encourage those that didn't grok it, to read and
>> > run the code in whatever scenarios would help more people to
>> > grokking in fullness.
>> >
>> > I hadn't expected to twiddle a bug!

I have put eric's ecn quickack patch into what will be the next
release of cerowrt.

I think I saw another related one go by, too.

>>
>> Well, so drop at target is wrong wrt deployed TCPs.  Ok, fine.
>>
>> So, instead, how about this: mark instead of dropping, but only for
>> the first few iterations around the while loop in dequeue (so that
>> huge backlogs can be drained).  The question then is, how many is a
>> few?  I suppose that can be answered empirically.
>>
>> Andrew
>
> Lets take the analogy with RED.
>
> Once a MAX_THRESH was reached, it did a hard_mark.
>
> So we could choose a threshold to drop instead of marking.
>
> Possible easy choices :
>
> 1) A threshold on sojourn time. For example force_drop = 2 * target

I tried this and the net result was that: as codel doesn't start the
drop scheduler until things are wildly out of wack, that a large
percentage of ecn marked packets would be dropped at the outset, and
only when things got closer to target would CE start to be asserted.

Fast convergence is kind of a feature but, arguably, to use ECN most
effectively would be to start off marking and switch to dropping if
marking was not being effective in reducing the the delay
sufficiently.

> 2) A threshold on 'count'. For example force_drop if count > 1000

This has the benefit of having not been tried. However how count
varies is presently subject to the implementation.

So, new proposal:

3) When entering the drop scheduler for the first time, CE mark rather
than drop on ecn enabled packets. Over time (an interval?) keep an
overall slope (ewma?) of the curve between ldelay and current delay.
If that overall slope is downwards toward the target, then great, ECN
marking is working, and we're eventually going to get back to target.
If it is upwards for greater than (x), then start dropping instead.

This has the desirable properties of:

A) Trying CE first
B) Continuing to apply CE if it works
C) In case of overload, drop

But you'll note that there is no code in this proposal, and what an
"overall slope" is, is a handwave.


>
>



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