TURN: Reduce the channel number range?

[Philip Matthews]

In the current version of the TURN spec (TURN-10), channel numbers can  
range from 0x4000 to 0xFFFE, which 0xFFFF reserved for future  
extensions. This gives approx 49000 channels. (There are no channel  
numbers in the range 0x0000 to 0x3FFF to allow ChannelData messages to  
be easily distinguished from other TURN messages).

Cullen recently pointed out to me that 49000 channels is a lot more  
channels that we currently envision a client ever using, and that it  
might be good if we reserved some more of these channel numbers in  
case we need some special channels in the future.

In thinking about Cullen's suggestion, it seems totally impractical to  
me for a client to even use 10,000 channels, let alone 49,000. I am  
proposing the following:
*  0x4000 through 0x7FFF will be used for channel numbers (gives  
14,745 channels)
*  0x8000 through 0xFFFF will be reserved (reserving 32767 numbers for  
the future)
To enforce this, the server would reject ChannelBind requests with a  
CHANNEL-NUMBER value outside of 0x4000 - 0x7FFF

Does it seem a good idea to reserve a significant portion of the  
possible channel number range?
Does my concrete proposal seem sensible, or would a different division  
of the possible channel number space be better?

- Philip
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Rémi Denis-Courmont-7]

On Thursday 09 October 2008 20:28:48 ext Philip Matthews, you wrote:

> In the current version of the TURN spec (TURN-10), channel numbers can
> range from 0x4000 to 0xFFFE, which 0xFFFF reserved for future
> extensions. This gives approx 49000 channels. (There are no channel
> numbers in the range 0x0000 to 0x3FFF to allow ChannelData messages to
> be easily distinguished from other TURN messages).
>
> Cullen recently pointed out to me that 49000 channels is a lot more
> channels that we currently envision a client ever using, and that it
> might be good if we reserved some more of these channel numbers in
> case we need some special channels in the future.
>
> In thinking about Cullen's suggestion, it seems totally impractical to
> me for a client to even use 10,000 channels, let alone 49,000. I am
> proposing the following:
> *  0x4000 through 0x7FFF will be used for channel numbers (gives
> 14,745 channels)
> *  0x8000 through 0xFFFF will be reserved (reserving 32767 numbers for
> the future)
> To enforce this, the server would reject ChannelBind requests with a
> CHANNEL-NUMBER value outside of 0x4000 - 0x7FFF
>
> Does it seem a good idea to reserve a significant portion of the
> possible channel number range?
> Does my concrete proposal seem sensible, or would a different division
> of the possible channel number space be better?

To me, yes.

--
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Philip Matthews]

I now know of four people (Cullen, Dan, Remi, and myself) who support  
this idea and I have heard no objections. So unless I hear a strong  
objection, I will make this change in the next version of TURN (coming  
soon).

- Philip

On Thu, 9-Oct-08, at 13:28 , Philip Matthews wrote:

> In the current version of the TURN spec (TURN-10), channel numbers  
> can range from 0x4000 to 0xFFFE, which 0xFFFF reserved for future  
> extensions. This gives approx 49000 channels. (There are no channel  
> numbers in the range 0x0000 to 0x3FFF to allow ChannelData messages  
> to be easily distinguished from other TURN messages).
>
> Cullen recently pointed out to me that 49000 channels is a lot more  
> channels that we currently envision a client ever using, and that it  
> might be good if we reserved some more of these channel numbers in  
> case we need some special channels in the future.
>
> In thinking about Cullen's suggestion, it seems totally impractical  
> to me for a client to even use 10,000 channels, let alone 49,000. I  
> am proposing the following:
> *  0x4000 through 0x7FFF will be used for channel numbers (gives  
> 14,745 channels)
> *  0x8000 through 0xFFFF will be reserved (reserving 32767 numbers  
> for the future)
> To enforce this, the server would reject ChannelBind requests with a  
> CHANNEL-NUMBER value outside of 0x4000 - 0x7FFF
>
> Does it seem a good idea to reserve a significant portion of the  
> possible channel number range?
> Does my concrete proposal seem sensible, or would a different  
> division of the possible channel number space be better?
>
> - Philip
> _______________________________________________
> Behave mailing list
> Behave@...
> https://www.ietf.org/mailman/listinfo/behave
>

_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Jonathan Rosenberg]

I'm fine with this too.

-Jonathan R.

Philip Matthews wrote:

> I now know of four people (Cullen, Dan, Remi, and myself) who support
> this idea and I have heard no objections. So unless I hear a strong
> objection, I will make this change in the next version of TURN (coming
> soon).
>
> - Philip
>
> On Thu, 9-Oct-08, at 13:28 , Philip Matthews wrote:
>
>> In the current version of the TURN spec (TURN-10), channel numbers can
>> range from 0x4000 to 0xFFFE, which 0xFFFF reserved for future
>> extensions. This gives approx 49000 channels. (There are no channel
>> numbers in the range 0x0000 to 0x3FFF to allow ChannelData messages to
>> be easily distinguished from other TURN messages).
>>
>> Cullen recently pointed out to me that 49000 channels is a lot more
>> channels that we currently envision a client ever using, and that it
>> might be good if we reserved some more of these channel numbers in
>> case we need some special channels in the future.
>>
>> In thinking about Cullen's suggestion, it seems totally impractical to
>> me for a client to even use 10,000 channels, let alone 49,000. I am
>> proposing the following:
>> *  0x4000 through 0x7FFF will be used for channel numbers (gives
>> 14,745 channels)
>> *  0x8000 through 0xFFFF will be reserved (reserving 32767 numbers for
>> the future)
>> To enforce this, the server would reject ChannelBind requests with a
>> CHANNEL-NUMBER value outside of 0x4000 - 0x7FFF
>>
>> Does it seem a good idea to reserve a significant portion of the
>> possible channel number range?
>> Does my concrete proposal seem sensible, or would a different division
>> of the possible channel number space be better?
>>
>> - Philip
>> _______________________________________________
>> Behave mailing list
>> Behave@...
>> https://www.ietf.org/mailman/listinfo/behave
>>
>
> _______________________________________________
> Behave mailing list
> Behave@...
> https://www.ietf.org/mailman/listinfo/behave
>

--
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
jdrosen@...
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave