[Codel] drop state short-circuit...

[Jeff Weeks]

Thanks!

I'm a bit skeptical of 'count' usage in general, yes.

Say the codel algorithm is managing a large queue, using the default parameters.

That queue could fill, and codel would enter the drop state, and we'd then start dropping packets at 100ms, 70ms, 57ms, 50ms, etc... (i.e., 100/sqrt(count)).

If the queue size is reasonable, this converges quickly on the correct drop rate.

However, if the queue is larger, it takes considerably longer to reach the correct drop rate.

I has previously (perhaps incorrectly) thought that the queue size becomes somewhat irrelevant when using codel, as the queue is effectively managed by inspecting packet latencies, rather than blindly queuing and dequeuing, but that's not entirely true, it seems, as there's no limit placed on the enqueue operation.

In other words, given a high enough input rate, and a large enough queue, codel will still output packets considerably beyond the target ms, no?

Put another way -- if the codel algorithm starts in a heavily congested pipe, it will take many seconds before it can adjust to a 1ms interval (count would have to rise to 10,000).  While adjusting, it's very likely to output many packets with high latencies.

Is this a concern for the algorithm?

--Jeff


________________________________
From: Jonathan Morton [chromatix99 at gmail.com]
Sent: Tuesday, August 11, 2015 1:35 PM
To: Jeff Weeks
Cc: codel at lists.bufferbloat.net
Subject: Re: [Codel] drop state short-circuit...


The logic is that if the stored count was effectively controlling the queue, we want to keep using that value if the network is still under load.  If 16 intervals (1.6 seconds) pass without re-entering drop state, we can assume the link is no longer saturated (by this flow) and reset count.

I think the value 16 itself is mostly arbitrary.

I'm a bit skeptical of the way count is saved and restored in the reference versions - it's hard to follow.  Cake's version explicitly keeps the old value, but halves it, allowing it to grow back to its original value if required.  It would also be reasonable to scale the backoff with time, rather than thresholding it.

- Jonathan Morton