does not raise its path MTU above the 1200-byte minimum, so there is no black hole for it to detect. The server streamed 96 KiB at it and the path swallows anything over 1300, but nothing it sent was ever that large.
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
- xquic — Alibaba xquic + BoringSSL, 2060a44
- Test
- Path MTU black hole above a threshold —
q-pmtu-blackhole - Clause
- RFC 9000 §14, RFC 8899 (SHOULD)
- Class
- resilience — Recovered rather than giving up.
- Required behaviour
- Detect the black hole, probe down to a working size, and keep the connection. Path-MTU discovery is driven past the limit on this port, so it engages on every connection.
- Measured
- 2026-10-27
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-pmtu-blackhole"]'