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

[Sebastian Moeller <moeller0@gmx.de>]

Hi Michael,


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

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

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

Regards
	Sebastian

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