[Seamoby] issue-#47: Change in MN-AR signaling retransmission scheme and of

["James Kempf" <[e-mail]>]

The issue is why has the retransmission scheme and the associated
protocol constants changed? These changes cannot be
associated with any IESG comment.

The response is that the changes in version 07 were made to implement
exponential backoff. Lack of exponential backoff for congestion
control came up during conversations with the shepherding AD, though
they were not, as the issue mentions, identified during IESG review.
Exponential backoff is the recommended IETF way for any application
level datagram-based transport protocol that does retransmissions to
handle congestion control.

Specifically, comparing texts between draft 06 and draft 07,
the 06 draft says this about transport on the MN-AR interface (Section
4.4.1, phrased as failure recovery):

----
It is likely that either a MN-AR CA Request or MN-AR CARD Reply may be
dropped due to poor radio link conditions. A MN SHALL retransmit the CARD
Request using the same message sequence number, if it does not receive a
CARD Reply within MR_AR_CARD_TIMEOUT seconds. The MN SHALL retry sending the
MN-AR CARD Request for a pre-configured number of times (MN_AR_CARD_RETRIES)
before declaring the protocol message exchange aborted. The MN SHALL
silently discard any duplicate MN-AR CARD Reply messages received from its
current AR and take the latest information received as valid.
----

The 07 draft says this about transport on the MN-AR interface (Section 4.4,
phrased as MN-AR transport):

----
The MN-AR interface uses ICMP for transport. Because ICMP messages are
limited to a single packet, and because ICMP contains no provisions for
retransmitting packets if signaling is lost, the CARD protocol incorporates
provisions for improving transport performance on the MN-AR interface.

CARD Requests which fail to elicit a response are retransmitted.  The
initial retransmission occurs after a CARD_REQUEST_RETRY wait period.
Retransmissions MUST be made with exponentially increasing wait intervals
(doubling the wait each time).  CARD Requests should be retransmitted until
either a response (which might be an error) has been obtained, or for
CARD_RETRY_MAX seconds occurs. ARs MUST discard any CARD Requests having the
same sequence number after CARD_RETRY_MAX seconds.

MNs which retransmit a CARD Request use the same CARD sequence number. This
allows an AR to cache its reply to the original request and then send it
again, should a duplicate request arrive.  This cached information should
only be held for a maximum of CARD_RETRY_MAX seconds after receipt of the
request.  Sequence numbers SHOULD be randomly chosen to avoid duplicates if
MNs restart frequently.

MNs SHOULD limit the amount of information requested in a single ICMP reply
packet, since ICMP has no provision for fragmentation above the IP level.
----

The differences between these two are:

    1) The 07 draft specifies exponential backoff, whereas the 06 draft
specifies a fixed number of retries.

    2) The name of the wait period constant before the initial retry in the
06 draft is MR_AR_CARD_TIMEOUT while the name in the 07 draft is
CARD_REQUEST_RETRY.

    3) The 06 draft specifies that the MN issues MN_AR_CARD_RETRIES before
giving up while the 07 draft specifies that the MN retransmits with
exponential backoff until CARD_RETRY_MAX expire.

    4) The 07 version specifies that the AR drops requests after
CARD_RETRY_MAX seconds. The 06 version doesn't put any time limit on
replies.

    4) The 07 version allows the AR to cache its reply for CARD_RETRY_MAX
seconds after first sending it so that it can quickly resend should the
reply be lost and the MN request retransmission.

    5) The 07 version changes how sequence numbers are generated and used:
   a) That the request and any retransmissions have the same sequence
numbers. This point is also included in version 06.
   b) That the request and reply sequence numbers must match, and that the
MN must reject any replies that don't match an outstanding request. This
point is also included in version 06.
    c ) That the sequence number should be randomly chosen. This avoids the
following problems with incremented sequence numbers:
      i) Draft 06 required the AR to maintain a cache of sequence numbers,
with no limit given in the draft about how large the cache should be. An
attacker could use this to launch a state exhaustion attack on the router.
      ii) If the MN shuts down then restarts a short time later, the AR
might not have flushed the sequence number cache associated with the MN, and
the AR would interpret restarting as a replay attack. This requires the MN
to maintain the sequence number in stable storage, considerably complicating
the implementation of the protocol. Usage patterns involving short shut down
periods are likely to be common with mobile devices.

    6) The 07 version gives additional guidance about limiting the amount of
information requested to avoid the need for fragmentation.

The points above indicate that the changes to the 07 draft were made to
implement
exponential backoff and to strengthen the use of  sequence numbers. One
constant
name was changed (MR_AR_CARD_TIMEOUT), one constant was dropped
due to the introduction of exponential backoff (MN_AR_CARD_RETRIES).

The recommendation is that we keep the text as is in version 07, so that the
MN-AR transport properly supports the IETF recommended way for
datagram application level protocols to handle congestion - exponential
backoff.

                                                jak



_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby