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

Re: IETF multihoming powder: just add IPv6 and stir



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.