Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Mar 2013 10:12:17 +0000

Hi,

>BUNDLE and data muxing works for both "Plan A" and "Plan B". 
>
>Recall that "Plan B" is muxing multiple media sources of the same type over a single m= line, and BUNDLE then provides muxing of the audio, video, and data m= lines.

My understanding (based on the Boston slides, because I haven't read Cullen's plan draft yet) of "Plan B" is that it didn't include BUNDLE - or any other multi-mediatype multiplexing negotiation mechanism - but only multiple SSRCs per m- line.

Regards,

Christer

On Thu, Feb 28, 2013 at 3:10 PM, Ejzak, Richard P (Richard) <[email-masked]> wrote:
Since multiplexing of the data channel with RTP media has been shown as a desirable feature of BUNDLE (and most of its variants), I would suggest that this be treated as a significant advantage for BUNDLE (and similarly capable variants) over any proposal without it.  Cullen's "Plan A" is preferred over Plan B precisely because it has an incremental muxing advantage.

BR, Richard

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christer Holmberg
> Sent: Wednesday, February 27, 2013 2:30 PM
> To: Ted Hardie; [email-masked]
> Cc: Richard Barnes; [email-masked]
> Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB
>
>
> Hi,
>
> Does the Data Channel part (or some other part) of the agenda include
> making a decision on whether it shall be possible to bundle the Data
> Channel with the RTP media?
>
> Or, do we already have consensus that it shall be possible?
>
> Just to clarify, because I think it is important input for the MMUSIC
> discussions on the actual mechanism.
>
> Regards,
>
> Christer
>
>
> ________________________________________
> From: [email-masked] [[email-masked]] on behalf of
> Ted Hardie [[email-masked]]
> Sent: Wednesday, 27 February 2013 7:49 PM
> To: [email-masked]
> Cc: Richard Barnes; [email-masked]
> Subject: [rtcweb] DRAFT Agenda for RTCWEB
>
> The agenda below has been uploaded as an initial, draft agenda for the
> group.  Comments on the timing and balance are encouraged.
>
> thanks,
>
> Ted Hardie
>
> RTCWEB Draft Agenda
> March 12, 2013 9:00 to 11:30
>
> Administrivia (5 min)
>
> AD Message (5 min)
>
> Data Channel
>  - draft-jesup-rtcweb-data-protocol (20 min)
>  - draft-thomson-rtcweb-data (15 min)
>  - draft-marcon-rtcweb-data-channel-management (15 min)
>  - Discussion (30 min)
>  - Consensus call(s) (5 min)
>
> WGLC Issue resolution (30 min)
> - draft-ietf-rtcweb-security
> - draft-ietf-rtcweb-security-arch
> - draft-ietf-rtcweb-overview
> - draft-ietf-rtcweb-use-cases-and-requirements
>
> RTCP-XR (15 min )
> - draft-ietf-rtcweb-rtp-usage-06
>
> FEC in RTCWEB  (Call for interest)
> - draft-mandyam-rtcweb-fecframe-00 (5 min)
>
> Mobile issues for RTCWEB (Call for review)
> - http://tools.ietf.org/html/draft-reddy-rtcweb-mobile-00 (5 min)
>
>
> March 14, 2013 9:00 to 11:30
>
> JSEP
> - draft-rtcweb-jsep (40 min)
> - Discussion (30 min)
> - Consensus call(s) (5)
>
> Video Codec                       10:15 to 11:30
> 1. draft-alvestrand-rtcweb-vp8-01 (15 mins) 2. draft-burman-rtcweb-
> h264-proposal-01+draft-dbenham-webrtcvideomti-01+draft-marjou-rtcweb-
> video-codec-00
> (25 mins)
>       Discussion (30 minutes)
>       Call the question (5 minutes)
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 01 Mar 2013 11:47:54 +0100

> My understanding (based on the Boston slides, because I haven't read Cullen's plan draft yet) of "Plan B" is that it didn't include BUNDLE - or any other multi-mediatype multiplexing negotiation me…
My understanding of Plan B is the same as Justin's.

I remember the statement (or I may have made it) that "with Plan B, 
we're able to live without Bundle (would prefer to have it); with Plan 
A, we're absolutely dependent on Bundle, we can't live without it."

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Mar 2013 12:38:21 +0000

Hi,

>>> Recall that "Plan B" is muxing multiple media sources of the same type over a single m= line, and BUNDLE 
>>> then provides muxing of the audio, video, and data m= lines.
>> My understanding (based on the Boston slides, because I haven't read Cullen's plan draft yet) of "Plan B" is that 
>> it didn't include BUNDLE - or any other multi-mediatype multiplexing negotiation mechanism - but only multiple SSRCs per m- line.
> I remember the statement (or I may have made it) that "with Plan B, we're able to live without Bundle (would prefer 
> to have it); with Plan A, we're absolutely dependent on Bundle, we can't live without it."

If that was the outcome, I'm glad I understood wrong :)

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 1 Mar 2013 10:58:41 -0500 (EST)

> From: "Ejzak, Richard P (Richard)" <[email-masked]>
> 
> Since multiplexing of the data channel with RTP media has been shown
> as a desirable feature of BUNDLE (and most of its variants), I would
> suggest that this be treated as a significant advantage for BUNDLE
> (and similarly capable variants) over any proposal without it.
> Cullen's "Plan A" is preferred over Plan B precisely because it has
> an incremental muxing advantage.

As far as I can tell from my analysis
(http://tools.ietf.org/html/draft-worley-sdp-bundle-04#section-8),
SCTP-over-DTLS can be demuxed from RTP and STUN quite easily.  (This
comes from RFC 5764 section 5.1.2.)  And SCTP can be demuxed from the
rest as long as you control the range of SCTP ports used.  (And since
the ports aren't actually to route the packets to the receiver (the
underlying UDP does that), you have freedom in choosing SCTP ports.)

So I don't see anything blocking Plan A as compared to Plan B.  Of
course, we have to *do* a bundle technique, but we've got a large
library of possibilities now and can look at the fundamental design
questions in context.

Dale

---

From: Martin Thomson <[email-masked]>
Date: Fri, 1 Mar 2013 08:39:26 -0800

>> My understanding of Plan B is the same as Justin's.
Likewise.  Plan B wouldn't have been the mother of all solutions, but
it would have been enough.

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 1 Mar 2013 18:58:35 +0100

> comes from RFC 5764 section 5.1.2.)  And SCTP can be demuxed from the
As far as I understand it is easy (based on the first byte) to demux
DTLS from STUN and SRTP. SCTP is the only payload for DTLS, so there
is no need for demuxing. So no need to control SCTP ports. Or am I
missing something?

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Mar 2013 10:57:32 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dale R. Worley
> Sent: Friday, March 01, 2013 7:59 AM
> To: Ejzak, Richard P (Richard)
> Cc: [email-masked]
> > Cullen's "Plan A" is preferred over Plan B precisely because it has an
> > incremental muxing advantage.
> 

The analysis should also examine impact of port-based QoS on 
multiplexing data over the same port as audio.  Even audio and
video often prefer different drop precedence.  I know the general
consensus is to just supply more bandwidth, yet we consume all 
available bandwidth much like disk space, memory, and CPU/GPU 
cycles.

-d

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 1 Mar 2013 14:57:21 -0500 (EST)

> From: Michael Tuexen <[email-masked]>

> is no need for demuxing. So no need to control SCTP ports. Or am I

Controlling port numbers is needed if SCTP is *not* encapsulated in
DTLS and yet has to be distinguished from RTP et al.  (That would
become significant if encryption was applied to the bundle's packet
stream as a whole, rather than to the constituent streams
individually.)

Dale

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 2 Mar 2013 00:09:05 +0100

> stream as a whole, rather than to the constituent streams
Sorry, I don't understand what you are saying. Which document describes
the stack you are referring to? How would encryption be done for SCTP over UDP
over IP?

