One problem with fair queueing is that it can be gamed. By opening multiple
flows you achieve unfair priority. Part of Codel or PIE's beauty is that
they are blind to the traffic, only reacting to the externally visible
characteristics. This stems from the question 'what is a flow?'. There is
no easy answer to this question, so Codel and PIE intentionally avoid the
question.
Of course in many practical situations some simple assumptions about what a
flow is do work, and in those situations fair queueing performs very well.
It's important to keep in mind the limitations though. Fair queueing is not
a panacea.
Simon
Sent with AquaMail for Android
http://www.aqua-mail.com
On April 13, 2015 10:41:37 AM Toke Høiland-Jørgensen <[email protected]> wrote:
"Francini, Andrea (Andrea)" <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
