Hi Jeremy,
> On Mar 13, 2023, at 18:37, Jeremy Austin <[email protected]> wrote: > > > > On Mon, Mar 13, 2023 at 10:26 AM dan <[email protected]> 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 — and in fact any packet > injection doing more than a bare minimum probe — destructive testing, and > said as much to NTIA recently. [SM] Why? With competent traffic shaping, scheduling and AQM even a capacity test running at full throttle (like e.g a three minute bidirectional flent RRUL test) is not destructive to network responsiveness. I am not saying that the network behaves as if there was no load, but the old, "stop your downloads I have a VoIP call/vide conference coming scenario" really only need to happen at networks with way too little capacity assigned. > 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. [SM] I respectfully disagree, as long as ISP market and price on capacity it is not unreasonable to actually have end-users actually measure capacity. I do agree the way we d this currently is sub-optimal though. And it is a but unfair to ISPs as other business fields are not held to such standards. However, my solution would be to hold other businesses equally to account for their promises, not letting ISPs off the hook ;) (but easy for me to say, I do not operate/work for an ISP and likely misunderstand all the subtleties involved). > 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 — now that we know that speed > tests are not just bad but actively misleading, we need to provide real tools > and education. [SM] +1; however as long as ISP essentially sell capacity, capacity tests will stay relevant. > > 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*?" [SM] Oh, I share this question especially with my cake-autprate junior partner hat on... in theory one could not only use the organic load, but also the organic TCP timestamp increases as shown by pping to estimate times when the load exceeds/meets capacity (I think preseem have an iron in the fire there as well), but that is also not without its challenged. E.g. my router sits behind a bridged modem, but accesses the modem over the same link as the internet and routinely collects data from the modem, will pping now give the delay to the modem as its minimal estimate? If it does it is pretty much useless as that RTT is going to essentially stay flat as it is not affected by the bottleneck queue to/from the internet... (that is why the autorates opted for active probes as that allows to select spatially separate reflectors). 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: [email protected] > > Stay Connected with Newsletters & More: https://preseem.com/stay-connected/ _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
