Subject: guaranteed delay & reshaping/policing

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Fri, 1 Mar 96 18:17:40 EST

Reference:  Your note of Wed, 28 Feb 96 16:28:57 EST

jj, some possible answers to your questions.

>A few comments/questions on the reshaping/policing aspects of
>Guaranteed:
>
>
>   reshaping points (reshaping points are defined below)
>
>The text says this twice, but there is never any formal definition of
>a reshaping point.

My definition of a reshaping point, although it may not be the most
formal, is a device that ensures that irrespective of what traffic it
takes as input, the output conforms to a pre-specified TSpec.  In the
context of the Guaranteed Service, this would typically be the TSpec
specified by the flow (or some smaller one, provided you can guarantee
it does not affect the GS bound).  In terms of operation, such a
device releases packets at the earliest possible
time that is consistent with being conformant with the TSpec

There are a number of ways to do that.  One way is to keep track of the
amount of traffic you have sent and check if sending the next packet
will cause you to violate the TSpec constraint.  If not, you can send it
right away, otherwise you can easily compute the earliest time at which
sending it will not cause a violation and then hold to it until that
time.

>It also never says when or why a particular node
>would designate itself as a reshaping point.  Does this just map to
>the policing points?

This is probably related to identifying the benefits of reshaping, and
they are essentially in terms of the buffer requirements for downstream
service elements.  There is no hard requirement for a node to designate
itself as a reshaping point.  You could decide to have all nodes in
your network doit, or alternatively you could base that decision on the
current values of the Csum and Dsum values since the last reshaping
points.  My personal view is that for the Guaranteed Service, I'd
probably recommend doing that at all nodes.  You pay a price in terms of
an increase in average delay, but I think the benefits in terms of
buffering and better manageability of the traffic outweigh it.  Note
that I would clearly not recommend doing it for all other service
classes.

Now, in terms of the relation to policing, if you do reshaping
what comes out of the shaper is by definition conformant, and would not
be affected by policing.  The issue is, however, what you can assume
for what is coming into the shaper.

If you know that what came out
of the source was initially conformant to the TSpec, then you don't
need to worry about policing and only to make sure that you have enough
buffer to hold packets which may be held back by the reshaper. This is
because any non-conformance you are trying to remove through reshaping,
was caused only by variations in queueing delays inside the network,
and the Guaranteed Service tells you how much buffer you need to be
able to deal with that.

The key assumption here is that you know that what entered the network
was initially conformant.  This is why you need to do policing at the
edge of the network.  This is meant to check that the users indeed
conform to what they advertised as their TSpec (don't want to trust
them on that one...)  At this point you can do *hard* policing, i.e.,
drop packets that are not conformant or mark them as best effort if
that capability is available.  However, note that depending on how the
source is attached to the network, you may still want to do some level
of reshaping even at the edge.  For example, if the source has to
cross another network first, this may then perturb its traffic so that
it may appear as non-conformant even if it was not to start with.
Doing some minor reshaping will ensure that you do not unnecessarily
drop or mark a packet.  This is exactly what would happen inside the
network if you were doing policing there, and that's the motivation
for the statement below.

>
>   Inside the network, this approach does not produce the desired
>   results, because queueing effects will occasionally cause a flow's
>   traffic that entered the network as conformant to be no longer
>   conformant at some downstream network element.  Therefore, inside the
>   network, service elements must reshape traffic before applying the
>   token bucket test.  Reshaping entails delaying packets until they are
>   within conformance of the TSpec.
>
>I think this confirms that policing nodes and reshaping nodes are one
>and the same.  If so, we should explicitly say that.

Inside the network you can do reshaping but wont do policing, or if you
do it after the shaper it wont have any effect since the flow leaving
the shaper is by definition conformant.  The assumption is that you
know the flow has been policed at some point upstream, i.e., at the
network edge.  There you can do policing without any shaping, although
as I mentioned, it might be wise to still do some minor shaping.

>
>   regulator should start with its token bucket full of tokens).  Under
>   guaranteed service, the amount of buffering required to reshape any
>   conforming traffic back to its original token bucket shape is
>   b+Csum+(Dsum*r), where Csum and Dsum are the sums of the parameters C
>   and D between the last reshaping point and the current reshaping
>   point.
>
>This only addresses the distinct reservation scenario (one sender, one
>reservation).  We need some text here to say what happens if this is a
>shared reservation and the router is at a source branch point (i.e.,
>when you have to take multiple Tspecs into account, and the sum of the
>Tspec rates may be less than the clearing rate).

Not sure I fully understand the scenario here, so maybe we can talk
about it in LA.

Roch