TURN: Problems with Send request concept

[Philip Matthews]

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
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Philip Matthews]

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



On Thu, 11-Sep-08, at 09:54 , Philip Matthews wrote:

> 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
> Behave@...
> https://www.ietf.org/mailman/listinfo/behave
>

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

[Marc Petit-Huguenin-2]

Philip Matthews wrote:

> 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.
>

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: marc@... [RFC1855-compliant space for rent ]
Work: marc@...            [                                 ]
[                                                               ]
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Philip Matthews]

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



On Fri, 26-Sep-08, at 11:44 , Marc Petit-Huguenin wrote:

>
> 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
>

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

[Marc Petit-Huguenin-2]

Philip Matthews wrote:
> 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.

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.

>
> Does anyone else have any opinion on the two proposals?
>
> - Philip
>
>
>
> On Fri, 26-Sep-08, at 11:44 , Marc Petit-Huguenin wrote:
>
>>
>> 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: marc@... [RFC1855-compliant space for rent ]
Work: marc@...            [                                 ]
[                                                               ]
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Philip Matthews]

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

> Philip Matthews wrote:
>> 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.
>
> 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.

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



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

[Marc Petit-Huguenin-2]

Philip Matthews wrote:

>
> On Fri, 26-Sep-08, at 12:19 , Marc Petit-Huguenin wrote:
>
>> Philip Matthews wrote:
>>> 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.
>>
>> 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.
>
> 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.

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

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

[Philip Matthews]

On Fri, 26-Sep-08, at 13:07 , Marc Petit-Huguenin wrote:
>
> Ok, then I think that only CreatePermission should create/refresh
> permissions.

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


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

[Simon Perreault-3]

Philip Matthews wrote:
> 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?

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
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Richard Aas-2]

Philip Matthews wrote:
> On Fri, 26-Sep-08, at 13:07 , Marc Petit-Huguenin wrote:
>>
>> Ok, then I think that only CreatePermission should create/refresh
>> permissions.
>
> 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.

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

> 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.

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
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Philip Matthews]

Right now, I am seeing a preference on the mailing list and with  
people I have talked with privately to keep the ability for  
CreatePermission to create permission. People like the fact that this  
ability reduced the amount of messages that clients need to send.

I am currently seeing mixed support for making channel lifetimes and  
permission lifetimes equal. Though I agree it makes things a little  
cleaner, it seems to have very little practical impact. Since I am in  
favor of leaving things as they are unless there is strong support to  
change things, I am currently not planning to make this change.

- Philip


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