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