Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Ulrich Speidel <ulrich@cs.auckland.ac.nz>
To: Michael Richardson <mcr@sandelman.ca>
Cc: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] thinking about the laser links again
Date: Thu, 28 Oct 2021 21:00:43 +1300	[thread overview]
Message-ID: <e9e46140-2a17-31b7-4d6e-c6cb36a61689@cs.auckland.ac.nz> (raw)
In-Reply-To: <8007.1635359366@localhost>

On 28/10/2021 7:29 am, Michael Richardson wrote:

> I guess the real question is: have you written the Hollywood Security 
> Theatre
> script based upon this issues, and can I play the geek that explains 
> this? :-)
Sure!
>
> > - Tell satellites where to send packets (in something along the 
> lines of a
> > long header, as in AX.25 for example). Then a sending ground station 
> would
> > need a complete almanach of the constellation and an idea as to 
> where the
> > receiving ground station is, and which satellite it would use for the
> > downlink. Pros: The sending ground station can do all the number 
> crunching on
> > ground rather than space power. Cons:  Header size costs bandwidth.
>
> From what I understood, Starlink shipped some kind of comodity SDN capable
> chip. So MPLS, or SRv6 ought to be easy, costing only a few bytes
> interpreted in hardware, and a path computation element on the ground 
> should
> be able to deal with the calculation.
>
> It's a challenging situation perhaps because the network effectively gets
> rewired every few minutes, but ground based computation should be able to
> deal with the problem.

That presumes that the ground station has complete topology information 
for the constellation, though. That includes knowing about defective 
satellites and lasers etc., birds deviating from assigned orbit.

But in principle, I can see how that could work, yes.

>
> > - 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.
>
> I think, but I might be wrong, that there is a pattern which repeats 
> over and
> over again. Just need to update the mapping of which satellite is in which
> position in the precomputed mesh. No need to send the entire mesh.

Of course. Bellman-Ford & Co. all assume a network without such 
regularities. But you need to make use of those patterns in order to 
make things possible - whether you do source or hop-to-hop routing. And 
while the configuration of the network is indeed predictable at least 
for the near future, it's not simply repeating over and over again. The 
current constellation (if viewed in isolation) more or less runs in 95 
minute cycles. Earth rotates under the constellation, so the teleports 
only return to the same position with respect to the constellation when 
multiples of the length of a sidereal day coincide with multiples of 95 
minutes. Plus you may find that the Starlink constellation isn't 
perfectly regular either in its pattern.



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

School of Computer Science

Room 303S.594 (City Campus)
Ph: (+64-9)-373-7599 ext. 85282

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




  reply	other threads:[~2021-10-28  8:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-26  1:26 Dave Taht
2021-10-26 13:49 ` Mike Puchol
2021-10-26 17:51   ` Michael Richardson
2021-10-27  6:20     ` Ulrich Speidel
2021-10-27  7:03       ` David Lang
2021-10-27  9:34         ` Ulrich Speidel
2021-10-27 10:49           ` David Lang
2021-10-27 18:37           ` Michael Richardson
2021-10-27 18:29       ` Michael Richardson
2021-10-28  8:00         ` Ulrich Speidel [this message]
2021-10-28 10:52           ` Mike Puchol
2021-10-29  1:12             ` Dave Taht
2021-10-29  1:50               ` David Lang
2021-10-29  2:01                 ` Dave Taht
2021-10-29  3:06                   ` David Lang
2021-10-29  2:38               ` Steve Crocker
2021-10-29  3:08                 ` David Lang
2021-10-29 13:13                   ` Michael Richardson

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=e9e46140-2a17-31b7-4d6e-c6cb36a61689@cs.auckland.ac.nz \
    --to=ulrich@cs.auckland.ac.nz \
    --cc=mcr@sandelman.ca \
    --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