Re: IP network address assignments/allocations information?

[Keith Moore <moore at cs.utk.edu>]

> > if multiple addresses are available for a host, the chances are good 
> > that the paths associated with some of those addresses are significantly
> > better, or worse, than others.  with IPv4 multihoming, the routing system 
> > sorts out which path to use.  this doesn't work perfectly but at least 
> > the decision is made in light of some information about the nature and 
> > current state of those paths.  with IPv6 multihoming, the sending host is 
> > just guessing.  it's difficult to believe that this will work well.
> 
> That's why you add some feedback-based smarts to the address-order
> selection scheme, and overlap the connection attempts (perhaps
> separating them by an RTT or so).  

given TCP's inability to do congestion-sensitive backoff during
connection establishment, I'm not so sure that increasing the number
of concurrent connection attempts is a good idea.

> Given typical distributed apps,
> feedback selection based on end-to-end latency will be the right
> answer in almost all cases; bandwidth-based feedback can also
> potentially be done.

in my experience with automatic selection of ftp mirrors based
on latency estimtes, the selection of the server with the apparent
lowest latency was often a good one (i.e. significantly better than 
a random selection) but rarely was that selection the optimal one, 
and it certainly didn't work well "in almost all cases".  
in a significant number of cases (~10%) the choice was 
very pessimal, the variability of time to load a web page
over ftp *increased* when mirror selection was used,
and the users we tried this out on were often less satisified 
with the results than with a browser that just used the ftp server 
in the URL.  so I doubt that latency alone is a good metric
for server selection.  latency over a highly-loaded path is highly 
variable, and packet loss rates have a significant effect on how much
bandwidth you get out of TCP.  (to be fair, variations in load
between different servers were also a factor in our experiments, 
which would presumably not be the case for a single server host 
with multiple addresses)


> Given how hard it is to get an ISP do to anything special for you
> these days, I really can't see a routing-system-based multihoming
> actually scale down to, say, individual SOHO networks being
> multihomed, while multiple-address-based multihoming doesn't require
> anything special out of the ISP's..

no, I can't see how a routing-system-based multihoming
will scale down to SOHO networks either.  but neither do I 
think that DNS based multihoming will work well, at least,
not without developing a lot more infrastructure than is
even on the drawing board at present.  and making this work 
well in practice is at least a few years away.  

Keith