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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 03 January 2013 19:23 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 D3AA821F8D12 for <mmusic@ietfa.amsl.com>; Thu, 3 Jan 2013 11:23:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.429
X-Spam-Level:
X-Spam-Status: No, score=0.429 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 RfXYbSF0I9Rr for <mmusic@ietfa.amsl.com>; Thu, 3 Jan 2013 11:23:16 -0800 (PST)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 65E2821F86F4 for <mmusic@ietf.org>; Thu, 3 Jan 2013 11:23:16 -0800 (PST)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta08.westchester.pa.mail.comcast.net with comcast id jW4F1k00616LCl058XPFlF; Thu, 03 Jan 2013 19:23:15 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id jXPF1k00R3ZTu2S3SXPFni; Thu, 03 Jan 2013 19:23:15 +0000
Message-ID: <50E5DAA2.9050600@alum.mit.edu>
Date: Thu, 03 Jan 2013 14:23:14 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Dan Wing <dwing@cisco.com>
References: <5093A2C9.9040001@alvestrand.no><50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu><50C6F800.1080500@ericsson.com> <50C7548C.3090807@alum.mit.edu><010401cdd7d0$d006d310$70147930$@cisco.com> <1.c8c3cdc026cf630fdfa4@alum.mit.edu> <01f801cde962$f1f6c2c0$d5e44840$@cisco.com>
In-Reply-To: <01f801cde962$f1f6c2c0$d5e44840$@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357240995; bh=rMfE8shz9MUyZXPB8lt6M9zfwgaK5R3BFzJMottG7gE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ojPdzGTW+e84i6xw3etXSg47ch0IwMyB2TGsTez0v+C7YFU1v8KwS/SWkNJk3Ycm4 6kGvK0zlMMRZH6X4SfLYto/2DucTLi1DgBYK9jeqfJaMDOBAK5PlInGqldDeGvh/xp BeN83RNH1vci2kqfHc+9WoxgasnnixLJMktwEw8HXdEyoh5Y5+ChFjjExOWLb23mFY P1ZpMMVffUSE/nmuOmEMlsPnmeOHvnCmZUwjFEmyEHiF9da6/uuxQG9rSZSm7FtliT 80hw5L/CqxtH30lFpN0u20ZUmXYooQIDm+03P1BYQsU5+Nu16lbIBUa4ojKsEwKE04 dTyezgPf4+nQQ==
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] RESTART: 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: Thu, 03 Jan 2013 19:23:18 -0000

I'm totally lost!
I looked back, and count 43 messages in this thread.
At this point I no longer understand the question(s), or what if 
anything has been answered.

Can we start over?
Sort out what the questions are, and then discuss whether we have 
answers to them?
(Preferably in separate, well identified, threads.)

I *think* Harald originally asserted that DTLS/SCTP *can* already be 
multiplexed with SRTP audio and video streams. And so he was asking 
*how* this could be specified in SDP. (E.g. Does "bundle" support it?)

Along the way, a question came up of how many DTLS/SCTP connections 
could be multiplexed with each other and with SRTP media. I think Harald 
assumed only one (and assumed there is only a need for one.) But reasons 
for more have been discussed. I suggested that it appears that multiple 
should be supportable, each with a different SCTP port.

I think Dan raised some additional issues related to multipath support.

	Thanks,
	Paul

