Victor
unread,Aug 1, 2020, 11:39:16 PM8/1/20Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to web-transport-dev, bernar...@gmail.com, web-transport-dev, Luke Curley, yhi...@chromium.org, 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
- WebTransport should be built on top of HTTP3, getting most of its features, but adding overhead;
- 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;
- 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.