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

From: "Feng, Mark" <[email-masked]>
Date: Mon, 16 Jul 2001 09:21:48 -0700

Hi Ping,

The proposed work-around seems to work. However, for use of summary-refresh
extension, that means potentially quite a number of connections/states need
to be re-synchronized.

The other work-around is not to do the check. If the check is not done, the
result is no worse than the normal RSVP (RFC 2205), which does not have such
mechanism in place, but rely on soft-state instead. The RFC 2961 mentions
the receiver "should" do it; so it is not a "must":-).

Thanks.

Mark

-----Original Message-----
From: Ping Pan [mailto:[email-masked]]
Sent: Friday, July 13, 2001 9:29 PM
To: Feng, Mark
Cc: [email-masked]
Subject: Re: RFC 2961 - detectoin of out-of-order msg

"Feng, Mark" wrote:
> 
> 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.
> 

Mark,

One solution is that when the message id becomes too big, the router
simply changes the epoch value, and start to send the id from a low
number again. In this case, if you use the Ack-extension only, the
receiving node will simply update the states to the new id's in the next
refresh cycle. If you use the summary-refresh extension, the receiving
node will nack the summary-refresh messages due to epoch change. The
sending node will have to reply a bunch of messages to sync up the id's.

I know the RFC said something like epoch value should not change unless
the router has restarted.... Well, the router does restart the message
id now. :-)

- Ping

> Thanks in advance.
> Mark

---

From: Ping Pan <[email-masked]>
Date: Mon, 16 Jul 2001 10:02:15 -0700

Mark,

Yes. But I think it's OK when you use exponential backoff timers (or
staged refresh timers). Since each refresh cycle is much larger now, I
don't think you will have a hugh burst of trigger messages. Also how to
control the amount of messages being sent over the wire is an
implementation issue.
 
> the receiver "should" do it; so it is not a "must":-).

Don't like it. :-) Remember you must not send the same msg-id for two
different messages. Without checking, it would be tough to achieve this.

- Ping