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

From: Salvatore Loreto <[email-masked]>
Date: Sat, 1 Dec 2012 13:03:09 +0200

Hi Harald,

sorry to be late on this
and thanks a lot for raising the question

IMO how to multiplex DTLS/SCTP traffic with te rest of the "WebRTC" 
traffic is something that belongs
to the BUNDLE discussion, and there won't be anything about how to 
bundle in this draft.
To answer your question at present I don't think there should be 
anything special for DTLS/SCTP

However, what I have in my working copy on the draft (I will publish it 
at some point next week)
and it can be interesting to you is the possibility to have multiple 
SCTP associations on top of the same
DTLS connection (for future WebRTC scenarios, or non WebRTC scenarios):

        Running SCTP over DTLS make possible to have multiple SCTP
        associations on top of the same DTLS connection; each SCTP
        association make use of a distinct port number that is mainly
    used to
        demultiplex the associations.  If the <proto> sub-field is 'DTLS/
        SCTP' the <fmt> sub-fields contain SCTP association port numbers.
        When a list of port number identifiers is given, this implies that
        all of these associations MUST run on top of the DTLS connection.
        For the payload type assignments the "a=sctpmap:" attribute
        SHOULD be used to map from a port number to a media
        encoding name that identifies the payload format transported by the
        association or the actual application protocol running on top of it.

                   m=application 54111 DTLS/SCTP 5000 5001 5002
                   c=IN IP4 79.97.215.79
                   a=sctpmap:5000 protocol=webrtc-DataChannel;streams=16
                   a=sctpmap:5001 protocol=XXX;streams=2
                   a=sctpmap:5002 protocol=YYY;streams=1

best regards
Salvatore

On 11/2/12 12:39 PM, Harald Alvestrand wrote:
> As currently specified, the DTLS/SCTP protocol is carefully specified 
> in such a way that it can ride on the same 5-tuple as an SRTP session. 
> I'd like to keep that property when we SDP-negotiate it.
>
> The proposed syntax for DTLS/SCTP seems to be
>
> m=<something, likely application> <port number> DTLS/SCTP <fmt data, 
> mostly meaningless>
>
> I see two ways to define this as a multiplex:
>
> - Give the same port number as another m= line in the same SDP session
> - Give a meaningless port number, and use the a=group:BUNDLE (of 
> whatever flavor) to give which port number it's actually multiplexed 
> together with.
>
> The best way to do this may be obvious after the BUNDLE discussion, 
> but in case there are other considerations .... are there thoughts?
>
>                Harald
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 01 Dec 2012 15:53:45 +0100

> anything special for DTLS/SCTP
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.
- None of the ordinary BUNDLE considerations about colliding parameters 
apply

Since the ability to multiplex was thought an important factor for 
selecting this stacking, we'd better make sure we specify how it's being 
done.

>
> However, what I have in my working copy on the draft (I will publish 
> it at some point next week)
that's a sentence fragment I can't parse, so I hope you revise that 
before submission. If there's a comma before "the <fmt> sub-fields" it 
parses.
>> in such a way that it can ride on the same 5-tuple as an SRTP 
>> session. I'd like to keep that property when we SDP-negotiate it.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 01 Dec 2012 13:09:44 -0500

I must say that I am getting confused about what is being multiplexed 
here. We must be very careful to be precise.

SCTP defines an *association*, which in simple cases is bound to a 
5-tuple. (For now lets not talk about the cases where each end can have 
more than one address.)

SCTP multiplexes multiple one-way *streams* over an association. (These 
are not RTP streams.)

RTCWEB binds pairs of sctp-streams together into *channels*.

A channel could be used like a TCP connection. Or like a UDP connection.

Where we currently use SDP to negotiate the application level use of a 
UDP or TCP connection, we might (probably will) also like to use SDP to 
negotiate the application level use of an SCTP stream or channel.

For instance, we might want to negotiate one channel for use with the 
CLUE protocol and another for the BFCP channel. (We might want that in a 
pure sip environment - no rtcweb.) But we might also want do the same 
thing when one or both ends rtcweb clients. And in that case they might 
also want to dynamically assign other channels for rtcweb-specific use.

It could also be useful to define an RTP session over a channel. And in 
fact, define multiple RTP sessions, each over a distinct channel. For 
*each* such RTP session we would want to negotiate payload numbers and 
the mappings of those numbers to codec attributes, etc.

This starts to look like a fractal structure, which could present some 
problems for describing in SDP. Here are some examples of different ways 
multiplexing the same set of media belonging to a single sip 
session/call or rtcweb PeerConnection. (I'm intentionally not using SDP 
to describe this, in order to show the similarities between the 
alternatives and to avoid arguments of hypothetical SDP.)

For instance, we could have a sip session/call that has the following media:

- audio RTP session
   - a set of payload numbers for use in this audio RTP session
   - mappings for each payload number to codec parameters
   - several audio RTP streams within the audio RTP session
- video RTP session
   - a set of payload numbers for use in this audio RTP session
   - mappings for each payload number to codec parameters
   - several video RTP streams within the video RTP session
- a BFCP over TCP connection
- an SCTP association over DTLS over UDP
   - an SCTP channel used for the CLUE protocol

But we could also multiplex the same stuff differently:

- a single RTP session for audio/video
   - a set of payload numbers, some for audio and some for video
   - mappings for each payload number to codec a/v codec parameters
   - several audio RTP streams
   - several video RTP streams
- an SCTP association over DTLS over UDP
   - an SCTP channel used for BFCP
   - an SCTP channel used for the CLUE protocol

Or in principle the same stuff could be multiplexed as:

- an SCTP association over DTLS over UDP
   - an SCTP channel used for BFCP
   - an SCTP channel used for the CLUE protocol
   - an SCTP channel used for audio RTP
     - a set of payload numbers for use in this audio RTP session
     - mappings for each payload number to codec parameters
     - several audio RTP streams within the audio RTP session
   - an SCTP channel used for video RTP
     - a set of payload numbers for use in this video RTP session
     - mappings for each payload number to codec parameters
     - several video RTP streams within the video RTP session

Or:

- an SCTP association over DTLS over UDP
   - an SCTP channel used for BFCP
   - an SCTP channel used for the CLUE protocol
   - an SCTP channel used for a single audio session & stream
     - a set of payload numbers for use in this RTP session/stream
     - mappings for each payload number to codec parameters
   - an SCTP channel used for a single audio session & stream
     - a set of payload numbers for use in this RTP session/stream
     - mappings for each payload number to codec parameters
   - an SCTP channel used for a single audio session & stream
     - a set of payload numbers for use in this RTP session/stream
     - mappings for each payload number to codec parameters
   - an SCTP channel used for a single video session & stream
     - a set of payload numbers for use in this RTP session/stream
     - mappings for each payload number to codec parameters
   - an SCTP channel used for a single video session & stream
     - a set of payload numbers for use in this RTP session/stream
     - mappings for each payload number to codec parameters
   - an SCTP channel used for a single video session & stream
     - a set of payload numbers for use in this RTP session/stream
     - mappings for each payload number to codec parameters

Note that multiplexing multiple RTP sessions over SCTP channels is 
topologically equivalent to Magnus' proposal for a shim layer to 
multiplex multiple RTP sessions over a single UDP 5-tuple. So I could 
sketch out some added alternatives based on that. But I won't.

Of course not all of these are currently possible because we don't have 
all the necessary mappings defined. But they could be. For instance, I 
think we will *need* BFCP over a channel if we want to support an rtcweb 
client that has full functionality in a conference. It may be harder to 
motivate a need for RTP over an sctp channel.

My point in bringing this up is that I think we must be very clear about 
which of these various forms of multiplexing we are trying to represent 
*now*, and which we at least want to leave room to support in the 
future. Without at least thinking about it we are likely to come up with 
something that won't extend to a case we might later wish to support.

	Thanks,
	Paul

> lines with proto DTLS/SCTP in a bundle.

I originally thought this, but after some discussions in Atlanta I am 
not sure about this. IIUC, SCTP has its own port concept. In a kernel 
implementation that would be used to demux multiple SCTP associations to 
the processes that own them, etc. But in a user mode implementation over 
another transport this should be available to the application to demux 
multiple SCTP associations.

So I think you might indeed be able to have multiple SCTP associations 
over the same DTLS/SCTP instance.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 03 Dec 2012 08:53:37 +0100

On 12/01/2012 07:09 PM, Paul Kyzivat wrote:
> 5-tuple. (For now lets not talk about the cases where each end can 
> have more than one address.)
>
> SCTP multiplexes multiple one-way *streams* over an association. 
> (These are not RTP streams.)
>

I'm not talking about any of these levels. I'm talking about the reuse 
of the RTP session's 5-tuple for the DTLS/SRTP 5-tuple, as described in 
RFC 5764 section 5.1.2.

I said the same thing earlier on this thread (Nov 5), when you first 
responded (thanks for being the first responder!)

You do make the point that the term "multiplex" is so over-used, it 
should probably be abandoned altogether - but that section talks about 
(de)multiplexing, so changing terminology is probably too late for that 
particular usage.

               Harald

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Dec 2012 08:00:54 +0000

Hi,

I guess it would be nice to hear from the browser/endpoint people whether they see a need for covering non-RTP in BUNDLE.

If NOT, it would mean a minimum of two 5-tuples, instead of one (one for the bundled RTP media, and one for the data channel).

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 3. joulukuuta 2012 9:54
To: [email-masked]
Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?

> RTCWEB binds pairs of sctp-streams together into *channels*.

I'm not talking about any of these levels. I'm talking about the reuse of the RTP session's 5-tuple for the DTLS/SRTP 5-tuple, as described in RFC 5764 section 5.1.2.

I said the same thing earlier on this thread (Nov 5), when you first responded (thanks for being the first responder!)

You do make the point that the term "multiplex" is so over-used, it should probably be abandoned altogether - but that section talks about (de)multiplexing, so changing terminology is probably too late for that particular usage.

               Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 03 Dec 2012 09:10:40 +0100

> If NOT, it would mean a minimum of two 5-tuples, instead of one (one for the bundled RTP media, and one for the data channel).

Speaking with my browser implementor hat on, I want to avoid adding an 
extra 5-tuple for data channels.

Our stats on improvement from the introduction of rtcp-mux were pretty 
compelling that the issue is real.

---

From: <[email-masked]>
Date: Mon, 3 Dec 2012 09:02:44 +0000

Hi,

I agree that it would be useful to be able to run data channel on the same 5-tuple as RTP/RTCP, and even making it the default and must-implement way for the browsers.

QoS/prioritization comes to mind as the only potential drawback. The endpoint can naturally still give different priorities to the different components (audio, video, "data") it is sending. I assume SCTP also has TCP-style receiver window that can be used to throttle reception if needed. And presumably RMCAT will find solutions to congestion control in genenral. But from the network perspective there is only one flow, and the only(?) way to differentiate the components is to use DSCP. I don't think our QoS (or API) draft yet clearly explains how DSCP's are learned and set, or whether that is even going to be a realistic solution. 

Markus

