lsquic — Deliberately tight MAX_DATA and MAX_STREAM_DATA

Inconclusive

The run did not exercise this test: the connection failed during the handshake (timed out), 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

lsquic — LiteSpeed lsquic + BoringSSL, 4.9.4

Test

Deliberately tight MAX_DATA and MAX_STREAM_DATA — q-flow-control

Clause

RFC 9000 §4 (SHOULD)

Class

discretionary — The RFC permits either behaviour; the report says which was chosen.

Required behaviour

Respect the limit. Announcing the stall with DATA_BLOCKED or STREAM_DATA_BLOCKED is a SHOULD in §4.1, not a MUST, so a client that stays silent is still conformant.

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-flow-control"]'