Re: [Cake] tossing acks into the background queue

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

On Tue, Nov 23, 2021 at 12:06 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>
> Hi Dave,
>
> On 23 November 2021 08:32:06 CET, Dave Taht <dave.taht@gmail.com> wrote:
> >The context of my question is basically this:
> >
> >Is cake baked? Is it done?
>
> How about per MAC address fairness (useful for ISPs and to treat IPv4/6 equally)?
>
> How about configurable number of queues (again helpful for ISPs)?

How about MPLS?

https://www.techtarget.com/searchnetworking/definition/Multiprotocol-Label-Switching-MPLS

>
> IMHO cake works pretty well, with the biggest issue being its CPU demands. As far as I understand however, that is caused by the shaper component and there low latency and throughput are in direct competition, if we want to lower the CPU latency demands we need to allow for bigger buffers that keep the link busy even if cake itself is not scheduled as precisely as we would desire or as e.g. BQL requires.
>
> Regards
>          Sebastian
>
> >
> >Is there anything from libreQos that would be better in C?
> >
> >On Mon, Nov 22, 2021 at 11:17 PM Dave Taht <dave.taht@gmail.com> wrote:
> >>
> >> On Mon, Nov 22, 2021 at 11:07 PM Sebastian Moeller <moeller0@gmx.de> wrote:
> >> >
> >> > Hi Dave,
> >> >
> >> >
> >> > On 23 November 2021 06:03:03 CET, Dave Taht <dave.taht@gmail.com> wrote:
> >> > >ages ago I'd (we'd? I really don't remember - forgive me if I've
> >> > >forgotten who actually leaned in on it) written a basic ack-filter in
> >> > >ebpf. this was before cake gained tc actions and my primary use for
> >> > >the tech was for asymmetric connections, and before the good
> >> > >ack-filter arrived, and I was (and remain) unfriendly to this level of
> >> > >dpi.
> >> > >
> >> > >That said, on a symmetric connection, deprioritizing pure acks to the
> >> > >5% background queue nd then turning the cake ack-filter loose on it
> >> > >might actually work.
> >> > >
> >> > >Am I on drugs/is there any point?
> >> >
> >> > I think at leat when using multiple priority tins forward and reverse traffic should by default use the same tin (I can see non-standard situations that want differential treatment). The argument is that unlike earlier attempts at ingress shaping that tried to throttle reverse ACKs? cake/codel do proper 'hit the brakes' signalling via marking/dropping and we want that signal to reach the other end as quickly as possible, no?
> >>
> >> My thought was basically an optional filter that steered all pure acks
> >> (no matter the classification) into the background queue.
> >> Non-pure-acks (sacks) essentially jump the background queue and signal
> >> that loss earlier. The backlog of other acks in background get
> >> delivered out of order, but purely out of order and discarded by the
> >> reciever.
> >>
> >> > Regards
> >> >         Sebastian
> >> >
> >> >
> >> > >
> >> > >
> >> > >
> >> > >--
> >> > >I tried to build a better future, a few times:
> >> > >https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> >> > >
> >> > >Dave Täht CEO, TekLibre, LLC
> >> > >_______________________________________________
> >> > >Cake mailing list
> >> > >Cake@lists.bufferbloat.net
> >> > >https://lists.bufferbloat.net/listinfo/cake
> >> >
> >> > --
> >> > Sent from my Android device with K-9 Mail. Please excuse my brevity.
> >>
> >>
> >>
> >> --
> >> I tried to build a better future, a few times:
> >> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> >>
> >> Dave Täht CEO, TekLibre, LLC
> >
> >
> >
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.



-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC