[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Move forward



On Wed, 12 Mar 2003, Marcelo Bagnulo wrote:

> We have tried to evaluate a concrete proposal for multi-homing using
> MIPv6 tools. The result can be found:

> http://www.ietf.org/internet-drafts/draft-bagnulo-multi6-mnm-00.txt

> We would really appreciate your comments,

Ok, some comments:

- It looks like you want to authenticate the secondary address
  beforehand when there is still return routability. But can you then
  simply keep the secndary address in some kind of "hot standby" state
  untill it is time to start using it and then use it for some
  considerable amount of time without re-authentication? Does this work
  and is it secure? Oh wait: "This is a major limitation for this
  application, since the binding can not be refreshed until the original
  route is restored and outages can last longer than 420 seconds."

- ICMP echo for keepalive wouldn't work. Not so much because of all the
  broken firewalls that block them, but because the only thing an echo
  reply tells you is that there is _someone_ present at the address, it
  doesn't tell you who it is. (Ie dial user may have logged out and
  another logged in and gotten the same address.)

- Why don't you look at the return traffic to see if the path is still
  viable? If you keep (re)sending data but there is no reply from the
  other side, something must be broken. This probably needs per-session
  state, though.

- "If a failure   has occurred along the path, the attempt to initiate
  the communication will fail and the CN will try again with another
  address. Eventually, a packet from CN will reach MHH." As this is
  application-dependent you can't count on this. Worse: the all-time
  most popular networked application typically chokes if the first address
  tried doesn't work.

- Having to interact every 70 seconds may break sessions that would
  otherwise remain intact. For instance, I often put my laptop to sleep
  in the middle of a session to conserve the battery. When it wakes up,
  my session is still ok because there was no communication during the
  nap so the fact that my laptop was effecitvely disconnected didn't
  matter. So lack of a HoT my not be an outage but simply saving
  energy...

This is excellent work. It shows multihoming in IPv6 is just around the
corner, and not impossible as some people seem to believe.

However, I do see a problem: as this solution isn't well suited to
medium-sized and larger sites, and provides no compatibility with other
solutions that do cater to larger sites, implementing this as-is may not
bring as much benefit as we hope. After all, the majority of all
communication is with at least one non-small site. And I don't think
Google or some other huge site really wants to start doing MIP as a
mattoer of course on all those 200 msec TCP sessions just because the
other side is multihomed.

So what I'd like to see is compatibility with one or more solutions that
are more suited for larger sites. But I guess the first thing we need
for that is one or more solutions that are ore suited for larger sites.  :-)

Iljitsch