Thread (36 messages) flat view 36 messages, 4 authors, 2026-01-21

Re: [PATCH v9 net-next 06/15] tcp: accecn: handle unexpected AccECN negotiation feedback

From: Eric Dumazet <edumazet@google.com>
Date: 2026-01-20 10:18:40
Also in: bpf, linux-doc, linux-kselftest

On Mon, Jan 19, 2026 at 7:59 PM [off-list ref] wrote:
From: Chia-Yu Chang <redacted>

According to Section 3.1.2 of AccECN spec (RFC9768), if a TCP Client
has sent a SYN requesting AccECN feedback with (AE,CWR,ECE) = (1,1,1)
then receives a SYN/ACK with the currently reserved combination
(AE,CWR,ECE) = (1,0,1) but it does not have logic specific to such a
combination, the Client MUST enable AccECN mode as if the SYN/ACK
confirmed that the Server supported AccECN and as if it fed back that
the IP-ECN field on the SYN had arrived unchanged.
I find this a bit confusing.

3.1.2 has :

An AccECN implementation has no need to recognize or support the Server
response labelled 'Nonce' or ECN-nonce feedback more generally , as RFC 3540
has been reclassified as Historic . AccECN is compatible with alternative
 ECN feedback integrity approaches to the nonce (see Section 5.3).
 The SYN/ACK labelled 'Nonce' with (AE,CWR,ECE) = (1,0,1) is reserved
for future use.
A TCP Client (A) that receives such a SYN/ ACK follows the procedure
for forward compatibility given in Section 3.1.3.

The relevant section in the RFC is 3.1.2 _and_ 3.1.3 ?

Honestly, AccECN is way too complex for my taste :/

Please copy/paste the precise RFC parts, it will help future maintenance.

Reviewed-by: Eric Dumazet <edumazet@google.com>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help