Intent to Experiment: 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/389

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

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

M91-M95

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

[Yutaka Hirano]

Hi,

On Wed, Apr 14, 2021 at 10:19 AM guest271314 <guest...@gmail.com> wrote:

> 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.

I am not confused by quic-transport protocol.

blob: file:, other protocol exist. 

The server code at https://github.com/GoogleChrome/samples/tree/gh-pages/webtransport works as intended.

I would suggest to not removed quic-transport, given there is no comparable HTTP/3 working code for WebTransport that I am aware of https://github.com/aio-libs/aiohttp/discussions/5581#discussioncomment-570522.

For those already using the quic-transport protocol, consider only removing quic-transport once there is working server code to substitute for the working Python aioquic server code.

At this moment I *believe* WebTransport over QUIC is still working - we haven't deleted the code yet. But we are doing that soonish.

 

> vs. "https"

We may as well just use fetch()?

I'm not sure if I understand this question.

Please refer to the IETF working group discussions for the protocol selection.

 

> Our partners want to evaluate this API on various network circumstances (i.e., lab environments are not enough) to see its effectiveness.

Some experiments using quic-transport protocol to stream STDOUT from espeak-ng to work around Web Speech API and Media Capture and Streams (getUserMedia()) and Screen Capture (getDisplayMedia()) not supporting capture of window.speechSynthesisSpeak(), and Web Speech API not supporting SSML input or parsing option passed to Speech Dispatcher (including usage of Media Transform API) therewith

https://github.com/guest271314/webtransport

I am willing to test (media streaming; etc.) at the front end.

[Yoav Weiss]

Any learnings from the OT with QUIC that led you to try WebTransport over H3?

[Bernard Aboba]

One learning was that client/server QuicTransport was converging toward Http3Transport to address security issues. So having 2 client/server protocols was hard to justify.

The learning from the previous OT was that P2P QuicTransport was preferred over client server in gaming and remote desktop use cases (removing ICE was considered a bug, not a feature). P2P QUIC performed better than RTCDatachannel for reliable streams but for gaming and remote desktop use cases partial or unreliable transport was required and there the perf advantage was not as great, nor did QUIC datagrams do any better in terms of backpressure (needed to be handled at the app layer anyway). 

--
You received this message because you are subscribed to the Google Groups "web-transport-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-transport-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-transport-dev/6a93c6e5-5dc2-43b0-bada-16bc890f40bfn%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "web-transport-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-transport-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-transport-dev/CAHVo%3DZ%3DLrbufoo7L7mWp-HcPszX%3DkO65pRHWVaScDBWy-U3dZA%40mail.gmail.com.

[Yutaka Hirano]

