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

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

On 12/1/12 9:53 AM, Harald Alvestrand wrote:
> On 12/01/2012 12:03 PM, Salvatore Loreto wrote:
>> 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
> 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 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.

> - 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)
>> 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.
>>
> 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.
>>
>>        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
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>>
>> --
>> Salvatore Loreto, PhD
>> www.sloreto.com
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>