Bruce Lowekamp said:
"Many of the questions you raise point to the same question of whether
tests or techniques that are known to fail on a certain percentage of
NATs under a certain percentage of operating conditions are
nevertheless valuable. behavior-discovery has an applicability
statement
http://tools.ietf.org/html/draft-ietf-behave-nat-behavior-discovery-06#section-1
that discusses those issues in some detail. I spent enough time
wording that statement and discussing it with various people that I
think it is best to refer to that statement.
You also repeatedly uses phrases such as "basically won't work" and
"it might work." The comes down to the value of "certain percentage"
as used above. My experience with these techniques, and the
experience of those who have used such techniques recently, is that
they are far more reliable than that, into the 90% range, particularly
when used correctly. That is not high enough that we could go back to
3489---all techniques require fallbacks because they fail, and 90% is
far, far too low of a success rate---but it is high enough that
applications can make useful decisions based on that information,
provided they have a fallback in cases where the information is wrong.
And those are the conditions of the experiment."
What I am failing to understand is the distinction between those
situations in which we "cannot go back to RFC 3489" and the scenarios
envisaged for the experiment.
Presumably, situations in which we "cannot go back to RFC 3489"
include Internet telephony, which may be used for life-critical
situations such as E911. For those kind of scenarios, we need
traversal technologies that are as reliable as possible, and are
willing to live with the complexity of ICE to achieve this.
The draft mentions P2P applications as one potential situation in
which usage of imperfect techniques is acceptable, and yet the
IETF currently has the P2PSIP WG, which is involved in the
development of technology for usage of SIP over P2P networks.
In that kind of application, wouldn't the reliability requirements
be similar to those in which we "cannot go back to RFC 3489"?
This lead me to think about the requirements for the diagnostic
scenarios that are also discussed in the document. In existing
deployments it is often challenging to figure out the reasons
why traversal is unsuccessful, and what can be done to improve
the overall success rate. Data suggests that there are even
common situations in which ICE will fail. But in thinking
through how to approach diagnosis under those conditions,
I'd currently be more inclined to start from the addition of
diagnostics to an ICE implementation than to focus on the
use of the diagnostic mechanisms described in the draft.
So while I'm generally sympathetic to the idea that there
are situations in which "less than perfect" techniques can
be useful, in practice a number of common situations
where NAT traversal is used today (such as life-critical
Internet telephony) do not seem to fit into that bucket.
It could be that I didn't quite understand the examples
given in the applicability statement, or that I'm putting
too much emphasis on corner conditions, because that is
what customers tend to complain about.
However, overall the document left me unclear about the
rationale by which the material deprecated in RFC 3489
was being re-introduced. While it does seem possible
to construct a rationale for this, the document doesn't
provide enough background to get me over that hump.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf