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

From: "Youn-Hee Han" <[email-masked]>
Date: Thu, 18 Apr 2002 19:52:17 +0900

I would like to point out another stumbling block in RFC 2461, in order to 
achive good MIPv6 handoff performance.

Page 55 of RFC 2461 states the followings.

   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.  If a host has already performed
   a random delay since the interface became (re)enabled (e.g., as part
   of Duplicate Address Detection [ADDRCONF]) there is no need to delay
   again before sending the first Router Solicitation message.

The above block states the case for an MN sending an RS before receiving an RA.
When an MN moves and re-attaches to a new link,  transmittion an RS prior to 
receving an RA is good behavior for reducing L3 handoff times.
However, the delaying by some random amount evidently becomes an obstacle 
for L3 handoff performance. Although the random delay behavior is a SHOULD, 
there should be some kind of reference in the Mobile IPv6 spec to it

Page 55 of RFC 2461 also states the followings.

   Moreover, a host SHOULD send at least one solicitation in the case where an
   advertisement is received prior to having sent a solicitation.
   Unsolicited Router Advertisements may be incomplete (see Section
   6.2.3); solicited advertisements are expected to contain complete
   information.

In order to require complete new link information, the above block states 
an MN SHOULD send an RS, although it receives an unsolicited RA prior to sending an RS.
I am worried that the BUs for new COA must be sent to HA and CN only after 
receiving a solicited RA. Such behavior is also an obstacle for L3 handoff performance.
Although such behavior is a SHOULD, there should be some kind of reference 
in the Mobile IPv6 spec to it, too.

Youn-Hee Han,
Samsung Advanced Institute of Technology (SAIT)

----- Original Message ----- 
From: "James Kempf" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 18, 2002 1:58 AM
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance Fatality

> Erik,
> 
> We're preparing a separate draft for this, which I think we will submit
> to IPNG this week. It is very short (4 pages I think). The draft adds a
> bit to the RS saying that the host would like an immediate response. Of
> course, hosts can cheat and send it even if they aren't doing MIP
> handover, but if everybody plays the rules the congestion control should
> work, like TCP.
> 
> The other issue is whether there should be some kind of reference in the
> Mobile IPv6 spec to it, so that implementors of Mobile IPv6 are
> recommended to use it.
> 
>             jak
> 
> ----- Original Message -----
> From: "Erik Nordmark" <[email-masked]>
> To: "James Kempf" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, April 16, 2002 7:50 PM
> Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance
> Fatality
> 
> 
> > > This isn't security related, but I think it is something that *must*
> be
> > > fixed before the MIPv6 goes to RFC.
> >
> > I think it is sufficient "before MIPv6+IPv6+... can be deployed" -
> > while the issue is important I don't see why it needs to hold up
> > the MIPv6 specification.
> >
> > I'd prefer this being done as a short separate draft since this makes
> it
> > easier to fold it into RFC 2461 at a later time.
> >
> > > 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).
> >
> > Pre-RFC versions of neighbor discovery had a the ability (if my memory
> serves
> > me) for routers to immediately unicast a RA in response to a RS, but
> > randomly delay and rate limit any multicast RAs send it response to
> RSs.
> >
> > Having a mechanisms to select between an immediate unicast response
> and
> > a delayed multicast response seemed not worth the effort at the time,
> but
> > that is an avenue that can be explored now.
> > For instance, if the last RS was received less than 3 seconds ago
> > the router could do the randomly delayed multicast RA; otherwise
> > an immediate unicast RA.
> >
> >   Erik
> >
> >
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 19 Apr 2002 08:37:16 -0700

Youn-Hee,

Good points. I think there needs to be something in the spec which says
that an MN shouldn't wait to solicit, and that an AR should send
complete information if possible (RAs are limited to PMTU size).

            jak

----- Original Message -----
From: "Youn-Hee Han" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, April 18, 2002 3:52 AM
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance
Fatality

Fatality