Subject: Re: [BEHAVE] TCP TURN Multiplexing Issue

From: Cullen Jennings <[email-masked]>
Date: Thu, 10 Apr 2008 21:10:38 -0600

On Mar 19, 2008, at 8:38 AM, Philip Matthews wrote:
>
> On Mon, 17-Mar-08, at 18:24 , Adam Roach wrote:
>
>> I've done a lot of thinking on the "multiple relayed connections
>> over a
>> single Client-Relay connection" problem over the weekend, and I  
>> have a
>> modest proposal that is, at the very least, easy to implement.
>>
>> It seems that the problem arises from a fundamental mismatch
>> between the
>> way that clients interact with relays, and the way that TCP listeners
>> generally behave. For example, consider the way the sockets interface
>> handles TCP server connections: applications create a socket
>> descriptor
>> and listen() on it. When a new incoming connection is made, the
>> listen()
>> call returns a *new* socket descriptor, which the applications then
>> performs read() and write() operations on.
>>
>> Now, what we're really trying to do with TCP TURN is provide remote
>> access to this kind of resource model. The problem arises when we
>> try to
>> take the original socket (the listen() socket) and multiplex its
>> information with multiple other sockets (the read() and write()
>> sockets)
>> on a single TCP connection.
>>
>> So what I'm proposing is: don't.
>>
>> In other words: to listen for incoming TCP connections, TURN clients
>> would establish a TCP connection to the relay (roughly
>> corresponding to
>> the listen() socket) that serves as a control channel. When a remote
>> peer connects, the Connection Status Indication (ESTABLISHED) would
>> include a new attribute, which contains a cookie. The user then
>> connects
>> to the relay using a new TCP connection, authenticates, and then  
>> sends
>> the cookie in a request of some kind (perhaps we re-use CONNECT for
>> this; perhaps we use a new message type). From that point forward,
>> this
>> new connection is used to ferry information to and from the remote
>> peer
>> connection.
>>
>> I recognize that this generally ends up taking twice as many
>> connections; I think that there is room for optimization on top of  
>> the
>> basic theme (e.g., dropping the control connection when listening
>> is no
>> longer necessary), but wanted to know whether there would be any
>> support
>> for this *kind* of approach before I spent too much time polishing  
>> the
>> corners down.
>
> The TURN-TCP authors considered this approach. I developed a proposal
> similar to the one you are proposing and argued for it.
>
> As I recall, we dropped this one because it didn't work well with
> ICE. The client would end up establishing a lot of temporary TCP
> connections to the server that would then be dropped.

I'm being dense and don't understand why this doesn't work well with  
ICE. Can you explain?

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Apr 2008 10:55:45 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: Thursday, April 10, 2008 8:11 PM
> To: Philip Matthews
> Cc: 'Behave WG'
> Subject: Re: [BEHAVE] TCP TURN Multiplexing Issue
> 
> 

Here is the analysis:
<analysis>

Let's say you receive four a=candidate lines from your peer.  You 
prioritize the list of candidates, as specified in ICE.  You start
doing connectivity checks (basically, the priority is:  local 
candidates, STUN'd candidates, TURN'd candidates).  You do those
following the pacing rules (to not flood the network).

If, as you are doing your connectivity checks, none of them is 
succeeding so far, you will eventually get so low in your priority
list to need to use your TURN server to do the four connectivity
checks.  

Now, the two different designs:

* If the design of TURN requires a new TCP connection for each of
those four connectivity checks, you have four TCP 3-way handshakes
to the TURN server.  

* If the design of TURN requires only one TCP connection for each
of those four connectivity checks, you can send the connectivity
checks inside of TCP.  I would assume, because you're running
over TCP, you are already TCP-friendly so the connectivity 
checks would not need to be paced.
</analysis>

It is certainly worth discussing if establishing the separate 
TCP connections is 'bad', especially compared to how 'bad' it is
to multiplex several TCP connections over one TCP connection.

-d

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 14 Apr 2008 16:24:36 -0700

> to multiplex several TCP connections over one TCP connection.

Thanks -  I see what you are saying. I'm not sure how bad it is.  
Fundamentally ICE forms a ton of connections that don't get used so  
not sure how much different I see these than others. Would be  
ntersting to see more results on this.