[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: The state of IPv6 multihoming development
On Sun, 27 Oct 2002, Michel Py wrote:
> Here's the scenario: the home/soho host that is multihomed with cable
> and dsl makes a choice on which of its own addresses (the cable one, or
> the dsl one) to use. This choice will dictate on which pipe the return
> traffic from the web server to the requesting host goes.
Actually it doesn't, twice.
First of all, in order to really be multihomed, both addresses must be
viable. So if the HTTP farm decides to direct its traffic to the other
address, Joe can't really stop them, other than not advertise this
address in the first place.
Also, presumably, both of Joe's addresses are reachable over both of the
HTTP farm's uplinks. If the HTTP farm is smart enough to be able to
direct outgoing traffic depening on the traffic engineering needs rather
than simply the destination address, they can route each of Joe's
addresses over either of their uplinks as desired. And even if they
don't have this capability, it's still 50% chance that both of Joe's
addresses are routed over the same uplink so which address they use to
reach Joe doesn't matter for traffic engineering purposes.
> This is what we really are talking about here: Joe-six-pack's PC thinks
> the ping to the cable default gateway is better than the ping to the dsl
> default gateway and chooses its own source address to be the cable's
> one.
> And this, gentlemen, is *not* what I call traffic engineering.
So what's your definition?
The Right Thing for Joe's PC would be to measure the end-to-end delay,
packet loss and bandwidth over both links and use the one that best
suits his application. However, this is complex enough to NOT solve this
at this stage. We may want to provide some hooks so people can do this
later, though.