Subject: [BEHAVE] TURN: Problems with Send request concept

From: Philip Matthews <[email-masked]>
Date: Thu, 11 Sep 2008 09:54:39 -0400

Jonathan and I have been talking about the Send request concept that  
was agreed to in Dublin. As you may recall, in TURN-09 permissions are  
added or refreshed by Send indications and ChannelData messages, but a  
concern was raised that these messages are not authenticated. To  
address this concern, we agreed in Dublin to remove the permission  
install/refresh semantics from these messages, and limit permission  
install/refresh to ChannelBind requests and to a proposed new Send  
request (since requests can be authenticated, while indications and  
ChannelData messages cannot).

The proposed Send request would be very similar to the Send indication  
of TURN-09. It would carry a PEER-ADDRESS attribute and optionally a  
DATA attribute. It would install or refresh a permission, and if the  
DATA attribute was included, it would also send the data toward the  
indicated peer.

In working out the details for the proposed Send request message, we  
have come across two problems:

Problem 1: Over UDP, requests can be retransmitted if no success  
response is received within a certain time. For Send requests, if  
nothing special is done, this would result in multiple copies of the  
data being sent to the peer. There are two ways to handle this:
a) Allow this, and say that Send requests cannot be used if the  
application cannot handle this. For example, if the data is ICE  
connectivity checks, then retransmissions are not a problem.
b) Prevent this by requiring the server to remember transaction ids of  
recent Send requests and suppress the retransmission.

Some people want to build TURN servers that handle retransmissions in  
the STUN stack (before doing TURN-specific processing) and would thus  
implement option (b). However, this might result in remembering lots  
of transaction ids, since a client could send lots of Send requests.   
Other people want to build TURN servers that handle retransmissions in  
the TURN-specific code and would thus prefer option (a).

Problem 2: One of the reasons that a Send request was proposed in the  
first place was to allow the Send request to both refresh the  
permission and to carry an ICE Binding request. However, this leads to  
two STUN state machines stacked on top of each other: a lower one for  
the Send request, and an upper one for the ICE Binding request. If the  
Send request is lost, then both state machines will want to retransmit  
(at about the same time). Exactly what happens at this point depends  
on how the implementation is done; in the worst case, the  
retransmitted ICE Binding request would create a second Send request  
state machine to send what TURN thinks is new data.

After thinking about these two problems, Jonathan and I are proposing  
to replace the Send request with a CreatePermission request instead.  
This new request would take only a PEER-ADDRESS attribute and would  
only establish or refresh a permission; it would not send any data.  
The other details of the proposed change remains the same: Send  
indications and ChannelData messages would not affect permissions, and  
permissions would be installed/refreshed using CreatePermission and  
ChannelBind requests only. This CreatePermission request would avoid  
these two problems, at the cost of sending an additional message every  
5 minutes or so to refresh the server permission.

A TURN client could do one of two things when receiving data to send  
to a peer (if not using channels):
a) The client could send a CreatePermission request (if one has not  
already been send) and then queue the data until the CreatePermission  
success response is received, OR
b) The client could send a CreatePermission request (if one has not  
already been send) and then immediately send a Send request containing  
the data.
The latter approach is quite appropriate if the client believes the  
application can easily handle lost data in the peer-to-client  
direction. For example, approach (b) is quite suitable if TURN is  
being used with ICE.
A similar choice exists if the client uses channels instead: the  
client can either queue data until the ChannelBind success response is  
received, or just go ahead and send and ChannelData message.

If there are no objections to this approach, then TURN-10 will contain  
a CreatePermission request rather than a Send request.

- Philip

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

---

From: Philip Matthews <[email-masked]>
Date: Fri, 26 Sep 2008 10:54:55 -0400

This proposed change has an interaction with the SET-DF feature (now  
called the DONT-FRAGMENT feature).

As previously discussed on the mailing list, the DONT-FRAGMENT feature  
allows a client to request that the server set the DF bit when sending  
the UDP datagram to the peer. The client does this by including the  
DONT-FRAGMENT attribute in the Send indication. Some servers might not  
be able to support this feature because they are unable to set the DF  
bit on outgoing packets. To allow the client to determine whether the  
server supported this feature or not, we had previous agreed that the  
client would include the attribute in a Send request, and the Send  
request would then fail if the feature was not supported.

However, this way of detecting support for DONT-FRAGMENT doesn't work  
if we remove Send requests are proposed below.

So the proposal is to now allow the client to include the DONT- 
FRAGMENT attribute in an Allocate request. Servers that support the  
feature accept this attribute without comment. Servers that do not  
support this feature treat the attribute as an unknown comprehension- 
required attribute, and thus reject the request with a 420 (Unknown  
Attributes) error and include the attribute number in the UNKNOWN- 
ATTRIBUTES attribute of the response.

This alternative way of detecting support seems to be easy to  
implement on both the TURN client and server.

Unless there are objections, the next version of TURN will use this  
method to detect support for DONT-FRAGMENT.

- Philip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 26 Sep 2008 08:44:23 -0700

> a CreatePermission request rather than a Send request.

I would like to propose a slightly simpler alternative.  Instead of
creating a new CreatePermission transaction, I propose to use the
ChannelBind transaction without CHANNEL-NUMBER attribute to indicate
that the permission for the IP address in the PEER-ADDRESS must be
created or refreshed.  With your proposal, we have this sequence:

CreatePermission (create permission)
Send
Send
CreatePermission (refresh permission)
Send
ChannelBind (create channel and refresh permission)
ChannelData
ChannelData
ChannelBind (refresh channel binding and permission)
ChannelData
ChannelData

This sequence becomes this with my proposal:

ChannelBind (without channel, create permission)
Send
Send
ChannelBind (without channel, refresh permission)
Send
ChannelBind (create channel and refresh permission)
ChannelData
ChannelData
ChannelBind (refresh channel binding and permission)
ChannelData
ChannelData

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Fri, 26 Sep 2008 12:05:50 -0400

Hmmm. Speaking personally, my initial reaction to this proposal is  
negative because it further blurs the distinction between channels and  
permissions, something that I personally dislike. In fact, Jonathan  
and I discussed going in the opposite direction and removing the  
ability of ChannelBind to update permissions: have ChannelBind deal  
only with channels and CreatePermission deal only with permission. We  
decided against proposing this only because, though architecturally  
purer, there seems to be no real value in it.

Does anyone else have any opinion on the two proposals?

- Philip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 26 Sep 2008 09:19:36 -0700

Philip Matthews wrote:
> permissions, something that I personally dislike. In fact, Jonathan and
> I discussed going in the opposite direction and removing the ability of
> ChannelBind to update permissions: have ChannelBind deal only with
> channels and CreatePermission deal only with permission. We decided
> against proposing this only because, though architecturally purer, there
> seems to be no real value in it.

Well, I personally do not see the point of having  different refresh
cycles for permission and channels, hence my proposal, but I could have
miss something, in which case I certainly would advocate to completely
separate the two.

---

From: Philip Matthews <[email-masked]>
Date: Fri, 26 Sep 2008 12:58:28 -0400

On Fri, 26-Sep-08, at 12:19 , Marc Petit-Huguenin wrote:

>> and

The details for how channels become unbound were worked out in the  
TURN conference call of 7 Feb 2008. At that time, there was a vague  
feeling that having permissions and channels expire at the same time  
was a bad idea and would lead to race conditions. Hence I picked a 10- 
minute lifetime for channels, in contrast to the 5-minute lifetime for  
permissions. See:

   http://www.ietf.org/mail-archive/web/behave/current/msg03289.html

I am not sure I still agree with this vague feeling, but until now no  
one has really questioned it.

Though it might be cleaner to have the same lifetime for both channels  
and permissions, I don't see any concrete advantage to this change,  
and I am resisting changes that do not add value.

- Philip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 26 Sep 2008 10:07:36 -0700

Philip Matthews wrote:
> The details for how channels become unbound were worked out in the TURN
> conference call of 7 Feb 2008. At that time, there was a vague feeling
> that having permissions and channels expire at the same time was a bad
> idea and would lead to race conditions. Hence I picked a 10-minute
> lifetime for channels, in contrast to the 5-minute lifetime for
> permissions. See:
> 
> and permissions, I don't see any concrete advantage to this change, and
> I am resisting changes that do not add value.

Ok, then I think that only CreatePermission should create/refresh
permissions.

---

From: Philip Matthews <[email-masked]>
Date: Fri, 26 Sep 2008 14:26:34 -0400

> Ok, then I think that only CreatePermission should create/refresh

Jonathan and I discussed this idea today. I am mildly in favor this  
because I think it makes things cleaner. However, Jonathan is against  
it because it means that a client using channels has to periodically  
send both CreatePermission requests and ChannelBind requests.

What are your reasons for wanting this change?

The one argument I came up with is the following:
With the current proposals, a client using Send indications can send  
data without installing a permission, while a client using channels  
cannot. Removing the ability for ChannelBind to update permissions  
would allow a client using channels to send without installing  
permissions. However, we could see no reason why a client would not  
want to install a permission, so  we judged this argument to be very  
weak.

Does anyone else have an opinion on this?

- Philip

---

From: Simon Perreault <[email-masked]>
Date: Sat, 27 Sep 2008 16:33:42 -0400

Philip Matthews wrote:
> cannot. Removing the ability for ChannelBind to update permissions would 
> allow a client using channels to send without installing permissions. 
> However, we could see no reason why a client would not want to install a 
> permission, so  we judged this argument to be very weak.
> 

I do have an opinion.

The point of channels is optimization. Therefore it makes sense as an 
additional optimization to coalesce the CreatePermission request into 
the ChannelBind request.

However I would argue against repurposing ChannelBind as a way of 
creating permissions when not using channels. It doesn't save bytes on 
the wire, just words in the RFC. It's a bad idea.

To summarize:
- Have CreatePermission method as previously discussed.
- Make the channel's permission tied to the channel lifetime.

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Richard Aas <[email-masked]>
Date: Mon, 29 Sep 2008 09:56:57 +0200

Philip Matthews wrote:
> because I think it makes things cleaner. However, Jonathan is against it 
> because it means that a client using channels has to periodically send 
> both CreatePermission requests and ChannelBind requests.

I support Jonathan in his argument above. For the same reason I would
also advocate to align channel and permission lifetimes.

> permission, so  we judged this argument to be very weak.

A client that doesn't want to receive data can always ignore it. As noted
above, I think having ChannelBind requests create/refresh permissions adds
value/simplicity in real work scenarios.

	Richard