Subject: [mobile-ip] Proposed resolution for issue #181

From: Charlie Perkins <[email-masked]>
Date: Mon, 02 Dec 2002 16:58:16 -0800

Hello folks,

From this issue, I could not think of much improvement to be made.
A citation for RFC 2461 should be added to the relevant text, as
suggested, but I don't see how to make the timing parameters better.

Regards,
Charlie P.

Thomas Narten writes:

>    its registration is accepted by one of these home agents.  The
mobile
>    node MUST, however, wait at least 1.5 times longer than
(RetransTimer
>    * DupAddrDetectTransmits) before sending a Binding Update to the
next
>    home agent.  In trying each of the returned home agent addresses,
the

seems odd to base this off DupAddrDetectTransmits... And the values
here are link-specific, so the MN needs to know what kind of link the
HA is on in order to get these right. Seems like a tall order...

=======================================================================
        It might take this long before the home agent would be able
        to accept the Binding Update because of DAD.  Since the home
        agent is a router on the mobile node's home link, it is
        reasonable to assume that the mobile node has the needed
        timing information. Are there any suggestions about how to
improve
        this?   Otherwise, it might be the best we can do.
=======================================================================

>     -  If the mobile node is sending a Binding Update and it does not
>        have an existing binding at the home agent, it SHOULD use a
value
>        for the initial retransmission timer that is at least 1.5 times

>        longer than (RetransTimer * DupAddrDetectTransmits).  This
value

where are these defined (should cite ND here I think)? and 1.5 times
this sounds odd. Should be based on RTT between HA and MN (not known)
plus max DAD time. 1.5 times the latter would likely be much larger
than the desired time.

=======================================================================
        Proposal: Citation should be added to the text.

        Typically, the DAD timeouts would be a lot larger than
        the RTT for signaling.  The 1.5 factor should account for
        the RTT plus some extra time for other small uncertainties.
=======================================================================

---

From: Jari Arkko <[email-masked]>
Date: Sun, 08 Dec 2002 22:36:11 +0200

First a reminder for everyone that the issues are at
http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html
and the list includes color coding to indicate current status.
I also mark the draft number to the list when the solution has
been edited to the draft, so you know what the current progress
is.

Then to issue #181, about Thomas' complaint no basing switchover
to another HA on DupAddrDetectTransmits. As Charlie noted, the
main delay in getting an answer to a BU is DAD, and therefore
both RetransTimer and DupAddrDetectTransmits certainly are
factors in evaluating the required waiting time.

The problem Thomas brought up was that the necessary values
are the ones that appear on the home link, and the MN might
be using some other values at the moment on its current
link. For instance, a lossy visited link might have
DupAddrDetectTransmits set to 3 instead of 1 at home, so
which value would apply for our delay? It is true as Charlie
noted that the mobile node could learn it from the home
link. But I'm not sure all deployments of mobile IPv6 have
links that you can actually go to, and we might even have
virtual home links that can't be attached to.

On the other hand the difficulties doing anything more
that Charlie brough up are valid. At the time we need
this information, we are trying to connect to our home
agent, so the home agent can hardly tell us anything
about them. We might use the information from our
previous communications with the home agent as the
alternative home agents are all on the same link
(and therefore the information is the same). However,
this still doesn't address the situation when we try
to connect to the home agent for the first time.

In conclusion I agree with Charlie that we can't do
much more. However, I also agree with Thomas that
the links in question are different. Perhaps the
best we can do is to have a MIPv6 specific configuration
variable for this timeout. This would have the following
benefits:

- Can be set if the home agent is for some reason running
   a "weird" link with a non-default DupAddrDetectTransmits
- Can not be confused with the current link's properties
- Leaves the possibility for us to later invent a way to
   communicate the value to the MN

So the proposal is the introduction of a new configuration
variable. The default is based on the defaults of Retranstimer
and DupAddrDetectTransmits and the current formula.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 09 Dec 2002 17:32:23 +0200

> and DupAddrDetectTransmits and the current formula.

Here's the text proposal for the above. In Section 11.4.1, replace
the text

    The mobile
    node MUST, however, wait at least 1.5 times longer than (RetransTimer
    * DupAddrDetectTransmits) before sending a Binding Update to the next
    home agent.

=>

    The mobile node MUST, however, wait at least FirstBindingBindAckTimeout
    seconds (see Section 13) before sending a Binding Update to the next home
    agent.

And in Section 11.8, replace the text

     -  If the mobile node is sending a Binding Update and it does not
        have an existing binding at the home agent, it SHOULD use a value
        for the initial retransmission timer that is at least 1.5 times
        longer than (RetransTimer * DupAddrDetectTransmits).  This value
        is likely to be substantially longer than the otherwise specified
        value of INITIAL_BINDACK_TIMEOUT (see Section 12) that would be
        used by the mobile node.  This longer retransmission interval
        will allow the home agent to complete the DAD procedure which is
        mandated in this case, as detailed in Section 11.7.1.

=>

     -  If the mobile node is sending a Binding Update and it does not
        have an existing binding at the home agent, it SHOULD use
        FirstBindingBindAckTimeout as a value for the initial retransmission
        timer. This long retransmission interval will allow the home agent
        to complete the DAD procedure which is mandated in this case,
        as detailed in Section 11.7.1.

And add a new Section 13, Protocol Configuration Variables:

     The configuration variables and their default values are as
     follows:

       HomeRtrAdvInterval           3,600 seconds
       MaxMobPfxAdvInterval        86,400 seconds
       MinMobPfxAdvInterval           600 seconds
       FirstBindingBindAckTimeout     1.5 seconds

     Home agents MUST allow the first three variables to be configured
     by system management, and mobile nodes MUST allow the last variable
     to be configured by system management.

     The default value for FirstBindingBindackTimeout has been
     calculated as 1.5 times the default value of RetransTimer
     [rfc2461] times the default value of DupAddrDetectTransmits
     [rfc2462].

Jari