Open jlivingood opened 1 year ago
It would be interesting to surface such details but I'm not sure that would be workable from a web browser, where such low level connection control is not usually available from JavaScript.
If those network changes are effective, I'd expect them to result in improved numbers without any changes to the measurement components. And that would be observable (over time) in the public speed test results (which currently only include tests performed from https://speed.cloudflare.com) available through M-Lab's BigQuery:
https://www.measurementlab.net/blog/cloudflare-aimscoredata-announcement/ https://www.measurementlab.net/data/docs/bq/quickstart/
Hi - Some networks are working to test/deploy the IETF L4S standard for low latency networking, which creates a 2nd network queue at bottleneck links for packets marked with ECT(1) or DSCP-45 to use a low latency queue with a shallow queue depth. This should in theory improve working latency dramatically.
Perhaps it is worth considering in the future adding support for L4S and NQB. Initially it may just be probing to see if the marks work E2E (a la Is My BGP Safe Yet from CF). Then later test the performance effects.
Timing - The Comcast network is planning to trial L4S from mid-June so one way to test it may come up soon (you can also test in a lab of course).
References: RFC 9330, 9331, 9332, draft-ietf-tsvwg-nqb