The IP over ATM Mailing List Archive by date

[mwg@faline.bellcore.com (Mark W Garrett)]

Jon, Tim et al,

OK, now you've succinctly made a statement that we can discuss
(on my favorite topic these days...).

 > ...while over a long time scale an IP
 > session's rate may be substantially less than line rate, the cells which
 > make up an IP packet will tend to arrive back to back.  Thus the
 > connection's "instantaneous rate" will exceed its negotiated "average rate"
 > (in ATM-ese, its sustainable cell rate or SCR), invoking the policing
 > function.  The policing function will allow the connection to exceed
 > its SCR, for a period derived from MBS.

First, the leaky bucket (or GCRA or UPC) rate parameter is in NO WAY
determined by the AVERAGE RATE of a source.  It is more closely
related to an ALLOCATED rate for the source, and even a statement like
that has to be treated carefully because what you allocate depends on
your scheduler implementation, how the traffic has been jittered, what
it means in your net to allocate resources etc etc.

There is a slight relation in that the rate parameter and allocated
rate must be higher than the average source rate.  To see this,
consider that the source is free to turn off for arbitrary periods of
time.  Thus the average rate can be arbitrarily lower than whatever
has been allocated or set a priori as a description of the traffic.

Now to the point.  Tim is right that the bucket size parameter (i.e.,
MBS) should probably be larger than a IP MTU, since that can clearly
be sent into the network as a single burst.  However much larger
bursts may be present and may be normal.  It depends on the access
line rate, the end equipment's bottleneck rate, what the intermediate
LANs or routers have done to the traffic etc.

Traffic descriptor parameters cannot be decided only on the basis of
knowing the size of the next layer's PDU.  I would be reluctant to
accept any statements about traffic shape or UPC parameter values
derived simply from principles.  We need experimental evidence to
understand how traffic shaping/monitoring/policing really works.
(This is especially true of any statements which have hidden
assumptions based on Markov chain traffic models.)

(I seem to be bursting into flames, sorry...)

-Mark

-------------------------------------------------------------------------------
			Bellcore   Rm. 2L-237			+1 201 829-4439
Mark W. Garrett		445 South St.			mwg@faline.bellcore.com
			Morristown NJ 07960-6438  USA	     (FAX 201 829-2504)
                        WWW: ftp://thumper.bellcore.com/pub/mwg/homepage.html
-------------------------------------------------------------------------------