Subject: Re: [mobile-ip] Mobile Prefix Advertisements, take 2

From: Jari Arkko <[email-masked]>
Date: Fri, 11 Oct 2002 17:15:03 +0300

T.J. Kniveton wrote:

> It would be nice if we could have some input on these formulae. Here are some
> proposed changes to synchronize everything and some questions:
> 
> - HomeRtrAdvInterval should be renamed, perhaps to MaxMobPfxAdvInterval

Agree.

> - formula for MAX_SCHEDULE_DELAY should use MaxMobPfxAdvInterval instead of
> MAX_PFX_ADV_DELAY

Yes.

> - Is there some reason why we need a separate variable, MAX_PFX_ADV_DELAY? It
> seems like it should always be equal to MaxMobPfxAdvInterval. Correct? Maybe we
> can just get rid of it and the mobile node can use the same value defined for
> the latter.

Yes. Where the mobile node needs MAX_PFX_ADV_DELAY today, we should
replace MaxMobPfxAdvInterval instead.

> - RAND_ADV_DELAY uses MinRtrAdvInt. But this is for router advertisements at
> the home agent. Perhaps we also need to define a MinMobPfxAdvInterval to set
> the min bound for MPAs.

I agree that MinRtrAdvInt is wrong.

> - What should the best values for {Max,Min}MobPfxAdvInterval be?

Sourajeet suggested an hour for the max value, and Vlad suggested
to follow the RFC 2461 values (3 and 600 s). But these advertisements
are not multicasted, and they are not sent on a local LAN. And this
traffic could be going to devices that wish to stay in dormant mode.
So I would suggest large values, maybe in the order 10 mins to a day
or even more.

Here's suggested new definitions for the formulae and constants:

       MinMobPfxAdvInterval            600 seconds
       MaxMobPfxAdvInterval         86,400 seconds

    ...

    Otherwise, the home agent computes a fresh value for RAND_ADV_DELAY,
    the offset from the current time for the scheduled transmission
    as follows.  First calculate the maximum delay for the scheduled
    Advertisement:

        MAX_SCHEDULE_DELAY = min (MaxMobPfxAdvInterval, Preferred Lifetime),

    where MaxMobPfxAdvInterval is as defined in Section ??.

    Then compute

        RAND_ADV_DELAY = MinMobPfxAdvInterval +
                         rand()*(MAX_SCHEDULE_DELAY - MinMobPfxAdvInterval)

    where MinMobPfxAdvInterval is also defined in Section ??.

Jari

---

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 11 Oct 2002 11:02:37 -0400

Jari

> So I would suggest large values, maybe in the order 10 mins to a day

RFC 2461 defines the largest MaxRtrAdvInterval to be 1800 sec (30 minutes)
It defines MinRtrAdvInterval as .75 * MaxRtrAdvInterval = 1350s (22.5 min).

The question is how often should be send the unsolicited MPAs?  Is once
every 30 minutes OK?  Once every hour?

>    where MinMobPfxAdvInterval is also defined in Section ??. 

I don't think this formula is correct...  Trying to plug in values
we get the following:

Using rfc2461 default for Preferred Lifetime (604800 seconds) and using
your proposed values we get:

MAX_SCHEDULE_DELAY = min (86400,  604800) = 86,400

RAD_ADV_DELAY = 600 + rand() * (86,400 - 600) = 600 + rand() * 85,800

Using this formula, we will exceed the value of MaxMobPfxAdvInterval
for values of rand() > 1, and will exceed the default value of Prefered
Lifetime (7 days) for rand() > 8.

I think the multiplication needs be be replayced by moduler division:

RAND_ADV_DELAY = MinMobPfxAdvInterval +
                         rand() % (MAX_SCHEDULE_DELAY - MinMobPfxAdvInterval)

This will create the random delay such that
	MinMobPfxAdvInterval < RAND_ADV_DEALY < MAX_SCHEDULE_DELAY

-vlad
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Jari Arkko <[email-masked]>
Date: Sat, 12 Oct 2002 01:09:20 +0300

> every 30 minutes OK?  Once every hour?

Yes, that's the question. I'm trying to propose that RFC 2461 limits
and MIPv6 pfx advs are not necessarily related.

>     MinMobPfxAdvInterval < RAND_ADV_DEALY < MAX_SCHEDULE_DELAY

Yes, I was thinking about this when I wrote the proposal. The
question is what does "rand()" represent. If it's the C function
then it gets 0..2^32-1 values. Apparently the original assumption
was a (hypothetical?) 0.0..1.0 function. Hmmm... maybe the C
interpretation should be preferred... but there's a problem: %
and * behave differently when the second argument is negative,
and this was built in to the formula to cover for the cases when
the preferred lifetime is shorter than MinMobPfxAdvInterval.

But I'm not sure we want to send the prefix advertisements faster
than MinMobPfxAdvInterval in any case. Consider a million-mobile-node
HA that has a prefix that whose lifetime is about to expire. As
the expiration comes near, the number of prefix advertisements sent
by the home agent goes up.

So my suggestion is to use the formula

   RAND_ADV_DELAY = MinMobPfxAdvInterval +
                           rand() % (max(0,MAX_SCHEDULE_DELAY -
                                           MinMobPfxAdvInterval))

Jari

---

From: Vladislav Yasevich <[email-masked]>
Date: Mon, 14 Oct 2002 09:39:07 -0400

> and MIPv6 pfx advs are not necessarily related.

You are right, the limits are not related, but the varialbes are.  The
new variables attempt to replicate to some extent the functionality
provided by {Min,Max}RtrAdvInterval.  So, I can see at least using the
same math to figure out the min value based on the max value...

>                           rand() % (max(0,MAX_SCHEDULE_DELAY -

I don't think you want to divide by 0. :)

Using an absolue value of the difference fixes the problem:

	rand() % abs(MAX_SCHEDULE_DELAY - MinMobPfxAdvInterval)

-vlad
--