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

[Eugene Y Chang <eugene.chang@ieee.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2801 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 6904 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]