[Starlink] Re: SCONE, bandwidth indeterminacy and network to host signals (was Re: Re: Starlink Digest, Vol 53, Issue 14)

[Sebastian Moeller <moeller0@gmx.de>]

Hi Michael,


> On 29. Sep 2025, at 00:57, Michael Richardson via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> The point of SCONE is allow end ("terminals") to better select (video)
> bandwidths that are going to be more sustainable.  It's definitely driven by
> 3GPP (LTE) operators so far.   

Mmmh, so the idea is to make QUIC all encrypted so no network entity can play nasty games, but now the makers of QUIC accommodate exactly such a party with a rationale not really aligned with that of the end users... Color me not surprised...



> I give it a 40% chance of getting usefully
> deployed before the need is overtaken by other events.

Let's see.

> The promise is that 3GPP operators won't have to do expensive DPI anymore.

If you believe that, I have a bridge to sell...

> 
> It's true the the 3GPP people have a long-standing habit of doing often
> useless DPI, including ack pacing, ack-proxying, https://en.wikipedia.org/wiki/TCP_pacing
> 
> While I'm definitely in the smart-end-point, dumb-network camp,

Glad we agree.

> I also see that the lack of useful end-host<->network relationship/API has
> resulted in our inability to offer new kinds of services.

Not sure we need "new kinds of services"...

> (Ironically: "5G" operators need this more than anyone else.  The ill-fated
> IETF APN BOF/WG was after that.  Kinda. But not everyone knew that)

Intrigued, will need to follow that bread crumb in due time, thanks or the pointer.

> 
> I've often wanted a "less than best effort" service (as much as that's a
> terrible term), which would allow me to purchase unused bandwidth at low-peak
> times in order to do bulk data movement.  I'd often be happy to do this in a
> store-and-forward fashion.    (Yes, I used to live on UUCP!)

SCONE is not going to give you that though... for that you need reasonably timely information about the actual capacity usage, not some policy decision how much capacity someone along the path is willing to assign to your X-tuple, no?

> 
> That's what we should be creating for space use; my understanding is that
> Bundle Protocol tries to be that, but that many think it is un-deploybale.
> (I haven't an opinion myself)

All of this is plenty ambitious, I wonder whether there are not "good enough solutions" available that are deployable earlier?

> 
> I see no reason why any streaming service has to be live in the same way that
> a video conference needs to be.  

That is a policy/opnion question. I tend to share your position, but I am aware that this is not something that has an objective veridical answer, as it ties into the question of priority and (subjective) importance.

> Even people watching a "live" football game
> would probably be happy with a feed that was 3-5 minutes behind, if it meant
> they never stalled.

Again, I tend to agree, BUT people over here notice on big events if the neighbours start cheering (or gnashing their teeth) well before they see the relevant play themselves, and trade magazines publish measurements of relative delays of common distribution methods for live sport events.
And "never stall" is only going to work for a pretty lax definition of "never" ;)


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