I agree with Henry, Frank, Suresh, and the lurkers on this list who have concern that ICE hasn't demonstrated its claims in the real world, while others have achieved similar ends with great success using much simpler approaches. (Some examples: Skype, Hamachi, Red Swoosh/Akamai, etc.)
For example, regarding the "hole punching" approach (by which I assume you mean "opening a hole and trying to keep it open" versus ICE's "open a hole 'on demand' for each connection"), it's been demonstrated to work at large scale with at least 90% direct peer connectivity across the internet, today, with a much simpler message flow and implementation. I find it concerning that ICE has taken a more costly, difficult route without confirming it's truly worth the additional incremental effort (or even a step backwards). I share the concern that ICE standardization has gotten far out ahead of the horse in inventing a new protocol from scratch rather than modeling off of the proven protocols that came before it, which historically has been the IETF strength. Given this choice to go a new route, I think it warrants a higher burden of evidence -- contrasted against known success rates of competing solutions -- before being formally endorsed by the IETF. I'm completely open to ICE being superior to all others. I have no doubt more effort has been put into it, and I'm eager to enjoy the fruits of everyone's labor. But I'd like to see the data that proves it, and I see no reason to charge ahead with standardization until data is firmly in hand. -david > -----Original Message----- > From: Philip Matthews [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 18, 2007 9:27 AM > To: Pyda Srisuresh > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected]; 'Henry Sinnreich' > Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > > Frank, Henry, Suresh: > > I agree that ICE is a complex spec. I also agree that it would be > very interesting to see > more data on which situations result in a direct path between > endpoints, as opposed to > a path via a TURN server. > > However, I don't understand the comment that "Hole Punching > Techniques" are an alternative. > In my view, ICE _is_ a "Hole Punching Technique". > > Perhaps you are referring to the use of STUN alone??? > The problem with using STUN alone is that there are cases where using > the reflexive address > doesn't work, and there is no way with STUN alone to determine when > an endpoint should or > should not use a reflexive address. > > But perhaps you are referring to something else? > - Philip > > > On 18-Jul-07, at 11:37 , Pyda Srisuresh wrote: > > > Thanks to Henry and Frank for so eloquently articulating this. > > > > As both Henry and Frank mentioned, I fully support standardizing on > > HOLE > > PUNCHING TECHNIQUE and leveraging the IETF's considerable influence > > to force > > NAT vendors to migrate towards implementations that are friendly to > > Hole > > Punching and the Application developers to design applications > > using the hole > > punching techniques. That should be the FIRST order of priority. > > > > Yet, what is happening in BEHAVE WG is the other way around. Some > > people have > > put their weight so heavily in favor of ICE that they asked to drop > > the work on > > hole punching technique as WG item. THIS IS WRONG. I no longer see > > "NAT > > Traveral application design guidelines" as BEHAVE WG milestone. > > > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING > > TECHNIQUES > > to move forward as a WG item? > > > > regards, > > suresh > > > > --- "Frank W. Miller" <[EMAIL PROTECTED]> wrote: > > > >> > >> > >> Greetings, > >> > >> > >> > >> What I think Henry is advocating is a systematic approach to > >> making sure > >> that the content of the ICE spec is right for its intended > >> purpose, i.e. a > >> complete, general NAT traversal solution. NAT traversal has been > >> in my > >> opinion one of the most difficult aspects of SIP implementation > >> and its very > >> important that its eventual standardized solution be right. I > >> know I spent > >> a lot of time implementing all the "tests" in the first 3489, only to > >> discover that they were not that useful. There are two valid > >> technical > >> concerns that are put forth in this email: > >> > >> > >> > >> 1) Viability of correct operation in practical > >> implementations. ICE can > >> result in very complicated message transfers. > >> > >> 2) Performance. As pointed out in this email and in other > >> places, the > >> additional latency associated with ICE operations can be significant. > >> > >> > >> > >> Henry also points out that there are competing approaches (e.g. Hole > >> Punching) that can perform well in many situations and have better > >> performance. IMHO, another approach by the IETF in general would > >> be to > >> standardize on Hole Punching and leverage the IETF's considerable > >> influence > >> to force NAT vendors to migrate towards implementations that are > >> friendly to > >> Hole Punching. > >> > >> > >> > >> The bottom line is that I agree with Henry in that labeling ICE as an > >> experimental draft is the right thing to do. It will allow those > >> implementing ICE (including myself in all likelihood) to proceed > >> but signals > >> to the users the correct status of the standard's contents. > >> > >> > >> > >> I also want to applaud loudly the underlying tone of Henry's > >> thread here. > >> That is, in solving specific technical problems within the IETF > >> forum, > >> focusing on empirical observation of working implementations > >> should be the > >> MO that we all strive for when developing and proposing what may > >> become > >> protocol standards. > >> > >> > >> > >> Thanks, > >> > >> FM > >> > >> > >> > >> > >> > >> _____ > >> > >> From: Henry Sinnreich [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, July 18, 2007 8:20 AM > >> To: Magnus Westerlund > >> Cc: [email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > >> Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > >> > >> > >> > >> Magnus, > >> > >> > >> > >> I sincerely appreciate your interest and this note! > >> > >> > >> > >>> I don't quite understand why you are requesting a status change > >>> of ICE > >> > >> > >> > >> However the arguments stated by the WG co-chairs and by you here are > >> procedural in nature, whereas the facts are some cause for serious > >> concern, > >> and I will just mention a few facts: > >> > >> > >> > >> RFC 3489 (STUN) was also presented as a NAT traversal solution > >> back in 2003, > >> but <draft-ietf-behave-rfc3489bis-07> now clearly admits that > >> "STUN is not a > >> NAT traversal solution by itself. Rather, it is a tool to be used > >> in the > >> context of a NAT traversal solution. This is an important change > >> from the > >> previous version of this specification (RFC 3489), which presented > >> STUN as a > >> complete solution." > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-behave- > >> rfc3489bis-07.txt > >> > >> My guess is, in plain English, RFC 3489 turned out just NOT to be an > >> acceptable solution as it was hoped to be. > >> > >> > >> > >> The excellent I-D <draft-ietf-sipping-nat-scenarios-07> shows the > >> ICE call > >> flow with two endpoints behind two NAT (Fig. 22 on page 38) > >> require 66 > >> messages just for the SIP INVITE! > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat- > >> scenarios-07.txt > >> > >> What happens if the two endpoints are in different ISPs that have > >> NAT of > >> their own in addition to the ones in Fig. 22? > >> > >> What happens if one would try ICE along a P2PSIP route with say > >> 5-8 hops? > >> Would there be hundreds of messages? What is the likelihood for > >> failure? > >> > >> > >> > >> By contrast with such approaches based on hope and faith, the > >> BEHAVE WG has > >> produced work based on real measurements and tools to do the > >> measurements, > >> such as > >> > >> > >> > >> "NAT Classification Test Results" > >> > >> > >> > >> "Application Design Guidelines for Traversal through Network Address > >> Translators" > >> > >> The measurements for hole punching are reported in > >> > >> "Peer-to-Peer Communication Across Network Address Translators" > >> > >> http://www.brynosaurus.com/pub/net/p2pnat/ > >> > >> > >> > >> I am also a believer in ICE and have actually urged Jonathan > >> Rosenberg to do > >> this work and he has given his best. Now that we have ICE-17 > >> version, it is > >> in the best interest of the industry and the IETF to make it an > >> experimental > >> RFC, but not yet a standard so that: > >> > >> 1. Independent, compliant implementations will be developed, > >> > >> 2. Testing in events such as SIPit, > >> > >> 3. Reporting the results, such as reported for the "hole > >> punching" above. > >> > >> > >> > >> What happens if indeed hole punching proves to be the far more > >> effective > >> approach? > >> > >> > >> > >> The industry can ill afford a new series of RFC[ICE]-bis and all > >> the years > >> it takes to move from believing to measuring and proving. I am > >> sure IETF > >> procedures were meant in this spirit (though I am not good in > >> producing the > >> right quotes). > >> > >> > >> > >> Thanks again for your attention to this concern about ICE. > >> > >> Also my apology to all the anguish to the numerous contributors to > >> the ICE > >> related I-Ds, but writing test tools and reporting measurements is > >> the right > >> way to go. > >> > >> > >> > >> Henry > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, July 18, 2007 1:11 AM > >> To: Henry Sinnreich > >> Cc: [EMAIL PROTECTED]; [email protected]; [EMAIL PROTECTED] > >> Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC > >> > >> > >> > >> Henry Sinnreich skrev: > >> > >>> Following some discussions and soul searching, the best approach for > >> > >>> ICE-17 for LC would be to _go ahead and make it an experimental > >>> RFC_. > >> > >>> > >> > >>> This would support the development of interoperable > >>> implementations, the > >> > >>> collection of deployment data and also hopefully open source code. > >> > >>> > >> > >>> Though I have full faith in ICE, following the practices that > >>> made the > >> > >>> IETF successful take precedent here, I believe. > >> > >>> > >> > >>> This is a change from the attached that I wrote on 7/16/2007. > >> > >>> > >> > >>> Note: We can only hope the proliferation of SBC in VoIP service > >>> provider > >> > >>> networks will not make these concerns and ICE for SIP a moot > >>> issue, but > >> > >>> this is another topic. > >> > >> > >> > >> Henry, > >> > >> > >> > >> I don't quite understand why you are requesting a status change of > >> ICE? > >> > >> To me it appears that ICE is almost finished spec. It has been > >> > >> implemented, used and feedback has been influencing the protocol. > >> It is > >> > >> definitly one of the better examples of current IETF work that > >> actually > >> > >> has running code. Sure, the implementations may not be fully > >> updated yet > >> > >> to the latest draft version. But I think it is safe to say that ICE > >> > >> works in the intended core cases. If there are some corner cases > >> where > >> > >> it fails, that may be. But that is not information we will have until > >> > >> really large scale deployement or someone makes very extensive tests. > >> > >> > >> > >> I think the IETF and the Internet has much more benefit from a > >> standards > >> > >> track solution than any of the risks existing with ICE of today. > >> > >> > >> > >> And to be clear, proposed standard is allowed to be published > >> without a > >> > >> single implementation exists. It might not be good practice, but > >> it is > >> > >> allowed by our process. And as I said before ICE has had enough > >> > >> implementation that I am very confortable in balloting YES for it > >> when > >> > >> it appears on the IESGs table. > >> > >> > >> > >> Cheers > >> > >> > >> > >> Magnus Westerlund > >> > >> > >> > >> IETF Transport Area Director & TSVWG Chair > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Multimedia Technologies, Ericsson Research EAB/TVM/M > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Ericsson AB | Phone +46 8 4048287 > >> > >> Torshamsgatan 23 | Fax +46 8 7575550 > >> > >> S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] > >> > >> --------------------------------------------------------------------- > >> - > >> > >>> _______________________________________________ > >> Behave mailing list > >> [EMAIL PROTECTED] > >> https://www1.ietf.org/mailman/listinfo/behave > >> > > > > > > > > > > > > _______________________________________________ > > Behave mailing list > > [EMAIL PROTECTED] > > https://www1.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > Behave mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
