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

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

Hi Bob

Thank you for your timely and constructive comments. Please see the
inline responses below.

> 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"?

"We believe it to be a safe default" means that we have not seen any of
the theoretical limitations we have documented in section 6 be a concern
*in practice* in any of the extensive number of deployments FQ-CoDel has
seen already. And that the benefits of turning on FQ-CoDel are
sufficient that nudging people in that direction is a good idea.

> Indeed, these sentences seem rather Orwellian.

I can assure you that we are not attempting to exert "draconian control
by propaganda, surveillance, misinformation, denial of truth, and
manipulation of the past" (quoting
https://en.wikipedia.org/wiki/Orwellian here). But thank you for
implying it :)

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

At the time it was made the default in OpenWrt (several years ago now,
if memory serves me right), there was not a whole lot of real-world
deployment experience, due to the chicken-and-egg problem of not wanting
to change the default before we have gathered more experience. However,
today the situation is quite different, thanks in part to the boldness
of the OpenWrt devs. So no, I do not believe that to be the case any
longer.

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

This is certainly not my reading. This is an experimental RFC saying "we
believe it to be safe as a default" not a standards track RFC saying
"this should be the default". This is an important difference; we are
not mandating anything, but rather expressing our honest opinion on
the applicability of FQ-CoDel as a default, should anyone wish to make
it one in their domain.

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

Well, for CoDel and PIE that is certainly true. But FQ-CoDel in many
cases reduces latency under load by an order of magnitude compared to
both of them, while improving throughput.

> 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'm not sure it would be possible for the AQM group to agree on a
recommendation for a default. But I suppose it might be a good
bikeshedding exercise. And as noted above, this is not what we intend to
do in this case.

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

It is certainly not our intention to "create an impression that there is
not really a limitation". Rather, we are trying to suggest ways in which
each limitation can be mitigated by people who are concerned about it,
but still want to realise the benefits of deploying FQ-CoDel. Sure, some
of those proposals are not exactly at the "running code" stage, but
dismissing them as arm-waving is hardly fair.

I'll add, as I noted initially, that many of the limitations we have
noted are of a theoretical nature (in the sense that we are not aware of
any deployments where they have caused issue in practice). This does not
make it any less important to document them, of course, and we have been
grateful for the feedback from the working group that the section grew
out of (you yourself were among the people providing this feedback, I
believe). However, this also means that it is difficult to do more than
point out each issue. We can't quantify them, for instance.

If you have concrete suggestions for language that would make things
clearer, do tell (though I suppose that's exactly what you'll do in your
follow-up mail). :)

-Toke