Subject: [mobile-ip] 50 ms RA timer?

From: "James Kempf" <[email-masked]>
Date: Fri, 22 Nov 2002 05:23:29 -0800

So it seemed like a lot of people supported the 50 ms timer option at the Mobile
IP meeting on Tues. I'm curious exactly what wireless MAC people had in mind for
this.

For 802.11, I think the minimum frame size is something like 460 bytes (but I
couldn't find this in the spec, so I might be mistaken). At 50 ms per RA, this
comes out to about 73.6 kbps. For 802.11b, that's about 9% of the aggregate
bandwidth, assuming 8 Mbps of available aggregate bandwidth, which is typical,
given interference and other effects. In a similar situation, Novell's SAP
typically consumed that much on wired networks and it was considered to be a
severe problem by sysadmins.

For 802.11a, the consumed bandwidth isn't so bad (about 1% assuming 42 Mbps
aggregate), but even there, the RAs will get spaced out by CSMA/CA as the cell
becomes more congested, because they won't be scheduled for transmission at any
higher priority than the data traffic. So, ultimately, they won't be received at
50 ms intervals, unless the PCF is used instead of DCF, but there are only a few
cards that implement PCF and fewer access points.

For cellular, the situation is even more problematic. I recall several years ago
3GPP2 requested IETF to look into the problem of eliminating periodic FA
beaconing for Mobile IPv4 entirely. Unless the RAs are sent over one of the
cellular signaling channels, I don't think operators will want to use licensed
spectrum for this purpose. Modifying the 3GPP and 3GPP2 specs to send IP
signaling over the cellular signaling channels would be a good thing, but I
don't think it is currently on the 3Gs roadmap.

With Bluetooth, the time required to come up into a new scatternet is around 3
sec., so 50 ms RA timers won't help.

Can somebody who was in favor of the 50 ms RA option explain what MAC they had
in mind for this?

                    jak

---

From: "Richard Nelson" <[email-masked]>
Date: Sun, 24 Nov 2002 18:27:03 +1100

James,

I prefer L2 triggers to frequent RAs, but....

The way the RAs are specified in RFC2461, the interval between them is a
uniformly distributed random variable between MinRtrAdvInterval and
MaxRtrAdvInterval.  The 50ms recommendation for MinRtrAdvInterval  is
accompanied by a MaxRtrAdvInterval of 1.5 sec so the mean interval is
775msec.    This probably wouldn't overload most L2 technologies.

Richard.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Nov 2002 12:49:10 -0800

Richard,

Then perhaps someone could explain why the 50 ms timer is needs to be specified
in the base draft? 775 ms is simply insufficient to provide any handover
acceleration.

To me, this argues for taking a more comprehensive approach to specifying ND
changes, rather than trying to do them piecemeal.

            jak

---

From: Thomas Narten <[email-masked]>
Date: Mon, 25 Nov 2002 16:44:29 -0500

> 775msec.    This probably wouldn't overload most L2 technologies.

If the above is the rational for lowering the Min value, it seems like
the overall algorithm of a uniform random interval between Min and Max
is just plain broken for the application at hand.

I.e, it sounds like what is needed is beaconing at close to fixed
intervals, with maybe a little bit of randomness/jitter to prevent
synchronization of RAs. Having the interval be between 50ms and 1.5
seconds seems the wrong way to get "an average" beacon interval of .75
seconds.

If .75 is the goal, then make the advertisments be every .75 seconds
and add a bit of jitter.

The above again leads me to think that this work really needs a bit
more review/thought in order to be sure it solves the underlying
problem well.

Thomas

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 25 Nov 2002 13:58:47 -0800

Hello Thomas,

> If .75 is the goal, then make the advertisments be every .75 seconds

The goal was to allow advertisements every 50ms.  I don't remember
anyone every crusading for an advertisement interval of the general
magnitude of .75 seconds.

> more review/thought in order to be sure it solves the underlying

Having advertisements every 50ms is known to produce good results
in many circumstances.

I don't think anyone is saying that it's the only solution.
I reckon that a larger effort would be welcome, especially if
better solutions result.  However, in the meantime I reckon we
need to have at least the capability for having frequent advertisements.

Regards,
Charlie P.

---

From: Thomas Narten <[email-masked]>
Date: Mon, 25 Nov 2002 17:06:34 -0500

> magnitude of .75 seconds.

Actually, the current suggested wording in the MIPv6 spec doesn't seem
to achieve your goal. Please re-read the previous posting in this
thread, in which:

> 775msec.    This probably wouldn't overload most L2 technologies.

The above matches my understanding of what 2461 says.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Mon, 25 Nov 2002 17:02:50 -0500

> magnitude of .75 seconds.

OK. But then, jak's original  question still has not been answered. I'm
also curious.

"James Kempf" <[email-masked]> writes:

> Can somebody who was in favor of the 50 ms RA option explain what
> MAC they had in mind for this?

Thomas

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 25 Nov 2002 16:04:04 -0800

actually, there is something wrong. and I think I can explain
it. I always set the MaxRtrAdvInterval as 3 times the 
MinRtrAdvInterval. thats what RFC 2461 recommends. I first 
determine what the average should be and then set the min and 
max accordingly. 

Section 7.5 in MIPv6 is wrong. It should recommend a value
for either the MinRtrAdvInterval or the MaxRtrAdvInterval. not
both. RFC 2461 says

>     MinRtrAdvInterval
>                     The minimum time allowed between sending
>                     unsolicited multicast Router Advertisements from
>                     the interface, in seconds.  MUST be no less than 3
>                     seconds and no greater than .75 *
>                     MaxRtrAdvInterval.
>
>                     Default: 0.33 * MaxRtrAdvInterval

so I propose that section 7.5 be changed to recommend a default
value for either the min or the max value. not both.

I think I can also explain the 0.05 and 1.5 second values. the
first proposal was to make it 0.5 and 1.5. after some discussion
it was felt this is not enough. then the MinRtrAdvInterval was 
changed to 0.05, but the max was not changed. I guess that should 
have been changed too. I dont remember the discussion.

regards
Vijay

---

From: Brett Pentland <[email-masked]>
Date: Tue, 26 Nov 2002 11:13:52 +1100

Firstly, I'm in favour of allowing frequent advertisements to provide
reasonable handover performance when no other means are possible. 
However, dealing with the effect of DAD on performance is to be pulled
out of the base spec so I don't really see how it is worth dropping the
advertisement interval to 50ms in the base spec when about one second
will be lost doing DAD anyway.  It seems that the interval should be of
the same order of magnitude as the DAD delay or that dropping it to a
very low value should be coupled with a strategy to remove this DAD
delay.

Regards,
Brett.

PS. For what it's worth, I wasn't on the list when the advertisement
rate was first discussed, and so up until now I thought that the draft
meant that the interval would be a random value between 0.05 and 1.5
seconds.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 25 Nov 2002 17:51:47 -0800

Brett Pentland wrote:
> will be lost doing DAD anyway.  

depends on whether you are doing DAD or DIID. if you are doing 
DAD, it makes a lot of sense. you can start DAD for CoA that much 
earlier. maybe even in parallel to the DAD for the link local 
address. if you dont have frequent router adverts, you have to 
first complete DAD for link local, then send a router solicitation, 
and then get a router advert and then configure a CoA.

take a look at a long discussion on the IPv6 mailing list a few 
months back on DAD Vs DIID. a lot of implementations seem to be 
doing DAD.

even if you do DIID, it still helps because you have a valid CoA 
as soon as you complete DAD on link local. CoA configuration is 
not tied to the MN first completing DAD for the link local address.

> or that dropping it to a

unfortunately ND changes are not on IPv6 WG's priority list.

> meant that the interval would be a random value between 0.05 and 1.5

nope, that was not the intention, IMO. 0.775 seconds as an average 
makes no sense..... 

regards
Vijay

---

From: Greg Daley <[email-masked]>
Date: Tue, 26 Nov 2002 15:15:12 +1100

Hi Vijay,

Optimistic DAD *is* a mobile-ip WG priority,
as discussed in the meeting last tuesday.

If we're optimistic that Opti-DAD will be adopted,
then it makes sense to rely upon it for fast handovers
(and it doesn't matter if you're doing DAD or DIID).

In our recent tests with FastRA  over 802.11b (albeit
while doing no DAD at all), it took consistently
less than 20ms to receive the RA (90% < 15ms)
and configure an address.

Even if DAD has to be performed on the global address, this
still only requires an additional NS message, with no
delays until the address can be used.

This is the case even with beacon-RAs.

Regarding the 0.775 ms delays, that's the substance of the
current mipv6-19 specification. If we want to improve it,
then the specification must be changed.

Since it's important to have a solution quickly, I think
that either the text is updated to reflect the intention,
or a new draft is written by Charles which covers it.

Most people in the WG meeting seemed to be of the idea that
if people want to chew access network bandwidth with
RA beacons, then that's an administrative issue.

It's worth noting that MinRtrAdvInterval is specified
in the Protocol Constants section (12), but MaxRtrAdvInterval
which also appears in the section Changes to Sending Router
Advertisements (7.5), is not presented in section 12.

Maybe it is sufficient to modify the MaxRtrAdvInterval
to a suitable value (?), add it to the protocol constants,
and add a warning about network utilization.

How about text like this
(starting at secton 7.5 paragraph 4):

....

"Such routers {SHOULD|MAY} be configured with a smaller
MinRtrAdvInterval value and MaxRtrAdvInterval value, to
allow sending of unsolicited multicast Router Advertisements
more often. Recommended values for these limits are:

     -  MinRtrAdvInterval       0.05 seconds

     -  MaxRtrAdvInterval       0.15 seconds

Multicast Router Advertisements will be randomly distributed
between the two values (in this case an expected value of 100ms).
It is important to note that as specified in RFC 2461[12],
MinRtrAdvInterval MUST be less than 0.75 * MaxRtrAdvInterval.

Use of these modified limits MUST be configurable, and specific
knowledge of the type of network interface in use SHOULD be taken
into account in configuring these limits for each network interface.
This is important with some wireless links, where increasing the 
frequency of multicast beacons can cause considerable overhead.
Routers SHOULD adhere to the intervals specified in
RFC 2461[12], if this overhead is likely to cause service
degradation.

Note that multicast Router Advertisements are not always required
in certain wireless networks that have limited bandwidth.  Mobility
detection or link changes in such networks may be done at lower
layers.  Router advertisements in such networks SHOULD be sent only
when solicited.  In such networks it SHOULD be possible to disable
unsolicited multicast Router Advertisements on specific interfaces.
The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be set
to some high values.
...."

(GD Aside: this gives a average beacon time of 100ms. It may be
better to specify lower values, or leave specifying the constants
to the protocol constants section).

Similarly, in section 12 (Protocol Constants).

"...
     MinDelayBetweenRAs       0.05 seconds
     MaxDelayBetweenRAs       0.15 seconds
...."

"...
The values MinDelayBetweenRAs and MaxDelayBetweenRAs override
the value of the protocol constants MIN_DELAY_BETWEEN_RAS and
MIN_DELAY_BETWEEN_RAS, specified in RFC 2461 [12].
...."

Greg

---

From: Brett Pentland <[email-masked]>
Date: Tue, 26 Nov 2002 16:29:21 +1100

DAD was what I was referring to.  

If you are expecting to wait for an RA to discover that you are on a new
link, you still have to perform DAD on the new CoA after the RA arrives.
If DAD is then going to take one second before you can start to use the
address then whether you spend half a second waiting for an RA or only
10ms, the total delay is still of the order of seconds.  

Anyway, that was really just an observation.  I gather that it was
decided in Atlanta that frequent RAs will stay in the base spec and that
is fine as long as we are not drawing a line in the sand that slows the
document's advance.  The main point is that it needs rewording so that
it is clear that we end up with around 50ms intervals rather than
average 775ms.

Regards,
Brett.

---

From: Brian Haley <[email-masked]>
Date: Tue, 26 Nov 2002 11:58:12 -0500

> value for either the min or the max value. not both.

I would disagree, it needs to specify both.

Anyways, issue #42 supposedly fixed these values, but the changes
didn't show up in the draft, text below.  I've found 200ms maximum
for 802.11 good in my lab, but haven't analyzed it in detail to say this
is "ok" for everyone, so would agree with leaving it at .05 to .15.  The
discussion on what is recommended for each media type can be
brought up in the mipv6ops/mipv6dep wg if/when we re-charter.

-Brian

http://www.piuha.net/~jarkko/publications/mipv6/issues/issue42.txt

Background: Krishna Kumar writes. In Section 7.5 :

   -  MinRtrAdvInterval       0.05 seconds
   -  MaxRtrAdvInterval       1.5 seconds

Question: This interval is too long, a range of 30 times. If the
router is using 1.5 seconds (using Advertisement Interval Option), the
MN may need a very long time to register the fact that it has moved,
probably having to miss a few of these router advertisements. I think
suggested values should be in the range of 0.05 to 0.25 seconds at the
most, implementors are welcome to increase this if they want, but
Mobile Specs should be more stringent on smooth handoff.

Brian Haley writes: I would agree, but would set the range at 0.05 to
0.15 seconds, although I've found .2 to .5 is adequate for MNs on an
Ethernet.

Jari Arkko writes: We also need to ensure that the text is clear
enough to show that different link types must be able to have
different min/max values (even outside the range for some link
types).

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Nov 2002 09:21:15 -0800

Vijay,

What wireless link protocol are you proposing to deploy this on?

            jak

----- Original Message -----
From: "Vijay Devarapalli" <[email-masked]>
To: "Thomas Narten" <[email-masked]>; "Charles E. Perkins"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, November 25, 2002 4:04 PM
Subject: Re: [mobile-ip] 50 ms RA timer?

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Nov 2002 09:39:22 -0800

> RA beacons, then that's an administrative issue.

I disagree with this. RFC 1958 states clearly that performance is important. I
don't believe IETF specifications should be recommending settings on
configurable parameters that have some potential to harm network performance.

In addition, I have yet to receive an answer about specifically what wireless
links the 50 ms timer is engineered to benefit. As such, it seems to me a
theoretical consideration that is not appropriate to an engineering document (we
are, after all, the Internet *Engineering* Task Force).

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 26 Nov 2002 10:07:29 -0800

Hello Jim,

> configurable parameters that have some potential to harm network performance.

Certainly!  I don't think anyone would want to configure the
parameter settings to values that would harm their networks.

Calculating the total capacity consumed by the beacons
(including framing and preamble and so on) and limiting
that to less than 1% of the available capacity would be
a good approach.

> are, after all, the Internet *Engineering* Task Force).

You posed the question and I've been thinking about how to answer.
From the way you pose the question, it seems to me that you do
not believe there are any benefits.  The results I have seen
indicate otherwise.  Maybe you are wondering whether it is useful
over 802.11.  Such systems have been built that take advantage
of the higher beacons, both for IPv4 and for IPv6, but I think that
there are really noticeable problems with many 802.11 cards being
sold today.  In fact, I believe that you and Bernard Aboba were
having a discussion at the microphone in Atlanta in which some
of the problems were brought out.

Here are two specific cases to answer your question, but not at
all a definitive list. 

- Any dual-band system that offers make before break.
  This is a luxury now, but it seems likely to be one of those
  luxuries that will soon be considered a necessity.
- Any wireless medium that doesn't require a lengthy frequency
  scan to lock onto another channel (oops, that seems to
  currently eliminate Bluetooth)

I hope that's enough for now.

