From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 92B353B29E for ; Wed, 24 May 2023 09:44:47 -0400 (EDT) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-3f60804faf4so8142185e9.3 for ; Wed, 24 May 2023 06:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684935886; x=1687527886; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6pi7og8/fdYzv431mw5JI8W32UE9SYntuwcBLWHxYh8=; b=rPatfu2eyS4QtBqfaTWjt71C1+uAKbflp5Rqc3I6RRidJjpqCrvP2Aw+im0SuE8V/b 6ScZJSqXflZ9ADB99uYRXasCFa8tsAnqyfYPtCd8lZe3+YhSGRSkHzI0V5Kmy3//AD8s lvZKzfs7g1fjFsR3CVOz5QZ0Gt0nzrUTGWAbeJLNesLG0TMGnKMzFo6TR7KOWVlh0LRs YWKVo2TyRa27C5B+zjgIbFkEl8eXc+ae9wpIL1bDQZy3yhTTADaEVmXH51SmbH9/I4B8 guZeyqgpZB1hN86l6dsBwOBOmvntqp49UtY3MlaR1EjAvbRUQlXJ9J6kVjG63d/Qpnv+ AQbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684935886; x=1687527886; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6pi7og8/fdYzv431mw5JI8W32UE9SYntuwcBLWHxYh8=; b=g7jrOHkOBvwSKsoukc2RuKh1oGBbI6MEy+cjYLmD6FsbUtPK1CYsUIqdFZux09Ugii wx6Z0VhZaYlM6eRVf05TyfSnq/QJxHYmw8qfqypToL756tMiay96XQ5iC/uT+YFrNq8j 4ZCVQCEK2nG3ptr/WoIntDz1exkglqlWXkia97p77NQxITy8j053BhEP/m4yWaaC6r9U pVDGregx5jURjbFLLHQDJR33/9gIugn81UiSESBIEMLV1wG/yAPhgi9BcyHwBTIMVcwq d3Co8SoAz+Xgjp8IvkgjMOsQRwS+IW6vJcoFglv7HZFdYBfgirN3PGIeO6XKpZ9gMI31 6gMA== X-Gm-Message-State: AC+VfDwyrsXz1rQrS32P5bC5mUHq0fLK9EIBHbNsgt6fTi4CUPf9u3a+ gNLllXsSyGGVoBHmyXfMfk8EWbMN8I7O3yul0jEdfTFY X-Google-Smtp-Source: ACHHUZ4+DCTK/zI4Yac8Yv9TGpaK1l3KxXcg2UvCcm/Gdrt/u4mbGEK9Pj9LBTuDV6ww3IyO4D8HRl/OW4BOdeO9czs= X-Received: by 2002:a05:600c:228a:b0:3f6:426:eae with SMTP id 10-20020a05600c228a00b003f604260eaemr7325532wmf.15.1684935886062; Wed, 24 May 2023 06:44:46 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <1c9df33b-e964-f531-7326-1a11b159e6a7@auckland.ac.nz> From: Dave Taht Date: Wed, 24 May 2023 07:44:34 -0600 Message-ID: To: Ulrich Speidel Cc: David Lang , "starlink@lists.bufferbloat.net" Content-Type: multipart/alternative; boundary="000000000000f5634b05fc70b49e" 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 13:44:47 -0000 --000000000000f5634b05fc70b49e Content-Type: text/plain; charset="UTF-8" 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) --000000000000f5634b05fc70b49e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This thread got pretty long. I just had a comment twe= ak me a bit:

Fair queueing provides an automatic a= nd reasonably robust means of defense against simple single threaded DOS at= tacks, 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 ove= r in 51 days, it flooded the upstream with dhcpv6 requests. We did not noti= ce this *at all* in day to day use, until looking at cpu and bandwidth usag= e and scratching our heads for a while (and rebooting... and waiting 51 day= s... and waiting for the user population and ISPs to report more instances = of this bug)

These=C2=A0are the biggest reliabilit= y reasons why I think FQ is *necessary* across the edges of the internet.

pure AQM, in the case above, since that flood was u= ncontrollable, would have resulted in a 99.99% or so drop rate for all othe= r traffic. While that would have been easier to diagnose I suppose, the nea= r term outcome would have been quite damaging.=C2=A0

Even the proposed policer modes in L4S would not have handled this bug.<= /div>

I always try to make a clear distinction between F= Q and AQM techniques. Both are useful and needed, for different reasons (bu= t 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)

=
--000000000000f5634b05fc70b49e--