Subject: [mobile-ip] Mipv6 issue #126: exponential back-off vs. rate limiting

From: Jari Arkko <[email-masked]>
Date: Fri, 27 Sep 2002 22:54:05 +0300

(Originally brought up by Conny Larsson)

Draft 18 has an exponential back-off mechanism to
send BUs at 1 s, 2 s, 4 s, 8 s and so on intervals
until a BA is received or 256 s is reached.

But it also has a rate-limiting procedure to avoid
sending more than 5 BUs at 1 s intervals and then
any number of BUs at 10 s intervals.

These two procedures seem to be in conflict and
may duplicate functionality. The conflict
arises if rate-limiting would allow sending 5 BUs
in 5 seconds, while the exponential back-off would
allow only 3. Could these procedures be combined?
Perhaps exponential back-off would be sufficient
by itself (maybe with a lower maximum time than 256
seconds).

The same applies to return routability messages.

BE rate limitation is as it should be (references
ICMP). BRR rate limitation must be applied, but
there is no indication of what kind of rate
limitation to use. This should be specified.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 27 Sep 2002 18:01:17 -0700

I am not sure if these mechanisms are in conflict.

exponential back-off mechanism is used to sent BUs to the
same CN.

rate-limiting is used to avoid sending more than a certain
number of BUs in a certain amount of time to any CN/HA.

Jari Arkko wrote:
> allow only 3. 

this conflict wont happen right, if you take the above two
definitions into account.

please correc tme if I didnt understand the issue.

regards
Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sat, 28 Sep 2002 09:43:53 +0300

> number of BUs in a certain amount of time to any CN/HA.

This would perhaps be a good interpretation, but it is *not* what
the text says in the draft. It says:

    After sending MAX_FAST_UPDATES consecutive Binding Updates to a
    particular node with the same care-of address, the mobile node SHOULD
    reduce its rate of sending Binding Updates to that node, to the rate
    of SLOW_UPDATE_RATE per second.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 30 Sep 2002 17:12:31 +0300

I have thought about this some more. Here are a few observations:

- We need a retransmission back-off rule to limit the number
   of BUs/RRs sent in one purpose towards one node. Just like
   TCP.

- We may also need other, more global rules. Potential
   candidates include:

   1. Limit the overall rate of BUs/RRs from this MN.
   2. Limit the overall rate of BUs/RRs towards this CN
      (grouping together all our bindings, for sequential
      or parallel bindings).
   3. Limit the overall rate of BUs/RRs on an interface,
      towards a particular network, etc.

- Limiting the overall rate of BUs/RRs seems too strict.
   A mobile server would have trouble telling all its peers
   about its new location, despite the bandwidth available
   to it.

- Limiting the BUs/RRs towards one CN seems useful
   when when the mobile is moving fast and changing its
   binding. However, 11.4.2. already dictates that movement
   can't occur too frequently, as new care-of addresses
   can't be created more than MAX_UPDATE_RATE per second,
   i.e. once per second.

- What about limiting the number of BUs/RRs per home
   address, given, say, a one-million home address MN?
   We could claim that this is like the server case,
   the MN should be free to do this. However, it is also
   a question of what the CN on the other side will be
   able to handle. So this should be limited in some
   manner.

- Per-interface or per-network limits seem too arbitrary.

- SLOW_UPDATE_RATE and MAX_BINDACK_TIMEOUT are in conflict
   with each other.

 From the above it seems like we need the retransmission
back-off rule, and it would be useful to specify an overall
limit for how many BUs and RRs can be sent towards the same
CN. So, roughly the current approach should be kept, but
we need to work on the text:
- clarify rate limitation is per-CN, any binding
- clarify when retransmission timers are reset
- keep only the MAX_BINDACK_TIMEOUT upper limit
- remove MAX_FAST_UPDATES, and SLOW_UPDATE_RATE

For the text, my proposal is to move all retransmission and
rate limitation discussion to a new section at the end of
11 (we already did this for rate limitation). The text
could look like this:

11.x. Retransmissions and Rate Limiting

The mobile node is responsible for retransmissions and
rate limiting in the return routability and binding
procedures.

When the mobile node sends a Home Test Init, Care-of Test Init or
Binding Update message for which it expects a response,
the mobile node has to determine a value for the initial
retransmission timer:

- 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
   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~\ref{update-home}.

- Otherwise, the mobile node should use the specified value
   of INITIAL_BINDACK_TIMEOUT for the initial retransmission timer.

If the mobile node fails to receive a valid, matching response within the
selected initial retransmission interval, the mobile node SHOULD
retransmit the message, until a response is received.

The retransmissions by the mobile node MUST use an exponential
back-off process, in which the timeout period is doubled upon
each retransmission until either the node receives a response
or the timeout period reaches the value MAX_BINDACK_TIMEOUT.
The mobile node MAY continue to send these messages at
this slower rate indefinitely.

The mobile node SHOULD start a separate back-off process for
different message types, different home addresses and different
care-of addresses. However, the mobile node MUST NOT send
a particular Mobility Header message type to any individual node
more often than once per MAX_UPDATE_RATE seconds.

Retransmitted Binding Updates MUST use a Sequence Number
value greater than that used for the previous transmission of
this Binding Update. Retransmitted Home Test Init and Care-of Test
Init messages MUST use a new HoT or CoT Cookie value.