Re: [Starlink] Comprehensive Measurement Study on Starlink Performance Published

[Ulrich Speidel <u.speidel@auckland.ac.nz>]

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

Thanks for that! Another few interesting pieces to the jigsaw puzzle.

I've been a bit reluctant to enter the performance measurement game 
around Starlink myself, chiefly because it's a moving target in more 
than one sense, so essentially you end up producing (nevertheless 
useful) snapshots. There's the rapid growth in satellite numbers and 
hence the associated change in Dishy behaviour and improved performance 
in conditions where Dishy has obstructions to deal with. There's the 
advent of the ISLs. There's also the fact that we don't know which 
underlying changes are made by SpaceX in terms of network configuration.

5G is also a moving target in its own right.

Handovers: I think it's important to consider that while your Dishy 
might not get handed over, others operating via the same satellite might 
move away and yet others again might join the satellite you're on. So 
it's not just the potential of you moving away to a satellite that looks 
different in terms of load, it's also a matter of your satellite's 
capacity changing during someone else getting handed over to it with 
cwnd wide open and being allocated fewer slots than before. But, again, 
as mentioned above, good on SpaceX if they're using some form of AQM to 
try and manage this.

My most serious concern about Starlink as a system remains the fact that 
it puts a pipe between the end user and the first network hop (the 
satellite) that is in principle very difficult to scale: There's only so 
much extra spectrum one can use, spatial diversity (beamforming) has 
limited potential, and unlike in cellular networks, you can't really 
shrink the cell size to accommodate more end users through frequency 
re-use as your cell size is determined to a good part by orbital 
altitude. That all but rules out the scaling effects that CDNs have 
brought to the rest of the Internet, which keep orders of magnitude 
worth of traffic off long distance cables. There simply isn't an obvious 
place in LEO topology to put a cache that'll produce a decent number of 
hits while being able to serve this content to end users through a large 
collective bandwidth.

The interesting question for me is how much we can scale Starlink and 
its up-and-coming cousins from the few million users Starlink has now. 
To 100 million? To 200 million? Half a billion even?

On 27/02/2024 7:12 am, Nitinder Mohan via Starlink wrote:
> Hi folks,
>
> Our comprehensive multifaceted measurement study looking at Starlink 
> global and last-mile performance is now available online: 
> https://arxiv.org/abs/2310.09242 
> <https://arxiv.org/abs/2310.09242>. 
>
>
> TL;DR: See the summary in this nice teaser video we made: 
> https://youtu.be/WtE3MoK8J80 
> <https://youtu.be/WtE3MoK8J80> 
>
>
> We looked at several third-party measurement sources (M-Lab, RIPE 
> Atlas) and performed our own measurements over multiple Starlink 
> dishes to uncover the following:
>
> 1. How different is Starlink network performance globally? How do 
> ground station and PoP availability impact performance?
> 2. How much latency is consumed by the satellite part of the link?
> 3. Is Starlink connection affected by bufferbloat?
> 4. Are satellite handovers the root-cause of Starlink 15-sec 
> reconfigurations?
> 5. How good is Starlink compared to terrestrial cellular networks for 
> real-time applications, specifically Cloud Gaming and Zoom.
>
> The study has been accepted and will appear in ACM The Web Conference 
> 2024 
> <https://www2024.thewebconf.org> (WWW), 
> which is a flagship venue that has historically housed several 
> pioneering works central to Internet success.
>
> Feel free to let me know if you have any questions related to the work.
>
> P.S. We also thanked this mailing list in our paper for providing us 
> several key insights and inquisitive discussions :)
>
> Thanks and Regards
>
> Nitinder Mohan
> Technical University Munich (TUM)
> https://www.nitindermohan.com/ 
> <https://www.nitindermohan.com/>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



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