From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 74A7E3B29E for ; Mon, 13 Mar 2023 13:37:56 -0400 (EDT) Received: by mail-yb1-xb2c.google.com with SMTP id e65so4062982ybh.10 for ; Mon, 13 Mar 2023 10:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aterlo.com; s=google; t=1678729076; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UUDPAmr/+8JwX24lxQo9vYn0WuMm2aSRZ6v7IymMWZc=; b=jQbK1K2J5IiJX6i81nL2eo/WLUykTuAl1V+Suy4dWZsuUuQ85+blwXY7Jcnc3DVmpV KpXmbt5m6Jmz2f4mIOB+h+kTdeYnpJliRT/E4zDAqpwzQ04eTi9tqCtaRTzAnrdb2WKN qqjxfSkqj+b9t5wqLMjz5AiALPA5vvcHUmvYM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678729076; 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=UUDPAmr/+8JwX24lxQo9vYn0WuMm2aSRZ6v7IymMWZc=; b=wVve+O2iKuLmiMag2TrMu3a8tWUoDuAMCbVknD0q3UWqqa2kzRuNWRfeCxi/ylS4PP eUgX6DsRQjueDoW7Pjr2LDC1cKv3yIToOeTVC5h4R3pIwCXu7Lp95kUk0CAZ7FFXK3Po Ln++kPvlOXtUz0Mqy1dPTqEr1dV/bYrR8+xSUHVqQ7f5SlYmetMEX/ksD+OXl4+D1+/c 02UEzREkdJ1AZTfQMgpvEsN0yt2c+8oPl8uei8xgyeowNEOxM8Sj/BqZm6LjEJ9Bc2PI WJboWQof5njdNt97L8Rh48g/4z+AwL/Jlfcc4HE33d2Jr0tK+06rimgdcHMG/mKw+swq eaAw== X-Gm-Message-State: AO0yUKU2Fb5HyHM3fxQxacMiiFr/8AHQ4uLcwjRG2Zx0dz4TMiLwjtUJ HTkWcg74+NLwNJsTDiyAu5pBDjrULpzzHu5WvbMZzg== X-Google-Smtp-Source: AK7set9p+SREeUhMLZZozmorAg8/FCeEVPNa1gMKzlrrwPOTO5j8wZagRLTaAWm9d4zP8TCAMcUQfXVnDmF7T7uSVuo= X-Received: by 2002:a25:8a8b:0:b0:af6:9419:60bc with SMTP id h11-20020a258a8b000000b00af6941960bcmr7393899ybl.0.1678729075707; Mon, 13 Mar 2023 10:37:55 -0700 (PDT) MIME-Version: 1.0 References: <1672786712.106922180@apps.rackspace.com> <77CCAD19-07E0-4F9E-88C1-D207CF7BF376@cable.comcast.com> <83ffc0dad19e3343e49271889369cefc@rjmcmahon.com> <3CD0B9E6-0B2A-4A70-8F53-ED0822DF77A6@gmx.de> <13DE6E53-665F-4C20-BBE2-70E685421E9D@gmx.de> In-Reply-To: From: Jeremy Austin Date: Mon, 13 Mar 2023 10:37:44 -0700 Message-ID: To: dan Cc: Sebastian Moeller , Rpm , libreqos , Dave Taht via Starlink , rjmcmahon , bloat Content-Type: multipart/alternative; boundary="0000000000003b64a605f6cb92bd" Subject: Re: [LibreQoS] [Starlink] [Rpm] [EXTERNAL] Re: Researchers Seeking Probe Volunteers in USA X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2023 17:37:56 -0000 --0000000000003b64a605f6cb92bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 13, 2023 at 10:26=E2=80=AFAM dan wrote: If you troubleshoot your ISP based on speed tests you will be chasing your tail. Meanwhile, that internet facing interface can see the true numbers the entire time. The consumer is pulling their full capacity on almost all links routinely even if briefly and can be nudged into pushing more a dozen ways (including a speed test). The only thing lacking is a latency measurement of some sort. Preseem and Libreqos's TCP measurements on the head end are awesome, but that's not available on the subscriber's side but if it were, there's the full testing suite. how much peak data, what happened to latency. If you could get data from the ISP's head end to diff you'd have internet vs isp latencies. 'speed test' is a stress test or a burn in test in effect. I cannot upvote this enough. I call speed tests =E2=80=94 and in fact any p= acket injection doing more than a bare minimum probe =E2=80=94 destructive testin= g, and said as much to NTIA recently. The *big problem* (emphasis mine) is that the recent BEAD NOFO, pumping tens of billions of dollars into broadband, has *speedtests* as the "proof" that an ISP is delivering. It's one thing to solve this problem at the ISP and consumer level. It's another to solve it at the political level. In this case, I think it's incumbent on ISPs to atone for former sins =E2=80=94 now that we know that = speed tests are not just bad but actively misleading, we need to provide real tools and education. Going back to my previous comment, and no disrespect meant to the CAKE autorate detection: "How do we distinguish between constrained supply and reduced demand *without injecting packets or layer violations*?" --=20 -- Jeremy Austin Sr. Product Manager Preseem | Aterlo Networks preseem.com Book a Call: https://app.hubspot.com/meetings/jeremy548 Phone: 1-833-733-7336 x718 Email: jeremy@preseem.com Stay Connected with Newsletters & More: *https://preseem.com/stay-connected/* --0000000000003b64a605f6cb92bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Mar 13, 2023 at 10:26=E2=80= =AFAM dan <dandenson@gmail.com> wrote:

I cannot upvote this enough.= I call speed tests =E2=80=94 and in fact any packet injection doing more t= han a bare minimum probe =E2=80=94 destructive testing, and said as much to= NTIA recently.

The *big problem* (emphasis mine) is tha= t the recent BEAD NOFO, pumping tens of billions of dollars into broadband,= has *speedtests* as the "proof" that an ISP is delivering.
=

It's one thing to solve this problem at the ISP and= consumer level. It's another to solve it at the political level. In th= is case, I think it's incumbent on ISPs to atone for former sins =E2=80= =94 now that we know that speed tests are not just bad but actively mislead= ing, we need to provide real tools and education.

--0000000000003b64a605f6cb92bd--