Subject: [BEHAVE] TCP TURN Multiplexing Issue

From: Adam Roach <[email-masked]>
Date: Mon, 17 Mar 2008 17:24:08 -0500

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.

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

---

From: Adam Roach <[email-masked]>
Date: Mon, 17 Mar 2008 18:58:44 -0500

On 3/17/08 5:43 PM, Hadriel Kaplan wrote:
> But could I ask why you don't just have it use the already-established "control" connection, and force a new control connection to be created if you need to listen for more?  I.e., make it one TURN connection = one peer connection.  I suppose your model is cleaner because it keeps the allocated TURN server listen port tied to the control channel, and each spawned TURN connection is per peer connection using that.  But you can do the same thing the other way 'round, by using that cookie to make the turn server give you the same listen port.
>   

That's the kind of thing that I think we can optimize later, once we 
agree on the basic approach.

> The nice thing about using that initial "control channel" for the peer connection is it reduces delay when the peer connects, and you don't need to tear-down the old one if you don't need multiple connections (this isn't supposed to be for server-type service, right?).
>   

Right.

> But if you envision multiple remote peers connecting at the same time, then it won't work my way.  Is that one of the use-cases for TURN? (I haven't been following it)
>   

Well, for SIP, it is (or can be). That's where the entire problem we're 
trying to solve arises. The problem is that we can send an INVITE with 
TCP indicated in the offer, and have it fork. My understanding, based on 
the conversation last week, is that we are also expected (by the IESG) 
to handle this situation gracefully if it arises in other protocols (in 
other words, a SIP-specific solution to the problem is probably not 
suitable).

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Mar 2008 21:52:37 -0400

I like it, for what it's worth. (which isn't much)

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Adam Roach
> Sent: Monday, March 17, 2008 6:24 PM
> To: 'Behave WG'
> Subject: [BEHAVE] TCP TURN Multiplexing Issue
>

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 18 Mar 2008 12:02:57 +0200

> new connection is used to ferry information to and from the remote peer

That is essentially what I was trying to suggest at the meeting.

I'd much rather do that than re-invent SCTP on top of TCP.

-- 
Rémi Denis-Courmont

---

From: Adam Roach <[email-masked]>
Date: Tue, 18 Mar 2008 16:04:42 -0500

> That is essentially what I was trying to suggest at the meeting.

Ah, I had missed your point, then. I apologize, and apparently agree 
with your suggestion. :)

/a

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 18 Mar 2008 14:07:29 -0700

> > new connection is used to ferry information to and from the 
> > remote peer connection.
> 

Yes, at 1:59:23 into:
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf71/ietf71-ch5-thur-noo
n-behave.mp3

It seems like a very useful alternative design and I hope that it is pursued
and compared with the current TURN-TCP design.

-d

---

From: Philip Matthews <[email-masked]>
Date: Wed, 19 Mar 2008 10:38:19 -0400

> for this *kind* of approach before I spent too much time polishing the

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.

We could discuss this question on the mailing list (which didn't  
happen before). However, before we do this I think we need to decide  
what is going to happen with ICE-TCP. If we go with the TCP over UDP  
approach, then TURN-TCP is unnecessary and the whole issue goes away.

- Philip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 19 Mar 2008 16:58:53 +0200

> connections to the server that would then be dropped.

The server is anyway going to have to establish many TCP connections, either 
way, on the "peer" leg.

A two factor won't kill it.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Mar 2008 11:14:46 -0400

> Of Philip Matthews

I think there are conflicting needs.  One is for p2psip or other p2p/p4p protocols, where TURN-TCP needs to happen at the OS user-level to have hope of adoption.

I don't know why there's a difference to a TURN client or the TURN server between:
1) opening up new "channels" within a single TURN TCP connection through STUN signaling inside that single channel, and...
2) opening up new TCP connections, one per channel.

On the server side, the p2p TURN server PC's will be relaying bulk data traffic at the OS layer, so a few extra TCP handshakes in the kernel should hardly be a concern.  On the client PC side, a few extra TCP handshakes should be noise. (I realize the model of p2p is those PC's are one and the same when they're on the public Internet, but really it's noise compared to the overall work)

You're not removing the actual separate socket overhead - you're just muxing the sockets in a single TCP carrier between TURN client/server, right?  So there's no overhead savings there either.

The other need is for actual hope of getting network providers to offer TURN servers (maybe?); but that should really be hardware friendly, and TURN-TCP is not.

-hadriel

---

From: Philip Matthews <[email-masked]>
Date: Wed, 19 Mar 2008 11:45:37 -0400

