[Starlink] Why ISLs are difficult...

[Michael Richardson]

Mike Puchol via Starlink <starlink at lists.bufferbloat.net> wrote:
    > In terms of ground station coverage, once the entire ISL “mesh” is
    > complete, you could find a satellite with gateway coverage somewhere,
    > all the time. The path will change every few minutes, as the satellite
    > linking to the gateway changes, but it’s in the order of minutes, not
    > seconds.

And, it's clockwork as you've said, so it's not like our traditional routing
protocols where failures are due to problems or errors.

To my mind, I'd want to have a fourth laser so that one could always be
making before breaking, but if it's fast enough then one can probably buffer
the packets while the lasers move.  That's an evolution to my mind.

That creates spikes in latency though, and it would be wise to keep the
maximum apparent bandwidth to some 95% (or something) of max in order to
always have enough bandwidth to catch up. (By Theory of Constraints)

    >  Turning this into a global network in the shell: Even harder.

    > Agreed! If you equate this to an OSPF network with 4400 nodes, which
    > are reconfiguring themselves every few minutes, the task is not
    > trivial.

OSPF is just not what I'd use :-)
RPL (RFC6550) is probably better, but you'd still need a few tweaks since the
parent selection is going to be predictable.

    > automatically adjust. Any calculation as to what links are established,
    > are active, etc. can be done on the ground and sent to the satellites
    > for execution, much in the same way that RF resource scheduling is done
    > centrally in 15 second blocks.

SDN is great, but a self-healing control plane loop is better (as Rogers learnt on July 7 in Canada).


--
Michael Richardson <mcr+IETF at sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 515 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20220901/c1992c8c/attachment.sig>