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 12:20 PM
> To: Dan Wing
> Cc: [e-mail]
> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?
> 
> 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.


The SCTP_REMOTE_UDP_ENCAPS_PORT socket option exists in the user-mode
implementation, per the middle of this thread,

http://www.ietf.org/mail-archive/web/rtcweb/current/msg03302.html


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

Yeah, but requires first deciding what layer is best for such
mobility.

-d


> 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
> >>>
> >>>
> >>>
> >
> >
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic