I’ve been trying to reach out to people shipping games for the Web and gather their thoughts on this proposal. Jukka Jylänki (Unity) provided the following comments, which I found really helpful:
Pthatcher’s notes on the missing gaps (unordered datagrams, avoiding head-of-line blocking) are spot on. Something I’d like to highlight here is that WebRTC data channels did add UDP-like communication, but because of the complexity involved in implementing both a client and a server stack for WebRTC data channels, adoption has remained practically zero in games. Contrast this to WebSockets, which is quite lightweight in its definition, and much easier for a programmer to implement a client stack or a server stack to converse in WebSockets.
In order for any kind of new server-client protocol spec to be successful, it is not enough that there is a spec for the feature that browser/shell vendors implement as part of a tight spec+development iteration cycle, but the spec needs to be friendly towards independent implementors who need to ground up build a stack to talk the protocol. Back with WebRTC the browser implementations were initially riddled with quirks that were not well defined in the spec, and Chrome and Firefox had a long tail of bug bashing work stemming from confusion with unspecified scenarios, due to the complexity of the spec. So I would like to stress how important it is that a protocol spec of this kind is built up with simplicity and practicality in focus, keeping independent implementations in mind. Reading through https://pthatcherg.github.io/web-transport/ , it has user guide examples, and from there the transport spec leads to https://tools.ietf.org/html/draft-pauly-quic-datagram-02 which is a bit short treatise - so I am not sure how much work will currently be involved in implementing the protocol stack.
In summary, “implementor’s guide” is as important as “user’s guide”, or perhaps even more important, to guarantee adoption.
It is great to see efforts on this front progress - game networking with WebSockets is really painful, and game networking with WebRTC data channels is too messy to pull off.
I think the part about independent implementers matches with what we’ve been trying to achieve with QuicTransport design: minimizing the gap between basic QUIC and QUIC as useful for the web.