Subject: [Ietf-behave] TURN Issue #9: UDP/TCP consolidation and simplification

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Dec 2005 11:32:13 -0800 (PST)

Right now, there are a bunch of things that are different between TCP
and UDP turn. The biggest one is that, with UDP, you can modify the
active destination after its set. With TCP, you cannot. With TCP, once
you perform a Set Active Destination, additional TURN traffic is
basically forbidden. This produces a nice handoff between TURN control
traffic and data traffic. This handover does not exist with UDP. With
UDP, you need to use the MAGIC-COOKIE to disambiguate TURN and regular
data traffic. With TCP, its still there but actually not needed. With
TCP, there is no explicit tear down or keepalive; closure of the tcp
connection or timeout cleans up the allocation. With UDP, there is a
separate TURN keepalive.
This difference is one of the ugly spots in TURN, and it leads to a
bunch of complexity in the protocol. It will make it more challenging to
build the stun framework, since it interleaves message processing with
transport protocols, which is a bad idea.
I've been striving to simplify TURN a bunch before it completes, as it
seems overly complicated to me for the value it brings. As a
consequence, I've been debating making the UDP operation closer to the
TCp operation. This would involve a bunch of changes that would not be
backwards compatible, so they require discussion definitely:
1. removal of the LIFETIME attribute. Rather, allocations are kept alive
only by data traffic. Data traffic is going to be present all the time
anyway to keep regular nat bindings open. Thus, keeping the TURN
bindings open the same way makes sense. Over time, I have increasingly
seen TURN as a protocol that "converts" a symmetric NAT to address
restricted.
2. only one Set Active Destination allowed. Once done, you cannot do any 
more, and indeed, no other turn signaling is possible. Unlike TCP, where 
there is an immediate transition, with UDP, you'll need a window of like 
10s where you need to disambiguate data and TURN/STUN packets based on 
magic cookie.

This whole discussion intertwines somewhat with the one around open 
issue #6.

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com