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