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

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

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: Thursday, January 10, 2013 4:02 PM
> To: Dan Wing
> Cc: [e-mail]
> Subject: Re: [MMUSIC] RESTART: SCTP question: Where does it multiplex?
> 
> On 1/10/13 5:06 PM, Dan Wing wrote:
> >> -----Original Message-----
> >> From: Paul Kyzivat [mailto:[e-mail]]
> >> Sent: Thursday, January 03, 2013 11:23 AM
> >> To: Dan Wing
> >> Cc: [e-mail]
> >> Subject: Re: [MMUSIC] RESTART: SCTP question: Where does it
> multiplex?
> >>
> >> 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.
> >
> > Yes, it can.
> >
> > An UDP packet is either a STUN packet (for ICE connectivity checks),
> > DTLS, or SRTP.  This is depicted in Section 5.1.2 of RFC5764:
> >
> >                     +----------------+
> >                     | 127 < B < 192 -+--> forward to RTP
> >                     |                |
> >         packet -->  |  19 < B < 64  -+--> forward to DTLS
> >                     |                |
> >                     |       B < 2   -+--> forward to STUN
> >                     +----------------+
> >
> > A DTLS packet containing application_data is handed to the SCTP stack.
> >
> > As I have mentioned previously, I am concerned with sending both
> > realtime interactive audio/video and non-realtime data over the same
> > UDP 5-tuple, because it becomes difficult (or impossible) to apply QoS
> > to differentiate those very different flows.  If everyone always had
> > adequate bandwidth, that concern would vanish.  But the industry has
> > never been able to stay ahead of the bandwidth curve.
> 
> This is all about policy, not mechanism. It seems that some people want
> to use this mechanism and think it will be good for them. Perhaps there
> can be a section in some draft on this subject that points out your
> concern and recommends that people consider carefully what they
> multiplex on the same 5-tuple.
> 
> Similar arguments may apply to bundling audio and video onto the same 5-
> tuple.

I have been told there is a 3GPP document that might be worth citing
on that point.  I'll get a pointer soon.  I expect there is a long-standing
RFC on that point, too, but I don't know of one.  


> >> And so he was asking
> >> *how* this could be specified in SDP. (E.g. Does "bundle" support
> >> it?)
> >
> > We need a way for SDP to signal:
> >    1. the UDP port for SCTP.  This feels like an SDP media ("m") line
> to me.
> >    2. SCTP native (native SCTP over IPv6 should be tenable, whereas
> > native SCTP over IPv4 is pretty much untenable),
> >    3. the data carried over each SCTP port (e.g., port NNN for XMPP,
> > port NNNN for file sharing, port NNNNN for screen sharing, and so on).
> > This feels like an SDP media ("m") line to me.
> 
> I don't disagree with any of your points, but you have missed the point
> I was making.
> 
> Everything you list applies for SCTP on its own 5-tuple. But then there
> is the question of how to describe how this shares a 5-tuple with some
> audio and video streams.

(1), from my list, is the UDP port.  This could be the same UDP port
as the audio/video media.

> The current candidates for representing the
> bundling of audio and video are the bundle draft and the mmt draft.
> Neither of these currently supports including DTLS/SCTP with audio or
> video. So if bundling in the SCTP is a requirement, then both bundle and
> mmt should be extended cover it if they are to remain in the running.

Yep.

> A *native* SCTP session (directly over IPv*) runs on a 5-tuple,
> including the *SCTP* ports at each end. So the SDP for that needs to
> specify a port. 
>
> ISTM that in this case the port field on the m-line
> would signify the SCTP port. And this is what draft-ietf-mmusic-sctp-sdp
> says.
>
> A DTLS/SCTP session requires a 7-tuple, including both an SCTP port and
> a UDP port at each end. So the SDP for that needs to specify both an
> SCTP port and a UDP port. Only one of those can be in the port field of
> the m-line. (Which one that should be can be argued either way.) draft-
> ietf-mmusic-sctp-sdp puts the UDP port in the m-line, and has no way to
> specify the SCTP port. (It has an open issue about that.
> Presumably it is either defaulted or must go in an attribute.)

That's a good summary of the current state of the art.

> > I don't think we can use media lines for both (1) and (3), so perhaps
> > bundling is the answer.  I don't know.
> 
> Even *with* bundling the problem remains. But I agree that if you want
> to run SCTP on two or more SCTP ports over the same UDP port, then
> bundle is one way to do it. Each of the bundled m-lines would have to
> specify the SCTP port, presumably as an attribute.
> 
> >> 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.
> >
> > SCTP can support multipath, so we need to decide if we allow SCTP to
> > do its own multipath, or if we require ICE to first validate a (new)
> > path before SCTP can try to do its multipath.
> 
> This is outside my area of expertise.
> 
> > The same question and issues exist for multipath RTP
> > (draft-singh-avtcore-mprtp) and how multipath RTP should split its
> > functions between ICE, ICE extensions, and SDP.  I know that multipath
> > RTP is not a working group document, but it might be a good basis for
> > analyzing multipath SCTP and reaching a conclusion on multipath SCTP
> > that makes sense for both multipath SCTP and multipath RTP (and
> > presumably multipath TCP, RFC6182 and its related documents).
> 
> If you want to multiplex SCTP and RTP on the same connection, and you
> are going to make SCTP multipath work for that, then why would you not
> just do RTP over an SCTP channel??? Then you don't need to reinvent how
> to multipath for RTP.

I guess to support remote endpoints that lack SCTP, yet want to do 
multipath RTP.

-d

> 	Thanks,
> 	Paul
> 
> > -d
> >
> >
> >> 	Thanks,
> >> 	Paul
> >>
> >> On 1/2/13 10:32 PM, Dan Wing wrote:
> >>>> -----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
> >>>
> >>>
> >>>
> >
> >