[Seamoby] CARD MN-AR Transport

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

So I wanted to discuss Marco's comment in a separate thread so that people
clearly understand what the issues are. Here's the comment:

>----
>4.4 MN-AR Transport
>This looks inconsistent and sections on protocol transport
>should be covered either by chapter 4 or 5. Now it is split.
>Proposal: Move this section to 5.1.1, similar to how it is
>done for the AR-AR transport in 5.2.1.
>
>Why has the retransmission scheme and the assocated protocol
>constants changed? Use of exponential bakoff is ok.
>
>These changes, I cannot associate with any IESG comment.

The changes in the latest document for MN-AR transport do not, in fact,
correspond to any specific IESG comment, but rather come out of a
conversation I had with Allison about transport in CARD (and CTP, but that's
not at issue here). The basic issue was lack of exponential backoff in the
MN-AR transport protocol. Exponential backoff is an IETF requirement (as in
MUST) for any application level datagram-based transport protocol that does
retransmissions. The requirement is not simply arbitrary, it comes out of
many years of experience in implementation and deployment of these types of
protocols. Exceptions are always possible, but expected to be rare.

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 is more explicit about how sequence numbers should be
chosen: that the request and any retransmissions have the same sequence
numbers, that the sequence number should be randomly chosen to avoid
possible duplicates (it should probably also say that the request and reply
seq numbers should match, though that is said elsewhere in the document).

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

Basically, the additions to the 07 draft were made to implement exponential
backoff, and to strengthen the use of  sequence numbers. W.r.t. the changes
in constant names, we could revert CARD_REQUEST_RETRY to the name used in
the 06 draft and change CARD_RETRY_MAX to something like
MN_AR_CARD_RETRY_MAX if people don't like the new naming convention. Other
than that, it is difficult to see what could be dropped without harming the
guidance on exponential backoff.

So my recommendation is that we keep the current text as is, with the
exception that the WG consider merging Section 4.4 with Section 5.2.1 to
form a single top level section that deals with transport, and that we add a
sentence to paragraph 3 saying that the request and reply have the same seq
number.

For those of you who would like to check how a similar protocol specifies
exponential backoff, please see RFC 2608 Section 12.3.

            jak









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