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

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Nov 2017 18:04:55 +1100

This is a timely contribution.  We'll be discussing this in the first
QUIC session at IETF 100 (Tuesday 1330).  I encourage people who care
about this topic to attend.  I won't be present for the Thursday
morning avtcore session, so I thought that I'd provide my input on the
list.

I think that there are several considerations the draft doesn't give
due consideration.

First is the set of things that need to be multiplexed.  The draft
mostly seems to assume that everything needs to be multiplexed with
everything else.  This is not necessary, as far as I can see.

- I still don't understand why RFC 7983 gives TURN channels top
billing.  If I'm talking to a TURN server, that link only ever sees
STUN and TURN channels.  I would not expect to see SRTP.  I might see
DTLS if I was using STUN over DTLS, but I wouldn't expect to see QUIC.

- I don't know if we care about ZRTP.

- I don't see any case for needing to demux DTLS and QUIC.  The draft
talks about DTLS-SRTP for keying SRTP, but the observation I'd make
here is that QUIC has a TLS handshake.  That handshake can happily
carry the use_srtp extension.  In other words, if you are serious,
QUIC-SRTP isn't that much of a stretch.

- If RTP is being sent *inside* QUIC, you don't care about demux
between QUIC and SRTP any more.  I guess you could send RTP in two
places between the same two peers, but that seems like something that
could be ruled out.

Second is that this doesn't really give due credit to the role of
signaling in protecting properties you care about.  For instance, one
of the gnarlier bits of the multiplexing puzzle is the QUIC Version
Negotiation packet, which doesn't include any integrity check (as of
this moment, that is).  Signaling could be used to ensure that Version
Negotiation never has to happen.  It also opens up other more ...
disruptive ... options as well.

Third is the strategies that the draft proposes.  I agree that these
are three options (I've a few corrections on my suggested strategy to
add below).  But this list is not exhaustive.

Option 0: crypto

An important observation to make is that (almost) all the packets that
need to be demultiplexed use a cryptographic integrity check in some
form (MESSAGE-INTEGRITY, HMAC, AEAD, etc...)  That means that if all
else fails, an implementation could feed every packet to every stack
and the right thing would happen.  Keep that in mind when it comes to
this discussion, because it highlights the fact that this is all about
optimization.

Option 4: a new QUIC version

As I observed, if version negotiation is possible, then negotiating a
new QUIC version is possible.  That new version could be defined with
maximum compatibility for multiplexing.  For instance, it might define
new packet types that cause critical messages to land in gaps in the
RFC 7983 table.  It is possible that this is the ONLY change that it
makes - QUIC versions numbers are inexpensive.

On the heuristics option, there are a few things:

- I would never consider DTLS-SRTP in addition to QUIC if you have QUIC-SRTP.

- the document should talk about reordering a little.  Application
data in QUIC can arrive before the final handshake packets.  This
isn't something I originally mentioned, but it does have an effect on
the multiplexing scheme.  The potential for overlap is transitory
though.

- just bundle the initial ICE checks with the consent checks when
talking about this. You could find a way to disable ICE-level consent
and replace it with QUIC PING/PONG, but I don't see the point.

A few (minor) errors:

- clause 2.a is a non-requirement, because QUIC Initial, Handshake,
Retry, and 0-RTT packets have to use the long header; similarly,
clause 3.a is a non-requirement, because 1-RTT protected packets have
to use the short header (though this is a recent change); that
invalidates the alternative in clause 3.c.i.
- clause 3.d.i talks about collisions (on the first octet) between
QUIC handshake packets and STUN, but handshake packets always have the
high bit of the octet set.  STUN actually conflicts with all QUIC
packets.

Finally, I would say that the multiplexing scheme that realtime
protocols use doesn't have any sort of architectural or moral right to
continue to exist.  The draft implies that multiplexing in the way
enshrined in RFC 7983 is some goal that needs to be protected, even as
new protocols are added into the mix.  I don't think that claim is
necessarily true.

RFC 7983 describes a protocol.  That protocol is the composit of up to
5 protocols.  Those protocols were simply glued together and by some
combination of luck and planning they avoided collisions.  Any new
protocol either fits into this scheme or not.

If we want that new protocol to fit, and can make it happen, great,
but that doesn't mean that every new protocol has to fit.  Insisting
that all protocols that use UDP fit into this system is not
sustainable.  There's little enough free space left already.

