Intent to Ship: WebTransport congestion control

[Chromestatus]

Contact emails

moni...@microsoft.com

Explainer

https://github.com/w3c/webtransport/blob/main/explainer.md

Specification

https://www.w3.org/TR/webtransport/#dom-webtransportoptions-congestioncontrol

Summary

Adds the congestionControl constructor option and read-only attribute to WebTransport. Applications can request "default", "throughput", or "low-latency" behavior, allowing the user agent to select suitable congestion-control behavior for each session.

Blink component

Blink>Network>WebTransport

Web Feature ID

webtransport

Motivation

WebTransport applications have different performance requirements. Interactive applications prioritize low latency, while bulk transfers prioritize throughput. This hint lets applications express that preference without selecting or controlling a specific congestion-control algorithm.

Initial public proposal

No information provided

TAG review

Not applicable as a separate review. This is an incremental implementation of an API already defined in the W3C WebTransport specification and covered by the broader WebTransport TAG review: https://github.com/w3ctag/design-reviews/issues/1212

TAG review status

Not applicable

Goals for experimentation

None

Risks

Interoperability and Compatibility

Low. The API is additive, standardized, and already implemented by Firefox and Safari. Implementations may choose different underlying algorithms while preserving the standardized hint and fallback behavior

Gecko: Shipped/Shipping (https://github.com/mozilla/standards-positions/issues/167)

WebKit: Shipped/Shipping (https://github.com/WebKit/standards-positions/issues/18)

Web developers: Positive (https://github.com/web-platform-tests/interop/issues/1121) The Interop 2026 WebTransport proposal received 28 👍 reactions. Developers also reported active WebTransport use and significant cross-engine differences.

Other signals:

Ergonomics

Low. The three values are straightforward, but developers must understand that the option is a hint and may resolve to "default" when the requested behavior is unavailable.

Activation

Low. This is an additive constructor option and attribute. The value is a preference rather than a guarantee, and unsupported preferences may fall back to "default".

Security

Low. The API grants no new network access and does not expose congestion-window or network-state information. Applications provide only a high-level preference; the browser retains control of the selected algorithm.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Low. This is an additive WebTransport option and attribute implemented in shared Blink and network-service code. Existing WebView applications are unaffected, and applications using the option must treat it as a preference that may fall back to "default".

Debuggability

The requested value is readable through  transport.congestionControl . Existing DevTools networking, NetLog, and QUIC logging can diagnose connection behavior

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/webtransport/congestion-control.https.any.html?label=experimental&label=master&aligned

Flag name on about://flags

chrome://flags/#enable-experimental-web-platform-features

Finch feature name

WebTransportCongestionControl

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/501268547

Measurement

Validate API exposure and connection behavior through WPT, Chromium tests, and developer feedback from latency-sensitive and high-throughput WebTransport applications.

Availability expectation

Already supported by Firefox and Safari as part of the W3C WebTransport specification. Chromium support is implemented behind an experimental runtime feature.

Adoption expectation

Expected to be adopted by games, interactive media, remote-interaction applications, and bulk-transfer services that need to express latency or throughput preferences.

Adoption plan

Adoption is expected to happen organically through existing WebTransport applications and documentation.

Estimated milestones

Shipping on desktop	158
DevTrial on desktop	150
Shipping on Android	158
DevTrial on Android	150
Shipping on WebView	158

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None. The option and attribute are already defined by the W3C WebTransport specification.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5180947573112832?gate=5529995941380096

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

Are they shipping congestion control, or just WebTransport?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ad005f7.4ec1d848.c43ea.00a3.GAE%40google.com.

[Monica Chintala]

Thanks, the existing Mozilla and WebKit links are positions on Web Transport overall, not specifically on the congestion-control option. Both Firefox and Safari expose the API surface, but their behavioral support differs. Firefox currently ignores the requested value and reports the spec-permitted  "default"  fallback. Safari reflects the requested value, but its open-source network-process implementation does not pass it into the QUIC configuration. The shared WPT passes in all three engines, but it intentionally permits fallback to "default" and therefore tests API interoperability rather than the underlying congestion-control behavior.

[Alex Russell]

Can we update the positions of other browsers to be more accurate (e.g., neutral) given that they have not actually shipped the whole feature?

With that nit, LGTM1.

[Dan Clark]

LGTM2

[Monica Chintala]

Thank you all. I’ve updated both browser positions to Neutral and added clarifying comments per the recommendation, but the changes don’t appear to be showing on the ChromeStatus entry yet.

[Reilly Grant]

I'm concerned that shipping this is premature because according to the code both the "throughput" and "low-latency" options apply the same congestion control algorithm, with a TODO to consider doing something else.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d25435d9-f098-4c63-8433-5fe65f06cbddn%40chromium.org.

[Monica Chintala]

Adam, could you confirm whether this is appropriate to ship as-is? During the implementation review, BBRv1 was determined not to be suitable, so "low-latency" was mapped to BBRv2 for now, the same algorithm used for "throughput" with a TODO to revisit it.  

Given that background, do we consider BBRv2 to satisfy both preferences, or should "low-latency" fall back to "default" until a more suitable option is available? Your context on that decision would help address the concern.

[Reilly Grant]

I can see arguments both for shipping the options now and refining the algorithms later, or for waiting until specific algorithms are specified for each option. This intent should explain which path we are taking and why.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/871e1ae9-b0d2-4d06-b6eb-72d307a8ae70n%40chromium.org.

[Chris Harrelson]

Please also file Mozilla and Webkit standards requests for congestion control specifically.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMafyZUpMqBXeWYWGex9xa_2ZdWbFYgJZ1rNa1snYfu%3D4w%40mail.gmail.com.

[Monica Chintala]

Thanks, Reilly. We’re choosing the ship now and refine the algorithm later path.

With upstream networking owners, our assessment is that it is reasonable to ship with "low-latency" currently using BBRv2, while investigating Prague/L4S as a future mapping. The identical BBRv2 mapping is therefore an intentional initial implementation rather than an unfinished API contract. The values are semantic hints, and the specification does not require distinct algorithms for each value. BBRv2 offers both high throughput and lower queuing delay. If QUICHE’s Prague/L4S support proves suitable, Chromium can later improve the "low-latency" mapping without changing the web-facing API. This provides developers with the standardized API now while preserving implementation flexibility.

[Monica Chintala]

Feature-specific position requests are also open with  WebTransport congestion control option and attribute · Issue #1472 · mozilla/standards-positions  and  WebTransport congestion control option and attribute · Issue #734 · WebKit/standards-positions.

[Reilly Grant]

Given that "default" does not map to BBRv2, under what conditions would you recommend developers choose it over hinting that their priority is "throughput" or "low-latency"? Does the default option provide more balanced performance?

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/26626160-7f46-4458-bc4c-7b7e18bb8628n%40chromium.org.

[Monica Chintala]

Thanks, Reilly. "default" does not mean guaranteed “balanced” performance; it means the application has no specific congestion-control preference, so Chromium retains its normal QUIC behavior.

We recommend  "default"  for mixed outgoing workloads, workloads without a clear priority, or sessions primarily receiving server-to-client data.  "throughput"  is appropriate for sustained client-sent bulk data, while  "low-latency"  is for client-sent delay-sensitive data. The hint only affects data sent by the browser; it does not control the server’s sending algorithm.

I'll also update in chrome entry anticipated spec change section with "Chromium will initially map "low-latency" to BBRv2. We’ll evaluate future algorithms separately and may introduce additional hints if transparently changing that mapping would create compatibility concerns".

[Adam Rice]

My preference is to ship now with both "throughput" and "low-latency" mapped to BBRv2, and then switch "low-latency" to the Prague CUBIC implementation once it is production-ready. This enables developers to start stating their preference now, and get a smooth upgrade to Prague once both client and server support it. This also has the benefit of aligning us with what other browsers are doing.

[Alex Russell]

Thanks for this, Monica and Adam.

I'm not sure we're going to have much luck with moving away from BBRv2 if the web comes to rely on that, but we can imagine compatible additions to the API surface that would allow folks who want to transition to do so. A bridge we can cross when we some to it.

LGTM1 to ship this with the BBRv2 mapping added as a non-normative note to the spec. I'd also like to see tests for BBRv2 behaviour if that's possible, but won't hold this intent up for that.

Best,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

LGTM2

Having both "throughput" and "low-latency" map to BBRv2 seems like a bit of a risk, but there's always the option of introducing a 4th value if changing "low-latency" later proves difficult. Hopefully the change happens soon enough that nobody has time to start using "low-latency".

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/871e1ae9-b0d2-4d06-b6eb-72d307a8ae70n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b94b75e7-2d35-4b02-9cf7-f55abe852597n%40chromium.org.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeOAw%2BNxsf4p97k7%3DapywPz7DEdgkdMA4ZhuYL_x3oSKA%40mail.gmail.com.