xquic — Datagrams delivered out of order

Inconclusive

The run did not exercise this test: the connection failed during the handshake (detected an error with protocol compliance that was not covered by more specific error codes in STREAMS_BLOCKED_BIDI: illegal frame type in handshake), so the client never reached the anomaly.

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

Datagrams delivered out of order — q-packet-reordering

Clause

RFC 9000 §2.2 (MUST)

Class

resilience — Recovered rather than giving up.

Required behaviour

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.

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-packet-reordering"]'