Subject: [BEHAVE] TURN Issue: How important are channels anyway?

From: Philip Matthews <[email-masked]>
Date: Fri, 4 Jan 2008 22:02:44 -0500

The whole point of the TURN channel mechanism is to provide an  
alternate encapsulation mechanism, one that has about 32 bytes less  
overhead (over IPv4). Is this reduction in overhead important?

Channels certainly add some complexity to TURN: the Framing Header  
and the issues around its Length field and how-to-demux, the  
ChannelBind method, and the yet-to-be-defined mechanism for  
deallocating channels. About half of the issues we have been  
discussing since Vancouver have been about the channel mechanism.

There are a lot of other things out there today that add overhead to  
a packet. Moving to IPv6, for example.  Various tunneling  
technologies inside the network, for another (MPLS, VPNs, IP  
tunnels, ...). So perhaps an extra 32 bytes is not a killer. Or  
perhaps the 32 bytes should be removed using other techniques:  
compression techniques between a handset and its base station, for  
example.

Moreover, with the decision that TURN control messages are NOT  
framed, channels are now cleanly separable from the rest of TURN.  
Channels are very much an extra mechanism. So it would be easy to add  
channels as an extension to TURN.

So the question is: Is removing these 32 bytes important enough to  
add channels to the base TURN specification (with the consequent  
delays to the specification that this will inevitably add), or should  
they be defined as an extension to TURN?

Comments?

- Philip

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 7 Jan 2008 09:41:43 +0200

> discussing since Vancouver have been about the channel mechanism.

On the other hand, fixed size overhead simplifies lots of things. For 
instance, programmers can use scatter-gather buffer arrays on the receive 
path, which help avoid extra memory-copying. It also avoids the need for even 
more intricate demultiplexing (remember how older TURN spec used Send and 
Data indication...).

> compression techniques between a handset and its base station, for

I would rather add 32 bits *always* than add lots bytes of sometimes
=> pseudo-random looking failures.

-- 
Rémi Denis-Courmont

---

From: "Kevin Johns" <[email-masked]>
Date: Mon, 7 Jan 2008 22:53:32 -0700

I tend to agree that while channel numbers complicate TURN, they do provide simplification in other areas. In addition to Remi's points, they also make network resource allocation a bit easier since you don't have to figure out which flow has the single active destination vs. all the others which don't and thus require additional overhead.

Kevin 

-----Original Message-----
From: Rémi Denis-Courmont [mailto:[email-masked]] 
Sent: Monday, January 07, 2008 12:42 AM
To: [email-masked]
Subject: Re: [BEHAVE] TURN Issue: How important are channels anyway?

Le Saturday 05 January 2008 05:02:44 ext Philip Matthews, vous avez écrit :
> Channels certainly add some complexity to TURN: the Framing Header and 
> the issues around its Length field and how-to-demux, the ChannelBind 
> method, and the yet-to-be-defined mechanism for deallocating channels. 
> About half of the issues we have been discussing since Vancouver have 
> been about the channel mechanism.

On the other hand, fixed size overhead simplifies lots of things. For instance, programmers can use scatter-gather buffer arrays on the receive path, which help avoid extra memory-copying. It also avoids the need for even more intricate demultiplexing (remember how older TURN spec used Send and Data indication...).

> There are a lot of other things out there today that add overhead to a 
> packet. Moving to IPv6, for example.  Various tunneling technologies 
> inside the network, for another (MPLS, VPNs, IP tunnels, ...). So 
> perhaps an extra 32 bytes is not a killer. Or perhaps the 32 bytes 
> should be removed using other techniques:

I would rather add 32 bits *always* than add lots bytes of sometimes => pseudo-random looking failures.

--
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Tue, 8 Jan 2008 03:57:06 -0500

