Re: [Starlink] The "reasons" that bufferbloat isn't a problem

[Frantisek Borsik <frantisek.borsik@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3443 bytes --]

Here is a current view of it, IIRC:

https://forum.openwrt.org/t/rfc9330-rfc9331-rfc9332-for-lower-latency/180519/12

All the best,

Frank

Frantisek (Frank) Borsik



https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com


On Tue, May 7, 2024 at 10:03 PM Eugene Y Chang via Starlink <
starlink@lists.bufferbloat.net> wrote:

> I thought I saw a reference to an OpenWRT implementation with L4S. How
> well does that work?
>
>
>
> Gene
> ----------------------------------------------
> Eugene Chang
>
>
>
> On May 7, 2024, at 9:46 AM, Dave Taht <dave.taht@gmail.com> wrote:
>
> Pete heist, jon morton, and rod grimes published a TON of research as
> to where l4s went wrong in these github repos:
>
> https://github.com/heistp
>
> The last was:
> https://github.com/heistp/l4s-tests?tab=readme-ov-file#key-findings
>
> They were ignored. Me, I had taken one look at it 7+ years ago and
> said this cannot possibly work with the installed base of wifi
> properly and since 97E% of all home connections terminate in that it
> was a dead horse which they kept flogging.
>
> After the L4S RFCs were published they FINALLY took their brands of
> wishful thinking to actually exploring what happeed on real wifi
> networks, and... I have no idea where that stands today. Yes a custom
> wifi7 AP and presumably wifi8 will be able to deal with it, but
> everything from the backoff mechanisms in the e2e TCP Prague code and
> the proposed implementations on routers just plain does not work
> except in a testbed. Fq_codel outperforms it across the board with
> perhaps, some increased sensivity to RFC3168 seems needed only. L4S
> (all transports actually) benefits a lot from packet pacing, and...
> wait for it... fq)
>
> Slow start and convergence issues are problematic also with l4s.
>
> Being backward incompatible with fq_codel's deployed treatment of RFC3168
> ECN.
> is a huge barrier too.
>
> The best use case I can think of for l4s is on a tightly controlled
> docsis network, pure wires and short RTTs only. The one implementation
> for 5G I have heard of was laughable in that they were only aiming for
> 200ms of induced latency on that.
>
> If on the other hand you look at fq (and also how well starlink is
> performing nowadays) and ccs like bbr, well...
>
> I do honestly think there is room for this sort of signalling
> somewhere on the internet, and do plan to add what I think will work
> to cake at some point in the future. I do wish SCE had won, as it was
> backwards compatible.
>
>
> On Tue, May 7, 2024 at 12:15 PM Jeremy Austin <jeremy@aterlo.com> wrote:
>
>
>
>
> On Tue, May 7, 2024 at 11:11 AM Dave Taht via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>
> The RFC is very plausible but the methods break down in multiple ways,
> particularly with wifi.
>
>
>
> Dave, can you elaborate more on the failures? Are these being researched
> or addressed in the current trials, in your opinion?
>
> Jeremy
>
>
>
>
> --
> https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
> Dave Täht CSO, LibreQos
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 7534 bytes --]