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

Harald Alvestrand <harald@alvestrand.no> Mon, 03 December 2012 11:13 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DCF21F85D7 for <mmusic@ietfa.amsl.com>; Mon, 3 Dec 2012 03:13:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.427
X-Spam-Level:
X-Spam-Status: No, score=-110.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDWkCVjmQNkl for <mmusic@ietfa.amsl.com>; Mon, 3 Dec 2012 03:13:49 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D327021F8596 for <mmusic@ietf.org>; Mon, 3 Dec 2012 03:13:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C6FED39E1FC; Mon, 3 Dec 2012 12:13:47 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPZc9P7820aV; Mon, 3 Dec 2012 12:13:46 +0100 (CET)
Received: from [158.38.97.117] (unknown [158.38.97.117]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A16DF39E04C; Mon, 3 Dec 2012 12:13:45 +0100 (CET)
Message-ID: <50BC8969.6010101@alvestrand.no>
Date: Mon, 03 Dec 2012 12:13:45 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Markus.Isomaki@nokia.com
References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BA47E8.4010909@alum.mit.edu> <50BC5A81.6050503@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04CC3A@ESESSMB209.ericsson.se> <50BC5E80.4090006@alvestrand.no> <E44893DD4E290745BB608EB23FDDB76231FA24@008-AM1MPN1-042.mgdnok.nokia.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB76231FA24@008-AM1MPN1-042.mgdnok.nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: mmusic@ietf.org, christer.holmberg@ericsson.com
Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Dec 2012 11:13:49 -0000

On 12/03/2012 10:02 AM, Markus.Isomaki@nokia.com wrote:
> 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.

That is indeed the only reason I can think of to specify multiple 
m-lines for DTLS/SCTP (and we don't need to bundle them together).

At the moment, the MMUSIC API doesn't define a way to control which 
m-line a DTLS assocation gets mapped onto.

This may be more complexity than is really needed, though.

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