msquic — Path marking packets CE, not just ECT(0)

Pass

Responded correctly: reported the congestion back: 12 ECN-CE among 0 ECT(0) and 0 ECT(1), after 411 datagram(s) were marked.

The client did what the clause requires.

What was measured

Client

msquic — .NET HttpClient + msquic, 2.7.0

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 msquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-ecn-congestion"]'