Subject: Service disciplines for RSVP 7/08/95 7/08/95 21:35:45

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Mon, 10 Jul 95 07:14:04 EDT

Reference:  Your note of Sat, 8 Jul 1995 21:35:45 PDT

>I wonder if my understanding of "rate-controller" is somewhat
>different from yours--to strictly limit the rate to be within a
>specific value, isnt it necessary that the system has to be non-work
>conserving?

I think we have the same definition of a rate-controller, e.g., a
leaky bucket or some other mechanism which is meant to limit the
envelope of the traffic which can enter the network or node.
If the operation of such a device is independent of the state of
the network/link and of the scheduler, as it is in most rate-controlled
service disciplines, then we indeed end-up with a non-work-conserving
system.  However, a simple modification of the operation of the
rate-controller can make the system work-conserving.  Specifically,
rate-control is only enforced when there is contention on the
link, i.e., if the link is idle you can send packets even if they
have not yet cleared their rate-controller.  Such a modification has
been proposed in a number of contexts, but the issue is then what
it does to the "guarantees" that the non-work-conserving version
of the policy provides.  What we show in the report is that the same
guarantees can be provided under the work-conserving version than under
the non-work-conserving one.
Roch

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 10 Jul 1995 21:57:28 PDT

> However, a simple modification of the operation of the

that sounds great!
actually that's my intuition too.  Scott and I talke about this in the
past: one simply cannot cause delay violation by sending a packet
out earlier :-)
did you also looked at the buffer occupancy issue?  i.e. would
work-conserving rate-control cause downstream nodes more buffer space
that the non-work conserving version?

Lixia