<div dir="ltr"><div>This thread got pretty long. I just had a comment tweak me a bit:</div><div><br></div><div>Fair queueing provides an automatic and reasonably robust means of defense against simple single threaded DOS attacks, and badly behaving software. My favorite example of this was in the early days of cerowrt, we had a dhcpv6 bug that after a counter flipped over in 51 days, it flooded the upstream with dhcpv6 requests. We did not notice this *at all* in day to day use, until looking at cpu and bandwidth usage and scratching our heads for a while (and rebooting... and waiting 51 days... and waiting for the user population and ISPs to report more instances of this bug)</div><div><br></div><div>These are the biggest reliability reasons why I think FQ is *necessary* across the edges of the internet.</div><div><br></div><div>pure AQM, in the case above, since that flood was uncontrollable, would have resulted in a 99.99% or so drop rate for all other traffic. While that would have been easier to diagnose I suppose, the near term outcome would have been quite damaging. </div><div><br></div><div>Even the proposed policer modes in L4S would not have handled this bug.</div><div><br></div><div>I always try to make a clear distinction between FQ and AQM techniques. Both are useful and needed, for different reasons (but in the general case, I think the DRR++ derived FQ in fq_codel is the cats pajamas, and far more important than any form of AQM)</div><div><br></div></div>