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

It seems that  the presentation used Linux version for Codel. I can't 
quite get what exactly it does but it does not decrease count by two (as 
in the draft):

on reentering dropping state within 16 intervals:
delta = vars->count - vars->lastcount;
vars->count = delta;
vars->lastcount = vars->count;

See  the bottom image on slide 18 
https://www.ietf.org/proceedings/85/slides/slides-85-iccrg-2.pdf: count 
does not get reset to zero, but it drops by at least two times * .

It also seems that the delay variations on slide 15 with two UDP flows 
were caused by this reentering behavior...

* cake version did not exist at the time, did it?

On 09/30/2015 05:57 PM, Jeff Weeks wrote:
> I don't believe codel does start fresh; there are various back-off mechanisms that have been employed in the management of 'count' such that if the drop state is entered soon after it previously left the drop state, it'll re-enter at close to the same interval.
>
> I believe these mechanisms were put in place to combat the sluggishness, but that doesn't help the initial drop state.
>
> In practice, I've found that incrementing 'count' more rapidly can help to a point... but incrementing it too much appears to result in the sqrt approximation diverging from the ideal value, and then things start to fall apart.
>
> --Jeff
>
> ________________________________________
> From: aqm [aqm-bounces@ietf.org] on behalf of Polina Goltsman [polina.goltsman@student.kit.edu]
> Sent: Wednesday, September 30, 2015 11:43 AM
> To: Bob Briscoe
> Cc: AQM IETF list
> Subject: Re: [aqm] CoDel's control law that determines drop frequency
>
> Bob,
>
> May I ask how curvy red is supposed to perform in those situations?
>
> 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.
>
> 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 ...
>
> BTW, I haven't seen any place in the original specification that
> suggested that fixed target delay is the intended design goal.
>
> 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
>>> aqm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/aqm
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm