Re: [aqm] References on AQM test results and fq_nocodel

[David Lang <[e-mail]>]

On Mon, 13 Apr 2015, Toke Høiland-Jørgensen wrote:

> "Francini, Andrea (Andrea)" <[e-mail]> writes:
>
>> CoDel's effort to limit the queuing delay appears well motivated when
>> there is only one queue (e.g., to shield VoIP from the delay induced
>> by bulk-transfer or video traffic), but when multiple queues are
>> available the net gain of the effort is unclear. I suspect the same
>> may happen with the flow-queue version of PIE.
>
> Yep, this has been my conclusion as well, and the test results on those
> slides are what convinced me of it: flow queueing is much more important
> than AQM, for most applications. However, note that in the tests I have
> run, the latency is measured by a separate flow; the latency of the
> packets making up the bulk flows is not measured. For most common
> traffic, this is fine, but there can be exceptions where you have a flow
> that has enough traffic to induce a queue, but which also requires low
> latency throughout. Adaptive video codecs for real-time media is a
> notable example. For those, having the AQM is nice.
>
> Also, having the AQM in place guards you against hash collisions. With
> the AQM in place, you degrade to its performance, whereas without,
> you're basically back to a large, dumb FIFO queue. fq_codel as it exists
> now is unfortunately not immune to those; we're working (in the
> Bufferbloat community) on an improved queueing discipline that solves
> this in most cases. See http://www.bufferbloat.net/projects/codel/wiki/Cake

do your finding still stand if you have enough different flows through the 
system that you end up with lots of flows (some of which may be bulk data) in 
each queue?

>> Is this just because the set of tests in the slides does not include
>> one that clearly exposes the superiority of fq_codel over fq_nocodel?
>> And what would that test look like?
>
> Well, see above. Adaptive real-time video in particular is under-tested,
> in part due to a lack of good tools to generate traffic. Also, if you
> want to see fq_* break, try sticking all your flows in an encrypted VPN :)

In this case, doesn't the router just see everything as a single flow? In which 
case there is nothing that it can do to affect priorities within that flow.

David Lang