does not accept a server whose flow-control windows are this tight. It abandoned the handshake on this port, whose transport parameters grant 512 bytes per stream and 1024 per connection and differ from the other ports in nothing else, while completing exchanges on others in this session. It sent no CONNECTION_CLOSE to say so (this client runs on the endpoint's own host, where nothing is lost), so the refusal is inferred from where it happened.
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.
Why the run landed here
lsquic refuses any server offering flow-control windows under 4096 bytes, and says nothing when it does.
A separate experiment drove the real lsquic binary against the same endpoint at a range of initial flow-control windows: at this test's window it completed 0 handshakes out of 6, and with the window relaxed it completed 6 of 6. lsquic's source names the threshold: with es_check_tp_sanity on, as it is by default for HTTP/3, a peer whose initial_max_stream_data_bidi_remote or initial_max_data is under 0x1000 fails the handshake -- a policy of lsquic's, since RFC 9000 sets no minimum. Its default LSQUIC_DF_SILENT_CLOSE then sends no CONNECTION_CLOSE, which is why the endpoint sees only a timeout. Since 2026-09-25 the verdict records the refusal itself; this note is the evidence behind the inference.
Established separately from the run and recorded beside it, not in it:
the verdict above is still only what the server could see. Measured by
pqcrypta-proxy/src/conformance/lsquic_windows.rs; lsquic src/liblsquic/lsquic_enc_sess_ietf.c,
2026-09-19; source read 2026-09-24.
What was measured
- Client
- lsquic — LiteSpeed lsquic + BoringSSL, 4.9.4 (2b30189)
- 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-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 lsquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-flow-control"]'