I recently attended an IEEE 802.16 meeting, and there was quite
a lot of discussion about how it could best serve future needs
for Internet connectivity.  Mobile IP seemed to be quite well-regarded
as a beneficial technology there.  I mentioned a couple of my
pet peeves about current 802.11 device drivers and delays, and
I got the impression that many (not all!) IEEE engineers in the
meeting wanted to ensure that future products would work well
with Mobile IP.  It would be shame if that happened but somehow
the Mobile IPv6 specification was unable to take advantage of it.

Furthermore, from our days together at Sun, I believe you are
aware of the theoretical underpinnings of the requirement, from
projects at Berkeley and at Sun and at other places.  I realize
that IETF is geared towards engineering and not base technology,
but that does not invalidate our ability to use basic results
when engineering protocol solutions.

Regards,
Charlie P.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 26 Nov 2002 12:13:47 -0800

> What wireless link protocol are you proposing to deploy this on?

deploying things is not in my hands. frequent RAs works on 802.11,
in the absence of L2-UP trigger on the MN.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 26 Nov 2002 12:16:42 -0800

> didn't show up in the draft, text below.  I've found 200ms maximum

I had forgotten that this was dicussed and the issue resolved.

> is "ok" for everyone, so would agree with leaving it at .05 to .15.  The

fine with me.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Nov 2002 12:20:49 -0800

> indicate otherwise.

Were these results in  networks with realistic traffic patterns or where they in
lab prototypes with one MN per cell?

>Maybe you are wondering whether it is useful

The problems with 802.11 cards Bernard and I were discussing have nothing to do
with this specific issue. They have to do with using predictive handover
algorithms.

>   luxuries that will soon be considered a necessity.

By "dual-band" I presume you mean an 802.11 card capable of listening to two
channels at once? If so, then it should be possible to do true
"make-before-break" handover with such a card (using the forward channel to
perform the MIP configuration on the new subnet while the backward channel is
used for carrying traffic), and speeding up RAs wouldn't be necessary. The MN
can do RS on the forward channel to find out about the router, as soon as it has
a link.

>   currently eliminate Bluetooth)

Can you give a specific example?

> the Mobile IPv6 specification was unable to take advantage of it.

Sure, 802.16 looks quite promising. But I don't think it would need 50 ms RAs
either. If, as I have heard, it is to be based on flash OFDM, then it will have
"make-before-break" handover. Furthermore, I believe that 802.16 would run on
licensed spectrum, and I don't think most spectrum owners would be willing to
consume link bandwidth for 50 ms RAs.

> when engineering protocol solutions.

I don't know of any specific theoretical underpinnings for 50 ms RAs. Some of
the other enhancements that have been discussed for ND recently would provide
similar performance, with much less potential link bandwidth consumption. Thus,
examining the question of how to make ND better for wireless seems like a more
productive route to take than keeping specific changes in the MIPv6 spec which
have been in for a long time and don't benefit from the recent experimental work
Monash, Nokia, and Docomo have done in this area.

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 26 Nov 2002 12:58:47 -0800

Hello Jim,

James Kempf wrote:

> Were these results in networks with realistic traffic patterns or
> where they in lab prototypes with one MN per cell?

The results I have been familiar with are in lab prototypes and
simulations.   However, systems using beacons would scale
well with more mobile nodes, since the number of beacons would
not increase.

> with this specific issue. They have to do with using predictive handover

When connectivity is lost, it matters about how one might find
a different point of attachment.  Plus, a lot of the problems
with delays and resets and ambiguous acknowledgements do bear
on this issue.

> can do RS on the forward channel to find out about the router, as soon as it has

It would be nice to know whether or not the current channel
is operational before registering a new care-of address.

> Can you give a specific example?

Is the point unclear?  All the specific examples I know about
have to do with 802.11 cards of various descriptions, and they
seem to have a variety of problems.  None of the problems
directly bear on this issue, but it does mean that one has to
be clever (in various ways, per card) to get the desired performance.
I remain hopeful that as the network-layer technology is standardized
that cards will become available that don't require so many tricks.

