Subject: [BEHAVE] TURN: channel ID vs STUN Send

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Mar 2008 11:55:49 -0400

Hi,
I've read the TURN-07 draft a couple times and don't understand the motivation for having two ways of doing something: channel-ID encapsulated and STUN-encapsulated data.  The draft does describe why one would want to use channel-ID's, to reduce overhead, but I just don't get why both are needed.  I'd understand the need if the TURN server only wanted do one or the other for performance reasons, and thus indicated which in its Allocate response, but that's not the model.  Instead, it looks like the client can start with STUN-encapsulated and switch to channel-id at its convenience, at any time, whenever or never; or it could just start with channel-id.

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

---

From: Philip Matthews <[email-masked]>
Date: Mon, 24 Mar 2008 12:34:32 -0400

On Mon, 24-Mar-08, at 11:55 , Hadriel Kaplan wrote:
> Hi,
> I've read the TURN-07 draft a couple times and don't understand the  
> motivation for having two ways of doing something: channel-ID  
> encapsulated and STUN-encapsulated data.  The draft does describe  
> why one would want to use channel-ID's, to reduce overhead, but I  
> just don't get why both are needed.  I'd understand the need if the  
> TURN server only wanted do one or the other for performance  
> reasons, and thus indicated which in its Allocate response, but  
> that's not the model.  Instead, it looks like the client can start  
> with STUN-encapsulated and switch to channel-id at its convenience,  
> at any time, whenever or never; or it could just start with channel- 
> id.

You are right that they are similar mechanisms. You are also right  
that the client can bind a channel at any time and is never forced to  
use it. This means that a client can:
a) Always use Send indications and never bind channels;
b) Always bind channels before sending to a peer, and always use  
ChannelData msgs;
c) Use ChannelData msgs to some peers, and Send indications to others;
d) Intermix Send and ChannelData msgs to the same peer.

Historically, the Send indication came first. Channels are a recent  
addition.

I believe that it is true that we could remove the Send indication  
and force clients to always use ChannelData (though I would need to  
carefully look through the spec to confirm). This would provide some  
simplification to the spec.

However, note that:
a) This would force clients to bind a channel even if they only  
wanted to send one or two messages. This might add some extra delay  
while the ChannelBind transaction completes. It would also force the  
client to use and track channels that it might not wish to. Consider,  
for example, ICE connectivity checks. I could easily see clients  
using Send indications for ICE connectivity checks, and binding a  
channel only after a valid pair has been selected.
c) We could not remove the corresponding Data indication, since there  
are cases where the server needs to send data to the client but has  
no available channel.

Anyone else have an opinion on this?

- Philip

PS. This comment provides some additional input into the question of  
authenticating Send indications.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Mar 2008 12:48:21 -0400

> -----Original Message-----
> From: Philip Matthews [mailto:[email-masked]]
>

I have to admit I really don't understand how ICE is making use of TURN in this regard (I haven't read ICE in well over a year).  It would seem to me that ICE should be doing as much as possible directly from the endpoints, and only using the TURN relay for a last-resort relayed candidate, and I'm not clear why it has to do multiple connectivity checks through the TURN relay since it is essentially guaranteed to work.  I know there is some language in the TURN draft about trying not to put strain on TURN servers by using them as a last resort measure, but ironically for hardware-based relays, any ad-hoc STUN messages being sent for connectivity checks at the beginning *are* the bulk of the work-load, rather than the relaying of data streams.  So reducing/removing these ad-hoc Sends through a TURN server should actually be a goal of ICE, imho.

> are cases where the server needs to send data to the client but has

Well, that depends on whether we stick to this connection muxing concept at all, or go for 1 TURN connection = 1 peer connection.  I know that's a really big change for TURN (and maybe ICE), so I am writing up a straw-man draft for this (called TWIST) and will submit it in the next couple weeks.

-hadriel

---

From: Philip Matthews <[email-masked]>
Date: Mon, 24 Mar 2008 13:07:16 -0400

On Mon, 24-Mar-08, at 12:48 , Hadriel Kaplan wrote:
> I have to admit I really don't understand how ICE is making use of  
> TURN in this regard (I haven't read ICE in well over a year).  It  
> would seem to me that ICE should be doing as much as possible  
> directly from the endpoints, and only using the TURN relay for a  
> last-resort relayed candidate, and I'm not clear why it has to do  
> multiple connectivity checks through the TURN relay since it is  
> essentially guaranteed to work.  I know there is some language in  
> the TURN draft about trying not to put strain on TURN servers by  
> using them as a last resort measure, but ironically for hardware- 
> based relays, any ad-hoc STUN messages being sent for connectivity  
> checks at the beginning *are* the bulk of the work-load, rather  
> than the relaying of data streams.  So reducing/removing these ad- 
> hoc Sends through a TURN server should actually be a goal of ICE,  
> imho.

TURN relays are indeed the last resort solution for ICE. However, you  
still need to test that this path works. A firewall might block, for  
example.

There might also be situations where there are multiple TURN servers  
and the endpoints want to select between them.

I am not sure I understand your comment about the ad-hoc STUN  
messages send at the beginning being the bulk of the work load.

> Well, that depends on whether we stick to this connection muxing  
> concept at all, or go for 1 TURN connection = 1 peer connection.  I  
> know that's a really big change for TURN (and maybe ICE), so I am  
> writing up a straw-man draft for this (called TWIST) and will  
> submit it in the next couple weeks.

When you talk about 1 TURN connection = 1 peer connection, are you  
talking about TCP or UDP to the peer? The problem that Rohan  
discussed at the BEHAVE meeting was with TCP between the server and  
the peer. If you are talking about UDP, then you are the first person  
(that I know of) to think this is a problem.

- Philip

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Mar 2008 13:24:24 -0400

> still need to test that this path works. A firewall might block, for

Sure, but I would expect a TURN path to work in most cases and fail rarely, so optimizing for the failure case seems odd.  Just *assume* it will work if you create an allocation on it, so include the channel-id at the allocation request, and have a way to tear it down if it doesn't.  As opposed to trying it first and then creating a channel if it worked.

> messages send at the beginning being the bulk of the work load.

This is where the difference between a software-based TURN relay as one would expect in p2p applications, differs from a hardware-based on.  For a software relay, it hardly matters if there are a bunch of STUN Sends/Data, since they're not much work difference from relaying of channel's (there is a difference, but avoiding relaying is a big benefit).  With hardware, once a relay flow is setup in hardware, the actual relaying incurs trivial overhead.  It's the STUN messages and setup of relay flows that costs processing.  The fewer STUN messages, the better.  And since the muxing concept does not actually save the server any flow-related data or flow setup, it's effectively no savings to mux stuff for a hardware server (in fact, in some servers it will be a penalty to mux).

> (that I know of) to think this is a problem.

I think it's a problem for TCP, mostly.  But if it's fixed one way for TCP, then I don't see why that way wouldn't work for UDP too.  And the way I think it should work is the same way I think you guys have recommended it should work for TCP between a client and its peer direct (namely, TCP/UDP/IP or TCP/IP/UDP/IP).

-hadriel

---

From: "Benny Prijono" <[email-masked]>
Date: Tue, 25 Mar 2008 11:40:22 +0000

On 3/24/08, Hadriel Kaplan <[email-masked]> wrote:
> This is where the difference between a software-based TURN relay as one would expect in p2p applications, differs from a hardware-based on.  For a software relay, it hardly matters if there are a bunch of STUN Sends/Data, since they're not much work difference from relaying of channel's (there is a difference, but avoiding relaying is a big benefit).  With hardware, once a relay flow is setup in hardware, the actual relaying incurs trivial overhead.

It will be interesting to hear if you can handle ChannelData in
hardware. I mean, receiving ChannelData involves a) parsing the
channel number, b) lookup the channel number in table to get the peer
address, c) update the permission's timer, and d) relay the
ChannelData payload to peer.  And sending ChannelData involves a)
looking up the channel number for the peer, b) making sure the
permission has not expired, c) package a ChannelData header and send
the header with the payload to the client.

So it doesn't look so trivial to me to get implemented in hardware.
And if you can, why can't you handle Send and Data indications too,
since the complexity is not that much different (typical Send/Data
indications only contains PEER-ADDRESS and DATA attributes).

On the other hand, removing Send/Data indications will require big
modifications in ICE protocol and its implementation (as opposed to
just add ChannelData as optimization case once the negotiation
completes), and frankly I'm not looking forward to this.

Just my 0.02p.

Cheers
 Benny

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Mar 2008 13:11:40 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Benny
> Prijono
>

That's all do-able in hardware, although obviously it depends a lot on the vendor's hardware.  But the channel header is a small fixed length header, with trivial "parsing".  For UDP it isn't much different than what SBCs have to do for RTP/RTCP relaying today.  The channel number is just part of the key for a relay table lookup, not much different than what some SBCs do for RTP payload type numbers today.

For TCP it could be a lot harder, but as I was reminded by someone else in Behave WG, you can play tricks with what you ACK, such that you can handle tcp-stitching things as bounded message segments instead of an unbounded stream.  But this gets ugly fast, and could affect the throughput of the client's connection to its peers due to many retransmissions and HOL blocking.  TURN-TCP is clearly the harder part over TURN-UDP.

> indications only contains PEER-ADDRESS and DATA attributes).

Because the Send Data is not a table lookup for relaying, but rather an explicit command to send it someplace, and someplace potentially new.  And sending something to a new target is not always directly resolvable in hardware, because it may require a separate routing table lookup or ARP resolution.  And because it's a little harder to parse (optional fields and TLVs).  Some hardware devices will want to handle that in the exception path (software).

> completes), and frankly I'm not looking forward to this.

Yeah, I have to admit I'm not thinking of optimizing this for ICE - I'm thinking of it for NICE or IPv4/IPv6 transition for general use.
But anyway, if ICE is the main driver and you're finding plenty of TURN servers out there, then you can certainly ignore my comments. (not that people won't anyway ;)
I'm just trying to lower the bar on the server side, because I think they have the least to gain from this whole thing, and should therefore have the least amount of overhead/work to do. (And by decreasing their complexity, they become cheaper or scale more and thus the RoI for a provider deploying them is easier to justify)

-hadriel