For this reason, the option where modifications are made to QUIC is a
bad option.  Not because QUIC can't afford the bits, but more for the
precedent it establishes.  (I recall similar objections from the TLS
people, and rightly so.)

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Nov 2017 10:03:59 +0000

Hi,

A few initial questions:

Q1:
-----

The Abstract says:

   "This document describes potential approaches to multiplexing of QUIC
   along with RTP, RTCP, DTLS, STUN, TURN and ZRTP in WebRTC peer-to-
   peer data exchange."

Is there a reason why this is limited to WebRTC?

And, if it is, I think it should be indicated in the draft title. "QUIC Multiplexing for WebRTC", or something like that.

Q2:
-----

Is the intention to include SDP O/A procedures in the draft?

Regards,

Christer

-----Original Message-----
From: avt [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: 08 November 2017 09:05
To: [email-masked]
Subject: [AVTCORE] Comments on draft-aboba-avtcore-quic-multiplexing

This is a timely contribution.  We'll be discussing this in the first QUIC session at IETF 100 (Tuesday 1330).  I encourage people who care about this topic to attend.  I won't be present for the Thursday morning avtcore session, so I thought that I'd provide my input on the list.

I think that there are several considerations the draft doesn't give due consideration.

First is the set of things that need to be multiplexed.  The draft mostly seems to assume that everything needs to be multiplexed with everything else.  This is not necessary, as far as I can see.

- I still don't understand why RFC 7983 gives TURN channels top billing.  If I'm talking to a TURN server, that link only ever sees STUN and TURN channels.  I would not expect to see SRTP.  I might see DTLS if I was using STUN over DTLS, but I wouldn't expect to see QUIC.

- I don't see any case for needing to demux DTLS and QUIC.  The draft talks about DTLS-SRTP for keying SRTP, but the observation I'd make here is that QUIC has a TLS handshake.  That handshake can happily carry the use_srtp extension.  In other words, if you are serious, QUIC-SRTP isn't that much of a stretch.

- If RTP is being sent *inside* QUIC, you don't care about demux between QUIC and SRTP any more.  I guess you could send RTP in two places between the same two peers, but that seems like something that could be ruled out.

Second is that this doesn't really give due credit to the role of signaling in protecting properties you care about.  For instance, one of the gnarlier bits of the multiplexing puzzle is the QUIC Version Negotiation packet, which doesn't include any integrity check (as of this moment, that is).  Signaling could be used to ensure that Version Negotiation never has to happen.  It also opens up other more ...
disruptive ... options as well.

Third is the strategies that the draft proposes.  I agree that these are three options (I've a few corrections on my suggested strategy to add below).  But this list is not exhaustive.

Option 0: crypto

An important observation to make is that (almost) all the packets that need to be demultiplexed use a cryptographic integrity check in some form (MESSAGE-INTEGRITY, HMAC, AEAD, etc...)  That means that if all else fails, an implementation could feed every packet to every stack and the right thing would happen.  Keep that in mind when it comes to this discussion, because it highlights the fact that this is all about optimization.

As I observed, if version negotiation is possible, then negotiating a new QUIC version is possible.  That new version could be defined with maximum compatibility for multiplexing.  For instance, it might define new packet types that cause critical messages to land in gaps in the RFC 7983 table.  It is possible that this is the ONLY change that it makes - QUIC versions numbers are inexpensive.

- the document should talk about reordering a little.  Application data in QUIC can arrive before the final handshake packets.  This isn't something I originally mentioned, but it does have an effect on the multiplexing scheme.  The potential for overlap is transitory though.

- just bundle the initial ICE checks with the consent checks when talking about this. You could find a way to disable ICE-level consent and replace it with QUIC PING/PONG, but I don't see the point.

A few (minor) errors:

- clause 2.a is a non-requirement, because QUIC Initial, Handshake, Retry, and 0-RTT packets have to use the long header; similarly, clause 3.a is a non-requirement, because 1-RTT protected packets have to use the short header (though this is a recent change); that invalidates the alternative in clause 3.c.i.
- clause 3.d.i talks about collisions (on the first octet) between QUIC handshake packets and STUN, but handshake packets always have the high bit of the octet set.  STUN actually conflicts with all QUIC packets.

Finally, I would say that the multiplexing scheme that realtime protocols use doesn't have any sort of architectural or moral right to continue to exist.  The draft implies that multiplexing in the way enshrined in RFC 7983 is some goal that needs to be protected, even as new protocols are added into the mix.  I don't think that claim is necessarily true.

RFC 7983 describes a protocol.  That protocol is the composit of up to
5 protocols.  Those protocols were simply glued together and by some combination of luck and planning they avoided collisions.  Any new protocol either fits into this scheme or not.

If we want that new protocol to fit, and can make it happen, great, but that doesn't mean that every new protocol has to fit.  Insisting that all protocols that use UDP fit into this system is not sustainable.  There's little enough free space left already.

For this reason, the option where modifications are made to QUIC is a bad option.  Not because QUIC can't afford the bits, but more for the precedent it establishes.  (I recall similar objections from the TLS people, and rightly so.)

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 8 Nov 2017 11:46:09 -0500

> sustainable.  There's little enough free space left already.

+1

The technique of 9783 is a hack to avoid formalizing another layer in 
the protocol stack.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Nov 2017 10:49:38 -0800

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.

Supporting multiplexing of DTLS and QUIC allows QUIC usage scenarios to be
progressively rolled out as standards and implementation work is completed,
rather
than requiring that everything be done before anything can happen.

While QUIC may eventually be widely used for SRTP keying (QUIC-SRTP),
trasnport of RTP, and all data exchange scenarios (obsoleting the existing
SCTP/DTLS/UDP data channel), it seems unwise to mandate that all of those
QUIC uses be standardized and successfully deployed before enabling
the first step toward  peer-to-peer use of QUIC by enabling QUIC data
exchange.

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.

Martin also said:

"If we want that new protocol to fit, and can make it happen, great,
but that doesn't mean that every new protocol has to fit. "

[BA] I would agree that attempting to support "every new protocol" would be
difficult and unnecessary.  On the other hand, QUIC may not be the last
protocol that needs to multiplex with other protocols covered by RFC 7983,
so
that figuring out how this works is important.

---

From: Adam Roach <[email-masked]>
Date: Wed, 8 Nov 2017 13:13:13 -0600

[as individual]

On 11/8/17 12:49 PM, Bernard Aboba wrote:
> protocol that needs to multiplex with other protocols covered by RFC 
> 7983, so

It worked by pure luck. I agree with Martin: that's not a sustainable 
model. I'm kind of ambivalent about the QUIC work under discussion 
(mostly because I haven't looked at the use cases in detail), but if 
you're envisioning some kind of UDP-wide /etc/magic approach, I urge you 
to stop.

/a

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Nov 2017 12:44:30 -0800

> On Nov 8, 2017, at 11:13, Adam Roach <[email-masked]> wrote:
> 
> It worked by pure luck. I agree with Martin: that's not a sustainable model. I'm kind of ambivalent about the QUIC work under discussion (mostly because I haven't looked at the use cases in detail), but if you're envisioning some kind of UDP-wide /etc/magic approach, I urge you to stop.

[BA] We’re not trying to boil the ocean - just enable peer-to-peer QUIC data exchange based on the QUIC transport document.  Other uses of QUIC may also come along, but we don’t want to be gated on those other uses and standards which may (or may not) ever come to fruition. 

And yes, RFC 7983 seems more like documentation of fortuitous circumstances than an  extensible architecture - particularly with respect to the IANA allocations section.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Nov 2017 07:49:56 +1100

> 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.

> 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.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Nov 2017 12:52:42 -0800

Christer said: 

“Is this just for WebRTC?”

[BA] It’s for use by applications that could need to multiplex QUIC with the other applications covered by RFC 7983.  So that need could be shared more widely than WebRTC. 

“What about SDP?”

[BA] The draft is focused on multiplexing.  How QUIC integrates with SDP and things like BUNDLE is a distinct problem and will require other documents. In general, it seems like a better idea to handle those questions separately than to attempt to wedge a new feature into BUNDLE, for example.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Nov 2017 13:12:33 -0800

On Nov 8, 2017, at 12:49, Martin Thomson <[email-masked]> wrote:
> 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

[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

[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. 

> 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.
> 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.  

> 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.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Nov 2017 09:50:05 +1100

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

Can you unpack that a little more?  QUIC is a generic protocol.
Presumably you have an application (protocol) in mind.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Nov 2017 15:21:39 -0800

> Presumably you have an application (protocol) in mind.

[BA] Some immediate use cases: 

1. Embedded systems.  These devices often want to utilize as little code as possible. If they are already incorporating client-server QUIC (for use with HTTP/2), then using QUIC for a reliable data channel as well will be natural, particularly if the devices do not need to inter-operate with browsers that only support the SCTP data channel. 

2. File transfer along with audio and video. QUIC supports pluggable congestion control, which SCTP implementations typically do not. This means that QUIC congestion control can be made to be friendly with the congestion control mechanisms utilized for audio and video (such as the algorithms discussed in RMCAT).  In contrast, the aggressive loss-based congestion control of SCTP builds queues that can result in additional delay, degrading audio and video.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Nov 2017 10:57:53 +1100

> [BA] Some immediate use cases:

What protocol would these use?  You don't just "use" QUIC and more
than you "use" TCP.

I can believe that you want something simpler than the datachannel
protocol, but it seems like you aren't far from that when you talk
about these use cases.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Nov 2017 17:56:15 -0800

Use cases based on reliable QuicStreams are most ready for implementation based on the QuicTransport/QuicStream Javascript API Peter described at W3C TPAC.

The data channel API isn’t needed where bare QuicStreams can do the job and data chsnnel does not support back pressure so it can be an awkward fit in situations where the receiver might not be able to keep up (such as embedded).

> On Nov 8, 2017, at 3:57 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Nov 2017 13:03:55 +1100

The back pressure thing is - I think - just a matter of lack of
attention.  I think that all the pieces are in place.  Gluing JS
streams to the websockets API might be all that is needed.

I'll have to look at Peter's proposed API now.  This is the first I've
heard of it.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Nov 2017 18:11:45 -0800

Proposal starts at slide 86 here:
https://docs.google.com/presentation/d/1Sg_1TVCcKJvZ8Egz5oa0CP01TC2rNdv9HVu7W38Y4zA/edit

> On Nov 8, 2017, at 6:03 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 8 Nov 2017 22:11:59 -0500

> 2. File transfer along with audio and video. QUIC supports pluggable congestion control, which SCTP implementations typically do not. This means that QUIC congestion control can be made to be frien…

What this sounds like to me is:
we don't like RTCWeb and want to try again based on QUIC.

Or did I misunderstand?

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Nov 2017 19:20:15 -0800

> we don't like RTCWeb and want to try again based on QUIC.

[BA] The draft is only about enabling multiplexing of peer-to-peer QUIC data exchange.  In particular, it takes the position that adding multiplexing support for QUIC data exchange shouldn’t require massive changes to the rest of the RTCWEB protocol stack (such as requiring that RTP run over QUIC, that QUIC-SRTP be used, or that the SCTP data channel be abandoned. 

Those other uses of QUIC might or might not be good things, but they are orthogonal to use of QUIC purely for peer-to-peer data exchange.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Nov 2017 14:33:43 +1100

Thanks for the pointer.

This probably needs a more strategic approach.  I agree with the
notion that there is value in letting websites choose their
mechanisms, but this would have a third thing added to the platform
that looks like a websocket.  Maybe it's time to talk about layers:
one for the type of communications medium, one for the application
contract (ordered, unordered, reliable, not, etc...).

It is basically just datachannels over QUIC.  Which necessarily means
a new protocol (Peter outlines some of the ways in which that protocol
might be designed to use QUIC, and those seem like reasonable things).

On Thu, Nov 9, 2017 at 1:11 PM, Bernard Aboba <[email-masked]> wrote:
> Use cases based on reliable QuicStreams are most ready for implementation
> based on the QuicTransport/QuicStream Javascript API Peter described at W3C
> TPAC.
>
>
> The data channel API isn’t needed where bare QuicStreams can do the job and
> data chsnnel does not support back pressure so it can be an awkward fit in
> situations where the receiver might not be able to keep up (such as
> embedded).
>
>
> 1. Embedded systems.  These devices often want to utilize as little code as
> possible. If they are already incorporating client-server QUIC (for use with
> HTTP/2), then using QUIC for a reliable data channel as well will be
> natural, particularly if the devices do not need to inter-operate with
> browsers that only support the SCTP data channel.
>
>
> 2. File transfer along with audio and video. QUIC supports pluggable
> congestion control, which SCTP implementations typically do not. This means
> that QUIC congestion control can be made to be friendly with the congestion
> control mechanisms utilized for audio and video (such as the algorithms
> discussed in RMCAT).  In contrast, the aggressive loss-based congestion
> control of SCTP builds queues that can result in additional delay, degrading
> audio and video.