<html><head></head><body>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....<br><br>Regards<br>        Sebastian<br><br><br><br><div class="gmail_quote">On 14 February 2022 18:52:29 CET, "Bjørn Ivar Teigen" <bjorn@domos.no> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr"><div>Sebastian,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 14 Feb 2022 at 17:15, Sebastian Moeller <<a href="mailto:moeller0@gmx.de">moeller0@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Bjørn,<br>
<br>
<br>
I guess I should have started with the obvious. Nice short article!<br></blockquote><div>Thank you! <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> "See the problem? Buffers produce jitter!"<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
<br>
        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".</blockquote><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
        Given Pete's data at <a href="https://github.com/heistp/l4s-tests" rel="noreferrer" target="_blank">https://github.com/heistp/l4s-tests</a> 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...</blockquote><div> </div><div>Ohh, that work has been updated a lot since the IETF showdown! Thanks for reminding me, I'll have a look at it again.</div><div><br></div><div>- Bjørn Ivar<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Regards<br>
        Sebastian<br>
<br>
<br>
> > <br>
> > <br>
> > On Mon, Feb 14, 2022 at 7:07 AM Bjørn Ivar Teigen <<a href="mailto:bjorn@domos.no" target="_blank">bjorn@domos.no</a>> wrote:<br>
> >> <br>
> >> Hi everyone,<br>
> >> <br>
> >> 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: <a href="https://www.domos.no/news-updates/network-quality-for-rocket-scientists" rel="noreferrer" target="_blank">https://www.domos.no/news-updates/network-quality-for-rocket-scientists</a><br>
> >> <br>
> >> Cheers,<br>
> >> Bjørn Ivar Teigen<br>
> >> <br>
> >> --<br>
> >> Bjørn Ivar Teigen<br>
> >> Head of Research<br>
> >> +47 47335952 | <a href="mailto:bjorn@domos.no" target="_blank">bjorn@domos.no</a> | <a href="http://www.domos.no" rel="noreferrer" target="_blank">www.domos.no</a><br>
> >> WiFi Slicing by Domos<br>
> >> _______________________________________________<br>
> >> Starlink mailing list<br>
> >> <a href="mailto:Starlink@lists.bufferbloat.net" target="_blank">Starlink@lists.bufferbloat.net</a><br>
> >> <a href="https://lists.bufferbloat.net/listinfo/starlink" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/starlink</a><br>
> > <br>
> > <br>
> > <br>
> > -- <br>
> > I tried to build a better future, a few times:<br>
> > <a href="https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org" rel="noreferrer" target="_blank">https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org</a><br>
> > <br>
> > Dave Täht CEO, TekLibre, LLC<br>
> > _______________________________________________<br>
> > Starlink mailing list<br>
> > <a href="mailto:Starlink@lists.bufferbloat.net" target="_blank">Starlink@lists.bufferbloat.net</a><br>
> > <a href="https://lists.bufferbloat.net/listinfo/starlink" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/starlink</a><br>
> <br>
> <br>
> <br>
> -- <br>
> Bjørn Ivar Teigen<br>
> Head of Research<br>
> +47 47335952 | <a href="mailto:bjorn@domos.no" target="_blank">bjorn@domos.no</a> | <a href="http://www.domos.no" rel="noreferrer" target="_blank">www.domos.no</a><br>
> WiFi Slicing by Domos<br>
<br>
</blockquote></div><br clear="all"></div></blockquote></div><div style='white-space: pre-wrap'><div class='k9mail-signature'>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</div></div></body></html>