Re: [MMUSIC] SCTP question: Where does it multiplex?

Hi,

I agree that it would be useful to be able to run data channel on the same 5-tuple as RTP/RTCP, and even making it the default and must-implement way for the browsers.

QoS/prioritization comes to mind as the only potential drawback. The endpoint can naturally still give different priorities to the different components (audio, video, "data") it is sending. I assume SCTP also has TCP-style receiver window that can be used to throttle reception if needed. And presumably RMCAT will find solutions to congestion control in genenral. But from the network perspective there is only one flow, and the only(?) way to differentiate the components is to use DSCP. I don't think our QoS (or API) draft yet clearly explains how DSCP's are learned and set, or whether that is even going to be a realistic solution. 

Markus

>-----Original Message-----
>From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>Behalf Of ext Harald Alvestrand
>Sent: 03 December, 2012 10:11
>To: Christer Holmberg
>Cc: mmusic@ietf.org
>Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?
>
>On 12/03/2012 09:00 AM, Christer Holmberg wrote:
>> Hi,
>>
>> I guess it would be nice to hear from the browser/endpoint people whether
>they see a need for covering non-RTP in BUNDLE.
>>
>> If NOT, it would mean a minimum of two 5-tuples, instead of one (one for
>the bundled RTP media, and one for the data channel).
>
>Speaking with my browser implementor hat on, I want to avoid adding an
>extra 5-tuple for data channels.
>
>Our stats on improvement from the introduction of rtcp-mux were pretty
>compelling that the issue is real.
>
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>
>> -----Original Message-----
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>> Behalf Of Harald Alvestrand
>> Sent: 3. joulukuuta 2012 9:54
>> To: mmusic@ietf.org
>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?
>>
>> On 12/01/2012 07:09 PM, Paul Kyzivat wrote:
>>> I must say that I am getting confused about what is being multiplexed
>>> here. We must be very careful to be precise.
>>>
>>> SCTP defines an *association*, which in simple cases is bound to a
>>> 5-tuple. (For now lets not talk about the cases where each end can
>>> have more than one address.)
>>>
>>> SCTP multiplexes multiple one-way *streams* over an association.
>>> (These are not RTP streams.)
>>>
>>> RTCWEB binds pairs of sctp-streams together into *channels*.
>> I'm not talking about any of these levels. I'm talking about the reuse of the
>RTP session's 5-tuple for the DTLS/SRTP 5-tuple, as described in RFC 5764
>section 5.1.2.
>>
>> I said the same thing earlier on this thread (Nov 5), when you first
>> responded (thanks for being the first responder!)
>>
>> You do make the point that the term "multiplex" is so over-used, it should
>probably be abandoned altogether - but that section talks about
>(de)multiplexing, so changing terminology is probably too late for that
>particular usage.
>>
>>                 Harald
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>_______________________________________________
>mmusic mailing list
>mmusic@ietf.org
>https://www.ietf.org/mailman/listinfo/mmusic