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

[Toke Høiland-Jørgensen <[e-mail]>]

Hi Andrea

> 1. Besides the results in Toke’s ICCRG presentation at IETF 91 in
> November 2014
> (http://www.ietf.org/proceedings/91/slides/slides-91-iccrg-4.pdf),
> where can I find other comprehensive comparisons of AQM
> implementations for Linux (or any other non-simulated system that
> handles real packets)?

The data underlying my experiments are available from here:
http://www.cs.kau.se/tohojo/modern-aqms/ -- that page also has links to
the test scripts used to run the experiments. The paper is still under
submission, so can't link that, sadly, but I can share a copy with you
privately if you are interested.

> 2. In Toke’s slides, the fq_nocodel scheme appears to be never worse
> than fq_codel (or any other AQM in those tests), except for the VoIP
> delay plot of slide 12. Besides the Linux code, is there anywhere a
> description of the fq_nocodel scheme?

Well, fq_nocodel is basically the term I use for fq_codel configured so
as to disable the CoDel algorithm (i.e. the target and/or interval is
set to 100 seconds so the algorithm never triggers). As such, it doesn't
have a description outside of my paper, but you can read the fq_codel
draft and ignore everything it says about CoDel, I suppose :)

Also, note that configuring fq_codel in this way in Linux is not optimal
in terms of CPU use: it deliberate triggers the overflow drop mechanism,
which does a linear search through all configured queues, eating up 4k
of cache on every drop. If your test router is sufficiently
CPU-over-provisioned (a modern x86 counts as this for <=1Gbit speeds)
this doesn't affect performance, but I wouldn't recommend it on a tiny
MIPS processor, for instance. (Oh, and this limitation is specific to
the current implementation, and could easily be fixed if anyone wanted
to; the overflow mechanism was meant as a backup, and so wasn't
optimised like, say, the SFQ was).

-Toke