Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Michael Richardson <mcr@sandelman.ca>
To: starlink@lists.bufferbloat.net
Subject: [Starlink] Re: Starlink looking less niche as its retail presence expands
Date: Thu, 25 Sep 2025 13:45:10 -0400	[thread overview]
Message-ID: <30473.1758822310@obiwan.sandelman.ca> (raw)
In-Reply-To: <175876550514.1555.8294777204829819629@gauss>

{resending without signature, since new list can't cope with attachments yet}

Luis A. Cornejo via Starlink <starlink@lists.bufferbloat.net> wrote:
    > Since Starlink controls all the wireless parts of their system. Does
    > anybody here know what they could do to mitigate the limits of
    > classical wireless comms, like Shannon-Hartley Capacity Theorem or the
    > interference?

I don't know much about this part.
I am kinda hijacking this thread, but I think there is a connection.
Dr.Pan gave a talk about Starlink measurements last week in Ottawa.
(The time slot was way too short.  Very nice talk)

I was thinking about the many places where bandwidth can go up and down, both
for Starlink's various mis-attachment situations, but also for OneWeb's Polar
orbit mechanism.  (I didn't know it was doing that).
And just getting redirected to a different downlink/base-station, and then
have to cross over Starlink's internal network to the same exit point.
(Too bad MobileIP never took off)

I think the only thing worse than bufferbloat is varying bandwidth rates.
That's because the only way to use that bandwidth is to introduce bufferbloat :-)
It was the cablemodem burst mechanism that clued Jim into bufferbloat.

So my related question is, if they could mitigate, they likely can't do it
continuously, so things will up/down.  The IETF now has a SCONE WG, with the
aim of inserting signals into QUIC traffic about bandwidth available.
Yes, meddling by middle boxes.  Ick.

Could Starlink even do this given the lack of L3 processing along the
entire link?  At least according to Dr. Pan's diagrams.
(An L2 hop could well mess with packets too).
Ideally, one or more of the satellites involved in the ISL would
know what the current bandwidth to a given terminal is, and could inform the
end system.

The two questions:
1. are the limits/conditions stable enough for long enough that the available
   bandwidth could be communicated back to the uplink?

2. assuming, yes, what would the best place to do the SCONE marking?

    >> Let's recap: Spectrum's boxed in, and power is boxed in. That imposes
    >> a hard limit on total capacity (look up the Shannon-Hartley Capacity
    >> Theorem if you don't believe me). This capacity is all that Starlink
    >> has to share among its users in a cell. No matter how many satellites
    >> they launch or how big the rocket. Add more users in a cell, and the
    >> capacity per user there has to go down. Law of nature.

And users will need to know what they have on a minute-by-minute basis so
that they avoid screwing themselves, let alone their neighbours.
Packets going up the link, then being dropped, is just wasted.

ps:
I have been watching: https://www.youtube.com/playlist?list=PL-_93BVApb58SXL-BCv4rVHL-8GuC2WGb
where they have powered up 50+ year old Apollo Transponders.

--
]               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    [

       reply	other threads:[~2025-09-25 17:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <175876550514.1555.8294777204829819629@gauss>
2025-09-25 17:45 ` Michael Richardson [this message]
2025-09-25 18:21   ` J Pan
2025-09-25 18:31   ` Marc Blanchet
2025-09-25 18:41     ` Spencer Sevilla
2025-09-25 18:53       ` David Lang
2025-09-25 18:55         ` Spencer Sevilla
2025-09-25 20:08   ` Ulrich Speidel
2025-09-26 13:11   ` Sebastian Moeller
     [not found] <175883435104.1555.15600582277556656536@gauss>
2025-09-25 21:32 ` Michael Richardson
2025-09-17 16:54 [Starlink] " the keyboard of geoff goodfellow
2025-09-17 18:20 ` [Starlink] " Inemesit Affia
2025-09-17 18:47   ` Frantisek Borsik
2025-09-17 19:04     ` Inemesit Affia
2025-09-17 23:02       ` Ulrich Speidel
2025-09-24 23:39         ` Luis A. Cornejo
2025-09-25 13:24         ` Inemesit Affia

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=30473.1758822310@obiwan.sandelman.ca \
    --to=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