q-packet-reordering
· RFC 9000 §2.2 · resilience · layer quic · udp/4506 · MUST
Passing this means: Recovered rather than giving up.
Anomaly type: transport
How each client answered
| Client | Version | Verdict | What happened |
|---|---|---|---|
| curl | ngtcp2/1.11.0 | Pass | Recovered and completed the follow-up request. |
| quinn | noq fork | Pass | Recovered and completed the follow-up request. |
| aioquic | 1.3.0 | Pass | Recovered and completed the follow-up request. |
| chromium | build 1223 | Pass | Recovered and completed the follow-up request. |
| quic-go | quic-go v0.61.0 | Pass | Recovered and completed the follow-up request. |
| quiche | 0.30.0 | Pass | Recovered and completed the follow-up request. |
| neqo | 0.31.1 | Pass | Recovered and completed the follow-up request. |
What the clause requires
Put the stream back in order and deliver the whole body. §2.2 requires an endpoint to be "able to deliver stream data to an application as an ordered byte stream", and says plainly that doing so "requires that an endpoint buffer any data that is received out of order". Distinct from the loss test, which needs retransmission before the gap can be filled. Nothing is lost here: every byte arrives, some of it early, and a client that assumes arrival order is delivery order will produce a corrupt body or stall waiting for data it already has.
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-packet-reordering")'What this suite is · The full grid · All clients · All tests · Findings