issue 14 - path testing and congestion

I'd like to close this issue based on what Bill Sommerfeld
said about it:

   While there may be situations where you can ignore congestion control
   best practices and get excellent benchmark results under carefully
   controlled conditions, such environments tend to be unstable under
   load and are therefore unsuitable for production use.

   Path failover is likely to be triggered in as the result of packet
   loss.  Packet loss is often caused by congestion.  Sending a burst of
   packets when you detect an event which may be the result of congestion
   has been considered a really bad idea for about two decades now.

   We MUST NOT produce a spec which, if deployed, would force router
   vendors to produce countermeasures to protect the rest of the network
   from us.

As a result, I'd like to suggest that when peers test candidate addresses
(or pairs), they SHOULD attempt testing all of them, but MUST do this
sequentially (based on an implementation-dependent priority order) and
using an exponential back-off procedure.

Ok for everyone? I'll assume so unless I hear from you in the next
couple of days.

Note that the unpleasant but necessary side-effect is that only a
small set of multihoming addresses on both sides is practical. On
larger sets, testing takes too long. Some math about this in

   http://www.arkko.com/publications/multi6/faildet.html#anchor9

--Jari