Subject: RE: [mobile-ip] Connectathon 2003 issues for MIPv6 draft-20

From: Erik Nordmark <[email-masked]>
Date: Sun, 16 Mar 2003 19:37:39 +0100 (CET)

> When combined with the other mechanisms mentioned above, you could perhaps
> shorten the time needed to detect a L3 move down to approx. 10 seconds,
> perhaps less. In the case of using the Advertisement Interval, I'd think
> that you might even be able to skip the NUD PROBE state and after missing
> receiving some number of beacons in sequence from your current default
> router, immediately decide that the current default router is unreachable
> and solicit by sending a RS to find a new one, that could be even faster
> than 5 seconds (depending on how fast the beacons are being sent).

I think you can potentially do this faster if we think about the fast RS
space.

The idea is that there is a set of hints that can indicate that an L3 movement
has occurred. The hints can be some indication from L2, or
the receipt of an RA from a router that hasn't been heard before or
with a prefix option that hasn't been heard before.
Note that the hint itself doesn't indicate L3 movement.

The hint triggers the sending of a few RSs spaced per RFC 2461.
If the RS doesn't cause the receipt of an RA from the old router
(same source address) and with the old prefix option (different R-bit
router address) then movement has been detected.

Getting this to work really fast requires tweaking the rate limiting of
the RAs, but that is something that can be discussed as part of the
general IPv6 optimizations (wherever they will take place).

  Erik

---

From: Greg Daley <[email-masked]>
Date: Mon, 17 Mar 2003 12:33:28 +1100

G'Day Erik,

I like your idea.

I have some further comments though.

> router address) then movement has been detected.

If the L2 hints that a link may have changed then this is
a more reliable reason why you would believe an RA from
a previously unseen router.  This doesn't necessarily
entail RS/RA exchange with a new router, especially if the
new network undertakes the MIPv6 RA beaconing behaviour
(~50ms spacing), or network side L2 systems provide or
prompt an RA upon MN association.

These systems are significantly faster than current
RFC2461 based RS/RA.

FastRS/RA systems are an obvious step if
the MN receives link-up triggers, though.  The existing
proposal of FastRA (mkhalil et al) gives a good
first approach at tackling this issue, by removing RA
response delays.  We've used it in our lab to good effect.

It doesn't handle the issue of RS delay, which is highly
link-layer dependent.  The delays (also shared by DAD) seem
to be aimed at reducing multicast packet bombing on links
where many devices are configuring at once.
This can happen in MIPv6 if many devices move and transmit
simultaneously.

At this stage, our early 802.11b tests with 10 nodes
simultaneously transmitting multicast packets have shown few
problems (all packets received in <20 ms, little or no
packet loss).  This isn't particularly helpful if the number
of devices moving simultaneously exceed these values.
So we're focussing on MAC simulation, in order to
characterize behaviour in this area.

