Re: QUIC and WebRTC Comments

On Jan 9, 2018, at 16:34, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> Replacing RTP is self-evidently a massive
> project that is unlikely to be viable in the short term, so that's
> clearly not ready for consideration.

[BA] Yes, it’s way to early to know what that would require.

> An API for direct use of QUIC means that browsers no longer control
> access to the protocol.  If you wanted to use this direct API at the
> same time as one of the browser-native uses of QUIC like data
> channels, then your only option is to have two (or more) QUIC
> connections.  

[BA] That may depend on whether distinct uses can reuse the same QuicTransport object.  As an example, SRTP keyed with QUIC-SRTP should be able to coexist with QUIC data transport, much as data channel does with SRTP keyed by DTLS-SRTP today.

RTP (or media) over QUIC would be a more difficult example, but hard to judge without more details.

With respect to RTCDataChannel over QUIC, the issues may depend on how QuicStreams are allocated and the mapping of data channels to QuicStreams. 
Initial thinking was that unreliable data channel messages would be sent within a distinct QuicStream, with a header that mapped the QuicStream to a data channel and provided other info.  So the header design might need to take into account how to multiplex a data channel with something else (e.g. media) on the same QuicTransport.

> That introduces new complications around shared
> congestion control (if the connections use the same path, but how can
> you be sure about that even if the endpoints are the same?)

[BA] Bundled SCTP data channel and SRTP isn’t much different from bundled QUIC data and SRTP.  However, trying to transmit QUIC data and media using the same QuicTransport could create some tricky congestion control issues. 

> and maybe even multiplexing (it's possible to have two QUIC connections share a
> 5-tuple, but then you need to have connection IDs, which ruins the
> work we did to make QUIC multiplex cleanly with STUN).

[BA] The multiplexing proposal discussed in QUIC WG and AVTCORE assumes only a single QuicTransport (but potentially many QuicStreams) between two endpoints. This is probably ok if only QUIC data is considered, but might not work so well if you wanted both QUIC data and media. 

> A QUIC API needs both support for both unidirectional and
> bidirectional streams.  

[BA] Bi-directional streams were put in first, pending the addition of uni-directional streams to the QUIC transport document. Looking at EKR’s presentation, supporting both seems feasible (though minimizing complexity might be a challenge). 

> Similarly, stream states need updating to
> match the specification (not all states need to be reflected, but the
> current state doesn't match the protocol at all).

[BA] The states do differ somewhat, mostly due to complexities introduced by the half-closed state. I suspect that the change to uni-directional stream support will simplify things and reduce the differences. 

> I very much like that the API does not expose stream identifiers.
> Please keep that.  That said, it's probably a good idea to make them
> accessible on debug consoles and the like for troubleshooting
> purposes.

[BA] Hopefully the mapping of RTCDataChannels to QuicStreams won’t require stream identifiers to be surfaced.

> Obviously, it's early yet and there's a lot more to do. 

[BA] Definitely.

Received on Wednesday, 10 January 2018 04:01:45 UTC