Subject: Re: RFC 2961 - detectoin of out-of-order msg

From: Bob Braden <[email-masked]>
Date: Sun, 15 Jul 2001 17:05:41 -0700 (PDT)

Comments on this question, please, from at least one of the
6 authors of 2961?

Bob Braden

  *> From [email-masked]  Wed Jul 11 14:46:17 2001
  *> From: "Feng, Mark" <[email-masked]>
  *> To: [email-masked]
  *> Subject:  RFC 2961 - detectoin of out-of-order msg
  *> Date: Wed, 11 Jul 2001 14:41:55 -0700
  *> MIME-Version: 1.0
  *> 
  *> Hi,
  *> 
  *> RFC 2961 describes a mechanism to detect out-of-order messages for a
  *> particular state (Please see the quote below). I am not sure the mechanism
  *> works all the time. The test should work if the new number does not wrap
  *> around too far. However, since the message ID is per generator's IP address,
  *> it could be sent to multiple receivers; and there could be numbers of
  *> connections/states on each receiver. In this case, if a particular state
  *> does not experience any change of state for a substantial long period of
  *> time, the next state change could result in the receiver getting a trigger
  *> message with a message ID that wraps around far enough so that the test will
  *> fail (e.g. let's say old id is 0x8fffffff, the new value is 0x00000002, the
  *> test fails)
  *> 
  *> Please correct me if I am wrong.
  *> 
  *> Thanks in advance.
  *> 
  *> Mark
  *> 
  *>    "Nodes processing incoming MESSAGE_ID objects SHOULD check to see if a
  *>    newly received message is out of order and can be ignored.  Out of
  *>    order messages SHOULD be ignored, i.e., silently dropped.  Out of
  *>    order messages can be identified by examining the values in the Epoch
  *>    and Message_Identifier fields.  To determine ordering, the received
  *>    Epoch value must match the value previously received from the message
  *>    sender.  If the values differ then the receiver MUST NOT treat the
  *>    message as out of order.  When the Epoch values match and the
  *>    Message_Identifier value is less than the largest value previously
  *>    received from the sender, then the receiver SHOULD check the value
  *>    previously received for the state associated with the message.  This
  *>    check should be performed for any message that installs or changes
  *>    state.  (Includes at least: Path, Resv, PathTear, ResvTear, PathErr
  *>    and ResvErr.)  If no local state information can be associated with
  *>    the message, the receiver MUST NOT treat the message as out of order.
  *>    If local state can be associated with the message and the received
  *>    Message_Identifier value is less than the most recently received
  *>    value associated with the state, the message SHOULD be treated as
  *>    being out of order.
  *> 
  *>    Note that the 32-bit Message_Identifier value MAY wrap.  To cover the
  *>    wrap case, the following expression may be used to test if a newly
  *>    received Message_Identifier value is less than a previously received
  *>    value:
  *> 
  *>        if ((int) old_id - (int) new_id > 0) {
  *>           new value is less than old value;
  *>        }
  *>    "
  *>

---

From: "Feng, Mark" <[email-masked]>
Date: Tue, 17 Jul 2001 14:24:46 -0700

Sorry for the late reply, I was busy on other things for a while...

I am not sure what problem we will have due to route changes. But if the
check is necessary, and I agree it is a nice thing to have, your suggestion
seems to be quite reasonable.

Thanks.

- Mark

> -----Original Message-----
> From: Ping Pan [mailto:[email-masked]]
> Sent: Monday, July 16, 2001 11:40 AM
> To: Feng, Mark
> Cc: [email-masked]
> Subject: Re: RFC 2961 - detectoin of out-of-order msg
> 
> 
> "Feng, Mark" wrote:
> > 
> > I agree the check for duplicate message ID should be there. 
> I meant the
> > check and subsequent action for out-of-order message ID 
> could be skipped.
> > 
> 
> Mark,
> 
> Out-of-order message ID checking must be done, otherwise, I fear bad
> things will happen due to route changes.
> 
> > As for duplicate message ID, since there could be multiple 
> receivers, each
> > receiver would not know if it has received a message ID 
> which has been used
> > by other receivers. It is really up to the sender to ensure that.
> >
> 
> Receivers do know that. At a receiving node, the message-id's that are
> arrived from a previous/next hop on a particular interface must be
> unique and increasing. Only looking at the msg-id itself is 
> not enough.
> 
> - Ping
> 
> > Thanks.
> > 
> > Mark
>