[Cake] tossing acks into the background queue

[Sebastian Moeller]

Hi Dave,

On 23 November 2021 08:17:38 CET, Dave Taht <dave.taht at gmail.com> wrote:
>On Mon, Nov 22, 2021 at 11:07 PM Sebastian Moeller <moeller0 at gmx.de> wrote:
>>
>> Hi Dave,
>>
>>
>> On 23 November 2021 06:03:03 CET, Dave Taht <dave.taht at 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.

Mmmh, not sure whether all connections actually use SACK in the first place?
I am always a bit uneasy when networks try to be clever, if we think that ACK rates are too high, IMHO we should teach the ACK emitters to slow down. Sure, ACK filtering as in cake is a valuable tool if used judiciously in a home network (after all fixing the emitters is not going to happen overnight) but I would appreciate it much less if my ISP would by the same logic fuzz with my packets. (I grudgingly accept that GEO satellite ISPs might have to do some fuzzing with RTTs so much outside of what normal TCPs are prepared for, but I degress)

Regards
         Sebastian



>
>> 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 at lists.bufferbloat.net
>> >https://lists.bufferbloat.net/listinfo/cake
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.