[Starlink] The "reasons" that bufferbloat isn't a problem

Wed Jun 5 15:17:24 EDT 2024

Alex,
Thanks for the reminder about telepresence and conversation (telephone) over a network. Even non-technical users can appreciate this. Has anyone tried to establish a quantitive measure for this as a benchmark? If we have this benchmark, we can relate our other measures (e.g., latency, buffering, etc.) to these “common sense” human measures.

While the measures and technical issues make sense to us (the networking engineers), they are too abstract to win support from non-technical users. We need to show how the technical issues manifest in human observable behavior.

I wish for a way for normal people to relate to issues that drive us.

Gene
----------------------------------------------
Eugene Chang
eugene.chang at ieee.org
o 781-799-0233

> On Jun 5, 2024, at 1:36 AM, Alexandre Petrescu via Starlink <starlink at lists.bufferbloat.net> wrote:
> 
> 
> Le 04/06/2024 à 22:58, Eugene Y Chang via Starlink a écrit :
>> For automobiles, the sensation of speed comes from engine noise and the G-force at the seat-of-your-pants.
>> 
>> I think of it as mostly the second derivative of the motion (aka acceleration).
>> 
>> For snappiness of a network action, it is the time interval from activation to completion. This perception can be enhanced by giving quick feedback (response) while many things are still in motion (still incomplete).
>> 
>> We do need to agree on what makes a network snappy and how that is measured.
> I think a part of qualifying a communications network as 'snappy' is to hold a 1-to-1 long-range audio conversation that acts as much as possible as an in-person conversation to a person nearby.  Landline phones still excel at that and should be the benchmark.
> 
> A 'tele-presence' over satcom linking several persons each speaking in high density bursts might need a 1ms RTT latency.
> 
> Alex
> 
>> 
>> 
>> 
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> eugene.chang at ieee.org <mailto:eugene.chang at ieee.org>
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Jun 4, 2024, at 10:06 AM, Sauli Kiviranta via Starlink <starlink at lists.bufferbloat.net <mailto:starlink at lists.bufferbloat.net>> wrote:
>>> 
>>> Good examples Stuart, it is quite interesting that as humanity we have not come up with aggregate term what would fairly collapse the dimensions to one single metric that would describe the snappy feeling we intuitively seek for but can not quite verbalize. Vehicles have the same issues, we have top speed (F1 at 360mph feels fast compared to Starship at 16000mph), we have acceleration (Hot-rod going 0 to 60 mph in 5 seconds feels high but pales in comparison to Tesla going 0 to 60 mph in 2 sec), we have horse powers (tractor plowing field with 300hp feels great but seems small compared to 1000hp of Hot-rod) then also there is torque (tractor with 1450 Nm of torque wins a Tesla having 900Nm on wheel while at completely different torque curve).
>>> 
>>> Capacity has the same issue as literally the truck from your example shipping magnetic tapes for "raw carry capacity" but it does not feel responsive, snappy, good to handle in the "traffic" of Internet. We have jitter, that could be compared to how a vehicle does in repeatability of track laps? We have packet loss on how the car handles on curves and does it slip off the track or on accelerations spin the wheels? Download is speed forward, upload is almost like speed at reverse gear usually far worse. Latency is like a lap track as such, depends on the track, use-case specific tests "What time did it do on Nürburgring?" or "How fast does it go from 0 to 60Mbps? Less than 200ms?". Horse power feels much like raw capacity of the HW / radio channel and techniques available beam forming, frequencies etc. what was discussed here related to Starlink and even collectively across different technologies. Speed is then instead of how much specific combination of modem and base-station combo can achieve at certain configuration? Torque feels like ability to maintain that performance, closest we get is loaded performance in context of bufferbloat?
>>> 
>>> Watching videos on Netflix require different performance characteristics than downloading a big update to Fortnite. One has certain acceleration need to have snappy user experience but focus is more on connection stability at certain bitrate. On the other hand Fortnite update you want to be delivered at brute force speeds without ruining others user experience.
>>> 
>>> Maybe we can not find that aggregate property or metric, but just need to be rigorous on making sure we accurately characterize each dimension and standardize them so the confusion and play with words, specially with marketing, get stabilized. Each needs to have standardized benchmarks much like 3D rendering benchmarks and PC perf tests are done? All that said, as I failed to come up with a perfect term, "varying performance ISP links" feels like the right thing to say? Now we have obfuscated to be able to throw any of the dimensions underneath. Only thing left for us to do is then to provide those dimensions like a nutrient labels. We are getting there? Nothing new under the sun also to some extend.
>>> 
>>> Just as a funny side note on the tractor marketing:
>>> 
>>> ”Torque gives you the feeling of responsiveness and that the machine does the right things,” Tapani Katila encapsulates his view. “The torque is directly linked to the feeling of having power available in the entire range of the power curve, resulting in more meaningful work.” from https://www.agcopower.com/power-is-important-but-torque-is-crucial/ <https://www.agcopower.com/power-is-important-but-torque-is-crucial/>
>>> 
>>> Seems like some other people are also trying to figure out what dimensions to showcase to customers?
>>> 
>>> Thank you for the thought provoking examples!
>>> 
>>> Is bufferbloat property of a vehicle or characteristic of the road design? Is it a question of ICE vs EV -or- roundabout vs crossing with traffic lights? Feels more like a roundabout, no? Is this the problem behind the objections?
>>> 
>>> - Sauli
>>> 
>>> On Tue, Jun 4, 2024 at 9:19 PM Stuart Cheshire via Starlink <starlink at lists.bufferbloat.net <mailto:starlink at lists.bufferbloat.net>> wrote:
>>> On May 7, 2024, at 18:48, Dave Taht via Starlink <starlink at lists.bufferbloat.net <mailto:starlink at lists.bufferbloat.net>> wrote:
>>> 
>>> > This was a wonderful post, rich!
>>> 
>>> <https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/ <https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/>>
>>> 
>>> I agree. Thanks for writing this Rich.
>>> 
>>> One minor change I will request. Any time you write words like “speed” or “fast”, pause and consider whether it would be more accurate to use some other term like “capacity”, “bandwidth”, or “throughput”. Part of what keeps us in this mess is that people equate network capacity with “speed”, as if those terms were synonyms. We can’t change how people think overnight, but at least we can avoid further reinforcing that wrong thinking.
>>> 
>>> If someone has 200 Mb/s Internet service and it feels slow, then they might upgrade to 400 Mb/s Internet service and expect everything to be uniformly twice as fast. We here know that doubling the network capacity may make large downloads faster, but everything else is most likely unchanged, and can be even worse.
>>> 
>>> People never make this mistake in other contexts. If someone commutes to work in their 20-foot RV feels that it’s too slow, then upgrading to a 40-foot RV will not get them to work faster. A 40-foot RV is *bigger* than a 20-foot RV, but it’s probably not *faster*. If you are moving a vast amount of cargo that requires multiple trips, then a larger truck will let you complete that task in fewer trips. But for most daily driving, a bigger truck will not get to your destination any quicker.
>>> 
>>> Some simple edits:
>>> 
>>> Instead of “varying speed ISP links” how about “varying capacity ISP links”?
>>> 
>>> Instead of “they profit if you decide your network is too slow and you upgrade to a faster device/plan” how about “they profit if you decide your network is too slow and you upgrade to a higher throughput device/plan”?
>>> 
>>> Stuart Cheshire
>>> 
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink at lists.bufferbloat.net <mailto:Starlink at lists.bufferbloat.net>
>>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink at lists.bufferbloat.net <mailto:Starlink at lists.bufferbloat.net>
>>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>> 
>> 
>> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net <mailto:Starlink at lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net <mailto:Starlink at lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240605/b182bcd0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240605/b182bcd0/attachment-0001.sig>