Summary
- ECN did not abolish packet loss. It gave an active queue a less destructive congestion signal for packets whose endpoints had declared that they could respond.
- The mechanism is a closed control loop: a sender declares capability, a router marks congestion, a receiver echoes the evidence, and the sender reduces load. A break at any boundary converts an explicit signal into decoration.
- The path from RFC 2481 to RFC 3168, tunnel rules, experimental relaxation and L4S shows that the hard problem was never the scarcity of bits. It was preserving one meaning across independently operated systems.
Before the mark, the queue had to hurt
Congestion control first learned to listen to absence. A packet entered the network and, if a queue overflowed, failed to arrive. The sender inferred pressure from that loss and backed off. That feedback helped avert congestion collapse, but it made impairment do two jobs at once: damage the transfer and report the condition that caused the damage.
RFC 2309, published in April 1998, described why the familiar tail-drop queue was a poor witness. It waited until the buffer was full. By then, bursts could lose several packets together, flows could synchronize their retreat, and the standing queue itself could add delay. The document recommended active queue management: routers should act before overflow, keep average queues shorter and expose persistent congestion earlier.
Early action still needed a language. Dropping a packet before the buffer was full was an earlier signal, but it remained a loss. ECN’s proposal was more precise: if the transport said it understood explicit notification, an active queue could change a codepoint on the packet rather than discard it. The packet would carry evidence of the queue it had crossed.
That is the historical mechanism in one sentence. A network that had used destruction as testimony acquired a way to attach testimony to an intact object.
Four states, not a magic bit
RFC 3168, issued on the Standards Track in September 2001, defines four codepoints in the two-bit ECN field. Not-ECT says the transport has not declared ECN capability. ECT(0) and ECT(1) identify ECN-capable transport under the document’s original semantics. CE means Congestion Experienced.
Those names can make ECN sound like a router feature. It is not. The router performs the visible edit, but the mechanism needs at least three cooperating roles and, in TCP, an explicit exchange of state.
The sender first negotiates or otherwise establishes that the transport can respond. It then places an ECN-capable indication on packets. A router running an active queue management rule may set CE on an ECN-capable packet at the point where it would otherwise have used loss as a congestion indication. The receiver reports that evidence back. The sender reduces its congestion window and acknowledges that response so the receiver does not indefinitely repeat an old indication as if it were new.
This division matters. The router knows about its queue but not the application’s complete control state. The receiver sees the marked packet but does not set the sender’s offered load. The sender controls the rate but did not observe the bottleneck directly. ECN works by moving a small, verifiable observation across those boundaries.
It also retains loss. A Not-ECT packet cannot be safely converted into an explicit signal its transport never promised to understand. Severe congestion can still require dropping packets. Corruption, route failure and policing do not disappear because the ECN field exists. The factual claim is narrower: for eligible traffic under the specified conditions, marking can replace a congestion-indicating drop.
That narrowness is a strength. It prevents the attractive but false story that two bits make queues harmless.
From proposal to contract
RFC 2481 appeared as an Experimental proposal in January 1999. RFC 3168 obsoleted it two years later and incorporated ECN into IP and TCP behavior. The move from experiment to Standards Track did not merely bless a field allocation. It specified negotiation, feedback, sender response, interaction with IP security and coexistence with traffic that did not use ECN.
Incremental deployment shaped the design. A sender could not assume every peer or path preserved the signal. A router could not assume every packet was eligible to be marked. A receiver could not silently reinterpret ordinary TCP flags. The protocol therefore had to make capability observable and preserve fallback to loss.
This history offers an operational lesson. Backward compatibility is not an abstract courtesy to old equipment. It determines whether an early adopter can deploy without transferring new risk to everyone else. ECN’s fallback kept the pre-existing signal—drop—available while a more informative signal was introduced.
The inference is that deployment success cannot be counted at only one layer. An operating system may enable ECN, but a bottleneck may never mark. A router may mark, but a tunnel may erase the indication. A path may preserve CE, but the endpoint may not respond as intended. Product checkboxes count components; the control loop counts outcomes.
The nonce and the problem of honest feedback
Explicit notification created a new question: what if a receiver concealed marks to avoid making its sender slow down? RFC 3540, published as an Experimental RFC in June 2003, proposed an ECN nonce. The sender varied the ECT codepoint and used the returned sum as a check on whether congestion feedback had been faithfully reported.
The experiment is useful even though it did not become the enduring use of ECT(1). It made the incentive problem visible. A congestion mark asks one endpoint to reduce its own rate for the stability of a shared resource. The network can provide evidence, but cooperation cannot simply be presumed.
In January 2018, RFC 8311 changed RFC 3540 to Historic and relaxed several restrictions on ECN experimentation. That decision freed ECT(1) for other experimental semantics. The bit did not become blank by administrative declaration; the IETF first had to close the earlier claim on its meaning.
This is a recurring feature of protocol history. Scarce fields acquire institutional memory. Reuse requires more than a clever new scheme. It requires an account of the old scheme, a safe boundary for the new one and a transition that makes ambiguity observable.
Tunnels and the custody of evidence
A congestion mark can cross an encapsulation boundary. An inner packet is wrapped in an outer header, carried through a tunnel, then recovered. If the outer path experiences congestion, the tunnel endpoints must decide how that evidence affects the inner packet. If they simply discard the outer ECN state, the decapsulated packet emerges with a falsely clean history. If they combine states incorrectly, they can manufacture a signal that the path did not produce.
RFC 6040, published on the Standards Track in November 2010, updates the rules for ECN tunnelling. Its tables and modes are technical, but their purpose is legible: encapsulation and decapsulation must preserve congestion meaning across layers while handling legacy behavior safely.
This is a fact about packet processing and, by inference, a rule about the custody of operational evidence. The tunnel ingress chooses what the outer header says. The tunnel path may mark it. The egress reconciles outer and inner state. Each actor can preserve, bleach or distort what the previous actor observed.
For operators, that makes the tunnel a measurement boundary. “ECN enabled” on two endpoints does not prove that a VPN, mobile core, data-centre overlay or inter-provider tunnel carries the signal correctly. The unknown must remain path-specific until it is measured.
Permission to experiment was not permission to pretend
RFC 4774, a Best Current Practice document from 2006, addresses alternate semantics for the ECN field. It does not treat the codepoints as an ungoverned extension space. A different use needs a way to identify its traffic, coexist with established ECN and bound the risks of partial deployment.
RFC 8311 later relaxed specific RFC 3168 restrictions so controlled experiments could depart from the classic rule that a mark should be treated as equivalent to a drop. The wording matters. Relaxation makes experiments possible; it does not certify every new response on every network.
That distinction becomes central in the Low Latency, Low Loss and Scalable Throughput architecture published in January 2023. RFC 9330 describes the architecture. RFC 9331, Experimental, identifies L4S traffic with ECT(1) and uses CE for frequent congestion feedback under new semantics. RFC 9332, also Experimental, specifies a Dual-Queue Coupled AQM framework.
L4S is not merely classic ECN with a lower threshold. Its scalable congestion controls are expected to react to frequent marks without treating each one as a classic loss-equivalent event. The network isolates low-latency treatment from the standing delay of classic traffic, while coupling congestion indications so the two queues share capacity. RFC 9330 describes this as separating latency rather than granting a simple bandwidth priority.
The architecture is deliberately multipart: a compatible sender response, a bottleneck queue treatment and an identification protocol. ECT(1) alone delivers none of the promised outcome. A sender that claims the identifier without the compatible response is not using a fast lane; it is breaking the bargain on which coexistence depends.
What the record proves—and what it does not
The RFC sequence proves that ECN evolved through explicit stages: active queue management motivated an earlier signal; an experiment became a Standards Track mechanism; feedback integrity was tested; alternate semantics and tunnels received rules; restrictions were relaxed for new experiments; and L4S reused the field inside a broader architecture.
The record does not prove that ECN is preserved on most Internet paths in 2026. It does not disclose which middleboxes bleach the field. It does not show that every enabled endpoint responds correctly, that every bottleneck runs useful AQM, or that L4S will become the universal low-latency service. Those are deployment and measurement questions, not conclusions that can be extracted from an RFC category.
The durable achievement is more modest and more important. ECN separated evidence of congestion from the destruction of the packet carrying that evidence. It then forced the Internet’s independently controlled components to state who may create the evidence, who must relay it and who must act.
The packet survives. The obligation does not become lighter.
Sources
- RFC 2309 — Recommendations on Queue Management and Congestion Avoidance
- RFC 2481 — A Proposal to add Explicit Congestion Notification (ECN) to IP
- RFC 3168 — The Addition of Explicit Congestion Notification (ECN) to IP
- RFC 3540 — Robust Explicit Congestion Notification (ECN) Signaling with Nonces
- RFC 4774 — Specifying Alternate Semantics for the Explicit Congestion Notification Field
- RFC 6040 — Tunnelling of Explicit Congestion Notification
- RFC 8311 — Explicit Congestion Notification Experimentation
- RFC 9330 — L4S Internet Service: Architecture
- RFC 9331 — The ECN Protocol for L4S
- RFC 9332 — Dual-Queue Coupled AQM for L4S
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
