From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Mike Puchol <mike@starlink.sx>, starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Why ISLs are difficult...
Date: Thu, 01 Sep 2022 18:00:32 -0400 [thread overview]
Message-ID: <27620.1662069632@localhost> (raw)
In-Reply-To: <8231ade1-cac9-4a82-bdb0-66ff87217a63@Spark>
[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]
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.
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@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]
next prev parent reply other threads:[~2022-09-01 22:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-01 12:19 Ulrich Speidel
2022-09-01 14:37 ` Dave Taht
2022-09-01 17:24 ` Mike Puchol
2022-09-01 22:00 ` Michael Richardson [this message]
2022-09-01 22:12 ` Dave Taht
2022-09-05 10:54 ` Ulrich Speidel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=27620.1662069632@localhost \
--to=mcr+ietf@sandelman.ca \
--cc=mike@starlink.sx \
--cc=starlink@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox