Summary

  • Successful validation says that sent ECN markings and peer-reported ACK_ECN counters are sufficiently consistent for congestion feedback on one path.
  • ECT(0), ECT(1), and ECN-CE counts are cumulative, separate by packet-number space, and must be interpreted with acknowledgment history.
  • The result does not name a queue, hop, router, interconnection, operator, duration, severity, SLA breach, or customer impact.

A dashboard that sees an ECN-CE increase may be tempted to put a red circle around a named interconnection. That is a category error. QUIC ECN validation answers a narrower operational question: can the sender use the peer's reported markings as congestion feedback on this path? It is not a location system or an attribution ledger.

A sender marks an IP packet ECT(0) or ECT(1). A network node may change that field to ECN-CE rather than drop the packet. A receiver able to inspect the field increments separate ECT(0), ECT(1), and ECN-CE counters and reports them in later ACK frames. When a validated path produces a new ECN-CE increase, RFC 9002 requires the specified congestion controller to enter recovery. That reaction is real, but it is a protocol reaction, not a diagnosis.

The accounting is easy to misread. QUIC keeps acknowledgment state and ECN counts separately for each packet-number space: Initial, Handshake, and 1-RTT. Coalesced QUIC packets share one IP header, so the packets in a coalesced datagram see the same IP ECN field; each successfully processed QUIC packet is nevertheless counted in its own packet-number space. Duplicate packets are not processed again and do not add to the counts. An ACK can therefore report a larger cumulative increase than the packets newly acknowledged in that ACK, because an earlier ACK may have been lost. A counter is not a rate, a path map, or a per-flow causal trace.

Validation is performed per network path. A new connection, a server preferred-address change, and active migration to a new path require the path to be treated separately. An endpoint can mark early packets on a new path with ECT(0), then compare acknowledgments and loss outcomes with the reported counters. If newly acknowledged ECT-marked packets have no ECN counts, validation fails; the field may have been zeroed, or the peer may not report it. For ECT(0), the increase in ECT(0) plus ECN-CE must not be smaller than the number of newly acknowledged packets sent as ECT(0). The analogous test applies to ECT(1).

Reported counts also cannot exceed the total packets sent with the corresponding codepoint, including a non-zero count for a codepoint never used. A reordered ACK that does not advance the largest acknowledged packet number must not by itself fail validation.

These checks test signal integrity, not identity. Failure cannot by itself distinguish bleaching, improper rewriting, peer non-reporting, loss, reordering, a path change, hostile manipulation, or another implementation fault. When validation fails, the endpoint disables ECN on that path and stops setting ECT, treating the path or peer as unsupported. It may later revalidate. Success permits continued marking; a changed path can later fail again.

The security boundary matters. Loss, delay, and ECN markings are signals from unauthenticated network entities. An attacker can alter sending rate by dropping packets, delaying traffic, or changing codepoints. A receiver can misreport markings: suppression can permit an excessive rate, while extra CE reports can make the sender reduce its rate. Validation provides useful checks, but it does not authenticate a queue, router, carrier, operator, or administrative domain.

The independent evidence ledger should therefore retain connection and current path identity; packet-number space and acknowledged ranges; each sent ECT(0), ECT(1), or Not-ECT marking; peer cumulative counts; counter deltas against the prior successfully processed ACK; validation state transitions; missing counts, impossible increases, loss, reordering, and path changes; and the congestion controller's response and recovery epoch. Interface, queue, hop, routing, and interconnection telemetry belong in a separate ledger, as do root cause, duration, severity, operator attribution, and customer impact.

ACK_ECN alone does not supply any of them.

This is distinct from TR-038 spin-bit sampling, which concerns an optional observer-visible RTT sample; TR-045 ACK delivery semantics; TR-050 receiver-reported ACK delay; and TR-051 PTO progress probing. ECN validation is endpoint feedback for congestion control, not passive latency sampling, application delivery proof, host-time measurement, or a packet-loss verdict.