[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Seamoby] Re: further comments on CARD version 8

James Kempf wrote:

Marco,

Many thanks for your detailed comments. This is the kind of review that
really helps improve the quality of IETF documents.
Most of the comments were editorial and I incorporated them without change.

There were two technical comments:



same paragraph:
Question: How does the MN know about a lost message in a sequence of
CARD Reply messages? In case of retransmission, is the full block
retransmitted?




Good question.

I added back in the description of the L-flag. It is set on the last message
of a multi-message reply. In addition, I added the following text to Section
4.2.1:

A MN uses exponential backoff to retransmit the CARD Request
in the event a CARD Reply is not received within CARD_REQUEST_RETRY
seconds. The retransmitted CARD Request MUST have the same sequence
number
as the original.With the exception of certification paths, which are
large by nature, an
AR SHOULD attempt to limit the information in a CARD Reply to a single
message.
Should that not be possible, the AR MAY send the reply in multiple
messages. The
last message of a reply MUST always have the L-flag set in the CARD
Reply option to
indicate that the message is the last for the associated sequence
number. An AR
retransmitting the CARD Request MUST always send the full CARD Reply.


ARs do not retransmit CARD Requests but CARD Replies. What about:
" An AR retransmitting replies to a CARD Request MUST always send the full CARD Reply sequence."

Well, obviously keeping the protocol simple is a design goal. For that it's fine to
retransmit the full sequence. However, this does not solve the issue to allow MN's
detecting a particluar lost message in a reply sequence. Hence, what about the following:
Allow ARs, which reply a sequence of CARD Reply messages to a CARD Request, to
increase Sequence Numbers of CARD Replies, but starting the with the same sequence number
as in the request. With the help of the L-flag this allows detection of the sequences' end
AND of a missing segment in between. Further, this still allows correlation of Requests with
Replies on the MN, since the first Reply matches the Request's sequence number.

Only remaining issue is in case the first CARD Reply message of a sequence gets lost, but the second is
received, having the sequence number incremented. This should be ignored then by the MN and
the CARD Request should be retransmitted according to the procedure described in section 4.2.1.

Did I miss something?
What do you think?


The Trusted
   Anchor sub-option and the Router Certificate sub-option provide a means
whereby the
   MN can request specific certificates in a certification path, in the
event that the CARD Reply
   carrying a certification path spans multiple messages and one of them is
lost. However, a
   request for specific certificates that were not received in the initial
CARD Reply MUST
   be treated as a new request by the MN and MUST use a different sequence
number.

Does this sound OK?



In general: setting of sequence numbers:
Is it correct that the MN should randomly choose whereas the
AR should start with 0 and increment? Is this how you want it?




Yes. The AR-AR interface may involve periodic updates, and there will be a
longer term relationship. Theoretically, the sequence number could be
dropped on the AR-AR interface, because SCTP takes care of it, but it's kept
in for consistency. With the MN-AR interface, the MN may handover to another
AR, then come back. Maintaining sequential sequence numbers under those
conditions is awkward.

Do you see any problem with this?



Ok, thanks for clarification.

marco

I'll add these two issues to the issue tracker.

           jak





_______________________________________________
Seamoby mailing list
Seamoby at ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby