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

[Ulrich Speidel <u.speidel@auckland.ac.nz>]

On 26/09/2025 5:45 am, Michael Richardson via Starlink wrote:
> 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.
I'd expect almost any modern communication system these days to operate 
with a more complex protocol stack than just the good old textbook OSI 
... so your "L2" may actually be sitting on top of a layer running UDP 
over IP, for example. In that sense, L2 and L3 as labels mean very 
little these days, and issues at one layer can actually come about as a 
result of this complexity, having been introduced further down the stack.
>
> The two questions:
> 1. are the limits/conditions stable enough for long enough that the available
>     bandwidth could be communicated back to the uplink?

Um yes, but I wouldn't work on the assumption of shared bandwidth (in 
the sense of "sharing the same Ethernet cable" here). The 
uplink/downlink bandwidth an end user on Starlink gets is almost 
certainly determined by the assignment of a time slot or slots on a 
certain frequency (beam) subband(s). You could add other parameters to 
this (e.g., spreading code, polarisation, ...). This is an assignment 
made by Starlink's scheduler, and the only thing that's certain here is 
that for a given satellite, the maximum total number of frequency 
subbands and time slots is fixed. These have to be shared between all 
users of the satellite. Quite how many slots someone gets therefore 
depends on the number of other users and whatever they get, plus 
whatever Starlink might want / need to reserve for regulatory and other 
reasons.

Of course, every 15 seconds, things change: Existing users get handed 
over to new satellites, new users join the present one, and slots get 
redistributed. Switching to user perspective, getting handed over to a 
new satellite at the 15 second point means potentially getting a 
completely different share of bandwidth. Even staying with the same 
satellite does. Whatever the cwnd value of participating TCP sockets is 
at that point, it's not adapted to what you're dealing with here.

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

Now there's also the data that's in transit from the Internet to the 
user. That'll have to hit a queue somewhere, from where it then gets 
uplinked to the satellite that serves the user it's destined for. Given 
that TCP senders out there have the RFC-given right to transmit data 
whenever they think fit, the Internet has zero control over when a TCP 
segment hits that queue, however. Now imagine that it hits that queue 
just before the user in question gets handed over to a different 
satellite ... and it doesn't make it out of the queue before the user 
gets passed on. Then where does that data go? I think it was Geoff 
Huston who told me that he'd observed packet loss at the handover times 
and that's probably what he was looking at here.

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

School of Computer Science

Room 303S.594 (City Campus)

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