Subject: [BEHAVE] TURN-TCP status

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 Feb 2009 16:40:16 -0800

The working group needs a new primary editor/author for turn-tcp.

Philip Matthews, who has helped with TURN, does not have sufficient time 
to work on TURN-TCP.  Rohan, the other co-author, also said he has
insufficient time.  That would leave Jonathan as the sole author 
and unfortunately he is stretched too thin.

Our current milestone is March 2009 to submit the document to IESG but
we won't make that date.  TURN-TCP's model is similar to TURN (with a
separate separate TCP connection per peer) which is expected to work
well with a mix of slow and fast TCP peers.  

The document still needs a significant amount of work, including:

  * describe the TURN server behavior
  * finish description of TURN client behavior
  * IAB considerations section, including why TURN-TCP is necessary
    (versus SOCKS or other already-defined approaches)
  * Security considerations

Related to TURN-TCP is ICE-TCP.  Namely, if ICE-TCP can successfully
establish a peer-to-peer TCP connection then TURN-TCP is unnecessary.
However, research [1] indicates that the techniques considered by
ICE-TCP will be successful approximately 80% of the time in establishing
a direct peer-to-peer connection.  The other 20% will simply fail, 
need to utilize a TURN-TCP relay, or use UDP (with the potential 
to lose TCP friendliness).  There is a suggestion that ICE-TCP 
should encourage additional candidate gathering (Teredo, UPnP IGD, 
SOCKS) [2] which will help ICE-TCP establish direct peer-to-peer 
TCP connections, but the amount of improvement is not yet known.

Is anyone planning to implement TURN-TCP client?  TURN-TCP server?
Or should we abandon TURN-TCP due to lack of need?

And the $64 million question:  if you can volunteer to take over
editing TURN-TCP, please drop the chairs an email.  Or should we
abandon TURN-TCP due to lack of editor?

-d

[1] http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/
[2] http://tools.ietf.org/html/draft-lowekamp-mmusic-ice-tcp-framework-00

---

From: Sebastien Vincent <[email-masked]>
Date: Tue, 10 Feb 2009 10:54:20 +0100

> Or should we abandon TURN-TCP due to lack of need?

I plan to implement TURN-TCP in TurnServer (http://www.turnserver.org/) 
if any.

--
Sebastien Vincent

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

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Tue, 10 Feb 2009 13:45:04 +0200

> I plan to implement TURN-TCP in TurnServer (http://www.turnserver.org/)

No offense intended, but this is "just" a university software project. I think 
it's great that we have motivated students doing implementations of IETF 
protocols. On top of that, your implementation is not just a reference; you 
seem clearly focused on performance and security (I did that sort of things 
too when I was a little younger). I think other people on this 
list are also intending to implement TURN servers, and likely TURN client 
libraries. *But*, that does not mean it is going to be deployed/used to any 
meaningful extent. It does not even mean that a real application is intending 
to use it.

Compared to TURN-UDP, TURN-TCP has some additionnal challenges. For low 
bandwidth TCP use cases, such as instant messaging, there is no need for 
relays. Data cab go inband all the time. This is also simpler. In other words, 
TCP is for bulk (bandwidth-heavy) transfers rather than real-time bandwidth-
limited media (SIP, XMPP, RTSP, etc). TCP NAT traversal needs a relay in more 
cases than UDP NAT traversal, which further aggravates the bandwidth problem. 
Last, ICE-TCP would be much more complicated to implement than ICE-UDP, which 
is itself not quite simple; this is just another roadblock.

Between ALG-based (SBCs) in the "telco" track, and UDP encapsulation (such as 
Teredo) in the "net" track, and the pre-existing SOCKS in the "corporate" 
track, there is little room for TURN-TCP.

If only file transfer of SIP actually did "work", there would be demand for 
TURN-TCP. But even MSRP, if it ever works, has gone a different way (MSRP 
relays and now SBCs). Truth is that we have no real use case for COMEDIA in 
SIP, and hence no use case for TURN-TCP either. If it were up to me, I would 
ditch MSRP, specify file transfer directly over COMEDIA (one file = one SIP 
session), and then maybe specify TURN-TCP. Not happening though.

I would say we should first understand what (if any) are the use cases.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D

---

From: Simon Perreault <[email-masked]>
Date: Tue, 10 Feb 2009 08:38:09 -0500

> I would say we should first understand what (if any) are the use cases.

I suppose multi-player games use TCP for communication, and I suppose they 
would benefit from ICE. I'm just guessing here, I have no experience in that 
field... 

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 10 Feb 2009 08:45:19 -0500

> I would say we should first understand what (if any) are the use cases.
in several typical firewall configurations, udp is not permitted to pass
through (except port 53) while tcp is more opened to pass through. (for
good or bad reasons). therefore, for an application where tcp would be
ok for transport, then tcp is a better choice than udp.

Marc.
-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca