Intent to extend the origin trial: WebTransport over HTTP/3

[Yutaka Hirano]

Contact emails

yhi...@chromium.org,vas...@chromium.org

Explainer

https://github.com/w3c/webtransport/blob/main/explainer.md

Design docs/spec

Specification: https://w3c.github.io/webtransport/#web-transport

https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit

TAG review

https://github.com/w3ctag/design-reviews/issues/669

Summary

WebTransport is an interface representing a set of reliable/unreliable streams to a server. The interface potentially supports multiple protocols, but based on discussions on the IETF webtrans working group, we are developing WebTransport over HTTP/3 which uses HTTP3 as the underlying protocol.

Note that we were developing QuicTransport a.k.a. WebTransport over QUIC and we ran an origin trial M84 through M90. It uses the same interface WebTransport, but because of the protocol difference ("quic-transport" vs. "https") it is difficult for web developers to be confused by them.

new WebTransport("quic-transport://example.com:9922")

represents a WebTransport over QUIC connection, and

new WebTransport("https://example.com:9922")

represents a WebTransport over HTTP/3 connection.

Goals for experimentation

We're shipping the API in M97. Twitch, one of our partners, wants to continue their experiment until the API is fully shipped. I think this is a reasonable request given we originally aimed to ship the feature in M96 but we missed the branch point.

The original goals follow:

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

M95 and M96

Ongoing technical constraints

None

Debuggability

The devtools support is under development.

Just like with regular HTTP/3 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.

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/4854144902889472

[Yoav Weiss]

Discussing amongst the API owners (Alex, Daniel, Rego and myself), this is essentially a request for a gapless OT, only that the would-be-gap is slightly longer than usual. Given the evidence of developer feedback presented in the I2S, that seems like a reasonable request.

LGTM1 (as gapless OT requests require 3 LGTMs)

On Monday, October 18, 2021 at 10:39:14 AM UTC+2 Yutaka Hirano wrote:

Contact emails

yhi...@chromium.org,vasilvv@chromium.org

[Daniel Bratell]

For a gapless origin trial->shipping it is important to be sure we don't overlook any feedback in the race to shipping. The normal process has gaps built in which form natural points to do that final polish based on received feedback and that will be missing here.

It does sound like the feedback has been positive though and that there are no known problems that can't be fixed after shipping, and with that in mind:

LGTM2

--
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/9ffa05b8-fbbf-4f2a-975d-be72a1089ebcn%40chromium.org.

[Mike West]

LGTM3.

-mike

On Thu, Oct 21, 2021 at 9:58 PM Daniel Bratell <brat...@gmail.com> wrote:

For a gapless origin trial->shipping it is important to be sure we don't overlook any feedback in the race to shipping. The normal process has gaps built in which form natural points to do that final polish based on received feedback and that will be missing here.

It does sound like the feedback has been positive though and that there are no known problems that can't be fixed after shipping, and with that in mind:

LGTM2

On 2021-10-21 21:53, Yoav Weiss wrote:

Discussing amongst the API owners (Alex, Daniel, Rego and myself), this is essentially a request for a gapless OT, only that the would-be-gap is slightly longer than usual. Given the evidence of developer feedback presented in the I2S, that seems like a reasonable request.

LGTM1 (as gapless OT requests require 3 LGTMs)

On Monday, October 18, 2021 at 10:39:14 AM UTC+2 Yutaka Hirano wrote:

Contact emails

yhi...@chromium.org,vas...@chromium.org

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a2d36d19-d8dd-20e2-638a-001304d9a8c9%40gmail.com.

[Joe Medley]

Hi,

Can I get some clarification?

So this extends the origin trial through 96, but you don't know yet whether it will ship in 97? Is this correct?

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

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

[Yutaka Hirano]

On Thu, Oct 28, 2021 at 2:38 AM Joe Medley <jme...@google.com> wrote:

Hi,

Can I get some clarification?

So this extends the origin trial through 96, but you don't know yet whether it will ship in 97? Is this correct?

We're shipping WebTransport over HTTP/3 in 97.

[Yutaka Hirano]

bcc: blink-dev

cc: web-transport-dev

Hi, web-tran...@chromium.org is a better place for this kind of discussion.

On Thu, Jan 20, 2022 at 3:47 PM kk as <kmsli...@gmail.com> wrote:

Hi

  Can you please let me know  what transport protocol  do the Streams API use in WebTransport over http3/quic.  

I am assuming the datagram API uses the UDP protocol for transport .   Can you also please let me know what is the difference in latency

when you send data using Streams API vs Datagram API ?

Reg: protocol, we use WebTransport over HTTP/3.

We expect Datagrams is better than Streams in terms of latency, but actual number depends on the network environment, server and client implementation.

Our client implementation is not (at all) perfect, so we'll appreciate your performance feedback!

 

thanks

[kk as]

Hi

  Can you please let me know  what transport protocol  do the Streams API use in WebTransport over http3/quic.  

I am assuming the datagram API uses the UDP protocol for transport .   Can you also please let me know what is the difference in latency

when you send data using Streams API vs Datagram API ?

thanks

On Wednesday, October 27, 2021 at 10:34:56 PM UTC-7 Yutaka Hirano wrote: