Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Michael Richardson <mcr@sandelman.ca>
To: Mike Puchol <mike@starlink.sx>
Cc: Nathan Owens <nathan@nathan.io>, Dave Taht <davet@teklibre.net>,
	starlink@lists.bufferbloat.net
Subject: Re: [Starlink] dynamically adjusting cake to starlink
Date: Wed, 09 Jun 2021 17:18:50 -0400	[thread overview]
Message-ID: <12105.1623273530@localhost> (raw)
In-Reply-To: <a956add1-eb1b-4466-80eb-39b15ac35658@Spark>

[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]


Mike Puchol <mike@starlink.sx> wrote:
    > This is correct, with a few twists once you throw in inter-satellite
    > links. In future satellite versions, optical
    > links will allow satellites within the same orbital plane to use each
    > other as relays, thus providing coverage in areas not within a
    > gateway’s coverage.

This would seem to wind up overloading the downlink to the gateway, as well
as causing hard to predict fluctuations in bandwidth.   This is definitely a
complex situation where I can see buffers being added looks like a good
cure-all.

Allowing for direct terminal to terminal traffic would ultimately help
as many of the latency sensitive things like gaming and video calls are often
rather local.

    mcr> (Also, we talk about uplink/downlink from the point of view of the the end
    mcr> user station. But, are there better terms from the satellite's point of
    mcr> view to distinguish traffic to/from the end user?)

    > In general, downlink is anything from satellite to ground, be it
    > satellite -> gateway or satellite -> terminal, and uplink the reverse
    > path. These are the clearest terms to use IMHO. Thus, if satellite to
    > terminal has 75/25 DL/UL duty cycle, the satellite to gateway link will
    > be reversed, with 25/75 DL/UL duty cycle.

Yeah, so in order to speak usefully about some of this stuff, I think we need
to distinguish between traffic going "up" which is going towards the Gateway,
from traffic which might be going "up" from the Gateway (or across from
another satellite).  Some additional terms would help.  I had hoped that
there were some :-)

Do you know how traffic is being steered?  I.e. how does the Gateway say
which terminal traffic is to?  All we know is that tweet "Simpler than IPv6"
Some kind of SDN, but based upon what kind of discriminators?
Are there circuits involved (ala ATM or PPPoE), tags like MPLS or 802.1Q?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

  reply	other threads:[~2021-06-09 21:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-06  3:31 [Starlink] pretty cool starlink visualizer Darrell Budic
2021-06-06  4:26 ` David Lang
2021-06-08 21:54 ` Nathan Owens
2021-06-09  9:12   ` [Starlink] dynamically adjusting cake to starlink Dave Taht
2021-06-09 10:20     ` Mikael Abrahamsson
2021-06-09 16:39       ` Michael Richardson
2021-06-09 18:10         ` David Lang
2021-06-09 12:09     ` Nathan Owens
2021-06-09 12:16     ` Mike Puchol
2021-06-09 13:21       ` Dave Taht
2021-06-09 14:12       ` Michael Richardson
2021-06-09 15:23         ` Mike Puchol
2021-06-09 21:18           ` Michael Richardson [this message]
2021-06-09 21:36             ` Nathan Owens
2021-06-09 23:37               ` Mike Puchol
2021-06-09 15:32       ` Nathan Owens
2021-06-09 15:46         ` David Lang

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=12105.1623273530@localhost \
    --to=mcr@sandelman.ca \
    --cc=davet@teklibre.net \
    --cc=mike@starlink.sx \
    --cc=nathan@nathan.io \
    --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