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

[Seamoby] Re: further comments on CARD version 8



> >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."
>

Right, it's a typo. It should say CARD Reply. I'll fix it.

> 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?
>

I don't think you can use incrementing the sequence number. Suppose the
messages are delivered out of sequence. The MN can't determine if the
message matches an outstanding request, so it drops the packet. One could
suppose a more complex processing mechanism, but it't not really necessary.
Most CARD Replies are likely to be small, with the exception of the Router
Certificate option. The latest version (draft-08) has support for "X of N"
(ex.: 2nd of 5) so that a MN can ask for individual certs in a certification
path, if one is dropped.


            jak



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