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

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

[David Fernández]

Sebastian, I would appreciate a lot if you can be more concrete on what are
these "solutions are already out there, instead of the maximum signal tell
each and every packet about the maximum of the relative capacity usage
along a path, now the sender can track and extrapolate the change of that
capacity and ideally exit slow start, before over extending the capacity."

AFAIK, the objective of SCONE is " improve slow-start in general", not only
for video, but I must confess I am not following it closely.

For video there is the Media Over QUIC IETF group, so I wonder, if the
SCONE is only for video, why it has not been just discussed there, as
another feature.

Regards,

David

Date: Mon, 29 Sep 2025 08:08:15 +0200
> From: Sebastian Moeller <moeller0@gmx.de>
> Subject: [Starlink] Re: Starlink Digest, Vol 53, Issue 14
> To: Michael Richardson <mcr@sandelman.ca>
> Cc: starlink@lists.bufferbloat.net
> Message-ID: <B71F6D77-800E-4A97-AEEA-8E0479C38577@gmx.de>
> Content-Type: text/plain;       charset=utf-8
>
>
>
> > On 29. Sep 2025, at 00:58, Michael Richardson via Starlink <
> starlink@lists.bufferbloat.net> wrote:
> >
> >
> > David Fernández via Starlink wrote:
> >> I understand that SCONE info about maximum possible bandwidth
> (bottleneck
> >> maximum possible bandwidth, not zero, of course) available on the path
> >> between a QUIC client and server is not to define a steady state
> (although
> >> it could be), but may be better used to set the size of the initial
> burst
> >> of packets after a connection is established, during the slow start
> phase,
> >> to a value that can be more optimal than just a fixed value like 10 (RFC
> >> 6928), which was updated as networks became faster (with more
> >> capacity).
> >
> > No, that's not the goal as I understand it.
> > It's to tell the client that asking for 4K video is not going to work.
>
> However that is a question that actually involves rate-control and IMHO it
> woukld be better to improve slow-start in general than to taylor a bespoke
> solution for just video streaming over QUIC.
>
> > Yes, it might be able to get an initial few seconds of 4K, but then the
> burst
> > tolerances (token buckets, etc.) of the network will be exhausted, and
> the 4K
> > will begin to fail.
>
> I keep repeating this, but that solutions are already out there, instead
> of the maximum signal tell each and every packet about the maximum of the
> relative capacity usage along a path, now the sender can track and
> extrapolate the change of that capacity and ideally exit slow start, before
> over extending the capacity.
>
> > The video will then pause/skip/.. and the client will go back to 2K.
> > Lather. Rinse. Repeat.
> >
> >> The advantage of QUIC vs. TCP for web browsing should be an increased
> >> interactivity, less RTTs to do connections, more responsiveness of
> sites,
> >> less lag and latency, although it seems people is not really noticing
> the
> >> difference after sites start using HTTP/3 vs. HTTP/2.
> >
> > Probably the most important thing is that it gets rid of head of queue
> blocking.
> >
> >> For example, today, the following site was reported as recently starting
> >> using HTTP/3:
> >> Pokemon.com (https://w3techs.com/sites/info/pokemon.com)
> >
> >> If anybody made a survey to usual Pokemon site visitors, I wonder if
> they
> >> noticed that change.
> >
> > When I think about QUIC, I think about PsyDuck for some reason.
> > When I think about TCP, I think about JigglyPuff.
> > Or maybe Kirby (not a pokemon).
> > And, when I think about UUCP, I think about Thomas the Tank Engine.
> > Yes, I was a parent over the last 20 years.
>
> :)
>
> >
> > --
> > ]               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] Re: SCONE, bandwidth indeterminacy and network to host signals (was Re: Re: Starlink Digest, Vol 53, Issue 14)

[Sebastian Moeller]

Hi David,


> On 29. Sep 2025, at 09:37, David Fernández via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> Sebastian, I would appreciate a lot if you can be more concrete on what are
> these "solutions are already out there, instead of the maximum signal tell
> each and every packet about the maximum of the relative capacity usage
> along a path, now the sender can track and extrapolate the change of that
> capacity and ideally exit slow start, before over extending the capacity."

Fair point, let me post 
E.g. Poseidon:
https://www.usenix.org/system/files/nsdi23-wang-weitao.pdf

or this:
https://web.stanford.edu/~sarslan/files/Switches_Know_The_Exact_Amount_of_Congestion___BufferSizingWorkshop.pdf

as an example... there are more, there was even an ID regarding this, but the IETF was pretty hostile so people moved on to to among others ultraethernet.


What these proposals/experiments/solutions have in common is the realisation that veridical information about a path's bottleneck as timely as possible is the special sauce that allows fast reaction to changes.
Now, some of this is going to be hard to implement over the existing internet, but hand on heart, so is SCONE.

Here is the kicker, if you actually track the changes in bottleneck capacity and compare these against your own rate or intended rate increases you will be able to actually extrapolate when you reach that capacity and hence can do a better job of not over-committing too much date into the network. But to do this you really want per-packet multi-bit information about the path so you can react in a timely fashion to changes. This, by the way, is also why I consider L4S too little too late, this is NOT the desired per-packet  multi-bit signal, in a sense it can be seen as a multi-bit information dithered across multiple packets from undetermined flows.

But I stop this tangent here, unless you have more question.



> AFAIK, the objective of SCONE is " improve slow-start in general", not only
> for video, but I must confess I am not following it closely.

Not seeing that objective clearly in the SCONE group/working group or ID, but I might have overlooked that.

> 
> For video there is the Media Over QUIC IETF group, so I wonder, if the
> SCONE is only for video, why it has not been just discussed there, as
> another feature.

Honestly, that is how the IETF operates (with a bit of luck things will get coordinated a bit better if overlöapping IDs reach more mature state)... but at least the SCONE group's goals are formulated generically and not focussed on video (or on slow-start for that matter), but that tells little about the underlaying motivation to make that specific pig get airborne...
I have zero püroblems, accepting that this might be mobile carriers that desire to flub network neutrality requirements (or that operate in areas without such regulations)


> 
> Regards,
> 
> David
> 
> Date: Mon, 29 Sep 2025 08:08:15 +0200
>> From: Sebastian Moeller <moeller0@gmx.de>
>> Subject: [Starlink] Re: Starlink Digest, Vol 53, Issue 14
>> To: Michael Richardson <mcr@sandelman.ca>
>> Cc: starlink@lists.bufferbloat.net
>> Message-ID: <B71F6D77-800E-4A97-AEEA-8E0479C38577@gmx.de>
>> Content-Type: text/plain;       charset=utf-8
>> 
>> 
>> 
>>> On 29. Sep 2025, at 00:58, Michael Richardson via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>> 
>>> 
>>> David Fernández via Starlink wrote:
>>>> I understand that SCONE info about maximum possible bandwidth
>> (bottleneck
>>>> maximum possible bandwidth, not zero, of course) available on the path
>>>> between a QUIC client and server is not to define a steady state
>> (although
>>>> it could be), but may be better used to set the size of the initial
>> burst
>>>> of packets after a connection is established, during the slow start
>> phase,
>>>> to a value that can be more optimal than just a fixed value like 10 (RFC
>>>> 6928), which was updated as networks became faster (with more
>>>> capacity).
>>> 
>>> No, that's not the goal as I understand it.
>>> It's to tell the client that asking for 4K video is not going to work.
>> 
>> However that is a question that actually involves rate-control and IMHO it
>> woukld be better to improve slow-start in general than to taylor a bespoke
>> solution for just video streaming over QUIC.
>> 
>>> Yes, it might be able to get an initial few seconds of 4K, but then the
>> burst
>>> tolerances (token buckets, etc.) of the network will be exhausted, and
>> the 4K
>>> will begin to fail.
>> 
>> I keep repeating this, but that solutions are already out there, instead
>> of the maximum signal tell each and every packet about the maximum of the
>> relative capacity usage along a path, now the sender can track and
>> extrapolate the change of that capacity and ideally exit slow start, before
>> over extending the capacity.
>> 
>>> The video will then pause/skip/.. and the client will go back to 2K.
>>> Lather. Rinse. Repeat.
>>> 
>>>> The advantage of QUIC vs. TCP for web browsing should be an increased
>>>> interactivity, less RTTs to do connections, more responsiveness of
>> sites,
>>>> less lag and latency, although it seems people is not really noticing
>> the
>>>> difference after sites start using HTTP/3 vs. HTTP/2.
>>> 
>>> Probably the most important thing is that it gets rid of head of queue
>> blocking.
>>> 
>>>> For example, today, the following site was reported as recently starting
>>>> using HTTP/3:
>>>> Pokemon.com (https://w3techs.com/sites/info/pokemon.com)
>>> 
>>>> If anybody made a survey to usual Pokemon site visitors, I wonder if
>> they
>>>> noticed that change.
>>> 
>>> When I think about QUIC, I think about PsyDuck for some reason.
>>> When I think about TCP, I think about JigglyPuff.
>>> Or maybe Kirby (not a pokemon).
>>> And, when I think about UUCP, I think about Thomas the Tank Engine.
>>> Yes, I was a parent over the last 20 years.
>> 
>> :)
>> 
>>> 
>>> --
>>> ]               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

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

[Michael Richardson]

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.   I give it a 40% chance of getting usefully
deployed before the need is overtaken by other events.
The promise is that 3GPP operators won't have to do expensive DPI anymore.

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,
I also see that the lack of useful end-host<->network relationship/API has
resulted in our inability to offer 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)

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!)

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)

I see no reason why any streaming service has to be live in the same way that
a video conference needs to be.  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.

--
]               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] Re: SCONE, bandwidth indeterminacy and network to host signals (was Re: Re: Starlink Digest, Vol 53, Issue 14)

[Sebastian Moeller]

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