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

[Eugene Y Chang]

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 at 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 at aterlo.com> wrote:
>> 
>> 
>> 
>> On Tue, May 7, 2024 at 11:11 AM Dave Taht via Starlink <starlink at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240507/6ab761ef/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240507/6ab761ef/attachment.sig>