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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Paul Kyzivat
> 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.
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic