QuicTransport vs. HTTP3Transport

[Yutaka Hirano]

Hi,

As you may know, we are talking about whether we should specify and implement QuicTransport or HTTP3Transport (or both), in the IETF mailing list. https://mailarchive.ietf.org/arch/msg/webtransport/CEGNLkMqrvug3uPyPmQIXnWVIAY/

If you have any opinions, now is a good time to express them there.

Thanks,

[Luke Curley]

Thanks for the email Yutaka; somehow I didn't even realize there was a working group...

--
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/CABihn6GV8fi%2B4Hmxd79pSKm%3DRawn3evWzOC7mpwbHPqJo6%2BvzQ%40mail.gmail.com.

[Victor]

I've read the discussion linked and would like to share my opinion.

The same way WebSockets feels like a Upgrade from the default Request/Response REST Pattern, I believe WebTransport should too.

Using HTTP3Transport might keep the entry barrier low enough to allow WebDeveloper to feel it was an easy Upgrade, while getting experience with a new tool and pattern.

And if the developer feel the need for an Upgrade, like for example a Heavily Video based VR Web Game, and he finds some limitations on using HTTP3Transport, he should have a simple 'Upgrade' path to QuicTransport, without having to deal with WebRTC as it would be the 'next' alternative.

[Bernard Aboba]

A frequent ask from games developers is “UDP for the Web”. They want this to send “fire and forget” updates or to do audio chat within the game. The mode is either c/s or P2P.

In these uses small footprint and simplicity is key. The developers want datagrams with as low overhead and footprint as possible. Some are currently using WebRTC data channels but find it clumsy and excessively complex.

Typically these developers do not need “more features” than what QuicTransport provides and some ask about slimming down QuicTransport (e.g. no interest in reliable streams, just datagrams).

[Victor]

I'll try to summarize the discussion linked so we are all on the same page:

WebTransport aims to give a low latency UDP-like way to send data to a centralized server. It would be useful in some scenarios  specially in Games. It could allow Real-time Games and, from what I understood, real-time Video and Audio. 

The draft for WebTransport uses QUIC as a back bone, which gives UDP-like features but with added security.

HTTP3 is built on top of QUIC and has a whole bunch of features and metadata on the connection which allows many features, like CORS and DoS protection 'out of the box'.

The current discussion is on about whether 

1. WebTransport should be built on top of HTTP3, getting most of its features, but adding overhead;
2. WebTransport directly on top of QUIC, so it is a more 'direct' communication, but lacking the features mentioned, and others, 'out of the box'. These would be added to the implementation or manually added by the developer;
3. Do both, but we would need to know what they would have in common and different and how that would be informed to the developer, and also having to implement it TWO times.
   

One of the arguments in favor of implementing it on top of HTTP3 is that it would allow developers to use existing HTTP3 connections to both make requests and to make Voice Calls, like in a delivery app were the client might want to take to the delivery agent. Having it on only ONE connection instead of TWO, is better for the server. 

A use case for using BOTH would be a VR Social Game. The game state could be synced with players using WebTransport over HTTP3, so it has the features of HTTP, but the developer could to handle Voice and Video data using WebTransport directly over QUIC, to reduce the latency as much as possible. WebRTC could be seen as the correct solution for Voice and Video. But the whole NAT, STUN and TURN make it hard for a developer to use this tool. They could if they really needed.

My take is that it should be implemented on both, so that it is easier to get started with the new tool, but allowing a upgrade path if needed. But my understanding is that  WebTransport/HTTP3 should go live first, then feedback is gathered on what features WebTransport/QUIC should have/focus on.

[Luke Curley]

My fault for not being part of the working group until now. I started a thread in the working group to catch up to the discussion.

Victor, can you elaborate on the statement about QuicTransport lacking "out of the box" features. As far as I know, Http3Transport has the ability to provide multiplex WebTransport sessions and to provide the origin/path via HTTP headers, but otherwise QuicTransport has identical functionality and "latency".

My problem with Http3Transport is not the feature set, but rather the implementation details. It requires HTTP/3 level changes in a non-backwards compatible way and breaks some of the underlying assumptions about QUIC streams. There's extra risk associated with the complexity of Http3Transport and I don't think it's justified by the slight difference in functionality.

[Victor]

The opinion I presented was based on what I read on the e-mail thread and my limited understanding of what to expect from the WebTransport API, based on other articles about it.

I'll read the drafts to have a more educated opinion on this issue.