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. On Monday, October 19, 2026 at 2:33:31 PM UTC-7 Reilly Grant wrote: > 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/871e1ae9-b0d2-4d06-b6eb-72d307a8ae70n%40chromium.org.
