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

[Sauli Kiviranta <smksauli@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6132 bytes --]

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@lists.bufferbloat.net> wrote:

> On May 7, 2024, at 18:48, Dave Taht via Starlink <
> starlink@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 7031 bytes --]