Subject: [mobile-ip] RA Solicitation Response Delay Performance Fatality

From: "James Kempf" <[email-masked]>
Date: Wed, 10 Apr 2002 13:04:40 -0700

This isn't security related, but I think it is something that *must* be
fixed before the MIPv6 goes to RFC.

Page 47 of RFC 2461 states that a router MUST delay a response to a RA
solicitation by a random number between 0 and MAX_RA_DELAY_TIME seconds.
This seems to have been put in to avoid flooding the local subnet with
responses when a bunch of hosts come up at once.

However, this is fatal for MIPv6 handover performance. Consider a
wireless link layer technology in which the MN gets a trigger when the
link comes up, and sends out a solicitation for RA in order to get a new
CoA. If the router abides by 2461, the handover will be delayed by some
random amount, delaying the MN getting its traffic.

Ideally, we could insert some text into the MIPv6 spec saying that this
behavior needs to be modified for routers that are handling wireless
links, but this would be somewhat counter to the trend in MIPv6 of
integrating MIP more tightly with standard IPv6 mechanisms.
Alternatively, we could do a separate draft that modified the text in
RFC 2461 to make the random delay behavior a SHOULD, or add rate
limiting behavior instead (i.e. make the random delay behavior be a
function of the incoming SolRA rate).

            jak

---

From: Brett Pentland <[email-masked]>
Date: Thu, 11 Apr 2002 11:22:23 +1100

Hi,

We have also been looking at MIPv6 handover performance where the new
network information needs to be discovered after the layer two handover has
taken place and this section 6.2.6 of RFC 2461 certainly seems to be a
stumbling block.

If, as James suggests, the point of delaying the RA is to avoid flooding
when a large number of hosts come up at once, then perhaps a flag could be
added to the RS that requests an immediate RA.  I guess it may be a bit late
in the day to go changing packet formats, however.

Can anyone say if this was the sole reason for the RA delay or were there
other design considerations that brought about its existance?

Regards,
Brett.

-- 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Brett Pentland                  [email-masked]
 CTIE - Centre for Telecommunications and Information Engineering
 Department  of  Electrical  and   Computer  Systems  Engineering
 PO   Box   35,   Monash   University,   VIC,   3800,   Australia
 Phone : +61 3 9905-5245                    Fax : +61 3 9905-5358
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Francis Dupont <[email-masked]>
Date: Thu, 11 Apr 2002 10:33:00 +0200

=> the explaination you give is for MAX_RTR_SOLICITATION_DELAY at page 56.
The idea behind MAX_RA_DELAY_TIME is if there are more than one router
on the link they will collide if they try to answer to the RS immediately.

   However, this is fatal for MIPv6 handover performance.

=> the whole idea to use RAs as beacons is fatal to many things, at least
(in good cases at choice) prefix discovery and handoff performances.

   Consider a
   
=> an elegant way to avoid the problem is to trigger the RA when the link
comes up. This is what happens with PPP and usually the first RA is sent
before the RS is received.

=> the real issue is the MIPv6 spec is not supposed to heavily change
the standard IPv6 mechanims, especially without the IPv6 WG agreement.

=> IMHO MIPv6 should not lead the neighbor discovery protocol away from
its role and should rely on layer two mechanisms when performances become
critical. And this should be dicussed in the IPv6 WG, not only here.

Thanks

[email-masked]

---

From: "James Kempf" <[email-masked]>
Date: Thu, 11 Apr 2002 08:52:33 -0700

Brett,

This was suggested to me by someone in private email. I think we could
quickly get a draft together and
send it through IPNG recommending this approach.

The issue is if we should have some text in the MIPv6 specification that
requires the MN to set the bit when it solicits. This will result in a
normative dependence on the draft about the bit, but, otherwise, the
point might be missed by implementors, resulting in poor performance.

            jak

----- Original Message -----
From: "Brett Pentland" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 10, 2002 5:22 PM
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance
Fatality

---

From: Brett Pentland <[email-masked]>
Date: Fri, 12 Apr 2002 11:37:15 +1100

Hi James, Francis,

> point might be missed by implementors, resulting in poor performance.

If a flag in the RS is the correct approach then yes, it would seem almost
essential to have some reference to the technique in the MIPv6 specification
for the reason you mentioned.  In another email, Francis mentioned a
technique of triggering an RA when an interface comes up.  If this is a
method of achieving the same result but without any change to the neighbour
discovery protocol, then it may be better.  Francis, perhaps you could
elaborate on how a mobile node's interface coming up on a network could be
made to trigger an RA from the router on that network without sending an RS
(or a very similar packet).

Regards,
Brett.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 19 Apr 2002 15:00:44 +0200

If a flag in the RS is the correct approach

=> I believe there is a better approach even for fast RS/RA (which is
not a good idea in the general case IMHO).

   In another email, Francis mentioned a technique of triggering an RA
   when an interface comes up.

=> your message suggested the MN sends a RS because the layer 2 detects
the arrival on a new link. My observation is that another entity can get
the same information and use it to trigger a RA.

   Francis, perhaps you could
   elaborate on how a mobile node's interface coming up on a network could be
   made to trigger an RA from the router on that network without sending an RS
   (or a very similar packet).
   
=> If another entity on the link detects the arrival of the new MN, it can
give the info to a router which can send a RA. The conditions are:
 - detection by another entity (works well for PPP, IEEE 802.11 in
   infrastructure mode, any layer 2 with some kind of association for
   network access control, etc)
 - some communication betwee the entity and a router (obvious if the entity
   is a router)
 - an arrival frequency low enough (delay between two arrivals far greater
   than MAX_RA_DELAY_TIME)

Thanks

---

From: "James Kempf" <[email-masked]>
Date: Fri, 19 Apr 2002 09:12:33 -0700

This will work as well. But not if the only trigger is on the mobile.

            jak

----- Original Message -----
From: "Francis Dupont" <[email-masked]>
To: "Brett Pentland" <[email-masked]>
Cc: "James Kempf" <[email-masked]>;
<[email-masked]>
Sent: Friday, April 19, 2002 6:00 AM
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance
Fatality

> In your previous mail you wrote:
>

---

From: Brett Pentland <[email-masked]>
Date: Mon, 22 Apr 2002 16:01:59 +1100

Thanks for your response; I hadn't really pursued that line of thought. In
any case, the method you describe requires significant infrastructure to
work.  I think that in cases where that infrastructure is not in place, if a
mobile node is aware that a layer two handover has occured then it is
desirable that it be able to perform a handover at layer three quickly.

Regards,
Brett.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 23 Apr 2002 11:59:51 +0200

work.

=> I don't believe this infrastructure is "significant" and (more important)
in many cases it is already there, for instance as soon as you have
common layer two "AAA" features. And don't forget easy cases like PPP.

   I think that in cases where that infrastructure is not in place, if a
   mobile node is aware that a layer two handover has occured then it is
   desirable that it be able to perform a handover at layer three quickly.
   
=> I'd like to know how "a mobile node is aware that a layer two
handover has occured"...

Thanks