Subject: Re: Last Call: draft-ietf-behave-nat-behavior-discovery (NATBehavior Discovery Using STUN) to Experimental RFC

From: Bernard Aboba <[email-masked]>
Date: Fri, 3 Apr 2009 23:39:42 -0700

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.

---

From: Bruce Lowekamp <[email-masked]>
Date: Sun, 5 Apr 2009 22:57:22 -0400

Bernard,

Thanks for the comments.  Let me see if I can describe a scenario in
which behavior-discovery is useful.

First, we don't want to "go back to 3489."  There were two problems
(well, there were a lot more problems, but I just want to talk about
two right now) in particular that we don't ever want to go back to:

- 3489 specified that an application would start up, characterize its
NAT, and work in that mode forever after
- 3489 specified that if you had a friendly NAT, you could query the
STUN server for your transport address and use that one address

At the same time, behavior-discovery is targeting applications for
which ICE doesn't necessarily make sense.  For example, applications
that don't want to fall back to TURN, but have other options for how
to establish a connection.   (whether this means indirect routing or
not needing the connection, or other reasons)

So let me try to go into more details on a potential P2P application.
When P2P node A starts up, it evaluates its NAT(s) relative to other
nodes already in the overlay.  Let's say that its testing indicates
it's behind a good NAT, with endpoint-independent mapping and
filtering.  In this case, the peer will join the overlay and establish
connections with appropriate peers in the overlay, but it will
advertise to any node in the overlay that wants to reach it that they
don't need to route through the overlay network formed by the P2P
nodes to reach it (which is the normal routing mode in a P2P overlay),
they can just send directly to its IP address.

So when node B wants to send a message to A, it sends the message
directly to A's IP address and starts a timer.  If it doesn't receive
a response within a certain amount of time, then it routes the message
to A across the overlay instead.  (Alternatively, B could
simultaneously send the message to A's IP address and across the
overlay, which guarantees minimum response latency, but can waste
bandwidth.)

A over time observes what percentage of the time it receives direct
messages compared to overlay messages. If the percentage of direct
connections is below some threshold (say 66%, picking a random number)
then may stop advertising for direct connections.  But if the
percentage is high enough, it continues to advertise because it may be
helping performance.  If at some point, the NAT changes its behavior,
A will notice a change in its direct connection percentage and may
re-evaluate its decision to advertise a public address.

(There are a lot of other details how this might work, how it would
deal with multiple levels of NATs, and what the actual cost benefits
are.  I don't want to get into all of the details of how it would work
here.)

This is a good example because behavior-discovery is used for initial
operating mode selection, but the actual decision for whether to
continue advertising that public IP/port pair is made based on actual
operating data.  It's also using the result of the behavior-discovery
work as an optimization, not in a manner where the application will
fail if a percentage of the nodes in the overlay are unable to make a
connection.

Bruce

On Sat, Apr 4, 2009 at 2:39 AM, Bernard Aboba <[email-masked]> wrote:
> statement
> http://tools.ietf.org/html/draft-ietf-behave-nat-behavior-discovery-06#section-1
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>
>

---

From: "Tadayuki Abraham HATTORI" <[email-masked]>
Date: Tue, 7 Apr 2009 00:13:33 +0900

Dear experts,

Essentially, P2P application should be considered as a kind of invention of 
social science.
The role and the location of people and the related basis should be 
scientifically
defined within the technical specification. In addition to, the 
specification should be
proposed to neighborhood and our each local congress, parliament or diet.
Even if it includes military aspects.

The bell then beating one - Look where the ghost of traditional rigid 
computer come again.

TaddyHatty

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 6 Apr 2009 09:10:22 -0700

Bruce --

Thanks for the reply.  Your explanation provides some helpful background. 
Would you consider adding some of this material to the document? 

> Date: Sun, 5 Apr 2009 22:57:22 -0400
> Subject: Re: Last Call: draft-ietf-behave-nat-behavior-discovery (NATBehavior 	Discovery Using STUN) to Experimental RFC
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]
> 
> Bernard,
>

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 6 Apr 2009 13:17:05 -0400

Yes, if having more of a sketch of an application that would satisfy
the experiment criteria would help, I can add more detail about this
possibility in the applicability section.

Bruce

On Mon, Apr 6, 2009 at 12:10 PM, Bernard Aboba
<[email-masked]> wrote:
>> Subject: Re: Last Call: draft-ietf-behave-nat-behavior-discovery
>> (NATBehavior Discovery Using STUN) to Experimental RFC
>> From: [email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 8 Apr 2009 18:49:54 -0600

On Apr 5, 2009, at 8:57 PM, Bruce Lowekamp wrote:

> filtering.

This is the where this whole line of thinking goes off the rails. How  
would we run a test that would indicate the above? Many of the NATs  
out there you can not make this determination without multiple IP  
addresses behind the NAT. I have raised this objection at the  
microphone multiple times in the WG and it is always meant with  
roughly the same answer that is here "ah, there are some details that  
are in the draft but we can explain how to do it in the next version  
of the draft". The draft is now in IETF LC and we have not seen  
details on how to do this that work even in an opportunistic way. The  
WG has not even had a chance to comment on if the believe these  
details would work or not.

Cullen <as individual contributor>

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 14 Apr 2009 22:38:15 -0400

On Wed, Apr 8, 2009 at 8:49 PM, Cullen Jennings <[email-masked]> wrote:
> This is the where this whole line of thinking goes off the rails. How would
> we run a test that would indicate the above?

I've been thinking about whether there is any more accurate way to
describe what the tests indicate.  4.3 currently uses the phrase "the
NAT currently has Endpoint-Independent Mapping".  It might be slightly
more accurate to say that "the test produces no evidence to indicate
that the NAT is not currently using Endpoint-Independent Mapping."  Of
course, given all of the requests to shorten the text, that's a lot of
verbage to update all relevant statements.  It's also going to be very
hard to read.  I can add another explanation to the beginning of
Section 4, though.

> Many of the NATs out there you
> can not make this determination without multiple IP addresses behind the
> NAT.

So you're right that you can test for a few more bizarre NAT behaviors
with multiple IP addresses, but I haven't seen any evidence suggesting
those behaviors are present in most NATs.  Obviously these tests (that
require multiple private IP addresses) can't be run by most
applications.  I also think this is a good example of tests that can
be run using the Attributes defined in behavior-discovery, but which
really don't need to be described in the draft.  Can you provide what
you would think would be an appropriate reference?  I'll add a
statement that for more accurate characterization of NAT behavior,
these tests must be run using multiple private IP addresses.

Regardless of those tests, this is playing with the law of diminishing
returns.  Since NATs can change behavior over time and under load,
focusing too much effort on characterizing a single instant in time
isn't going to be nearly as useful as monitoring the NATs behavior
under usage.

> I have raised this objection at the microphone multiple times in the WG
> and it is always meant with roughly the same answer that is here "ah, there
> are some details that are in the draft but we can explain how to do it in
> the next version of the draft".

Please cite any time when you have raised this objection at the mic in
the minutes or audio recordings.  I have no recollection of you doing
this, and do not see it in the minutes.  Henry did mention it in a
comment at the mic once, which I did not respond to clearly, but I
don't believe you have ever brought this up at the mic.

The topic has been discussed offline, though, and I believe it is in
the same category of the discussions about testing for linux NATs and
for other bizarre behaviors that have been seen.  The draft tries to
discuss the most straightforward tests, in particular for describing
behaviors according to rfc4787.  It can't describe every test possible
with the attributes, nor should it.  But providing pointers to and
encouraging readers to investigate other applications of the
attributes seems like a good idea.

> The draft is now in IETF LC and we have not
> seen details on how to do this that work even in an opportunistic way. The
> WG has not even had a chance to comment on if the believe these details
> would work or not.

I don't know what you're referring to here.  For some reason your
reply didn't go to the behave WG list, so I restored that to the CC
list.  This draft has been discussed in detail at 3 separate sessions,
briefly at several others, and multiple times on the mailing list.  If
you think there is a topic that has not been adequately discussed on
the mailing list, by all means bring it up.  I welcome any WG comments
on this topic.

Bruce