More Accurate Explicit Congestion Notification (AccECN) Feedback in TCP
updates
- rfc-3168 — The Addition of Explicit Congestion Notification (ECN) to IP
Extracted elements (30)
AccECN deliberately overloads and replaces the Classic ECN flags (CWR, ECE) and the formerly reserved NS bit rather than adding feedback alongside Classic ECN. This reuses scarce TCP header space, avoids a protocol fork, eliminates conflicting feedback signals from both schemes, and is more likely to traverse middleboxes faithfully than newly defined header areas.
Counter initialization uses non-zero values (r.cep=5, r.e0b=r.e1b=1, r.ceb=0) to support stateless handshakes (SYN cookies) — values 0b000 and 0b001 in the ACE field on the ACK of the SYN/ACK signal that AccECN was not negotiated — and to distinguish normal operation from middlebox zeroing of the fields.
Two alternative AccECN Option orderings (Kind=172 and Kind=174) are defined so the receiver can place the most recently changed counter field first and truncate unchanged tail fields, reducing option space consumption. The 24-bit counter width was chosen to prevent rollover within a single TSO event while fitting within available TCP option space.
If the AccECN Option is stripped by a middlebox, AccECN degrades gracefully to CE-only feedback via the 3-bit ACE field. The design ensures the protocol remains functional without the option, though with reduced resilience against ACK loss and no ECT(0)/ECT(1) byte feedback.
TCP Proxies, transparent middleboxes, ACK filtering elements, TCP Segmentation Offload (TSO), and Large Receive Offload (LRO) engines each have specific AccECN compliance requirements in Section 3.3 concerning how they must preserve or translate the ACE field and AccECN Options.
When an AccECN TCP Client receives a SYN/ACK from a Classic ECN server (AE,CWR,ECE)=(0,0,1), it MUST fall back to Classic ECN feedback mode and comply with RFC 3168. When the server is not ECN-capable (0,0,0), ECN is disabled for the connection.
A Data Receiver MUST increment the CE packet counter (r.cep) for every Acceptable packet received with CE in the IP-ECN field, including CE-marked control packets and retransmissions, but excluding CE on SYN packets (SYN=1; ACK=0).
After AccECN negotiation, a Data Receiver MUST encode the 3 least significant bits of its r.cep counter into the ACE field on every ACK with SYN=0, except when the special handshake encoding applies on the ACK of the SYN/ACK. The LSB is at TCP header bit offset 9.
An AccECN Data Receiver MUST emit an ACK (Increment-Triggered ACK) if 'n' CE marks have arrived since the previous ACK: n SHOULD be 2 when unacknowledged data exists; otherwise n SHOULD be 3 and MUST be at least 3. In both cases n MUST NOT exceed 7.
An AccECN Data Receiver SHOULD emit a Change-Triggered ACK whenever a data packet marked CE arrives after the previous packet was not CE. This rule exists so the sender can detect queue growth as early as possible.
An AccECN implementation MUST NOT switch into a different feedback mode from the one it first entered per Table 2, regardless of subsequently received SYNs or SYN/ACKs. It MUST reset the connection with RST if it receives both a Classic ECN-setup SYN and an AccECN-requesting SYN during the same handshake.
If a TCP Server receives a SYN with (AE,CWR,ECE) not in {(0,0,0),(0,1,1),(1,1,1)} and lacks specific logic for that combination, it MUST negotiate AccECN as if the flags were (1,1,1). However, an AccECN Client MUST NOT send a SYN with any combination other than those three.
If an AccECN TCP Client receives a SYN/ACK with (AE,CWR,ECE)=(1,1,1) — indicating a broken server that reflects SYN flags — it MUST fall back to Not ECN mode for both its half-connections and continue with ECN disabled.
In AccECN mode, a Data Sender MUST NOT set CWR to indicate that it has received and responded to congestion indications, unlike an RFC 3168 sender. The continuously repeated counter approach replaces the CWR mechanism.
It is RECOMMENDED that AccECN be implemented alongside SACK (RFC 2018). If SACK is implemented with AccECN, D-SACK (RFC 2883) MUST also be implemented.
Once an AccECN TCP Client receives a SYN/ACK confirming AccECN support (one of the four combinations in Table 2), it MUST set both its half-connections into AccECN mode. The Client MUST NOT enter AccECN mode before receiving the first SYN/ACK.
To request AccECN feedback, a TCP Client MUST set the TCP flags (AE,CWR,ECE)=(1,1,1) in the initial SYN segment. An AccECN-enabled TCP Server that receives such a SYN MUST set both its half-connections into AccECN mode and MUST NOT set one of the four AccECN SYN/ACK combinations unless the preceding SYN requested AccECN.
When a TCP Client in AccECN mode uses a pure ACK with no SACK blocks to acknowledge the SYN/ACK, it MUST use the handshake encoding from Table 3 to feed back the IP-ECN field received on the SYN/ACK — the only exception to the standard ACE counter encoding rule on SYN=0 packets.
Section 8 addresses privacy considerations: AccECN feedback fields reveal congestion information on the path which could expose routing or network topology details to on-path observers, since the feedback is not encrypted in the TCP header.
Each Data Receiver maintains four counters: r.cep (CE packet count), r.ceb (CE byte count), r.e0b (ECT(0) byte count), and r.e1b (ECT(1) byte count). Byte counters reflect only TCP payload length, excluding TCP header and options.
The Accurate ECN (ACE) field is a 3-bit field formed by overloading the AE (bit 7), CWR (bit 8), and ECE (bit 9) flags in the TCP header once AccECN is negotiated. On non-SYN packets it carries the 3 LSBs of the CE packet counter r.cep from the Data Receiver.
The previously reserved NS (Nonce Sum) TCP header flag at bit offset 7 is renamed to AE (Accurate ECN). During the handshake it participates in ECN capability negotiation; after the handshake it forms the most significant bit of the 3-bit ACE counter field.
The TCP Server encodes the IP-ECN codepoint it received on the SYN into the (AE,CWR,ECE) bits of the SYN/ACK per Table 2, providing feedback of the SYN's IP-ECN field. This allows both endpoints to detect middlebox mangling of the ECN field during the handshake.
The previously reserved TCP header flag at bit offset 7 (formerly NS/Nonce Sum, reclassified as Historic in RFC 8311) is officially renamed to AE (Accurate ECN) and assigned to AccECN use.
Two new TCP Option Kinds are registered: AccECN0 with Kind=172 (field order: EE0B, ECEB, EE1B) and AccECN1 with Kind=174 (field order: EE1B, ECEB, EE0B). These options MUST NOT be used on TCP SYN segments.
AccECN provides mechanisms to detect middlebox mangling of the IP-ECN field by comparing the ECN field set on the SYN/SYN/ACK with what the peer fed back. Detection of invalid ECN transitions advises the sender to revert to non-ECN-capable packets while continuing to mechanistically feed back any markings it receives.
AccECN uses byte-based counters (r.ceb, r.e0b, r.e1b) to protect against ACK-Division attacks where a middlebox or receiver splits acknowledgements to artificially inflate the congestion window, following RFC 5681's recommendation to count acknowledged bytes rather than packets.
AccECN negotiation via the three-way handshake produces one of three feedback modes: AccECN mode, Classic ECN feedback mode, or Not ECN mode. The Client enters the mode indicated by the first SYN/ACK it receives per Table 2; the Server enters the mode indicated by the first SYN. Mode cannot change once entered.
AccECN0 Option (Kind=172, Length=11): three consecutive 24-bit fields in network byte order — EE0B (24 LSBs of r.e0b), ECEB (24 LSBs of r.ceb), EE1B (24 LSBs of r.e1b). Unchanged tail fields may be omitted; the Length field indicates which fields are present (minimum Length=3 for just EE0B).
AccECN1 Option (Kind=174, Length=11): same three 24-bit fields as AccECN0 but in reversed order — EE1B, ECEB, EE0B — allowing the receiver to select the ordering that places the most recently changed counter field first for efficient truncation.