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

> 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.

I’m also interested to see how interactive adaptive applications are performing on the different FQ schemes. For most of the time, such an application will behave as a greedy flow (always data available), while the generation of application data is made fast adaptive to the available throughput experienced by the sender application. Obviously the interactivity is enhanced when the network has a very low latency, which is not provided by the FQ_noCodel scheme. Reporting the self inflicted delay on greedy flows might be a good measurement to additionally report in the test suites, so its impact on greedy interactive applications can be estimated.

> So both a mark/drop algorithm and flow queuing are needed to really solve
> the problem, though as Toke says, fq makes the biggest difference if you only pick one.

I expect also that the advantage of FQ in general will becomes less relevant if the queue of all flows in the network are very small and even most of the time empty. This is what you see already when a low latency configured AQM is combined with FQ. The lower the latency in the queues the less the impact of FQ. FQ might still have an advantage in case of dynamics where a queue build up cannot be avoided.

Koen.

From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Jim Gettys
Sent: maandag 13 april 2015 20:43
To: Toke Høiland-Jørgensen
Cc: Michael Welzl; aqm@ietf.org; Francini, Andrea (Andrea)
Subject: Re: [aqm] References on AQM test results and fq_nocodel

Note that having no AQM at all, and only flow queuing (e.g. fq_nocodel), leaves some applications in dire straights, being both interactive, and using a single TCP stream (for example, you really don't want to run my favorite window system, X, over a bloated link without some form of mark/drop algorithm to keep TCP behaving sanely).  And with RTT's of those applications growing without bounds, they become really insane charging elephants.  Ironically, I used to be able to run X over intercontinental links (e.g. 150ms RTT's); trying that on today's bloated edge puts you in a world of hurt.

So both a mark/drop algorithm and flow queuing are needed to really solve the problem, though as Toke says, fq makes the biggest difference if you only pick one. But this is really more of an artifact of the web's abuse of TCP; tons of short, transient connections...
                                            - Jim

On Mon, Apr 13, 2015 at 1:41 PM, Toke Høiland-Jørgensen <toke@toke.dk<mailto:toke@toke.dk>> wrote:
"Francini, Andrea (Andrea)" <andrea.francini@alcatel-lucent.com<mailto:andrea.francini@alcatel-lucent.com>> 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

> 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 :)

-Toke

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