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

Alexandre Petrescu alexandre.petrescu at gmail.com
Wed Jun 5 07:36:14 EDT 2024


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
>
>
>
>
>
>
>> On Jun 4, 2024, at 10:06 AM, Sauli Kiviranta via Starlink 
>> <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/
>>
>> 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> wrote:
>>
>>     On May 7, 2024, at 18:48, Dave Taht via Starlink
>>     <starlink at lists.bufferbloat.net> wrote:
>>
>>     > This was a wonderful post, rich!
>>
>>     <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
>>     https://lists.bufferbloat.net/listinfo/starlink
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>
>
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240605/d9febfda/attachment-0001.html>


More information about the Starlink mailing list