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 [[email protected]] on behalf of Polina Goltsman
[[email protected]]
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
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