Hadriel, Remi:

Say ICE-TCP takes the TCP over UDP approach, and thus a TURN-UDP  
server will also handle a TCP over UDP connection.  If so, are you  
still interested in this question?

- Philip

---

From: "Derek MacDonald" <[email-masked]>
Date: Wed, 19 Mar 2008 13:44:06 -0500

We also have to consider implementation cost; TCP over UDP is more work(and
testing!) than implementing an entire TURN/ICE client library.

I like Adam's approach.

-Derek

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Mar 2008 15:45:35 -0400

Yes, if the "question" you're talking about it single channel per connection vs. muxing channels.

But I think I would be in the minority here, because for me the forking property is not that big a driver - it's the exception not the rule, and I would optimize for the common rule instead (which ain't forking), and handle forking but accept a penalty for that case.  For example for NICE (non-sip), forking is not a property I think should be handled at all, because it basically *is* server socket behavior and it will drive firewalls to not allow it.  Otherwise we're just inventing RFC 3093.  ;)

-hadriel

> From: Philip Matthews [mailto:[email-masked]]
> Sent: Wednesday, March 19, 2008 11:46 AM
> To: Hadriel Kaplan; Rémi Denis-Courmont
> Cc: Adam Roach; 'Behave WG'
> Subject: Re: [BEHAVE] TCP TURN Multiplexing Issue
>
> Hadriel, Remi:
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Mar 2008 16:52:33 -0400

