RE: Some thoughts about "path failover"

Tero Kivinen wrote:
> > The document probably has to say something about acceptable
> > retransmission behavior, in order to ensure that the path
> > testing works together with that.
> 
> Yes, but normally those include that if you get n
> retransmissions immediately following each other, you only
> reply to one of them (this can happen, when there is some box
> between that queues the packets for some reason, the normal
> reason for developers to see this is the case where they debug
> the program and it is stopped in the debugger for some time,
> and the other end decides to retransmit several packets during
> that time).

Maybe this behavior could be amended to take into account 
the (source, destination) IP addresses; that is, ignore the
extra packets only if they have same IP addresses. Otherwise 
it seems that we can't test different paths simultaneously
(and have some problems even testing them one-by-one, depending
on network latencies and definition of "immediately following
each other").

> > This seems to assume that we have e.g. some configuration
> > information for picking the best working local IP address 
> > (or in other words, prior knowledge about which paths 
> > are likely to work, given that the current one doesn't).
> 
> Yes, the local host do have the information about what source
> address should be usable for the remote end. I.e. if it tries
> to route them out, he do get one ip-address which to use...
> 
> He also have knowledge which of the local links are broken,
> thus if he removes the routes from those links, then packets
> will not be routed to those links, and it will not use that
> ip-address.
> 
> I do not think MOBIKEs should be fixing problems in the core
> network, i.e. the sender will only select the local ip based
> on the local information he have (i.e. information from the
> link status and routes for each links).

If the nodes always know which of the local links are broken,
and we don't consider failures elsewhere in the network, it
seems that we don't need path testing at all.

This would certainly simplify things, but I think the assumption
about always knowing which links work would severely restrict
MOBIKE's usability. Multihoming features in existing protocols
such as SCTP don't require this (i.e. they don't care where
in the network failures occur).

If we want to handle the case where failures are detected only
using lack of IKEv2 packets ("path testing"), we may need to
test all M*N combinations even if all the failures are on local
links: M, N or even M+N combinations are not always enough to
find which of the local links are broken (if more than one
failure can occur at the same time).

Thus, it seems that if we do path testing at all, the protocol
will also be able to recover from many failures that actually
occured "in the core"; maybe this is a somewhat unintended
consequence, but a positive consequence, I think.

Cheers,
Pasi