Thanks, Reilly. "default" does not mean guaranteed “balanced” performance; it means the application has no specific congestion-control preference, so Chromium retains its normal QUIC behavior.
We recommend "default" for mixed outgoing workloads, workloads without a clear priority, or sessions primarily receiving server-to-client data. "throughput" is appropriate for sustained client-sent bulk data, while "low-latency" is for client-sent delay-sensitive data. The hint only affects data sent by the browser; it does not control the server’s sending algorithm. I'll also update in chrome entry anticipated spec change section with "Chromium will initially map "low-latency" to BBRv2. We’ll evaluate future algorithms separately and may introduce additional hints if transparently changing that mapping would create compatibility concerns". On Thursday, October 22, 2026 at 12:33:53 PM UTC-7 Reilly Grant wrote: > 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/066ed962-600b-4786-95f1-7e953de1cbe5n%40chromium.org.
