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

From: Bernard Aboba <[email-masked]>
Date: Wed, 10 Jul 2019 12:59:45 -0700

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.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 11 Jul 2019 10:34:55 +0200

On Wed, 10 Jul 2019 at 21:59, Bernard Aboba <[email-masked]> wrote:
>
> 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?"

Actually I did not say that 👆

:)

-- 
Iñaki Baz Castillo
<[email-masked]>