xquic — Packets marked ECT(0)

Inconclusive

The run did not exercise this test: ECN validation failed: packets sent marked ECT(0) came back acknowledged without ECN counts, so the marking was disabled. Whether the peer declined to report or the path rewrote the codepoint cannot be told apart from this end.

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

xquic — Alibaba xquic + BoringSSL, 2060a44

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 inconclusive rather than a failure: it cannot be told apart from a path that stripped the codepoint in transit.

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