Saving cost is not a factor if it isn't usable in the end.  But I agree with you that it has to be reasonably do-able on the client side too.  It's just that in my humble opinion, the application or client needing it really should be the one bearing the burden of dev cost and CPU overhead, because it's the one who needs/wants it - the network is perfectly happy keeping the status quo, because its up to the new app to make itself work in the already deployed network.  With P2P the overhead doesn't matter as much (or rather, I don't care what it is).  So yes I agree, if P2P is the primary use-case, this is all good... nothing to see here, move along. :)

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Derek MacDonald
Sent: Wednesday, March 19, 2008 2:44 PM
To: Philip Matthews
Cc: Hadriel Kaplan; Rémi Denis-Courmont; Behave WG
Subject: Re: [BEHAVE] TCP TURN Multiplexing Issue

We also have to consider implementation cost; TCP over UDP is more work(and testing!) than implementing an entire TURN/ICE client library.

I like Adam's approach.

-Derek
On Wed, Mar 19, 2008 at 10:45 AM, Philip Matthews <[email-masked]<mailto:[email-masked]>> wrote:
Hadriel, Remi:

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

---

From: "Derek MacDonald" <[email-masked]>
Date: Wed, 19 Mar 2008 14:28:08 -0700

I suspect we are in the same camp on the TCP over UDP issue, but a few
points:

* the primary use case *isn't* P2P for the clients that are currently
driving turn TCP
* forking rarely happens
* TCP over UDP has a high implementation cost *everywhere* not just at the
client.

-Derek

On Wed, Mar 19, 2008 at 1:52 PM, Hadriel Kaplan <[email-masked]>
wrote:

>  Saving cost is not a factor if it isn't usable in the end.  But I agree
> with you that it has to be reasonably do-able on the client side too.  It's
> just that in my humble opinion, the application or client needing it really
> *should* be the one bearing the burden of dev cost and CPU overhead,
> because it's the one who needs/wants it – the network is perfectly happy
> keeping the status quo, because its up to the new app to make itself work in
> the already deployed network.  With P2P the overhead doesn't matter as much
> (or rather, I don't care what it is).  So yes I agree, if P2P is the primary
> use-case, this is all good... nothing to see here, move along. J
>
>
>
> -hadriel
>
>
>   ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Derek MacDonald
> *Sent:* Wednesday, March 19, 2008 2:44 PM
> *To:* Philip Matthews
> *Cc:* Hadriel Kaplan; Rémi Denis-Courmont; Behave WG
> *Subject:* Re: [BEHAVE] TCP TURN Multiplexing Issue
>
>
>
> We also have to consider implementation cost; TCP over UDP is more
> work(and testing!) than implementing an entire TURN/ICE client library.
>
> I like Adam's approach.
>
> -Derek
>
> On Wed, Mar 19, 2008 at 10:45 AM, Philip Matthews <
> [email-masked]> wrote:
>
> Hadriel, Remi:
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Mar 2008 18:32:34 -0400

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Derek MacDonald
Sent: Wednesday, March 19, 2008 5:28 PM
To: Hadriel Kaplan
Cc: Philip Matthews; Rémi Denis-Courmont; Behave WG
Subject: Re: [BEHAVE] TCP TURN Multiplexing Issue

I suspect we are in the same camp on the TCP over UDP issue, but a few points:

* the primary use case *isn't* P2P for the clients that are currently driving turn TCP
OK, my mistake, what is the primary use-case?

* forking rarely happens
Yup, we're on that same page. :)

* TCP over UDP has a high implementation cost *everywhere* not just at the client.

Nope.  We're not on the same page there.  It depends on what layer you expect the relaying to be done on.  UDP encapsulation/decapsulation of packets can be done on lots of commercial hardware that is already deployed and available off-the-shelf, with very good scaling properties.  The implementation cost for a server is obviously box-dependent, but it should be less than current TURN-TCP model for most hardware vendors, IMO.  The important thing is to not make that box terminate TCP sockets and modify TCP payload contents.  Not that there isn't hardware that can do that (there is), but it costs more and often scales less.  Even TCP splicing is expensive compared with encapsulation, usually, and I'm not convinced you can do TURN-TCP with TCP splicing anyway.  Even if TCP splicing could be used, I'm not talking about SBC-type hardware - I'm talking router hardware or firewall hardware or whatever - because the use-case is NICE, so you'd want as many vendors to potentially do it as possible, and not all of them can do TCP splicing in scale.
If you allow TCP/IP/UDP/IP, and you allow 8 extra bytes between and a small trailer (ie, it looks like TCP/IP/8B/UDP/IP), then from a hardware perspective even more vendors already do that - because lots of boxes do RFC 3948 in hardware (and that hardware is available off-the-shelf and it's cheap).  Obviously it would still take development cost, but it's nothing compared to doing TURN-TCP.
-hadriel
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Derek MacDonald" <[email-masked]>
Date: Wed, 19 Mar 2008 15:53:05 -0700

Inline.

On Wed, Mar 19, 2008 at 3:32 PM, Hadriel Kaplan <[email-masked]>
wrote:

> *Sent:* Wednesday, March 19, 2008 5:28 PM
> *To:* Hadriel Kaplan
> *Cc:* Philip Matthews; Rémi Denis-Courmont; Behave WG
> OK, my mistake, what *is* the primary use-case?
>
> For me, its getting protocols for things like view/sharing through a
NAT...possibly established using an invite dialog.

>
> * forking rarely happens
>
> Yup, we're on that same page. J
>
>
>  Nope.  We're not on the same page there.  It depends on what layer you
> expect the relaying to be done on.  UDP encapsulation/decapsulation of
> packets can be done on lots of commercial hardware that is already deployed
> and available off-the-shelf, with very good scaling properties.  The
> implementation cost for a server is obviously box-dependent, but it should
> be less than current TURN-TCP model for most hardware vendors, IMO.  The
> important thing is to not make that box terminate TCP sockets and modify TCP
> payload contents.  Not that there isn't hardware that can do that (there
> is), but it costs more and often scales less.  Even TCP splicing is
> expensive compared with encapsulation, usually, and I'm not convinced you
> can do TURN-TCP with TCP splicing anyway.  Even if TCP splicing could be
> used, I'm not talking about SBC-type hardware – I'm talking router hardware
> or firewall hardware or whatever – because the use-case is NICE, so you'd
> want as many vendors to potentially do it as possible, and not all of them
> can do TCP splicing in scale.
>
> If you allow TCP/IP/UDP/IP, and you allow 8 extra bytes between and a
> small trailer (ie, it looks like TCP/IP/8B/UDP/IP), then from a hardware
> perspective even more vendors already do that – because lots of boxes do RFC
> 3948 in hardware (and that hardware is available off-the-shelf and it's
> cheap).  Obviously it would still take development cost, but it's nothing
> compared to doing TURN-TCP.
>

I didn't realize that people considered terminating TCP sockets be so
expensive.  Stream modification, yes...but it sounds like the main
motivation is the availability of hardware support for this.

OTOH, the problem remains that this is a large implementation cost for
clients; it will greatly reduce support on the endpoint side.

-Derek

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Mar 2008 18:52:51 -0400

> connections to the server that would then be dropped.

Why would ICE have made it establish a lot of temporary TCP connections?

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Mar 2008 16:21:45 -0700

> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf
> > Of Philip Matthews
> >

If the offer contains RFC4145 (TCP) and it forks, the offerer 
will need to establish TCP connections with the answerers.  Only
one of those answerers will actually answer (return 200), and the
others are no longer needed; they are 'temporary'.

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Mar 2008 19:44:01 -0400

Inline...

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Derek MacDonald

OK, my mistake, what is the primary use-case?
For me, its getting protocols for things like view/sharing through a NAT...possibly established using an invite dialog.

OK, so who do you expect to pay for the TURN server to exist?  With p2p, the answer is "other users", and that works because they either don't know or don't care, and there is no directly billable cost.  If it's your own company, or some application provider, they're willing to pay because it makes their application work.  If it's a network provider, the incentive is harder to see.  I don't know how the client business model works, but in either of those non-p2p cases, as far as I can tell the server is the main capex issue for the provider, not the clients.  They will be paying X for the client software no matter what, if they didn't make it themselves or make their customers pay for it, and my guess is no matter how much more dev cost it is to you to do TCP/UDP up-front, in the end you will still charge approx. X because you can hide that one-time expense in volume. :) (I may be wrong on that - I don't sell clients)  For servers, that isn't the case.  We can hide development cost in volume, but not component cost.  Component cost results in direct increased capex to the provider.

I didn't realize that people considered terminating TCP sockets be so expensive.  Stream modification, yes...but it sounds like the main motivation is the availability of hardware support for this.

It's gotten less expensive (there are at least 3 off-the-shelf "chips" which do this now), but they still can't match what "regular" hardware can do in cost and scale.  I don't know if hardware support is a motivation for others.  It is for me, but I can already do TCP splicing.  But I'm just a tiny fish in the big pond.  The number of router services blades, firewalls, and VPN switch hardware boxes out there dwarfs SBCs.  Some of them can do TCP splicing, but active TCP termination drops their performance to crap.  So if the use-case for this thing is truly NICE (non-sip), and possibly even IPv4/v6 conversion a la Teredo, for non-P2P, then personally I would want as low a bar for hardware as possible, so as many hardware boxes can do it as possible.

OTOH, the problem remains that this is a large implementation cost for clients; it will greatly reduce support on the endpoint side.

To me the clients are the ones who will do it no matter what, because they need it.  They're the application.  Obviously if we can't use a normal TCP/IP stack in windows and other OS'es, that would be a big problem.  So I guess one question is, is it acceptable to install a VPN-like driver in the client?  Or do all the client changes HAVE to be done at the OS user-layer?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Mar 2008 19:51:01 -0400

> From: Dan Wing [mailto:[email-masked]]
> > Hadriel:

Ummm... wouldn't you only use a TURN server for listen-mode/receive TCP connections?  I mean if it's for creating TCP connections out to the peer (which I thought was disallowed?), why not just send it from behind the NAT to the peer direct??  I mean NATs do allow that. ;)
(it may be to the peer's TURN server, but that's still a listen mode for the peer)

Obviously if it forks and multiple answerers open TCP connections to the offerer, that would be multiple received peer connections on the TURN server, but that's the exception case not the rule. (ie, it's not a "lot")

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Mar 2008 17:05:19 -0700

> Ummm... wouldn't you only use a TURN server for 
> listen-mode/receive TCP connections?  I mean if it's for 
> creating TCP connections out to the peer (which I thought was 
> disallowed?), why not just send it from behind the NAT to the 
> peer direct??  I mean NATs do allow that. ;)

It would be something like this, with the current TURN-TCP spec:

 TURN client     TURN server  SIP proxy   TURN peer1   TURN peer2
    |                |            |            |            |
 1. |-----TCP--------|            |            |            |
 2. |---INVITE------------------->|            |            |
 3. |                |            |---INVITE-->|            | 
 4. |                |            |---INVITE--------------->|
 5. |                X<---TCP SYN--------------|            |
 6. |                X<---TCP SYN---------------------------|
 7. |                |            |<-18x w/SDP-|            |
 8. |<---18x w/SDP----------------|            |            |
 9. |                |            |<-18x w/SDP--------------|
10. |<---18x w/SDP----------------|            |            |
11. |-PEER-ADDRESS1->|            |            |            |
12. |-PEER-ADDRESS2->|            |            |            |
13. |                |<---TCP 3-way handshake->|            |
14. |                |<---TCP 3-way handshake---------------|

where TURN messages 11 and 12 are in the same TCP connection as message 1.

With the change being mentioned in this thread, message 1, 11, and
12 would all be different TCP connections.

> Obviously if it forks and multiple answerers open TCP 
> connections to the offerer, that would be multiple received 
> peer connections on the TURN server, but that's the exception 
> case not the rule. (ie, it's not a "lot")

For SIP, you're right it usually isn't a lot.  However, we 
have been tasked with making this work well for any arbitrary
protocol.

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Mar 2008 22:06:30 -0400

> From: Dan Wing [mailto:[email-masked]]
[snip]
> where TURN messages 11 and 12 are in the same TCP connection as message 1.

Right, good ok so it's what I was thinking.

> 12 would all be different TCP connections.

Right, understood.

> have been tasked with making this work well for any arbitrary

Sure, and I would expect any arbitrary protocol which expects multiple TCP connections, to handle multiple TCP sockets/descriptors. (since it would need to work without a TURN server)  So there's no reason to burden the protocols that don't need such forking behavior, or rarely do, to incur the overhead to optimize for the ones which do, imho. (especially since forking is a rather unusual behavior for protocols, afaik)

-hadriel

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 20 Mar 2008 10:03:29 +0200

> still interested in this question?

Yes.

Maybe the other end does not implement such hack. Or maybe the other end only 
can do real TCP out of its network.

By the way, I'd rather have one TCP control connection, _plus_ one TCP data 
connection per peer, i.e. (n+1) TCP connection to the TURN server, for n TCP 
connections to remote peers. There are two drivers for this:
- it is much simpler,
- it allows splicing, stateless translation and/or other heavy optimizations 
on the TURN server.

Also, if the client knows it will not establish/accept any further connections 
through the TURN allocation, it could simply close the TURN control 
connection, yet keep the data connections open. Effectively, this would 
remove much of the overhead of separating the control channel from the data 
channels.

---

From: Philip Matthews <[email-masked]>
Date: Thu, 20 Mar 2008 07:44:52 -0400

As I recall, with ICE-TCP as currently defined, a client needs 3 TCP  
candidates for each peer (an active candidate, a passive candidate,  
and an actpass candidate). Going with the model that each TCP  
connection to the peer requires a separate TCP connection to the  
server, this is three separate TCP connections between the client and  
the server, of which at most one will end up being used. We didn't  
like this.

However, I totally agree that separate TCP connections have other  
nice properties.

- Philip

On Wed, 19-Mar-08, at 22:06 , Hadriel Kaplan wrote:

> Sure, and I would expect any arbitrary protocol which expects  
> multiple TCP connections, to handle multiple TCP sockets/ 
> descriptors. (since it would need to work without a TURN server)   
> So there's no reason to burden the protocols that don't need such  
> forking behavior, or rarely do, to incur the overhead to optimize  
> for the ones which do, imho. (especially since forking is a rather  
> unusual behavior for protocols, afaik)
>
> -hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Mar 2008 11:23:09 -0400

> and an actpass candidate).

Really??
Why does it need a relayed active candidate?  Obviously it can create a TCP connection out from its NAT instead, but does it need a relayed one so it can know the public addr/port of its outgoing connection to a peer?
And why does it need an actpass one, if it has an active and a passive?

> Going with the model that each TCP

Yeah, and that's where I was thinking that the difference between P2P and network-server shows up the most.  For P2P, since it would handle terminating TCP and relaying at the user-layer, lots of sockets may become an issue for its OS.  But if they are truly short-lived, then it shouldn't be as big a deal.  For a server, the ability to easily splice is far more important than the number of sockets, because those sockets aren't real sockets once it starts splicing.

But I think we can accomplish both goals at once, using Adam's approach.  The client creates a single TCP connection to the relay (call it the control one), and sends STUN to get the 3 address candidates, but only one is for relaying through the control TCP connection: the passive one, if that's the common case.  The relay returns the addresses and cookies in that control one.  If the client wants to open a connection to a peer (ie, be active) it opens a new TCP connection and uses that cookie in its STUN to get the same public address.  If the relay gets a syn from a peer, it tells the client using STUN in the control TCP connection, which thus lets the client open a new TCP connection using the cookie for that connection data (the cookie being a relay socket descriptor, basically).

Thus, it only uses one socket initially, but one per peer connection for actual data transfer.  This should work at the user-layer, and also be do-able with splicing.  Though TURN is not typical TCP splicing, and as I said in another thread, this limits how many hardware devices can do it I think.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Mar 2008 11:46:41 -0400

> From: Rémi Denis-Courmont [mailto:[email-masked]]
>

I think you can do TCP splicing with the muxing concept.  It's not "normal" splicing, and has additional overhead which will impact performance, but I think it's technically possible.  The other down-side is I think it creates a head-of-line blocking problem on the muxed TURN connection, which SIP usage may not care about (if it ends up only using one channel in the end), but other protocols would.  And I'm not sure how many servers which do splicing in hardware could really do this type of muxed splicing.

Has anyone actually tried to do splicing with TURN-tcp?

-hadriel