Re: [aqm] CoDel's control law that determines drop frequency

[Jeff Weeks <[e-mail]>]

Getting back to this...

Bob; I agree.  Seems that the further we are from the target, the coarser the adjustments should be towards the target (and therefore, in codel, the larger increments of count, leading to larger reduction of the interval).

One problem is large modifications of 'count' in codel could result in the integer based calculation of 1/sqrt(count), that most implementation use, to lose accuracy, and may actually result in it diverging *away* from the correct value, rather than moving towards it.

I've seen success using CAKE's model of halving count upon re-entering the drop state (as well as multiplying 1/sqrt(count) by sqrt(2), for parity, but as you've noted, this just modifies the starting position -- the approach to the correct value is still a steady linear walk, and is unaffected by how far from the target we are.

It seems like codel could benefit by modulating 'count' based on some factor of the difference between the current packet latency, and the desired packet latency (i.e., the target), but again, that would make pre-calculating 1/sqrt(count) more challenging, and it's a non-starter (at least for me) to *actually* have to calculate with the full division and sqrt.

Cheers,
Jeff
________________________________________
From: aqm [[e-mail]] on behalf of Bob Briscoe [[e-mail]]
Sent: Thursday, October 01, 2015 9:06 AM
To: Polina Goltsman
Cc: AQM IETF list
Subject: Re: [aqm] CoDel's control law that determines drop frequency

Polina,

I've answered your points but changed their order...

On 30/09/15 16:43, Polina Goltsman wrote:
> Bob,
>
> If I understand Codel's law correctly, Codel "starts fresh" every time
> it enters dropping state, so when the load increases it will take more
> time for the control law to reach the correct "count" value for the
> queue to drop. Thus with higher load latency is increased.
As Jeff has said, Codel has been modified to not start count fresh every
time it enters dropping state.

My point was that no-one has questioned the control law itself, once in
dropping state. All the activity seems to have been around avoiding
having to start increasing count from fresh. However, the rate that the
control law increases count is completely disconnected from how bad the
queue is getting. Any good control system should make the strength of
the correction depend on how far the performance metric (queue delay) is
from its target.
>
> BTW, I haven't seen any place in the original specification that
> suggested that fixed target delay is the intended design goal.

'target' is the fixed delay target. The whole point of CoDel is to
detect when queue delay exceeds this target for more than interval, then
bring it back to this target by dropping packets.

>
> Now, if I understood your curvey red report correctly, you argued that
> AQM should increase latency when load increases since otherwise it
> will cause too much loss. Which makes Codel's behavior at least
> justified ...
No. At higher load CoDel's control law behaviour does not aim for a
higher target delay. It still aims for 'target'. In this thread so far,
we have been talking about sluggish dynamic behaviour in reaching the
target, not the target itself.

Just because a journey to the wrong place happens to go through the
right place, doesn't justify wandering slowly on the way to the wrong
place. Admittedly, you will be near the right place for a little longer,
but you'll also be in all the wrong places for longer, and once you
reach your destination, you will stay in the wrong place.

> May I ask how curvy red is supposed to perform in those situations?
>
Like CoDel, Curvy RED has a) a target and b) a process for getting there.

a) Unlike CoDel, the target delay is not fixed, it increases a little
with load. As you say, this avoids having to introduce too much loss.
The precise compromise between the two depends on how strongly each of
loss and delay affect the performance of typical applications - there is
not one answer to that, but I'm working on finding a reasonable compromise.

b) Like any good AQM, Curvy RED doesn't jump straight to its target. We
have introduced some smoothing delay so it doesn't start dropping
packets too quickly when hit by a burst that might disappear. Initially
we just used the same approach as RED - using an exponentially weighted
moving average of the queue. It works OK. We could probably improve on
this smoothing. But, as long as Curvy RED isn't significantly worse than
other AQMs, my main focus is the L4S side of the DualQ AQM that Koen
presented. I'm happy for others to improve on Curvy RED for existing TCP
traffic if they want - I won't get round to that for a while.

CoDel's (fixed) interval addresses this burst-smoothing problem, and
CoDel's (fixed) control law adds to its smoothing delay. It's unclear to
me why CoDel uses this control law to find the right level of drop.
Hence my question to Kathy & Van back in 2013 that started this thread
and still hasn't been answered.

Cheers


Bob

> Does this make any sense?
>
> Regards,
> Polina
>
> On 09/30/2015 02:59 PM, Bob Briscoe wrote:
>> Polina,
>>
>> I think this was it:
>> <https://www.ietf.org/proceedings/85/slides/slides-85-iccrg-2.pdf>
>>
>> I have a set of charts from Rong with many more tests showing CoDel's
>> sluggish responsiveness, but I believe the above was the published
>> summary.
>>
>>
>> Bob
>>
>> On 30/09/15 10:13, Polina Goltsman wrote:
>>> Dear Bob,
>>>
>>> On 09/30/2015 10:50 AM, Bob Briscoe wrote:
>>>>
>>>> Early on, Rong Pan showed that it takes CoDel ages to bring high
>>>> load under control. I think this linear increase is the reason.
>>>
>>> Is there a link to this ?
>>>
>>> Polina
>>>
>>> _______________________________________________
>>> aqm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/aqm
>>
>
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm

--
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

_______________________________________________
aqm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/aqm