Subject: Re: RSVP Hierarchy Summary Refresh draft

From: [email-masked]
Date: Thu, 4 Nov 1999 12:43:37 -0800

George,

A few minor comments on your interesting (and laudably terse) draft:

1. On the sender side, the sender must be prepared to save each (sub-)
	Srefresh message and retransmit it until ACK'd  (You indicated
	only what the receiver has to do).

2. It seems to me it might be tough for a sender to do the
	bookkeeping necessary to figure out when a particular saved
	Srefresh has changed, ie, when it has to send a trigger
	Srefresh.

	I guess one solution would be for the sender to periodically
	regenerate each saved Srefresh and then compare the result
	against the saved value; if it was the same, its message ID
	could be included in the higher-level Srefresh.  Then the
	hierarchy would save network bandwidth and receiver work, but
	it would not benefit the sender.

	Have I got this wrong?

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?

4. You state that a two-level hierarchy can refresh 90,000 messages
	with a single messge, using an MTU of 1500 bytes.  However, I
	have a real hard time imagining that it will EVER get the
	chance.  Given any reasonable thrash rate, the chances of all
	90,000 reservations staying the same for 30 seconds must be
	very small indeed.  This does not really reduce the
	effectiveness of your scheme a whole lot, though it would be
	good to have some numerical idea of how much.

Bob

---

From: George Swallow <[email-masked]>
Date: Fri, 05 Nov 1999 14:55:40 -0500

Bob -

>	only what the receiver has to do).

Actually the sender doesn't *really* have to do this.  The point
should be the the sender saves the message for as long as it is useful
for her.  If one of the message IDs becomes invalid, then it shouldn't
be saved.  Also the sender might decide to combine it with some other
Srefresh message (creating a new Srefresh make the the previous ones
obsolete.)

But point well taken that some text for the sender side would be
useful.

>	it would not benefit the sender.

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

>	also be greater, ie., isn't it true that the two rates are

I have no idea why one would want to do such a thing, but nothing
would break if you did.

>	good to have some numerical idea of how much.

Two small points.  If one message changes then I have to 

1. For MPLS LSPs, I was thinking that one might send the hierarchical
refresh much more often than 30 seconds.

2. Suppose there is a trigger event.  The I continue to send the
hierarchical refresh but without the message ID of the one affected
Srefresh.  And I have to send a new Srefresh.

So as far as the effectiveness of the scheme goes.  Suppose that
without the hierarchical scheme I'm sending n messages.  During the
refresh interval k of them change.  Then without the heirarchy I'm
sending n messages every interval.  With it I send k+1 messages.  The
usefulness of the scheme is really tied to the life-time of the
underlying Srefresh messages.  

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824