[Bloat] [Starlink] [Rpm] [LibreQoS] [EXTERNAL] Re: Researchers Seeking Probe Volunteers in USA

[dan]

 I’m sticking to my guns on this, but am prepared to let this particular
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’s 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 ‘good put’
and similar numbers.  Basically, provide the end user with decently
accurate data that includes what the speed test app wasn’t 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’t really have a way to ask the shaper directly.

My point in all of this is that if you’re giving the end user information,
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’t
so useful to the 99% of users that just want low ‘lag’ on their games and
no buffering.




On Mar 13, 2023 at 3:00:23 PM, Sebastian Moeller <moeller0 at gmx.de> wrote:

> Hi Jeremy,
>
> On Mar 13, 2023, at 20:52, Jeremy Austin <jeremy at aterlo.com> wrote:
>
>
>
>
> On Mon, Mar 13, 2023 at 12:34 PM dan <dandenson at gmail.com> 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 reach
> that capacity ever, now an ISP is careful in what they promise... Speedtest
> (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 an
> 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 and
> 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 getting
> usabe capacity estimates 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 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 this
> 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 at preseem.com
>
>
> Stay Connected with Newsletters & More:
> https://preseem.com/stay-connected/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20230313/13f9d038/attachment.html>