Subject: RE: [midcom] new I-D on "symmetric STUN"

From: Steve Davies <[email-masked]>
Date: Tue, 20 Nov 2001 17:17:41 -0000

John,

You are quite right. This email didn't help move the debate forward much.
I'm afraid I got a little frustrated with the politics. Nevertheless, I
stick by my statements so let me give you a couple of examples of the flaws
I see. 

* FANTOM uses an out-of-band signalling method 'Create Media Flow' to assign
transport addresses on the remote server/public intemediary. It then sends
outbound UDP Probes (with a session identifier) to create the dynamic NAT
assignment and to complete the mapping between the resultant random source
port the probe came from, and the transport addresses the Create Media Flow
method assigned, and the call. The first probe effectively creates an
outbound UDP connection down which media may flow in either direction for
that call. Please note that media is NOT tunneled in FANTOM.

TURN tries to simplify this approach by combining the 'probe' (the method to
create the dynamic NAT assignment) with an in-band signalling method to
assign transport addresses on the public intermediary. This is the ALLOCATE
method in TURN. 

One of the main reasons FANTOM has out-of-band signalling was to conform to
the spirit of RTP/RTCP by assigning consecutive port pairs to represent the
receive RTP/RTCP addresses at the intermediary. A single method 'Create
Media Flow' does that. Having grabbed a port pair, 2 UDP outbound
connections are needed to the intermediary to receive the respective RTP and
RTCP flows. Hence the Probes. 

TURN cannot conform to the spirit of RTP in this way because the ALLOCATE
method only reserves a single transport address on the intermediary. If it
requested 2 transport addresses, a probe or very similar mechanism would be
required to establish the second outbound UDP connection. Even worse, the
way TURN is specified, there is a good chance that as a TURN server runs out
of resource the associated RTP and RTCP transport addresses could have
different IP addresses. NOT ALLOWED.

There are many other advantages to using a separate Probe message. One very
good use of probes is to keep NAT bindings assigned, i.e. they are sent at
regular intervals to prevent the NAT from timing out. TURN has no probe or
NAT keep-alive methods which breaks the solution on at least 2 counts. In
one case, a terminal may make an ALLOCATE to obtain an address with which to
register with a public SIP proxy. It then sits there waiting to receive
incoming calls. However, without some traffic such as a probe or a NAT keep
alive, the NAT assignment created by the ALLOCATE times out, which means the
terminal won't receive incoming call notifications. A second case when the
NAT binding may time out is when the remote party is not talking and their
terminal implements silence suppression. 

FANTOM uses probes to ensure this doesn't happen. In FANTOM probes are
designed to be easily recognisable in order to help the implementation of an
efficient forwarding intermediary.

* TURN doesn't use a tunnel. FANTOM does. Some think that this implies
FANTOM is a VPN variant. FANTOM is most definitely not, but we'll deal with
that separately. FANTOM uses a tunnel for multiplexing out-of-band call
control and the out-of-band FANTOM client-server protocol into a single
connection. The connection is TCP because we valued reliability and the
life-time is more easily managed by the NAT. It could be UDP but we didn't
feel we needed to re-invent a UDP session with TCP characteristics. 

We envisaged that the client end of FANTOM would be implemented in severals
ways. For example, it could be implemented in a standalone system, serving
many terminals in a single enterprise. In Centrex applications there would
be no local proxy. In this case the FANTOM client would have to handle
multiple simultaneous call setups and cleardowns. We judged a single
persistant tunnel for all call control from the FANTOM client to FANTOM
server was the most efficient use of resources. 

To avoid tunnels, a similar TURN implementation would require the standalone
client to create many UDP connections to the intermediary - one for each
terminal wanting to receive incoming calls. As we remarked above, these UDP
connections need to keep NAT bindings through some sort of NAT-keep-alive
messages. The SEN proposal implemented a similar technique and found it to
be too resource intensive - hence their SIP proposal extensions. 

Having a tunnel in FANTOM has further advantages, not least in allowing
out-of-band signalling and control. The benefit here is that the protocol
can be extended to include other functions such as network management
without breaking the architecture. We want FANTOM to be extensible.

This email is getting quite long so I'll conclude by remarking that I hope
that these explanations indicate that while  FANTOM appears more complex
than TURN, there is a reason behind each method FANTOM implements. We
haven't made it complex for complexity's sake. FANTOM may be unfamiliar, but
that's no reason to start from scratch which I fear TURN is. 

