v158 · webtransport · congestion control
Which hint does your workload want?
The enum has three values because real traffic has (at least) three shapes. Answer two questions about yours and get the value the spec intends for it, the constructor line to copy, and — on a supporting build — a live readback of what this browser would actually grant that request right now.
Chrome targets congestionControl for Chrome 158 behind the WebTransportCongestionControl runtime flag (--enable-blink-features=WebTransportCongestionControl, or chrome://flags/#enable-experimental-web-platform-features). The grant check below constructs a real session against an unreachable local address — the grant resolves in the constructor, so no server is needed to read it.
Describe the traffic
Recommendation
…
…
…What this browser grants that request right now: not checked yet
What the hint does not do
- It names no algorithm. RFC 9002 §7 lets endpoints pick any controller; the enum expresses an optimisation goal, not "use BBR". (Chromium's implementation notes map the preference onto BBR-family controllers, but that is an implementation detail, not a contract.)
- It is per-session, sender-side. It shapes how this endpoint sends. The server's sending behaviour is the server's business — ask your server operator for the matching knob.
- It is resolved once, in the constructor. There is no setter; you cannot flip a live session from throughput to low-latency. Reconnect to renegotiate.
- Pooling shares the controller. With
allowPooling: trueyour session may share a connection — and its congestion state — with other sessions on the same origin. - Check the attribute, not your assumption. A request the user agent cannot optimise for resolves to
"default"silently — the attribute is the only honest readout.