Subject: RE: Doubt about Refresh reduction

From: Khuzema Pithewan <[email-masked]>
Date: Thu, 14 Feb 2002 11:57:23 +0530

How would you make "Out of Order" check on Error Messages...

consider following scenario...

	L1---------L2--------L3

if L2 sends PATH message contains the messageID generated at L2  to L3. In
reponse of this message L3 sends a PATH Error message back to L2 which
contains the message ID generated at L3. Now at L2 how to check whether this
error message  is out of order or not.

RFC says....

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

Assume here messageID received in the error mesage is less than the largest
value received from L3 till now and we have not received RESV message from
L3 yet .. so how u will determine the "Out of order" message here??

Khuzema.

> ----------
> From: 	Suresh Katukam[SMTP:[email-masked]]
> Sent: 	Thursday, February 14, 2002 7:40 AM
> To: 	Sandeep B
> Cc: 	[email-masked]
> Subject: 	Re: Doubt about Refresh reduction
> 
> 
> I think it is useful to have Message IDs for all messages. Even for 
> optical/SONET links too.
> If you have OF/OB, or IF/IB control channels, it is quite possible that
> you 
> wanted to send
> a refresh PATH message and then send a PATH TEAR. If you do not use
> message 
> ids,
> it is quite possible that PATH TEAR may come first and then the PATH 
> message at the
> other end. This would tear down and create the circuit at the other end of
> 
> the link.
> 
> In effect, to find out of order messages.
> 
> -- Suresh
> 
> At 03:48 PM 2/13/2002 -0800, Ping Pan wrote:
> >If I recall correctly, at one point, we were worried about the noisy 
> >links, where without some sort of ack, RSVP messages may get dropped. In 
> >this case, having msgids for teardown and error would be nice. Depending 
> >on where you want to apply refresh reduction, you have the option where
> to 
> >apply msgid's. On SONET/optial links, I am not sure it's useful to use 
> >msgid for error and teardown messages.
> >
> >2 cents,
> >
> >- Ping
> >
> >
> >Sandeep B wrote:
> >
> >>I have a more basic question.
> >>Ping -
> >>Why do we need to send PATHTEAR, RESVTEAR, PATHERR, RESVERR with Msgids.
> 
> >>These are all triggered messages and what purpose do they solve when we 
> >>send these packets with msgid.
> >>-Sandeep
> >>
> >>_________________________________________________________________
> >>Send and receive Hotmail on your mobile device: http://mobile.msn.com
> >
> >
>

---

From: Suresh Katukam <[email-masked]>
Date: Thu, 14 Feb 2002 08:49:03 -0800

I think the main reason for all these questions and confusion
comes from how MESSAGE_ID is used. In many other
protocols, you have a sequence number to identify ooo
(out-of-order) messages and a circuit/Call ID to identify
a Call/LSP.

With Refresh Reduction, We are trying to use MESSAGE_ID
to identify a state (or a LSP or a call) and also to identify
ooo messages. This is not necessarily the best mechanism
and causing lot of issues and I am positive that this will cause
inter-op issues too. Infact, there were issues when OUNI interop
tests were conducted. During that, we used only message_id and
no Srefresh mechanism.

Anyways, to answer your question.. see in line

>L3 yet .. so how u will determine the "Out of order" message here??

If you received a PATH error from L3 with messageID less than the largest 
received,
I would not process this message. The RFC says that if the Epoch values match,
message_id < previously received value, then check the state. If there is 
no state,
then it is certainly out-of-order message. It says "SHOULD check the value
previously received for the state....". It is not must and it also does not 
explicitly state
what happens if there is no corresponding state. It is logical to conclude that
if there is no state, then it is OOO message.

Thanks,
Suresh

---

From: Manas Kamal Bhattacharya <[email-masked]>
Date: Thu, 14 Feb 2002 14:11:34 -0800

The MesgId & Srefresh extensions are useful for reducing the refresh
overhead for rsvp states. The use of Mesg Id in Path and Resv gives
significant improvement in reducing protocol processing load. If a trigger
Path/Resv message arrives you got to do full protocol processing for the
packet, but all subsequent refreshes for this state will come with the new
Mesg Id. In Path and Resv messages use of Mesg Id will also help in
detecting out of order messages. The implementer has the option of using
mesg Id along with Ack to provide reliability.

Coming to mesg id in the Tears and Errors. The only reason why an
implementer MAY choose to use include Mesg Id in outgoing Tears and errors
is to provide some reliability using the ack mechanism. One cannot use Mesg
Id in the Tear/Error messages to reduce protocol processing load or even to
detect ooo packets, if some implementation does this there may be interop
issues.  This becomes apparent from Section 4.5 in RFC2961. 

Please read the rest of my comments inline. 

>-----Original Message-----
>From: Suresh Katukam
>Sent: Thursday, February 14, 2002 8:49 AM
>To: Khuzema Pithewan
>Cc: Sandeep B; [email-masked]; Manoj Agiwal
>Subject: RE: Doubt about Refresh reduction
>
>
>

[Manas] Suresh, you cannot assume that the packet is ooo, if a matching
state block is not found and the new mesg id is less then the mesg id
previously received from the neighbor. There is also another possibility
that the mesg id has wrapped around. Also what about this case:
You have one  LSP, L1 and you want to setup a new LSP L2. So you send a Path
For L2(with mesg id 100), now for some reason you are tearing L1, so you
send PTear for L1(with Mesg Id101). The PTear for L1(mesg id 101) somehow
arrives before the Path for L2(mesg id 100). So 101 is the last received
mesg id from the neighbor. Now when the Path(L2,mesgid 100) arrives, we do
not have a matching PSB( as this is the first Path for the LSP L2) and the
last received message id is 101.  You cannot drop this Path for L2 message.

I agree with Ping that is may not be a good idea to use mesg id in Tear and
error message. However if we receive a Tear or Error with Mesg Id( with ack
desired) we should be able to send an Ack message. Mesg Id in Path/Resv and
also Srefresh are pretty good optimizations to reduce protocol processing
load.

Thanks,
Manas

---

From: Suresh Katukam <[email-masked]>
Date: Thu, 14 Feb 2002 17:05:41 -0800

Manas,

At
>mesg Id along with Ack to provide reliability.

This is correct.

>issues.  This becomes apparent from Section 4.5 in RFC2961.

I agree that is what the RFC says. But I am not sure whether this is correct.

>last received message id is 101.  You cannot drop this Path for L2 message.

Here is another scenario: source wants to send a Full PATH message as
a refresh, and then send a PATH TEAR . But at the other end, PATH TEAR
was received. So PATH STATE and everything is removed. Now, the refresh
PATH message is received. So the other end considers that this is for a new
LSP and tries to create one. This takes up resources everywhere along the path.
This is wrong to since Source is not going to send a PATH again for this. 
The worst
thing is that, if Source wants to send another PATH with different 
parameters (but
same session/sender template), then the other end sends a PATH error.

This would cause more problems than dropping a PATH message for L2 in
your example. In your example, if I drop PATH, Source will atleast retry. 
In the
case I described, you will waste resources and will not be able to set up 
new circuits.

Best bet is to separate Message ID from Call Reference (Call ID) and use 
two ids
for two different purposes.

Thanks,
suresh

---

From: Manas Kamal Bhattacharya <[email-masked]>
Date: Thu, 14 Feb 2002 19:34:18 -0800

Suresh,
Please read my comments inline.

>Sent: Thursday, February 14, 2002 5:06 PM
>To: Manas Kamal Bhattacharya
>Cc: Khuzema Pithewan; Sandeep B; [email-masked]; Manoj Agiwal; 'Ping Pan'

