Re: [Starlink] Starlink hidden buffers

[Dave Taht <dave.taht@gmail.com>]

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

This thread got pretty long. I just had a comment tweak me a bit:

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)

These are the biggest reliability reasons why I think FQ is *necessary*
across the edges of the internet.

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.

Even the proposed policer modes in L4S would not have handled this bug.

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)

[-- Attachment #2: Type: text/html, Size: 1498 bytes --]