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
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm


_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

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

_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Reply via email to