From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) (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 C45A03B29E; Mon, 13 Mar 2023 17:27:05 -0400 (EDT) Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-5416949b35aso141257927b3.13; Mon, 13 Mar 2023 14:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678742825; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vP19EPi+qsk6uHpl3eS4JJSM8XTTBCh/JZrUaYZ0aBg=; b=CEJ5XwYxvprFxnKxqB3EDjwRojYBe+gIjs+LDp/l3FkTxcazcJqyZ/kDTNLthAvx3M zHlR1XQDEKKJkiYFGXOCk9FG7zsYRbtZtaphsqqxqHCiq1nd6+EmVgVl2Hx/lcqmwN1g OACm6/BTZgGyGPMu/N6DVEXahCVUXNIQaNdES6DCGvcF6Fh+5WvFDGkur6TczS3OFdym mapjBruW0k1DobIiXpRuG2lwA0s3+DfAjwJbvaZ4wzeBiKEKevnaxHGf38wG0eEaMHz6 ANrK09p9OTQCYEU4hXpQ/8dVqeKu0vBzEdFFBmSiLor2KpV60b73+vEC949eP0ywXZym Mv4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678742825; 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=vP19EPi+qsk6uHpl3eS4JJSM8XTTBCh/JZrUaYZ0aBg=; b=pyqDJnp6DSFbVX9PcdlI9B+hUHArao0dNp+5zVNqDNMH8shYFMo7GsmB1prYW345I4 8oXZWZ4LvOxe0832n00PM6HUYtGNuchrQiBuux9rUNAjpyH/t8+9V9nk7vfoVSMkxApI x6Y4ZPSpe053DPzgg9pGeLEV/6hNGCbCx8w4CgU+vF17LOQ5igPj5I+SjMpXYs8YXj6V vNZOoW1oYF4MX9cCr46bQbea0UuNuvoMjDE6c0PPq9UOpwu4Qi0E95VsXjgEejz6LNqO fREbdln9M72IdokXhg2UoI0af1si3dgb4E6UKY+eTbRLmr8ttYYSbCVFeJQ01W/4V0vP /cUg== X-Gm-Message-State: AO0yUKWjGjtrqf7P/ahC8QxeIUucWvhaGDNxdbI2KV+X27z22QBqdBuL aJamQCEb/7ZB1aqPpqgDWahAuLvJU7Gle5jZroPbzlux X-Google-Smtp-Source: AK7set/tIyQRQUhBLEq9RckJhMeNoEjV7tIOOBxnAwTtu0560kIHo5iW0StDPspxtjKMoswctxwl8K8Io0NqCyZHq4w= X-Received: by 2002:a81:a784:0:b0:541:6dce:50d6 with SMTP id e126-20020a81a784000000b005416dce50d6mr5814097ywh.1.1678742824935; Mon, 13 Mar 2023 14:27:04 -0700 (PDT) Received: from 1064022179695 named unknown by gmailapi.google.com with HTTPREST; Mon, 13 Mar 2023 17:27:04 -0400 Received: from 1064022179695 named unknown by gmailapi.google.com with HTTPREST; Mon, 13 Mar 2023 17:27:00 -0400 Mime-Version: 1.0 (Mimestream 0.41.5) 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> <22C819FA-DDD7-4B9B-8C09-8008D4273287@gmx.de> In-Reply-To: From: dan Date: Mon, 13 Mar 2023 17:27:04 -0400 Message-ID: To: Sebastian Moeller Cc: Rpm , libreqos , Dave Taht via Starlink , rjmcmahon , bloat , Jeremy Austin Content-Type: multipart/alternative; boundary="000000000000bfe55b05f6cec598" 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 21:27:05 -0000 --000000000000bfe55b05f6cec598 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m sticking to my guns on this, but am prepared to let this parti= cular argument rest. The threads is approaching unreadable. Let me throw something else out there. It would be very nice to have some standard packet type that was designed to be mangled by a traffic shaper. So you could initiate a speed test specifically to stress-test the link and then exchange a packet that the shaper would update both ways with all the stats you might want. Ie, speed test is getting 80Mbps but there=E2=80=99s= an additional 20Mbps on-link so it should report to the user that 100M aggregate with the details broken out usably. Could also report to that speed test client and server things like latency over the last x minutes along with throughput so again, could be charted out to show the =E2=80=98g= ood put=E2=80=99 and similar numbers. Basically, provide the end user with decently accurate data that includes what the speed test app wasn=E2=80=99t able to = see itself. It could also insert useful data around how many packets arrived that the speed test app(s) could use to determine if there are issues on wan or lan. I say mangle here because many traffic shapers are transparent so the speed test app itself doesn=E2=80=99t really have a way to ask the shaper directl= y. My point in all of this is that if you=E2=80=99re giving the end user infor= mation, it should be right. No information is better than false information. End users will call their ISP or worse get on social media and trash them because they bought a $29 netgear at Walmart that is terrible. After all the entire point if all of this is end-user experience. The only benefit to ISPs is that happy users are good for business. A lot of the data that can be collected at various points along the path are better for ISPs to use to update their networks to improve user experience, but aren= =E2=80=99t so useful to the 99% of users that just want low =E2=80=98lag=E2=80=99 on t= heir games and no buffering. On Mar 13, 2023 at 3:00:23 PM, Sebastian Moeller wrote: > Hi Jeremy, > > On Mar 13, 2023, at 20:52, Jeremy Austin wrote: > > > > > On Mon, Mar 13, 2023 at 12:34=E2=80=AFPM dan wrote: > > > See, you're coming around. Cake is autorating (or very close, 'on > > device') at the wan port. not the speed test device or software. And > > the accurate data is collected by cake, not the speed test tool. That > > tool is reporting false information because it must, it doesn't know > > the other consumers on the network. It's 'truest' when the network is > > quiet but the more talkers the more the tool lies. > > > cake, the kernel, and the wan port all have real info, the speed test > > tool does not. > > > I'm running a bit behind on commenting on the thread (apologies, more > later) but I point you back at my statement about NTIA (and, to a certain > extent, the FCC): > > > Consumers use speed tests to qualify their connection. > > > [SM] And rightly so... this put a nice stop to the perverse practice of > selling contracts stating (up to) 100 Mbps for links that never could rea= ch > that capacity ever, now an ISP is careful in what they promise... Speedte= st > (especially using the official speedtest app that tries to make users pay > attention to a number of important points, e.g. not over WiFi, but over a= n > ethernet port that has a capacity above the contracted speed) seem to be > good enough for that purpose. Really over here that is the law and ISP > still are doing fine and we are taking low single digit thousands of > complaints in a market with ~40 million households. > > > Whether AQM is applied or not, a speed test does not reflect in all > circumstances the capacity of the pipe. One might argue that it seldom > reflects it. > > > [SM] But one would be wrong, at least the official speedtests over here > are pretty reliable, but they seem to be competenyly managed. E.g. users > need to put in the contracted speed (drop down boxes to the select ISP an= d > contract name) and the test infrastructure will only start the test if it > managed to reserver sufficient capacity of the test servers to reliably > saturate the contracted rate. This is a bit of engineering and not > witchcraft, really. ;) > > Unfortunately, those who have "real info", to use Dan's term, are > currently nearly powerless to use it. I am, if possible, on both the ISP > and consumer side here. > > > [SM] If you are talking about speedtests being systemicly wrong in gettin= g > usabe capacity estimates I disagree, if your point is that a sole focus o= n > this measure is missing the way more important point od keeping latency > under load limited, I fully agree. That point currently is lost on the > national regulator over here as well. > > And yes, Preseem does have an iron in this fire, or at least a dog in thi= s > fight. > > > [SM] Go team! > > Ironically, the FCC testing for CAF/RDOF actually *does* take interface > load into account, only tests during peak busy hours, and /then/ does a > speed test. But NTIA largely ignores that for BEAD. > > > [SM] I admit that I have not looked deeply into these different test > methods, and will shut up about this topic until I did to avoid wasting > your time. > > Regards > Sebastian > > > > -- > > -- > > 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/ > > > --000000000000bfe55b05f6cec598 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80=99m sticking to my guns on this, but am prepared to let this pa= rticular argument rest.=C2=A0 The threads is approaching unreadable.
<= div dir=3D"ltr">
Let me throw something else out = there.=C2=A0 It would be very nice to have some standard packet type that w= as designed to be mangled by a traffic shaper.=C2=A0 So you could initiate = a speed test specifically to stress-test the link and then exchange a packe= t that the shaper would update both ways with all the stats you might want.= =C2=A0 Ie, speed test is getting 80Mbps but there=E2=80=99s an additional 2= 0Mbps on-link so it should report to the user that 100M aggregate with the = details broken out usably.=C2=A0 Could also report to that speed test clien= t and server things like latency over the last x minutes along with through= put so again, could be charted out to show the =E2=80=98good put=E2=80=99 a= nd similar numbers.=C2=A0 Basically, provide the end user with decently acc= urate data that includes what the speed test app wasn=E2=80=99t able to see= itself.=C2=A0 It could also insert useful data around how many packets arr= ived that the speed test app(s) could use to determine if there are issues = on wan or lan. =C2=A0

I sa= y mangle here because many traffic shapers are transparent so the speed tes= t app itself doesn=E2=80=99t really have a way to ask the shaper directly.= =C2=A0

My point in all of = this is that if you=E2=80=99re giving the end user information, it should b= e right.=C2=A0 No information is better than false information.=C2=A0 End u= sers will call their ISP or worse get on social media and trash them becaus= e they bought a $29 netgear at Walmart that is terrible.

After all the entire point if all of this is= end-user experience.=C2=A0 The only benefit to ISPs is that happy users ar= e good for business.=C2=A0 A lot of the data that can be collected at vario= us points along the path are better for ISPs to use to update their network= s to improve user experience, but aren=E2=80=99t so useful to the 99% of us= ers that just want low =E2=80=98lag=E2=80=99 on their games and no bufferin= g.




On Mar 13, 2023 at 3:00:23 PM, Se= bastian Moeller <moeller0@gmx.de&= gt; wrote:
=20
Hi Jeremy,

On Mar 13, 2023, at 20:52,= Jeremy Austin <jeremy@aterlo.com> wrote:

<= blockquote type=3D"cite">

<= /blockquote>
On Mon, Mar 13, 2023 at 12:34=E2=80= =AFPM dan <dandenson@gmail.com> wrote:

See, you're coming around.=C2=A0 Cake is autor= ating (or very close, 'on
de= vice') at the wan port. =C2=A0not the speed test device or software.=C2= =A0 And
the accurate data is col= lected by cake, not the speed test tool.=C2=A0 That
tool is reporting false information because it must, it= doesn't know
the other cons= umers on the network.=C2=A0 It's 'truest' when the network is
quiet but the more talkers the mo= re the tool lies.