>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of ext Harald Alvestrand
>Sent: 03 December, 2012 10:11
>To: Christer Holmberg
>Cc: [email-masked]
>> I guess it would be nice to hear from the browser/endpoint people whether
>they see a need for covering non-RTP in BUNDLE.
>>
>> If NOT, it would mean a minimum of two 5-tuples, instead of one (one for
>the bundled RTP media, and one for the data channel).
>
>> I'm not talking about any of these levels. I'm talking about the reuse of the
>RTP session's 5-tuple for the DTLS/SRTP 5-tuple, as described in RFC 5764
>section 5.1.2.
>>
>> You do make the point that the term "multiplex" is so over-used, it should
>probably be abandoned altogether - but that section talks about

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 03 Dec 2012 12:13:45 +0100

> QoS/prioritization comes to mind as the only potential drawback. The endpoint can naturally still give different priorities to the different components (audio, video, "data") it is sending. I assum…

That is indeed the only reason I can think of to specify multiple 
m-lines for DTLS/SCTP (and we don't need to bundle them together).

At the moment, the MMUSIC API doesn't define a way to control which 
m-line a DTLS assocation gets mapped onto.

This may be more complexity than is really needed, though.

>>> Behalf Of Harald Alvestrand

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Dec 2012 14:36:18 -0500

> of the RTP session's 5-tuple for the DTLS/SRTP 5-tuple, as described in

These are all related. We are making even more of a mess of SDP than it 
already is by patching on a new hack for each sort of multiplexing 
somebody comes up with. But focusing on just this:

How do you imagine this multiplexing will be signaled in SDP?
The obvious way would be to bundle the DTLS/SCTP m-line with the RTP 
m-lines. But that will violate the rule that all the bundled m-lines 
have the same <proto>. (And there is an even worst fit between this and 
mmt.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Dec 2012 15:00:18 -0500

Commenting on a different point

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

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Dec 2012 15:13:48 -0500

On 12/3/12 6:13 AM, Harald Alvestrand wrote:
>> I agree that it would be useful to be able to run data channel on the
>> same 5-tuple as RTP/RTCP, and even making it the default and
>> must-implement way for the browsers.
>>
>> QoS/prioritization comes to mind as the only potential drawback. The
>> endpoint can naturally still give different priorities to the
>> different components (audio, video, "data") it is sending. I assume
>> SCTP also has TCP-style receiver window that can be used to throttle
>> reception if needed. And presumably RMCAT will find solutions to
>> congestion control in genenral. But from the network perspective there
>> is only one flow, and the only(?) way to differentiate the components
>> is to use DSCP. I don't think our QoS (or API) draft yet clearly
>> explains how DSCP's are learned and set, or whether that is even going
>> to be a realistic solution.
>

MMUSIC *API*???

Do you mean the SDP signaling for this? (draft-ietf-mmusic-sctp-sdp-02)

It specifies a new m-line format for this.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Mon, 3 Dec 2012 20:23:32 +0000

Hi,

Paul Kyzivat wrote:
>>>I don't think our QoS (or API) draft yet
>>> clearly explains how DSCP's are learned and set, or whether that is
>>> even going to be a realistic solution.
>>

Sorry about starting the confusion. I thought this was on rtcweb mailing list and with API I was in my reply actually referring to the QoS/prioritization related APIs in W3C related to WebRTC. Don't know which API Harald is referring to, though :-)

Markus

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 06 Dec 2012 14:02:39 +0100

>> m-line a DTLS assocation gets mapped onto.

Sorry, I was writing at a non-awake time.
I meant the WebRTC API (Javascript, specified in the W3C WG).

I

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Dec 2012 12:04:00 -0500

Harald - comment at end.

> I meant the WebRTC API (Javascript, specified in the W3C WG).

OK. That makes more sense.

Well, there are two solutions to that:

- enhance the API to provide that capability, perhaps with a default
   to make it simple in common cases.

- limit WebRTC to follow a convention for which only supports a
   subset of what is possible in SDP.

IMO the first is the wiser choice.

In any case we are not defining this in SDP solely for WebRTC. We need 
to specify this in a way that works for everybody that wants to use it.

One way or another the SDP must define the SCTP association, and if it 
is to share a 5-tuple then the grouping to do that needs to be defined.
IIUC, the current bundle draft isn't capable of doing that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Dec 2012 18:01:13 +0000

Hi,

>IIUC, the current bundle draft isn't capable of doing that.

The current bundle draft needs additional work, mainly regarding the handling of SDP attributes etc, even to share a 5-tuple for RTP.

But, in general, what problems do you see with using bundle also for SCTP?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Dec 2012 16:44:45 -0500

> The current bundle draft needs additional work, mainly regarding the handling of SDP attributes etc, even to share a 5-tuple for RTP.

The current draft requires the <proto> fields of all the bundled m-lines 
to be the same. It also strongly implies that all of them must be 
RTP-related. To include the SCTP m-line for support of the data 
channels, it will be necessary dissimilar <proto> fields to be bundled. 
But not all combinations are valid.

So it needs some additional text to explain which other cases may be 
bundled. The simple way out would be to simply enumerate the different 
combinations of <proto>s that may be bundled and any other constraints 
that may apply. Better would be to define some more general criteria for 
those that may be bundled, so that it might survive future extensions.

An obvious constraint is that there must be some way of demuxing them.

I am still trying to understand the details of how the DTLS/SRTP is 
multiplexed with RTP (actually I guess it will be UDP/TLS/RTP/SAVP(F)). 
Is there some place that explains that? RFC 5764 explains how RTP, DTLS, 
and STUN are demuxed for DTLS/SRTP. And 
draft-tuexen-tsvwg-sctp-dtls-encaps explains how to run SCTP over DTLS. 
But those two mappings don't seem to be compatible.

Has anyone written down a proposal for how that will work?

	Thanks,
	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 11 Dec 2012 11:08:16 +0200

Hi Paul,

see in line!

On 12/3/12 10:00 PM, Paul Kyzivat wrote:
> 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.
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.

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.

> 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.
>
I agree that it is a challange how then to bundle everything together

Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: <[email-masked]>
Date: Tue, 11 Dec 2012 10:34:28 +0000

Hi Sal,

Salvatore Loreto wrote:
>
>based on the current stack the SCTP traffic is the only traffic that runs directly
>over the DTLS stack.
>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)
>*associations* running  on top of the same DTLS session and of course
>providing a way to signal it in SDP.
>
>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.
>

It's a bit unclear to me what the benefit of this would be. SCTP itself allows multiple streams to be transported in parallel within a single SCTP association. So, in what type of situations would we need multiple parallel SCTP associations? I thought the main point of SCTP is that it provides the parallelism and multiplexing by itself.

In other words: I do understand the desire to multiplex RTP and SCTP within the same UDP flow, so we can for instance reduce the number of needed NAT/FW bindings. I also understand why multiple independent non-HOL blocking streams within SCTP are useful for applications. But I don't yet understand the additional benefit of multiple parallel SCTP associations. No doubt it can be technically done, but to what purposes?

Markus

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Dec 2012 10:43:08 -0500

More inline.

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

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

That of course depends on having a signaling mechanism to set it up.

> so this is something that would be nice to define just to be ready for

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.

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

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 11 Dec 2012 16:58:26 +0100

> DTLS/SRTP traffic that it would be multiplexed with.)
Yes, it's SRTP traffic that the DTLS/SCTP traffic will be multiplexed 
with (the DTLS part of DTLS/SRTP is just a key negotiation mechanism, 
unlike the DTLS part of DTLS/SCTP, which is an actual encapsulation).

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Dec 2012 12:05:50 -0500

> It's a bit unclear to me what the benefit of this would be. SCTP itself allows multiple streams to be transported in parallel within a single SCTP association. So, in what type of situations would…

It may not provide any benefit for WebRTC. To provide some benefit it 
would need to be exposed in the WebRTC API.

If every stream/channel within the SCTP session is always negotiated in 
SDP then there is less likely to be benefit in general.

But if (as planned, I think) the streams/channels within the SCTP 
association can be managed dynamically, then having two associations 
means you could have two separate pools of streams to dynamically 
manage. This could be helpful if you have multiple components within 
your application that want their own control over dynamic data streams.

Whether the multiple SCTP associations are over the same DTLS connection 
or different ones is an independent question.

> In other words: I do understand the desire to multiplex RTP and SCTP within the same UDP flow, so we can for instance reduce the number of needed NAT/FW bindings. I also understand why multiple ind…

IIUC this is a mechanism that is already latent in the SCTP. It is a 
matter of whether to expose the capability. Not exposing it just means 
that the latent capability isn't being used - everyone will be operating 
on a default SCTP port.

Exposing it needs to occur at two levels, and the decision whether to do 
so or not can be made separately:

IIUC the SCTP *protocol* already has this capability.

The proposed SDP currently provides no way to specify the SCTP port. If 
it is to continue that way then it minimally needs to specify which port 
value is to be used in the protocol. (Otherwise we can have 
interoperability failures.)