On 1/2/13 10:32 PM, Dan Wing wrote:
>> -----Original Message-----
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
>> Of Paul Kyzivat
>> Sent: Tuesday, December 11, 2012 11:17 AM
>> To: Dan Wing
>> Cc: mmusic@ietf.org
>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?
>>
>> Hi Dan,
>>
>> Comments inline
>>
>> On 12/11/12 1:53 PM, Dan Wing wrote:
>>>> -----Original Message-----
>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>>>> Behalf Of Paul Kyzivat
>>>> Sent: Tuesday, December 11, 2012 7:43 AM
>>>> To: mmusic@ietf.org
>>>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?
>>>>
>>>> More inline.
>>>>
>>>> On 12/11/12 4:08 AM, Salvatore Loreto wrote:
>>>>> Hi Paul,
>>>>>
>>>>> see in line!
>>>>>
>>>>> On 12/3/12 10:00 PM, Paul Kyzivat wrote:
>>>>>> Commenting on a different point
>>>>>>
>>>>>> On 12/1/12 9:53 AM, Harald Alvestrand wrote:
>>>>>>
>>>>>>> The interesting difference is that the multiplexing between
>>>>>>> DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP
>>>>>>> traffic is not carried in SSRCs, which means:
>>>>>>>
>>>>>>> - There can be only one DTLS/SCTP stream in a bundle (which may
>>>>>>> have multiple associations, as you state below); you can't have
>>>>>>> multiple lines with proto DTLS/SCTP in a bundle.
>>>>>>
>>>>>> I am not an SCTP expert. But IIUC, SCTP was designed to run
>>>>>> directly over IP. It has its own notion of port used to demux
>>>>>> multiple SCTP associations over the same IP address.
>>>>>>
>>>>>> I presume that that same mechanism is still there when SCTP is run
>>>>>> over DTLS over UDP.
>>>>>>
>>>>>> So, the traffic coming over DTLS must first be demuxed into RTP
>>>>>> traffic and SCTP traffic.
>>>>> based on the current stack the SCTP traffic is the only traffic that
>>>>> runs directly over the DTLS stack.
>>>>
>>>> Yes, that is what I thought. But Harald has been asking about
>>>> multiplexing this with RTP traffic. (Actually I think it would be
>>>> DTLS/SRTP traffic that it would be multiplexed with.)
>>>>
>>>>> What I am trying to do is to include the Randell Jesup (I am
>>>>> including him in CC as I am not sure he is subscribed to this
>>>>> mailing list) suggestion to give the possibility to have multiple
>>>>> SCTP
>>>>> *associations* running on top of the same DTLS session and of course
>>>>> providing a way to signal it in SDP.
>>>>
>>>> IIUC, SCTP (having been designed as a transport layer protocol)
>>>> defines its own notion of port, and has fields in its protocol to
>>>> carry the local and remote port number. Presumably those fields are
>>>> still there when run over UDP or DTLS. So it should be possible to
>>>> support multiple SCTP associations over the same DTLS connection,
>>>> each distinguished by its own port pair.
>>>
>>> Yes, SCTP has its own notion of ports. How this works when SCTP is
>>> carried over UDP is not quite clear, especially because SCTP assumes a
>>> NAPT will not rewrite the SCTP port number (SCTP endeavors to make
>>> such port rewriting difficult). But of course a NAPT (and the MAP
>>> techniques) rewrite UDP port numbers. I believe SCTP would only be
>>> able to successfully convey its UDP port numbers for a device that is
>>> not behind a NAT (that is, a server sitting directly on the Internet,
>>> rather than a remote peer that is behind a NAT). Creative use of PCP,
>>> NAT-PMP, or UPnP IGD would improve that situation in the future.
>>
>> I find what you say above confusing.
>>
>> SCTP running naked over IP would still have its own ports.
>> If that ran over a path with a NAPT, then I could see why the NAPT might
>> want to do the same as it does with UDP and TCP, and so replace
>> addr/port pairs to minimize addr usage. (That's if the NAPT supported
>> SCTP at all - I gather most don't.)
>
> As I mentioned earlier, SCTP does not allow its source port number to
> be changed.
>
>> But with SCTP over DTLS over UDP, there is a UDP port, and then
>> presumably a separate SCTP port carried in the SCTP protocol within the
>> UDP message.
>
> Yep, I assume that is how it works.  Effectively, UDP is just used
> to tunnel the SCTP.
>
>> An NAPT on the path would presumably be messing with the UDP port. Given
>> use of DTLS, the NAPT won't even be able to tell that SCTP is being
>> used, much less mess with the SCTP port.
>>
>>>> That of course depends on having a signaling mechanism to set it up.
>>>
>>> After the initial SCTP association is created, SCTP could be allowed
>>> to do its own thing (that is, chose to find and use other ports).
>>
>> Here you are talking about finding and using other UDP addr/port pairs?
>
> No, I was referring to the SCTP ports.
>
> -d
>
>
>> That is explicitly excluded in the DTLS/SCTP mapping.
>>
>> Thanks,
>> Paul
>>
>>> SCTP's behavior in this regard is similar to MPRTP (multipath RTP),
>>> but of course they are not identical.
>>>
>>>>> to be clear: at moment WebRTC allows only one SCTP association per
>>>>> PC, so this is something that would be nice to define just to be
>>>>> ready for the future.
>>>>
>>>> AFAIK WebRTC is just one possible user of this mechanism. The SDP
>>>> mechanism shouldn't be limited by the constraints of WebRTC. It would
>>>> be very difficult to define the SDP so that it was impossible to set
>>>> up multiple SCTP associations over different 5-tuples.
>>>>
>>>>>> Then the RTP traffic can be demuxed based on SSRC, and SCTP traffic
>>>>>> can be demuxed based on SCTP port. And once the traffic for a
>>>>>> single SCTP port is identified, it can be demuxed based on stream
>> number.
>>>>>>
>>>>>> Representing this in SDP is a challenge. Some variant of the bundle
>>>>>> proposal might allow bundling together several RTP m-lines and some
>>>>>> DTLS/SCTP m-lines. This would require a mechanism for specifying
>>>>>> the SCTP port number - already an open issue (#3) in
>>>>>> draft-ietf-mmusic-sctp-sdp-02.
>>>>> I agree that it is a challange how then to bundle everything
>>>>> together
>>>>
>>>> But it is a challenge that needs to be tackled if we are to realize
>>>> Harald's dream.
>>>
>>> -d
>>>
>>>
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>