The run did not exercise this test: no ECN counts came back at all. §13.4.1 requires reporting only where the ECN field is accessible, and a path that stripped the codepoint cannot be told apart from a client that does not report.
The suite could not establish what this client does here. That is a shortcoming of the run rather than anything about the client, and every one of these is on our list to remove.
What was measured
- Client
- neqo — neqo (Firefox), 0.31.1
- Test
- Path marking packets CE, not just ECT(0) —
q-ecn-congestion - Clause
- RFC 9000 §13.4 (MUST)
- Class
- correctness — Rejected something invalid, with the code the RFC names.
- Required behaviour
- Report the CE count back in the ECN section of an ACK. §13.4.1 makes this the same conditional requirement as reporting ECT(0) — an endpoint MUST provide feedback about the markings it receives "if these are accessible" — and CE is the marking that matters, since it is how a path says it is congested. Distinct from the ECT(0) test on the neighbouring port: that one asks whether a client reports markings at all, and this asks whether it distinguishes the one that means something. A client that echoes ECT(0) counts faithfully and never reports a CE has a congestion signal it cannot see. Silence is inconclusive, not a failure, for the same reason: the ECN field may be inaccessible to the peer, and a path that rewrites the codepoint in transit is indistinguishable from here.
- Measured
- 2026-09-18
Reproduce it
The suite is the judge, so the reproduction is to point the same client at the same test and let the server report what it saw.
SESSION=$(curl -sX POST https://conformance.pqcrypta.com/session | jq -r .id)
# then drive neqo at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-ecn-congestion"]'