TURN: Handling retransmitted requests

[Philip Matthews]

On Fri, 22-Aug-08, at 14:10 , Benny Prijono wrote:

> - I think the Note in Section 6.2 (page 20/21) about server  
> remembering last error response is not necessary. The rfc3489bis-18  
> already says that server SHOULD retransmit last error response. And  
> in fact the text in that Note that says:
>
>  "Server implementors MAY elect to prevent this second case by
>   remembering recent failure responses and returning the saved
>   failure response when receiving a retransmitted Allocate request."
>
>  contradicts the SHOULD requirement in rfc3489bis-18, thus should be  
> deleted IMO.

Jonathan and I have been discussing the issue of retransmitted  
requests over UDP in TURN. Some people want to handle this in the STUN  
stack (before doing TURN-specific processing), by remembering  
transaction ids and the corresponding responses for 40 seconds. Other  
people want to handle this in the TURN-specific processing (the so-
called "stateless stack" approach).

We are trying to make sure that the TURN spec supports both  
approaches. To do this, TURN-10 will contain a paragraph in the  
General Behavior section that talks about the issue and mentions the  
two approaches. At that point, nothing more needs to be said about the  
approach of handling it in the TURN stack, but the description of each  
request will contain a note on how the "stateless stack" approach can  
be implemented for that request.

For an Allocate request, the note will say:
<t>NOTE: Implementations may implement the idempotency of the Allocate  
request over UDP using the so-called "stateless stack approach" as  
follows. To detect retransmissions when the original request was  
successful in creating an allocation, the server can store the  
transaction id that created the request with the allocation data and  
compare it with incoming Allocate requests on the same 5-tuple. Once  
such a request is detected, the server can stop parsing the request  
and immediately generate a success response. When building this  
response, the value of the LIFETIME attribute can be taken from the  
time-to-expiry field in the allocate state data, even though this  
value may differ slightly from the LIFETIME value originally returned.  
In addition, the server may need to store an indication of any  
reservation token returned in the original response, so that this may  
be returned in any retransmitted responses.</t>
<t>For the case where the original request was unsuccessful in  
creating an allocation, the server may choose to do nothing special.  
Note, however, that there is a rare case where the server rejects the  
original request but accepts the retransmitted request (because  
conditions have changed in the brief intervening time period). If the  
client receives the first failure response, it will ignore the second  
(success) response and believe that an allocation was not created. An  
allocation created in this matter will eventually timeout, since the  
client will not refresh it. Furthermore, if the client later retries  
with the same 5-tuple but different transaction id, it will receive a  
437 (Allocation Mismatch), which will cause it to retry with a  
different 5-tuple. The server may use a smaller maximum lifetime value  
to minimize the lifetime of allocations "orphaned" in this manner.</t>

For a Refresh request, there is a small issue of a retransmitted  
Refresh request with a 0 lifetime value. If the first transmission  
deletes the allocation, then the retransmission will fail with a 437  
(Allocation Mismatch) error, since there is no longer any allocation.  
To handle this case, we have added a sentence saying that the client  
should consider a 437 response as "success" (since the allocation is  
gone).

For a ChannelBind request, there is normally no problem, however there  
is a small issue if the client tries to rebind the channel number at  
the 10 minute mark. In this case, the first ChannelBind might fail  
(because the channel number is still bound), but the retransmission  
might succeed (because the channel number has become unbound in the  
meantime). To fix this problem, the text will say that the client  
should wait 15 minutes before trying to reuse either the channel  
number or the peer address in a new binding, and should consider a  
ChannelBind failure response as an indication that the client and  
server are now out-of-sync and should thus abandon the allocation.

For a Send request, see my separate e-mail.


Comments?

- Philip


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

[Magnus Westerlund]

Hi,

I like to comment that I find it problematic that no one has commented
on these proposals. Maybe we should kill TURN there clearly doesn't seem
to be enough interest in completing this high importance WG item.

Irritated AD



Philip Matthews skrev:

> On Fri, 22-Aug-08, at 14:10 , Benny Prijono wrote:
>> - I think the Note in Section 6.2 (page 20/21) about server  
>> remembering last error response is not necessary. The rfc3489bis-18  
>> already says that server SHOULD retransmit last error response. And  
>> in fact the text in that Note that says:
>>
>>  "Server implementors MAY elect to prevent this second case by
>>   remembering recent failure responses and returning the saved
>>   failure response when receiving a retransmitted Allocate request."
>>
>>  contradicts the SHOULD requirement in rfc3489bis-18, thus should be  
>> deleted IMO.
>
>
> Jonathan and I have been discussing the issue of retransmitted  
> requests over UDP in TURN. Some people want to handle this in the STUN  
> stack (before doing TURN-specific processing), by remembering  
> transaction ids and the corresponding responses for 40 seconds. Other  
> people want to handle this in the TURN-specific processing (the so-
> called "stateless stack" approach).
>
> We are trying to make sure that the TURN spec supports both  
> approaches. To do this, TURN-10 will contain a paragraph in the  
> General Behavior section that talks about the issue and mentions the  
> two approaches. At that point, nothing more needs to be said about the  
> approach of handling it in the TURN stack, but the description of each  
> request will contain a note on how the "stateless stack" approach can  
> be implemented for that request.
>
> For an Allocate request, the note will say:
> <t>NOTE: Implementations may implement the idempotency of the Allocate  
> request over UDP using the so-called "stateless stack approach" as  
> follows. To detect retransmissions when the original request was  
> successful in creating an allocation, the server can store the  
> transaction id that created the request with the allocation data and  
> compare it with incoming Allocate requests on the same 5-tuple. Once  
> such a request is detected, the server can stop parsing the request  
> and immediately generate a success response. When building this  
> response, the value of the LIFETIME attribute can be taken from the  
> time-to-expiry field in the allocate state data, even though this  
> value may differ slightly from the LIFETIME value originally returned.  
> In addition, the server may need to store an indication of any  
> reservation token returned in the original response, so that this may  
> be returned in any retransmitted responses.</t>
> <t>For the case where the original request was unsuccessful in  
> creating an allocation, the server may choose to do nothing special.  
> Note, however, that there is a rare case where the server rejects the  
> original request but accepts the retransmitted request (because  
> conditions have changed in the brief intervening time period). If the  
> client receives the first failure response, it will ignore the second  
> (success) response and believe that an allocation was not created. An  
> allocation created in this matter will eventually timeout, since the  
> client will not refresh it. Furthermore, if the client later retries  
> with the same 5-tuple but different transaction id, it will receive a  
> 437 (Allocation Mismatch), which will cause it to retry with a  
> different 5-tuple. The server may use a smaller maximum lifetime value  
> to minimize the lifetime of allocations "orphaned" in this manner.</t>
>
> For a Refresh request, there is a small issue of a retransmitted  
> Refresh request with a 0 lifetime value. If the first transmission  
> deletes the allocation, then the retransmission will fail with a 437  
> (Allocation Mismatch) error, since there is no longer any allocation.  
> To handle this case, we have added a sentence saying that the client  
> should consider a 437 response as "success" (since the allocation is  
> gone).
>
> For a ChannelBind request, there is normally no problem, however there  
> is a small issue if the client tries to rebind the channel number at  
> the 10 minute mark. In this case, the first ChannelBind might fail  
> (because the channel number is still bound), but the retransmission  
> might succeed (because the channel number has become unbound in the  
> meantime). To fix this problem, the text will say that the client  
> should wait 15 minutes before trying to reuse either the channel  
> number or the peer address in a new binding, and should consider a  
> ChannelBind failure response as an indication that the client and  
> server are now out-of-sync and should thus abandon the allocation.
>
> For a Send request, see my separate e-mail.
>
>
> Comments?
>
> - Philip
>
>
> _______________________________________________
> Behave mailing list
> Behave@...
> https://www.ietf.org/mailman/listinfo/behave
>

--

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@...
----------------------------------------------------------------------
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave