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