> more intricate demultiplexing (remember how older TURN spec used  

In general, always using Send/Data indications also gives a fixed- 
size overhead:
    STUN header                 20 bytes
    PEER-ADDRESS attribute      12 bytes (for IPv4)
    DATA attribute              4  bytes + size of application data +  
0-3 bytes of padding

However, it is true that TURN currently allows clients and servers to  
add extra attributes to these indications if they wish, nor does TURN  
currently specify the order of the PEER-ADDRESS vs DATA attribute.

- Philip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 8 Jan 2008 12:24:50 +0200

>     DATA attribute              4  bytes + size of application data +

Overhead is always fixed, or it is not fixed. There is no such thing 
as "generally fixed" in that sense. Send/Data overhead is NOT fixed, because 
data from the active destination is not wrapped while data from other 
destination is.

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Tue, 8 Jan 2008 19:50:25 -0500

> data from the active destination is not wrapped while data from other

There is no longer a "Set Active Destination" concept in TURN. It was  
removed in TURN-05.

I was thinking about this some more, and now believe that an  
implementation could easily detect the very common case where a Send  
or Data indication is formatted as shown above. A few quick tests are  
sufficient to confirm this. When the Send or Data indication is  
formatted this way, it can be processed efficiently, and if the tests  
fail, then the general STUN parsing code can be invoked.

So I think the question really come down to the NUMBER of bytes of  
overhead present. It is certainly true that Send and Data indications  
require more bytes. Is this really important.

- Philip

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Jan 2008 20:51:59 -0800

For the specific case of RTP over TURN, I think this is a requirement  
question better asked in AVT. There has been significant discussion  
of packet overhead when we came to the consensus that a new security  
protocol (SRTP) was needed instead of using RTP over an existing  
protocol such at TLS or IPSEC. I would encourage people to review how  
long that conversation went on last time we had it.

On Jan 4, 2008, at 7:02 PM, Philip Matthews wrote:

> There are a lot of other things out there today that add overhead  
> to a packet. Moving to IPv6, for example.  Various tunneling  
> Channels are very much an extra mechanism. So it would be easy to  
> add channels as an extension to TURN.
>
> delays to the specification that this will inevitably add), or  
> should they be defined as an extension to TURN?
>
> Comments?
>
> - Philip
>
>
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Jan 2008 12:13:18 -0500

Sorry for popping in late here...

 From the very, very beginning, it has been a requirement of TURN to 
support a very low overhead encapsulation since RTP and voip in 
particular has been its primary usage. I haven't seen anything that 
indicates these requirements have changed. Efficiency of RTP has been 
and continues to be an issue, driving work like SRTP (as Cullen 
mentioned) and ROHC.

I don't see any reason to revisit this design decision and think we 
should continue our current course of providing a low-overhead 
encapsulation.

-Jonathan R.

Cullen Jennings wrote:
> question better asked in AVT. There has been significant discussion of 
> packet overhead when we came to the consensus that a new security 
>> should be removed using other techniques: compression techniques 
>> between a handset and its base station, for example.
>>
>> Moreover, with the decision that TURN control messages are NOT framed, 
>> channels are now cleanly separable from the rest of TURN. Channels are 
>> very much an extra mechanism. So it would be easy to add channels as 
>> an extension to TURN.
>>
>> So the question is: Is removing these 32 bytes important enough to add 
>> channels to the base TURN specification (with the consequent delays to 
>> the specification that this will inevitably add), or should they be 
>> defined as an extension to TURN?
>>
>> Comments?
>>
>> - Philip
>>
>>
>>
>>

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Philip Matthews <[email-masked]>
Date: Fri, 18 Jan 2008 10:55:09 -0500

It seems that everyone still wants the channel mechanism, despite the  
difficulties we are having in resolving the open issues around it.

So the channel mechanism will be in TURN-06 (coming soon!). However,  
as noted below, the changes that we have agreed to have made in a non- 
core mechanism, so it is now presented after the other, more basic,  
parts of TURN.

- Philip

On 15-Jan-08, at 12:13 , Jonathan Rosenberg wrote:

> indicates these requirements have changed. Efficiency of RTP has  
> been and continues to be an issue, driving work like SRTP (as  
> Cullen mentioned) and ROHC.
>
>> For the specific case of RTP over TURN, I think this is a  
>> requirement question better asked in AVT. There has been  
>> significant discussion of packet overhead when we came to the  
>> consensus that a new security protocol (SRTP) was needed instead  
>> of using RTP over an existing protocol such at TLS or IPSEC. I  
>> would encourage people to review how long that conversation went  
>> on last time we had it.
>>> alternate encapsulation mechanism, one that has about 32 bytes  
>>> less overhead (over IPv4). Is this reduction in overhead important?
>>>
>>> Channels certainly add some complexity to TURN: the Framing  
>>> Header and the issues around its Length field and how-to-demux,  
>>> the ChannelBind method, and the yet-to-be-defined mechanism for  
>>> compression techniques between a handset and its base station,  
>>> for example.
>>>
>>> So the question is: Is removing these 32 bytes important enough  
>>> to add channels to the base TURN specification (with the  
>>> consequent delays to the specification that this will inevitably  
>>> add), or should they be defined as an extension to TURN?
>>>
>>> Comments?
>>>
>>> - Philip
>>>
>>>
>>>
>>>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 21 Jan 2008 09:30:47 -0800

On Jan 18, 2008, at 7:55 AM, Philip Matthews wrote:

> It seems that everyone still wants the channel mechanism, despite  
> the difficulties we are having in resolving the open issues around it.
>
> as noted below, the changes that we have agreed to have made in a  
> non-core mechanism, so it is now presented after the other, more  
> basic, parts of TURN.
>
> - Philip

What does "non core" mean?  If this means "optional" then I sure  
missed the part were we came to agreement about it.

---

From: Philip Matthews <[email-masked]>
Date: Mon, 21 Jan 2008 15:37:27 -0500

On 21-Jan-08, at 12:30 , Cullen Jennings wrote:

>> So the channel mechanism will be in TURN-06 (coming soon!).  
>> However, as noted below, the changes that we have agreed to have  
>> made in a non-core mechanism, so it is now presented after the  
>> other, more basic, parts of TURN.
>>
>> - Philip
>

"Non-core" means that channels are supplemental; they provide a  
second encapsulation scheme.

Send and Data indications are the primary scheme. They are primary  
because there are situations where Send and Data indications must be  
used. Channels, on the other handle, do not have to be used.

As for "optional", TURN-06 never uses this term, but in a sense  
channels are optional. How? Note that, over UDP transport, a client  
MUST always wait for a success response to a ChannelBind Request  
before using the channel (since the ChannelBind Request might get  
lost). So any robust client would work as follows:
    if Data to send to remote peer
    	If channel exists to remote peer then
		Form and send a ChannelData message
    	else
		Form and send a Send Indication
So if the server always replies with an error response to any  
ChannelBind requests (or just silently ignores them), then everything  
would continue to work, albeit without any channels.

To repeat, TURN-06 _does not_ use the word "optional" or even  
"supplemental". It just introduces channels as an "alternative"  
encapsulation scheme.

- Philip

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 21 Jan 2008 12:46:20 -0800

ok, thanks - I'll stop bugging you and let you get the draft done :-)

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 Jan 2008 12:58:58 -0800

At Mon, 21 Jan 2008 15:37:27 -0500,
> "supplemental". It just introduces channels as an "alternative"  

True, but it seems that the spec needs to read that servers MUST
implement and serve ChannelBind requests. I.e., it's not OK to
write a server which just refules all channel binding and call
it TURN.

-Ekr

---

From: Philip Matthews <[email-masked]>
Date: Mon, 21 Jan 2008 16:05:28 -0500

> write a server which just refules all channel binding and call

We can do that, but I also think that clients MUST be able to handle  
the server rejecting the ChannelBind Request. A server might do that  
for perfectly valid reasons (e.g., out of resources).

- Philip

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 Jan 2008 13:21:49 -0800

At Mon, 21 Jan 2008 16:05:28 -0500,
> for perfectly valid reasons (e.g., out of resources).

I was going to say I totally agree, but really, what resource would
you run out of here? I mean, the channel is just this a small memory
structure, right? If the TURN server gets that low on memory, it's
going to crash shortly anyway, so it's not clear to me that this is
really that legitimate a case.

That said, I think that a TURN client needs to be able to handle the
server rejecting the ChannelBind in that it doesn't crash or reformat
your hard drive, but it's reasonable for the client to handle that by
closing the connection entirely, since any TURN server which won't do
this is basically broken.

-Ekr

---

From: Philip Matthews <[email-masked]>
Date: Mon, 21 Jan 2008 22:20:23 -0500

> this is basically broken.

Maybe.

But I could easily imagine an implementation which, on startup,  
allocated space for a fixed number of channel bindings and handed  
them out to various allocations on demand, keeping a free list of  
those not currently in use. The application would only get memory on  
startup and would not do any more mallocs after that. When channel  
binding entries ran out, the ChannelBind request would fail, but the  
application would be totally robust because the next time an  
allocation expired it would free up some channel binding entries for  
re-use.

Most of the embedded products that I am most familiar with and been  
heavily involved in coding work this way.

- Philip

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 Jan 2008 20:02:42 -0800

At Mon, 21 Jan 2008 22:20:23 -0500,
> heavily involved in coding work this way.

As Randy Bush is fond of saying: I encourage my competitors to design
their systems this way.

-Ekr

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 22 Jan 2008 12:53:20 -0500

Options adds to complexity.

Implementation of the channel mechanism is not optional for servers. Its 
mandatory. Clients can use it or not, at their discretion.

A server should never reject a ChannelBind message because of lack of 
implementation or lack of memory or whatever, and CERTAINLY we should 
not require clients to handle these cases. If a broken server wants to 
reject a ChannelBind with a 400 because its out of memory, so be it, but 
we don't need to say anything about that in the spec.

-Jonathan R.

Philip Matthews wrote:
> allocated space for a fixed number of channel bindings and handed them 
> out to various allocations on demand, keeping a free list of those not 
> currently in use. The application would only get memory on startup and 
> would not do any more mallocs after that. When channel binding entries 
> ran out, the ChannelBind request would fail, but the application would 
> be totally robust because the next time an allocation expired it would 
> free up some channel binding entries for re-use.
>

---

From: Philip Matthews <[email-masked]>
Date: Tue, 22 Jan 2008 14:37:29 -0500

The spec currently says:
    Over UDP, the client SHOULD NOT send ChannelData messages on the
    channel until it has received a ChannelBind Success Response for the
    binding attempt.  Sending them before the success response is
    received risks having them dropped by the server if he ChannelBind
    Request was lost.

In my opinion, the same should apply for ChannelBind over TCP, since  
the server might reject. It may be unlikely, but it could still happen.

And I still claim that a robust client will do what I suggested earlier:
    If data to send then
       If have a channel to destination peer then
           Send ChannelData message
       else
           Send a "Send" indication

- Philip

On 22-Jan-08, at 12:53 , Jonathan Rosenberg wrote:

> Implementation of the channel mechanism is not optional for  
> servers. Its mandatory. Clients can use it or not, at their  
> discretion.
>
> A server should never reject a ChannelBind message because of lack  
> of implementation or lack of memory or whatever, and CERTAINLY we  
> should not require clients to handle these cases. If a broken  
> server wants to reject a ChannelBind with a 400 because its out of  
> memory, so be it, but we don't need to say anything about that in  
> the spec.
>
> -Jonathan R.
>
> Philip Matthews wrote:
>> those not currently in use. The application would only get memory  
>> on startup and would not do any more mallocs after that. When  
>> channel binding entries ran out, the ChannelBind request would  
>> fail, but the application would be totally robust because the next  
>> time an allocation expired it would free up some channel binding  
>> entries for re-use.
>> Most of the embedded products that I am most familiar with and  
>> been heavily involved in coding work this way.
>> - Philip

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Jan 2008 11:47:27 -0800

At Tue, 22 Jan 2008 14:37:29 -0500,
>     received risks having them dropped by the server if he ChannelBind

I actually think this is wrong.

In the vast majority of cases the ChannelBind will work (if this
isn't true your network is likely unusably hosed). Since
the consequences of sending ChannelData prior to a ChannelBind
success is purely that the ChannelData gets dropped, this isn't
an interop issue and it should be up to the client what it
wants to do.

The spec should simply describe the possible cases and be
silent on recommendations.

> the server might reject.

I definitely think this is wrong. First, as I argued above, it's
up to the client how he wants to balance these risks. Second,
if the server rejects, the client may well want to simply drop 
the connection, in which case it's hard to see why it shouldn't
it be optimistic?

-Ekr

---

From: Philip Matthews <[email-masked]>
Date: Tue, 22 Jan 2008 15:31:23 -0500

Eric:

If I understand your proposal correctly, you would like to see the  
document list the consequences of sending a ChannelData message  
before receiving a ChannelBind success response,  where the two  
consequences are: (1) over UDP, the ChannelBind request might be  
lost, and (2) over any transport, the server might reject the  
ChannelBind request.  The document would then say "the client MAY  
send in this situation".

I believe you think that (2) is possible, but think it is very  
unlikely. I personally think the chances are a bit higher. But I  
would suggest we just be silent about probabilities.

I am happy with this change. As you point out, letting clients send  
or not in this case does not break interoperability or have bad  
network side-effects. The only side-effect is possible lost packets.

Any comments from anyone else?

- Philip

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Jan 2008 22:28:18 -0500

I agree with what Ekr is saying.

And I think the probability of rejecting CHannelBind is low - really 
low. I don't buy this argument about running out of memory or some other 
such thing.

-Jonathan R.

Philip Matthews wrote:
> document list the consequences of sending a ChannelData message before 
> receiving a ChannelBind success response,  where the two consequences 
> are: (1) over UDP, the ChannelBind request might be lost, and (2) over 
> any transport, the server might reject the ChannelBind request.  The 
> document would then say "the client MAY send in this situation".
> 
> I believe you think that (2) is possible, but think it is very unlikely. 
> I personally think the chances are a bit higher. But I would suggest we 
> just be silent about probabilities.
> 
> I am happy with this change. As you point out, letting clients send or 
> not in this case does not break interoperability or have bad network 
> side-effects. The only side-effect is possible lost packets.
>