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.
On Thursday, October 15, 2026 at 10:13:21 AM UTC-7 Mike Taylor wrote: > On 10/14/26 6:45 p.m., Chromestatus wrote: > > *Contact emails* > [email protected] > > *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 > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%3EWebTransport%22> > > *Web Feature ID* > webtransport <https://webstatus.dev/features/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) > > Are they shipping congestion control, or just WebTransport? > > > *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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > 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 > <https://chromestatus.com>. > > -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ad005f7.4ec1d848.c43ea.00a3.GAE%40google.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ad005f7.4ec1d848.c43ea.00a3.GAE%40google.com?utm_medium=email&utm_source=footer> > . > > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9b1da152-7ee3-4d18-a191-0d14a1fbb993n%40chromium.org.
