Intent to Extend Origin Trial: QuicTransport

105 views
Skip to first unread message

Yutaka Hirano

unread,
Feb 8, 2021, 6:22:44 AMFeb 8
to blink-dev
yhi...@chromium.org,vas...@chromium.org https://github.com/WICG/web-transport/blob/master/explainer.md Specification: https://wicg.github.io/web-transport/#web-transport https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit https://github.com/w3ctag/design-reviews/issues/389 QuicTransport is an API that allows Web applications to connect directly to remote servers using QUIC. It is a part of the WebTransport framework; Http3Transport and FallbackTransport are not covered by this enhancement. To see whether the API (and the implementation) is useful in various circumstances. Our partners want to evaluate this API on various network circumstances (i.e., lab environments are not enough) to see its effectiveness. We also expect feedback for performance. M84-M88

Reason this experiment is being extended

One of our partners wants to start an experiment fairly soon.


Please note that we decided to develop WebTransport over HTTP/3, not WebTransport over QUIC, in the IETF working group. Hence we don't implement further features on top of current WebTransport over QUIC, but the request from the partner is valid, given that WebTransport over HTTP/3 and WebTransport over QUIC is very similar. We should be able to take advantage of experiments findings with WebTransport over QUIC for WebTransport over HTTP/3.

None Printing an error message with the reason when the opening handshake fails. We're planning the following but they are not available during the origin-trial period. The current plan is to show outgoing QuicTransport connections in the “Network” section of DevTools, the same place where WebSocket connections are shown. Unlike WebSockets, we do not intend to show the actual contents of the QuicTransport sessions, thus avoiding the performance decrease that would cause. Just like with regular HTTP/3-based QUIC traffic, the detailed information about the connection can be obtained via chrome://net-export interface. Yes No We have browser tests, but we are going to port them to WPT shortly. https://www.chromestatus.com/feature/4854144902889472

Mike West

unread,
Feb 8, 2021, 6:33:16 AMFeb 8
to Yutaka Hirano, blink-dev
The original QuicTransport origin trial ran (is running) from M84 to M88, and you suggest that the extension is due to a partner just starting their experiment now. The "goals for experimentation" are, however, unchanged. Did you get any developer feedback during that period that would help answer the questions? Do you plan additional changes to the API that a trial extension would help you evaluate? How much of an extension are you asking for to help evaluate the API's shape?

-mike


--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6GnSYYfmsK9LuT1z7fMNkhJXjPCSXQpfpC_enExzhqO9Q%40mail.gmail.com.

Frédéric Wang

unread,
Feb 8, 2021, 6:57:26 AMFeb 8
to blin...@chromium.org
Le 08/02/2021 à 12:22, Yutaka Hirano a écrit :
No We have browser tests, but we are going to port them to WPT shortly.

Hi,

As part of my work in [1], I noticed that quic-transport was added in the SchemeRegistry's standard_schemes and secure_schemes [2]. This implies web-exposed changes for which it would be good to update the spec and add web platform tests. Below are some things I'm aware.

1. URL using the quic-transport schemes are treated as "potentially trustworthy" per [3]. I think it makes sense to add it to step 3 of [3] together with "https" and "wss".

2. Origin with the quic-transport schemes are not treated as opaque, [4] should probably be updated accordingly.

Additionally,

3. I suspect you want quic-transport to be a "special scheme" so that its URL parsing is handled consistently with https etc [5]. This can be easily tested e.g. compare the result of new URL("https:/a/b") vs new URL("notspecial:/a/b")

Note that I already added internal tests for the two first items while working on [1].

Hope that helps,

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1153336
[2] https://source.chromium.org/chromium/chromium/src/+/master:url/url_util.cc;l=31;drc=09c1e888854f4ca8bf35de6b5e67fead82274ef7
[3] https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy
[4] https://url.spec.whatwg.org/#concept-url-origin
[5] https://url.spec.whatwg.org/#special-scheme https://url.spec.whatwg.org/#url-parsing

-- 
Frédéric Wang

Yutaka Hirano

unread,
Feb 8, 2021, 8:34:20 AMFeb 8
to Mike West, blink-dev
On Mon, Feb 8, 2021 at 8:33 PM Mike West <mk...@chromium.org> wrote:
The original QuicTransport origin trial ran (is running) from M84 to M88, and you suggest that the extension is due to a partner just starting their experiment now. The "goals for experimentation" are, however, unchanged. Did you get any developer feedback during that period that would help answer the questions? Do you plan additional changes to the API that a trial extension would help you evaluate? How much of an extension are you asking for to help evaluate the API's shape?

I'd like to extend the origin trial for two milestones (89, 90). 

https://groups.google.com/a/chromium.org/g/web-transport-dev/c/EqQodC2V50U is an example feedback we got. We'll appreciate such feedback/feature requests.

Yutaka Hirano

unread,
Feb 8, 2021, 8:38:44 AMFeb 8
to Frédéric Wang, blink-dev

As mentioned in the original e-mail, we are planning to remove the WebTransport over QUIC implementation, and we will not need the "quic-transport" scheme in the future.

Thanks,

--
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 blink-dev+...@chromium.org.

Mike West

unread,
Feb 8, 2021, 9:18:47 AMFeb 8
to Yutaka Hirano, blink-dev
The branch point for M90 is in ~3 weeks, so extending the trial to M90 doesn't buy you much time to deal with feedback. Are you going to be able to make a ship/no-ship call by then?

-mike

Yutaka Hirano

unread,
Feb 8, 2021, 10:30:53 AMFeb 8
to Mike West, blink-dev
We're not close to shipping, so I'll not be ready to make a final call at that time I think.

Mike West

unread,
Feb 10, 2021, 3:00:23 AMFeb 10
to Yutaka Hirano, blink-dev
My understanding of the current state is the following:

1.  Y'all know you don't want to ship `QuicTransport`, and plan breaking changes to the API in the M91 timeframe.
2.  You have a partner who plans to expand their experiment during the M89-M90 timeframe, and the data gathered from that experiment will help you understand the characteristics of the underlying transport layer in a way that will continue to be useful in the API's new shape.
3.  You do not plan to extend the `QuicTransport` OT again; it will die after M90, and you'll come back to start a new trial with the API's new shape.

Given all that, my worries about burn-in seem reasonably addressed. Extending the OT to M90 to gather more data LGTM.

-mike

Reply all
Reply to author
Forward
0 new messages