Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Ulrich Speidel <u.speidel@auckland.ac.nz>
To: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Subject: [Starlink] Why ISLs are difficult...
Date: Fri, 2 Sep 2022 00:19:14 +1200	[thread overview]
Message-ID: <cf9ab778-d2a2-bb94-d87f-c49180643ff9@auckland.ac.nz> (raw)

As this seems to have branched out... There are a whole bag of issues 
with ISL's and routing, really, and again we know diddly squat about 
what Starlink actually intend to do.

My 5 cents worth:

- Linking two satellites that follow each other on the same orbit is the 
easiest exercise. I gather that Starlink have ticked that one off. It's 
probably not too useful on its own for most real scenarios though: 
ground stations move through orbital planes. Also, two arbitrary ground 
stations between one would want to forward will probably not be 
connectable by a chain of satellites all in the same orbital plane.
- Linking two satellites that are in different but adjacent orbital 
planes is one notch up but probably not a lot harder if you master 
gimbal / mirror control. You have some relative movement, but most of 
the time it's slow. Low hanging fruit if it's not already been picked.
- Linking two satellites in range of each other that satisfy some 
arbitrary criterion (minimum distance, desired direction): A bit harder.
- Turning this into a global network in the shell: Even harder.

Let me elaborate a bit on this.

Let's assume we have one or more gimbals that allow us to point our 
space laser(s) at other satellites in range. Or a mirror arrangement - 
doesn't matter.

One unknown that we have is what the receiver side of these links will 
look like. As we'll see in a moment, this is actually quite important.

There are in principle two options for the receiver:

1) A receiver with a wide angle lens that can receive laser signals from 
multiple other satellites at once. This is a pretty simple arrangement 
and may not even need moving parts.

2) A receiver that gets pointed back at the transmitting satellite, 
perhaps with a telescopic zoom lens. This adds a little weight and could 
be on the same gimbal as a laser, so we could communicate both ways 
between the satellites. Moreover, the zoom lens would be like antenna 
gain in a link budget, so would allow a higher data rate between the 
satellites and / or less power.

Now 2) seem clearly superior, right, if we can handle a few extra grams? 
Then we could give each satellite n TX/RX gimbals and could, say, get 
each of our satellites to connect to its n nearest neighbours. And 
bingo, we'd have a network that spans the globe, right?

Not so simple. Two problems, and they're serious ones as it turns out:

A) What happens if one of our n nearest neighbours doesn't have us among 
its n nearest neighbours? Then they won't point their gimbal back at us. 
How do we resolve this?
B) If n=3 and I have Dave, Mike, and Brandon as my nearest neigbours, 
Dave's 3 nearest neighbours are Mike, Brandon and me, Mike's nearest 
neighbours are Dave, Brandon and me, and Brandon has Dave, Mike and me 
as his nearest neighbours, then David, Dick and Sebastian who may be 
orbiting a bit further away from us don't get to link to our elitist 
cluster and our dream of a global network turns to dust.

Now, Problem B (which also occurs for outward links from clusters with 
receiver type 1) can be mitigated by requiring a minimum distance to a 
neighbour, but in combination with a), we seem to have a nasty little 
overlay graph problem to solve. Oh, and we'd want to do that in a 
distributed fashion if possible, and every few seconds from scratch, please.

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************




             reply	other threads:[~2022-09-01 12:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-01 12:19 Ulrich Speidel [this message]
2022-09-01 14:37 ` Dave Taht
2022-09-01 17:24 ` Mike Puchol
2022-09-01 22:00   ` Michael Richardson
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=cf9ab778-d2a2-bb94-d87f-c49180643ff9@auckland.ac.nz \
    --to=u.speidel@auckland.ac.nz \
    --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