Re: [MMUSIC] Single SCTP usage per SDP session?

[Salvatore Loreto <[e-mail]>]

On Nov 26, 2014, at 5:03 PM, Christer Holmberg <[e-mail]> wrote:

> Hi,
> 
>>>>>> Hopefully there are some SCTP experts in da hause that can clarify the following:
>>>>>> 
>>>>>> Previously, in the SCTP-SDP discussions, we have agreed that for a given SCTP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single usage (e.g. a webrtc-datachannel).
>>>>>> 
>>>>>> So, if one wants multiple usages, one needs to establish multiple associations, using multiple m- lines.
>>>>>> 
>>>>>> BUT, according to RFC 4960, two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time. Not exactly sure why, but that is what the text says.
>>>>>> 
>>>>>>      "SCTP association: A protocol relationship between SCTP endpoints,
>>>>>>                 composed of the two SCTP endpoints and protocol state information
>>>>>>                 including Verification Tags and the currently active set of
>>>>>>                 Transmission Sequence Numbers (TSNs), etc.  An association can be
>>>>>>                 uniquely identified by the transport addresses used by the
>>>>>>                 endpoints in the association.  Two SCTP endpoints MUST NOT have
>>>>>>                 more than one SCTP association between them at any given time."
>>>>>> 
>>>>>> <Sal>
>>>>>> That is not a problem.
>>>>>> As it has also already suggested it is enough to use a different port number on one side.
>>>>>> </Sal>
>>>>> 
>>>>> After discussing with an SCTP expert, my understanding is that it is enough to have a unique 4-tuple for each SCTP association.
>>>>> 
>>>>> So, that means that SDP can contain multiple m- lines describing an SCTP association, as long as each use unique 4-tuples.
>>>>> 
>>>>> However, afaik, that means that a BUNDLE group CANNOT contain multiple SCTP associations, as they would all share the same 4-tuple.
>>>>> 
>>>>> 
>>>>>> <Sal>
>>>>>> note also that in
>>>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-06
>>>>>> we already have the following text that implies that is possible to 
>>>>>> have multiple SCTP associations between two endpoints
>>>>>> 
>>>>>>  o  Multiple SCTP associations MAY be multiplexed over a single DTLS
>>>>>>     connection.  The SCTP port numbers are used for multiplexing and
>>>>>>     demultiplexing the SCTP associations carried over a single DTLS
>>>>>>     connection.
>>>>> 
>>>>> Based on the one-SCTP-assocation-per-4-tuple assumption, isn't that text wrong?
>>>> 
>>>> <Sal>
>>>> the text is correct!
>>>> because it implies that different SCTP associations use different ports (i.e. each of them use an unique 4-tuples)
>>>> 	-> "The SCTP port numbers are used for multiplexing and demultiplexing..."
>>>> </Sal>
>>> 
>>> Well, in case of SCTPoDTLS one could claim that the SCTP port is not 
>>> really part of the 4-tuple. But, if the tsvwg folks are ok to 
>>> multiplex multiple SCTP associations using a single UDP/TCP port, then 
>>> fine... I don't have any strong opinion - I just want to clarify :)
>>> 
>>> However, in the SCTP-SDP discussions in Honolulu it was agreed to only allow a single SCTP association in the case of 
>>> SCTPoDTLS (even if draft-ietf-tsvwg-sctp-dtls-encaps allows multiple). The reason is that you would otherwise have 
>>> multiple m- lines with the same port value (even if you don't use BUNDLE), as the port indicates the UDP/TCP port - not the SCTP port.
>> 
>> IMO when considering SCTPoDTLS we need to be talking about a unique 6-tuple, not a 4-tuple: 2 IP addresses, 2 UDP ports, 2 SCTP ports.
> 
> Perhaps it would be a good idea to add some clarification text regarding this in the draft-ietf-tsvwg-sctp-dtls-encaps.

I completely disagree.
The uniqueness SCTP rfc 4960 is referring to is the "classic" transport level 4-tuple 
and this respected in the sctp-dtls-encaps draft.

br
Salvatore

> 
> Regards,
> 
> Christer
> 
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic