Summary

  • RFC 9768 turns the TCP receiver into a generic reflector of congestion indications. It deliberately leaves congestion response to the data sender.
  • AccECN has two evidence paths: an essential three-bit ACE packet counter and supplementary 24-bit byte counters. Loss, wrap, option stripping and scarce header space affect them differently.
  • An operational conclusion therefore needs a reconstruction receipt: what was sent, what was acknowledged, which counters were available, what uncertainty remained and which sender-local action followed.

One missing acknowledgment

Suppose a sender receives ACE value six, then no acknowledgment for an interval, then value one. The modular increment could be three. It could also conceal another complete turn of the three-bit counter. Packet reordering may change which acknowledgment arrives first; delayed ACK policy changes the sampling rhythm; ACK filtering may remove intermediate states. The wire has returned useful evidence, but it has not returned an unambiguous history.

That is the right entry point to RFC 9768, More Accurate Explicit Congestion Notification (AccECN) Feedback in TCP. The standard improves the receiver-to-sender feedback defined for TCP ECN. It does not define a new congestion-control algorithm. It does not tell the receiver to throttle the sender. It does not prove which queue applied a Congestion Experienced codepoint. Its carefully narrower achievement is to transport more information about ECN markings back to the endpoint that sent the data.

This division of work is a governance decision embedded in a header. The receiver sees the incoming IP ECN field and counts acceptable packets. The sender knows which ECN-capable codepoints it transmitted, observes the returned counters and decides whether the report is internally consistent. The sender can then apply DCTCP, a scalable response, a conventional TCP response or some future behavior. The receiver need not be upgraded for every new sender algorithm.

The specification calls the receiver a generic mechanistic reflector. That phrase prevents a common analytical error. A reflector supplies evidence; it does not acquire authority over the action taken from that evidence.

What the standard changes—and what it does not

RFC 9768 was published on the Standards Track in April 2026. It updates RFC 3168’s TCP ECN negotiation and feedback. The earlier TCP mechanism can communicate no more than one congestion indication in a round trip, even when several packets were CE-marked. That was sufficient for a binary response model but not for algorithms that respond to the fraction or extent of marking.

AccECN replaces that bottleneck with counters. It is a wire-protocol change between the data receiver and sender. The congestion response is explicitly out of scope. A Standards Track document fixes interoperable behavior; it does not certify that a given kernel shipped it, that a middlebox preserved it, that a path marked correctly or that a chosen sender response produced a good service outcome.

That limitation is operationally productive. It tells an investigator to separate four layers: the rule in the RFC, the implementation’s claim, the packets observed and the inferred cause. Combining those layers into “AccECN reported congestion, so the network reduced the flow” destroys both technical and organizational accountability.

The essential path: three bits that keep speaking

AccECN reuses the three TCP ECN flags as the AccECN Counter, or ACE. After successful negotiation, those bits carry the low three bits of the receiver’s CE packet counter. The receiver repeatedly reports its current state rather than emitting a fragile one-time event. A later acknowledgment can therefore recover some information lost with an earlier ACK.

The ACE path is essential because it remains in the fixed TCP header. An optional TCP option can be stripped or crowded out; the ACE field is designed to keep returning a coarse packet count. This is graceful degradation, not perfect continuity. Three bits represent only eight states. The counter wraps often, so a sequence of missing acknowledgments can hide complete cycles.

Counting rules also matter. The CE packet counter covers acceptable CE-marked TCP packets, including control packets and retransmissions, apart from the SYN. It is not a unique-data counter. If an analyst compares ACE changes with application bytes as though both measured the same object, retransmissions and pure control traffic can create apparent contradictions.

RFC 9768 therefore constrains feedback frequency. A receiver must acknowledge often enough that too many CE marks do not accumulate unseen; the document gives tighter recommendations depending on unacknowledged data. When the richer option is absent and a wrap is plausible, the sender has to use a conservative interpretation. “More accurate” never means “independent of sampling.”

The supplementary path: larger byte ledgers

The AccECN option carries the low 24 bits of three payload-byte counters: bytes received with CE, ECT(0) and ECT(1). Those ledgers answer a different question from ACE. They count payload octets on acceptable packets, not packet events, and exclude TCP/IP headers and options. Retransmitted payload is counted again because the receiver is recording what arrived, not deduplicating the application stream.

Twenty-four bits make a complete unseen wrap implausible across a normal interval of missing acknowledgments. The byte path is consequently more resilient to ACK loss and better suited to algorithms that care about marked proportions. But it lives in option space, where resilience is political as well as mathematical. SACK blocks compete for the same scarce bytes. Middleboxes may remove unfamiliar options. Offload engines may aggregate traffic before the host’s accounting point. A path can pass the option at setup and suppress it later, or the reverse.

RFC 9768 defines more than one option form and allows the receiver to repeat current low-order values. The sender establishes baselines and computes modular differences. It must never treat the byte option as a replacement for ACE. The two paths are designed to be reconciled: one is durable but coarse, the other informative but conditional.

When option space cannot hold the minimum AccECN option together with two SACK blocks, loss information wins. That priority is revealing. A protocol that exists to improve congestion evidence still yields space to evidence needed for loss recovery. The header is a budget, not a blank canvas.

Negotiation is part of the evidence

AccECN capability is negotiated through AE, CWR and ECE combinations in the three-way handshake. The initiating SYN uses a defined pattern; the server’s response reports both support and what it observed on the SYN. Older endpoints fall back to classic ECN or no ECN. Certain reflected or invalid combinations are treated as evidence of a broken path, not as permission to assume success.

The AccECN option itself is not sent on the initial SYN because SYN option space is especially constrained. Its passage is tested on the SYN/ACK and the first ACK. That creates two related but distinct receipts: AccECN negotiation may succeed while the supplementary option is unavailable.

Initial counter values are intentionally nonzero. They help stateless handshake processing and make systematic zeroing visible. Yet an implementation must not insist on one exact valid initial value; doing so would turn spare protocol states into permanent debt. Reordering can also make the first post-handshake ACE appear to be zero legitimately. A simplistic “zero means mangling” rule would reject good connections.

This is Heng Lu’s minimum-initial-specification principle in protocol form. Specify enough to interoperate and expose failure, but leave future decisions local when they do not need global agreement. The sender can evolve its response unilaterally because the receiver’s duty remains mechanical.

When the path edits the testimony

ECN fields can be bleached, zeroed or changed in either direction. TCP options can be stripped. Proxies can terminate one half-connection and originate another. ACK filters can remove samples. GRO or LRO can coalesce arrivals before software observes them. None of these effects grants the receiver a better view of the sender’s original intent.

The data sender is therefore best placed to validate feedback. It knows whether it sent ECT(0), ECT(1) or Not-ECT and can compare that history with ACE and byte-counter changes. The receiver reflects the codepoints on acceptable packets; it should not invent a diagnosis for an inconsistency it cannot see end to end.

RFC 9768 requires the sender to reconcile the essential and supplementary paths. If the CE byte count advances in a way that cannot be reconciled with the packet counter and no legitimate explanation remains, the sender may disable ECT for that half-connection. This is a local safety choice. The response protects the connection without requiring a global verdict about which device altered the evidence.

Half-connection is the right granularity. TCP data can flow both ways, and the path or implementation behavior can be asymmetric. Recording only a connection-wide label such as “AccECN enabled” erases which sender negotiated, which receiver counted and which direction lost trustworthy feedback.

A mark count is not a queue diagnosis

CE means that an ECN-capable packet arrived carrying the Congestion Experienced codepoint. It does not encode queue length, marking threshold, device identity, operator ownership or application damage. Several network mechanisms can produce the same codepoint under different policies. A retransmission can cause the receiver’s packet and byte ledgers to move differently from unique delivered data.

Nor does the count prescribe one response. DCTCP uses marking extent differently from classic TCP; L4S defines a scalable signaling environment; future controllers may interpret a series with still different time constants. AccECN’s value is precisely that the feedback format does not bind the receiver to those algorithms.

An incident report should therefore resist the sentence “the receiver detected congestion and slowed the sender.” The receiver counted what it received. The sender interpreted a reconstructed series and selected a response. If throughput later fell, the causal account also needs congestion-control state, application demand, loss, pacing, receive limits and path observations.

The operational receipt

A useful AccECN record begins at the handshake. Preserve the flags transmitted and returned, the negotiated mode and any evidence of ECN-field or option mangling. For each data direction, record sent IP-ECN codepoints, ACE observations, modular deltas, byte-counter baselines and changes, ACK sequence and timing, option form and availability, SACK pressure and invalid-segment filtering.

Then preserve the reconstruction judgment. Was a full ACE wrap plausible? Were acknowledgments lost, delayed, reordered or filtered? Did the byte counters remain available? Did ACE and the option agree after accounting for control packets, retransmissions and payload units? Did offload or proxying change the observation point? Which uncertainty rule did the sender apply?

Finally record the local action separately: ECT disabled or retained, congestion-controller state changed or unchanged, rate or window adjustment, and the implementation version that made the decision. Independent queue telemetry, packet capture, throughput and application latency belong beside this receipt, not inside the counter’s meaning.

Adversarial tests should remove individual ACKs, hide more than one ACE cycle, reorder the first acknowledgment, strip the option after negotiation, crowd it with SACK, zero handshake bits, alter ECN fields in one direction, coalesce packets and inject unacceptable segments. The pass condition is not that every case yields full precision. It is that the endpoint degrades explicitly, preserves the essential path where possible and never turns missing evidence into false certainty.

Sources