Now that Linux 7.0 is switching AccECN to ON by default, would this have any implication for how CAKE or SQM in general works?
But I know full well that it will probably take ages for this trickle down to both endpoints and servers so there would be plenty of time.
I recall back in the past there was a discussion on SCE vs AccECN, but I haven't caught up in that in a while.
But from what I can tell, the CAKE's ack-filter is already defensively coded:
/* 3 reserved flags must be unset to avoid future breakage
* ACK must be set
* ECE/CWR are handled separately
* All other flags URG/PSH/RST/SYN/FIN must be unset
* 0x0FFF0000 = all TCP flags (confirm ACK=1, others zero)
* 0x00C00000 = CWR/ECE (handled separately)
* 0x0F3F0000 = 0x0FFF0000 & ~0x00C00000
*/
if (((tcp_flag_word(tcph) &
cpu_to_be32(0x0F3F0000)) != TCP_FLAG_ACK))
return false;
--------------------------------------------------------------
/* If the ECE/CWR flags changed from the previous eligible
* packet in the same flow, we should no longer be dropping that
* previous packet as this would lose information.
*/
if (elig_ack && (tcp_flag_word(tcph_check) &
(TCP_FLAG_ECE | TCP_FLAG_CWR)) != elig_flags) {
elig_ack = NULL;
elig_ack_prev = NULL;
num_found--;
}
--------------------------------------------------------------
/* We made it through the queue without finding two eligible ACKs. If
* we found a single eligible ACK we can drop it in aggressive mode if
* we can guarantee that this does not interfere with ECN flag
* information. We ensure this by dropping it only if the enqueued
* packet is consecutive with the eligible ACK, and their flags match.
*/
if (elig_ack && aggressive && elig_ack->next == skb &&
(elig_flags == (tcp_flag_word(tcph) &
(TCP_FLAG_ECE | TCP_FLAG_CWR))))
goto found;