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

From: Erik Nordmark <[email-masked]>
Date: Wed, 17 Apr 2002 04:50:13 +0200 (CEST)

> 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: Wed, 17 Apr 2002 09:58:38 -0700

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

---

From: "Youn-Hee Han" <[email-masked]>
Date: Thu, 18 Apr 2002 15:21:08 +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)

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 18 Apr 2002 14:56:19 -0700

Hello Jim,

I see your need, but I am a little concerned about the increase in
RAs and the associated overhead.. There is also the potential for abuse
as you mention. Shouldn't a MN interested in faster
address acquisition use something like FMIPv6 ?

Regards,

-Rajeev

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 19 Apr 2002 03:55:44 +0200 (CEST)

> to IPNG this week. It is very short (4 pages I think).

Good.

> The draft adds a

And what should the router do when it receives 100 RSs within one second
all with the bit set?

With this approach there is a danger that all implementation, whether mobile
or not, set the "I want a fast response" bit you propose.
Thus I think the routers need to rate limit in any case.
But we can argue this on the IPv6 list :-)

> Mobile IPv6 spec to it, so that implementors of Mobile IPv6 are

Seems like a useful discussion for IPv6 node requirements at some point in
time.

  Erik

---

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

=> I disagree with the reasonning because it uses the assumption there is
only one router: if RAs are immediately sent (unicasted or multicasted,
this doesn't matter) at the reception of a multicasted RS, then they will
collide. So I agree the bit approach is not good, but the right approach
(to unicast the RS) has some difficulties...
(PS: I can't see a better alternative to trigger though the link layer a RA)

Regards

[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 Apr 2002 07:13:46 -0700 (PDT)

> address acquisition use something like FMIPv6 ?

Rajeev,

This assumes that the AR supports and offers
FMIPv6. I don't see that as the case always,
especially with open kiosk kinds of situations.
IMO, it should be possible for a mobile node
reasonably close to its home agent to dispense
with all of the heavy machinery (and dependencies)
and achieve reasonable results. The couple of
seconds of delay here (as well as DAD) doesn't
strike me as striking a very good balance.

	   Mike

---

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

Sure. But FMIPv6 isn't part of the base spec, and I think the base spec
should implementable in a way that gives good performance.

            jak

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>;
<[email-masked]>
Sent: Thursday, April 18, 2002 2:56 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
> > > I'd prefer this being done as a short separate draft since this
makes
> > it
> > > > Ideally, we could insert some text into the MIPv6 spec saying
that
> > this
> > > > Alternatively, we could do a separate draft that modified the
text
> > in
> > > Pre-RFC versions of neighbor discovery had a the ability (if my
memory
> > serves
> > > 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

---

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

> But we can argue this on the IPv6 list :-)

Sure. But that's true of any mechanism that requires node co-operation
to relieve congestion, like TCP backoff.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 19 Apr 2002 17:38:08 -0700

Hello Mike,

> strike me as striking a very good balance.

If the address acquisition is due to roaming, then
the delay is tolerable. If it is due to handover, I
agree that FMIPv6 may not be available
everywhere. But, I am still concerned about the
increase in RA overhead.

A tweak that might dampen the load is to consider
multicasting solicited RA to all-nodes so that
the solicitations are reduced. Each node should
wait for a short time (say few tens of milliseconds)
before sending an RS.
This may have been discussed in IPv6 with a No :-)

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Sat, 20 Apr 2002 10:23:33 -0700

Rajeev,

In general, I think we want to reduce or eliminate multicasting of
unsolicited RAs on wireless links when possible. This even holds for
wireless links with large aggregate bandwidth, like WLAN. I have
recently seen some simulation results (currently unpublished) in NS2
which show that in heavily loaded WLAN cells, the RAs tend to get
delayed or dropped due to link contention, resulting in long delays in
handover time.

            jak

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: "Michael Thomas" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; "Erik Nordmark"
<[email-masked]>; <[email-masked]>
Sent: Friday, April 19, 2002 5:38 PM
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance
Fatality

---

From: Greg Daley <[email-masked]>
Date: Mon, 22 Apr 2002 08:50:34 +1000

Hi Francis,

> (PS: I can't see a better alternative to trigger though the link layer a RA)

It would be straightforward to ensure that only one
router on any link is using the 'Fast Response' bit.
This would guarantee that the fastest reply available 
is achieved, with appropriate backup capability (i.e.
current rfc2461, in the case where failure occurs).

Greg Daley

---

From: Brett Pentland <[email-masked]>
Date: Mon, 22 Apr 2002 19:05:33 +1100

> (PS: I can't see a better alternative to trigger though the link layer a RA)

A good point.  Perhaps a small delay is still required to prevent collisions
(unless implementation of small random delays is too tricky) or possibly
better still, if sending fast responses was made configurable then it could
be enabled only on access routers where faster handovers are desirable and
then only on one router on any given link.

Regards,
Brett.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 22 Apr 2002 09:28:40 -0700

I think one could say that only one router on the link should respond
this way. The others should be configured to delay.

            jak

----- Original Message -----
From: "Brett Pentland" <[email-masked]>
To: "Francis Dupont" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>; "James Kempf"
<[email-masked]>; <[email-masked]>
Sent: Monday, April 22, 2002 1:05 AM
Subject: Re: [mobile-ip] RA Solicitation Response Delay Performance
Fatality

> >    > Ideally, we could insert some text into the MIPv6 spec saying
that this
> >    > Alternatively, we could do a separate draft that modified the
text in
> >    Pre-RFC versions of neighbor discovery had a the ability (if my
memory serves
> >    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

---

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

=> I am not convinced this would be so "straightforward":
 - this assumption defeats the goal to have several available routers
 - if a router is by some ways made "special" why not to allow it
   to answer to NSs without delay? (in this case the FR bit is
   simply useless).
To come back to Erik's comment, I agree there is a good solution
in ND itself which keeps to original RFC 2461 goals...

Regards