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

Inconclusive

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 run did not establish what this client does here — either it was never put in the situation, or its answer admits more than one reading. Not a failure, and never counted as one.

What was measured

Client

lsquic — LiteSpeed lsquic + BoringSSL, 4.9.4

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