Re: [dispatch] Dispatching WebTransport (boiling it down)

[Bernard Aboba <[e-mail]>]

Inaki Baz Castillo said:

"if this is a pure client-to-server transport, why is webrtc mentioned in
the background at all? shouldn't this be a replacement of websockets and
NOT of the webrtc datachannels?"

[BA] Indeed.  The protocol proposals in draft-vvv-webtransport-quic and
draft-vvv-webtransport-http3 relate to the client/server scenario, and so
issues relating to peer-to-peer operation, ICE, WebRTC, W3C APIs, etc. seem
to be peripheral.

To my mind, draft-vvv-webtransport-http3 appears to raise the following
question:

"Do we need additional work to update "Bootstrapping WebSockets with HTTP/2"
(RFC 8441), in order to enable bootstrapping {bi-directional stream,
uni-directional stream, datagrams} on HTTP/3"?

Given that QUIC offers relief from TCP's head-of-line blocking problems,
one can make the case that WebTransport(s) over HTTP/3 will perform better
than WebSocket(s) over HTTP/2. Also, I can see uses for a uni-directional
stream (server -> client or client -> server). And with the recent interest
in streaming over unreliable transport (e.g. SRT), the datagram mode could
come in handy as well.

Since draft-ietf-quic-transport only covers bi-directional and
uni-directional streams, it might make sense to focus on that functionality
initially and then add datagrams support once we understand how and where
QUIC datagrams (as described in draft-pauly-quic-datagram ) will be
progressed.