|
Re: Last Call: <draft-ietf-aqm-fq-codel-05.txt> (FlowQueue-Codel) to Experimental RFC
2016-03-18 10:03:38
IESG, authors,
1. Safe?
My main concern is with applicability. In particular, the sentence in
section 7 on Deployment Status: "We believe it to be a safe default and
encourage people running Linux to turn it on: ...". and a similar
sentiment repeated in the conclusions. "and we believe it to be safe to
turn on by default, as has already happened in a number of Linux
distributions."
Can one of the authors explain why a solution with the limitations in
section 6 can still be described as "safe"? Doesn't "safe" mean "no
unintended side-effects"? For instance, the limitations section says
FQ_CoDel will schedule all the flows within an IPsec VPN as one entity -
equivalent to a single microflow outside the VPN. Also, it says FQ_CoDel
overrides the attempt of a scavenger flow to use less capacity than
other flows (consequently causing foreground flows to get less capacity
than intended). Why do the authors feel the need to say that these
behaviours are safe?
Indeed, these sentences seem rather Orwellian. They assert the current
group-think as fact, even though it is the opposite of the facts stated
earlier.
Would it not be correct instead to say that FQ_CoDel has been made the
default in a number of Linux distributions despite not being safe in
some circumstances?
2. Default?
If a draft saying "We believe it to be a safe default..." is published
as an RFC, it means "The IETF/IESG/etc believes..."
Only one solution can be default, so if the IETF says that FQ_CoDel is a
safe default, and no other AQM RFC makes any claim to being a safe
default (which they do not at the moment), it could be read as the IETF
recommending FQ_CoDel for default status and, by implication, other AQMs
(like PIE, say) are not recommended for default status.
As far as I know, unlike the listed FQ_CoDel limitations, no limitations
of PIE have been identified. I don't think anyone is claiming that the
performance of FQ_CoDel is
awesomely better than PIE. May be a bit better, may be a bit worse,
depending on circumstances, and depending on which you value most out of
low queuing delay, high utilization, or low loss.
So, if the authors want the IETF to recommend a default AQM on the basis
of safety (and I agree safety is the most important factor when choosing
a default), the most likely candidate would be PIE, wouldn't it?
FQ_CoDel has unintended side-effects, which implies it is not a good
candidate for default; it should only be configured deliberately by
those who can live with the side-effects.
I believe these unintended side-effects were the main reason PIE rather
than FQ_CoDel was defined as the minimum requirement for a DOCSIS 3.1
cable modem.
For those reading this who haven't been following the AQM WG, I can
assure you I'm not associated with the authors of PIE (or FQ_CoDel).
Indeed, I provided an extensive critique of PIE during the WG phase.
3. A Detail
I also have a concern about the way the limitations are written
(typically, each limitation is stated, followed by a arm-waving
qualification attempting to create an impression that there is not
really a limitation). To keep the thread clean, I'll send that in a
follow-up email.
Indeed, rather than downplay each limitation, it would be more
appropriate (and it is common IETF practice) to flag applicability
limitations up front, in the abstract.
Regards
Bob
On 03/03/16 17:20, The IESG wrote:
The IESG has received a request from the Active Queue Management and
Packet Scheduling WG (aqm) to consider the following document:
- 'FlowQueue-Codel'
<draft-ietf-aqm-fq-codel-05.txt> as Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2016-03-17. Exceptionally, comments
may be
sent toiesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This memo presents the FQ-CoDel hybrid packet scheduler/AQM
algorithm, a powerful tool for fighting bufferbloat and reducing
latency.
FQ-CoDel mixes packets from multiple flows and reduces the impact of
head of line blocking from bursty traffic. It provides isolation for
low-rate traffic such as DNS, web, and videoconferencing traffic. It
improves utilisation across the networking fabric, especially for
bidirectional traffic, by keeping queue lengths short; and it can be
implemented in a memory- and CPU-efficient fashion across a wide
range of hardware.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-aqm-fq-codel/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-aqm-fq-codel/ballot/
No IPR declarations have been submitted directly on this I-D.
--
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/
|
|