Subject: RE: Simplicity vs. generality (was Re: [midcom] 2x allocate vs FANTOM)

From: "Christian Huitema" <[email-masked]>
Date: Mon, 26 Nov 2001 11:39:04 -0800

Part of the design choice in STUN/TURN is really about allowing
deployment of applications without requiring changes on the NAT and
firewalls, and also as much as possible without incurring cost -- which
means, by minimizing the number of additional servers and the amount of
traffic routed through these servers. There are several deployment
environments that we want to serve, depending on the type of
NAT/firewall that is obstructing the communication:

1- "cone" NAT, i.e. NAT mapping is independent of the outside
destination, communication with multiple peer is not restricted.
2- "restricted cone" NAT, i.e. NAT mapping is independent of the outside
destination, communication is restricted to peers to which traffic has
been sent from the inside.
3- "symmetric" NAT, i.e. NAT mapping is dependent of the outside
destination, communication is ipso-facto restricted to peers to which
traffic has been sent from the inside.
4- "symmetric" firewall, similar to "restricted cone" but without the
mapping.
5- "full firewall", i.e. UDP communication is mostly blocked.

As Jonathan previously mentioned, we have no intention of solving the
5th case -- if the local admin wanted to allow UDP, it would have done
so. STUN solves cases 1, 2 and 4; 1 and 2, combined, cover a very large
fraction of the current "residential NAT" installations, probably around
95%. TURN covers case 3, i.e. the remaining 5% of the residential market
and a good share of the firewall deployments. 

There is a very large difference between the cost of running STUN and
the cost of running a relay: about 2 transactions per call for STUN, 50
messages per second for the duration of the call for relays, including
TURN. As Jonathan pointed out, this is a big difference on the bottom
line -- and this is also the reason why "one size fits all" is not a
good approach.

-- Christian Huitema

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