Re: [Starlink] Starlink hidden buffers

[David Lang <david@lang.hm>]

fair point. I am playing a bit loose with the AQM terminology and definition 
here

David Lang

On Wed, 24 May 2023, Dave Taht wrote:

> 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)
>