In addition to the experiment Twitch is running, Zoom also used our WebTransport over QUIC prototype and provided a feedback (https://groups.google.com/a/chromium.org/g/web-transport-dev/c/EqQodC2V50U/m/fU0RsCoYAQAJ).

It led us to specify a few options in the spec (https://github.com/w3c/webtransport/issues/152).

Thanks,

[Yoav Weiss]

Great learnings, thanks for sharing all!

LGTM to experiment M91-95

[guest271314]

> 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.

I am not confused by quic-transport protocol.

blob: file:, other protocol exist. 

The server code at https://github.com/GoogleChrome/samples/tree/gh-pages/webtransport works as intended.

I would suggest to not removed quic-transport, given there is no comparable HTTP/3 working code for WebTransport that I am aware of https://github.com/aio-libs/aiohttp/discussions/5581#discussioncomment-570522.

For those already using the quic-transport protocol, consider only removing quic-transport once there is working server code to substitute for the working Python aioquic server code.

> vs. "https"

We may as well just use fetch()?

> Our partners want to evaluate this API on various network circumstances (i.e., lab environments are not enough) to see its effectiveness.

Some experiments using quic-transport protocol to stream STDOUT from espeak-ng to work around Web Speech API and Media Capture and Streams (getUserMedia()) and Screen Capture (getDisplayMedia()) not supporting capture of window.speechSynthesisSpeak(), and Web Speech API not supporting SSML input or parsing option passed to Speech Dispatcher (including usage of Media Transform API) therewith

https://github.com/guest271314/webtransport

I am willing to test (media streaming; etc.) at the front end.

On Monday, April 12, 2021 at 3:15:09 AM UTC-7 yhi...@chromium.org wrote:

[guest271314]

I read the IETF working group discussions for the protocol selection.

quic-transport protocol is not confusing one way or the other , here, re this document.

My request is simple: Kindly substitute working HTTP/3 server code for working Python aioquic server code at Google sample before removing quic-transport from Chrome source code. I am still on 

Chromium
91.0.4458.0 (Developer Build) (64-bit)
Revision
e6fc042e9d532f8c1d223301495d2919e3da5a2c-refs/heads/master@{#866361}

I noted some additions and modification in recent bugs re WebTransport. I am not sure if the protocol is still there. I know the code I use works now with quic-transport over WebTransport and QuicTransport.

Re fetch() - given the vote was to use HTTPS, why would developers not just use fetch() instead of WebTransport - in case IETF working group decide to change their minds again and remove working code?

Thanks for this technology, again. 

[Luke Curley]

To clarify, Http3Transport and QuicTransport both offer the same WebTransport API and functionality. It requires more code to support HTTP/3 (primarily QPACK) but the IETF working group felt it was important to converge on one transport instead of two.

Http3Transport uses a HTTP request (CONNECT) while QuicTransport uses a custom handshake on the first QUIC stream. Once the session has been established, both expose the underlying QUIC connection as the WebTransport API. So Http3Transport uses HTTP/3 just for the handshake while QUIC is used for everything else.

Twitch is using QuicTransport and we'll be the first to try out Http3Transport when it's available.

--

You received this message because you are subscribed to the Google Groups "web-transport-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-transport-...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-transport-dev/86d1807a-5ed8-4332-86f2-f3e32ea1cca9n%40chromium.org.

[Luke Curley]

Hey Yoav, not sure if that question was directed at me, but I'll answer it anyway!

We've built an application using QuicTransport, utilizing a server that pushes and prioritizes QUIC streams based on importance. Prioritization is possible using WebSockets, but just like HTTP/2 it suffers from TCP head-of-line blocking. We've had to work around a few bugs with QuicTransport but it's fundamentally the best browser-supported protocol for our use-case.

We'll be using WebTransport over H3 because it offers the same functionality but with a different handshake. It would be unfortunate if WebTransport fails to be adopted and we would fallback to a slightly worse approach that uses HTTP/3.

On Thu, Apr 15, 2021 at 9:43 AM Yoav Weiss <yoav...@chromium.org> wrote:

--

You received this message because you are subscribed to the Google Groups "web-transport-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-transport-...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-transport-dev/6a93c6e5-5dc2-43b0-bada-16bc890f40bfn%40chromium.org.

[Dana Tyler]

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/CAL5BFfX_XjA%3Do49Qk06Apq-pa41dv9%2BHPXnbM%3DHbLQgAGE7WXg%40mail.gmail.com.

[guest271314]

My use case for QuicTransport/WebTransport is not necessarily based on networking, rather a substitute for using a browser extension and Native Messaging (which has limitations re streaming; cannot really use Transferable Streams between extension and browser at console at an arbitrary page) to execute arbitrary local native applications and shell scripts, streaming STDOUT therefrom to browser. 

I filed this FUGU https://bugs.chromium.org/p/chromium/issues/detail?id=1115640 before experimenting with QuicTransport, which effectively achieves the requirement - save for the inability to run the code at console at arbitrary web page due to CORS and/or CSP restrictions - otherwise works as intended for the use case of getting output of espeak-ng as WAV piped to browser then output using Media Capture Transform MediaStreamTrackGenerator or Web Audio API AudioWorklet - to work around the fact that there is no API to 1) capture audio output of Web Speech API (https://lists.w3.org/Archives/Public/public-speech-api/2017Jun/0000.html); 2) pass an option to speech-dispatcher to interpret input as SSML (speech synthesis markup language) (https://github.com/guest271314/SSMLParser) .

I do not need "pooling". 

TL;DR As soon as I got this working you folks removed the functionaility without a working replacement or substitute.

On Saturday, May 1, 2021 at 9:19:35 PM UTC guest271314 wrote:

Now that QuicTransport has been removed from Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=1201118 (https://github.com/GoogleChrome/samples/blob/gh-pages/webtransport/quic_transport_server.py obsolete) what server code are you using for WebTransport?

[guest271314]

Now that QuicTransport has been removed from Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=1201118 (https://github.com/GoogleChrome/samples/blob/gh-pages/webtransport/quic_transport_server.py obsolete) what server code are you using for WebTransport?

On Friday, April 16, 2021 at 11:19:30 PM UTC Luke Curley wrote:

[Yutaka Hirano]

On Sun, May 2, 2021 at 11:16 PM guest271314 <guest...@gmail.com> wrote:

My use case for QuicTransport/WebTransport is not necessarily based on networking, rather a substitute for using a browser extension and Native Messaging (which has limitations re streaming; cannot really use Transferable Streams between extension and browser at console at an arbitrary page) to execute arbitrary local native applications and shell scripts, streaming STDOUT therefrom to browser. 

I filed this FUGU https://bugs.chromium.org/p/chromium/issues/detail?id=1115640 before experimenting with QuicTransport, which effectively achieves the requirement - save for the inability to run the code at console at arbitrary web page due to CORS and/or CSP restrictions - otherwise works as intended for the use case of getting output of espeak-ng as WAV piped to browser then output using Media Capture Transform MediaStreamTrackGenerator or Web Audio API AudioWorklet - to work around the fact that there is no API to 1) capture audio output of Web Speech API (https://lists.w3.org/Archives/Public/public-speech-api/2017Jun/0000.html); 2) pass an option to speech-dispatcher to interpret input as SSML (speech synthesis markup language) (https://github.com/guest271314/SSMLParser) .

I do not need "pooling". 

TL;DR As soon as I got this working you folks removed the functionaility without a working replacement or substitute.

Sorry for the inconvenience. We decided to focus on WebTransport over HTTP/3 in January at the IETF working group, and I should have announced our plan earlier.

As I stated before, "Please note that the API is not at all final, and we will make further changes. But we'll do our best to minimize your pain when we update the API." This is still true, and this applies to the protocol too.

 

On Saturday, May 1, 2021 at 9:19:35 PM UTC guest271314 wrote:

Now that QuicTransport has been removed from Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=1201118 (https://github.com/GoogleChrome/samples/blob/gh-pages/webtransport/quic_transport_server.py obsolete) what server code are you using for WebTransport?

We're using a simple server on our browser tests.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-transport-dev/9ea7b8fe-370b-4863-9324-a55a23837d42n%40chromium.org.

[guest271314]

> We're using a simple server on our browser tests.

I am not sure if you are using https://source.chromium.org/chromium/chromium/src/+/main:net/tools/quic/quic_simple_server.h, https://source.chromium.org/chromium/chromium/src/+/main:net/tools/quic/quic_transport_simple_server.h, https://source.chromium.org/chromium/chromium/src/+/main:net/test/embedded_test_server/embedded_test_server.h or a combination of the three?

My particular use case is running local applications and shell scripts at console on any origin and getting STDOUT streamed to browser in "real-time". Something like what is described at https://github.com/httpslocal/proposals/issues/2. That can be achieved using several existing technologies already existing in Chrome/Chromium source code. Unfortunately QuicTransport was deprecated, the focus here is on networking alone, while this technology is capable of solving longstanding issues other than networking in Chrome/Chromium, a bried synpopsis of those issues and what WebTransport can remedy is described at https://groups.google.com/a/chromium.org/g/chromium-extensions/c/BnsgStmVOMc.

It would be helpful to users in the field if the server and browser test code used here be updated at https://github.com/GoogleChrome/samples/blob/gh-pages/webtransport/, if that is possible. The current quic-transport code is obsolete, and the repository has Google's name on it.

Due to focus on HTTP/3 which is under CSP I am not certain if using WebTransport will be any different than using a Chrome extension and fetch() to stream STDOUT.

I look forward to the further development of WebTransport nonetheless.

Kind regards,

/guest271314/

[Yutaka Hirano]

Sorry, the test server is for QuicTransport, and we've switched the protocol since then.

Currently we're using a WebTransport over HTTP/3 server for testing, but using the server is not easy I think.

We're working to build a WebTransport over HTTP/3 server for web-platform-test, and that server will be easier to use/extend.

On Wed, Jun 2, 2021 at 3:58 PM 刘连响 <not...@gmail.com> wrote:

The  https://github.com/GoogleChrome/samples/tree/gh-pages/webtransport can not works now,   Is there any working demo with the latest WebTransport?

Anyone will fix the https://github.com/GoogleChrome/samples/tree/gh-pages/webtransport to a  working demo? 

[刘连响]

The  https://github.com/GoogleChrome/samples/tree/gh-pages/webtransport can not works now,   Is there any working demo with the latest WebTransport?

Anyone will fix the https://github.com/GoogleChrome/samples/tree/gh-pages/webtransport to a  working demo? 

在2021年5月6日星期四 UTC+8 下午5:56:20<yhi...@chromium.org> 写道：

[Luke Curley]

We migrated our application from QuicTransport to Http3Transport with no issues so far. I wish I could release sample code, but it's one of the problems when working at a large company...

[Victor Vasiliev]

For what it's worth, I don't believe there are any meaningful parts of Google's WebTransport implementation that are not already open source; we do have a test server written in C++ that is a part of Chromium, though it's not very well-documented nor is it really that useful (I think it only implements echo operations).

Regarding the example code, it will most likely be updated to HTTP/3-based WebTransport relatively soon, though I can't give an exact timeline for that yet.

On Fri, Jun 4, 2021 at 8:27 PM guest271314 <guest...@gmail.com> wrote:

> We migrated our application from QuicTransport to Http3Transport with no issues so far. I wish I could release sample code, but it's one of the problems when working at a large company...

I do not understand. What happened to FOSS? QuicTransport worked before deprecation/removal. Now there is no working code in the Google samples repository. Google cannot claim that their corporation has lack of resources. The only conclusion to draw is lack of will to post basic working server. The proverbial cart before the horse, unless it is intended for this to be the mere playground of the small group of individuals who contribute to the specification and change said specification at will, yet cannot publish the code they are using to test or use for commercial purposes. More closed-source than open source.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-transport-dev/1edcb918-3dad-4da8-8aa1-62187011f2f9n%40chromium.org.

[guest271314]

You mentioned large company. The same principle applies whatever the brand is, or the specification body that write up this stuff. What is the mission statement and priority, FOSS or profit? The result of that inquiry is observable in real-time. 

>  I can help if anybody has any questions or runs into issues.

I began this discussion in aio-http https://github.com/aio-libs/aiohttp/discussions/5581 

> aiohttp does only supports HTTP/1.1. To support HTTP/2 and HTTP/3 somebody needs to step in and actually implement it. 

because I finally got the Python code working while learning Python by doing. It would be, perhaps, useful for developers in the field who were running the Google samples server code to have similar Python HTTP/3 code. Or, any language server code, if you are involved with the inner mechanics of this efforet, big company, small company, individual, does not matter. Publish your tests for users in the field to test. You cannot gather all information in a closed-loop system, even if the group thinks they can, they cannot prove anything from only within, Godel proved that mathematically some time ago.

For now I am using fetch() to achieve the requirement of streaming STDOUT from shell script, to for example, stream speech synthesis and media, and PHP passthru() on the server side. I look forward to furhter experimenting with WebTransport. Thanks for your feedback.

On Friday, June 4, 2021 at 6:19:48 PM UTC-7 Luke Curley wrote:

To be clear, I don't work at Google nor do I work on Chromium. I agree that it would have been much easier to implement WebTransport with a sample server. I'm planning on releasing my QUIC + WebTransport implementation anyway but it will take a bit of time.

Fortunately, the spec is relatively simple and mostly involves supporting a few new stream/frame types at the HTTP/3 layer. I can help if anybody has any questions or runs into issues.

On Fri, Jun 4, 2021, 5:27 PM guest271314 <guest...@gmail.com> wrote:

> We migrated our application from QuicTransport to Http3Transport with no issues so far. I wish I could release sample code, but it's one of the problems when working at a large company...

I do not understand. What happened to FOSS? QuicTransport worked before deprecation/removal. Now there is no working code in the Google samples repository. Google cannot claim that their corporation has lack of resources. The only conclusion to draw is lack of will to post basic working server. The proverbial cart before the horse, unless it is intended for this to be the mere playground of the small group of individuals who contribute to the specification and change said specification at will, yet cannot publish the code they are using to test or use for commercial purposes. More closed-source than open source.

On Friday, June 4, 2021 at 2:04:55 PM UTC-7 Luke Curley wrote:

[Luke Curley]

To be clear, I don't work at Google nor do I work on Chromium. I agree that it would have been much easier to implement WebTransport with a sample server. I'm planning on releasing my QUIC + WebTransport implementation anyway but it will take a bit of time.

Fortunately, the spec is relatively simple and mostly involves supporting a few new stream/frame types at the HTTP/3 layer. I can help if anybody has any questions or runs into issues.

On Fri, Jun 4, 2021, 5:27 PM guest271314 <guest...@gmail.com> wrote:

> We migrated our application from QuicTransport to Http3Transport with no issues so far. I wish I could release sample code, but it's one of the problems when working at a large company...

I do not understand. What happened to FOSS? QuicTransport worked before deprecation/removal. Now there is no working code in the Google samples repository. Google cannot claim that their corporation has lack of resources. The only conclusion to draw is lack of will to post basic working server. The proverbial cart before the horse, unless it is intended for this to be the mere playground of the small group of individuals who contribute to the specification and change said specification at will, yet cannot publish the code they are using to test or use for commercial purposes. More closed-source than open source.

On Friday, June 4, 2021 at 2:04:55 PM UTC-7 Luke Curley wrote:

[guest271314]

> We migrated our application from QuicTransport to Http3Transport with no issues so far. I wish I could release sample code, but it's one of the problems when working at a large company...

I do not understand. What happened to FOSS? QuicTransport worked before deprecation/removal. Now there is no working code in the Google samples repository. Google cannot claim that their corporation has lack of resources. The only conclusion to draw is lack of will to post basic working server. The proverbial cart before the horse, unless it is intended for this to be the mere playground of the small group of individuals who contribute to the specification and change said specification at will, yet cannot publish the code they are using to test or use for commercial purposes. More closed-source than open source.

On Friday, June 4, 2021 at 2:04:55 PM UTC-7 Luke Curley wrote:

[Yoav Weiss]

guest271314@ - I urge you to tone it down. 

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/e08ab0e1-97ab-4a94-bb28-dec353aa4c68n%40chromium.org.

[guest271314]

> guest271314@ - I urge you to tone it down. 

I do not understand what you mean. Be specific. If you do not want feedback from me just say that. Don't infer.

Ban me for another 1,000 years for pointing out that the cart is before the horse re deprecation of QuicTransport before WebTransport over HTTP/3 is operational?

[Yoav Weiss]

On Mon, Jun 7, 2021 at 8:22 AM guest271314 <guest...@gmail.com> wrote:

> guest271314@ - I urge you to tone it down. 

I do not understand what you mean. Be specific. If you do not want feedback from me just say that. Don't infer.

I specifically ask to use a calm and respectful tone when talking to other folks in this forum. The example that triggered my comment is Luke providing useful feedback on this thread, and you responding aggressively because they cannot share the relevant code. 

Ban me for another 1,000 years

I'd prefer it if you could provide your feedback in a calm, respectful and constructive manner, according to our code of conduct.

 

for pointing out that the cart is before the horse re deprecation of QuicTransport before WebTransport over HTTP/3 is operational?

IIUC, QuicTransport was in an Origin Trial and never shipped. As such, there's no need for a replacement before changing the implementation or trying out a different API shape.