Intent to Extend Origin Trial: QuicTransport

[Yutaka Hirano]

Contact emails yhi...@chromium.org,vas...@chromium.org Explainer https://github.com/WICG/web-transport/blob/master/explainer.md Design docs/spec Specification: https://wicg.github.io/web-transport/#web-transport https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit TAG review https://github.com/w3ctag/design-reviews/issues/389 Summary 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. Goals for experimentation 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. Experimental timeline 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.

Ongoing technical constraints None Debuggability 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. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? No We have browser tests, but we are going to port them to WPT shortly. Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/4854144902889472

[Mike West]

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]

Le 08/02/2021 à 12:22, Yutaka Hirano a écrit :

Is this feature fully tested by web-platform-tests?

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]

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]

Please see https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/uoQG64TjVcU for the previous discussion.

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d9446a5d-a786-3fd1-7068-0d92fccf3473%40igalia.com.

[Mike West]

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]

We're not close to shipping, so I'll not be ready to make a final call at that time I think.

[Mike West]

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

[Frédéric Wang]

Hi,

Among items 1-3 it seems only the first one had already landed (and without runtime flag).

I'm not sure it's web-exposed, since chrome probably can't load a page with a quic-transport: scheme anyway, but since you don't plan to ship the quic-transport: scheme anymore, can you please remove it from the secure_schemes list:

https://source.chromium.org/chromium/chromium/src/+/main:url/url_util.cc;l=66;drc=ae97629737a9f0935c79337f5adb9b75e6edb84b

Thanks,

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6FOBhR%2BXxL6Rt04bgsYo_stfZcHCNxewBx0UK0Zp3QL9w%40mail.gmail.com.

-- 
Frédéric Wang

[Yutaka Hirano]

Sure, we're working on it: https://crbug.com/1201118.