--------------------

Spencer Dawkins (2004-04-16):

>> - Initiator sends the previous IKEv2 request (not a new one,
>>   to avoid problems with window size) over all the paths.

I know the Internet has changed a bit since Slow Start was introduced
:-}

but my impression was that if you think you have a problem, sending
multiple packets into the network is not the right thing to so. You're
talking about sending single packets over multiple paths, but we don't
know how disjoint the paths are (so they may all traverse one link
somewhere on the way). Should we ignore this, or think about it?

Pasi, do you have a sense that we're talking about a recovery
mechanism that we use during Fast Recovery, or during RTO (to put
things in TCP-speak)?

--------------------

Pasi Eronen (2004-04-21):

I think we should consider this somehow. At least we should not
send the path testing packets over all paths simultaneously, but 
instead separated by a short interval (since the paths could
share links).

My guess is that this is closer to RTO, but then again, window
size in IKEv2 is not really related to congestion control (though 
in some sense, "path failover" is trying to detect if the missing
packets were due to congestion, a broken link, or a dead peer).

--------------------

Jing Xiang (2004-04-27):

I think sending packets over all paths simultaneously or sequentially
can be useful depending on circumstances. e.g. some customers might
want to recover the connection ASAP at any cost, in this case sending
path testing packets out simultaneously might make sense. In other
cases, some customer might prefer certain paths because of cost and
not care much about recovering speed, then sending path testing
packets sequentially (subject to retry interval & retries) might make
sense.  It should not be that hard to have the protocol accormodate
both cases. I don't see any reasons we need to exclude either case in
our considerations.

--------------------

Bill Sommerfeld (2004-04-27):

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.

--------------------

Jari Arkko (2004-10-31):

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.

--------------------

Issue closed (2004-11-18): "Path testing must follow 
congestion control best practices (see full issue for details)."

--------------------