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

From: [email-masked] (Fred Baker)
Date: Tue, 12 Sep 1995 03:54:23 -0700

You will, I hope, forgive a combined reply?

At 6:28 PM 8/28/95, Vinod Peris wrote:
>The better end-to-end delay bounds that are in the proposal to include
>a peak rate, are a result of accounting for the peak rate at the
>source. Thus, it is important that the peak rate field in the TSpec
>reach the receiver without modification.

I understand that you only want to describe the source, but of what value
is that information if when the data arrives where the reciever is the
information is irrelevant due to changes that have occurred in the network?

At 7:09 PM 8/28/95, John Wroclawski wrote:
>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.

well, yes, maybe. Let's construct a couple scenarios.

first, very traditional. I have a codec on a workstation, and generate data
at basically the slower of the encoder speed and the LAN speed to which I
am attached (and let's presume it's a switched LAN). If I have an MPEG-2
codec, it will average between 3 and 7 MBPS, but at times can reach 12.

When the messages come out, they come out at LAN speed. There is then a
hiatus until the next message is ready. So, one could argue that each
message is a burst at LAN speed, and that there are idle periods. I submit
that this is too fine detail to worry about.

OK, now let's assume that there is a 4 MBPS router, perhaps a low speed
LAN. Whenever the arrival rate exceeds the discharge rate, the discharge
rate will peg at 4 and a queue will form. Traffic will average during a
message an (barring interlopers) for the foreseeable future at 4 MBPS.

Downstream of that, let's presume another ether-router, a DS-3, whatever.
The contents of individual messages will, of course, move at the access
rate, but average over as little as two messages with their intermessage
gaps, what is the output bit rate?

If you answered <= 4 MBPS, go to the head of the class. They can't go into
that pipeline any faster than they are arriving, and the 4 MBPS LAN defines
the fastest rate (other than the access rate for a single message) at which
they can arrive downstream from that point. Which is where I find myself
shaking my head and wondering what 10 MBPS (originator's LAN speed) could
possibly have to do with anything on the 4 MBPS side of the bottleneck?

And now we approach an OC-3 pipe. If ATM, RSVP would likely open a VCI at
average bit rate, with a peak rate of average+10..20% (administratively
controlled).If so, it's not going to transmit at 155 MBPS - it will
probably send at about 4 MBPS. even during the course of a message. The
chip will schedule cells at that rate.

At 7:16 PM 8/28/95, Roch Guerin ((914) 784-7038) wrote:
>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).

I'm not REAL sure I see the value of calculating the buffer. Either I have
enough, or I'm going to drop some traffic. RED aside, what value does
calculating the buffer have for me?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
So Bill Gates has paid Mick and the boys 12 million dollars to use "Start Me
Up" to sell Windows 95.

For those who don't know the song, it's the one that goes "You make a grown
man cry...".

Food for thought