Dave Taht via Starlink <starlink@lists.bufferbloat.net> wrote:
> These are the biggest reliability reasons why I think FQ is *necessary*
> across the edges of the internet.
It saved your bacon, but yeah, like all other resilient protocols (DNS,
Happy Eyeballs) tends to hide when one option is failing :-)
> 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.
What this says is that fq_codel doesn't have enough management reporting
interfaces. Going back 25 years, this has always been a problem with home
routers: ntop3 is great, but it's not easy to use, and it's not that
accessible, and it often can't see things that move around.
> 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)
Could fq_codel emit flow statistics as a side-effect of it's classifications?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Starlink mailing list Starlink@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/starlink
