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. On Tuesday, October 20, 2026 at 11:04:57 AM UTC-7 Reilly Grant wrote: > 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 | [email protected] | Google Chrome > <https://www.google.com/chrome> > > On Mon, Oct 19, 2026 at 3:08 PM 'Monica Chintala' via blink-dev < > [email protected]> wrote: > >> 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/871e1ae9-b0d2-4d06-b6eb-72d307a8ae70n%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/26626160-7f46-4458-bc4c-7b7e18bb8628n%40chromium.org.
