Subject: guaranteed rate service specificatio 7/13/95 18:38:14

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Fri, 14 Jul 95 08:14:59 EDT

Reference:  Your note of Thu, 13 Jul 1995 18:38:14 -0500 (CDT)

Pawan,

After reading your response, I think we are in agreement on
several points, but we look at them differently.  So, let me try to
clarify my views, and also point to where I think we may still have
different perspectives.
I have only kept material from your last response as after three levels
of embedding, things start getting confusing.

>Yes, one can do that also. However, in such a scenario a source
>would have to buffer all the packets which would increase the average delay.
>If an application does not care about the average delay performance, then
>this may be acceptable. The network, IMHO, should allow a source the
>flexibility to receive guaranteed worst case performance while achieving a good
>average case performance. By reserving buffers and rate separately and not
>making leaky bucket a part of the spec, a source
>rather than network, can select the trade-off.

Fully agree with the fact that we should try to avoid providing worst
case guarantees by making all packets experience them, i.e., give poor
average performance.  However, we only need to make sure that the
specs provide that flexibility, and not tie them to a specific solution
which we (currently) think is a good one.  This means that the traffic
and service parameters should not imply a particular approach.  I believe
this was part of the original design point, and I think that the current
specs, albeit with some extensions, can achieve that (more on this
below).  So, I think we generally agree on the goals.
On the other hand, I don't think that reserving buffers (or/and rate)
alone is a good solution as it implies a particular approach in the
network.

>Let us for the sake of simplicity, restrict our attention to
>scheduling algorithms that do not separate throughput allocation
>from delay (for example Virtual Clock and  RPPS assignment in PGPS).
>In such scheduling algorithms  for an allocated
>rate, the maximum e2e delay, considered from the packet generation time to
>the packet delivery time, is the same even if the traffic is reshaped to
>CBR at the access point.  Hence, I am not sure why you believe that
>smoothing would lead to tighter delay requirements in the network.
>
>If the scheduling algorithm separates delay specification from throughput,
>then one can  prove the sub-optimality of smoothing. Indeed this
>was the motivation for CRST rate assignment in PGPS networks. However,
>the current specs do not separate  delay from throughput.

I think we fully agree here.  We need to make sure that delay and
throughput are separated.  This was the motivation of the first note
I sent.  However, as Scott and Craig pointed out, you can do this
with the current specs even if they were not initially meant for that
purpose, i.e., set the rate to infinity and use D as your local delay
bound.  Note that the token rate and clearing rate need not be the
same.

My statement, was motivated by the fact that policies which
separate rate and delay can yield better overall performance
than those which don't, and I was therefore focusing on (assuming)
such policies.  For them, the trade-off between access and network
delays is not a simple issue, i.e., there is an optimal split
between access and network delay which is not necessarily at one
of the extremes (full or no smoothing).

>The key point is that a network supporting guaranteed delay service
>does not have to explicitly guarantee per packet delay.
>If a switch guarantees a rate and a  source conforms to some traffic
>specification, then the rate guarantee translates into a delay guarantee
>for each packet (the delay guarantee would ofcourse depend on the spec).
>It is upto the source to ensure that packet generation process conforms
>to the spec.  If the process does not conform to the spec, although
>the packets would not receive a guaranteed delay, the rate would still be
>guaranteed. This issue is elaborated in the paper that I had cited.

I also agree with the above, but you still need a traffic spec for the
source in order for the network to provision resources.  Irrespective
of the service discipline used, the network must have information
(traffic envelope) on the traffic for which it is making guarantees.
My view is that the current specs, complemented by a maximum rate
value, represent an adequate specification.
The source is certainly free to send more, knowing that the guarantees
may then not be provided to all packets.  The only thing the network
should ensure is that it will at least give the guaranteed service
to a subset of the packets sent which corresponds to a compliant
behavior.  Some networks may drop all non-compliant packets up front,
while others may try to get them across.  Any such behavior should
be acceptable.

Roch