Subject: Fwd: New Version Notification for draft-aboba-avtcore-quic-multiplexing-00.txt

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 Oct 2017 19:18:56 -0700

A new version of I-D, draft-aboba-avtcore-quic-multiplexing-00.txt
has been successfully submitted by and posted to the IETF
repository.

Name:           draft-aboba-avtcore-quic-multiplexing
Revision:       00
Title:          QUIC Multiplexing
Document date:  2017-10-23
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-aboba-avtcore-
quic-multiplexing-00.txt
Status:         https://datatracker.ietf.org/doc/draft-aboba-avtcore-quic-
multiplexing/
Htmlized:       https://tools.ietf.org/html/draft-aboba-avtcore-quic-
multiplexing-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-aboba-avtcore-
quic-multiplexing-00

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

---

From: Roni Even <[email-masked]>
Date: Thu, 26 Oct 2017 06:47:41 +0000

Hi,
When looking at the problem in the WEBRTC contents I am wondering if we cannot address it without multiplexing.
The use case is when bundling the RTP media streams with the Data channel.

1.       If we bundle RTP over QUIC and Data channel over QUIC using the same QUIC connection there is no problem.

2.       If we use RTP over QUIC is there any reason to run the data channel over UDP/DTLS/SCTP? If yes we need to address it also in the Heuristic option

3.       If we use RTP over UDP/DTLS and the Data channel over QUIC it is discussed in the Heuristic section but it seems like the recommendation there is  for WEBRTC to mandate that the Data channel in this case will use UDP/DTLS/SCTP . I think that UDP/DTLS/SCTP provides similar functionality to QUIC

I think that this document is still needed for a general case when we bundle RTP with QUIC not for the WEBRTC case but still wonder if when RTP is over UDP/DTLS why use QUIC for a bundled non RTP data and not leverage the UDP/DTLS connection or why not run RTP over QUIC in this case.

Roni Even

From: QUIC [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: יום ה 26 אוקטובר 2017 05:19
To: [email-masked]
Subject: Fwd: New Version Notification for draft-aboba-avtcore-quic-multiplexing-00.txt

Name:           draft-aboba-avtcore-quic-multiplexing
Revision:       00
Title:          QUIC Multiplexing
Document date:  2017-10-23
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-aboba-avtcore-quic-multiplexing-00.txt
Status:         https://datatracker.ietf.org/doc/draft-aboba-avtcore-quic-multiplexing/
Htmlized:       https://tools.ietf.org/html/draft-aboba-avtcore-quic-multiplexing-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-aboba-avtcore-quic-multiplexing-00

Abstract:

---

From: Colin Perkins <[email-masked]>
Date: Thu, 26 Oct 2017 12:03:25 +0100

Hi Roni,

It would be possible to run RTP and/or the data channel over QUIC, I agree (although we haven’t yet specified how to do so). 

We still need to either de-multiplex STUN and QUIC on the same port, or re-invent STUN within QUIC, if we want  to run peer-to-peer QUIC.

Colin

> On 26 Oct 2017, at 07:47, Roni Even <[email-masked]> wrote:
> 
> Hi,
> From: QUIC [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Bernard Aboba
> To: [email-masked] <mailto:[email-masked]>
> URL:            https://www.ietf.org/internet-drafts/draft-aboba-avtcore-quic-multiplexing-00.txt <https://www.ietf.org/internet-drafts/draft-aboba-avtcore-quic-multiplexing-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-aboba-avtcore-quic-multiplexing/ <https://datatracker.ietf.org/doc/draft-aboba-avtcore-quic-multiplexing/>
> Htmlized:       https://tools.ietf.org/html/draft-aboba-avtcore-quic-multiplexing-00 <https://tools.ietf.org/html/draft-aboba-avtcore-quic-multiplexing-00>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-aboba-avtcore-quic-multiplexing-00 <https://datatracker.ietf.org/doc/html/draft-aboba-avtcore-quic-multiplexing-00>
> 
> 
> Abstract:

-- 
Colin Perkins
https://csperkins.org/

---

From: Roni Even <[email-masked]>
Date: Thu, 26 Oct 2017 11:43:26 +0000

Hi Colin,
So there is a case of STUN and QUIC but without RTP for establishing the QUIC peer to peer. It becomes a simpler problem if we recommend to not multiplex RTP and QUIC (using RTP over QUIC which we started to specify).  This is not a problem if STUN is before QUIC starts or with QUIC long header.

The major reason I see for not multiplexing RTP and QUIC is the need have two security context one for RTP and one for QUIC  so in this case if RTP is used I suggested as also mentioned in the document to use UDP/DTLS/SCTP for the data channel and not QUIC since SCTP over UDP/DTLS  is quiet similar to QUIC  .

So the question is what we want to address in the multiplexing, do we need to multiplex everything or can we define the relevant subset (RTP and data multiplexed over QUIC or RTP and data multiplexed without QUIC) before going to a solution. It may make the solution simpler.

I can agree that we may fail in providing a good solution for RTP over QUIC but that can lead to the RTP over UDP/TLS and data over udp/dtls/sctp option leaving the need for STUN and QUIC for peer to peer connection.

Roni

From: Colin Perkins [mailto:[email-masked]]
Sent: יום ה 26 אוקטובר 2017 14:03
To: Roni Even
Cc: Bernard Aboba; [email-masked]
Subject: Re: New Version Notification for draft-aboba-avtcore-quic-multiplexing-00.txt

Hi Roni,

Colin

On 26 Oct 2017, at 07:47, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Roni Even

From: QUIC [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: יום ה 26 אוקטובר 2017 05:19
To: [email-masked]<mailto:[email-masked]>
Subject: Fwd: New Version Notification for draft-aboba-avtcore-quic-multiplexing-00.txt

Abstract:

--
Colin Perkins
https://csperkins.org/

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Oct 2017 08:47:07 -0700

In the short term, the most likely utilization of QUIC in WebRTC (other
than signaling) would be data exchange.  In that scenario,
RTP/RTCP/STUN/TURN would need to be multiplexed with QUIC, as would DTLS
(used for DTLS-SRTP, even if there was no usage of the SCTP data channel).

So while RTP over QUIC is certainly possible in the long-term, the
multiplexing problem still exists in the short term.

On Wed, Oct 25, 2017 at 11:47 PM, Roni Even <[email-masked]> wrote:

> 1.       If we bundle RTP over QUIC and Data channel over QUIC using the
> same QUIC connection there is no problem.
>
> 2.       If we use RTP over QUIC is there any reason to run the data
> channel over UDP/DTLS/SCTP? If yes we need to address it also in the
> Heuristic option
>
> 3.       If we use RTP over UDP/DTLS and the Data channel over QUIC it is
> discussed in the Heuristic section but it seems like the recommendation
> there is  for WEBRTC to mandate that the Data channel in this case will use
> UDP/DTLS/SCTP . I think that UDP/DTLS/SCTP provides similar functionality
> to QUIC
>
>
>
> I think that this document is still needed for a general case when we
> bundle RTP with QUIC not for the WEBRTC case but still wonder if when RTP
> is over UDP/DTLS why use QUIC for a bundled non RTP data and not leverage
> the UDP/DTLS connection or why not run RTP over QUIC in this case.
>
>
>
> Roni Even
>
>
>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Bernard Aboba
> *Sent:* יום ה 26 אוקטובר 2017 05:19
> *To:* [email-masked]
> *Subject:* Fwd: New Version Notification for draft-aboba-avtcore-quic-
> multiplexing-00.txt
>
>
>
>