Summary

  • Under classic RFC 3168, a TCP receiver continues to set ECE on acknowledgements after seeing CE until a new data packet carrying CWR arrives.
  • Several ECE-bearing ACKs can therefore arise from one CE observation; they are a durable feedback state, not a packet-for-packet congestion counter.
  • Connection setup uses ECE and CWR for capability negotiation, while tunnels, ACK loss and experimental ECN variants further limit what a raw flag count can prove.

One mark, an interval of echoes

The misleading graph is easy to imagine. A monitor sees one acknowledgement with ECE, then another, then five more. Its counter rises seven times, and an incident report quietly changes “seven packets carried the flag” into “seven congestion events occurred.” RFC 3168 defines a different object.

In the established data phase, an ECN-capable receiver notices the Congestion Experienced codepoint on an arriving data packet and sets ECE in its acknowledgement. If a delayed acknowledgement covers several packets and any of them was CE-marked, that ACK carries ECE. The receiver then keeps setting ECE on subsequent ACKs—even when those later ACKs correspond to unmarked data—until it receives CWR from the sender.

This persistence is not a defect in the signal. An acknowledgement can disappear. A one-shot echo would let a lost return packet erase a congestion indication. The repeated flag holds the receiver’s state open long enough for the sender to see it and respond. The useful unit is therefore an ECE interval: an opening observation, a run of asserted acknowledgements and a closing response.

CWR is the closing receipt

The sender’s side completes the handshake. Under the classic algorithm, an ECE indication causes a congestion response comparable to the response to a loss signal. The sender should reduce its congestion window no more than once for a series of loss or CE indications in one window of data—roughly one round-trip time—rather than shrinking it for every ECE-bearing ACK.

After making that reduction, the sender sets CWR on the first new data packet it transmits. RFC 3168 advises against placing that indication on a retransmission. When the receiver obtains the new CWR-bearing packet, it stops setting ECE on acknowledgements for later unmarked packets. A new CE observation can start another interval.

Even this receipt has a boundary. If the new packet carrying CWR is lost, the receiver’s ECE state remains visible and a later sender response can produce another CWR. That behaviour is precisely why a capture can contain repeated ECE without repeated queue marks. Receipt of CWR supports the proposition that the sender reacted after the relevant data was sent; it does not prove delivery of one particular ECE ACK or locate the marking queue.

The same bit changes meaning at setup

Packet phase matters before any count begins. During ECN setup, an initiating TCP sets both ECE and CWR on its SYN to request ECN-capable operation. A capable peer answers with ECE set and CWR clear on the SYN-ACK. Here the flags negotiate a capability. The ECE on that response is not an echo of congestion experienced by the SYN.

A field extractor that discards SYN state and retains only “ECE=true” mixes negotiation with established-flow feedback. It can manufacture a congestion event at the birth of every ECN-capable connection. Nor does a successful negotiation prove that every later outbound packet will be sent with an ECN-capable codepoint. The evidentiary record needs the connection phase, full flag combination and direction.

Pure acknowledgements add another limit. In classic RFC 3168 they are sent Not-ECT, so the same mechanism does not report congestion on the ACK path. The stream of ECE flags describes receiver state created by forward-path data observations; it is not a symmetric census of congestion in both directions.

A mark is not a queue biography

RFC 7567 explains that active queue management can ECN-mark instead of drop when congestion is mild or moderate, and can act before a queue is full. A CE observation therefore does not establish buffer overflow, packet loss, a particular delay or one device’s threshold. Those are separate claims requiring separate measurements.

Tunnels complicate location further. A forwarding element inside a tunnel may see and mark only the outer header. RFC 6040 defines how tunnel endpoints combine inner and outer ECN fields when congestion information is propagated. An endpoint’s ECE state can thus originate from a CE mark that crossed an encapsulation boundary. The feedback is real while the location remains unresolved.

RFC 5681 supplies a useful contrast. Duplicate ACKs have their own definition and can arise from loss, reordering or replication. They are not interchangeable with repeated ECE. A sound trace analysis keeps acknowledgement number, sequence space, retransmission, ECE, CWR and timing as distinct fields rather than letting one counter stand for all of them.

Finally, RFC 8311 permits documented experiments to relax parts of RFC 3168 and explore different marking or sender responses. The latch described here is the classic RFC 3168 contract, not a universal decoder for every ECN experiment or transport.

Sources