Re: [dispatch] Dispatching WebTransport

[Iñaki Baz Castillo <[e-mail]>]

On Mon, 17 Jun 2019 at 16:52, Sergio Garcia Murillo
<[e-mail]> wrote:
>
> From the draft:
>
>    WebTransport [OVERVIEW] is a protocol framework that enables clients
>    constrained by the Web security model to communicate with a remote
>    server using a secure multiplexed transport.
>
>
> Although while I agree with your analysis regarding current webrtc dc and sctp status, 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?

I assume WebRTC is mentioned there because currently it's the only way
to have P2P data messaging in the Web. With QUIC + RTCIceTransport we
have RTCQuicTransport, which can be used for P2P data messaging
between browsers without depending on a WebRTC PeerConnection.

So if I'm not wrong, WebTransport will provide:

1) QuicTransport, which is a QUIC based communication between the
browser and a server. It may use streaming or datagram based messaging
(if QUIC-datagram spec becomes real). It does not use ICE at all and.

2) RTCQuicTransport, which is a QuicTransport created with a
RTCIceTransport, so suitable for two browsers to communicate in P2P
fashion. And the same: QUIC streaming or datagrams. No PeerConnection
here.

Whether SCTP can be used or not in this new model is unclear for me.
SCTP does not provide security/encryption, so SCTP packets should be
put on top of DTLS (as we do in WebRTC) or on top of QUIC (so it
should be QUIC-datagram to properly frame those packets) which does
not make any sense since it provides nothing that QUIC-datagram
already provides.

-- 
Iñaki Baz Castillo
<[e-mail]>