v158 · network · webtransport

WebTransport congestion control

A cloud-gaming client and a bulk uploader want opposite things from the same congestion controller: one wants packets out now, the other wants the pipe full. Chrome 158 adds the congestionControl option to the WebTransport constructor — "default", "throughput", or "low-latency" — plus a read-only attribute of the same name that reports which preference the user agent actually satisfied.

concepts

  1. Preference readback, straight off the instance

    Probe the exact new surface — 'congestionControl' in WebTransport.prototype — dump its property descriptor, then construct three real sessions, one per enum value, and read the attribute back the moment each object exists. The spec resolves the hint in the constructor, so the answer never waits for a connection.

  2. Session builder: compose the real options object

    Assemble a real WebTransportOptions dictionary interactively — congestion-control preference, requireUnreliable, allowPooling, your own endpoint URL — then run the actual constructor and watch ready/closed settle, with the attribute sampled at every step and the equivalent code generated for copy-paste.

  3. A hint, not a guarantee

    The two edges the spec pins down: an enum value the parser does not know must throw a TypeError at the constructor, and a preference the user agent cannot satisfy silently becomes "default". Both run for real — and on a pre-158 build the invalid value not throwing is itself the proof that the option is being ignored.

  4. Which hint does your workload want?

    Answer two questions about your traffic — what hurts more, a late packet or a slow transfer, and what you mostly send — and get the enum value the spec intends for it, the real constructor line, and a live readback of what this browser would actually grant that request.

why it shipped

Congestion control decides how fast a sender ramps up and how it reacts to loss. Algorithms tuned for throughput (BBR-family) keep the pipe full at the cost of queueing delay; loss-based or latency-aware behaviour keeps queues short at the cost of peak bandwidth. Before this feature a WebTransport application had no way to say which trade-off it wanted — every session got whatever the browser's QUIC stack defaulted to. The congestionControl option lets the application state its preference without naming (or being promised) a specific algorithm, which RFC 9002 explicitly allows endpoints to choose freely.

The read-only attribute closes the loop: the constructor resolves the request immediately, so transport.congestionControl reports "throughput" or "low-latency" only when the user agent actually has an algorithm optimised for it, and "default" otherwise. The spec marks the option itself a feature at risk, because at the time of writing no browser ships an algorithm genuinely optimised for low latency — which makes honest readback, rather than blind trust in the request, the whole point of the attribute.

the API

const transport = new WebTransport("https://example.com:4433/game", {
  congestionControl: "low-latency",   // "default" | "throughput" | "low-latency"
});

// Resolved in the constructor — no need to await ready:
transport.congestionControl;
// "low-latency"  → the user agent satisfied the preference
// "default"      → requested but not satisfied (or never requested)

The option is a member of WebTransportOptions with default "default"; the attribute is a readonly accessor on WebTransport.prototype returning the WebTransportCongestionControl enum. An unknown string in the option position is a WebIDL enum violation and throws TypeError before any connection is attempted.

references