[support] UMIP: Config option InitialBindackTimeoutFirstReg ?

[Mattias Blomqvist]

Hi

On Thu, May 7, 2009 at 1:56 PM, Romain KUNTZ <kuntz at lsiit.u-strasbg.fr> wrote:
> Hi Mattias,
>
> On 2009/04/30, at 17:32, Mattias Blomqvist wrote:
>>
>> The configuration option InitialBindackTimeoutFirstReg does not seem
>> to work. Regardless of what I set it to in the configuration file, it
>> is set to 1.5 seconds at start.
>> I can see that there is an implementation of it in the configuration
>> parsing. But I'm unable find out why it doesn't work.
>> Is it supposed to work?
>> What about InitialBindackTimeoutReReg ? It has the same problem.
>
> By looking quickly at the code, I'd say this is supposed to work. Could you
> send the mip6d log of the MN? Especially, are these values correctly
> displayed in the debug (there are printed at startup)? That would help to
> know if it is a problem from the parser or later in the code.

It seems to be the parser. Because regardless of what I set the value
to, the debug output is:

Thu Jan 10 20:44:13 conf_show: InitialBindackTimeoutFirstReg = 1.500000

The same goes for InitialBindackTimeoutReReg.

>> I really need to set this value higher and it would be good to not
>> have to modify the source to do it.
>>
>> Wouldn't it be a good idea to also have the initial_solicit_timer_ts
>> configurable?
>
> INITIAL_SOLICIT_TIMER is a protocol constant defined by the MobileIPv6
> specification. This is I guess the reason why it is not configurable.
> However it seems that the specification does not forbid the use of another
> value, so this could be made configurable too.

Hmm... True.
The real problem isn't the initial value of 3 seconds. The problem is
that if the answer is delayed more than 3 seconds or if the link has a
high RTT it will result in retransmissions without increasing the
delay.
Consider a link with a RTT of about 5 seconds between MN and HA. If I
understand thing correclty, the sequence will be something like this:

Send MPS (id = x).

3 seconds....

Send MPS (id = y).

1.5 seconds...

Receive MPA (id =x). Since x is not equal to last sent id (y) the MPA
will be discarded and a new MPS will be scheduled immendiately.
Send MPS (id = z)

3 Seconds....

Receive MPA (id = y). Since y is not equal to last sent id (z) the MPA
will be discarded and a new MPS will be scheduled immendiately.
Send MPS (id = xx)

etc. etc...

The immediate send of a new MPS when an out of sequence MPA is
received is stated as SHOULD in the RFC.
I don't have an easy solution for this case other than making
INITIAL_SOLICIT_TIMER configurable. Turning off transmissions of MPS
(which i believe is possible by setting SendMobPfxSols to false on the
MN) is also a solution but then the feature it provides cannot be
used.

BR,
Mattias