From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 60B823CB51 for ; Mon, 13 Mar 2023 13:37:56 -0400 (EDT) Received: by mail-yb1-xb35.google.com with SMTP id u32so6022077ybi.6 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=FFCt09xIIjOOTmt5kLkFDmotfirE/UZj3X5+jkKoPspC0ouXpp0whQGQCRB1wDuVZY YG9iShm5vYyQXAXwGALMrTNuEWXq6MHhw9Y9eaOgYC9nO38D/gRKZaQMF1iXv3XQxoIm nZK1DhRc768Ehp0uDcsVSBqHpFLTexg3HtAjyMWe8IeMHJwiFZnkyR+a3jDrwyLddGPC F8JsItIPF4pf0hokU+PNxA/k4zBBmhwsmt9eCzyGno6jNK3wIdJZXLty4xAaLQuPmYvO SPImthYqwUthdahQEQmE0XTW4TJtgVmixBUyzzMIRvjfl/m/k83Ye/cgIKPqsrw22cuQ Ny8w== X-Gm-Message-State: AO0yUKWHqnBGsBDIDWWfzzvEcgixKeBKqpuxSec5Y0udkKPR4ElxX5F9 KOmO+GOqPqG5X6vWtTukODq0bU1zwxPf2lnt+zB6yg== 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: [Rpm] [Starlink] [LibreQoS] [EXTERNAL] Re: Researchers Seeking Probe Volunteers in USA X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness 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:


If you troubleshoot your ISP based on speed tests you will be chasing
=
your tail.=C2=A0 Meanwhile, that internet facing interface can see the true=
numbers the entire time.=C2=A0 The consumer is pulling their full capacity<= /div>
on almost all links routinely even if briefly and can be nudged into
<= /div>
pushing more a dozen ways (including a speed test).=C2=A0 The only thing
lacking is a latency measurement of some sort.=C2=A0 Preseem and Libreqos&#= 39;s
TCP measurements on the head end are awesome, but that's not available<= /div>
on the subscriber's side but if it were, there's the full testing
suite.=C2=A0 how much peak data, what happened to latency.=C2=A0 If you cou= ld
get data from the ISP's head end to diff you'd have internet vs isp=
latencies.=C2=A0 =C2=A0 '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 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--