Steve

-----Original Message-----
From: John LaCour [mailto:[email-masked]]
Sent: 15 November 2001 21:58
To: 'Steve Davies'; 'Jonathan Rosenberg'; [email-masked]'
Subject: RE: [midcom] new I-D on "symmetric STUN"

Steve,
 
You may or may not be correct, but this message does next to nothing
to help any of us evaluate the merits of either proposal.
 
Just because something was created earlier or even implemented doesn't
make it inherently better.
 
Rather than try to strong-arm us, you really need to enumerate the many
flaws and how your proposal addresses them.  If you want to be
completely forthcoming coming you should also discuss the weaknesses
of your own proposal and why you've made those trade-offs.
 
In fairness to you and Jonathan, I haven't done a thorough review of
either proposal yet.  This message should not be misconstrued
as  supporting either proposal.  Rather I'm trying to encourage
you to tell us something useful.
 
-John
-----Original Message-----
From: Steve Davies [mailto:[email-masked]]
Sent: Thursday, November 15, 2001 1:42 PM
To: 'Jonathan Rosenberg'; [email-masked]'
Subject: RE: [midcom] new I-D on "symmetric STUN"

Interesting TURN of events or should I say 'U TURN'. 
Puns aside, this proposal says nothing that hasn't already been proposed.
While I am pleased to see TURN uses IDENTICAL concepts to the Davies
proposal, it contains many flaws (too numerous to go into here). Fix those
flaws and you end up with the Davies proposal. Not only does TURN come a
month after the deadline set in Melinda's rules of engagement, but the
development of such a new and immature proposal is by definition not in the
best interests of a pre-midcom solution. If we agree on the concepts and
Jonathan et al are interested in a quick solution, then surely it makes
sense to jointly work on the most mature incarnation of those concepts. Why
re-invent the wheel?
Steve

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 20 Nov 2001 15:35:18 -0500

----- Original Message -----
From: "Steve Davies" <[email-masked]>
<snip>
> different IP addresses. NOT ALLOWED.

The ALLOCATE method could be modified to include a "number of ports"
attribute to request an allocation of 2 consecutive ports.

> NAT keep-alive methods which breaks the solution on at least 2 counts.

The STUN document does mention that "the application can periodically
retransmit the query in order to keep the binding fresh". The client will
need to send STUN "Request" type messages to the TURN server to keep the
binding alive. The STUN "Request" could be sent to the 2nd allocated port to
establish the binding.

> In
> terminal won't receive incoming call notifications.

Not a real good example, since a terminal will send REGISTER requests to the
SIP proxy on a regular basis (This will keep the NAT binding alive if the
registration interval is short enough). But you are correct that "keep
alives" will be required.

> A second case when the

Again, STUN explicitly mentions these keep alives and they could be used
once the TURN allocation is done.

> server was the most efficient use of resources.

Isn't this really the same as putting a proxy in the exterprise and having
it connect to the proxy in the public network over TCP? Why is FANTOM better
than adding a proxy? If FANTOM is present in the terminal, you have a tunnel
for every terminal. If you have a FANTOM client, then all the terminals need
to send signalling to the FANTOM client. Doesn't that make it a proxy?

> be too resource intensive - hence their SIP proposal extensions.

For residential and small enterprises, there won't be too many UDP
connections. Alternatively, they can use TCP connections. For larger
enterprises or networks, for the same cost as a FANTOM client, a proxy could
be installed which accepts the UDP connections and connects to the public
proxy with TCP (or even a single UDP connection).

> without breaking the architecture. We want FANTOM to be extensible.

I don't think there is a need for a tunnel. With STUN/TURN, setup of the
media binding occurs inband so there is no need for extra "signalling" to do
that. The applications can use TCP or STUN to make signalling connections.
With that, there is no need for a tunnel.

> that's no reason to start from scratch which I fear TURN is.

I don't think that TURN is starting from scratch. The basic concepts have
been presented in a couple of IDs for several months now.

STUN and TURN give us relatively simple tools that can be combined in
various ways to solve a number of different problems. Because they are so
simple, they will be easy to implement and add into existing products.

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: Melinda Shore <[email-masked]>
Date: Tue, 20 Nov 2001 15:50:12 -0500

I think that this is a good discussion.  One thing that might
help us make progress towards getting this done quickly would 
be to start identifying points on which there is agreement and
making them explicit/on the record/etc.  

Melinda