[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 22-okt-04, at 16:09, Noel Chiappa wrote:

I wasn't aware that I'm so set in my ways that people can predict
whether I'll like something in advance...

It's not just you, almost *nobody* likes it! So I'm merely going with the
odds! :-) Although I admit you seem to not be afraid of offbeat ideas, so you
may well like it at a purely technical level. Although I predict you will be
daunted by the magnitude of the change... :-) 

Hm...

Well, basically, I think we need to move the "path selection" function
out of the "network" (i.e. the routers), and let the hosts (or, if they
are lazy/stupid, an agent acting on their behalf) do it. To do this, they
obviously need more information, which I claim should be maps of network
topology. 

Source routing, you mean?

As Marcelo explained, we are already on the path towards some very loose source routing (only the exit ISP) if we let hosts select source/destination address combinations and in the internal network there is source address based routing.

I have two standards points to make to people who roll their eyes at this
hopeless technological naivete, and say that it's "obviously" way too
complex a job to give to the hosts:

- Back in the 1970's, the "network" took care of flow/congestion control and
also reliability, and now hosts do all this - using some fairly complex
algorithms that took us decades to get working well. And having made that
fundamental architectural reorganization, it's now "obvious" to everyone that
that's the way it ought to be.

- This is the way we do cars and highways, and it seems to work just fine.

Well, based on these two arguments (especially the second) the natural progression here would be "source routering" where every packet contains the code to forward itself and routers are just big fat java virtual machines. :-)

I'm not really sold on the car analogy, but I agree that fear of complexity in hosts in unfounded. Typical hosts have tons more complex algorithms on board than typical routers. However, we do want hosts to be simple with regard to the amount of configuration information they must receive before they can go about their business: it's not a good idea to have to load a full BGP table or similar topology map before a host can communicate, or to have to upgrade all hosts in order to fix interdomain routing problems (of which we have plenty).

Anyway, making this (admittedly major) architectural change kills about
17 dozen birds, of which the "how do I pick the best address for the
destination" is one.

I doubt it. There is just too much information to be able to make optimal internet-wide routing decisions before the first packet is exchanged.

But that's not a big deal. If you have multiple paths, you can just add some multipath logic with per-path windows to TCP and the like and suddenly you're using all paths to capacity.

(I was involved with implementing something where real-time traffic was "anycast" over several TCP streams towards different destinations. (Don't ask why we used TCP.) We were supposed to spread traffic randomly over the different TCP sessions. This was a disaster as we were now limited by the slowest. But simply skipping the sessions that were blocked because of a full window allowed us to use the combined bandwidth of all sessions.)

And yes, I know this is a really, really, *really*, ***REALLY*** big
change. But, surprisingly, when you start working through the details,
there are ways to incrementally deploy it, ways which don't mandate
changes to all hosts before it can begin to be useful.

Well, we're incrementing things now for multihoming support so this might be a good time to get some of this stuff in...