q-ecn-congestion
· RFC 9000 §13.4 · correctness · layer quic · udp/4508 · MUST
Passing this means: Rejected something invalid, with the code the RFC names.
Anomaly type: transport
How each client answered
| Client | Version | Verdict | What happened |
|---|---|---|---|
| curl | libcurl/8.23.0 ngtcp2/1.25.0 | Pass | Responded correctly: reported the congestion back: 7 ECN-CE among 0 ECT(0) and 0 ECT(1), after 7 datagram(s) were marked. |
| quinn | noq fork (189b0ed) | Pass | Responded correctly: reported the congestion back: 12 ECN-CE among 0 ECT(0) and 0 ECT(1), after 13 datagram(s) were marked. |
| aioquic | 1.3.0 (PyPI wheel) | Unsupported | does not report ECN counts, so the congestion signal had nowhere to be seen. 1 datagram(s) were marked CE and the codepoint demonstrably survives this path, so nothing here was lost in transit -- §13.4.1 requires reporting only where the ECN field is accessible to the endpoint, and for this client it is not. |
| chromium | build 1248 | Pass | Responded correctly: reported the congestion back: 11 ECN-CE among 0 ECT(0) and 0 ECT(1), after 12 datagram(s) were marked. |
| quic-go | quic-go v0.61.0 (h1:9So2anK4Tp22) | Pass | Responded correctly: reported the congestion back: 19 ECN-CE among 0 ECT(0) and 0 ECT(1), after 21 datagram(s) were marked. |
| quiche | 0.30.0 (1c8e976) | Unsupported | does not report ECN counts, so the congestion signal had nowhere to be seen. 2 datagram(s) were marked CE and the codepoint demonstrably survives this path, so nothing here was lost in transit -- §13.4.1 requires reporting only where the ECN field is accessible to the endpoint, and for this client it is not. |
| neqo | 0.31.1 (cac2b74) | Unsupported | does not report ECN counts, so the congestion signal had nowhere to be seen. 2 datagram(s) were marked CE and the codepoint demonstrably survives this path, so nothing here was lost in transit -- §13.4.1 requires reporting only where the ECN field is accessible to the endpoint, and for this client it is not. |
| picoquic | 8162550 | Pass | Responded correctly: reported the congestion back: 7 ECN-CE among 0 ECT(0) and 0 ECT(1), after 6 datagram(s) were marked. |
| ngtcp2 | 3c23148 | Pass | Responded correctly: reported the congestion back: 25 ECN-CE among 0 ECT(0) and 0 ECT(1), after 24 datagram(s) were marked. |
| lsquic | 4.9.4 (2b30189) | Unsupported | does not report ECN counts, so the congestion signal had nowhere to be seen. 2 datagram(s) were marked CE and the codepoint demonstrably survives this path, so nothing here was lost in transit -- §13.4.1 requires reporting only where the ECN field is accessible to the endpoint, and for this client it is not. |
| xquic | 2060a44 | Unsupported | does not report ECN counts, so the congestion signal had nowhere to be seen. 1 datagram(s) were marked CE and the codepoint demonstrably survives this path, so nothing here was lost in transit -- §13.4.1 requires reporting only where the ECN field is accessible to the endpoint, and for this client it is not. |
| msquic | 2.7.0 (7e6525d) | Pass | Responded correctly: reported the congestion back: 15 ECN-CE among 0 ECT(0) and 0 ECT(1), after 31 datagram(s) were marked. |
| quico | 0.7.0 (npm) | Unsupported | does not report ECN counts, so the congestion signal had nowhere to be seen. 2 datagram(s) were marked CE and the codepoint demonstrably survives this path, so nothing here was lost in transit -- §13.4.1 requires reporting only where the ECN field is accessible to the endpoint, and for this client it is not. |
What the clause requires
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.
Judged against RFC 9000.
Run this one yourself
Every test is reachable from your own client. Nothing here needs an account.
curl -s https://conformance.pqcrypta.com/catalog.json \
| jq '.tests[] | select(.id == "q-ecn-congestion")'