draft-rosenberg-midcom-turn-07

Marc Petit-Huguenin <[email protected]> Mon, 28 Feb 2005 17:27:02 -0800
Newsgroups gmane.ietf.midcom
Message-ID <[email protected]>
I think that I found two problems while implementing TURN:

The first problem is that the design creates some inefficiencies in the 
packet processing. Let say E is the endpoint, T the TURN server and R1 
and R2 two remote destinations that will exchange packets with E through 
the TURN server. First E want to send a packet to R1 so it wraps the 
packet in a TURN Send packet, sends it to T, that forwards the original 
packet to R1.
At this time, R1 becomes the default destination, and E can directly 
sends the next packets to T, that will forward them to R1. If R1 sends 
back a packet to T, the packet will be forwarded back to E. Now let say 
that E want to send a packet to R2. As R2 is not the default 
destination, E needs to wrap the packet in a Send request, and send it 
to T for forwarding to R2. The problem here is that if E want to send 
packets to R1, it will have to wrap again the packet in a Send request 
to change the default back to R1. In the worst case if E wants to send 
packets alternatively to R1 and R2, a Send wrapper must be used for each 
packet, which can be inefficient - a Send wrapper adds 80 bytes to the 
size of the packet, and needs more CPU and memory to be processed. A 
simple modification to the TURN protocol would be to add a parameter to 
explicitly ask the TURN server to change the default destination - or to 
use a different request, e.g. SendWithDefault.

The second problem is a race condition. When a packet is received by T 
from R1 or R2, the server forwards it if it comes from the default 
destination or wrap it in a DataIndication request if it comes from 
another destination. As the DataIndication request contains the source 
address/port of the packet, E can dispatch the packet to the correct 
module in the code. The problem is that the server and the client must 
always know what is the default destination but the values in the server 
and the client cannot be exactly synchronized because of the delay in 
the network. So let say R1 is the current default destination for E and 
T. If at the same time E sends a Send request with a packet for R2, and 
T receives a packet from R1, the default destination for E is now R2, 
but the default destination for T is still R1, so the packet is send 
unwrapped to E. E receives the unwrapped packet and dispatch it wrongly 
as if it comes from R2 instead of R1.


-- 
Marc Petit-Huguenin
Home: [email protected]
Work: [email protected]