Why architecture matters here
The reason ECN is an architecture question and not just a tuning knob is that it changes what a full queue means. Under loss-based control, the network needs queues to fill and overflow in order to communicate — the drop is the message. That couples throughput to latency: to keep the pipe full you must keep the queue near full, and a near-full queue delays every packet. This is bufferbloat in one sentence. ECN decouples the two by providing a congestion signal that does not require the queue to overflow, so the network can run at high utilization and low delay simultaneously, which loss-based control cannot do.
The second reason is the cost of the signal itself. A dropped packet is not free: it must be detected (often by waiting for duplicate ACKs or a timeout) and retransmitted, costing at least one extra round-trip and the bandwidth of resending. For a short flow — a web request, an RPC — a single loss can dominate the total completion time, because the retransmit round-trip is a large fraction of the whole transfer. An ECN mark costs nothing to the data: the packet arrives, the application gets its bytes on time, and only the sender's future rate is adjusted. The signal is delivered without penalizing the flow it is signaling.
Third, timing. A router doing active queue management can mark ECN-capable packets early, when the queue length crosses a low threshold, rather than waiting until it is full enough to force drops. Early marking means the sender learns of building congestion while there is still headroom, so it can trim its rate smoothly instead of reacting to a cliff. This proactive quality is why AQM schemes pair naturally with ECN: the AQM decides when congestion is building, and ECN lets it say so without discarding data.
Fourth, ECN is what makes ultra-low-latency transport feasible at scale. DCTCP in datacenters and L4S on the internet both depend on being able to mark a large fraction of packets and have senders respond proportionally to the marking rate. You cannot do that with drops — dropping a large fraction of packets would destroy throughput. Only a non-destructive signal can be applied frequently enough to give the fine-grained feedback these controllers need to hold queues at a few packets while staying fully utilized.
Finally, ECN matters because it is an end-to-end contract that requires cooperation across layers and vendors, which is exactly why it took so long to deploy and why understanding its architecture is practical rather than academic. The sender must mark packets ECT, every router on the path must preserve and optionally set CE, and the receiver must echo it — and any middlebox that clears or mangles the bits silently breaks the loop. The history of ECN is a history of that fragile cooperation, and deploying it well means understanding where each piece can fail.
The architecture: every piece explained
The IP-layer signaling uses the two least-significant bits of the old Type-of-Service byte (now the Traffic Class field). Four code points: 00 Not-ECT marks a packet from a non-ECN transport, which routers must drop rather than mark; 10 ECT(0) and 01 ECT(1) both declare the transport ECN-capable; and 11 CE is set by a router to mean Congestion Experienced. The two ECT code points exist partly to let a sender detect whether the network is faithfully preserving the marks (a receiver echoing the wrong ECT can reveal mangling) and are used by L4S to distinguish traffic classes.
The sender is responsible for marking outbound packets ECT (so routers know they may mark rather than drop) and for reacting to echoed congestion. In TCP this reaction is a window reduction identical to the response to a loss under classic ECN: on receiving an ECE, the sender halves its congestion window and sets CWR on its next segment to acknowledge that it has responded, which stops the receiver from echoing the same event repeatedly. Under DCTCP/L4S the reaction is instead proportional to the running fraction of marked packets, giving a gentler, more precise adjustment.
The router with active queue management is where the congestion decision is made. As its queue builds past a configured threshold, instead of dropping an arriving ECT packet it flips the code point to CE and forwards it. A well-tuned AQM (CoDel, PIE, or the dual-queue coupled AQM used by L4S) marks with a probability that rises as the queue grows, so the aggregate marking rate across a flow's packets encodes how congested the path is. Critically, the router only marks ECT packets; a Not-ECT packet in the same queue is dropped, because its sender did not opt in.
The receiver closes the loop by reflecting the signal. When it receives a segment with CE set, it must tell the sender, which in classic TCP it does by setting the ECE flag on returning ACKs until the sender confirms with CWR. Because an ACK can itself be lost, the receiver keeps echoing ECE until it sees CWR, making the notification reliable despite an unreliable reverse path. More modern variants (AccECN) echo a count of CE marks rather than a single bit, so the sender learns the exact marking rate needed for proportional control.
Around these sits negotiation. ECN is opt-in per connection: during the TCP handshake the endpoints set ECN-related flags in SYN and SYN-ACK to agree that both support it; only then does the sender start marking packets ECT. If either endpoint or a middlebox declines or strips the negotiation, the connection falls back to plain loss-based behavior. This handshake is what makes ECN safely incremental — a connection uses it only when the whole path agrees. The diagram below traces the IP code points, the TCP flags, and the sender/router/receiver roles through a single congestion event.
End-to-end flow
Follow one congestion event. Two ECN-capable hosts complete a TCP handshake in which both advertise ECN support, so the sender begins stamping every data packet with ECT(0) in the IP header — an invitation to any router on the path to mark rather than drop it.
Traffic ramps and an intermediate router's queue starts to build. Its active queue management notices the queue crossing its marking threshold. The next ECT-marked packet to arrive is not dropped; the router rewrites its code point to CE and forwards it downstream. From the data's perspective nothing bad happened — the bytes are intact and arrive normally — but the packet now carries a congestion stamp.
The receiver delivers the data to the application and, seeing CE, sets the ECE flag on the acknowledgments it sends back. It will keep setting ECE on subsequent ACKs until the sender signals that it has heard, which protects the notification against a lost ACK on the reverse path — the signal is idempotent and repeated rather than fire-and-forget.
The sender receives an ACK with ECE. It treats this as a congestion indication and reduces its congestion window — under classic ECN, the same multiplicative decrease it would apply to a loss, but without any retransmission because no packet was actually lost. On its next outgoing segment it sets the CWR flag, telling the receiver 'I got your congestion signal and have responded,' which lets the receiver stop echoing ECE for this event.
The net effect is a full congestion-control cycle completed without a single dropped or retransmitted packet: the queue was prevented from overflowing, the sender slowed down before latency spiked, and application data flowed uninterrupted. Under an L4S deployment the same loop runs continuously and at fine grain — the router marks a rising fraction of packets as the queue grows, the receiver reports the CE count, and the sender adjusts its rate proportionally, holding the queue at a handful of packets while staying near full utilization. That is the difference ECN makes: congestion becomes a smooth, cheap, early-arriving signal instead of a destructive, late one.