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

[Martin Thomson <[e-mail]>]

On Thu, Nov 9, 2017 at 5:49 AM, Bernard Aboba <[e-mail]> wrote:
> Martin said:
>
> "- I don't see any case for needing to demux DTLS and QUIC."
>
> [BA] Demuplexing of QUIC and DTLS is a requirement for initial deployments
> of
> peer-to-peer QUIC data exchange, since in those initial deployments
> DTLS-SRTP,
> SRTP/SRTCP and even the SCTP/DTLS/UDP data channel will continue to be used.

You need to be really crisp about your assumed deployment model here.

Let's say that you want to do data channels over QUIC.  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.

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

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.
In that case, you have no SRTP in the mix.  Then I'll concede that you
might have an issue... But only if you can't finish the data channel
work first.  That seems like an unlikely scenario given the
complexities involved.

If that does happen, then yes, things get unpleasant.  But I'd be
inclined to argue for modifications to QUIC (in the sense of a new
QUIC version more than a change in the fundamental protocol
invariants) or a shim in that case.

> At the moment, it is not even clear that peer-to-peer QUIC data exchange
> based on the QUIC transport document can completely substitute for all of
> the potential uses of the SCTP data channel (such as unreliable, low-latency
> data exchange in games), so that applications could conceivably wish to use
> both the SCTP data channel and QUIC data exchange in their applications.

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.

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.