On Mon, Jan 19, 2026 at 7:59 PM <[email protected]> wrote: > > From: Chia-Yu Chang <[email protected]> > > 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 <[email protected]>
