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]