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

[Bob Briscoe <[e-mail]>]

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/