RE: Some thoughts about "path failover"

Tero Kivinen wrote:
> > >    - The initiator does a couple of retransmissions over those
> > >      paths which don't seem to work.
> > 
> > Ok, I think. This is to make sure we didn't miss a faster
> > path just because one packet was dropped?
> 
> What about if the other end only replies to the first packet,
> i.e. it does not reply to those retransmissions coming during
> short time period, it will simply pick the first and answer to
> that, and ignore rest?

The document probably has to say something about acceptable
retransmission behavior, in order to ensure that the path
testing works together with that.

> > we could also skip CHANGE_YOUR_ADDRESS. What we would
> > lose is the ability to do M*N path testing; if both
> 
> I do not really think the M*N path testing is needed. If we
> assume that we can detect the problems in the local end, then
> we should be able to select on of the N ip-addresses. If we
> also assume that we are not really trying to fix general
> routing problems in the core network, i should be enough to
> use M*1 test packets, i.e. pick best working local IP-address
> for each remote address and send one packet to that remote
> end.

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).

If we have that, we certainly should take that into account, but
IMHO we should also handle the case where no such information
exists (my message yesterday suggested that "...this could be
either all N*M paths, or if the initiator has some additional
knowledge, only a subset of that").

> > One case where this might lead to problems is
> > a simple one: two GWs connected using two different
> > networks. Both GWs use a current address from network
> > 1. But then network 1 goes down. Now, there GWs are
> > unable to reach each other. This is because both are
> > able to use an address from network 2, but they can
> > only test it against network 1 address of the peer.
> 
> I think this is quite important case, thus I think we want to
> have address lists, i.e. so the both ends have knowledge of
> the all the ip-addresses of the both ends, thus either end
> have enough knowledge to try to fix the problem.

Yes, I also agree that this is an important case. Depending on
the details, it might be sufficient that one end has all the
knowledge, but not the other.

> > Overall conclusion: I think your list looks very good
> > and complete. Based on my 2 GW example, I am starting
> > to think we need the address lists and not just a single
> > address. 
> 
> I agree on that. I also think we do need address lists. 
> 
> > But perhaps we could have address lists and still fix the path
> > testing role for one of the participants only, such as the IKEv2
> > initiator.
> 
> I also think this should be fine. BTW, original IKEv2
> initiator is better party to do the recovery, as it is most
> likely going to be the roaming laptop. Thus it is the party
> which might move to behind NAT box, and it is only party which
> can fix that problem (i.e. move to use the NAT-T instead).

Yes, I agree that the initiator is better able to do this
(though I think this "path failover" and UDP encapsulation
are orthogonal features, not excluding each other.)

BR,
Pasi