Subject: Proposal for the inclusion of peak r 8/28/95 19:09:41

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Mon, 28 Aug 95 19:16:26 EDT

>If I have a (bursty) source with a peak rate of 10mb/s, which is then
>reduced to a peak rate of 1mb/s by a router in the middle of the net,
>the bursts will be smoothed somewhat. If a later router in the path
>has 155mb/s outgoing links, the traffic at that point might end up
>very bursty, with a higher peak rate than 10mb/s.
>
>Routers lowering the peak rate isn't the real issue. Routers that
>raise it seem more problematic.

Raising the peak rate may be an issue, but can be handled by providing
sufficient buffering as is requested in the current specs.  The required
sizes are given in the proposal we sent, using somewhat tighter
expressions than the original ones.  This was possible in part because
we did not assume that the whole burst of b could arrive instantaneously.
Note that in any case the provision of a clearing rate limits the
increase in burstiness, irrespective of link speeds.
Note also that changes in the "peak rate" caused by different link
speeds do NOT (except through the D term) affect the delay bounds.

>It seems to me that two possibly correct answers when considering
>a single source are:
>
> 1) routers do not modify the Tspec when the peak rate is lowered, but
>may modify the peak rate -upward- if required, or
>
> 2) routers do not modify the Tspec at all, but are required to
>reshape traffic to prevent it exceeding the TSpec peak rate.
>
>Of these, the second seems to impose more requirements on a router
>than the first.

You do not need to modify the peak rate upward (or downward) in the
TSpec, as a function of the link speeds, if you are only concerned
about the delay guarantees.
On the other hand, if you want to lower the buffer requirements, then
reshaping can help.  Actually, you can even reshape down to the clearing
rate R without impacting the delay bound (this is in essence what happens
when you get backlogged at a router).

Roch

---

From: Philippe Oechslin <[email-masked]>
Date: Wed, 30 Aug 1995 10:29:11 +0200

Some thoughts about reshaping and modifying the peak rate:

[email-masked] said:
> [someone said:]

> when you get backlogged at a router).

One of the arguments for introducing peak rate in Tspecs was that it
is needed for the establishment of connections through ATM
clouds. This is a Good Thing as it could allow to map traffic flows
directly to ATM connections. However, care has to be taken about
policing happening in the network, since conforming traffic may become
non-conforming after it has traveled through several nodes. 

Modifying the peak rate upward doesn't seem a viable solution as you
may end up requesting the maximal ATM bandwidth, which is as good as
not giving a peak rate. Reshaping to the original Tspec seems to be
a better solution. 

If a node at an IP/ATM boundary establishes an ATM connection with the
original Tspec (peak rate unmodified), it will have to reshape the
traffic or risk to have some data discarded by the policing of the ATM
network.

The same holds for RSVP. In RSVP policing based on Tspecs can be
requested at data merge points (and also at edges).  Again, if the
traffic is not reshaped, it may be discarded although it originally
conformed to the Tspec.

Thus, reshaping seems unavoidable if policing is done within the network
and policing within the network seems unavoidable if one establishes ATM
connections at IP/ATM boundaries.

Nodes at which policing is being applied (ATM and/or RSVP) can be aware
of that fact (note that in RSVP this can change dynamically). Thus one
can limit reshaping only to those nodes that know that they are being
policed. For other nodes there doesn't seem to be a need for reshaping.

   -Philippe

--
Philippe Oechslin                                    mailto:[email-masked]
Communication Networks Laboratory (LRC)               Phone:  +41(21) 693 66 16
Swiss Federal Institute of Technology (EPFL)            Fax:  +41(21) 693 66 10
CH-1015 Lausanne, Switzerland                   http://lrcwww.epfl.ch/~oechslin