Subject: RE: Object ordering in RSVP Messages

From: Bob Braden <[email-masked]>
Date: Sat, 29 Sep 2001 15:09:47 -0700 (PDT)

*> 
  *> My apology for the bad wording. I am not saying to remove the objects
  *> physically. Instead, after the Ack/Nack objects are processed, no further
  *> action needs to be taken against them. Then the message can be processed as
  *> a regular message.
  *> 
  *> Imagine the Ack/Nack is scattered all over the place in, let's say, a Path
  *> message. The module/function that is responsible to handle the Path message
  *> would have to constantly  look out for any potential Ack/Nack objects, which
  *> are not even related to that particular PSB, and involves different kind of
  *> processing.
  *> 

"Constantly look", e.g., a "case" in a switch statement.  Then a subroutine
call, say, pushing the context onto the stack.  And the ACK/NACK object
carries a handle that hopefully (!) avoids a full PSB lookup.  But are
you sure it wouldn't necessarily be the same PSB?

I really don't think there is a problem that competant implementation
cannot solve.

Bob Braden

---

From: Ping Pan <[email-masked]>
Date: Sat, 29 Sep 2001 17:30:00 -0700

> you sure it wouldn't necessarily be the same PSB?

The idea of msg-id in Ack/Nack is to avoid rsvp flow lookup. It is
important to keep track of id's and epoch correctly. Repeat what Bob had
said, when you are sending the messages, try to be nice and considerate.
On receive, always do your best to process whatever you can efficiently.
 
> I really don't think there is a problem that competant implementation

:-) Yep!

- Ping