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