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

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Nov 2014 08:33:10 +0000

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

Now, does that mean that, for a given SDP session, we can only have a single SCTP m- line (read: single SCTP usage)?

For WebRTC usage that is probably enough, as we use SCTP only for the data channel, but in general...

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 25 Nov 2014 12:18:50 +0000

Hi,

<Raju> An SCTP association is identified by 4-tuple: src ip, src port, dst ip, dst port (they form 2 Endpoints). To have a new SCTP association you need to change one parameter in the 4-tuple and most of the times local ip of the client is changed (if app does not specify a port then OS selects a local port). So, between same 2 hosts more than one SCTP associations are allowed.

Per "TCP-Based Media Transport in the Session Description Protocol (SDP) "RFC 4145 (section 4.1), the port conveyed in m= line is server port when a=setup:actpass or passive is used. For a=setup:active, port 9 (discard) should be used (as the client port may not be known until TCP conn is initiated).
I do not see similar semantics in http://www.ietf.org/id/draft-ietf-mmusic-sctp-sdp-07.txt . These semantics are needed in this draft as well for native SCTP usage as well as SCTP over DTLS.

</Raju>

BR

Raju

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Nov 2014 12:40:17 +0000

Hi,

<Christer> That would make sense, but that is not my understanding of the text in RFC 4960, which talks about SCTP endpoints, not 4-tuples. Or, is the 4-tuple part of the SCTP endpoint definition?

<Christer> This was discussed in Honolulu, and the agreement was that the setup attribute will NOT be used to determine who initiates the SCTP association. Instead BOTH endpoints are supposed to trigger the initiation. The setup attribute will only be used to determine the TLS role.

Regards,

Christer

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 25 Nov 2014 13:28:47 +0000

Please see inline comments marked under <Raju2> tags.

Hi,

<Raju2>

RFC 4960 defines SCTP Endpoint as the following. And yes, ip address(es)+port on each side constitutes an endpoint.

o  SCTP endpoint: The logical sender/receiver of SCTP packets.  On a
      multi-homed host, an SCTP endpoint is represented to its peers as
      a combination of a set of eligible destination transport addresses
      to which SCTP packets can be sent and a set of eligible source
      transport addresses from which SCTP packets can be received.  All
      transport addresses used by an SCTP endpoint must use the same
      port number, but can use multiple IP addresses.  A transport
      address used by an SCTP endpoint must not be used by another SCTP
      endpoint.  In other words, a transport address is unique to an
      SCTP endpoint.

</Raju2>

<Raju2>

2 use cases:

1.SCTP over DTLS: For this yes, a=setup is for DTLS.

  The sctp port usage needs be clarified indicating it is the server port, not the client port.

2.Native SCTP: I believe a=setup is for SCTP association.

When a=setup:passive/actpass is used the sctp port usage needs to be clarified indicating it is the server port. When a=setup:active is used port must be 9 (discard port). This needs clarification as well.

Both sides trying to open SCTP simultaneously is probably ok because SCTP allows them to be converted into single association if there are simultaneous INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. This is per RFC 4960 section 5.2.1<http://tools.ietf.org/html/rfc4960#section-5.2.1> and 5.2.2<http://tools.ietf.org/html/rfc4960#section-5.2.2> .

But the key here is same 4-tuple, which means the client must use same **server port** to initiate an outgoing association. If this is not done then, the end result will be 2 SCTP associations setup and/or one of them may be rejected and may depend on implementation.

So, I believe some clarifications are needed in this area.

</Raju2>

BR

Raju

Regards,

Christer

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Nov 2014 13:45:55 +0000

Hi,

<Raju2>

</Raju2>

<Christer2> Well, I hope you are right :)

<Raju2>

2 use cases:

<Christer2> Yes.

<Christer2> So, assuming we don't use (per the agreement in Honolulu) a=setup for the SCTP association, we would need to mandate (or, at least say SHOULD) usage of the server port also to initiate an outgoing association, in order to avoid 2 SCTP associations.

But, that also applies to SCTP over DTLS, doesn't it?

Regards,

Christer

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 25 Nov 2014 13:53:29 +0000

Please see comments under <Raju3> tags.

<Raju2>

2 use cases:

<Christer2> Yes.

<Raju3>

Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the above description under "native SCTP" instead of "SCTP over DTLS". For native SCTP, as discussed, a=setup negotiation determines which side initiates SCTP association, so the semantics are very clear here.

