Subject: [BEHAVE] TURN and TWIST

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Apr 2008 17:58:57 -0400

I read Hadriel's TWIST draft and as you can imagine I have lots of comments.

Firstly, despite Hadriel's comments on the list otherwise, my reading of 
this document is that it is positioned as an alternative proposal to 
TURN, obviously one coming extremely late in a process that has already 
taken a very long. The abstract says:

   This is similar to TURN, but defines an alternative mechanism which 
is more
    scalable, cheaper to deploy, and is thus more likely to succeed in 
achieving wide-
    spread use.  TWIST is not meant to replace TURN, but rather to 
provide an
    alternative.

The first and second sentences are clear contradictions to each other, 
since the argumentative language in the first sentence (and indeed 
throughout the document) position it as "lets boot turn and do this 
instead since its better". Though Hadriel of course has the right to 
author whatever drafts he likes, I find this approach at this late stage 
to be disruptive and not helpful.

Secondly, I disagree entirely with this approach. All along from day 
one, it has been an objective of TURN to provide a mechanism that was 
optimized for relaying of real time media and thus low overhead. Both 
the tunnel and transport modes in this document (and especially tunnel) 
bring huge overhead for no clear advantage. Thus, this draft doesn't 
even come close to meeting the needs which drove us towards the TURN 
design.

Next, the draft makes claims of more efficient hardware implementation. 
I find little real evidence for this; merely some hand-waving at 
similarity to existing VPN hardware products. However, TWIST is 
different than VPN and it is far from obvious to me that in reality this 
would be faster. To be frank this was a lot of FUD.

Architecturally, I find the mechansism is an odd hybrid between VPN 
(layer 3 relay) and transport (layer 4 relay). TURN is very much a 
transport layer relay and therefore IMHO a cleaner solution.

The draft also claims its simpler by only allowing one remote peer per 
allocation. This capability in TURN is not a bug, its a feature. It is 
there to make TURN work with SIPs forking feature. If you remove this 
capability in TWIST then TWIST will not work with SIP.

The transport mode in the draft appears to be broken; there is no way 
for a client to listen on a socket and then send a packet to a 
particular remote peer. The inner UDP packet only specifies the remote 
peer's destination port and not the destination IP. This is necessary 
for ICE to function. Therefore I do not believe transport mode works 
with ICE.

The latching behavior for listen connections is also broken. This used 
to be in TURN too - and was called lockdown. AN attacker can send a 
faked UDP packet with no credentials and cause the legitimate peer to be 
blocked. We discarded this approach years ago for this reason.

I believe the demultiplexing is broken. The draft says that, after an 
allocation is done, STUN and app data are demuxed by sending STUN within 
the native encapsulation, but using the default TWIST port. This is 
broken for two reasons. Firstly, it doesn't work if you want to 
communicate with the peer on its twist port. Second and more 
importantly, there can still be retransmissions of the original 
UNENCAPSULATED stun packets. This means the relay needs to demux STUN 
and UDP, which cannot be reliably done.

Thus my opinion is that we should set this draft aside and continue to 
work on TURN as we have been doing. If Hadriel or anyone else has 
suggestions on improvements or changes to be made in TURN let us of 
course hear them. But entertaining a completely new approach that 
doesn't work, provides no clear improvement over the current approach, 
and doesn't meet the needs that drove turn, is not beneficial for the 
group at this point.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 2 Apr 2008 22:18:52 -0400

Ah, I was wondering when you'd get time for this. :)
Thanks for responding.
Comments inline...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jonathan Rosenberg
>

Although I did not email it to the list, I did email to you and others that my intention was NOT to disrupt TURN with TWIST, and that it's NOT a replacement.  I am not, for example, suggesting that ICE be held up for it or even discuss TWIST.  I also noted several times to people off-line (though maybe not to you) that I was very sorry for being late with questions about TURN and though I tried to go through previous emails on the reflector archive but there just too many hits to go through, and that if the consensus was "we're way past that - go away" then I'd shut up about TURN.  The response from people off-line was "we're well past TURN with udp as the transport, but not Turn with tcp".  IF you and others on the list feel the turn-udp draft is well past the TCP or TLS transport issues, I will shut up about them.

I am keenly aware I am late to this process and do not want to put up roadblocks to it.  I was, for example, surprised to learn ICE had a normative dependency on the TURN-udp draft and that alone makes me regret raising issues on TURN-udp.  Again, I apologize sincerely for this.  :(

> even come close to meeting the needs which drove us towards the TURN

The "transport" mode, as noted in the TWIST draft, for udp could be made to *be* TURN's encapsulation.  You say "real time media", but using TCP transport for real-time media is a contradiction in itself.  The reason it's kosher, maybe, is it makes things work through certain firewalls and thus be "more successful".  In a similar vein, the "tunnel" encapsulation format is there simply to make things be "more successful", by letting more server relay types exist.  I.e., letting more things *be* TWIST relays.  Specifically I am thinking of firewalls, vpn switches, and router services blades.  That is the advantage for that format.  I am not personally tied to that format myself, though I do think it has other advantages if one were to actually encrypt using it.

> would be faster. To be frank this was a lot of FUD.

Don't take my word for it - talk to your company's hardware folks.  When you have to terminate TCP it's not free, and there aren't as many of your products that can do it.  There are ASICs that can do it in certain products, and there are at least 3 relatively new off-the-shelf chip vendors I know of that can do it in scale, where by scale I mean in the multi-gig and 100K-1M+ connections, one of whom your company uses in a couple of your products I believe.  For those 3 chips, terminating TCP or TLS is still more overhead than either of the encap formats in TWIST, with less resulting throughput and/or fewer flows.  I only "know" that because we have one of those too, and like any hardware vendor we're exposed to most if not all of their sales pitches and docs.  My goal for TWIST was to not only make those chips scale better, but to make it scale better on already deployed products which don't have those chips.  The reason for that desire is again to simply increase the probability of relays existing as much as possible, because I think that is a goal we should strive for.

"Cheap" is obviously a subjective concept, and for your company certainly pricing is different that for others.  For cases where people's PC's are being used as the TURN relays (ie, for p2p apps or models) it may even seem free to you.  I am not arguing against that, though there is an argument against it.  What I am referring to is "cheapness" in hardware.  Whether you agree with that or not should not actually matter to you, I think, because I am NOT proposing TWIST to replace TURN, and the market has a darn good way of figuring it out for us. :)  I am in a sense arguing to let the market do that.  I find the IETF is absolutely atrocious at trying to mandate market forces.  I'm not claiming to be any better at it, fwiw.

> transport layer relay and therefore IMHO a cleaner solution.

TURN is NOT a pure "transport layer relay", imho.  Not when it terminates TCP on one side and creates UDP on the other (for TURN-udp), or both sides (for TURN-tcp).  It is a hybrid of an application-layer relay, if anything.  It is muxing a control channel (STUN) and application channel inside a transport.  It is effectively creating a relay for a layer between app and transport.

> capability in TWIST then TWIST will not work with SIP.

I don't dispute this.  I indicate right in the TWIST draft muxing of relayed streams is possible with TWIST, just not defined in this first draft.  I think this muxing need is a unique property of SIP, but you're not proposing TURN be a SIP-specific-use relay mechanism anymore.  I left it as a TBD for TWIST, if we think it's important.

Your other comments I'll respond to separately, as they're in a different vein methinks.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 2 Apr 2008 22:35:14 -0400

With regards to the comments below, I have a general response: the TWIST draft is a straw-man.  It is not a fully defined draft.  It said that right in the abstract ("This document is a straw-man proposal, to stimulate discussion, not a fully defined draft"), but I realize I should have repeated that again (multiple times).

Some similar comments were made by others in other emails on this list, though you added some new ones as well, and I will attempt to resolve them in a revision.  Thank you for reviewing it and providing them, and I apologize for not having them covered already and for raising things you have already hashed out in the past.  I tried to grep through previous TURN-related emails on this list's archive, but quickly realized I would not be able to do so in reasonable human lifetime, and I did not see rationales in the current turn drafts for such decisions.

-hadriel