Re: [Starlink] Starlink "beam spread"

["David P. Reed" <dpreed@deepplum.com>]

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


Hi Dick -
glad you joined in the response, given your experience with spatial multiplexing of RF.
 
On Wednesday, August 31, 2022 3:04pm, starlink-request@lists.bufferbloat.net said:



> Date: Wed, 31 Aug 2022 10:52:15 -0700
> From: "Dick Roy" <dickroy@alum.mit.edu>
> To: "'Mike Puchol'" <mike@starlink.sx>
> Cc: <starlink@lists.bufferbloat.net>
> Subject: Re: [Starlink] Starlink "beam spread"
> Message-ID: <BCE2EFF2444C470C87D9D4C6D4E6E0A9@SRA6>
> Content-Type: text/plain; charset="iso-8859-1"
> On this particular one, the gateway beams are extremely narrow, around 1.5º
> to 2.5º. SpaceX is working on “mega-gateways” where 32 antennas
> will
> co-exist. They are also deploying a new gateway design with a larger
> antenna, and thus narrower beamwidth and more gain, allowing for a
> considerable reduction in TX power.
> 
> [RR] there is a much better way to do this! I sure hope starlink is
> considering it. Large antennas with narrow beam widths are a sledgehammer to
> kill a fly.
> :-)
 I'm pretty sure, from my examination of the dishy array (and the satellite arrays are likely the same) that at the front-end electronics level their use of 64 QAM (six bits of signal quantization in amplitude and phase) isn't gonna allow much signalling in multiple directions at once. That's a sampling theory issue, really.
 
There's a lot of handwaving in the discussion here, mostly focused on "beam width" rather than combined channel capacity. To me that's the "sledgehammer" you are referring to.
 
So that's one aspect. But the other aspect that I'm focused on is not in the arraycom space, it's in the question of how the highly variable (bursty) demand in both directions works out. The low-delay (small packets) at the signalling rate are actually smaller than the number of bits in transit over the 2 msec. path. So the packet level multiplexing here (with more dishy terminals than the 4 240 Mb/sec channels afforded) is also an issue. We aren't talking about one CBR uplink per dishy. It's bitrate is highly variable, given Internet load.
 
Now RRUL from *one dishy* doesn't address this problem properly. You need to look at what happens when all the dishys (uplink and downlink) are wanting to saturate all up and down links. Then you add a new packet that needs low latency (whether it is ACK packet for TCP or a click from a FPS, or an audio frame in a teleconference, latency matters for all of these, and they aren't predictable in advance). How long will it be before an uplink slot is opened? If there is no load, it still requires a clear channel, so it requires waiting till one's turn. Assume that each dishy using the uplink gets one uplink slot in a slot time T. Then the delay till slot available can be short, if the slots are short, all dishys get a turn within 2 msec. or less. But if there is a load in both the up and down direction (and one can easily have such a load from file uploads or file downloads on each dishy, or a fairly big load from UHD video streams to each dishy being "buffered" into a playback buffer on a Smart TV), then latency due to queueing delay can soar.
 
If you don't allow all the dishys to use all the capacity of a satellite, the latency problem gets smaller. But then, of course, you are wasting a bit of capacity to preserve latency for low bitrate traffic.
 
However, high bitrate traffic also has latency requirements. It's not all "background".
 
I'm sure this is something that can be worked out by some algorithm that reaches toward the optimal state by dropping packets to signal TCP (or QUIC) that the transmitter needs to slow down to avoid building up queueing delay. The problem here, though, is that all the focus in this discussion is about "throughput" in a single link, and ignores the burstiness that is driving the multiplexing.
 
My point is that the discussion here has focused entirely on achievable bitrate maximum, with no load and no burstiness.
 
This isn't fixed by having more spatial control, to the extent that is possible. It *is* fixable by suitable Automatic Queue Management in the satellite path (which will be the "bottleneck link" between the home and the public Internet), plus suitable end-to-end protocol congestion management that responds to drops or ECN. (I don't know if the satellite looks at the packet hard enough and has enough state to set the ECN bit or that it has enough state to achieve bloom filter based fair queue dropping).
 
Dave Taht indicates he has some mysterious statistics from (single) dishy experiments. It's a problem that we cannot see into the Starlink black box to understand it fully.
 
But I'm CERTAIN that simplistic analysis about achievable channel bitrates in the abstract will not capture the issues, and that there will be LOTS of systemic problems that are not easily solved by just thinking about rates and beam width.

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