From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9F03B3B29E for ; Wed, 24 May 2023 10:05:08 -0400 (EDT) Received: from dlang-mobile (unknown [10.2.2.69]) by mail.lang.hm (Postfix) with ESMTP id C1B881913B1; Wed, 24 May 2023 07:05:07 -0700 (PDT) Date: Wed, 24 May 2023 07:05:07 -0700 (PDT) From: David Lang To: Dave Taht cc: Ulrich Speidel , David Lang , "starlink@lists.bufferbloat.net" In-Reply-To: Message-ID: <8n2250q1-60s1-831o-ss14-r1796747976n@ynat.uz> References: <0no84q43-s4n6-45n8-50or-12o3rq104n99@ynat.uz> <48b00469-0dbb-54c4-bedb-3aecbf714a1a@auckland.ac.nz> <728orr66-1432-751p-263q-sqopr12s20sq@ynat.uz> <077e6ad1-d7cc-2d57-39f8-e9646bea32a5@auckland.ac.nz> <09552rq0-0n24-0pqo-4085-n918r0n71138@ynat.uz> <9q29o7n2-69rs-3os1-s93q-0795262qs3o1@ynat.uz> <1c9df33b-e964-f531-7326-1a11b159e6a7@auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Subject: Re: [Starlink] Starlink hidden buffers X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2023 14:05:08 -0000 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) >