[Starlink] gorgeous work on LEO beam spreading

[David P. Reed]

Hi Sascha -
On Tuesday, August 30, 2022 6:39pm, starlink-request at lists.bufferbloat.net said:
> Date: Tue, 30 Aug 2022 08:37:24 -0400

> From: Sascha Meinrath <sascha at thexlab.org>
> To: Dave Taht <dave.taht at gmail.com>, Dave Taht via Starlink
> <starlink at lists.bufferbloat.net>
> Subject: 
> 
> I'd be curious how accurate these simulations are -- even within something as
> simple as LAN Wi-Fi, the "simulations" often are wildly/hyperbolically
> over-stated. I could imagine that even a few over-rosy assumptions would
> exponentially metastasize optimism within the satellite context.
 
Very good point. They don't seem to be based on very thoughtful assumptions about the PHY level.
Remember, each satellite has  4 phased array antenna that can each "focus" in one direction. That's a pretty severe limit. Those antennas can either transmit or receive. They can't do both at the same time. Multiple dishys probably will need to share the capacity of those 4 antennas on the uplink from dishy to satellite. They also share the capacity on the downlink (because the beaming tracks individual dishys.
 
How are they "time shared"? Well you have two problems here - one is that you constantly drop dishys and pick up new ones as the satellite moves, so the "time division schedule" of each antenna has to be dynamic, especially as density of active dishys varies (and inactive ones might become active any millisecond or less - new packets being sent).
Now it takes at least 4 milliseconds for the a new uplink slot to be acquired. That's the dishy->sat->dishy round trip at the speed of light. Multiple dishys per satellite antenna means that the uplink, and downlink traffic rates depend on how predictable the traffic is.
 
Internet traffic (unlike classic voice or video which can be seen as a constant bit rate channel with long silence periods) is bursty at all timescales. It's fractally bursty, as studies have shown.
 
Nothing of this sort is even modeled in this work.
 
Now I first started working with 2 way satellite technology back in the Iridium days, and also with 2-way geosynchronous satellites that used RF transponders that just translated the frequency of the uplink to the downlink frequency and vice versa. (Tachyon was the company, I was working on some technology for Nicholas Negroponte's 2B1 project that decided on Tachyon and not Iridium for all kinds of reasons).
 
The big problem in a multiplexed two way system (even at LEO) is that the satellite uplink traffic from one of the many terminals had to share one or a few channels (frequencies) and they can't hear each other. So Internet traffic has to be held until it can get a free time slot, or else the frequencies have to be divided among the terminals dynamically.
 
This is the real issue with Starlink as load increases. And yet most people are pretending this scheduling problem doesn't exist!
 
Even Dave Taht and his buddies who have worked on trying to solve the problem of sharing with 802.11 haven't made much progress in dealing with bursty traffic sharing with heavy load. 
 
And yet people are modeling as if this didn't even matter!  (well, it's not something that has arisen much in the classic one-way or non-multiplexed satellite systems. I don't think even commercial airline satellite systems try to share capacity among multiple planes dynamically.)
 
The phased array tracking of satellites is indeed magical, and the ability to (in principle) switch directions between every 6 bit symbol time is very nice for the downlink from the satellite to multiple dishys.
Great technology.
 
But the multiplexing at the packet level given the burstiness of load and the need to stay under 20 msec. packet latency from dishy to anywhere in the continent is a problem. That's gonna destroy all interactive services as load grows. And that on top of bufferbloat (queueing delay under load caused by not dropping packets) that is apparently a problem in the system. and not being addressed.
 
My response to these kind of studies is "measure based on reality" before you imagine what a good model is.
 
> 
> --Sascha
> 
> On 8/30/22 07:52, Dave Taht via Starlink wrote:
> > mike is doing some great visualizations here:
> >
> > https://twitter.com/mikepuchol/status/1564544963857326081
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/private/starlink/attachments/20220830/3e4ec1b1/attachment.html>