From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 54D273B2A4 for ; Mon, 14 Feb 2022 13:39:36 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1644863973; bh=HAk8Ym7tpELuHH+5ruKjXI5Vuhq5r8dIopKN2jvEjns=; h=X-UI-Sender-Class:Date:From:To:CC:Subject:In-Reply-To:References; b=aGcw90bwPoVpjXi6PAC/Y3aEwKA1+e+AM9CpAga48d+UtZ65P4/lTpX4RxCdd4Vuc 7/cWYgKgyuIRx1DdH4Ng3nsOukd2AqEPiFYBlzMMo0K7v81w3Fk/a4n1781BxryOpt fjwyDeXMBRbm1tdZe2ZgLMoBWzGoBlR17QDcgaIg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [127.0.0.1] ([77.8.70.145]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mnpru-1o3BPz1Bpy-00pKTU; Mon, 14 Feb 2022 19:39:33 +0100 Date: Mon, 14 Feb 2022 19:38:54 +0100 From: Sebastian Moeller To: =?ISO-8859-1?Q?Bj=F8rn_Ivar_Teigen?= CC: =?ISO-8859-1?Q?Dave_T=E4ht?= , starlink@lists.bufferbloat.net User-Agent: K-9 Mail for Android In-Reply-To: References: <4AFF4380-4AA5-47C5-8BF0-440101A3D788@gmx.de> <3157ED41-1438-4519-9E84-847404BE229D@gmx.de> Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----NAQN57502QN0TEEEJO94CF87OZKVKQ Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:gBAXRI3TpmUfQmDSBida4Xd4eW7hSFsGLLmofVg49Me9soSu6pk 4AnTnZ33f/LLOJFx+VbvuiawLLXpWl1Mbn85wMA2GgCN81yLj3a++tMSZXYEfVGq50Ewu9H 595fQ7fbwmgV1EX9TE1APrtonzRm4xbfCfRu2N8Uejk36Dz2S9u1tHS9CGD0v2XdLleamJC hmhX0gYyFuYWyq+VXQwBw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:MsSbfN5ruYQ=:Hq8BM/EULe1MZ6jt7S5sUt VT2GJEkFw2Hchseymn+RopPwafOOnCACYjh0V/kwAOtuEhqSRwTJ6ko9QGFJeTD8BYbPE9N/8 B9fP6+9xYJLKZdm68p8WogBgZRrYkMm00ykht+WhSqbaKi5IXeX+GrYaMi2PHM+xdfZ2uhxHU VF0tu8KV9IYroUG9UOIeTmML4tCyDDqaHfC0UYLbnTyAUctaiT5xP6N3pb8Ms7gng4IjKElyd 1szFDoqRj9zUEwMuRiwu5qRRWSI0G6hz+oPSHHaejrnjLb8p8PHapC90pE5sOIBRp826rALjr UnAOmgUbseQyROjuJPTsl9cbntbgOrMfN/xmzaiprKVQIsTbsLY/Yi3tMn2wTKygBhenUIRuB q/WPBAr6CQxArZbLw7im+XHECVD75f4J9ADdwbLFsTlQ2QCUGoPV3ouzGuD6CObgDWtY1sqHZ z9WYTxq59eknuUCz3Xq+ptqtPb74pab3sflwO5CI/Uq2n71d483j3sWY28GoNjRnP8WbIAnhB 85FmmTKzFjCbu6u21Uu8mtkWIThWDMwRetVUxl3iXPeluLGUlLKT5VR7kx/PIk8rcqImtUDnJ aioFhV+RYoRd5OCJYFlE3kpsfj09eKFyhBDCDjnTBKPHjeM/x+wMaxL1Czc1vS6yUAPqMZrKN GG+mOuIwFGjBbDTvJf0GRAJGnR4uJ9xdNNjGo/8scUZTP5uB753+Hegv2mYEOn7HKLCUbugjN 2irmhfHdUCL7fPNyr1+OnZueS4qLkDGeDpkVB76A1EjoIS0mhJtS/WSomZeJAONVpB/nTW0iK 6jSiytPT9phIoTbCSvqDkzWlqctgeAMWq/yOYpHmPIvwKpjlYwb0Cr03KlT+Nh3q+1nJtNeZi qn/5dtNbDnr9/uLJlnHMeovQ/jm/I9/3ag54pYLzlbAf/6NDeieuf6FeITIbsZfAGB1PuXWhD x2Wil4m8bo1i5h6R4+ioFhdfCplOLWsQK5hG78+h7lSdP7I6Oss4yeDeX0YSSllHT+I62E9e4 LjaT+C7VXkdePpKZFKVR8v1nBOSTHIBiZ+mmgyjEAsfXZJTUBlQMsurG69TpomKNMb5DZHgCg P8EABHDj4M1Pcg= Subject: Re: [Starlink] Network quality for rocket scientists X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 18:39:36 -0000 ------NAQN57502QN0TEEEJO94CF87OZKVKQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Regarding work conservation, FQ as so often appears to be a decent solution= that while not optimal will also not be pessimal=2E Which IMHO is as much = as we can hope for unless we want to burden all middleboxes with deducing r= elative importance of packets=2E=2E=2E=2E Regards Sebastian On 14 February 2022 18:52:29 CET, "Bj=C3=B8rn Ivar Teigen" wrote: >Sebastian, > >On Mon, 14 Feb 2022 at 17:15, Sebastian Moeller wrote= : > >> Hi Bj=C3=B8rn, >> >> >> I guess I should have started with the obvious=2E Nice short article! >> >Thank you! > >> >> > "See the problem? Buffers produce jitter!" >> > >> > I would rephrase that as "over-sized and under-managed" buffers incre= ase >> jitter unduly=2E Interestingly, bound jitter can be converted into stat= ic >> latency by using, wait for it, (delay) buffers and a scheduler=2E >> > >> > You are absolutely right=2E I was hoping someone would spot that! The= re is >> one problem with that approach though=2E To actually remove the jitter = the >> scheduler can no longer be work-conserving (needs delay as you also poi= nt >> out), and that increases TCP ramp-up times (among other things)=2E Can = be a >> hard sell=2E I think the benefits outweigh the costs though, so I would= do it >> your way=2E >> >> But that is what end-points already do, on-line games do this t= o >> 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"=2E > > >Good points=2E The application clients and servers can choose to use thei= r >resources in a way that is not work-conserving and thus achieve sharing o= f >resources without introducing jitter=2E I would argue it's a different st= ory >with the queues "in the network", in routers, switches, access points, et= c=2E >There seems to be an unwritten law that those schedulers must be work >conserving, presumably to minimize round-trip times, and this makes it >harder to achieve well-behaved sharing=2E So in network devices configure= d to >forward packets as quickly as possible, I think it's mostly true to say >that buffers produce jitter=2E > > Given Pete's data at https://github=2Ecom/heistp/l4s-tests I am >> cautious to hold my breath=2E=2E=2E or to put it differently, I am cert= ain they >> will not deliver on their promises, the bigger question is whether the >> incremental improvement they offer (over the default FIFO) is decent en= ough >> to retroactively justify the disruption they will have caused=2E=2E=2E > > >Ohh, that work has been updated a lot since the IETF showdown! Thanks for >reminding me, I'll have a look at it again=2E > >- Bj=C3=B8rn Ivar > > >> Regards >> Sebastian >> >> >> > > >> > > >> > > On Mon, Feb 14, 2022 at 7:07 AM Bj=C3=B8rn Ivar Teigen >> wrote: >> > >> >> > >> Hi everyone, >> > >> >> > >> I was inspired by the latest Starship presentation to write a piec= e >> on network quality in the language of rocket science=2E The blog can be= found >> here: >> https://www=2Edomos=2Eno/news-updates/network-quality-for-rocket-scient= ists >> > >> >> > >> Cheers, >> > >> Bj=C3=B8rn Ivar Teigen >> > >> >> > >> -- >> > >> Bj=C3=B8rn Ivar Teigen >> > >> Head of Research >> > >> +47 47335952 | bjorn@domos=2Eno | www=2Edomos=2Eno >> > >> WiFi Slicing by Domos >> > >> _______________________________________________ >> > >> Starlink mailing list >> > >> Starlink@lists=2Ebufferbloat=2Enet >> > >> https://lists=2Ebufferbloat=2Enet/listinfo/starlink >> > > >> > > >> > > >> > > -- >> > > I tried to build a better future, a few times: >> > > https://wayforward=2Earchive=2Eorg/?site=3Dhttps%3A%2F%2Fwww=2Eicei= =2Eorg >> > > >> > > Dave T=C3=A4ht CEO, TekLibre, LLC >> > > _______________________________________________ >> > > Starlink mailing list >> > > Starlink@lists=2Ebufferbloat=2Enet >> > > https://lists=2Ebufferbloat=2Enet/listinfo/starlink >> > >> > >> > >> > -- >> > Bj=C3=B8rn Ivar Teigen >> > Head of Research >> > +47 47335952 | bjorn@domos=2Eno | www=2Edomos=2Eno >> > WiFi Slicing by Domos >> >> > >--=20 >Bj=C3=B8rn Ivar Teigen >Head of Research >+47 47335952 | bjorn@domos=2Eno | www=2Edomos=2Eno >WiFi Slicing by Domos --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------NAQN57502QN0TEEEJO94CF87OZKVKQ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Regarding work conservation, FQ as so often appear= s to be a decent solution that while not optimal will also not be pessimal= =2E Which IMHO is as much as we can hope for unless we want to burden all m= iddleboxes with deducing relative importance of packets=2E=2E=2E=2E

= Regards
Sebastian



On 1= 4 February 2022 18:52:29 CET, "Bj=C3=B8rn Ivar Teigen" <bjorn@domos=2Eno= > wrote:
Sebastian,

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, 14 Feb 2022 at 17:15, Sebastia= n Moeller <moeller0@gmx=2Ede>= ; wrote:
Hi Bj= =C3=B8rn,


I guess I should have started with the obvious=2E Nice short article!
<= /blockquote>
Thank you!

> "See the problem? Buffers produce jitter!"
>
> I would rephrase that as "over-sized and under-managed" buffers incre= ase jitter unduly=2E Interestingly, bound jitter can be converted into stat= ic latency by using, wait for it, (delay) buffers and a scheduler=2E
>
> You are absolutely right=2E I was hoping someone would spot that! The= re is one problem with that approach though=2E To actually remove the jitte= r the scheduler can no longer be work-conserving (needs delay as you also p= oint out), and that increases TCP ramp-up times (among other things)=2E Can= be a hard sell=2E I think the benefits outweigh the costs though, so I wou= ld do it your way=2E

        But that is what end-points already do, on-lin= e games do this to equalize internet access quality between players (allowi= ng them to make matches over larger populations), as do DASH type video str= eaming applications, where the isochronous play-out takes the role of the s= cheduler and the race-to-fill-the-play-out-buffers serves to keep the buffe= rs filled so the scheduler never runs "dry"=2E

<= div>Good points=2E The application clients and servers can choose to use th= eir resources in a way that is not work-conserving and thus achieve sharing= of resources without introducing jitter=2E I would argue it's a different = story with the queues "in the network", in routers, switches, access points= , etc=2E There seems to be an unwritten law that those schedulers must be w= ork conserving, presumably to minimize round-trip times, and this makes it = harder to achieve well-behaved sharing=2E So in network devices configured = to forward packets as quickly as possible, I think it's mostly true to say = that buffers produce jitter=2E

        Given Pete's data at https://githu= b=2Ecom/heistp/l4s-tests I am cautious to hold my breath=2E=2E=2E 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=2E=2E=2E
 
Ohh, that= work has been updated a lot since the IETF showdown! Thanks for reminding = me, I'll have a look at it again=2E

- Bj=C3=B8rn I= var
 
Regards
        Sebastian


> >
> >
> > On Mon, Feb 14, 2022 at 7:07 AM Bj=C3=B8rn Ivar Teigen <bjorn@domos=2Eno> w= rote:
> >>
> >> Hi everyone,
> >>
> >> I was inspired by the latest Starship presentation to write = a piece on network quality in the language of rocket science=2E The blog ca= n be found here: https://= www=2Edomos=2Eno/news-updates/network-quality-for-rocket-scientists
> >>
> >> Cheers,
> >> Bj=C3=B8rn Ivar Teigen
> >>
> >> --
> >> Bj=C3=B8rn Ivar Teigen
> >> Head of Research
> >> +47 47335952 | bjorn@domos=2Eno | www=2Edomos=2Eno
> >> WiFi Slicing by Domos
> >> _______________________________________________
> >> Starlink mailing list
> >> Starlink@lists=2Ebufferbloat=2Enet
> >> https://lists=2Ebufferbloat=2Enet/= listinfo/starlink
> >
> >
> >
> > --
> > I tried to build a better future, a few times:
> > https://wayforwa= rd=2Earchive=2Eorg/?site=3Dhttps%3A%2F%2Fwww=2Eicei=2Eorg
> >
> > Dave T=C3=A4ht CEO, TekLibre, LLC
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists=2Ebufferbloat=2Enet
> > https://lists=2Ebufferbloat=2Enet/list= info/starlink
>
>
>
> --
> Bj=C3=B8rn Ivar Teigen
> Head of Research
> +47 47335952 | = bjorn@domos=2Eno | www=2Edomos=2Eno
> WiFi Slicing by Domos


--
Sent from= my Android device with K-9 Mail=2E Please excuse my brevity=2E
= ------NAQN57502QN0TEEEJO94CF87OZKVKQ--