[Manas] This section of the RFC is unclear on the usage of 
Mesg Id on Tear and Error message. The implementer has the 
choice of including the mesg id in the Tears and Errors. 
However if once decides to use Mesg id in outgoing Tears and
Errors, it should be used ONLY to provide reliability. No 
performance gain can be achieved and if we use it to detect
ooo packet, the results cannot be guaranteed to be consistent.

>same session/sender template), then the other end sends a PATH error.

[Manas] If sender wants to setup a new LSP but sends a new Path
with same (session/sender tmpl) then it looks more like an 
implementation issue. Coming to the receiver even if some of 
the parameters are changed in the new Path message, it is not 
necessary that the receiver will always send a Path Err. 

>case I described, you will waste resources and will not be 

[Manas] I agree that resources will unnecessarily be held up till 
the lone PSB times out. If we look at the from another side. If the
Path is dropped and a refresh comes it will also have the same mesg
id as the previous Path we just dropped. So the LSP will not come up
until the mesg id in incremented after a cleanup timeout. 

I am sure we can come up with many such scenerios. But the fact is
that Mesg Id with Tears and Errors will not give a consistent result 
in many cases.

>for two different purposes.

[Manas] In RSVP-TE with MPLS we do not use Call Refrence to identify
any message or state block. 

Thanks,
Manas

---

From: Sreedhar Reddy <[email-masked]>
Date: Fri, 15 Feb 2002 12:46:31 +0530

Hi ,

***************************
Suresh Wrote-->

If you received a PATH error from L3 with messageID less 
than the largest received,I would not process this 
message. The RFC says that if the Epoch values match,
message_id < previously received value, then check the 
state. If there is no state,then it is certainly 
       -----------------------------------------
out-of-order message. It says "SHOULD check the value
--------------------
previously received for the state....". It is not must 
and it also does not explicitly state what happens if 
there is no corresponding state. It is logical to 
conclude thatif there is no state, then it is OOO 
message.
******************************

   First let us take the underlined statement. If it is
not a Typo then , As per RFC message_id < previously 
received value AND If there is no state the message is
NOT an out of order message. And ALL In Order messages
which are not Refresh messages should be FULLY processed.

I think the algo should be something like this:
( Assuming same Epoch Value):

IF recd_msg_id > larg_msg_id_in_store
    process the message ( I think none of us have 
                          any issues here)
IF recd_msg_id < larg_msg_id_in_store
   Get the state corresponding to this message
   If NO State
      Consider as Inorder message. Process the Massage
   If State Present 
      If STATE_msg_id > recd_msg_id
           out of order message. Ignore.
      else IF recd_msg_id > STATE_msg_id
           You might need to adjust Bandwidth etc for
            this state/Err/Tear message for this state
            STATE_msg_id = recd_msg_id
      else IF recd_msg_id == STATE_msg_id
           Refresh Message

Keeping in mind that 

 * ALL In Order messages which are not Refresh messages 
   should be FULLY processed
 * Use message ID only for those messages which are of
   refresh in nature and for other types where 
   reliability is required , use ONLY with
   ack_desired flag set and while retransmitting in case
   of no ack in time, with Message Id which is currently
   being used( next largest available not with the same 
   message_id )

hopefully should solve all these problems

Sreedhar Reddy

PS: If the above guidelines are followed the L1,L2,L3 
  case of Manas/Suresh also can be solved as follows.
  As L3 drops and wont send ack for PathMsg for L2 LSP,
  L2 times out and sends another PathMsg for L2 LSP THIS
  time with the msg_id greater than 101 which is 
  acceptable to L3 

> ----------
> From: 	Manas Kamal Bhattacharya[SMTP:[email-masked]]
> Sent: 	Friday, February 15, 2002 9:04 AM
> To: 	'Suresh Katukam'; Manas Kamal Bhattacharya

---

From: Manas Kamal Bhattacharya <[email-masked]>
Date: Thu, 14 Feb 2002 19:34:18 -0800

Suresh,

Thanks,
Manas