Given that "default" does not map to BBRv2, under what conditions would you recommend developers choose it over hinting that their priority is "throughput" or "low-latency"? Does the default option provide more balanced performance? Reilly Grant | Software Engineer | [email protected] | Google Chrome <https://www.google.com/chrome>
On Thu, Oct 22, 2026 at 11:06 AM 'Monica Chintala' via blink-dev < [email protected]> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/26626160-7f46-4458-bc4c-7b7e18bb8628n%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%3DMYd71cZM_ckgACVHKP6R%3Dfh7Jd0AvLXfYTk%3DkB9ATLOFA%40mail.gmail.com.
