Re: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing

[Bernard Aboba <[e-mail]>]

On Nov 8, 2017, at 12:49, Martin Thomson <[e-mail]> wrote:
> 
> You need to be really crisp about your assumed deployment model here.
> 
> Let's say that you want to do data channels over QUIC.  

[BA] That might come later, but would require additional standards work to define the protocol for support of data channels run over QUIC.

So for now, the goal is to support the use of peer-to-peer QUIC streams, as described in the QUIC transport document. 

> That seems the
> most plausible model, mainly to drive down the number of round trips
> between session signaling and session use.  I can imagine a very
> simple mapping of the data channel protocol would work nicely.

[BA] Since there are applications that can make use of QUIC streams, the immediate goal is to provide JS access to that.  Support for RTCDataChannels can be built on top of this in a JavaScript library once RTCDataChannel over QUIC protocol is worked out. 

> In that case, as I suggested, keying SRTP using QUIC is feasible, even
> trivial.  No DTLS.

[BA] Indeed, this might be a good idea, particularly in scenarios where only QUIC is used and not the SCTP/DTLS/UDP data channel.  However, we’re not there yet - I’m not clear that QUIC as defined in the QUIC transport document can substitute for the SCTP/DTLS/UDP data channel in every conceivable scenario.  Also, existing implementations use DTLS/SRTP.  So we don’t want to rule out multiplexing of QUIC and DTLS, even if that might not be necessary long-term. 

> Or, as you explore in the rtpfolks draft, you want to do RTP over
> QUIC.  That seems far less of a short term goal, but I'll humor you.

[BA] Definitely not a short term goal because that kind of a change would appear to require significant discussion and standards development, as well as a much bigger change to implementations than merely using QUIC for peer-to-peer data exchange.
> 
> There's a draft about that:
> https://datatracker.ietf.org/doc/draft-tiesel-quic-unreliable-streams/.
> It turns out to be possible, even if we might quibble about some of
> the details in that draft.  A mapping should be straightforward.

[BA] It doesn’t look complicated, but I’m not aware of any implementations and it has been ruled out of scope for the QUIC WG, so we don’t want support for peer-to-peer QUIC data exchange to depend on it.  

> I'd prefer to work on QUIC-SRTP and datachannels-over-quic than worry
> about these contingencies.  That way you have a much smaller pool of
> protocols to mash together.

[BA] You are most welcome to work on those things.  But as noted above, the potential need to utilize QUIC and SCTP data channels simultaneously means that you still need to multiplex QUIC and DTLS, at least in the short term.  Also, since RTCDataChannel can be built on top of the QUIC stream API, work on that protocol isn’t a gating factor either.