[Starlink] Re: Starlink looking less niche as its retail presence expands

[Sebastian Moeller <moeller0@gmx.de>]

> On 25. Sep 2025, at 19:45, Michael Richardson via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> {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.

Regarding SCONE:
"The Standard Communication with Network Elements (SCONE) protocol is
negotiated by QUIC endpoints. This protocol provides a means for
network elements to signal the maximum available sustained
throughput, or rate limits, for flows of UDP datagrams that transit
that network element to a QUIC endpoint."

That is going nowhere productive... 
a) restricting this to QUIC is fine only if you believe that QUIC will take over all traffic soon (keep in mind what we expected for IPv6)
b) "signal the maximum available sustained throughput" on a shared network like the internet has a simple true answer "0B"...

IMHO what we will end up doing, after exhaustively attempting and failing with more ambitious schemes like SCONE is tp collect something like the maximum of current capacity use in percent of all nodes along a path and have the endpoints use this to track changes in left over capacity and try to control their rates accordingly. That is better rate-control that is still driven by the endpoints.


> 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?

"long enough" is a relative term... but sure if the latency/"frequency of signalling" is substantially slower than the expected capacity fluctuations then this will not gain much, but if enough of those fluctuations are "slow" compared the RTT of a flow this scheme can have overall beneficial effects.

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

In our dreams.... in reality instead use the kind of marking that has already been shown to work in the real life... if I sound disillusioned about SCONE it is because I am, we knew even before L4S was ratified, that it is "too little, too late" and again instead of doing the proven thing IETF contemplates another academic proposal. I wonder who has the actual problem of a missing advisory signal that SCONE offers to solve.

> 
>>> 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.

That is what feed-back-based rate-control and some modicum of healthy (transient shock-absorber-style) buffering is for, no?

> Packets going up the link, then being dropped, is just wasted.

Sure, if we veridically knew which packts will get dropped, we could avoid sending them in the fist place ;)


> 
> 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    [
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net