Subject: [MMUSIC] SCTP-SDP: Mux category for SDP sctp-port and max-message-size attributes

From: Christer Holmberg <[email-masked]>
Date: Sun, 22 Feb 2015 16:18:38 +0000

Hi,

I've been asked to include the MUX category (as defined in draft-ietf-mmusic-sdp-mux-attributes) for the SDP attributes defined in the SCTP-SDP draft: sctp-port and max-message-size.

For 'SCTP' and 'SCTP/DTLS' I assume it is rather straight forward. The sctp-port attribute is not used to begin with, and the max-message-size applies to the transport layer SCTP association.

'(UDP | TCP)/DTLS/SCTP' is a little different.  The draft says (or, *will* say, based on the agreement in Honolulu) that multiple SCTP associations over a single '(UDP | TCP)/DTLS' connection is outside the scope of the document, which means it is not possible to have multiple '(UDP | TCP)/DTLS/SCTP' m- lines within a BUNDLE group.

Currently, unless I've missed something, there is however no category for attributes that can't be bundled, eventhough one could perhaps claim that the NOT RECOMMENDED category fits. So, I see three options:

1)      Allocate SPECIAL category, with a description saying that they can't be bundled

2)      Allocate NOT RECOMMENDED category

3)      Define a new mux category, for attributes that can't be bundled

Comments? My personal preference would be either 2) or 3).

SCTP:
=====

Attribute:                          Mux category:

sctp-port                           Not applicable
max-message-size          TRANSPORT

SCTP/DTLS:
==========

sctp-port                           Not applicable
max-message-size          TRANSPORT

(UDP | TCP)/DTLS/SCTP:
=====================

Attribute:                          Mux category:

sctp-port                           SPECIAL | New category
max-message-size          SPECIAL | New category

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 Feb 2015 12:26:31 -0500

On 2/22/15 11:18 AM, Christer Holmberg wrote:
> Hi,
>
> I’ve been asked to include the MUX category (as defined in
> draft-ietf-mmusic-sdp-mux-attributes) for the SDP attributes defined in
> the SCTP-SDP draft: sctp-port and max-message-size.
>
> For ‘SCTP’ and ‘SCTP/DTLS’ I assume it is rather straight forward. The
> sctp-port attribute is not used to begin with, and the max-message-size
> applies to the transport layer SCTP association.
>
> ‘(UDP | TCP)/DTLS/SCTP’ is a little different.  The draft says (or,
> **will** say, based on the agreement in Honolulu) that multiple SCTP
> associations over a single ‘(UDP | TCP)/DTLS’ connection is outside the
> scope of the document, which means it is not possible to have multiple
> ‘(UDP | TCP)/DTLS/SCTP’ m- lines within a BUNDLE group.
>
> Currently, unless I’ve missed something, there is however no category
> for attributes that can’t be bundled, eventhough one could perhaps claim
> that the NOT RECOMMENDED category fits. So, I see three options:
>
> 1)Allocate SPECIAL category, with a description saying that they can’t
> be bundled
>
> 2)Allocate NOT RECOMMENDED category
>
> 3)Define a new mux category, for attributes that can’t be bundled
>

As you say, the bundle draft currently forbids multiplexing these.

Suppose an extension was done to allow multiple '(UDP | TCP)/DTLS/SCTP' 
in a bundle. In that case it clearly would be necessary for them to be 
distinguished by sctp-port. And that would presumably be specified in 
the document that defines that behavior.

So why not just classify this attribute as SPECIAL? That covers the 
case, both now and in the future.

	Thanks,
	Paul

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 22 Feb 2015 19:32:55 +0000

Hi,

>> I've been asked to include the MUX category (as defined in
>> draft-ietf-mmusic-sdp-mux-attributes) for the SDP attributes defined 
>> in the SCTP-SDP draft: sctp-port and max-message-size.
>>
>> For 'SCTP' and 'SCTP/DTLS' I assume it is rather straight forward. The 
>> sctp-port attribute is not used to begin with, and the 
>> max-message-size applies to the transport layer SCTP association.
>>
>> '(UDP | TCP)/DTLS/SCTP' is a little different.  The draft says (or,
>> associations over a single '(UDP | TCP)/DTLS' connection is outside 
>> the scope of the document, which means it is not possible to have 
>> multiple '(UDP | TCP)/DTLS/SCTP' m- lines within a BUNDLE group.
>>
>> Currently, unless I've missed something, there is however no category 
>> for attributes that can't be bundled, eventhough one could perhaps 
>> claim that the NOT RECOMMENDED category fits. So, I see three options:
>>
>> 1)Allocate SPECIAL category, with a description saying that they can't 
>> be bundled
>>
>> 3)Define a new mux category, for attributes that can't be bundled
>>

I don't think the bundle draft forbids it, but the SCTP-SDP drafts says that the negotiation of multiple SCTP associations on a single DTLS connection is outside the scope of the draft.

> Suppose an extension was done to allow multiple '(UDP | TCP)/DTLS/SCTP' in a bundle. In 
> that case it clearly would be necessary for them to be distinguished by sctp-port. And that 
> would presumably be specified in the document that defines that behavior.
>
> So why not just classify this attribute as SPECIAL? That covers the case, both now and in the future.

That is one option.

However, any future extension would perhaps need to change the value.

For example, I assume the value for the sctp-port attribute would be UNIQUE - which is another category that currently doesn't exist :)

And, I guess the max-message-size would be NORMAL, as different values may be used on each SCTP association.

But, in any case: it seems like we, for the same attribute, need to register different category values depending on the proto value. How would we do that? 

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 Feb 2015 15:58:44 -0500

> And, I guess the max-message-size would be NORMAL, as different values may be used on each SCTP association.

If there was a UNIQUE category then it could be used. But certainly 
SPECIAL can continue to be used.

> But, in any case: it seems like we, for the same attribute, need to register different category values depending on the proto value. How would we do that?

Yes, that is something new that must be dealt with.

OR, again it can simply be defined as SPECIAL, and all these rules can 
be defined in this document.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 Feb 2015 04:51:56 +0000

Hi,

>>>> For 'SCTP' and 'SCTP/DTLS' I assume it is rather straight forward. 
>>>> The sctp-port attribute is not used to begin with, and the 
>>>> Currently, unless I've missed something, there is however no 
>>>> category for attributes that can't be bundled, eventhough one could 
>>>> perhaps claim that the NOT RECOMMENDED category fits. So, I see three options:
>>>>
>>>> 1)Allocate SPECIAL category, with a description saying that they 
>>>> can't be bundled
>>>>
>> I don't think the bundle draft forbids it, but the SCTP-SDP drafts says that the 
>> negotiation of multiple SCTP associations on a >single DTLS connection is outside the scope of the draft.
>>
>>> Suppose an extension was done to allow multiple '(UDP | TCP)/DTLS/SCTP' in a 
>>> bundle. In that case it clearly would be necessary for them to be distinguished by 
>>> sctp-port. And that would presumably be specified in the document that defines that behavior.
>>>
>> For example, I assume the value for the sctp-port attribute would be 
>> UNIQUE - which is another category that currently doesn't exist :)
>>
> If there was a UNIQUE category then it could be used. But certainly SPECIAL can continue to be used.

Perhaps it would be useful to define a UNIQUE category no matter what, but that's a separate issue.

>> But, in any case: it seems like we, for the same attribute, need to register different 
>> category values depending on the proto value. How would we do that?
>
> OR, again it can simply be defined as SPECIAL, and all these rules can be defined in this document.

Yes.

Then, exactly where are the rules defined? Do they need to be in the IANA template? Or, is the category value enough as far as IANA is concerned, and the rules are then defined somewhere else in the document?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Feb 2015 10:26:33 -0500

> Then, exactly where are the rules defined? Do they need to be in the IANA template? Or, is the category value enough as far as IANA is concerned, and the rules are then defined somewhere else in th…

I think the latter.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 Feb 2015 20:17:31 +0000

Hi,

....

>>>> But, in any case: it seems like we, for the same attribute, need to 
>>>> register different category values depending on the proto value. How would we do that?
>>>
>> Then, exactly where are the rules defined? Do they need to be in the IANA template? 
>> Or, is the category value enough as far as IANA is concerned, and the rules are then 
>> defined somewhere else in the document?
>
> I think the latter.

Did you take a look at the suggested text I sent out?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Feb 2015 12:33:33 -0500

> Did you take a look at the suggested text I sent out?

I'm now lost in the thread. I am guessing that the text you are 
referring to is back in:

http://mailarchive.ietf.org/arch/msg/mmusic/kVBnfuPgiHS40-KhYvaXYIPzaNE

but there has been much discussion since then. Can you restate what you 
have in mind in light of all that discussion?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Feb 2015 17:42:32 +0000

Hi,

>>>> Or, is the category value enough as far as IANA is concerned, and 
>>>> the rules are then defined somewhere else in the document?
>>>
>>> I think the latter.
>>
> I'm now lost in the thread. I am guessing that the text you are referring to is back in:
>
> but there has been much discussion since then. Can you restate what you have in mind in light of all that discussion?

I am referring to the text I sent out on Monday (23rd).

http://www.ietf.org/mail-archive/web/mmusic/current/msg14431.html

Regards,

Christer

	Thanks,
	Paul