Best regards
Michael

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 2 Mar 2013 08:34:54 +0200

> the stack you are referring to? How would encryption be done for SCTP over UDP

Dale: can you clarify which scenario you have in mind when you say:
"Controlling port numbers is needed if SCTP is *not* encapsulated in 
DTLS and yet has to be distinguished from RTP et al."
is it a WebRTC usage or a usage for a different aim (maybe CLUE?)

/Salvatore

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 02 Mar 2013 11:27:00 +0100

> available bandwidth much like disk space, memory, and CPU/GPU
A reason for the particular way BUNDLE is designed is so that it permits 
you to bundle all the audio separately from all the video if that's your 
desire.
It just doesn't force you to do so.

Once we have BUNDLE in place and the m-line thing settled, we can return 
to the issue of what the default operational mode should be.

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 4 Mar 2013 15:21:51 -0500 (EST)

> From: "Dan Wing" <[email-masked]>
> 

As Harald mentioned, since you can have more than one bundle in a
single session description, you can prescribe one bundle for the audio
and one for the video, and give different QoS parameters for each
bundle.

> Sorry, I don't understand what you are saying. Which document
> describes the stack you are referring to? How would encryption be
> done for SCTP over UDP over IP?

http://tools.ietf.org/html/draft-worley-sdp-bundle-04, section 8, as I
provided in the original message.

You get two variants of the problem, one where you multiplex all the
streams, and then apply DTLS, the other where you encrypt each stream
separately (SRTP, SRTCP, SCTP-over-DTLS) and then multiplex them.  The
analysis of how to demultiplex differs slightly in the two cases.

> From: Salvatore Loreto <[email-masked]>
> 

Actually, I'm analyzing the situation in abstract.  Since it turns out
to be straightforward to demultiplex in the general case, the solution
isn't limited to specific scenarios.

> From: Bernard Aboba <[email-masked]>
> 
> Why would we want unsecured SCTP either for the WebRTC data channel or
> CLUE signaling? Let's not invent problems when we have enough real
> ones.

The question would arise if one multiplexed the various streams
*before* encrypting them, then the demultiplexing problem is slightly
different.

In this case, we can straightforwardly solve a general problem, which
includes the current real problems, and possibly other real problems
we don't yet know that we'll have.

Dale

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 06 Mar 2013 18:47:13 +0100

(this may be a repeat, but I can't find the other mail)

On 02/27/2013 06:49 PM, Ted Hardie wrote:
> 1. draft-alvestrand-rtcweb-vp8-01 (15 mins)
> 2. draft-burman-rtcweb-h264-proposal-01+draft-dbenham-webrtcvideomti-01+draft-marjou-rtcweb-video-codec-00
> (25 mins)
>        Discussion (30 minutes)

Looking at what has to be presented, and the likelyhood of questions, I 
think a more reasonable (less optimistic) allocation of time for the VP8 
part of this discussion would be 15 minutes for presentations and 15 
minutes for clarifying questions.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 06 Mar 2013 12:56:51 +0100

>        Call the question (5 minutes)
On reconsidering this timeline, I feel that it is more realistic to 
expect 15 mins of presentations for VP8 followed by 15 mins of 
clarifying questions (not on the decision to be made, but in order to 
make sure everyone has a common understanding of what the VP8 
presentations were saying.

We will, however, live with what the chairs decide on time division.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 7 Mar 2013 08:16:05 -0800

Magnus and I discussed this morning, and we will allot this extra time
if the JSEP discussion runs short.

regards,

Ted Hardie

On Wed, Mar 6, 2013 at 9:47 AM, Harald Alvestrand <[email-masked]> wrote:
>> 2.
>> draft-burman-rtcweb-h264-proposal-01+draft-dbenham-webrtcvideomti-01+draft-marjou-rtcweb-video-codec-00
>> (25 mins)
>>        Discussion (30 minutes)
> part of this discussion would be 15 minutes for presentations and 15 minutes
> for clarifying questions.
>