Subject: [MMUSIC] SCTP-SDP and BUNDLE

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Feb 2015 12:15:02 +0000

Hi,

We may have discussed this before, but I'd like to verify.

According to the SCTP RFC, there can only be one SCTP association between two SCTP endpoints.

I ASSUME that applies also to DTLS/SCTP and SCTP/DTLS. If so, I would explicitly indicate that in the SCTP-SDP draft, as I have been asked to add a "BUNDLE considerations" section.

Regards,

Chrsiter

---

From: Christian Groves <[email-masked]>
Date: Fri, 13 Feb 2015 00:58:28 +1100

Hello Christer,

Are you planning on adding anything about the DTLS connection? 
draft-ietf-tsvwg-sctp-dtls-encaps indicates that there may be multiple 
SCTP associations over a DTLS connection.

Christian

On 12/02/2015 11:15 PM, Christer Holmberg wrote:
>
> Hi,
>
> We may have discussed this before, but I’d like to verify.
>
> I ASSUME that applies also to DTLS/SCTP and SCTP/DTLS. If so, I would 
> explicitly indicate that in the SCTP-SDP draft, as I have been asked 
> to add a “BUNDLE considerations” section.
>
> Regards,
>
> Chrsiter
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Feb 2015 14:05:42 +0000

Hi,

>draft-ietf-tsvwg-sctp-dtls-encaps indicates that there may be multiple SCTP associations over a DTLS connection.

That is true, and it was discussed some time ago. Need to check the archives.

Regards,

Christer

On 12/02/2015 11:15 PM, Christer Holmberg wrote:
> to add a "BUNDLE considerations" section.
>
> Regards,
>
> Chrsiter
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Feb 2015 11:43:44 -0500

> between two SCTP endpoints.

I think we've had this discussion before. But I don't get it. Such a 
restriction is *stupid*. Why does it exist?

I *guess* it may be trying to address multihoming, assuming that use of 
activity on multiple addresses/ports belonging to the same endpoint are 
assumed to be alternative addresses for the one association.

But I guess this also depends on what is meant by "endpoint" in this 
definition. If "endpoint" means an IP address and SCTP port, then it 
makes sense.

> explicitly indicate that in the SCTP-SDP draft, as I have been asked to
> add a “BUNDLE considerations” section.

Given that DTLS/SCTP is bound to a single UDP port, and multihoming is 
not supported, I don't see how the restriction makes any sense.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 12 Feb 2015 22:12:04 -0500

> definition. If "endpoint" means an IP address and SCTP port, then it 

I tried to track this down.  The relevant text seems to be RFC 2960
section 1.4:

   o  SCTP association: [...]
      Two SCTP endpoints MUST NOT have
      more than one SCTP association between them at any given time.

   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.

As far as I can tell, a transport address is an IP address and port
number (in the SCTP port number space).  A transport address is used by
at most one SCTP endpoint.  Two SCP endpoints can have only one
association between them.  But I assume that one software entity can
utilize more than one SCTP endpoint, as long as it has different
transport addresses for the two.  This seems to be essentially the same
way TCP handles this issue.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Feb 2015 11:36:22 +0000

Hi,

No matter what the definition of SCTP endpoint is, I think we all agree that one any given 5-tuple there can only be one SCTP association - in the same way there can only be one UDP "connection"/TCP connection on any given 5-tuple.

BUNDLE is all about multiple APPLICATIONS sharing a single transport. For example, the BUNDLE spec gives an example on how SRTP, DTLS and STUN can share a single 5-tuple - using a single transport layer "connection".

So, for SCTP and DTLSoSCTP, where SCTP is pure transport layer, we don't need to say anything. And, if multiple applications want to share a single SCTP association, the SCTP stream concept already allows that.

For SCTPoDTLS, one could of course claim that SCTP is an application, and you could have multiple SCTP applications sharing a single DTLS/UDP (or DTLS/TCP) connection. But, in Honolulu we agreed that we will only allow a single SCTP association per DTLS connection, and I hope we will not change that now. One can use a single SCTP associations with multiple SCTP streams.

So, as far as the SCTP association is concerned, my conclusion is that we don't need to say anything about BUNDLE in the SCTP-SDP draft.

Now, as far as the sctp-port and max-message-size attributes are concerned, we should still say to which "Mux category" [draft-ietf-mmusic-sdp-mux-attributes] they belong. I guess the category could be SPECIAL, and we would then say that there can only be one SCTP m- line within a given BUNDLE group.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: 13. helmikuuta 2015 5:12
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [MMUSIC] SCTP-SDP and BUNDLE

Paul Kyzivat <[email-masked]> writes:
> I *guess* it may be trying to address multihoming, assuming that use 
> of activity on multiple addresses/ports belonging to the same endpoint 
> are assumed to be alternative addresses for the one association.
>

I tried to track this down.  The relevant text seems to be RFC 2960 section 1.4:

As far as I can tell, a transport address is an IP address and port number (in the SCTP port number space).  A transport address is used by at most one SCTP endpoint.  Two SCP endpoints can have only one association between them.  But I assume that one software entity can utilize more than one SCTP endpoint, as long as it has different transport addresses for the two.  This seems to be essentially the same way TCP handles this issue.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Feb 2015 11:46:53 -0500

> No matter what the definition of SCTP endpoint is, I think we all agree that one any given 5-tuple there can only be one SCTP association - in the same way there can only be one UDP "connection"/TC…

You need to be careful about using 5-tuple here. When using native SCTP, 
the 5-tuple consists of "SCTP" (the protocol), two IP addresses, and two 
*SCTP* ports. In that case a "transport address" (for the sctp 
definition of endpoint), is one IP address and one SCTP port.

When using SCTPoDTLS, there is actually a 7-tuple, consisting of 
"SCTPoDTLS" (the protocol), two IP addresses, two SCTP ports, and two 
UDP ports. In this case I think that a transport address for sctp is one 
IP address, one SCTP port, and one UDP port.

> BUNDLE is all about multiple APPLICATIONS sharing a single transport. For example, the BUNDLE spec gives an example on how SRTP, DTLS and STUN can share a single 5-tuple - using a single transport…

I'm dubious of calling "SRTP", "DTLS" and "STUN" *applications*. And 
ultimately BUNDLE is about multiple *media streams* (as the term in used 
in RFC4566) sharing a single 5-tuple. When SCTPoDTLS is in use the 
5-tuple includes the UDP ports, and not the SCTP ports.

> So, for SCTP and DTLSoSCTP, where SCTP is pure transport layer, we don't need to say anything.

AFAIK these cases arent' covered by the current BUNDLE draft, so in that 
sense I agree.

> And, if multiple applications want to share a single SCTP association, the SCTP stream concept already allows that.
>

Yes. In principle there could be multiple SCTP m-lines, distinguished 
from one another by having distinct SCTP ports. But we agreed to rule 
that out of scope of the BUNDLE draft.

AFAIK, allowing it would not violate the SCTP exclusion. Each one would 
constitute a distinct SCTP endpoint.

> So, as far as the SCTP association is concerned, my conclusion is that we don't need to say anything about BUNDLE in the SCTP-SDP draft.

I think this is right.

The SCTP exclusion, read loosely, might appear to exclude two native 
SCTP m-lines, on *different* 5-tuples. I hope that is not intended.

> Now, as far as the sctp-port and max-message-size attributes are concerned, we should still say to which "Mux category" [draft-ietf-mmusic-sdp-mux-attributes] they belong. I guess the category coul…

Yes, that works, for now. It would need to be revisited if we wanted in 
the future to extend to allow multiple SCTP associations on different 
sctp ports.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 Feb 2015 00:07:55 +0000

Hi,

>> No matter what the definition of SCTP endpoint is, I think we all agree that one 
>> any given 5-tuple there can only be one SCTP association - in the same way there 
>> can only be one UDP "connection"/TCP connection on any given 5-tuple.
>
> You need to be careful about using 5-tuple here. When using native SCTP, the 5-tuple 
> consists of "SCTP" (the protocol), two IP addresses, and two *SCTP* ports. In that 
> case a "transport address" (for the sctp definition of endpoint), is one IP address and one SCTP port.

Correct. I should have clarified that I was talking about the case when SCTCP is the actual transport layer protocol.

> When using SCTPoDTLS, there is actually a 7-tuple, consisting of "SCTPoDTLS" (the protocol), two 
> IP addresses, two SCTP ports, and two UDP ports. In this case I think that a transport address for 
> sctp is one IP address, one SCTP port, and one UDP port.
> 
>> BUNDLE is all about multiple APPLICATIONS sharing a single transport. For example, the 
>> BUNDLE spec gives an example on how SRTP, DTLS and STUN can share a single 5-tuple - using 
>> a single transport layer "connection".
>
> I'm dubious of calling "SRTP", "DTLS" and "STUN" *applications*. 
>
> And ultimately BUNDLE is about multiple *media streams* (as the term in used in 
> RFC4566) sharing a single 5-tuple. When SCTPoDTLS is in use the 5-tuple includes the 
> UDP ports, and not the SCTP ports.

Correct.

> AFAIK these cases arent' covered by the current BUNDLE draft, so in that sense I agree.

Good :)

>> For SCTPoDTLS, one could of course claim that SCTP is an application, and you could have 
>> multiple SCTP applications sharing a single DTLS/UDP (or DTLS/TCP) connection. But, in 
>> Honolulu we agreed that we will only allow a single SCTP association per DTLS connection, 
>> and I hope we will not change that now. One can use a single SCTP associations with multiple SCTP streams.
>
> Yes. In principle there could be multiple SCTP m-lines, distinguished from one another by having distinct 
> SCTP ports. But we agreed to rule that out of scope of the BUNDLE draft.

We also agreed to rule that out of scope of the SCTP-SDP draft.

> AFAIK, allowing it would not violate the SCTP exclusion. Each one would constitute a distinct SCTP endpoint.
>
>> So, as far as the SCTP association is concerned, my conclusion is that we don't need to say
>> anything about BUNDLE in the SCTP-SDP draft.
>
> I think this is right.
>
> The SCTP exclusion, read loosely, might appear to exclude two native SCTP m-lines, 
> on *different* 5-tuples. I hope that is not intended.

The SCTP-SDP draft does not (at least that is not the intention) forbid usage of multiple SCTP m- lines. 

And, the actual meaning of 'only-one-SCTP-association-between-two-endpoints' is outside the scope of the SCTP-SDP draft. If we want to clarify that, we need to go elsewhere.

>> Now, as far as the sctp-port and max-message-size attributes are concerned, we should 
>> still say to which "Mux category" [draft-ietf-mmusic-sdp-mux-attributes] they belong. I 
>> guess the category could be SPECIAL, and we would then say that there can only be one 
>> SCTP m- line within a given BUNDLE group.
>
> Yes, that works, for now. It would need to be revisited if we wanted in the future to extend 
> to allow multiple SCTP associations on different sctp ports.

Perhaps, the day when people run out of SCTP streams on a single SCTP association, they may want such extensions. I do wonder whether people would want to put yet another SCTP association on the same 5-tuple in such case, though...

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Feb 2015 19:52:59 -0500

> We also agreed to rule that out of scope of the SCTP-SDP draft.

I don't know what that means. The SCTP-SDP draft says how to construct 
an m-line for SCTP. It doesn't (and shouldn't) say anything about more 
than one.

> The SCTP-SDP draft does not (at least that is not the intention) forbid usage of multiple SCTP m- lines.

The exclusion isn't stated in the SCTP-SDP draft. IIRC it is in the SCTP 
specification.

> Perhaps, the day when people run out of SCTP streams on a single SCTP association, they may want such extensions. I do wonder whether people would want to put yet another SCTP association on the sa…

Running out of streams is not the only reason to want more than one.

You might want more than one if different schemes (application usages) 
are used to manage streams on each. That may become important if/when we 
see another application usage defined.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 Feb 2015 10:59:18 +0000

Hi,

>>>> For SCTPoDTLS, one could of course claim that SCTP is an 
>>>> application, and you could have multiple SCTP applications sharing a 
>>>> single DTLS/UDP (or DTLS/TCP) connection. But, in Honolulu we agreed 
>>>> that we will only allow a single SCTP association per DTLS connection, and I 
>>>> hope we will not change that now. One can use a single SCTP associations with multiple SCTP streams.
>>>
>>> from one another by having distinct SCTP ports. But we agreed to rule that out of scope of the BUNDLE draft.
>>
> I don't know what that means. The SCTP-SDP draft says how to construct an m-line 
> for SCTP. It doesn't (and shouldn't) say anything about more than one.

One of the issues in Honolulu was whether we were going to describe how multiple SCTP associations (separated using the SCTP port) could be carried on a single UDP/TCP 5-tuple, but we decided that we were not going to do that. So, it's aligned with your opinion :)

>>>> So, as far as the SCTP association is concerned, my conclusion is 
>>>> that we don't need to say anything about BUNDLE in the SCTP-SDP draft.
>>>
>>> I think this is right.
>>>
> The exclusion isn't stated in the SCTP-SDP draft. IIRC it is in the SCTP specification.

Correct. My point was that the SCTP-SDP specification would not refer to that exclusion, and define associated SDP exclusions.

>> Perhaps, the day when people run out of SCTP streams on a single SCTP association, they may want 
>> such extensions. I do wonder whether people would want to put yet another SCTP association on 
>> the same 5-tuple in such case, though...
>
> You might want more than one if different schemes (application usages) are used to manage 
> streams on each. That may become important if/when we see another application usage defined.

True. Currently you can only define one application usage (webrtc data channel) per SCTP association. But, people are still able to use that for almost whatever they want, as long as they follow the SCTP guidelines etc for webrtc data channels. 

But, of course, in future there might be a use-case where the webrtc data channel application usage simply isn't applicable, and if someone wants to use both a webrtc data channel and that new application usage at the same time:

1) it either needs to be on separate 5-tuples;
2) someone needs to define how to carry multiple SCTP associations on a single 5-tuple; or 
3) someone needs to define how to negotiate multiple application usages on a single SCTP association.

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Tue, 17 Feb 2015 00:15:13 +1100

I'm abit confused... where are we going to document the agreement from 
Honolulu that only a single SCTP association per DTLS connection is allowed?

The SDP draft references draft-ietf-tsvwg-sctp-dtls-encaps-06:
8. UDP/DTLS/SCTP Transport Realization

    The UDP/DTLS/SCTP transport is realized as described below:

    o  SCTP on top of DTLS is realized according to the procedures
       defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and

ietf-tsvwg-sctp-dtls-encaps states in clause 6.1:

    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.

This leads to a different interpretation.

Regards,
Christian

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Feb 2015 13:23:11 +0000

Hi Christian,

> This leads to a different interpretation.

To be clear, the idea is to document that the SCTP-SDP mechanism doesn't support negotiation of multiple SCTP associations per DTLS connection.

Whether the SCTP-over-DTLS mechanism as such supports it is a separate issue, outside the scope of the SCTP-SDP draft, but of course we can add a note to the SCTP-SDP draft and inform people about it.

Regards,

Christer

>>>>> application, and you could have multiple SCTP applications sharing 
>>>>> a single DTLS/UDP (or DTLS/TCP) connection. But, in Honolulu we 
>>>>> agreed that we will only allow a single SCTP association per DTLS 
>>>>> connection, and I hope we will not change that now. One can use a single SCTP associations with multiple SCTP streams.
>>>> Yes. In principle there could be multiple SCTP m-lines, 
>>>> distinguished from one another by having distinct SCTP ports. But we agreed to rule that out of scope of the BUNDLE draft.
>> I don't know what that means. The SCTP-SDP draft says how to 
>> construct an m-line for SCTP. It doesn't (and shouldn't) say anything about more than one.
> One of the issues in Honolulu was whether we were going to describe 
> how multiple SCTP associations (separated using the SCTP port) could 
> be carried on a single UDP/TCP 5-tuple, but we decided that we were 
> not going to do that. So, it's aligned with your opinion :)
>
>>>> The SCTP exclusion, read loosely, might appear to exclude two 
>>>> native SCTP m-lines, on *different* 5-tuples. I hope that is not intended.
>>> Perhaps, the day when people run out of SCTP streams on a single 
>>> SCTP association, they may want such extensions. I do wonder whether 
>>> people would want to put yet another SCTP association on the same 5-tuple in such case, though...
>> You might want more than one if different schemes (application 
>> usages) are used to manage streams on each. That may become important if/when we see another application usage defined.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 17 Feb 2015 07:35:43 -0500

> Now, as far as the sctp-port and max-message-size attributes are concerned, we should still say to which "Mux category" [draft-ietf-mmusic-sdp-mux-attributes] they belong. I guess the category coul…
Bundle and mux-categories are closely related, so I'm not sure what you 
mean by "don't need to say anything about BUNDLE" in the draft.

Thanks

-- Flemming

> .

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 17 Feb 2015 07:37:31 -0500

On 2/13/15 7:52 PM, Paul Kyzivat wrote:
>> Correct. I should have clarified that I was talking about the case 
>> when SCTCP is the actual transport layer protocol.
>>
>>> "SCTPoDTLS" (the protocol), two
>>>> And, if multiple applications want to share a single SCTP 
>>>> association, the SCTP stream concept already allows that.
>>>>
>>>> application, and you could have
>>> distinguished from one another by having distinct
I disagree; the existence of "bundle" implies that you do need to 
consider the case where there is more than one m-line (even if all you 
want to say is that you are not allowed to bundle such lines).

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 17 Feb 2015 07:38:26 -0500

I think there are several technical details in this discussion that 
would be worthwhile capturing in the draft so people better understand 
how to use it correctly.

Thanks

-- Flemming