does not report ECN counts. Another peer has echoed the markings this same port sent, so the codepoint demonstrably survives the path from here -- this client simply reported nothing, which §13.4.1 permits where the ECN field is not accessible to it.
The client does not do this, and said so itself — by what it advertised, or by refusing outright. A definite answer about the client, not a failure and not a gap.
What was measured
- Client
- quico — quico + lemon-tls, 0.7.0 (npm)
- Test
- Packets marked ECT(0) —
q-ecn - Clause
- RFC 9000 §13.4 (MUST)
- Class
- correctness — Rejected something invalid, with the code the RFC names.
- Required behaviour
- Echo the ECN counts back in ACK frames carrying an ECN section (type 0x03). §13.4.1 makes this a conditional requirement — an endpoint MUST report the markings it receives "if these are accessible", and explicitly permits an endpoint with no access to the ECN field to report nothing. So counts coming back is a pass, and silence is never a failure. Silence is read against the path rather than left unresolved. Both directions cross the same path: a client whose own datagrams reach this endpoint still carrying ECT has shown the codepoint survives and that its stack sets it, and so has a port where any peer has ever echoed the markings sent from it. Either makes the silence the client's own and the result `unsupported` -- a property of the client, which §13.4.1 expressly allows. Only where nothing has shown the codepoint surviving is the run inconclusive, because only there is a stripped path still a live possibility.
- Measured
- 2026-10-15
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 quico at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-ecn"]'