It should be very simple to provide an attribute to explicitly specify 
the SCTP port, while still specifying a default value if not specified. 
By itself this would not be very useful if you could only specify one.

More complex would be to specify use of multiple SCTP ports over the 
same DTLS connection. That starts to look like a bundle problem again 
because they share the same address and UDP port, while having a number 
of attributes to specify about each.

If we want to keep this simple for now, then I suggest that 
draft-ietf-mmusic-sctp-sdp simply specify that implementations of this 
draft always use SCTP port zero, and that use of other ports is out of 
scope.

	Thanks,
	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Dec 2012 10:53:30 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Tuesday, December 11, 2012 7:43 AM
> To: [email-masked]
> >>> 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:
> >>>

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.

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

SCTP's behavior in this regard is similar to MPRTP (multipath RTP),
but of course they are not identical.

> But it is a challenge that needs to be tackled if we are to realize

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Dec 2012 10:53:30 -0800

> Of [email-masked]
> Sent: Tuesday, December 11, 2012 2:34 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> It's a bit unclear to me what the benefit of this would be. SCTP itself
> allows multiple streams to be transported in parallel within a single
> SCTP association. So, in what type of situations would we need multiple
> parallel SCTP associations? I thought the main point of SCTP is that it
> provides the parallelism and multiplexing by itself.
> 
> In other words: I do understand the desire to multiplex RTP and SCTP
> within the same UDP flow, so we can for instance reduce the number of
> needed NAT/FW bindings.

Sending bulk data (SCTP) and interactive audio/video over the same port
will break prioritization of the audio/video flow above the bulk data.

> I also understand why multiple independent non-
> HOL blocking streams within SCTP are useful for applications. But I
> don't yet understand the additional benefit of multiple parallel SCTP
> associations. No doubt it can be technically done, but to what purposes?

One example:  transferring a big file while, at the same time, doing 
screen sharing or an instant message chat.

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Dec 2012 14:17:28 -0500

Hi Dan,

Comments inline

> use of PCP, NAT-PMP, or UPnP IGD would improve that situation in

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

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.

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.

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

That is explicitly excluded in the DTLS/SCTP mapping.

	Thanks,
	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Dec 2012 11:25:31 -0800

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, December 11, 2012 11:17 AM
> To: Dan Wing
> Cc: [email-masked]
> >> Behalf Of Paul Kyzivat
> >>>>> 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.
> >>>>
> >>> 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)
> >>> *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.
> >
> > 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.
> 

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 at all - I  gather most don't.)

I am not aware of any shipping NAPT that supports SCTP.

> presumably a separate SCTP port carried in the SCTP protocol within the

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.

> used, much less mess with the SCTP port.

Right.

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

-d

> >>> 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.
> >>
> >> 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.
> >>
> >>>> 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.
> >>>>
> >>>> 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: Tue, 11 Dec 2012 14:26:54 -0500

> will break prioritization of the audio/video flow above the bulk data.

Yeah, probably. In theory you could use DSCP to mark the packets 
differently.

This indeed might be a reason to *not* multiplex the SCTP association 
for data channels with the media. Assuming we find a way to do that 
multiplexing, this would be an argument for making that multiplexing 
*optional*.

> screen sharing or an instant message chat.

When using DTLS/SCTP this is an argument for using SCTP associations 
over separate DTLS connections. Two SCTP associations (differing by SCTP 
port) over the same DTLS connection wouldn't solve this problem.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Dec 2012 15:20:03 -0500

Inline

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

> 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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Dec 2012 12:53:19 -0800

> Sent: Tuesday, December 11, 2012 12:20 PM
> To: Dan Wing
> Cc: [email-masked]
> >>>>>> 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.
> >>>>
> >>> use of PCP, NAT-PMP, or UPnP IGD would improve that situation in the
> future.
> >>
> > specifications require the NAPT to not rewrite (not change) the source
> > port number of outgoing SCTP-over-IP packets.  Reference
> >> 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
> >> presumably a separate SCTP port carried in the SCTP protocol within
> >> the UDP message.
> >
> > Right.
> >

Agreed.

> mode implementations over UDP.

The SCTP_REMOTE_UDP_ENCAPS_PORT socket option should work fine with
user-mode SCTP over UDP.  It causes the SCTP stack to send that
additional (meta) data to the remote peer.

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

Yes.

But the greater question is how does the industry want such mobility
to function when the mobility can be instantiated or disabled at
different layers of this deep X-over-Y stack of tunneled protocols.

That decision has a pretty significant impact on SDP, especially
if we want to follow DTLS-SRTP's lead of using "UDP/TLS/RTP/SAVP"
of enumerating every layer in the tunnels.

-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: Randell Jesup <[email-masked]>
Date: Tue, 11 Dec 2012 17:49:01 -0500

>> so this is something that would be nice to define just to be ready for

Right.  We're defining SDP for SCTP here, not *just* for WebRTC. (and 
direct use of rtcweb without WebRTC could allow for multiple 
associations in theory).

> will break prioritization of the audio/video flow above the bulk data.

For the general case, you could provide different DSCP markings, etc, 
per Dan's suggestion.

And also you could run different protocols on top of SCTP, each in an 
association.  One could run DataChannels, another could run BFCP, etc.  
That way they don't conflict (in how they allocate streams, etc).

> screen sharing or an instant message chat.

Right - until we create a new draft, there are buffer-hogging issues 
with large transfers (transfer a 270MB file, like I did at IETF, and all 
other streams are starved until the transfer finishes). Separate 
associations would also deal with the case without needing draft.  
(We'll want the draft for rtcweb).  They might use different congestion 
priorities, etc.

-- 
Randell Jesup
[email-masked]

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 11 Dec 2012 15:12:10 -0800

> will break prioritization of the audio/video flow above the bulk data.

In Lyon, we made the assertion that a browser network stack MUST be able 
to maintain a common congestion state that is shared between the various 
streams (1 or more RTP, at least 1 SCTP, etc.) and which is used to 
prioritize the dispatching of packets onto the network appropriate 
across at least 3 (I recommended 4) priority levels. This is *in 
addition* to the idea that these 3 (or 4) levels are also diffserv 
marked in a way that the network can apply different treatments to them.

(I recommended at least 4 levels to cover 
data-that-is-more-important-than-anything, audio, video, and 
data-that-is-less-important-than-anything)

> screen sharing or an instant message chat.

The fact that SCTP also suffers from a head-of-line blocking issue 
because its flow control is per-association not per-flow (ref: 
http://www.ietf.org/mail-archive/web/rtcweb/current/msg02787.html ) does 
suggest that until that is resolved one might want to use >1 SCTP 
association between peers as well.

Matthew Kaufman