v158 · webtransport · congestion control

Preference readback, straight off the instance

The spec resolves the congestion-control request inside the constructor: if the user agent has no algorithm optimised for what you asked, [[CongestionControl]] is set to "default" before the object is returned. So the attribute is readable the instant new WebTransport(...) finishes — no connection, no await ready. This page probes the exact surface, then constructs one real session per enum value and reads each answer back immediately.

Chrome targets congestionControl for Chrome 158 behind the WebTransportCongestionControl runtime flag. On an earlier or unflagged build, launch with --enable-blink-features=WebTransportCongestionControl, or flip chrome://flags/#enable-experimental-web-platform-features and relaunch. The sessions below target https://127.0.0.1:44443/never (nothing listens there) — the readback works anyway, because the spec resolves it before establishment.

The exact surface

Not typeof WebTransport — the constructor has existed since Chrome 97. The new thing is one accessor on the prototype:

typeof WebTransport
…
'congestionControl' in WebTransport.prototype
…
property descriptor
…

Reading…

One session per enum value

Construct three real WebTransport objects — "default", "throughput", "low-latency" — and read transport.congestionControl back synchronously, while each session is still in [[State]] "connecting".

Requested vs. satisfied, sampled at construction time
requested in optionstransport.congestionControlmeaning
No readback yet — press the button.

code path

for (const requested of ["default", "throughput", "low-latency"]) {
  const t = new WebTransport("https://127.0.0.1:44443/never", {
    congestionControl: requested,
  });
  // Readable immediately — the constructor already resolved it:
  console.log(requested, "->", t.congestionControl);
  t.close(); // we never needed the connection
}

see also