Subject: [mobile-ip] FW: Changing RS Reply Timing for Mobile IPv6

From: "Mohamed Khalil" <[email-masked]>
Date: Tue, 8 Oct 2002 11:40:30 -0500

FYI

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Tuesday, October 08, 2002 11:29 AM
To: [email-masked]
Subject: Changing RS Reply Timing for Mobile IPv6

Mohamad Khalil, Brett Pentland, and I just submitted a draft on modifying
the RS reply timing:

http://www.ietf.org/internet-drafts/draft-mkhalil-ipv6-fastra-02.txt

I didn't see an announcement from the drafts editor in this group.

In summary, the draft amends RFC 2461 to allow at most one router on a link
to reply immediately to an RS instead of waiting a random amount of time
between 0 and MAX_RA_DELAY_TIME. The router is allowed to reply to at most
MAX_FAST_RAS since the last unsolicited multicast is sent. If this number is
exceeded, the router rolls over to scheduling a multicast RA as soon as
possible. This is intended to avoid DoS attacks on the router.

We believe this amendment will be necessary for achieving good handover
performance with standard Mobile IPv6 movement detection. If the mobile node
is capable of detecting when the link changes, it can immediately send an RS
rather than wait for a multicast RA. This can significantly decrease the
amount of time required for movement detection. In addition to theoretical
considerations, we have some amount of implementation experience with the
existing movement detection algorithm to suggest that the RS reply protocol
in RFC 2461 could have moderate to severe performance limiting effects on
standard MIPv6 handover.

We would like to have review and discussion of this draft prior to the WG
meeting in Atlanta, and finish up the discussion there, with a goal of
making this a WG document. The Mobile IP working group will be finishing up
the MIPv6 draft soon, and we would like to be able to publish this draft in
about the same time frame, so implementors have some guidance.

                    jak

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Tue, 8 Oct 2002 11:07:56 -0700

As a followup, I'm wondering if we should put a reference to this document into
the MIPv6 spec? Implementors need to be made aware of it, since we've found that
the performance consequences of not having it can be pretty severe. If all goes
well, we hope to advance this spec in IPv6 WG quickly, so it should be ready by
the time MIPv6 gets to RFC (which will hopefully be soon). Alternatively, we
could put it into the nonnormative references, but I think it is important that
an RFC number be there so implementors can trace the reference.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 08 Oct 2002 11:39:36 -0700

I think not. I see Mobile IPv6 as a base protocl spec + a 
bunch of drafts talking about optimizations/implemenation 
considerations (for eg. HA-MN IPsec details, your fast RA 
draft, piggybacking, SPI, CGA and so on....).

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Tue, 8 Oct 2002 15:44:32 -0700

Vijay,

I guess I see a difference between CGA, fast handover, SPI, etc. and HA-MN IPsec
and this fast RA draft.

I think the CGA,etc. drafts are extra, whereas I think the HA-MN IPsec and fast
RA draft are really required for the base protocol to work well. I could see the
HA-MN IPsec draft being a BCP, for example, that is necessary for people to
understand proper deployment. So I think references to them should be included,
and I would go so far as to say they should be normative.

If there is some other way to make sure that references to the drafts required
to properly implement and deploy MIPv6 are referenced from one place, that would
work as well.

            jak

----- Original Message -----
From: "Vijay Devarapalli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Mohamed Khalil" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, October 08, 2002 11:39 AM
Subject: Re: [mobile-ip] FW: Changing RS Reply Timing for Mobile IPv6

---

From: Greg Daley <[email-masked]>
Date: Wed, 09 Oct 2002 09:24:15 +1000

Hi James,

We can possibly handle this in an informational RFC
about how to implement mobile-ip6 access networks
effectively.

If there is no additional signalling for fastra
then I don't think that mobile IPv6 client
implementors have to be aware of its existence.

I've seen the difference which Fast RA makes to L3 handover
performance, and I don't think that it is any less
important if we don't reference it from the base MIPv6
specification.

Greg Daley

James Kempf wrote:
>>>As a followup, I'm wondering if we should put a reference to this document
>>
> into
> 
>>>the MIPv6 spec? Implementors need to be made aware of it, since we've found
>>
> that
> 
>>>the performance consequences of not having it can be pretty severe. If all
>>
> goes
> 
>>>well, we hope to advance this spec in IPv6 WG quickly, so it should be ready
>>
> by
> 
>>>could put it into the nonnormative references, but I think it is important
>>
> that
> 
>>>>In summary, the draft amends RFC 2461 to allow at most one router on a
>>>
> link
> 
>>>>MAX_FAST_RAS since the last unsolicited multicast is sent. If this number
>>>
> is
> 
>>>>performance with standard Mobile IPv6 movement detection. If the mobile
>>>
> node
> 
>>>>is capable of detecting when the link changes, it can immediately send an
>>>
> RS
> 
>>>>existing movement detection algorithm to suggest that the RS reply
>>>
> protocol
> 
>>>>making this a WG document. The Mobile IP working group will be finishing
>>>
> up
> 
>>>>the MIPv6 draft soon, and we would like to be able to publish this draft
>>>
> in
>

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 9 Oct 2002 17:47:28 +0900

FW: Changing RS Reply Timing for Mobile IPv6Hi

James Kempf wrote

> If the mobile node is
> capable of detecting when the link changes, it can immediately send an RS rather
> than wait for a multicast RA.

According to RFC 2461, mobile host should not send RS immediately. Before sending 
RS, it should execute random delay like below. 

"Before a host sends an initial solicitation, it SHOULD delay the
transmission for a random amount of time between 0 and
MAX_RTR_SOLICITATION_DELAY.  This serves to alleviate congestion when
many hosts start up on a link at the same time, such as might happen
after recovery from a power failure."

Are you suggesting that above term should be loosened too? I wonder whether it is 
good idea to change current Neighbor Discovery protocol that much. I am afraid there 
may be side effect like RA overabundance.

Most people will agree that Movement Detection mechanism should be improved. It 
takes too much time for mobile node to detect link-change under current Neighbor 
Discovery protocol.

Hence we need to consider the following 2 items.

1) How to improve Movement Detection Algorithm?
2) How to incorporate the result of 1) to current Mobile IPv6 work?

For 2), MIPv6 implementators should be provided of the results of 1). It will be useful 
to produce an informative draft and make implementators aware of it.

For 1), I think more discussion is needed. And I have proposed an alternative method. 
In the proposal, AP caches Router Advertisement message and sends it to a new 
mobile node as soon as L2 association is made. You can find more details in below.

http://www.ietf.org/internet-drafts/draft-jinchoi-l2trigger-fastrd-01.txt