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

From: <[email-masked]>
Date: Mon, 25 Oct 2004 08:54:33 +0300

Jari,

> > 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.
> 
> I agree that we have some remaining issues. To give you
> another example, switching from a 50 Mbps LAN to a 20 Kbps
> GRPS might be needed when the LAN goes down at some point.
> However, what do we do when the LAN comes back up again later?
> The slower interface still works, so there's no need to do
> failover. But you'd really want to switch...

Let's take the corner case of 50 Kbps GRPS vs 200 Kbps WLAN
behind DSL.  You might prefer the WLAN connection, but the GPRS
might be more stable.  I think you also want to avoid ping-ponging
between the interfaces as well, so being prudent here is an
important issue.

> > 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...)
> 
> Hmm... I guess the issue is whether either end knows. I'm not
> sure the assumption that you know/test what the L2 does is any better
> than the assumption that you know/test what the core does.
> 
> I'm not really afraid of testing the speed of a path, but what
> I am afraid is the interaction with ULPs. We really don't want
> Multi6 and TCP and whatnot testing all the same thing and second
> guessing each other.

Exactly.
 
> > 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.
> 
> Yes. In http://www.arkko.com/publications/multi6/faildet.html#anchor9
> we did the math, and with the quite reasonable assumption of exponential
> back-off, testing all combinations of addresses with just four addresses
> on each side would last 3200 seconds.

So, I should read your draft (on my reading pile) but are there simplifying
assumptions? If we look at site multihoming, we might not need to test
all addresses.  For example, in a VPN case, there might only be a handful
of VPN gateways.  Instead of testing all of the destination addresses,
we might need just to test the different VPN gateways.  Additional
constraints are probably possible based upon site configuration.

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

You might want to consult ICE:

 Interactive Connectivity Establishment (ICE): A Methodology for
 Network Address Translator (NAT) Traversal for Multimedia Session
 Establishment Protocols

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-02.txt

> > 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.  :-)
> 
> Do you mean the "I am in a hurry, screw the others if this
> causes congestion" -flag? ;-)
> 
> I fear that the things that we want to do would really require
> better good knowledge of the current RTTs of the paths. This
> can be measured, but there's a tradeoff in how far we want
> to venture in the territory of TCP vs. how good our information
> is.

Agreed.  I think if we go down this route, it would be very important
to engage TSVWG types into the discussion.  TCP has a very conservative
approach to this.  TCP Quick Start is an interesting algorithm that
might be applicable here:

http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt

Finally, a big issue is also L2 Indications.  I think that we might
be able to assist any multihoming if we consider L2 indicators. Lots
of work has been done in the transport area about l2 indicators.  A
good summary can be found here:

http://www.ietf.org/internet-drafts/draft-iab-link-indications-00.txt

John

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Oct 2004 11:41:51 +0300

Hi John,

> between the interfaces as well, so being prudent here is an

Right. So that's why the approach taken in my draft
is "failover only". I'm just pointing out its limitations
in terms of user observable behavior. But just because I
point out a limitation doesn't necessarily mean that
I'm suggesting we go and fix it, because the solution
might not be available or would be complex.

> constraints are probably possible based upon site configuration.

I agree, but I was thinking about this one layer lower down.
If you have VPN gateways or something else, you still have a
set of addresses at both ends.

I guess what I'm saying is that there are some fundamental-looking
limits to what we can achieve. Basically, 2-3 addresses at both
ends seems to be the practical limit; anything beyond that isn't
easily explorable.

(And then an advertisement from your MOBIKE co-chair: I suspect the
VPN example is not very good one for MULTi6 because MOBIKE protocols
will do that pretty well -- including support for NATs in between
and mixed IPv4/IPv6.)

>  Network Address Translator (NAT) Traversal for Multimedia Session

Thanks for the pointer. I'm aware of STUN and ICE but need
to study them in more detail...

> http://www.ietf.org/internet-drafts/draft-amit-quick-start-03.txt

Thanks for this pointer too!

> http://www.ietf.org/internet-drafts/draft-iab-link-indications-00.txt

Yes. My failure detection draft has a couple of abstractions that
deal with "lower layer" (under MULTI6) issues, such as
- availability of an address (RA/DAD/DHCP all done)
- operational status of an address (router NUD, L2 info etc)

But there isn't a lot of details about link layer indications
beyond this. I guess one of the decisions that affects this
is whether we deal with on/off type of information or we want
to take bandwidth and issues into account too.

--Jari