pub const STREAM_RECEIVE_WINDOW: VarInt;Expand description
Per-stream flow-control window, in bytes.
A deliberate raise above quinn’s own default of 1,250,000, not inherited from
it and not a pin at it. No RFC constrains the value — RFC 9000 §4.2 leaves the
amount of credit to implementations outright, and §4.3 only observes the
consequence of getting it wrong: an endpoint that “cannot ensure that its peer
always has available flow control credit that is greater than the peer’s
bandwidth-delay product” finds “its receive throughput will be limited by flow
control”. That is advice, not a requirement, and it is the whole of the case.
The production path’s BDP — a 100 Mbps client uplink over a 95 ms RTT — is
about 1.19 MB, so quinn’s default sat at roughly 1.05x it: exactly one BDP,
with no margin for a window update still in flight. 2 MiB is about 1.75x.
Measured corroboration: the peer we interoperate with sizes its own side far
higher still, Surge’s ClientHello advertising
initial_max_stream_data_bidi_local = 12 MiB per stream.
Not a memory decision. CONNECTION_RECEIVE_WINDOW is the real bound — the
invariant is that (the sum of the highest offsets received) minus (the bytes
read) stays within it — so a larger per-stream window cannot raise the
per-connection worst case, which is unchanged at 16 MiB. What this value
actually decides is how few simultaneously saturated tunnels it takes to spend
the whole connection’s credit — 16 MiB / 2 MiB = 8 — which is a fairness
property rather than a memory one, and 8:1 is still far more conservative than
the 1.33:1 the peer itself runs (16 MiB of initial_max_data against 12 MiB
per stream). The per-tunnel ceiling in the download direction is whatever the
client advertises to us and is not settable here.