Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC

[Pyda Srisuresh <[e-mail]>]

--- Philip Matthews <[e-mail]> wrote:

> 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.
> 

[suresh] Right, ICE does use the HOLE PUNCHING technique and the BCP guidelines
described in draft-ford-behave-app draft, even though ICE draft does NOT
acknowledge or reference the above draft or prior work that introduced HOLE
PUNCHING TECHNIQUE. ICE is also using HOLE PUNCHING in a limited way within the
constraints of STUN and SIP. Hence, the croner case scenarios you site. ICE is
NOT HOLE PUNCHING in its native form.

In the BEHAVE WG meeting(last IETF), several people talked of ICE as the new
application traversal approach blessed by IETF, and proposed dropping the
original draft ford-behave-app draft that proposes HOLE PUNCHING TECHNIQUE. As
a result, the application milestone is dropped from the WG charter and
ford-behave-app is not adapted as work group item. This, to me, is pitting ICE
against the basic HOLE PUNCHING TECHNIQUE. This is what I believe to be WRONG.

regards,
suresh


> 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" <[e-mail]> 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:[e-mail]]
> >> Sent: Wednesday, July 18, 2007 8:20 AM
> >> To: Magnus Westerlund
> >> Cc: [e-mail]; [e-mail]; [e-mail]
> >> 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:[e-mail]]
> >> Sent: Wednesday, July 18, 2007 1:11 AM
> >> To: Henry Sinnreich
> >> Cc: [e-mail]; [e-mail]; [e-mail]
> >> 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 [phone]
> >>
> >> Torshamsgatan 23           | Fax   [phone]
> >>
> >> S-164 80 Stockholm, Sweden | mailto: [e-mail]
> >>
> >> --------------------------------------------------------------------- 
> >> -
> >>
> >>> _______________________________________________
> >> Behave mailing list
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/behave
> >>
> >
> >
> >
> >
> >
> > _______________________________________________
> > Behave mailing list
> > [e-mail]
> > 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip