[Starlink] [Rpm] so great to see ISPs that care

[Sebastian Moeller]

Dave,

your presentation was awesome, I fully agree with you ;). I very much liked your practical funnel demonstration which was boiled down to the bare minimum (I only partly asked myself, will the liquid spill in in your laptops keyboard, and if so is it water-proof, but you clearly had rehearsed/tried that before).
BTW, I always have to think of this h++ps://www.youtube.com/watch?v=R7yfISlGLNU somehow when you present live from the marina ;)


I am still not through watching all of the presentations and panels, but can already say, team L4S continues to over-promise and under-deliver, but Koen's presentation itself was done well and might (sadly) convince people to buy-in into L4(S) = 2L2L = too little, too late.

Stuart's RPM presentation was great, making a convincing point. (Except for pitching L4S and LLD as "solutions", I will accept them as a step in the right direction, but why not go in all the way and embrace proper scheduling?)

In detail though, I am not fully convinced about the decision of taking the inverse of delay increase as singular measure here as I consider that as a bit of a squandered opportunity at public outreach/education and as comparing idle and working RPM is non-intuitive, while idle and working RTT can immediately subtracted to see the extent of the queueing damage in actionable terms. 

Try the same with RPM values:

123-1234567:~ user$ networkQuality -v
==== SUMMARY ====                                                                                         
Upload capacity: 22.208 Mbps
Download capacity: 88.054 Mbps
Upload flows: 12
Download flows: 12
Responsiveness: High (2622 RPM)
Base RTT: 18
Start: 3/12/23, 21:00:58
End: 3/12/23, 21:01:08
OS Version: Version 12.6.3 (Build 21G419)

here we can divide 60 [sec/minute] * 1000 [ms/sec] by the RPM [1/min] to get: 60000/2622 = 22.88 ms loaded delay and subtract the base RTT of 18 for 60000/2622 - 18 = 4.88 ~5ms of loaded delay which is a useful quantity when managing a delay budget (this test was performed over wired ethernet with competent AQM and traffic shaping on the link, so no surprise about the outcome there). Let's look at the reverse and convert the base RTT into a base RPM score instead: 6000/18 = 333 rpm, what exactly does the delta RPM of 2622-333 = 2289rpm now tell us about the difference between idle and working conditions? [Well, since conversion is not witchcraft, I will be fine as will other interested in actual evoked delay, but we could have gotten a better measure*]

And all for the somewhat unhelpful car analogy... (it is not that for internal combustion engines bigger is necessarily better for RPM, either for torque or fuel efficiency).

I guess that ship has sailed though and RPM it is

*) Stuart notes that milliseconds and Hertz sound to sciency, but they could simply have given the delay increase in milliseconds a fancier name to solve that specific problem... 


> On Mar 12, 2023, at 20:31, Dave Taht via Rpm <rpm at lists.bufferbloat.net> wrote:
> 
> https://www.reddit.com/r/HomeNetworking/comments/11pmc9a/comment/jbypj0z/?context=3
> 
> -- 
> Come Heckle Mar 6-9 at: https://www.understandinglatency.com/
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Rpm mailing list
> Rpm at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm