Re: IETF multihoming powder: just add IPv6 and stir

[Iljitsch van Beijnum <iljitsch@muada.com>]

On zondag, mei 4, 2003, at 02:13 Europe/Amsterdam, Tony Li wrote:

> |    > To be sure I understand, you are saying that my laptop
> |    > should have the ability to make a decision as to what
> |    > ISP Microsoft uses to route packets back to me?
> |    Just because that's the way it's done today doesn't mean it has to
> |    continue to be done like that in the future.
> If you follow this argument a bit further, the number of possible
> paths internal to the core explodes.  There is no way to completely
> specify the path of a packet without a connection oriented setup
> protocol.
It was not my intention to suggest we start building X.25 networks. 
Even if we define a path as a combination of source ISP and destination 
ISP, the number of possible paths quickly increases with the number of 
ISPs used by both ends. I don't think it would be all that useful to 
differentiate between different paths through the core for a single 
source/dest combination: traditional mechanisms work well here.

> Frankly, there's no way to reasonably support a host path selection
> feature in the Internet architecture.
Having hosts select paths through the core would be a solution in 
search of a problem. Having hosts select the optimum combination of 
source and destination addresses = source and destination ISPs would be 
a useful feature, if not one that is trivial to implement.

Today, we don't have this feature, but we depend on routing to select a 
single path that is good enough. If it isn't, BGP provides a good 
number of knobs to manually influence this. As soon as we start giving 
hosts multiple addresses we open the door to all kinds of suboptimal 
and even pathalogical behavior. The current rules for source address 
selection only make this worse because in an attempt to do the right 
thing, they may succeed in consistently doing the wrong thing, rather 
than just doing the wrong thing once or twice and then try something 
else. (Side note: I had to go back to a single IPv6 prefix after 
experimenting with having two because there was no way I could make my 
hosts use the right source addresses.)

For long-lived sessions, it would be appropriate to go through a 
somewhat lengthy discovery process where different source/dest 
combinations are tried and eventually the best combination is adopted. 
(But this should happen "in the background" while communication is 
already happening.) For more ephemeral sessions or sessions that can't 
switch addresses, it is very important to select a good enough path: it 
doesn't have to be the best, as long as it's not the worst. I'm afraid 
there is no way to accomplish this without prior knowledge. It might 
seem like a good idea to import routing information for this purpose 
but that doesn't help much because this only deals with aggregates. I 
don't think we can get around this problem without incorporating a 
discovery phase where a host tries something to see if it works. 
Fortunately, for the source address, where this problem is most 
pressing, we should be able to use ICMP messages to quickly determine 
that something doesn't work. (Use source address in prefix A but router 
wants to send the packet to ISP B -> ICMP administratively prohibited 
within a few ms.) For the destination address, it might be workable to 
used send a connection request to several addresses and complete the 
session setup with the address that replies quickest.