Please also file Mozilla and Webkit standards requests for congestion control specifically.
On Tue, Oct 20, 2026 at 11:04 AM Reilly Grant <[email protected]> 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/CAEmk%3DMafyZUpMqBXeWYWGex9xa_2ZdWbFYgJZ1rNa1snYfu%3D4w%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMafyZUpMqBXeWYWGex9xa_2ZdWbFYgJZ1rNa1snYfu%3D4w%40mail.gmail.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/CAOMQ%2Bw9LSDS2XRJ%3DQ33WE%2BeWEVQg_6oBAB6Oi%3D9%3DoJXepatjng%40mail.gmail.com.