</Raju3>

BR

Raju

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Nov 2014 14:03:59 +0000

Hi,

<Raju2>

2 use cases:

<Christer2> Yes.

<Raju3>

<Christer3> The idea was to not use a=setup for any "type" of SCTP, including native SCTP.

Regards,

Christer

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Tue, 25 Nov 2014 14:26:40 +0000

To SCTP (RFC 4960), - and without consideration of SCTP protocol object represenation in SDP:

RFC 4960 defines actually (SCTP)-transport-connection-endpoints (using OSI-BRM terminology), equated as SCTP endpoint.
Whereas an (SCTP)-endpoint usually relates to the SCTP protocol implementation in an open system (terminal, gateway, etc).
An (SCTP)-endpoint is always able to instantiate multiple (SCTP)-connection-endpoint or (SCTP)-transport-connection-endpoint objects (given that the open systems provides multihomed IP host support).

Hence, there's a 1:N relation between (SCTP)-endpoint and (SCTP)-(transport)-connection-endpoints.

Consequently, an SDP media description ( c/m lines) indicates an (SCTP)-transport-connection-endpoint object, but not an (SCTP)-endpoint.
Fairly precise and clear in OSI-BRM terms (but you might be in trouble if you equate both).

-Albrecht

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Dienstag, 25. November 2014 15:04
To: Makaraju, Maridi Raju (Raju); [email-masked]
Subject: Re: [MMUSIC] Single SCTP usage per SDP session?

Hi,

<Raju2>

2 use cases:

<Christer2> Yes.

<Raju3>

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 25 Nov 2014 15:04:55 +0000

Please see inline comments marked under <Raju4>

<Raju3>

<Raju4>

I see. The SCTP draft-ietf-mmusic-sctp-sdp is obviously not yet updated as it still has a=setup based semantics.

</Raju4>

BR

Raju

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Tue, 25 Nov 2014 09:30:04 -0600

I want to go on record to say that this is the least readable 
quoting/reply style I've ever had to deal with in my life. I lost track 
of the conversation about three messages ago.

/a

On 11/25/14 08:03, Christer Holmberg wrote:
>
> Hi,
>
> /<Christer> This was discussed in Honolulu, and the agreement was that the setup attribute will NOT be used to determine who initiates the SCTP association. Instead BOTH endpoints are supposed to trigger the initiation. The setup attribute will only be used to determine the TLS role./
> */<Raju2>/*
> /2 use cases:/
> /1.SCTP over DTLS: For this yes, a=setup is for DTLS./
> /   The sctp port usage needs be clarified indicating it is the server port, not the client port./
> /  /
> /<Christer2> Yes./
> /  /
> /  /
> /2.Native SCTP: I believe a=setup is for SCTP association./
> /When a=setup:passive/actpass is used the sctp port usage needs to be clarified indicating it is the server port. When a=setup:active is used port must be 9 (discard port). This needs clarification as well./
> /Both sides trying to open SCTP simultaneously is probably ok because SCTP allows them to be converted into single association if there are simultaneous INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. This is per RFC 4960 section5.2.1  <http://tools.ietf.org/html/rfc4960#section-5.2.1>  and5.2.2  <http://tools.ietf.org/html/rfc4960#section-5.2.2>  ./
> /But the key here is same 4-tuple, which means the client must use same **server port** to initiate an outgoing association. If this is not done then, the end result will be 2 SCTP associations setup and/or one of them may be rejected and may depend on implementation./
> /So, I believe some clarifications are needed in this area./
> /  /
> /<Christer2> So, assuming we don’t use (per the agreement in Honolulu) a=setup for the SCTP association, we would need to mandate (or, at least say SHOULD) usage of the server port also to initiate an outgoing association, in order to avoid 2 SCTP associations./
> /  /
> /But, that also applies to SCTP over DTLS, doesn’t it?/
> */<Raju3>/*
> */Sorry, it actually ONLY applies to SCTP over DTLS. I misplaced the above description under “native SCTP” instead of “SCTP over DTLS”. For native SCTP, as discussed, a=setup negotiation determines which side initiates SCTP association, so the semantics are very clear here./*
> */  /*
> /<Christer3> The idea was to not use a=setup for any “type” of SCTP, including native SCTP./
> /  /
> /Regards,/
> /  /
> /Christer/
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Nov 2014 13:54:14 -0500

> of the conversation about three messages ago.

+1 !!!

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Nov 2014 14:04:48 -0500

I've been trying to follow this thread, without much success. But I 
hadn't seen much said that seemed to be authoritative about SCTP until I 
got to this message. But without going to study 4960 I don't find the 
quote below to be very enlightening either.

It does seem like it must be important to identify exactly what an SCTP 
endpoint is. It may well be that an SDP offerer or answerer might be 
allowed to be managing multiple SCTP endpoints.

I will guess that the constraint Christer is asking about has something 
to do with multihomed SCTP associations, and the need to recognize that 
all of those are tied together. I don't know how that is expected to be 
done in SDP, if at all. I don't see any way within SDP to explicitly 
identify multiple IP address/port combinations for the same SCTP 
association. Perhaps if the c-line has a DNS name, and that can be 
resolved to multiple IP addresses?

ISTM that, absent some additional bundle extensions, every SCTP m-line 
in an SDP offer/answer should be considered to be bound to a separate 
SCTP association.

	Thanks,
	Paul

On 11/25/14 9:26 AM, Schwarz, Albrecht (Albrecht) wrote:
> RFC 4960 defines actually /(SCTP)-transport-connection-endpoints/ (using
> OSI-BRM terminology), equated as SCTP endpoint.
>
> Whereas an /(SCTP)-endpoint/ usually relates to the /SCTP protocol
> implementation/ in an open system (terminal, gateway, etc).
>
> An (SCTP)-endpoint is always able to /instantiate multiple
> (SCTP)-connection-endpoint/ or /(SCTP)-transport-connection-endpoint
> objects/ (given that the open systems provides multihomed IP host support).
>
> Hence, there’s a 1:N relation between (SCTP)-endpoint and
> (SCTP)-(transport)-connection-endpoints.
>
> Consequently, an SDP media description ( c/m lines) indicates an
> (SCTP)-transport-connection-endpoint object, but not an (SCTP)-endpoint.
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* Dienstag, 25. November 2014 15:04
> *To:* Makaraju, Maridi Raju (Raju); [email-masked]
> *Subject:* Re: [MMUSIC] Single SCTP usage per SDP session?
>
> Hi,
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Nov 2014 19:13:53 +0000

Hi Paul,

My question was not about multihoming, about the fact that an SCTP endpoint is only allowed to create a single association, which would mean that we could only have one SCTP usage per SDP session.

...unless, "SCTP device" is bound to a specific address:port, in which case an SDP body could contain multiple SCTP associations - at least if they were un-bundled. Within a BUNDLE group, however, it would mean that only one SCTP association is allowed.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎25/‎11/‎2014 21:05
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] Single SCTP usage per SDP session?

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Nov 2014 14:30:51 -0500

On 11/25/14 2:13 PM, Christer Holmberg wrote:
> Hi Paul,
>
> My question was not about multihoming, about the fact that an SCTP
> endpoint is only allowed to create a single association, which would
> mean that we could only have one SCTP usage per SDP session.

I know your question wasn't about multihoming. I brought it up because 
of an inference on my part that the restriction you reference is 
probably related to multihoming - that different addresses will be bound 
to the same association rather than to different ones. That assumes 
there is isn't any way to distinguish the differing usages and allow 
them to coexist in some sensible way.

> ...unless, "SCTP device" is bound to a specific address:port, in which
> case an SDP body could contain multiple SCTP associations - at least if
> they were un-bundled. Within a BUNDLE group, however, it would mean that
> only one SCTP association is allowed.

In a bundle group, with SCTPoDTLS, ISTM you could have multiple SCTP 
associations, each on a distinct SCTP port. I don't see any ambiguity 
there. But it will require added specification of how bundle works in 
that case. Clearly they won't be multihomed - SCTPoDTLS can't be.

	Thanks,
	Paul

> ------------------------------------------------------------------------
> From: Paul Kyzivat <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
>> /Both sides trying to open SCTP simultaneously is probably ok because SCTP allows them to be converted into single association if there are simultaneous INITs (or INIT chunk received in ESTABLISHED state) on the same 4-tuple. This is per RFC 4960 section5.2.1<http://tools.ietf.org/html/rfc4960#section-5.2.1>  and5.2.2
> <http://tools.ietf.org/html/rfc4960#section-5.2.2>  ./
>>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Nov 2014 19:42:46 +0000

Hi Paul,

Whether multiple SCTP associations, with different SCTP port values, are allowed depends on whether they are considered to belong to different SCTP endpoints or not.

Perhaps this is the wrong WG to ask this question:)

Regards,

Christet

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎25/‎11/‎2014 21:30
To: Christer Holmberg<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] Single SCTP usage per SDP session?

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Nov 2014 15:02:12 -0500

On 11/25/14 2:42 PM, Christer Holmberg wrote:
> Hi Paul,
>
> Whether multiple SCTP associations, with different SCTP port values, are
> allowed depends on whether they are considered to belong to different
> SCTP endpoints or not.
>

Probably.

	Thanks,
	Paul

> To: Christer Holmberg <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
>>> /<Christer> This was discussed in Honolulu, and the agreement was that the setup attribute will NOT be used to determine who initiates the SCTP association. Instead BOTH endpoints are supposed to trigger the initiation. The setup attribute will only be usedto determine the TLS role./
>>>
>>> */<Raju2>/*
>>>
>>> /2 use cases:/
>>>

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 26 Nov 2014 09:07:54 +0000

Hi there,

in order to provide a clear and readable answer I am answering directly the first mail of the thread.
See in line

br
Salvatore

On Nov 25, 2014, at 10:33 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

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>

For WebRTC usage that is probably enough, as we use SCTP only for the data channel, but in general…

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

I hope it helps to clarify the issue.
</Sal>

Regards,

Christer
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Nov 2014 10:36:28 +0000

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

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.

>      demultiplexing the SCTP associations carried over a single DTLS

Based on the one-SCTP-assocation-per-4-tuple assumption, isn't that text wrong? 

Regards,

Christer

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 26 Nov 2014 10:42:14 +0000

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Nov 2014 11:29:31 +0000

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

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.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Nov 2014 09:59:15 -0500

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

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.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Nov 2014 15:03:31 +0000

Hi,

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

Regards,

Christer

	Thanks,
	Paul

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 26 Nov 2014 15:30:27 +0000

> >>> 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).
> >>>
> >>> 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.
> >>>
> >> 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
> > because it implies that different SCTP associations use different ports
> (i.e. each of them use an unique 4-tuples)
> 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.

<Raju>
Per my understanding, draft-ietf-tsvwg-sctp-dtls-encaps just talks about SCTP over DTLS and allowing multiple SCTP associations, which is perfectly fine.
Then it is possible to come up with SCTP-SDP semantics to use that capability.
One m= line allowing one SCTP over DTLS limit is fine. Using BUNDLE you can replicate same 4-tuple in multiple m= lines. Then there is only one DTLS association established and multiple SCTP associations over that is possible (one per m= line).
If BUNDLE is not used then I believe same 4-tuple on multiple m= lines are NOT possible. This is because, per my understanding, unlike TCP/native-SCTP used under non-ICE environments, in ICE-environments the TCP/UDP port specified is used both as client and server port for DTLS. 

I am not sure if draft-ietf-mmusic-sctp-sdp makes any distinction between use of ICE or not. I believe the semantics for port in m= line are different when ICE is used vs. ICE is not used.
- When ICE is used it is the client as well as the server port.
- When ICE is not used, the port is the server port and not the client port. For a=setup:active cases discard port 9 is used per RFC 4145, which draft-ietf-mmusic-sctp-sdp refers.

</Raju>

BR
Raju

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 26 Nov 2014 16:16:28 +0000

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Nov 2014 18:53:35 +0000

Hi,

...
 
>>>> 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.
>>> 
> The uniqueness SCTP rfc 4960 is referring to is the "classic" transport level 4-tuple and this respected in the sctp-dtls-encaps draft.

That's fine.

But, the fact is that each SCTP association will be transported on a single UDP/TCP 4-tuple (the SCTP port will only be used for de-multiplexing by the endpoints), and I see no harm in mentioning that.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Nov 2014 19:00:37 +0000

-----Original Message-----
From: Makaraju, Maridi Raju (Raju) [mailto:[email-masked]] 
Sent: 26 November 2014 17:30
To: Christer Holmberg; Salvatore Loreto
Cc: [email-masked]
Subject: RE: [MMUSIC] Single SCTP usage per SDP session?

> 
> >>> Hopefully there are some SCTP experts in da hause that can clarify 
> >>> the
> following:
> >>>
> SCTP/SCTPoDTLS/DTLSoSCTP association, we will only allow a single 
> usage (e.g. a webrtc-datachannel).
> >>>
> one SCTP association between them at any given time. Not exactly sure 
> why, but that is what the text says.
> >>>
> >>>                 composed of the two SCTP endpoints and protocol 
> >>> state
> information
> >>>                 including Verification Tags and the currently 
> >>> active set
> of
> >>>                 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>
> >>
> >>> we already have the following text that implies that is possible 
> >>> to have multiple SCTP associations between two endpoints
> >>>
> >> Based on the one-SCTP-assocation-per-4-tuple assumption, isn't that 
> >> text
> wrong?
> >
> > <Sal>
> > the text is correct!
> 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.

<Raju>
> One m= line allowing one SCTP over DTLS limit is fine. Using BUNDLE you can replicate same 4-tuple in multiple m= lines. Then there is only one DTLS association 
> established and multiple SCTP associations over that is possible (one per m= line).
> If BUNDLE is not used then I believe same 4-tuple on multiple m= lines are NOT possible. This is because, per my understanding, unlike TCP/native-SCTP used under non-
> ICE environments, in ICE-environments the TCP/UDP port specified is used both as client and server port for DTLS. 

Even with BUNDLE, you would have to use the same m= line port value from the beginning, which is not allowed. So, you basically would have to add the additional SCTPoDTLS m= lines once the usage of BUNDLE has been negotiated.

> I am not sure if draft-ietf-mmusic-sctp-sdp makes any distinction between use of ICE or not. I believe the semantics for port in m= line are different when ICE is used vs. ICE > is not used.

Per the agreement in Honolulu, there will be no port 9 for SCTP, as the agreement was that both endpoints will initiate the SCTP association.

And, in order to prevent two separate SCTP associations to be established, the m= line port needs to indicate both the client and server port also without ICE.

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 26 Nov 2014 19:58:47 +0000

> > Per my understanding, draft-ietf-tsvwg-sctp-dtls-encaps just talks about
> SCTP over DTLS and allowing multiple SCTP associations, which is perfectly
> fine.
> > One m= line allowing one SCTP over DTLS limit is fine. Using BUNDLE you
> can replicate same 4-tuple in multiple m= lines. Then there is only one DTLS
> association
> > If BUNDLE is not used then I believe same 4-tuple on multiple m= lines are
> NOT possible. This is because, per my understanding, unlike TCP/native-SCTP
> used under non-
> Even with BUNDLE, you would have to use the same m= line port value from the
> beginning, which is not allowed. So, you basically would have to add the
> additional SCTPoDTLS m= lines once the usage of BUNDLE has been negotiated.

<Raju>
You are right. Section 8.2.1 of draft-ietf-mmusic-sdp-bundle-negotiation
says the m= line should have unique 4-tuple to allow possibility of 
BUNDLE rejection. Very valid.
However, to facilitate multiple SCTP over same bundled SCTP, 
won't the following work?
- Offerer adds one m= line for each SCTP association needed.
- If the answerer selects BUNDLE then all the SCTP m= lines now map
  and use the same DTLS association.
- If the answerer does not accept BUNDLE then we don't have the option
  of negotiating multiple SCTPs over same DTLS anyway; so it will result
  in multiple DTLS, which still gives you a way to get multiple SCTPs.

With this approach a new subsequent SDP offer is not needed to 
add SCTP m= lines.
</Raju>

> 
> > I am not sure if draft-ietf-mmusic-sctp-sdp makes any distinction between
> use of ICE or not. I believe the semantics for port in m= line are different
> when ICE is used vs. ICE > is not used.
> >-  When ICE is not used, the port is the server port and not the client
> port. For a=setup:active cases discard port 9 is used per RFC 4145, which
> draft-ietf-mmusic-sctp-sdp
> > refers.
> 
> Per the agreement in Honolulu, there will be no port 9 for SCTP, as the
> agreement was that both endpoints will initiate the SCTP association.
> 
> And, in order to prevent two separate SCTP associations to be established,
> the m= line port needs to indicate both the client and server port also
> without ICE.

<Raju>
So, these 2 clarifications are needed in draft-ietf-mmusic-sctp-sdp as
it deviates from referred RFC 4145.
</Raju>

BR
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Nov 2014 10:19:18 +0000

Hi,

>> Even with BUNDLE, you would have to use the same m= line port value 
>> from the beginning, which is not allowed. So, you basically would have 
>> to add the additional SCTPoDTLS m= lines once the usage of BUNDLE has been negotiated.
>
> <Raju>
> says the m= line should have unique 4-tuple to allow possibility of BUNDLE rejection. Very valid.
> However, to facilitate multiple SCTP over same bundled SCTP, won't the following work?
> With this approach a new subsequent SDP offer is not needed to add SCTP m= lines.
> </Raju>

Correct.

But, still, without BUNDLE you will only be able to negotiate a single SCTP association per DTLS connection.

>>> I am not sure if draft-ietf-mmusic-sctp-sdp makes any distinction 
>>> between use of ICE or not. I believe the semantics for port in m= line are 
>>> different when ICE is used vs. ICE > is not used.
>>> -  When ICE is not used, the port is the server port and not the 
>>> client port. For a=setup:active cases discard port 9 is used per RFC 4145, 
>>> which draft-ietf-mmusic-sctp-sdp refers.
>> 
>> Per the agreement in Honolulu, there will be no port 9 for SCTP, as 
>> the agreement was that both endpoints will initiate the SCTP association.
>> 
>> And, in order to prevent two separate SCTP associations to be 
>> established, the m= line port needs to indicate both the client and 
>> server port also without ICE.
>
> <Raju>
> So, these 2 clarifications are needed in draft-ietf-mmusic-sctp-sdp as it deviates from referred RFC 4145.
> </Raju>

Yes, it will be covered in the next version.

But, I also want to be sure that people are ok with such approach. So, if someone thinks we should use the setup attribute to negotiate which endpoint initiates the SCTP association, please speak up now :)

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 27 Nov 2014 13:10:28 +0000

> association per DTLS connection.

<Raju>
This is also apparent from the fact that only one a=sctp-port allowed per m= line.
Mandating the use of BUNDLE to allow multiple SCTP associations seems reasonable to me.
</Raju>

> But, I also want to be sure that people are ok with such approach. So, if
> someone thinks we should use the setup attribute to negotiate which endpoint
> initiates the SCTP association, please speak up now :)

<Raju>
I see that the NAT traversal as a big advantage of both peers attempt to open SCTP association. SCTP INIT chunk will punch holes in NAT box which will then allows incoming INIT CHUNK or INT ACK. All this is possible because SCTP RFC http://tools.ietf.org/html/rfc4960#section-5.2.1 allows such INIT collisions and converts them into a single SCTP association; however the 4-tuple (+additional IPs) should match though.
This is the issue with a=setup usage for TCP and SDP descriptions (without ICE) specifying only the server port; though TCP allows simultaneous open, per a=setup only one side can initiate TCP conn which will not punch a hole in other end's NAT and results in TCP SYN being dropped. 

How about the concern of NATs and hosts not supporting simultaneous SCTP open? there by limiting the success rate?
Similar concerns were voiced here at http://tools.ietf.org/html/rfc6544#appendix-A for TCP.

</Raju>

BR
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Nov 2014 17:30:03 +0000

Hi,

...

>> But, I also want to be sure that people are ok with such approach. So, 
>> if someone thinks we should use the setup attribute to negotiate which 
>> endpoint initiates the SCTP association, please speak up now :)
>
> <Raju>
> I see that the NAT traversal as a big advantage of both peers attempt to open SCTP association. 
> SCTP INIT chunk will punch holes in NAT box which will then allows incoming INIT CHUNK or INT 
> ACK. All this is possible because SCTP RFC http://tools.ietf.org/html/rfc4960#section-5.2.1 allows 
> such INIT collisions and converts them into a single SCTP association; however the 4-tuple 
> (+additional IPs) should match though.
> This is the issue with a=setup usage for TCP and SDP descriptions (without ICE) specifying only the server 
> port; though TCP allows simultaneous open, per a=setup only one side can initiate TCP conn which will
> not punch a hole in other end's NAT and results in TCP SYN being dropped. 

Not that, in case of 'DTLS/SCTP', the transport layer protocol will be UDP or TCP, and in case of TCP I assume the setup attribute WILL
be used as defined in RFC 4145 when establishing the TCP connection. 

> How about the concern of NATs and hosts not supporting simultaneous SCTP open? there by limiting the success rate?

I have no idea.

(In case of 'DTLS/SCTP' it doesn't matter, though, as the transport layer protocol will be UDP or TCP.)

Regards,

Christer