Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sctp-sdp-08 - Paul's comments - default SCTP port

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Dec 2014 10:00:07 +0000

Hi,

>>>>> Section 5.1:
>>>>>
>>>>> IMO 5000 is a bad choice for the default port value. It falls in 
>>>>> the middle of the registered port list. It isn't currently 
>>>>> registered (I don't know why) but it potentially could. I suggest 
>>>>> that a number outside of the registered port range
>>>>> (>49151) would be safest. To avoid being arbitrary, I suggest 65535 - the largest possible 16 bit number.
>>>>
>>>> I have no problem to change the default value.
>>>>
>>>> However, 5000 was defined before I got involved with the draft, so I think it would be good to get some input from Gonzalo and/or Salvatore whether there was some specific reason for 5000.
>>>>
>>>> -------------
>>>
>>> 5000 is the default value the current/available SCTP over TLS are using.
>>
>> just to clarify
>> what I meant is that 5000 is the value that as far as I know Firefox 
>> is using in its SCTP over TLS data channel implementation
>
> AFAIK it is being explicitly specified as 5000, not that there is reliance on a default value of 5000. Changing the default only affects those implementations depending on the default.
>
> Also, if those implementations are using different SDP syntax, not conformant with this version of the draft, then they will need to be changed anyway before this change becomes effective.

Another option is to not define a default port to begin with, and mandate the usage of the sctp-port attribute.

Because, assume you would have two SCTP associations (described using different m- lines), both without an sctp-port attribute. You would use the same SCTP port for both SCTP associations...

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Dec 2014 09:51:44 -0500

> Because, assume you would have two SCTP associations (described using different m- lines), both without an sctp-port attribute. You would use the same SCTP port for both SCTP associations...

Remember - multiple SCTP associations, especially bundled ones, is 
likely to be a very rare occurrence. The normal case, especially in a 
bundle, will be for a single one. In that case the sctp port is 
irrelevant. So, optimizing for the common case by having a default will 
be one less thing that most people won't have to think about.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Dec 2014 07:42:16 +0000

Hi,

> Remember - multiple SCTP associations, especially bundled ones, is likely to be a very rare occurrence. The normal case, especially in a bundle, will be for a single one. In that 
> case the sctp port is irrelevant. So, optimizing for the common case by having a default will be one less thing that most people won't have to think about.

People have to think about it anyway - the question is whether they always will have to signal it in SDP :)

Personally I don't have any strong opinion - if people want a default port value I am happy to add it to the draft. Just gimme a numbah :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Dec 2014 12:09:33 -0500

> Personally I don't have any strong opinion - if people want a default port value I am happy to add it to the draft. Just gimme a numbah :)

Most people won't need to think about it at all.

	Thanks,
	Paul

---

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 4 Dec 2014 17:31:40 -0800

On Dec 3, 2014, at 6:51 AM, Paul Kyzivat <[email-masked]> wrote:

> Remember - multiple SCTP associations, especially bundled ones, is likely to be a very rare occurrence.

We shouldn't have a default port number for SCTP; this re-invents the mistakes of "RTCP = RTP port + 1" that necessitated the late standardization of a=rtcp which is *still* not reliably signaled by SIP endpoints (fortunately WebRTC is requiring it, I believe).  A fixed port number doesn't work with NAPT, A+P, or all the other stuff that mucks with port numbers.   Yes, I know SCTP dreams of NAPTs that don't rewrite ports, but even that dream doesn't work well if everything is trying to use the same port number.

I propose eliminating the sentence:
  "If the SDP sctp-port attribute is not present, the default value is
   5000."
and require signaling the SCTP port number.

-d

> The normal case, especially in a bundle, will be for a single one. In that case the sctp port is irrelevant. So, optimizing for the common case by having a default will be one less thing that most people won't have to think about.
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Dec 2014 10:33:15 -0500

Dan,

> We shouldn't have a default port number for SCTP; this re-invents the mistakes of "RTCP = RTP port + 1" that necessitated the late standardization of a=rtcp which is *still* not reliably signaled b…

Remember, this is only for the case where SCTP is being carried over 
another transport that has a port number.

And this isn't analogous to RTCP. In that case there are two independent 
streams. That isn't the case here.

And for those cases where multiple SCTP ports are needed, defining the 
attribute from the start means there aren't the backward compatibility 
issues that there were for a=rtcp.

	Thanks,
	Paul

---

From: 🔓Dan Wing <[email-masked]>
Date: Fri, 5 Dec 2014 09:17:53 -0800

On Dec 5, 2014, at 7:33 AM, Paul Kyzivat <[email-masked]> wrote:

> Remember, this is only for the case where SCTP is being carried over another transport that has a port number.

I had missed that.

I do agree IANA registration of the port seems a good idea.

-d

> 
> And this isn't analogous to RTCP. In that case there are two independent streams. That isn't the case here.
> 
> And for those cases where multiple SCTP ports are needed, defining the attribute from the start means there aren't the backward compatibility issues that there were for a=rtcp.
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Dec 2014 12:53:46 -0500

> I do agree IANA registration of the port seems a good idea.

The current default (5000) is a currently unassigned value in the range 
reserved for (registered) user ports. That seems wrong. I am proposing 
to use a number (65535) from the dynamic port number range as the default.

I agree that another possibility would be to register a port for the 
purpose. (Potentially this port could be in the system ports range. The 
restriction on use of system ports doesn't apply when the protocol is 
implemented in application space over another transport.)

I just find it a little easier to go with a dynamic port.

	Thanks
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 8 Dec 2014 12:48:55 +0000

Hi,

I doubt it is within the scope of this document to register a dedicated SCTP port with IANA...

But, the question is still whether we, for SDP Offer/Answer usage, want to define a default value for the SDP 'sctp-port' attribute, or whether we mandate it to always be present for 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 5. joulukuuta 2014 19:54
To: 🔓Dan Wing
Cc: Christer Holmberg; Salvatore Loreto; [email-masked]
Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sctp-sdp-08 - Paul's comments - default SCTP port

On 12/5/14 12:17 PM, 🔓Dan Wing wrote:
>>>>>>>>>> IMO 5000 is a bad choice for the default port value. It falls 
>>>>>>>>>> in the middle of the registered port list. It isn't currently 
>>>>>>>>>> registered (I don't know why) but it potentially could. I 
>>>>>>>>>> suggest that a number outside of the registered port range
>>>>>>> what I meant is that 5000 is the value that as far as I know 
>>>>>>> Firefox is using in its SCTP over TLS data channel 
>>>>>>> implementation
>>>>>>

The current default (5000) is a currently unassigned value in the range reserved for (registered) user ports. That seems wrong. I am proposing to use a number (65535) from the dynamic port number range as the default.

I agree that another possibility would be to register a port for the purpose. (Potentially this port could be in the system ports range. The restriction on use of system ports doesn't apply when the protocol is implemented in application space over another transport.)

	Thanks
	Paul