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

[Dave Taht <dave.taht@gmail.com>]

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