Re: [Starlink] Starlink hidden buffers

[Michael Richardson <mcr@sandelman.ca>]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]


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   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]