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

[Paul Kyzivat <[e-mail]>]

Inline

On 12/11/12 2:25 PM, Dan Wing wrote:
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[e-mail]]
>> Sent: Tuesday, December 11, 2012 11:17 AM
>> To: Dan Wing
>> Cc: [e-mail]
>> 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: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Paul Kyzivat
>>>> Sent: Tuesday, December 11, 2012 7:43 AM
>>>> To: [e-mail]
>>>> 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.
>
> It is confusing, because SCTP's specifications require different
> things of a NAPT than UDP, TCP, or DCCP.  Specifically, SCTP's
> specifications require the NAPT to not rewrite (not change) the
> source port number of outgoing SCTP-over-IP packets.  Reference
> draft-ietf-behave-sctpnat.
>
>> 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.)
>
> I am not aware of any shipping NAPT that supports SCTP.
>
>
>> 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.
>
> Right.
>
> And the new SCTP_REMOTE_UDP_ENCAPS_PORT socket option has some
> relationship, but I do not understand how it works.  Reference
> draft-ietf-tsvwg-sctp-udp-encaps.

1) draft-ietf-tsvwg-sctp-udp-encaps doesn't seem to cover SCTP over DTLS

2) I guess that would only apply for a kernel implementation of SCTP 
over UDP, accessed via the socket interface.

So I don't think it is relevant for the immediate future plans for user 
mode implementations over UDP.

>> 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.
>
> Right.
>
>>>> 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?
>
> Yes, for mobility.
>
>> That is explicitly excluded in the DTLS/SCTP mapping.
>
> I am thinking about where to layer mobility and multipath for RTP
> (MPRTP) and for SCTP.  Do we do that with MICE
> (draft-wing-mmusic-ice-mobility) or does SCTP do mobility itself?  If
> we do it with MICE, we need to disable or prevent SCTP from adding
> / removing interfaces itself, which is why SCTP includes its own
> ability to signal IP addresses and ports in SCTP itself.

OK. That will require extensions here and there over what drafts 
currently say.

	Thanks,
	Paul

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