> consume link bandwidth for 50 ms RAs.

"make-before-break" does not eliminate the need for fast beacons,
depending on which layer-2 triggers are supplied.  We have a ways
to go before we can expect standardized behavior for that.

Regarding the acceptability of layer-3 beacons on licensed spectrum,
I think that is somewhat unpredictable and depends on performance
numbers that we don't have.  For 802.11b, the overhead is already
down below 1%, I believe.  For 802.11a and for 802.16, it could be
much smaller, going below 0.1%.  That doesn't sound to me like the
death of anybody's business case.

> I don't know of any specific theoretical underpinnings for 50 ms RAs.

It makes voice work perfectly (assuming certain other bits of
technology having to do with fast handovers).

>                                                                    Some of

I have agreed many times that other methods exist towards improvement.
I think most people recognize that a scheme using layer-2 triggers is
going to be better.  Minimizing consumption of link capacity will
have the effect of extending Mobile IPv6's applicability to still
more physical media.

However, I'm a very firm believer that a bird in the hand is worth
two in the bush.  This business about advertisement frequency has
been understood for a long time, and has not been invalidated by
new improvements.

Regards,
Charlie P.

PS. I think that, with this note, I'll have to cede the honor of having
    the last word to you, Jim.

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 27 Nov 2002 10:35:37 +1100

> If we're optimistic that Opti-DAD will be adopted,

If we're Optimistic that it'll be adopted, we should just
proceed assuming it will be, but minimize disruption
to others and be prepared to relinquish the idea if it
collides ... :-)

> (and it doesn't matter if you're doing DAD or DIID).

For what it's worth, I've run roughshod over the whole
"Interface Identifier" concept in my current Optimistic
DAD implementation ... every time a new address is 
configured, a new (random) suffix is chosen.  It would
be easy enough to retrofit DIID though, if it showed
significant advantage and wasn't likely to harm
interoperation.

-----Nick

---

From: Greg Daley <[email-masked]>
Date: Wed, 27 Nov 2002 10:58:52 +1100

Hi James,

You're right.  I was trying to illustrate that
we're going for the immediately available,
(supposedly ;) well understood solution, rather
than the best.

About general scalability of beacon transmission,
the beacons have a well known worst case
( for example, 20 multicast beacons/second,
for MinRtrAdvInterval 0.05). This type of
performance maybe acceptable if it is well
disclosed, and understood by implementors.

Having some sort of minimum, so that implementors do not
have to design solutions which work at lower timing
intervals, is useful.

Maybe we can specify an absolute maximum rate for
beacons, and specify that an implementation
should not use MIPv6 specified values without
calculating the expected bandwidth usage and effects
on their (wireless) network. Especially we should
specify that the beacons shouldn't default to the
maximum beacon rate (even for networks which deploy
other MIPv6 RA options, such as Advertisement Interval).

Certainly, discussion of which wireless link people
have deployed on is useful, but I'm not sure that more
than a general warning  (independent of link type)
is useful in the draft.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Wed, 27 Nov 2002 08:53:17 -0800

Charlie,

OK, so the bandwidth is 1% instead of 10%, like I said, on 802.11b (extract foot
from mouth, remove bullet from own revolver out of foot :-). Chalk up the
misplaced decimal point to post-IETF fatigue and a raging head cold.

Still, the random backoff provided by DCF will space out any timing at the IP
layer as soon as there is any contention in the cell, so that the RA
interarrival time won't be 50 ms. I don't think any of the simulations or
prototypes have taken that into account. And FWIW there is still an issue with
the cellular protocols and licensed spectrum.

Finally, I still maintain, as I mentioned at the end of the fast handover
discussion in ATL, that separating local link mobility from global mobility is
better both architeturally and engineering-wise, since it lets the two evolve
separately. I believe this holds for both the base spec and fast handover. But,
since the working group seems not to agree for the base spec, I'll refrain from
pushing the issue any further, since we really need to get the base spec
completed.

            jak