From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 A6F653B2A4 for ; Mon, 14 Feb 2022 14:21:48 -0500 (EST) Received: by mail-lf1-x12c.google.com with SMTP id u6so32639745lfc.3 for ; Mon, 14 Feb 2022 11:21:48 -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=w83rYuHvUSuV6vnK+H65wMs/4fOk1qEsEoSblfap33c=; b=7vEflGlYHKPVO8Lj3KeiV37ho4I4Owhc9HEoTwxeyZ4KDQXilyHt+/WfhoiD8QabEK Bsq6bCfyoEpA+ETVmEMhIksWXmKtVW1eMTTvrSm7x3Ast5kONAz8+9T58z23jkYFomZy QR5H7kfa88n+PoxC/oMZbi03tQET0CXZ2YHqtgAPTHUG7wXlKuAc6nrshsYUEC/yTro3 5C+dDuHgdqiwEhZjpikpWE9sss/EeG4jNlZ2EtO7Y4LpSiXSpPQqj9wTp3W5xda3L1oA zYYRHc5cpadXhMqSAcZIn/IVv+c+WpvdfytahkTkPyVCEyYDkAsEt6csURa5ZtouijTw PvXA== 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=w83rYuHvUSuV6vnK+H65wMs/4fOk1qEsEoSblfap33c=; b=ebiCK13FruUxGT9c/OVLL/M64NPPVnbmOIcjFTQRVacyzSx0hQNh3YskyiPqzmh2Wg oY5sryyn8HEDFl73cHmDPJGbr83oZfK4QP9GwrXxEsIMdMLSkYF497zJdyoyUa8kKmHh wWYqmE00N2G870y0w0OQo65eblHQZDw5vMFRPeJMig8c8Vz9+pNRlJB0CcJHY3ccEgDK Z2z7tsLjuNAxsP8jF8D+ZpLriTptx2h9Vl6assgA/nSz0NgMOeEyp7KxvDeu9gCo2Hu1 1yIdHXJw6vUzJNUIGJWg8n8fyciB+b8vdEQ9wjlslKpsfhOogtKJHPMGx/p5/lBCRT4G 7cWQ== X-Gm-Message-State: AOAM532DkLHdMZxyOdh40ePuefq5YAQZEkEzjM2opmDQHt6BL/sqXiyz kBH797Nt4y6blWT+nayc6tw46pkkHPHQ72auWBVwwg== X-Google-Smtp-Source: ABdhPJzSBaWAWgUjby34JqQc5wXXwTto8xYS3Ljj3AGoSpgcxJzwr8Von9PU/R+u4ohxGFmqyvqczSzp73zPQvO/rUU= X-Received: by 2002:a05:6512:25a:: with SMTP id b26mr372430lfo.261.1644866507182; Mon, 14 Feb 2022 11:21:47 -0800 (PST) MIME-Version: 1.0 References: <4AFF4380-4AA5-47C5-8BF0-440101A3D788@gmx.de> <3157ED41-1438-4519-9E84-847404BE229D@gmx.de> In-Reply-To: From: =?UTF-8?Q?Bj=C3=B8rn_Ivar_Teigen?= Date: Mon, 14 Feb 2022 19:21:35 +0000 Message-ID: To: Sebastian Moeller Cc: =?UTF-8?Q?Dave_T=C3=A4ht?= , starlink@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000dd304a05d7ff538d" 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 19:21:48 -0000 --000000000000dd304a05d7ff538d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FQ clearly gets us very good behavior, so no argument there. Also agree the cost of giving up work conservation might be too high, and I'm not saying we should necessarily do that. I just wanted to point out that insisting on work conservation also comes at a cost (which we are free to choose to pay of course!). It's a choice between adding some middlebox complexity or accepting the amount of jitter induced by the amount of queuing needed to maintain high utilization (which depends on the jitteriness of the interface working to empty the queue). Regards, Bj=C3=B8rn Ivar On Mon, 14 Feb 2022 at 18:39, Sebastian Moeller wrote: > Regarding work conservation, FQ as so often appears to be a decent > solution that while not optimal will also not be pessimal. Which IMHO is = as > much as we can hope for unless we want to burden all middleboxes with > deducing relative importance of packets.... > > 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. Nice short article! >>> >> Thank you! >> >>> >>> > "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 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 poi= nt >>> 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 d= o it >>> your way. >>> >>> 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". >> >> >> 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 sto= ry >> with the queues "in the network", in routers, switches, access points, e= tc. >> 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 th= ey >>> 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... >> >> >> Ohh, that work has been updated a lot since the IETF showdown! Thanks fo= r >> 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 piec= e >>> on network quality in the language of rocket science. The blog can be f= ound >>> 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 >>> >>> >> -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > --=20 Bj=C3=B8rn Ivar Teigen Head of Research +47 47335952 | bjorn@domos.no | www.domos.no WiFi Slicing by Domos --000000000000dd304a05d7ff538d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FQ clearly gets us very good behavior, so no argument= there.
Also agree the cost of giving up work conservation might = be too high, and I'm not saying we should necessarily do that. I just w= anted to point out that insisting on work conservation also comes at a cost= (which we are free to choose to pay of course!). It's a choice between= adding some middlebox complexity or accepting the amount of jitter induced= by the amount of queuing needed to maintain high utilization (which depend= s on the jitteriness of the interface working to empty the queue).

Regards,
Bj=C3=B8rn Ivar

=

On Mon, 14 Feb 2022 at 18:39, Sebastian Moeller <moeller0@gmx.de> wrote:
Regarding work conservation, FQ as so= often appears to be a decent solution that while not optimal will also not= be pessimal. Which IMHO is as much as we can hope for unless we want to bu= rden all middleboxes with deducing relative importance of packets....
Regards
Sebastian



On= 14 February 2022 18:52:29 CET, "Bj=C3=B8rn Ivar Teigen" <bjorn@domos.no> wrot= e:
Sebastian,

On Mon, 14 Feb 2022 at 17:15, Sebastian= Moeller <moeller0@= gmx.de> 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" 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


--
Sent from my Android device with K-9 Mai= l. Please excuse my brevity.


--
Bj=C3=B8rn Ivar Teigen
Head of Research
+47 47335952 | bjorn@domos.no=C2=A0|=C2=A0ww= w.domos.no
<= span style=3D"font-family:arial,sans-serif">WiFi Slicing by Domos
<= /div>
--000000000000dd304a05d7ff538d--