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

["David Fernández" <davidfdzp@gmail.com>]

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