Re: Last Call: <draft-ietf-aqm-fq-codel-05.txt> (FlowQueue-Codel) to Experimental RFC

[Bob Briscoe <[e-mail]>]

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
> [e-mail]  mailing lists by 2016-03-17. Exceptionally, comments may be
> sent [e-mail]  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/