[Starlink] Re: Starlink Digest, Vol 53, Issue 14

[Sebastian Moeller <moeller0@gmx.de>]

Hi Michael,

> On 29. Sep 2025, at 17:43, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> Sebastian Moeller <moeller0@gmx.de> wrote:
>>> On 29. Sep 2025, at 00:26, Michael Richardson <mcr@sandelman.ca> wrote:
>>> 
>>> 
>>> Sebastian Moeller via Starlink <starlink@lists.bufferbloat.net> wrote:
>>>> I fully agree and am quite puzzled to find zero references in the SCONE
>>>> draft for any experiments, let alone successful ones that demonstrate
>>>> the value SCONE might deliver.
>>>> In my world one starts with such experiments and only writes an
>>>> internet draft if these experiments demonstrated that an idea has legs
>>>> to stand on.
>>> 
>>> I regularly attend the SCONE virtual interim meetings.
>>> 
>>> I think that there is more occuring than is being published,
> 
>> That would be IMHO a failure in process... as far as I understood the
>> IETF process aims at being transparent...
> 
> No, it's not.
> If big-5G-vendor runs an experiment, summarizes it's experience, and is
> waiting for the scholarly paper to get reviewed... fine.

Mmmh, in this case I would still like a verbal summary of that experience in the ID even if was not published and might never be.

> 
>>> and I think that
>>> the candidate TRONE and TRAIN and (was there a 3rd?) ideas did have some
>>> spike solutions created.
> 
>> As reader of the current ID I would very much like to know that that
>> happened and what the outcome was, preferably I would learn all of this
>> as part of reading the ID.
> 
> Yes.  Please ask for more on the list.
> 
>>> but, back to my original question:  is there sufficient feedback in the
>>> *starlink* datapath from downlink'ing Satellite, through ISL, to Ground
>>> Station about the actual experienced congestion such that either:
>>> a) packets could be dropped before wasting satellite capacity
>>> b) SCONE (or another mark, including L4S, whether you believe it or not),
>>> could be applied?
>>> 
>>> How much does that available bandwidth vary during each of the 15minute
>>> attachments?
> 
>> I think we are talking about "every 15 seconds" not minutes...
> 
>> There have been some users of cake-autorate on starlink that reported
>> at least some mild improvements, so I would say something might work,
>> albeit not SCONE as that solves none of the problems users have on
>> starlink...
> 
> 15s. Oh. I mis-understood the scale on the slides/presentation.
> No way to do anything useful with feedback on a 15s timescale, I think.

Mmmh, it only takes a few RTTs in slow start to fill a link (we call ist slow start, but doubling every RTT is exponential growth, that is pretty aggressive), so 15 seconds is not so short... 

Your typical on-line capacity test typically finished within 10-15 seconds and such tests want several seconds of full saturating load. So given starlink's often quite decent RTTs, I think 15 seconds should suffice for congestion control/rate contol. However, if I recall correctly there are other timescales with starlink that might be relevant, one was around 4 seconds, I think.

> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
>