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

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

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

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

[Yoav Weiss]

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

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

--

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.

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

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

[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]

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]

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.

[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/

[刘连响]

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? 

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

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

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

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

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

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

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.

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

[guest271314]

> I specifically ask to use a calm and respectful tone when talking to other folks in this forum.

I learned from hard lessons long ago that I do not care about "respect", which is an emotion controlled by someone else, and is absolutely arbitrary. An individual can feign "respect" in order to manipulate and change their mind about "respect" the next moment, after the manipulation.

Thus, I deal with facts, not emotions. I suggest you keep your opinion about "respect" to yourself, as there is no way to objectively test for "respect". I supply my own "respect".

I have been calm. I am not sure who you are used to dealing with, however, I am not the meek. I have fought City Hall, the State, and litigated to SCOTUS, twice, by myself. That cannot happen deferring to individuals who believe they have some form of pseudo authority and cannot be questioned.

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

If you think I have been "agressive" you evidently live in a very sheltered world, and have not had to fight physically, psychologically, culturally, and politically. I am direct. If you take that as being "agressive", that is your issue, not mines. Without what you refer to as "agressive" things do not move. You folks over at WICG were "agressive" with the absurd 1,000 year ban you imposed on me. That was pure reprisal, because you simply have not dealt with a real one before. I was not focusing on that individual - individually - my point, which you appear to still not get, in spite of your presumed position in these groups, etc., is that QuicTransport should have been left alone until the WebTransport changes were completed by vendors, so we would not be here, with several issues asking for HTTP/3 code to be developed while working QuicTransport code was deprecated/removed. That was simply not a sound decision, and if you think you are immune from being vetted, scrutinized, then I am telling you that you are not. 

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

I told you, I have been and am calm. If you feel my energy that is because my energy is piercing and powerful, yet without rancor. You are just not used to an individual such as myself. "respect", again, is an emotion that you must govern yourself. I don't need your "respect". I purvey my wares in several industries simultaneously, and perform primary source research of the highest order, which my clientsin the legal field certainly do not say do not be "agressive" with re my research acumen.

The "calm" term you use is rather preposterous. As if you can discern my termperment via reading my words on a screen. I am direct. I perform rigorous testing of code. As Run The Jewels say in Report to the Shareholders/Kill Your Master: "I will not be confused for docile..." I have done nothing but be constructive in all of the threads I post in or begin. It is not my fault individuals were raised in coddled little cul de sacs, got their letters from some fancy institution, and never had to deal with the lay of the land in the field across the tracks wherever they may reside. They stay on the other side of the tracks and pretend to be "offended" when they come across a real one that sees through their omissions and negligence and is not impressed with any letters behind their name. 

I am certain the vast majority of the folks on this board would not last 2 minutes in either of the industries I work in. Fingernails get dirty, fingerprints worn off, back always on fire, and that is before lunch. With regard to research, well, I am an expert on "race" theory; that took 4 years alone, on my own time, and I had to be "agressive" with my questions to get to the root of that fraud.

If/when we meet in person, you, perhaps, will grasp where I am coming from. Where you have never been and do not want to go. You would hardly survive a night talking about stay calm and don't be agressive. There was never a single day where I grew up that everybody was not "agressive", and if you were not, well, then you would be immediately manipulated, abused, pockets snatched off, shoes taken off, or you would take off your own shoes and hand them over with your "calm" suggestion.

Maybe we should arrange for a video/audio conference, so you can get a clue as to with whom you are dealing.

You can ban me if you want. I will just add that to the rest of the fraudulent bans you and the others who imposed them upon me have imposed. Because you really cannot deal with a through and through individual from where you have never been, yet has read the entirety of European and U.S. history, and can code at the front end, well versed in English literature and law and science, and still ain't doing no running when the sh*t goes down. 

Yes, I am direct. If you color that directness "agressive", well, I'll take that. No eagle has caught a salmon out of the rive being tame and non-agressive.