More Accurate Explicit Congestion Notification (AccECN) Feedback in TCP#

Bob Briscoe (Independent), Mirja Kühlewind (Ericsson), Richard Scheffenegger (NetApp) — TCPM

• Why: RFC 3168 ECN feedback allows one congestion signal per RTT; DCTCP, L4S, and ConEx need per-marking counts. This changes the TCP wire protocol itself — and it is now finished: published as RFC 9768 (Proposed Standard, April 2026).
• What: AccECN replaces Classic ECN feedback: the receiver continually feeds back a count of CE-marked packets using the three TCP header flags (the former NS bit renamed AE, plus overloaded CWR/ECE) as a 3-bit ACE counter, negotiated in the three-way handshake with careful backward compatibility. An optional AccECN TCP Option (two alternative field orders, never on the SYN) supplements this with 24-bit byte counters per ECN codepoint.
• How: Two-part design — the essential header counter works even where middleboxes strip options; the option adds byte-accuracy and ACK-loss resilience. The receiver acts as a "generic (mechanistic) reflector" so future sender behaviors deploy unilaterally. It also feeds back the IP-ECN value received on the SYN/SYN/ACK, letting endpoints detect middleboxes that mangle the ECN/ToS field instead of blindly disabling ECN. Normative compliance requirements cover TCP proxies, normalizers, ACK filters, and offload engines.
• Where applicable: All TCP — public Internet and private networks including data centers; explicitly the enabler for DCTCP-style and L4S congestion control. Broadly applicable; as an RFC this is now implementation/deployment news rather than work-in-progress.