Also, we have been looking at ways to avoid simulteneous
movement (and thus RS delay) by performing random delays
before disconnecting from the previous link (Nick Moore's idea).
We're also looking at reducing the RS Delay time depending
on the link type.

I'm pretty sure though that on systems with logical
point-to-point channels for the MN (TDMA/CDMA), these delays
can be dispensed with completely.

Please note that the same issues still exist with DAD delay
especially when receiving multicast RA (lots of nodes detect
movement simultaneously, and configure addresses).  It may
be possible to treat the random delay period before the
DAD NS is sent as tentative in the same fashion as
Optimistic DAD.  This would extend the tentative period by up
to a second, while still allowing unicast NA's and packet
reception in the meantime.

> general IPv6 optimizations (wherever they will take place).

RA rate limiting is relatively straightforward, if
the MN has an address from which it can send the original
RS (FastRA).  I'm not sure that we'd want to significantly
reduce the interval between solicited Multicast RA messages,
which is the only available response if the RS comes from the
unspecified address.

Greg D.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Mar 2003 14:18:35 +0100 (CET)

> prompt an RA upon MN association.

If you know that the MNs can get a local trigger from L2 that they
might have moved, then there is no need to waste bandwidth by sending
RAs every 50ms. 
The frequent RAs help when there is no such local trigger.

And the frequent RAs don't guarantee that you've moved.
In somebody adds an additional router on the link
(or an additional existing router can reach the MN)
then it doesn't mean that the old router is no longer bidrectionally
reachable. An RS/RA exchange will indicate whether the old router is
still bidirectionally reachable.

> This can happen in MIPv6 if many devices move and transmit

It would be good to have some (experimental or simulation) data on this.
In practise how close together would a busload or trainload of operating
MNs get a movement hint (from L2 or from frequent RA beacons) when
they move as a unit from one link to another?
If they would all move within milliseconds I think it would be required
to have some randomization.

> characterize behaviour in this area.

Great that you are looking into this.

> which is the only available response if the RS comes from the

Good point.
I guess it depends on how accurate the movement hints are.
If a movement hint with high probability corresponds to an actual movement
there might not be much harm to send a multicast RA in response to an RS,
because each movement will already incur a few multicast messages
(MLD join of solicited node MC address(es), DAD, RS to find new routers).
But if 90% of the movement hints are false (e.g. due to frequent L2 going up
and down) then it would be a problem to incur additional multicast packets.
In that case a strategy that first performs a unicast RS/RA exchange with the
old default router(s) would make more sense.

  Erik

---

From: Greg Daley <[email-masked]>
Date: Tue, 18 Mar 2003 10:36:59 +1100

Hi Erik,

> The frequent RAs help when there is no such local trigger.

We've got experimental confirmation of this (for small
numbers of nodes on a lightly loaded net).  We had
almost identical results when using fastra,optidad, as
using fastra,beacons & optidad.

> still bidirectionally reachable.

I think that my position is changing slightly here.
I believe the conclusion which Ed and JinHyeock reached
earlier was like this. Since we've got to look at the
situation where L2 triggers aren't available on the MN,
this may be the required fallback case for beaconing
systems (Check old router with RS/RA, using beacon as a
hint).

> to have some randomization.

At this time, we've concentrated on the collapse case
where all nodes arrive together.  Current WLAN
drivers don't seem to have such predictable L2 handover
durations, but we're looking at MIPv6 in the context of
generic applicability too.

Previous discussion on the list has talked about
association serialization.  There has been some
belief that AAA mechanisms will allow nodes onto
a link one at a time. We'll certainly be looking
at this issue, to see if the RS contention issues
become less serious in that case.

> old default router(s) would make more sense.

I've just relied to James' post where there was
some discussion about accuracy of hints implying
subnet change.  I think that there may be a possibility
of choosing an RS policy on a per-interface basis
if this is an issue.

Certainly if certain link types have enough information
in hints to distinguish between types of handover (intra/
inter-subnet), then discriminated RS sending could be
available.  This is highly dependent on the particular L2
and network design though.

Greg D.

---

From: Brett Pentland <[email-masked]>
Date: Tue, 18 Mar 2003 16:17:49 +1100

> a previously unseen router.  This doesn't necessarily
<snip>

If FastRA is in use, then the RS/RA exchange might be able to give a
further indication of movement by taking note of the time taken to
receive an RA after sending an RS.  If an RA is received quickly, it is
likely that it is from a router configured for FastRA.  Since at most
one router on a link can send an immediate response, if the previous
solicited RA was also fast and the address prefix has changed it is
likely that movement has occured.

Brett.

---

From: Alper Yegin <[email-masked]>
Date: Mon, 17 Mar 2003 21:48:08 -0800

> one router on a link can send an immediate response, if the previous

I don't think this claim is true.

RFC2461:

      Upon receipt of a Router Solicitation, compute a random delay
      within the range 0 through MAX_RA_DELAY_TIME.

So, one of those RFC2461-compliant routers might end up sending
one quick RA if you are lucky..... Note that random delay starts from 0..

> likely that movement has occured.

alper

---

From: Brett Pentland <[email-masked]>
Date: Tue, 18 Mar 2003 17:02:14 +1100

> > likely that movement has occured.

You are quite correct.  If quickly means, say, "within 10ms", then there
is a 1 in 50 chance that an RFC-2461 compliant router will respond
"quickly".  I did say, however, that it was "likely" that movement has
occured.  This is just another indication of possible movement, like
receiving in "link-up" trigger from layer two, not concrete proof that
the layer three network has changed.

Cheers,
Brett.