Subject: [BEHAVE] TURN Issue #2: Stateful allocations

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Dec 2007 14:21:51 -0500

We did not get a chance to discuss this issue in the WG meeting. It was 
discussed briefly during the ad-hoc.

The issue is that, as of TURN-05, refreshes are now done with an 
explicit Refresh request, not an Allocate request. A consequence of this 
is that, if a server receives an Allocate request for an existing 
allocation, it has to reject it with a 487. Of course, if a server 
receives a retransmit of an initial Allocate request, for which it had 
already send a successful response, it retransmits that successful 
response. This, in turn, means that a server would require different 
treatment for a retransmitted Allocate request and a new Allocate 
request. These would differ only by transaction ID. This, then, requires 
that a TURN server be transaction stateful, remembering transaction 
state for some duration (there is a value in rfc3489bis defined I 
believe). This differs from a STUN server, which can typically 
statelessly respond to requests without having transaction state.

Note that my slides are in error, and incorrectly show the flow. The 
final message in the flow in the slides should be 200 and not 487. This 
caused some confusion during the ad-hoc.

There was general agreement at the ad-hoc that this is a non-issue. TURN 
servers are already required to maintain state, in the form of 
allocations, permissions, channel bindings, and so on. Transaction state 
is not much more.

Note that, rfc3489bis requires stun transactions (including extensions 
like TURN) to be idempotent. Note that, despite the different response 
codes for a retransmit and new transaction, TURN remains idempotent. 
Idempotency only requires that subsequent retries do not alter the state 
on the server; it does NOT require the same response. We went through 
this ad-nauseum on XCAP.

The proposal is therefore to just document this fact, but otherwise not 
change anything.

Please comment if you agree (or not) with this.

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

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 10 Dec 2007 10:56:32 +0200

> Please comment if you agree (or not) with this.

If I understand correctly, this practically means the server must remember the 
ID of the STUN transaction that created the TURN allocation. When it receives 
an allocation, it returns a success response if it's the same ID or an error 
if it's not. Right?

In that case, that seems right to me.

-- 
Rémi Denis-Courmont

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Dec 2007 09:59:15 -0500

inline:

> an allocation, it returns a success response if it's the same ID or an error 

Yes.

-Jonathan R.

---

From: Philip Matthews <[email-masked]>
Date: Mon, 10 Dec 2007 10:29:22 -0800

On 10-Dec-07, at 06:59 , Jonathan Rosenberg wrote:

>> If I understand correctly, this practically means the server must  
>> remember the ID of the STUN transaction that created the TURN  
>> allocation. When it receives an allocation, it returns a success  
>> response if it's the same ID or an error if it's not. Right?
>
> Yes.

To be consistent with 3489bis, you would also have to have a 10  
second timer. 3489bis says:
    If the request uses UDP transport and is a retransmission of a
    request for which the server has already generated a success  
response
    within the last 10 seconds, the server MUST retransmit the same
    success response.  One way for a server to do this is to remember  
all
    transaction IDs received over UDP and their corresponding responses
    in the last 10 seconds.

For short-lived TURN allocations, the 10-second timer is probably  
pointless, even though 3489bis requires it. For long-lived  
allocations (days or weeks or even months), the timer might become  
important -- I haven't worked out the math. In either case, I think  
the two documents should be consistent.

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 12 Dec 2007 23:24:52 -0500

I don't see what the duration of the allocation has to do with the 10 
second timer. Another way to think about the timer is that the server 
has to provide transaction state and retain it for 10 seconds after the 
end of the transaction.

-Jonathan R.

Philip Matthews wrote:
> To be consistent with 3489bis, you would also have to have a 10 second 
> timer. 3489bis says:
>    request for which the server has already generated a success response
>    success response.  One way for a server to do this is to remember all
> pointless, even though 3489bis requires it. For long-lived allocations 
> (days or weeks or even months), the timer might become important -- I 
> haven't worked out the math. In either case, I think the two documents 
> should be consistent.
> 
> - Philip
> 
>

---

From: Philip Matthews <[email-masked]>
Date: Thu, 13 Dec 2007 10:00:33 -0500

I see a very small inconsistency between this and 3489bis.

Let's assume the server uses Remi's suggested implementation  
technique. And lets say a client does an Allocate transaction with  
the server, then immediately deletes the allocation, and then does a  
second Allocation that happens to use the same transaction id as the  
first, but which the server cannot accept for some reason. Say all  
this happens within 10 seconds. Then the server needs to response  
with an error response, but 3489bis says that is should respond with  
a success response.

The problem is simply that the language in 3489bis is too strong for  
the TURN case. We could fix this either by changing the language in  
3489bis, or by specifying Remi's proposed implementation technique  
and saying that this overrides the text in 3489bis about the 10  
second stuff.

- Philip

On 12-Dec-07, at 23:24 , Jonathan Rosenberg wrote:

> I don't see what the duration of the allocation has to do with the  
> 10 second timer. Another way to think about the timer is that the  
> server has to provide transaction state and retain it for 10  
> seconds after the end of the transaction.
>
> -Jonathan R.
>
> Philip Matthews wrote:
>>>> If I understand correctly, this practically means the server  
>>>> must remember the ID of the STUN transaction that created the  
>>>> TURN allocation. When it receives an allocation, it returns a  
>>>> success response if it's the same ID or an error if it's not.  
>>>> Right?
>>>
>>> Yes.
>> important -- I haven't worked out the math. In either case, I  
>> think the two documents should be consistent.
>> - Philip
>
> --

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Dec 2007 00:12:19 -0500

Ah, OK. I think this is an esoteric case but I agree this is an 
inconsistency. I'd suggest a minor word smithing in rfc3489bis to fix this.

-Jonathan R.

Philip Matthews wrote:
> Let's assume the server uses Remi's suggested implementation technique. 
> And lets say a client does an Allocate transaction with the server, then 
> immediately deletes the allocation, and then does a second Allocation 
> that happens to use the same transaction id as the first, but which the 
> server cannot accept for some reason. Say all this happens within 10 
> seconds. Then the server needs to response with an error response, but 
> 3489bis says that is should respond with a success response.
> 
> 
> The problem is simply that the language in 3489bis is too strong for the 
> TURN case. We could fix this either by changing the language in 3489bis, 
> or by specifying Remi's proposed implementation technique and saying 
> that this overrides the text in 3489bis about the 10 second stuff.
> 
> - Philip
> 
>> has to provide transaction state and retain it for 10 seconds after 
>> the end of the transaction.
>>
>> -Jonathan R.
>>
>> Philip Matthews wrote:

---

From: Philip Matthews <[email-masked]>
Date: Fri, 14 Dec 2007 08:46:47 -0500

That is fine with me.
- Philip
On 14-Dec-07, at 00:12 , Jonathan Rosenberg wrote:

>> the server, then immediately deletes the allocation, and then does  
>> a second Allocation that happens to use the same transaction id as  
>> the first, but which the server cannot accept for some reason. Say  
>> all this happens within 10 seconds. Then the server needs to  
>> response with an error response, but 3489bis says that is should  
>> respond with a success response.
>> The problem is simply that the language in 3489bis is too strong  
>> for the TURN case. We could fix this either by changing the  
>> language in 3489bis, or by specifying Remi's proposed  
>> implementation technique and saying that this overrides the text  
>> in 3489bis about the 10 second stuff.
>> - Philip
>>> I don't see what the duration of the allocation has to do with  
>>> the 10 second timer. Another way to think about the timer is that  
>>> the server has to provide transaction state and retain it for 10  
>>>> For short-lived TURN allocations, the 10-second timer is  
>>>> probably pointless, even though 3489bis requires it. For long- 
>>>> lived allocations (days or weeks or even months), the timer  
>>>> might become important -- I haven't worked out the math. In  
>>>> either case, I think the two documents should be consistent.
>>>> - Philip
>>>
>>> --