On Tue, Nov 23, 2021 at 12:06 AM Sebastian Moeller <moell...@gmx.de> wrote: > > Hi Dave, > > On 23 November 2021 08:32:06 CET, Dave Taht <dave.t...@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.t...@gmail.com> wrote: > >> > >> On Mon, Nov 22, 2021 at 11:07 PM Sebastian Moeller <moell...@gmx.de> wrote: > >> > > >> > Hi Dave, > >> > > >> > > >> > On 23 November 2021 06:03:03 CET, Dave Taht <dave.t...@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 _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
