Subject: [BEHAVE] TURN: Proposed conf call

From: Philip Matthews <[email-masked]>
Date: Fri, 28 Mar 2008 14:23:59 -0400

There has been some discussion recently on the encapsulations used  
between the client and the server in TURN. Specifically, Hadriel has  
questioned the use of TCP transport for a UDP allocation, and has  
proposed an alternative encapsulation in his TWIST proposal.

I would like to see more discussion on these points, so I am  
proposing to arrange an open conference call where this issue can be  
discussed. If you are interested in attending, please send a private  
reply to me, as I am trying to find a time that will work for everyone.

As before, once a time is arranged, it will be announced on the  
mailing list. However, if you reply now, you will get to influence  
the time of the call.

- Philip

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 1 Apr 2008 16:39:09 +0300

> proposed an alternative encapsulation in his TWIST proposal.

I believe, TWIST would be is very complicated to implement without special 
privileges. In theory, it is do-able: it would be a slimmed-down userland 
TCP/IP stack. This applies to both TURN client and TURN relay, and is 
somewhat similar to what slirp[1] does. Alternatively, some kind of raw 
packets or tunneling API could be used.
This seems to be fit fairly well for hardware relays, but not quite anything 
else (client, or soft relays).

[1] http://slirp.sourceforge.net/

Nevertheless, this proposal would address the congestion issues involving 
multiple TCP session over a single TURN allocation. It does not solve the 
TCP-to-UDP problem - it just does not allow this case to happen, as the 
client must use UDP to the relay, independent of the relay-to-peer transport.

The current TURN proposal does not address head-of-line blocking and MSRP-like 
multiplexing problems. IMHO, this is a serious flaw. TCP-to-UDP however works 
(if UDP packets are allowed to be dropped), though that can be difficult if 
not impossible for hardware relays to implement.

The "obvious" way to fix the congestion issues is the way SSH does (I think): 
have some congestion control protocol on top of TCP. Complicated however.

The N:N TCP connection proposal solves the congestion issues. It is extremely 
easy to implement in software (both client and relay). In fact, client can 
almost use the TCP sockets as usual - as they do with SOCKS. Software relays 
can terminate the TCP sessions toward both client and peer and forward data 
across. I believe, it would also be easy to implement in hardware or kernel: 
TCP packets can simply be translated much like a double-sided NAT - in this 
case congestion control (and retransmission) are done end-to-end 
(client-to-peer).

For TCP-to-UDP, this would be pretty much the same as the current TURN. In 
fact, in this case using multiple TCP connections is not so interesting.

So, as far as I am concerned (you're free to disagree):

                       TWIST   TURN     N:N
----------------------------------------------
TCP-UDP HW relay           No    Hard     Hard
TCP-UDP SW relay           No    Easy     Easy
TCP-TCP HW relay         Easy  Medium?    Easy
TCP-TCP SW relay         Hard  Medium     Easy
TCP-TCP Normal client    Hard  Medium     Easy
TCP-TCP "Root" client  Medium  Medium?    Easy
Number of flows           N+1      N+1    2N+1

-- 
Rémi Denis-Courmont

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 1 Apr 2008 10:48:24 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Rémi Denis-Courmont
>
> privileges.

Actually, I think "special privileges" (if by that you mean root/administrative level access) are actually appropriate to require, to make a PC into a TURN/TWIST relay or client, imho.

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 01 Apr 2008 08:29:08 -0700

At Tue, 1 Apr 2008 10:48:24 -0400,
Hadriel Kaplan wrote:
> Actually, I think "special privileges" (if by that you mean
> root/administrative level access) are actually appropriate to
> require, to make a PC into a TURN/TWIST relay or client, imho.

Why would it make sense to require admin access to be a *client*?

-Ekr