From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 72CBC3B2A4 for ; Mon, 14 Feb 2022 12:52:42 -0500 (EST) Received: by mail-lf1-x133.google.com with SMTP id z19so32093585lfq.13 for ; Mon, 14 Feb 2022 09:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=domos-no.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rBKJeOC5hbTm1TGaOb/P1PZGekGAi/DKXbNT+N4GHGE=; b=wyjnVdmixDHUAJk2OIAJSYU1zEVFEIaYYXM9/85FxICTNpJUEkpH7MfRZKdLyG2Zpx wGbI3RkhPKIzyRjweiylGkEKnHp10HdONqgRaZGPzQQkF48ZUf7SwXKvh3P0F4h2v9Ox m9FroSklT4EfpSFRljKjCQGZDJQYKZG5raTSqDTNC/9ijCrInpGCTGhrKW03QdN4tI9n Fd+dXvOiyxI4ciqVT5M1oapYjSBeiUbCqB2ZB9bQ7yiLA6LD56e0K39tb5Af2wTYciAF vcKdXLQIf1C2Ge9yfNpEvnVJoV4zGzks2gD21pnhZyDyQc3IbeMv9+v9d24HGQCEdR3M y+4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rBKJeOC5hbTm1TGaOb/P1PZGekGAi/DKXbNT+N4GHGE=; b=TEBE89TJ+EET+x8TY6t9+INsb/xnfcGpXzbrKUc4bn5njCmtrvoJKI0LABltq2JawJ EFt3xRXjJEDzCcHsjb3+b2WN9PWWlQ82obkHS6j4SscEMjl43R6Ag+vXmfKTbo6COgz/ tfP7Xvo1OwTl0b73F4PDq8XXBIRDvf/1rXb+oHxJjXmKm072Z0DgRVEQDensROSX95Q+ UuLMgTwUYJ6/0F7Rw4Wk5yIZQ68vGkU39cUXEQQXCZdbiLCb0UKQl7+SmMlJZl+1nWwh so9Evl8TiA3269KuemgI2ZU/7vv9rPkScU3U69HxV6UWDxQImxOtC8CWsRSdHM1EGXus cuZQ== X-Gm-Message-State: AOAM533FH0C+SqN2g3RDYOpHvdZXl2E0LLZE6V7hdm6acBO3Yq5Kn/u1 l3clqt90bLy8eZlFbhPTeNqNvde982AoDLGWC82dJw== X-Google-Smtp-Source: ABdhPJwQ/DVRO2Ygiiizu5TD0kr3iTi4LVBL7A1Lhep6oZTLzBsEA9D5+cglse9STEEfTdzQ3wdP6h8Y6VnxeMsirY0= X-Received: by 2002:a05:6512:25a:: with SMTP id b26mr107208lfo.261.1644861160723; Mon, 14 Feb 2022 09:52:40 -0800 (PST) MIME-Version: 1.0 References: <4AFF4380-4AA5-47C5-8BF0-440101A3D788@gmx.de> <3157ED41-1438-4519-9E84-847404BE229D@gmx.de> In-Reply-To: <3157ED41-1438-4519-9E84-847404BE229D@gmx.de> From: =?UTF-8?Q?Bj=C3=B8rn_Ivar_Teigen?= Date: Mon, 14 Feb 2022 17:52:29 +0000 Message-ID: To: Sebastian Moeller Cc: =?UTF-8?Q?Dave_T=C3=A4ht?= , starlink@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="00000000000030b20505d7fe1523" 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 17:52:42 -0000 --00000000000030b20505d7fe1523 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. Nice short article! > Thank you! > > > "See the problem? Buffers produce jitter!" > > > > I would rephrase that as "over-sized and under-managed" buffers increas= e > 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 i= s > 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". Good points. The application clients and servers can choose to use their resources in a way that is not work-conserving and thus achieve sharing of resources without introducing jitter. I would argue it's a different story with the queues "in the network", in routers, switches, access points, etc. 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. So in network devices configured to forward packets as quickly as possible, I think it's mostly true to say that buffers produce jitter. 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 enou= gh > to retroactively justify the disruption they will have caused... Ohh, that work has been updated a lot since the IETF showdown! Thanks for reminding me, I'll have a look at it again. - 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 piece > on network quality in the language of rocket science. The blog can be fou= nd > here: > https://www.domos.no/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.no | www.domos.no > > >> WiFi Slicing by Domos > > >> _______________________________________________ > > >> Starlink mailing list > > >> Starlink@lists.bufferbloat.net > > >> https://lists.bufferbloat.net/listinfo/starlink > > > > > > > > > > > > -- > > > I tried to build a better future, a few times: > > > https://wayforward.archive.org/?site=3Dhttps%3A%2F%2Fwww.icei.org > > > > > > Dave T=C3=A4ht CEO, TekLibre, LLC > > > _______________________________________________ > > > Starlink mailing list > > > Starlink@lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/starlink > > > > > > > > -- > > Bj=C3=B8rn Ivar Teigen > > Head of Research > > +47 47335952 | bjorn@domos.no | www.domos.no > > WiFi Slicing by Domos > > --=20 Bj=C3=B8rn Ivar Teigen Head of Research +47 47335952 | bjorn@domos.no | www.domos.no WiFi Slicing by Domos --00000000000030b20505d7fe1523 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sebastian,

