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

Hi John,

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

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.

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

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

> You might want to consult ICE:
> 
>  Interactive Connectivity Establishment (ICE): A Methodology for
>  Network Address Translator (NAT) Traversal for Multimedia Session
>  Establishment Protocols

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

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

Thanks for this pointer too!

> 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

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