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/0f64e3cb-f5b5-49da-a495-4ee971bb9656n%40chromium.org.
