Re: [Starlink] Starlink "beam spread"

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

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


A couple clarifications below on what I meant.
 
On Wednesday, August 31, 2022 4:28pm, "David Lang" <david@lang.hm> said:



> On Wed, 31 Aug 2022, David P. Reed via Starlink wrote:
> 
> > My point is that the discussion here has focused entirely on achievable
> bitrate maximum, with no load and no burstiness.
> 
> well, to be fair, some of that is in response to 'just looking at the bitrate,
> starlink cannot possibly perform well' posts
Who said that? Well a couple of the people who responded to my initial post about beam spread being the wrong way to look at this seemed to decide they wanted to say that.

> 
> > This isn't fixed by having more spatial control, to the extent that is
> > possible.
> 
> agreed, the spactial control discussion is just a response to 'it can't
> possibly...' posts
Actually, the beam spread (the colorful plots and analysis discussing that that Dave Taht highlighted as being important), is all about "spatial control". That was my original point.
 
> 
> > 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).
> 
> if the sats are going to have the ability to route through other satellites,
> they have to be looking at the packets, and once you start doing that, looking
> at ECN should not be a significant load.
 
I agree, but to do good queue management (especially avoiding starvation of some flows) you need to decide what packets on which to set ECN. That means you have to consider the current set of packets in some detail, which requires storing state about some number of IP flows. That's a lot more processing than just looking at a bit. That's what I am referring to here, and I assumed anyone who knows about ECN and AQM and how it works would understand that.
 
I'm not going to reason from "intersatellite" routing being operational until they offer it in operation. It's feasible, sort of. Laser beam aiming is quite different from phased array beam steering, and though they may have tested it between two satellites, that makes it a "link technology" not a network. (you can steer a laser beam by moving lightweight mirrors, I know. But tracking isn't so easy when both satellites are moving relative to each other - it seems like way beyond the technology base that Starlink has put in its satellites so far. But who knows.
--------------
As far as "intersatellite" routing being out there soon, well, there's no evidence it's happening soon. The one thing that may be an indication is that Starlink is claiming it will have achieved extensive maritime coverage in 2023. Since that can't be achieved by placing ground stations over all the oceans involved so that ships can get one "bounce" to some ground station attached to fiber, I'm guessing they may be providing such service by some additional satellite based"backbone" in space.
 
Given the low density of ships, and the fact that ships currently happily tolerate long space delays in the ways they currently offer Internet service far at sea, using "geosynchronous" two way systems positioned in fixed locations over the oceans, it's possible that the Starlink constellation might be using some "backbone" of another structure to get a one hop to groundstation repeater. These wouldn't be LEO, and they might not even be Starlink owned. That's all guesswork on my part.
 
Starlink is very eager to provide coverage at sea because it is a huge marketing win, and probably doable without too much effort. They announced a partnership with Royal Carribean a couple days ago.
 
Satellite "mesh routing" doesn't need to be made to work to provide maritime service away from land. If there's not too much aggregate load.
 
What's interesting to me is that their coverage map definitely doesn't cover Africa, South America, Cuba, large parts of Asia, and it isn't planned - if they had "mesh routing" working among satellites, those would be easy. But instead, they seem to be focused on the satellite one-bounce architecture (what the satellite industry calls "bent-pipe" however it is done).
 
A reason we don't do dynamic mesh routing in the public internet is that backbone concentration works very well as an engineering solution. I suspect that the Starlink guys are taking the lower risk path.

> 
> David Lang_______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
> 

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