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 IETFs 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 > _______________________________________________ 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
