Subject: Re: RSVP Hierarchy Summary Refresh draft

From: [email-masked]
Date: Fri, 5 Nov 1999 14:22:29 -0800

*> 
  *> If I were coding this, I'd just have a pointer form the PSB or RSB to
  *> the Srefresh message.  If the PSB or RSB is updated causing a trigger

George,

The bookkeeping is slightly more complex, I think.  A given PSB or RSB
will in general appear in multiple Srefresh messages, corresponding
to different next/previous hops.  And the Srefresh message may need
pointers back to all the RSBs that contributed to it, won't it?
Also, an Srefresh message needs a pointer to the 2nd-level Srefresh
message, which was the actual target of my question.

It occurs to me that your bookkeeping is probably easier than in the
UCLA state compression scheme, because they had to preserve order
to make the hash come out right. This caused problems when a particular
message moved from one Srefresh to another.  I think you do not care
about ordering, so yours is simpler.  (I think).

  *> message, then the Srefresh is invalidated.  The simplest thing to do a
  *> this point is to delete the one message ID, give the Srefresh a new
  *> message ID and set the ack=request bit.  You delete the old Srefresh
  *> message Id from the hierarchical Srefresh.  You add the new Srefresh
  *> message ID after the Srefresh has been acked.
  *> 

I think you are probably right here, but it is confusing because you
don't say which level of Srefresh you mean.

  *> >3. You suggested that the processing rate for Srefresh messages can be
  *> >	less than the rate of refreshing Srefresh messages. Can't it
  *> >	also be greater, ie., isn't it true that the two rates are
  *> >	entirely decoupled?
  *> 
  *> I have no idea why one would want to do such a thing, but nothing
  *> would break if you did.
  *> 
How about: the network congestion has increased and you now want
to refresh Srefresh messages more slowly, but the existing state
has its original refresh timeouts?

Bob

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 07 Nov 1999 22:02:49 -0800

At 02:22 PM 11/5/99 , [email-masked] wrote:
>message moved from one Srefresh to another.

In UCLA scheme, no particular msg would move from one 
Srefresh to another because each session is hashed to a
specific slot in the hash table.

> I think you do not care

Now I finally caught up with all the I-Ds, I feel a little confident in
speaking out: I am yet to be convinced that George's bookkeeping is any
easier than the UCLA scheme, especially if one's goal is good reduction of
number of messages in the presence of lots lots RSVP sessions (and as Bob
pointed out earlier, lots senssions lead to a high change rate per second,
even when each session has a reasonably long life time).

Also as Bob pointed out, I believe that the router needs pointers in both
directions (PSB or RSB to refresh message, and refresh msg to PSB/RSB) for
quick state update or ID update or summary update.

- Consider a case of 90,000 sessions, I would be worried
  about keeping up with those pointers.

- UCLA scheme does not necessarily uses a hash table.  I dont
  see why the scheme cannot do the same thing as George's scheme,
  that is a router tells a neighbor which sessions are included
  in a state summary computation, and then compute (instead of 
  just assigning) an ID for that set of session state.
  Doing a hash is, at least it looks to me, a much easier and
  systematic way to keep track of which sessions are included 
  in which summary msg.

Lixia

---

From: Masanobu Yuhara <[email-masked]>
Date: Mon, 08 Nov 1999 22:09:41 +0900

braden> It occurs to me that your bookkeeping is probably easier than in the
braden> UCLA state compression scheme, because they had to preserve order
braden> to make the hash come out right. This caused problems when a particular
braden> message moved from one Srefresh to another.  I think you do not care
braden> about ordering, so yours is simpler.  (I think).

Yeah, Srefresh^2 (read Srefresh's Srefresh) is simpler than the UCLA
scheme.  Since there's no restriction on how the sender builds up the
hierarchy, it is more flexible.
If I were to implement Srefresh^2, I might check the age of each
state and collect only ancient states (which are expected to be
stable) for the higher level Srefresh; Similar to the idea of
generation scanvenging Garbege Collector.

Srefresh^2 is an extention to Srefresh, and Srefresh itself is not
yet well established, so I recommend to leave it aside from the
refresh-reduct draft. Why not finish with the refresh-reduct draft and
then extend it later if necessary.

------
Masanobu Yuhara		[email-masked]
Fujitsu Laboratories Ltd.