On Mon, 14 Feb 2022 at 17:15, Sebastian= Moeller <moeller0@gmx.de> wro= te:
Hi Bj=C3=B8r= n,


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

> "See the problem? Buffers produce jitter!"
>
> I would rephrase that as "over-sized and under-managed" buff= ers increase jitter unduly. Interestingly, bound jitter can be converted in= to 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 h= ard sell. I think the benefits outweigh the costs though, so I would do it = your way.

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

=
Good points. The application clients and servers can choose to u= se their resources in a way that is not work-conserving and thus achieve sh= aring of resources without introducing jitter. I would argue it's a dif= ferent story with the queues "in the network", in routers, switch= es, access points, etc. There seems to be an unwritten law that those sched= ulers must be work conserving, presumably to minimize round-trip times, and= this makes it harder to achieve well-behaved sharing. So in network device= s configured to forward packets as quickly as possible, I think it's mo= stly true to say that buffers produce jitter.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Given Pete's data at https://gith= ub.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 big= ger question is whether the incremental improvement they offer (over the de= fault FIFO) is decent enough to retroactively justify the disruption they w= ill have caused...
=C2=A0
Ohh, that work has bee= n updated a lot since the IETF showdown! Thanks for reminding me, I'll = have a look at it again.

- Bj=C3=B8rn Ivar
=C2=A0
Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian


> >
> >
> > On Mon, Feb 14, 2022 at 7:07 AM Bj=C3=B8rn Ivar Teigen <bjorn@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 b= e found here: https://www.dom= os.no/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.no | www.domos.no
> >> WiFi Slicing by Domos
> >> _______________________________________________
> >> Starlink mailing list
> >> Starlink@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/= starlink
> >
> >
> >
> > --
> > I tried to build a better future, a few times:
> > https://wayforward.archiv= e.org/?site=3Dhttps%3A%2F%2Fwww.icei.org
> >
> > Dave T=C3=A4ht CEO, TekLibre, LLC
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/st= arlink
>
>
>
> --
> Bj=C3=B8rn Ivar Teigen
> Head of Research
> +47 47335952 | bjo= rn@domos.no | www.domos.no
> WiFi Slicing by Domos



--
Bj=C3=B8rn Ivar Teigen=
Head of Research
+47 47335952 | = bjorn@domos.no=C2=A0|=C2=A0www.domos.no
WiFi Slicing by Domos<= /span>
--00000000000030b20505d7fe1523--