There seems to be a bug in the L4S kernel "testing" branch where when the server is configured with sysctl net.ipv4.tcp_ecn=0, a TCP server using cubic still uses RFC3168 ECN if the client offers AccECN.
In this case tcpdump traces show the server sending packets with code point ECT(0) and signaling its cwnd reductions with CWR.
In the test where I noticed this, the CMTS was not setting the CE code point, and the CWR signals were during fast recovery.
This is with the pre-built kernel linux-image-5.10.31-3cc3851880a1-prague-37_1_amd64.deb 👍
uname -a shows:
5.10.31-3cc3851880a1-prague-37 #1 SMP Tue Jun 29 07:47:18 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
There seems to be a bug in the L4S kernel "testing" branch where when the server is configured with sysctl net.ipv4.tcp_ecn=0, a TCP server using cubic still uses RFC3168 ECN if the client offers AccECN.
In this case tcpdump traces show the server sending packets with code point ECT(0) and signaling its cwnd reductions with CWR.
In the test where I noticed this, the CMTS was not setting the CE code point, and the CWR signals were during fast recovery.
This is with the pre-built kernel linux-image-5.10.31-3cc3851880a1-prague-37_1_amd64.deb 👍 uname -a shows:
5.10.31-3cc3851880a1-prague-37 #1 SMP Tue Jun 29 07:47:18 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux