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 17:32:30 -0400 [thread overview]
Message-ID: <30882.1758835950@obiwan.sandelman.ca> (raw)
In-Reply-To: <175883435104.1555.15600582277556656536@gauss>
{oops, signed message rejected, resending}
As I understand it, the issue is that when a User Terminal changes satellites, it can wind up
going down to a "Landing Ground Station" (GS) different than it had before.
But, due to CGNAT at the GS itself, that packet can not be processed at the
local CGNAT, so it has to travel to the GS that it was allocated for the
CGNAT to work. (Same thing, alas, with IPv6, which does not have that state!)
While we hope that the terrestrial fiber network is never congested, it does
create some annoying dependancies that are likely to show up when you least
want it. Like during natural disasters.
Slide 7 thru 12 of Dr.Pan's presentation shows that terrestial network.
Lots of opportunities for jitter, latency, L2 bufferbloat, ...
MobileIP, had it been deployable, could have allowed the GS to send out
messages to corespondant nodes telling them that they should switch their
traffic to the new GS's Home Agent. IPv6 at least could be less stupid.
Lots of reasons why MobileIP couldn't be done, that Marc alluded to.
Messaging apps that can change their IP will not benefit.
a) the local IP address, 192.168.1.101 hasn't changed.
b) the outside CGNAT address will not have changed, and there is no way
(AFAIK) for the app to tell the CGNAT at the GS that it would prefer to exit there
with a different IP.
Maybe I mis-understand what people are talking about.
Video conference calls often last more than the 15min view of a single
satellite. The situation will be worse initially with OneWeb, as they have
fewer ground stations.
next parent reply other threads:[~2025-09-25 21:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <175883435104.1555.15600582277556656536@gauss>
2025-09-25 21:32 ` Michael Richardson [this message]
[not found] <175876550514.1555.8294777204829819629@gauss>
2025-09-25 17:45 ` Michael Richardson
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
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=30882.1758835950@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