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

Rémi Denis-Courmont wrote:
> On Thursday 20 November 2008 21:10:10 ext Marc Petit-Huguenin, you wrote:
>> 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
> 
> 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.
> 

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.

-- 
Marc Petit-Huguenin
Home: marc@petit-huguenin.org
Work: marc@8x8.com
_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave