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