Subject: [BEHAVE] Allocation move in TURN

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 08 Sep 2007 12:03:51 -0700

Sorry for the late comment.

There is an interesting paragraph in section 6.1.2.1 of
draft-ietf-behave-turn-04 that says this:

"If the port behavior requested is for a Specific Port, the server
 MUST attempt to allocate that specific port for the client.  If the
 port is allocated to a different internal 5-tuple associated with the
 same STUN long-term credentials, the client is requesting a move.
 The server SHOULD replace the old internal 5-tuple with the new tuple
 over which this Allocate request arrived.  The server MUST reject the
 move request if any of the attributes other than LIFETIME have
 changed (BANDWIDTH, REQUESTED-TRANSPORT, etc.)."

With some small modifications in the spec, this can be used to
automatically take care of NAT reboot or TCP disconnection.

Two modifications would be needed in section 6.1.1.2:

Instead of sending a subsequent Allocate request with exactly the same
attributes that was used on the initial request, the
REQUESTED-PORT-PROPS is modified to carry in the Specific Port Number
field the port allocated from the initial request.  If a NAT reboots,
the Allocate request will be seen as an initial request, and the
previous allocation will be moved to the new tuple.  The client will see
that the reflexive server transport address changed and can use it
immediately in a reINVITE without having to create a new allocation.
This does not work for a TCP disconnection as this will immediately
remove the allocation so I propose to remove the last sentence of
section 6.1.1.2 so a TCP disconnection does not remove the allocation.
When the client detects the TCP disconnection, it can open a new
connection and send an Allocate request as described above.  The server
will then move the tuple to the new connection.  The allocation for a
TCP connection is then removed by the expiration of the allocation timer
as for UDP.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 10 Sep 2007 11:24:57 +0300

> automatically take care of NAT reboot or TCP disconnection.

I am pretty sure I already commented that this would NOT WORK.

When a TCP connection is reset. you do not know where EXACTLY within the 
send/recv windows this has happened. As such, even if you moved the TCP 
allocation, you cannot resync with the other end (the real end. not the TURN 
server). Unless the application-layer protocol can automagically reset to 
some sane state.

Unfortunately. most TCP-based protocol are not capable of doing this. 
Especially, MSRP does not support this, and TCP-framed RTP does not support 
this either.

-- 
Rémi Denis-Courmont
Software engineer

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 10 Sep 2007 02:42:41 -0700

> Especially, MSRP does not support this, and TCP-framed RTP does not support 

True.

But what if the TURN client sends the number of bytes received before
the disconnection in a new attribute in the first Allocate request of
the new connection, and the TURN server responds by adding in the
response an attribute containing the number of bytes received from the
TURN client before the connection?  Wouldn't this help (assuming that
the TURN client and server have big enough buffers) to resynchronize the
streams?

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 10 Sep 2007 13:09:37 +0300

Le Monday 10 September 2007 12:42:41 ext Marc Petit-Huguenin, vous avez 
> the TURN client and server have big enough buffers) to resynchronize the

Nevermind that you would need to rewrite the socket API to access the internal 
TCP buffers. At that point you might as well extend TCP rather than TURN.

-- 
Rémi Denis-Courmont