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
