Re: [Starlink] thinking about the laser links again

[David Lang <david@lang.hm>]

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

On Wed, 27 Oct 2021, Ulrich Speidel wrote:

> - Get the satellites to work out where stuff needs to be sent. If they were 
> to use something like Bellman-Ford here, that would require an enormous 
> amount of update traffic. Dijkstra would require complete topology 
> information, which should in principle be computable from an almanach on the 
> satellites. But it's still a lot of number crunching on a bird. Another 
> option would be for each satellite to compute a great circle direction to the 
> target cell and then forward to whichever neighbour satellite comes closest 
> to being along that route.

Remember, IP routing doesn't require anybody have a global view of the network, 
just knowlege of nearby nodes.

So the satellite needs to know what are good next hops to send traffic to that's 
headed in different directions, not global knowledge of the entire 
constellation.

This doesn't require that all satellites be able to send in all directions. with 
lots of satellites in range, they could cycle between the first sending north, 
the second east, the third south, the fourth west...

A key question to me is how many lasers, how fast they can be redirected to 
different satellites, and how many different satellites the detectors can 
receive from at one time.

I'd hope that there are at least two lasers, so that they can transmit to the 
next hop and ack to the receiver without having to spin a laser 180.

It also doesn't require that the satellite send to the nearst node in that 
direction (if longer distance traffic can be detected, you would want to send to 
a further away next hop to reduce the number of hops)

They could even have a satellite varient that has more lasers/detectors and 
fewer RF antennas to connect to the ground to be dedicated to routing 
(especially as they launch satellites to different altitudes, nodes at higher 
altitudes could be optimized for long-distance hops)

With only 'nearby' node knowledge needed, I could see low-power omnidirectional 
RF beacons being used for nodes to advertise their existance and routing config 
to the network. I expect that if they were doing this, that it would show up in 
their FCC filings and everyone would be talking about it, but it's a thought for 
future versions.

All of this requies some way to tell from the packet where on earth (or in 
space) the destination is. If you tunnel over IPv6, you can have enough IPs to 
allocate them based on lat/long/ground/orbit so that the routing nodes (which 
know where they are) can know what direction to send things. Given the existance 
of mobile endpoints (vehicles, aircraft, spacecraft) this starts sounding like 
the mobile IP problem (how can you continue a persistant connection when moving 
from netowrk to network), but since all the entry/exit points are under their 
control, you can tunnel around and have a protocol to reconfigure the tunnels as 
endpoints move.

David Lang

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink