[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming

On 23-okt-04, at 8:00, <john.loughney@nokia.com> wrote:

The other reduction is that I'm not sure we need to solve
the "best path" problem but solving even the "a working
path" problem might be sufficient. That's at least my
preference.


Exactly; my thought has always been that we need to avoid
the non-working path(s) & that would be sufficient.

Avoiding non-working paths goes to the core of what's multihoming all about, so this is something we absolutely need. But I'm not sure it's all we need. What I'm worried about is the situation where there are multiple working paths, but there is a large difference in quality between them. For instance, one path has a capacity of 100 Mbps and another a capacity of 1 Mbps. In this case, selecting the latter path as part of regular operation would hardly be acceptable.

We _may_ be able to bring this problem back to manageable proportions by taking advantage of the information both ends have. So if either end knows that the second path is much slower, they'll avoid it as long as the first path is operational. This leaves only the cases where there is congestion in the core, which is pretty rare these days. (But this hasn't always been the case...)

Note that the whole reachability detection problem isn't as simple as it may seem at first, especially when we want to make use of unidirectional paths. Until not very long ago, I was favoring a "cartesian ping bomb" approach where there are reachability probes for all { src, dst } combinations. However, this can cause massive congestion when a link fails for a busy site, and it's also complex and most likely slow.

My current homework for the design team is to look how protocols such as OSPF and especially STUN implement similar features and see what we can borrow there. Unless this provides significant new insights I want so see if we can make a "be optimistic but check first" approach work. This means that when the reachability heuristics determine that there may be a path failure, we check the current path. If there is a failure, we check the next best path (for whatever "best" means locally) and so on, until we find one that works. In order to detect unidirectional reachability without excessive numbers of packets, each probe contains information about the last few multihoming signaling packets received from the other side. So unidirectional reachability won't be detected as fast as bidirectional reachability, but eventually it will.

I think we can probably tune this process such that significantly better (= lower RTT) paths are often discovered without any additional effort. This would be accomplished by having an artificially low timeout for the initial reachability test. (Successive ones should probably use an (exponential?) backoff.) So we send probe A->X and then 25 ms later B->Y. If the difference between RTT is bigger than 25 ms, the second probe will be answered first and we're in business. But if the RTT difference is smaller than 25 ms we'll still get a reply for the second probe after the reply for the first probe was received, as long as this one took longer than 25 ms. This works pretty well for a certain range of RTTs, only with very short ones we don't see better paths and with very long ones we send too many packets. If we can make the initial timeout a function of a previously established RTT we can probably get around this.

Another way to get around selecting a working, but non-optimal path is allowing applications to set an "impatient" flag which then triggers more extensive path evaluation. :-)