[Ecn-sane] [Cake] l4s kernel submission

[Dave Taht]

On Thu, Oct 14, 2021 at 2:44 PM Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>
> Dave Taht <dave.taht at gmail.com> writes:
>
> > weirdly enough, my gmail account has not received anything from netdev
> > since oct 11.
>
> You're not alone in that:
> https://lore.kernel.org/netdev/20211014112718.6aed7f47@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/T/#t

ok. One of these years I'll go back to running my own email server full time.

> > yes, i think fq_codel will be better, and even the proposed
> > too-shallow threshold will make for less of a dent on the internet.
> >
> > still... I do wish I'd seen this earlier.
>
> Earlier? You forwarded the patch hours after it was posted...

I have a daily search for fq_codel, bufferbloat, etc. I have noticed
lately that some mailing list traffic from us is being indexed again.
I wish I knew why our lists were not indexed by google.

Anyway, lacking being on that thread, it's currently impossible to
reply. I would certainly like more to be exploring HFCC - I do agree
that a shallow marking threshold is increasingly necessary at rates
beyond 10Gbit, and that more would read -
https://github.com/heistp/l4s-tests#key-findings before the internet
is split into a fast and slow lane.

That said, the l4s fq_codel patch is intrinsically fair, which is
vastly superior to the dualpi approach.

I think that the over-shallow proposed threshold of 50us - the lowest
I'd seen to date was 250us! won't work on anything other than bare
iron or from a self-local qdisc, and that will lead to the
implementation being naturally slow rate on virtualized hosts, but
lossless, which would be
a win, and for all I know interact well with the fast/slow queue concept.

I certainly think bbrv2 needs more testing, as it has always seemed to
be a more promising approach than prague.

My biggest feedback on the patch so far is I dislike the overload on
reporting where the CE came from, and would prefer that l4s_ce be
exposed to userspace. We have very little data on actual ce's in the
field as it is - conflating the two statistics won't help -

I also hate adding anything more to the hot path. And if we have to do
it, making sce available as an optional at the same time has the same
computational cost.

And it still bugs me, very much, that bbrv1 has no rfc3168-like response.

Perhaps with some time to work on a coherent reply to this patch and
figuring out how to get back on netdev,
I can say all that better. Or I can just go back to fixing up my boat.

>
> -Toke



-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC