[Starlink] Network quality for rocket scientists

[Sebastian Moeller]

Hi Bjørn,


I guess I should have started with the obvious. Nice short article!



> On Feb 14, 2022, at 17:32, Bjørn Ivar Teigen <bjorn at domos.no> wrote:
> 
> Hi Sebastian, thank you for the feedback.
> 
> "See the problem? Buffers produce jitter!"
> 
> 
> I would rephrase that as "over-sized and under-managed" buffers increase jitter unduly. Interestingly, bound jitter can be converted into static latency by using, wait for it, (delay) buffers and a scheduler.
> 
> You are absolutely right. I was hoping someone would spot that! There is one problem with that approach though. To actually remove the jitter the scheduler can no longer be work-conserving (needs delay as you also point out), and that increases TCP ramp-up times (among other things). Can be a hard sell. I think the benefits outweigh the costs though, so I would do it your way.

	But that is what end-points already do, on-line games do this to equalize internet access quality between players (allowing them to make matches over larger populations), as do DASH type video streaming applications, where the isochronous play-out takes the role of the scheduler and the race-to-fill-the-play-out-buffers serves to keep the buffers filled so the scheduler never runs "dry".


> 
> > 
> > Only nit is at the conclusion... the benefits of applying fair queuing
> > to level out apparent jitter is well demonstrated at this point, for
> > most kinds of traffic. Wish you'd mentioned it.
> 
>         I rather wish low latency DOCSIS (LLD) aka L4S's primary driver/use-case would not have been mentioned before it has been properly tested and confirmed delivering on its promises. Because most of what L4S offers/mandates for jitter reduction is "hopes and prayers", aka end-points are supposed to behave well... in fairness LLD at least has a poor man's FQ on board in the guise of "queue protection" (with by default like 32 "buckets")... some of the cost of FQ with only few of its benefits...
> Fair enough, time will show! 

	Given Pete's data at https://github.com/heistp/l4s-tests I am cautious to hold my breath... or to put it differently, I am certain they will not deliver on their promises, the bigger question is whether the incremental improvement they offer (over the default FIFO) is decent enough to retroactively justify the disruption they will have caused...

Regards
	Sebastian



>  
> Regards
>         Sebastian
> 
> 
> 
> > 
> > 
> > On Mon, Feb 14, 2022 at 7:07 AM Bjørn Ivar Teigen <bjorn at domos.no> wrote:
> >> 
> >> Hi everyone,
> >> 
> >> I was inspired by the latest Starship presentation to write a piece on network quality in the language of rocket science. The blog can be found here: https://www.domos.no/news-updates/network-quality-for-rocket-scientists
> >> 
> >> Cheers,
> >> Bjørn Ivar Teigen
> >> 
> >> --
> >> Bjørn Ivar Teigen
> >> Head of Research
> >> +47 47335952 | bjorn at domos.no | www.domos.no
> >> WiFi Slicing by Domos
> >> _______________________________________________
> >> Starlink mailing list
> >> Starlink at lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/starlink
> > 
> > 
> > 
> > -- 
> > I tried to build a better future, a few times:
> > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> > 
> > Dave Täht CEO, TekLibre, LLC
> > _______________________________________________
> > Starlink mailing list
> > Starlink at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> 
> 
> 
> -- 
> Bjørn Ivar Teigen
> Head of Research
> +47 47335952 | bjorn at domos.no | www.domos.no
> WiFi Slicing by Domos