Subject: [BEHAVE] behavior discovery category

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 12 Sep 2007 23:04:57 -0400

In Chicago we agreed to bring the question of what category
(Experimental or Informational) was appropriate for behavior-discovery
to the list.  Derek and I spent some time looking at this and at
http://www.ietf.org/u/ietfchair/info-exp.html.  We believe that the
appropriate status is experimental.   We have used P2P supernode
selection as an example application, but believe that the case of
applications without a rendevous server is more general.

I'm including the text from a revision of the draft that addresses this issue.

Bruce

Abstract

   This specification defines an experimental usage of the Simple
   Traversal Underneath Network Address Translators (NAT) (STUN)
   Protocol that discovers the presence and current behaviour of NATs
   and firewalls between the STUN client and the STUN server.

1.  Applicability

   This experimental STUN usage does not allow an application behind a
   NAT to make an absolute determination of the NAT's characteristics.
   NAT devices do not behave consistently enough to predict future
   behaviour with any guarantee.  This STUN usage provides information
   about observable transient behavior; it only truly determines a NAT's
   behavior with regard to the STUN server used at the instant the test
   is run.  Applications requiring reliable reach between two particular
   endpoints must establish a communication channel through a NAT using
   another technique.  IETF has proposed standards including ICE
   [I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] for
   establishing communication channels when a publically accessible
   rendevous service is available.

   This usage provides techniques known to be of use for diagnostic
   purposes.  These techniques are considered experimental when applied
   to real-time selection of parameters for protocols in situations
   where a publically accessible rendevous service is not available.
   One possible application might be optimizing supernode selection in
   P2P networks based on statistical experience with establishing
   connections and diagnosing NAT behavior with a variety of other
   peers.

2.  Introduction

   The Simple Traversal Underneath Network Address Translators (NAT)
   (STUN) [I-D.ietf-behave-rfc3489bis] provides a mechanism to discover
   the reflexive transport address toward the STUN server, using the
   Binding Request.  This specification defines the NAT Behavior
   Discovery STUN usage, which allows a STUN client to probe the current
   behaviour of the NAT/FW devices between the client and the STUN
   server.  This usage defines new STUN attributes for the Binding
   Request and Binding Response.

   Many NAT/FW devices do not behave consistently and will change their
   behaviour under load and over time.  Applications requiring high
   reliability must be prepared for the NAT's behaviour to become more
   restrictive.  Specifically, it has been found that under load NATs
   may transition to the most restrictive filtering and mapping
   behaviour and shorten the lifetime of new and existing bindings.  In
   short, applications can discover how bad things currently are, but
   not how bad things will get.

   Despite this limitation, instantaneous observations are often quite
   useful in troubleshooting network problems, and repeated tests over
   time, or in known load situations, may be used to characterize a
   NAT's behavior.  In particular, in the hands of a person
   knowledgeable about the needs of an application and the nodes an
   application needs to communicate with, it can be a powerful tool.
   For these diagnostics to be effectiev, the application must select a
   STUN server that is appropriately located with regards to its future
   communication partners.

2.1.  Example Use with P2P Overlays

   An application could use Behavior Discovery in a P2P protocol to
   determine if a particular endpoint is a reasonable supernode
   candidate.  This P2P network application is willing to select
   supernodes that might advertise unreliable IP addresses to avoid the
   cost of dedicated servers.  A supernode candidate requires that its
   NAT(s) offer(s) Address Independent Filtering.  It might periodically
   re-run tests and would remove itself as a supernode if its NAT/FW
   chain lost this characteristic.  These tests could be run with other
   supernode candidates acting as STUN servers as well as dedicated STUN
   servers.  As many P2P algorithms tolerate non-transitive connectivity
   between a portion of their peers, guaranteed pair-wise reliable reach
   might be sacrificed in order to distribute the P2P overlay's load
   across peers that can be directly contacted by the majority of users.

   Use of Behavior Discovery for such an application requires:

   o  Specification of protocols capable of offering reliable end-user
      performance using unreliable links between peers.

   o  The application is deployed behind NATs that provide Address
      Independent Filtering and that remain in this mode for an amount
      of time sufficient for the application to identify their behavior,
      distribute this information to the rest of the overlay, and
      provide useful work for the application.

   This draft is experimental as deployed applications implementing open
   protocols have yet to be deployed in such environments to demonstrate
   that these two requirements have been met.  However, apocryphal
   evidence suggests that househould and small business targeted NAT
   devices have stable behaviour, especially when there are few clients
   behind them.  And numerous P2P applications have been deployed that
   appear to have these properties, although their protocols have not
   yet been subjected to rigorous evaluation by standards bodies.

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 17 Sep 2007 16:39:46 -0700

Folks, please look over Bruce's email below.  We need some discussion on
Informational versus Experimental for
draft-ietf-behave-nat-behavior-discovery.  The choice will control how other
specifications can reference the document.  As Bruce mentions below, see
http://www.ietf.org/u/ietfchair/info-exp.html for guidelines on Informational
versus Experimental.

Thanks,
-d

> -----Original Message-----
> From: Bruce Lowekamp [mailto:[email-masked]] 
> Sent: Wednesday, September 12, 2007 8:05 PM
> To: Behave WG
> Subject: [BEHAVE] behavior discovery category
>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 23 Sep 2007 13:29:53 -0700

One of the key reasons that we needed to do a bis for RFC 3489  is  
because we have run the experiment to find out if nodes can reliably  
detect what type of NAT they are behind using a STUN like techniques.  
We know the answer - they can not and this is not a rare case but  
happens surprisingly often. This resulted in the change away from the  
advice in 3489 to the advice in bis (not to mention the move from  
unilateral NAT traversal techniques to bilateral techniques). There  
are test results document in draft-jennings-behave-test-results.  
These results are for specific NATs but we know from other deployment  
experience, and from other test results such as Saikat's and Ford's,  
that we wee similar issues in deployments.

I agree it would be nice if a client could detect what type of NAT it  
was behind using STUN, however, I believe the only experiment being  
proposed here we already clearly know the answer to.

Cullen <with my individual hat on>

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 26 Sep 2007 16:13:46 -0400

Cullen,

I think the argument of "this didn't solve the problem before" is a
little bit off target.  The original focus of 3489 was static
type-discovery, with the goal of obtaining information that could be
used for permanent configuration of a device.  We know that doesn't
work.

The focus of the behavior-discovery draft is explicitly on dynamic
behavior observation.    The experimental question is whether the
basic techniques that originally came from 3489 are useful in contexts
other than the original.  The current draft proposes two specific
uses.

- the first is just diagnostics for administrators. I don't think
there should be any dispute over whether this is useful.  I would also
argue that this is actually a PS type of use by itself.
- the second is the P2P example.  In this case, behavior discovery is
proposed to be used for initial guidance on how a new potential
supernode might perform.  The peer (and rest of the overlay) is
assumed to support ICE for connections regardless, but many overlays
would not want a node that requires ICE (and god-forbid relaying) to
act as a supernode.  So if behavior discovery reports an overlay
restrictive NAT behavior, the node won't try to become a supernode.
Otherwise, it might try and then if it discovered through usage that
there is too much overhead in contacting it, would withdraw as a
supernode.

The experimental question in the second case is whether such a test is
useful.  If becoming a supernode when you shouldn't and then
withdrawing is expensive or leads to unreliable or poorly performing
operation, then even if the behavior discovery check is only "correct"
75% of the time, its relative cheapness may make it very useful for
the application.

This is very different than the original use of 3489, because it's an
explicit statement that it may not be right 100% of the time, but is
still very useful.  In my opinion, making this available for new
protocols as an experimental option would be very useful.

Bruce

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 27 Sep 2007 09:34:09 -0400

I think we have all converged on experimental but I'm going to reply  
to bit of stuff bellow ... only because I think it might impact some  
of thinking on what goes in this draft and on how it is used in p2p.

On Sep 26, 2007, at 4:13 PM, Bruce Lowekamp wrote:

> act as a supernode.

small nit here - uh - I suspect that it is going to require ICE even  
if node has public IP. But I get what you are saying about wanting a  
way to detect if a relay is needed - I just would not phrase this as  
requires ICE

>   So if behavior discovery reports an overlay

> 75% of the time, its relative cheapness may make it very useful for

One thing we do know about testing NATs like this is that to run any  
sort of test that produces useful results, you need the client behind  
the NAT to have at least two and preferably more IP addresses. I am  
assuming that this nat test document is going to make that very  
clear. I suspect this will not be easy for a P2P node to do.

The second thing is that I think we are solving the goal the wrong  
way here. In the supernode case you are thinking of, what we want to  
know is that we won't need relays (or some other characteristic we  
deem desirable). The way to do this is let the node form a few  
connections and keep track of how many of them needed relays. If the  
number is good (like 0) then let it become a supernode and if the  
number is bad don't. I think this type of design will work out far  
better than any sort of STUN testing.

Culen <with my individual hat on>

PS - I hate all of the many ways IETF people are using the word  
"supernode" but fully understand what you mean by it above :-)