Re: [Starlink] Why ISLs are difficult...

[Dave Taht <dave.taht@gmail.com>]

On Thu, Sep 1, 2022 at 3:00 PM Michael Richardson via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
>
> Mike Puchol via Starlink <starlink@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.

One of the big flaws in early wifi extending to today was only 3
useful channels.

https://mathworld.wolfram.com/Four-ColorTheorem.html

I used to fiddle with graph theory a lot, one of my favorites for
describing "optimum"
resilient connectivity was the blanusa snark:

https://en.wikipedia.org/wiki/Blanu%C5%A1a_snarks

Which became the logo of the cerowrt project, and a subset of which,
of the babel routing protocol.

> 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.

Tee-hee. I would use something derived from a DV protocol in general,
and as I said, would use a l2 more amiable to movement, which is
something that ipv6 gloriously failed at. L3 identifiers would stay
fixed, the points underneath change....

The effects of what seems to be a starlink link state protocol (every
15s) are rather noticible at the scale they are currently at, and far
more dynamic convergence is possible with DV. Any centralized approach
fails at distance.

I have not been paying attention, to what extent are any rtt sensitive
metrics being used in production?

https://datatracker.ietf.org/doc/html/draft-ietf-babel-rtt-extension-00

>     > 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@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC