LGTM2
Having both "throughput" and "low-latency" map to BBRv2 seems like a
bit of a risk, but there's always the option of introducing a 4th
value if changing "low-latency" later proves difficult. Hopefully the
change happens soon enough that nobody has time to start using
"low-latency".
On Tue, Oct 27, 2026 at 7:47 PM Alex Russell
<[email protected]> wrote:
Thanks for this, Monica and Adam.
I'm not sure we're going to have much luck with moving away from
BBRv2 if the web comes to rely on that, but we can imagine
compatible additions to the API surface that would allow folks who
want to transition to do so. A bridge we can cross when we some to it.
LGTM1 to ship this with the BBRv2 mapping added as a non-normative
note to the spec. I'd also like to see tests for BBRv2 behaviour
if that's possible, but won't hold this intent up for that.
Best,
Alex
On Friday, October 23, 2026 at 4:23:08 AM UTC-7 Adam Rice wrote:
My preference is to ship now with both "throughput" and
"low-latency" mapped to BBRv2, and then switch "low-latency"
to the Prague CUBIC implementation once it is
production-ready. This enables developers to start stating
their preference now, and get a smooth upgrade to Prague once
both client and server support it. This also has the benefit
of aligning us with what other browsers are doing.
On Wed, 21 Oct 2026 at 03:04, 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
<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/b94b75e7-2d35-4b02-9cf7-f55abe852597n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b94b75e7-2d35-4b02-9cf7-f55abe852597n%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/CAARdPYeOAw%2BNxsf4p97k7%3DapywPz7DEdgkdMA4ZhuYL_x3oSKA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeOAw%2BNxsf4p97k7%3DapywPz7DEdgkdMA4ZhuYL_x3oSKA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
