Subject: [BEHAVE] Alternative Proposal for Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 20 Nov 2008 13:10:10 -0600

Following Jonathan Rosenberg presentation of TURN-tcp, I wrote a short
I-D describing an alternative based on Adam Roach suggestion of using
the same algorithm that is used in SSH:

http://www.ietf.org/internet-drafts/draft-petithuguenin-turn-tcp-variant-00.txt

-- 
Marc Petit-Huguenin
Home: [email-masked]
Work: [email-masked]
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Simon Perreault <[email-masked]>
Date: Thu, 20 Nov 2008 13:30:15 -0600

> the same algorithm that is used in SSH:

I have a few questions for which I think I know the answers, but I'd 
like to hear you answer anyway:

1. Can this be implemented completely in user space, both on the client 
and on the server?

2. How are the values of WINDOW-SIZE and MAX-SIZE determined?

Simon

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 20 Nov 2008 13:44:39 -0600

> 1. Can this be implemented completely in user space, both on the client

I didn't start the implementation but as OpenSSH is user space, I guess
that this should also be implementable in user space.

> 2. How are the values of WINDOW-SIZE and MAX-SIZE determined?

I think that MAX-SIZE is the size of the buffer allocated.  I do not
know for WINDOW-SIZE but it should be possible to find this in the
OpenSSH code.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Thu, 20 Nov 2008 22:01:17 +0200

> http://www.ietf.org/internet-drafts/draft-petithuguenin-turn-tcp-variant-00

This is more complicated (meaning costlier, more bug-prone and more 
IOP-failure prone) than plain TCP connections.

This is much less performant and scalable. For userland implementations, JDR's 
proposal benefits from the heavy optimization that TCP/IP stacks have gone 
through over the years with regard to many TCP connections, and to forwarding 
data across file descriptors. For kernel/hardware implementations, JDR's 
proposal allows simply doing 1:1 TCP packets translation (the TURN server 
becomes a double-way NAT).

This prevents using all TCP extensions such as ECE, new congestion algorithms, 
etc. This also will cause lots of headaches with the "preserving behavior", 
as you cannot do 1:1 packets matching.

This still suffers from some limited head-of-line blocking (it's like TCP 
compared to SCTP).

This exhibits a higher overhead, as we need multiplexing inside TCP.

The usual "advantage" of saving on TCP connections is to save state on the 
server. If that's to push the same state up the stack, I don't see the point.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 20 Nov 2008 15:33:10 -0600

> server. If that's to push the same state up the stack, I don't see the point.

Some of your arguments are absolutely true (HOLB), some are debatable,
and the others I have to think about them.

But there is also some advantages to the single connection solution, for
example establishing a new peer TCP connection is faster.  Please also
have a look to section 3.3.2 in the excellent draft-iab-ip-model-evolution.