Subject: [midcom] The pre-MidCom Agenda (was: Simplicity vs. generality)

From: Orit Levin <[email-masked]>
Date: Tue, 27 Nov 2001 14:49:57 -0500

I definitely think that for different cases different solutions should be
used. Also, I like very much the idea of having different servers being
deployed and the ability to discover them using the SRV records.
Because of the complexity and the variety of both the problems and the
solutions, not all of the evolving solutions (i.e. various SIP/SDP
extensions, RTP modifications, etc.) would comply with the pre-MidCom
agenda. In my mind, a candidate for the "temporary" and easy deployable
pre-MidCom protocol shall comply with the following:
1. It shall be application independent. - I don't think it is a
controversial topic for the MidCom WG.
2. It should be self-contained, i.e. it should require MINIMAL additional
efforts from the application if at all! This point is crucial for any
pre-MidCom efforts. How any standard solution, requiring additions and
special application behavior, can be considered as "quickly deployed" and
"intermediate"?

The point is that the "media intermediate" technique has became the
candidate for the pre-midcom technique NOT because it can solve all the
problems (although not in the most efficient way), but because it can solve
(many of) the problem(s) in the simplest and a self-contained way.

TURN is a good candidate for solving the NAT problem but it should be able
to stay on its own without requiring any application special behavior such
as SIP/SDP extensions, SIP refreshes, RTP/RTCP changes, etc. 

Orit Levin
Chief Architect
RADVISION Inc.
TEL: +1.201.529.4300 x 230
FAX: +1.201.529.3516

 -----Original Message-----
From: 	Christian Huitema [mailto:[email-masked]] 
Sent:	Monday, November 26, 2001 2:39 PM
To:	Ben Campbell
Cc:	[email-masked]
Subject:	RE: Simplicity vs. generality (was Re: [midcom] 2x allocate
vs FANTOM)

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

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