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

[Paul Kyzivat <[e-mail]>]

On 12/11/12 5:34 AM, [e-mail] wrote:
> 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)
>>   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.
>>
>
> 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.

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

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