Subject: [midcom] 2x allocate vs FANTOM

From: Rohan Mahy <[email-masked]>
Date: Mon, 26 Nov 2001 10:01:54 -0800

Hi,

Comments inline...

 >    * To: "Bob Penfield" <[email-masked]>, <[email-masked]>
 >    * Subject: [midcom] 2 x ALLOCATE == FANTOM
 >    * From: "Pete Cordell" <[email-masked]>
 >    * Date: Thu, 22 Nov 2001 07:46:31 -0000
 >    * List-Id: <midcom.ietf.org>
 >    * Sender: [email-masked]
 >
 >Steve Davies wrote:
 >>> 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.
 >
 >To which Bob replied:
 >> The ALLOCATE method could be modified to include a "number of ports"
 >> attribute to request an allocation of 2 consecutive ports.
 >
 >and:
 >> The STUN "Request" could be sent to the 2nd allocated port to
 >> establish the binding.
 >
 >This line of reasoning basically leads to FANTOM (or something similar!) as
 >follows.
 >
 >If you use TURN to allocate two ports in one message, you need a way to
 >associate the second port with the original allocation message.  In FANTOM
 >we do this by returning an identifier in the equivalent of the allocate
 >response.  We then include that identifier in a probe (equivalent to the
 >STUN request in Bob's suggestion) sent to the server.  This allows the
 >server to do the association.
 >
 >With this method, the second port is effectively being set up using
 >out-of-band signalling.

This is incorrect.  A second TURN request would still send traffic from and 
receive traffic on the same port it uses for an Allocate 
Request/Response.  You would just include an extra identifier in-band.

 >Having the second port requiring out-of-band signalling, removes any benefit
 >of having in-band signalling for the first port.

see above.

 >We have also found that
 >there are many benefits to having an out-of-band signalling method.  For
 >example, we are also able to explicitly close the forwarding operation.  The
 >latter is a great comfort to a number of network administrators!
[snip]

Understood.  This is another classic simplicity vs. functionality tradeoff.

thanks,
-rohan

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 26 Nov 2001 12:22:34 -0600

Rohan Mahy wrote:

[snip]

> Understood.  This is another classic simplicity vs. functionality tradeoff.

And there lies the crux of the problem. If the pre-midcom protocol is 
expected to have a short lifespan, that is it will eventually be 
supplanted by the real midcom protocol, then I would expect that we 
would want to err on the side of simplicity.

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 26 Nov 2001 22:02:21 -0000

From: Rohan Mahy <[email-masked]>

> Request/Response.  You would just include an extra identifier in-band.

Please be more specific about how this would actually work.  If you are not
using the FANTOM approach, I can see lots of ways that it won't work, so
would like to see how you make it work.

> Understood.  This is another classic simplicity vs. functionality
tradeoff.

Please see my response to Ben Campbell's e-mail for my view on this.

> -rohan

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 26 Nov 2001 22:13:29 -0000

Ben (and Rohan),

I think we are getting overly seduced by this complexity debate.

For a start, complexity should never be considered purely in relative terms.

If solution A requires 5 minutes to implement and solution B requires 10
minutes to implement, that does not make A better than B even though it is
half the complexity of the other.

On the other hand, if solution A takes 6 months to implement, and solution B
takes 9 months, this is a strong case for implementing solution A, even
though B is less than twice as complex as A.

We also need to be careful about how we decide how complex something is.  In
this case the superficial approach of comparing the number of messages is
not a good guide.  Both proposals will require underlying structure to
implement the actual forwarding (receive packet, decide whether to allow it,
send it out etc.) that will look much the same for both.  Both will require
the capability to create such a forwarding instance, link it in with all the
other data structures, and how to delete it.  And they will both have to
learn where to forward data to on the public side.  The messaging aspect of
this is likely to be only a small percentage of the overall solution.

As a finger in the air figure (I hope that's not impolite in the States!) I
estimate that both TURN and FANTOM protocols themselves would take about a
week or two to implement.  When you add on code for configuration,
monitoring, and installation, then add documentation, system testing....
And if you are implementing a proxy based solution you will either have to
do SIP or H.323....  Well, you'll soon find that the actual FANTOM or TURN
parts are pretty miniscule.

So I think the relative complexity of FANTOM and TURN is not an issue.  In
that case I would go for the flexibility, and broader applicability that
FANTOM offers.

Pete.