Responded correctly: reported the congestion back: 15 ECN-CE among 0 ECT(0) and 0 ECT(1), after 31 datagram(s) were marked.
The client did what the clause requires.
What was measured
- Client
- msquic — .NET HttpClient + msquic, 2.7.0 (7e6525d)
- 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 never a failure, for the same reason, and it is read against the path in the same way: where this client's own datagrams arrived carrying ECT, or where any peer has echoed the markings this port sent, the codepoint demonstrably survives and the silence is the client's own -- `unsupported`, which §13.4.1 expressly allows. Only where nothing has shown the codepoint surviving is a stripped path still possible, and only there is the run inconclusive.
- Measured
- 2026-10-27
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 msquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-ecn-congestion"]'