Subject: Re: Proposal for the inclusion of peak rate

From: [email-masked] (Fred Baker)
Date: Thu, 24 Aug 1995 12:52:08 -0700

this has been discussed several times in private and public email.

one thing to think about: the model thinks in terms of the flow
specifications being translucent objects passed around among the parties,
but in this case one would want the switches or routers to actively modify
them. When a flow is going through a switch with a lower access rate than
the advertised peak rate, the peak rate that it should advertise beyond
itself is its own access rate.

I haven't verified your math; The only value in advertising peak rate is if
the router can in fact verify that it will be able to maintain its delay
commitments AND admit the new flow. What I have asked for from others who
proposed doing so was an equation that I can put in the router that will
give me that. I'm going to have to think about whether your math enables me
to do that.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
If you're looking to find the key to the Universe, I have
  some bad news and some good news.  The bad news is -- there
  is no key to the Universe.  The good news is -- it has been
  left unlocked.

---

From: Vinod Peris <[email-masked]>
Date: Sat, 26 Aug 1995 01:59:05 -0400

>>>>> "FB" == Fred Baker's note dated Thu, 24 Aug 1995 12:52:08 -0700
 FB> one thing to think about: the model thinks in terms of the flow
 FB> specifications being translucent objects passed around among the parties,
 FB> but in this case one would want the switches or routers to actively modify
 FB> them. When a flow is going through a switch with a lower access rate than
 FB> the advertised peak rate, the peak rate that it should advertise beyond
 FB> itself is its own access rate.

The problem with modifying the TSpec is that it can result in an
incorrect computation of the end-to-end delay.  By lowering the peak
rate because of a lower speed link on the path, the receiver will be
unable to determine the true peak rate of the flow.  This in turn,
will prevent the receiver from asking for the right rate R that is
necessary to meet its end-to-end delay guarantees.  What this means,
is that the router should not modify the TSpec, even if it includes a
peak rate which is higher than any of its link speeds.

 FB> The only value in advertising peak rate is if
 FB> the router can in fact verify that it will be able to maintain its delay
 FB> commitments AND admit the new flow. What I have asked for from others who
 FB> proposed doing so was an equation that I can put in the router that will
 FB> give me that. I'm going to have to think about whether your math enables m
e
 FB> to do that.

Exactly.  These are just the kind of things (buffer requirements, number
of accepted calls) that adding the peak rate will help you improve on.

--Vinod