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

From: "Dan Wing" <[email-masked]>
Date: Wed, 2 Jan 2013 19:29:41 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Tuesday, December 11, 2012 12:20 PM
> To: Dan Wing
> Cc: [email-masked]
> 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:[email-masked]]
> >> Sent: Tuesday, December 11, 2012 11:17 AM
> >> To: Dan Wing
> >> Cc: [email-masked]
> >> 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: [email-masked] [mailto:[email-masked]] On
> >>>> Behalf Of Paul Kyzivat
> >>>> Sent: Tuesday, December 11, 2012 7:43 AM
> >>>> To: [email-masked]
> >>>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 2 Jan 2013 19:32:23 -0800

> >>>> I presume that that same mechanism is still there when SCTP is run
> >>>> over DTLS over UDP.
> >>>>
> >>> based on the current stack the SCTP traffic is the only traffic that
> >>> runs directly over the DTLS stack.
> >>
> >>> 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.
> >>
> > carried over UDP is not quite clear, especially because SCTP assumes a
> > NAPT will not rewrite the SCTP port number (SCTP endeavors to make
> > 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.
> 
> 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

As I mentioned earlier, SCTP does not allow its source port number to
be changed.  

> 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.
> >
> Here you are talking about finding and using other UDP addr/port pairs?

No, I was referring to the SCTP ports.

-d

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Jan 2013 14:23:14 -0500

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

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Jan 2013 14:06:13 -0800

> Sent: Thursday, January 03, 2013 11:23 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [MMUSIC] RESTART: SCTP question: Where does it multiplex?
> 
> I'm totally lost!
> 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.

> And so he was asking

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 think we can use media lines for both (1) and (3), so perhaps
bundling is the answer.  I don't know.

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

-d

> > Yep, I assume that is how it works.  Effectively, UDP is just used to
> > tunnel the SCTP.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jan 2013 19:01:49 -0500

> DTLS, or SRTP.  This is depicted in Section 5.1.2 of RFC5764:

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.

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

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

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

> SCTP can try to do its multipath.

This is outside my area of expertise.

> The same question and issues exist for

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.

	Thanks,
	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Jan 2013 21:51:19 -0800

> Sent: Thursday, January 10, 2013 4:02 PM
> To: Dan Wing
> Cc: [email-masked]
> > 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.
> 
> 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.  

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

Yep.

> specify a port. 
> ISTM that in this case the port field on the m-line
> 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.

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

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

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

-d

> >>>>>>>>> - 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.
> >>>>>>>>
> >>>>>>> mailing list) suggestion to give the possibility to have
> >>>>>>> multiple SCTP
> >>>>>> 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.
> >>>>>
> >>>>> 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
> >>>>> 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.
> >>>>
> >>>> 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.
> >>>
> >>>>> 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).
> >>>>
> >>>>> 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.
> >>>>>>
> >>>>>> would be very difficult to define the SDP so that it was
> >>>>>> impossible to set up multiple SCTP associations over different 5-
> tuples.
> >>>>>>
> >>>>>>>> for a single SCTP port is identified, it can be demuxed based
> >>>>>>>> on stream
> >>>> number.
> >>>>>>>>
> >>>>>>>> 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.
> >>>>>> But it is a challenge that needs to be tackled if we are to
> >>>>>> realize Harald's dream.
> >>>>>
> >>>>> -d
> >>>>>
> >>>>>
> >>>>>
> >>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jan 2013 11:57:02 -0500

Commenting on one specific point...

> as the audio/video media.

Yes. But SDP doesn't permit two m-lines with the same address and port. 
Bundle has been proposed to work around that. But currently bundle 
requires all the bundled m-lines to have the same <proto>. And that 
won't work for bundling SCTP and RTP.

The restriction to the same <proto> is dictated by the need for a way to 
demux. Bundle specifies rules for multiple RTP m-lines that ensures they 
can be demuxed. The demuxing of RTP from SCTP on the same UDP port uses 
a different mechanism. So for this to work bundle needs:

- more elaborate rules for what <proto> values may be bundled,
   and which may not

- explicit specification for the demuxing of each of the different
   m-lines that have been bundled.

This is not rocket science. Once you think about it a bit it is fairly 
evident which combinations work, and how to demux them. But it needs to 
be written down, directly or by reference.

	Thanks,
	Paul