Standard Token Bucket Terminology

P.F. Chimento May 18, 2000

The Token Bucket Model

This document tries to explain standard token bucket terminology and to give an example of how the token bucket works as a shaper (generator) of a stream with particular characteristics and as a policer of a stream with particular characteristics. First, a picture (See Figure 1): The operation of the bucket is as follows: Data ows into the mecha-

X
Simple Token Bucket Configuration
Figure 1: A simple Token Bucket nism from the left in quanta called packets. Token ow into the bucket (green) from the top at rate . When the bucket is full of tokens, new tokens are thrown away. Each token is worth a dened number of bytes. It is easier if we think of each token as being worth one byte. When a packet arrives from the left, if there are a number of tokens in the bucket at least equal to the number of bytes in the packet, the packet may exit the system immediately. If there are not enough tokens in the bucket, then one of a number of things may happen, depending on how the token bucket is being used: 1. The packet may be thrown away. 2. The packet may be marked in a particular way. 3. The packet may be buered (by inserting a buer between the inow and the decision point) and not released until a sucient number of tokens arrive in the bucket. There are a number of things to note about this picture: 1. The rate is the long-term rate at which the data ows out of the bucket. 2. The bucket depth is the maximum amount of information that can ow out of the bucket backto-back (i.e. with arbitrary spacing).

3. When the bucket is being used as a shaper, the outow rate is usually termed the peak rate which can in fact be much faster than the rate denoted by . This rate can be controlled to be a particular rate by inserting another buer/decision point after the token bucket. If no special notations or adjustments are made, is assumed to be the physical line rate of the output link. You can think of as the sustained rate at which the data can exit the token bucket system and you can think of as the size of the burst which can ow out of the system at the peak rate . Note that the device has a memory by reason of the bucket.

Relationship to QPS Trac Conditioning

The token bucket model provides standard terminology for describing the behaviour of a trac source. Thoudh it is not clearly stated in [1], I assume that we are talking about the use of the token bucket as a shaper for an aggregate. Because of this assumption, we would have to add a shaping buer to Figure 1 in front of the decision point. It should be clear from the above description that bucket depth is the same as what is intended in [1] by the term MTU. However, this appropriation of the term MTU is confusing because it conicts with the generally accepted denition of MTU and I recommend that its use be abandoned. The denition of peakRate in [1] is captured by the token bucket rate, as dened above. Because of the memory (i.e. the bucket) in the model, there is no need for the auxillary denitions in [1]. Specically, TMT U as dened in [1] is unnecessary because the token bucket bounds the amount of data that can be transmitted in any given interval. Given an interval of length seconds, and an initial bucket content of B bits, the maximum ow from the bucket into the network is + B bits. This assumes that , the exit rate (also known as the peak rate, not equivalent to peakRate as dened in [1]) is (much) faster than . Note that as , the maximum ow into the network from the token bucket approaches . Because the token bucket is dened in terms of bytes, it is independent of packet size and so the parameter PacketSize is not needed. The parameter BurstSize as dened in [1] is actually harmful because it may limit the number of packets transmitted if they are smaller than PacketSize.

Proposal

In order to keep to more or less accepted terminology and concepts, I suggest that the token bucket model, as described in [2] for example, be adopted as the trac descriptor for QPS and for the Bandwidth Broker design. Further, I think that a good model for us is the TSPEC as described in [4] and [3]. These RFCs have good descriptions of the parameters necessary to describe trac streams in terms of token buckets. If this proposal is accepted, we can work out some detailed denitions and format descriptions.

References
[1] R diger Geib, QPS Trac Conditioning, unpublished working document, May 2000 u [2] Craig Partridge, Gigabit Networking, Addison Wesley Publishing, 1994 [3] J. Wroclawski, Specication of Controlled-Load Network Element Service, RFC 2211, September 1997 [4] S. Shenker, C. Partridge, R. Gurin, Specicatino of Guaranteed Quality of Service, RFC 2212, e September 1997