I'm concerned that shipping this is premature because according to the code <https://source.chromium.org/chromium/chromium/src/+/main:net/quic/dedicated_web_transport_http3_client.cc;l=472;drc=4e393f181c91e3b221ece53fb83205e3602b6495> 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 | [email protected] | Google Chrome <https://www.google.com/chrome>
On Mon, Oct 19, 2026 at 12:10 PM 'Monica Chintala' via blink-dev < [email protected]> wrote: > 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. > > > > On Monday, October 19, 2026 at 11:35:04 AM UTC-7 Dan Clark wrote: > >> LGTM2 >> >> On Monday, October 19, 2026 at 11:29:17 AM UTC-7 [email protected] >> wrote: >> >>> 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. >>> >>> On Thursday, October 15, 2026 at 10:45:48 AM UTC-7 Monica Chintala wrote: >>> >>>> 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/d25435d9-f098-4c63-8433-5fe65f06cbddn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d25435d9-f098-4c63-8433-5fe65f06cbddn%40chromium.org?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/CAEmk%3DMZT1Cr10P%3DFvRORmQ%2B%2BoVKZMQEXHEyaU6FLi7bffTL%3D%3Dg%40mail.gmail.com.