cake, the kernel, and the wan port all have r= eal info, the speed test
tool do= es not.

I'm running a bit behind on commenting on the threa= d (apologies, more later) but I point you back at my statement about NTIA (= and, to a certain extent, the FCC):

Consumers use speed tests = to qualify their connection.

[SM] And rightly so... th= is put a nice stop to the perverse practice of selling contracts stating (u= p to) 100 Mbps for links that never could reach that capacity ever, now an = ISP is careful in what they promise... Speedtest (especially using the offi= cial speedtest app that tries to make users pay attention to a number of im= portant points, e.g. not over WiFi, but over an ethernet port that has a ca= pacity above the contracted speed) seem to be good enough for that purpose.= Really over here that is the law and ISP still are doing fine and we are t= aking low single digit thousands of complaints in a market with ~40 million= households.


Whether AQM is applied or not, a speed test does not reflec= t in all circumstances the capacity of the pipe. One might argue that it se= ldom reflects it.

[SM] But one would be wrong, at leas= t the official speedtests over here are pretty reliable, but they seem to b= e competenyly managed. E.g. users need to put in the contracted speed (drop= down boxes to the select ISP and contract name) and the test infrastructur= e will only start the test if it managed to reserver sufficient capacity of= the test servers to reliably saturate the contracted rate. This is a bit o= f engineering and not witchcraft, really. ;)

Unfortunately, those who have "real info", to use Dan's t= erm, are currently nearly powerless to use it. I am, if possible, on both t= he ISP and consumer side here.

[SM] If you are talking= about speedtests being systemicly wrong in getting usabe capacity estimate= s I disagree, if your point is that a sole focus on this measure is missing= the way more important point od keeping latency under load limited, I full= y agree. That point currently is lost on the national regulator over here a= s well.

And yes, Preseem does have an iro= n in this fire, or at least a dog in this fight.

[SM] = Go team!

Ironically, the FCC testing for = CAF/RDOF actually *does* take interface load into account, only tests durin= g peak busy hours, and /then/ does a speed test. But NTIA largely ignores t= hat for BEAD.

[SM] I admit that I have not looked deep= ly into these different test methods, and will shut up about this topic unt= il I did to avoid wasting your time.

Regards
Sebastian


--=
--
Jeremy Austin
Sr= . Product Manager
Preseem | Ater= lo Networks
preseem.com

<= /blockquote>
Book a Call: https://app.hubspot.com/meetings/jeremy548<= /a>
Phone: 1-833-733-7336 x718
Email: jeremy@preseem.com

Stay Connected with Newslett= ers & More: https://pre= seem.com/stay-connected/

--000000000000bfe55b05f6cec598--