Leaky Bucket - Wikipedia, The Free Encyclopedia

Leaky bucket - Wikipedia, the free encyclopedia
1 of 13
https://en.wikipedia.org/wiki/Leaky_bucket
Leaky bucket
From Wikipedia, the free encyclopedia
The leaky bucket is an algorithm that may be used to determine whether some
sequence of discrete events conforms to defined limits on their average and
peak rate or frequency. It is based on an analogy of how a bucket with a leak
will overflow if either the average rate at which water is poured in exceeds the
rate at which the bucket leaks, or if more water than the capacity of the bucket
is poured in all at once.[1][2][3][4]
The leaky bucket algorithm is used in packet switched computer networks and
telecommunications networks to check that data transmissions, in the form of
packets,[note 1] conform to defined limits on bandwidth and burstiness (a
measure of the unevenness or variations in the traffic flow). It can also be used
as a scheduling algorithm to determine the timing of transmissions that will
comply with the limits set for the bandwidth and burstiness applied by the
network: see network scheduler.
A version of the leaky bucket, the Generic Cell Rate Algorithm, is
recommended for Asynchronous Transfer Mode (ATM) networks[5] in
Figure 1: The leaky bucket
Usage/Network Parameter Control at UserNetwork Interfaces or Interanalogy
Network Interfaces or Network-Network Interfaces to protect a network from
excessive traffic levels on connections routed through it. The Generic Cell Rate
Algorithm, or an equivalent, may also be used to shape transmissions by a Network Interface Card onto an ATM
network (i.e. on the user side of the User-Network Interface), e.g. to levels below the levels set for
Usage/Network Parameter Control in the network to prevent it taking action to further limit that connection.
The leaky bucket algorithm is also used in leaky bucket counters, e.g. to detect when the average or peak rate of
random or stochastic events or stochastic processes, such as faults or failures, exceed defined limits.
At least some implementations of the leaky bucket are a mirror image of the Token Bucket algorithm and will,
given equivalent parameters, determine exactly the same sequence of events to conform or not conform to the
same limits. However, there are at least two different descriptions of the leaky bucket that can and have caused
confusion.[1][2][6]
Contents
1 Overview
2 The Leaky Bucket Algorithm as a Meter
2.1 Concept of Operation
2.2 Uses
2.3 Parameters
2.3.1 Emission Interval
2.3.2 Delay Variation Tolerance
2.3.3 Maximum Burst Size
2.4 Comparison with the Token Bucket Algorithm
07-Sep-16 3:38 PM
2 of 13
3 The Leaky Bucket Algorithm as a Queue

3.1 Uses
3.2 Parameters
3.3 Inefficiency of the leaky-bucket as a queue implementation
4 Comparison Between the two Versions of the Leaky Bucket Algorithm
5 See also
6 Notes
7 References
Overview
The Leaky Bucket Algorithm is based on, and gets it name from, an analogy of a bucket (figure 1) that has a
hole in the bottom through which any water it contains will leak away at a constant rate, until or unless it is
empty. Water can be added intermittently, i.e. in bursts, but if too much is added at once, or it is added at too
high an average rate, the water will exceed the capacity of the bucket, which will overflow. Hence, this leaky
bucket determines whether adding some amount of water would exceed or conform to a limit on the average
rate at which water can be added, set by the leak rate, and a limit on how much water can be added in a burst,
set by the depth of the bucket.
Two different methods of applying this leaky bucket analogy are described in the literature.[1][2][3][4] These give
what appear to be two different algorithms, both of which are referred to as the leaky bucket algorithm and
generally without reference to the other method. This has resulted in confusion about what the leaky bucket
algorithm is and what its properties are.
In one version of applying the analogy, the analogue of the bucket is a counter or variable, separate from the
flow of traffic or scheduling of events.[1][3][4] This counter is used only to check that the traffic or events
conform to the limits: The counter is incremented as each packet arrives at the point where the check is being
made or an event occurs, which is equivalent to the way water is added intermittently to the bucket. The counter
is also decremented at a fixed rate, equivalent to the way the water leaks out of the bucket. As a result, the value
in the counter when a packet arrives indicates its conformance to the bandwidth and burstiness limits or when
an event occurs, its conformance to the average and peak rate limits. However, the counter should not be
incremented if this would cause it to overflow - i.e. the test should be to see that there is enough capacity
remaining and increment only if there is, not increment it and see if it actually does overflow. So in this version,
the analogue of the water is carried by the packets or the events, added to the bucket on their arriving or
occurring, and then leaks away. This version is referred to here as the leaky bucket as a meter.
In the second version, the analogue of the bucket is a queue in the flow of traffic.[2] This queue is used to
directly control that flow: Packets are entered into the queue as they arrive, equivalent to the water being added
to the bucket. These packet are then removed from the queue (first come, first served), usually at a fixed rate,
e.g. for onward transmission, equivalent to water leaking from the bucket. As a result, the rate at which the
queue is serviced directly controls the onward transmission rate of the traffic. Thus it imposes conformance
rather than checking it, and where the queue is serviced at a fixed rate (and where the packets are all the same
length), the resulting traffic stream is necessarily devoid of burstiness or jitter. So in this version, the traffic
itself is the analogue of the water passing through the bucket. It is not clear how this version of applying the
analogy might be used to the check the rates of discrete events. This version is referred to here as the leaky
bucket as a queue.
07-Sep-16 3:38 PM
3 of 13
The leaky bucket as a meter is exactly equivalent to (a mirror image of) the token bucket algorithm, i.e. the
process of adding water to the leaky bucket exactly mirrors that of removing tokens from the token bucket when
a conforming packet arrives, the process of leaking of water from the leaky bucket exactly mirrors that of
regularly adding tokens to the token bucket, and the test that the leaky bucket will not overflow is a mirror of
the test that the token bucket contains enough tokens and will not 'underflow'. Thus, given equivalent
parameters, the two algorithms will see the same traffic as conforming or nonconforming. The leaky bucket as a
queue can be seen as a special case of the leaky bucket as a meter.[6]
The Leaky Bucket Algorithm as a Meter

Jonathan S. Turner is credited[7] with the original description of the leaky bucket algorithm and describes it as
follows: A counter associated with each user transmitting on a connection is incremented whenever the user
sends a packet and is decremented periodically. If the counter exceeds a threshold upon being incremented, the
network discards the packet. The user specifies the rate at which the counter is decremented (this determines the
average bandwidth) and the value of the threshold (a measure of burstiness).[1] The bucket (analogous to the
counter) is in this case used as a meter to test the conformance of packets, rather than as a queue to directly
control them.
Another version of what is essentially the same meter version of the algorithm, the Generic Cell Rate
Algorithm, is described by the ITU-T in recommendation I.371 and in the ATM Forums UNI Specification.
[3][4] The description, in which the term cell is equivalent to packet in Turner's description[1] is given by the
ITU-T as follows: The continuous-state leaky bucket can be viewed as a finite capacity bucket whose
real-valued content drains out at a continuous rate of 1 unit of content per time unit and whose content is
increased by the increment T for each conforming cell... If at a cell arrival the content of the bucket is less than
or equal to the limit value , then the cell is conforming; otherwise, the cell is non-conforming. The capacity of
the bucket (the upper bound of the counter) is (T + )..[4] These specifications also state that, due to its finite
capacity, if the contents of the bucket at the time the conformance is tested is greater than the limit value, and
hence the cell is non-conforming, then the bucket is left unchanged; that is, the water is simply not added if it
would make the bucket overflow.
David E. McDysan and Darrel L. Spohn
provide a commentary on the description
given by the ITU-T/ATM Forum. In this
they state In the leaky bucket analogy, the
[ATM] cells do not actually flow through
the bucket; only the check for conforming
admission does.[6] However, uncommonly
in the descriptions in the literature,
McDysan and Spohn also refer to the leaky
bucket algorithm as a queue, going on Note
that one implementation of traffic shaping is
to actually have the cells flow through the
bucket.[6]
In describing the operation of the ITU-T's
version of the algorithm, McDysan and
Spohn invoke a notion commonly
employed in queueing theory of a fictional
Figure 2: Traffic policing with a leaky bucket as a meter
07-Sep-16 3:38 PM
4 of 13
gremlin.[6] This gremlin inspects the level in the bucket and takes action if the level is above the limit value
: in policing (figure 2), it pulls open a trap door, which causes the arriving packet to be dropped and stops its
water from entering the bucket; in shaping (figure 3), it pushes up a flap, which delays the arriving packet and
prevents it from delivering its water, until the water level in the bucket falls below .
The difference between the descriptions given by Turner and the ITU-T/ATM Forum is that Turner's is specific
to traffic policing, whereas the ITU-T/ATM Forum's is applicable to both traffic policing and traffic shaping.
Also, Turner does not state that the contents of the counter should only be affected by conforming packets, and
should only be incremented when this would not cause it to exceed a limit, i.e. Turner does not explicitly state
that the buckets capacity or counter's maximum value is finite. To make Turners description clearly aligned
with ITU-T, the statement If the counter exceeds a threshold upon being incremented, the network discards the
packet would have to be changed to something like If the counter would exceed a threshold [equivalent to the
bucket depth, T + , in the ITU-T description] upon being incremented, the network discards the packet and the
counter is not incremented", i.e. it is only incremented when it is less than or equal to the limit value, , or at
least T less than the bucket depth in the ITU-T description.
While the description given by Turner does
not state that the counter should only be
affected by conforming packets, it is given
in terms of a traffic policing function, where
overzealousness in limiting a connection
containing nonconforming packets may not
be an issue. Indeed, in some contexts, such
as Variable bitrate (VBR) transmissions, the
loss of any one packet may corrupt the
entirety of a higher layer message, e.g. an
OSI Network Layer PDU. In which case,
discarding all the following packets of that
corrupted PDU sheds an unnecessary
network load. However, it would be entirely
unacceptable in traffic shaping for a packet
that fails the conformance test to affect how
long before conformance can next occur, i.e.
Figure 3: Traffic shaping with a leaky bucket as a meter
if the act of testing a subsequent packet for
conformance would change how long a
packet currently waiting to conform has to wait. This is exactly what would happen if the water from
nonconforming packets were to be added to the bucket, as any subsequent nonconforming packets would raise
the water level, and thus make a packet waiting to conform wait longer.
Neither Turner nor the ITU-T addresses the issue of variable length packets. However, the description according
to the ITU-T is for ATM cells, which are fixed length packets, and Turner does not specifically exclude variable
length packets. Hence, in both cases, if the amount by which the bucket content or counter is incremented for a
conforming packet is proportional to the packet length, they will both account for the length and allow the
algorithm to limit the bandwidth of the traffic explicitly rather than limiting the packet rate. For example,
shorter packets would add less to the bucket, and could thus arrive at smaller intervals; whereas, longer packets
would add more and thus have to be separated by proportionally larger intervals to conform.
Concept of Operation
A description of the concept of operation of the Leaky Bucket Algorithm as a meter that can be used in either
07-Sep-16 3:38 PM
5 of 13
traffic policing or traffic shaping, may be stated as follows:

A fixed capacity bucket, associated with each virtual connection or user, leaks at a fixed rate.
If the bucket is empty, it stops leaking.
For a packet to conform, it has to be possible to add a specific amount of water to the bucket: The
specific amount added by a conforming packet can be the same for all packets, or can be
proportional to the length of the packet.
If this amount of water would cause the bucket to exceed its capacity then the packet does not
conform and the water in the bucket is left unchanged.
Uses
The leaky bucket as a meter can be used in either traffic shaping or traffic policing. For example, in ATM
networks, in the form of the Generic Cell Rate Algorithm, it is used to compare the bandwidth and burstiness of
traffic on a Virtual Channel (VC) or Virtual Path (VP) against the specified limits on the rate at which cells may
arrive and the maximum jitter, or variation in inter-arrival intervals, for the VC or VP. In traffic policing, cells
that do not conform to these limits (nonconforming cells) may be discarded (dropped) or may be reduced in
priority (for downstream traffic management functions to drop if there is congestion). In traffic shaping, cells
are delayed until they conform. Traffic policing and traffic shaping are commonly used in UPC/NPC to protect
the network against excess or excessively bursty traffic, see bandwidth management and congestion avoidance.
Traffic shaping is commonly used in the network interfaces in hosts to prevent transmissions exceeding the
bandwidth or jitter limits and being discarded by traffic management functions in the network, see network
scheduling and network scheduler.
The leaky bucket algorithm as a meter can also be used in a leaky bucket counter to measure the rate of random
or stochastic processes. A Leaky bucket counter can be used to detect when the average or peak rate of events
increases above some, acceptable, background level, i.e. when the bucket overflows.[8] However, events that do
not cause an overflow, i.e. have sufficiently low rates and are well distributed over time, can be ignored. For
example, such a leaky bucket counter can be used to detect when there is a sudden burst of correctable memory
errors or when there has been a gradual, but significant, increase in the average rate, which may indicate an
impending failure,[9] etc.
The use of the leaky bucket algorithm in a leaky bucket counter is similar to that in traffic management, in that
it is used as a meter. Essentially, the events replace the packets in the description, with each event causing a
quantity of water to be added to the bucket. If the bucket would overflow, as a result of the event, then the event
should trigger the action associated with an out of limits event. Some implementations[8] seem to parallel
Turner's description,[1] in that there is no explicit limit on the maximum value that the counter may take,
implying that once the counter has exceeded the threshold, it may not return to its previous state until a period
significantly greater than the equivalent of the emission interval has passed, which may be increased by what
would otherwise be conforming events. However, other implementations may not increment the counter while it
is overflowed, allowing it to correctly determine whether following events conform or not.
Parameters
In the case of the leaky bucket algorithm as a meter, the limits on the traffic can be a bandwidth and a burstiness
of the output.[3][4][note 2]
07-Sep-16 3:38 PM
6 of 13
The bandwidth limit and burstiness limit for the connection may be specified in a traffic contract. A bandwidth
limit may be specified as a packet or frame rate, a byte or bit rate, or as an emission interval between the
packets. A limit on burstiness may be specified as a jitter or delay variation tolerance, or as a maximum burst
size (MBS).
Multiple sets of contract parameters can be applied concurrently to a connection using multiple instances of the
leaky bucket algorithm, each of which may take a bandwidth and a burstiness limit: see Dual Leaky Bucket
Controller.
Emission Interval
The rate at which the bucket leaks will determine the bandwidth limit, which is referred to as the average rate
by Turner[1] and the inverse of which is referred to as the emission interval by the ITU-T. It is easiest to explain
what this interval is where packets have a fixed length. Hence, the first part of this description assumes this, and
the implications of variable packet lengths are considered separately.
Consider a bucket that is exactly filled to the top by preceding traffic, i.e. when the maximum permitted
burstiness has already occurred, i.e. the maximum number of packets or cells have just arrived in the minimum
amount of time for them to still conform to the bandwidth and jitter limits. The minimum interval before the
next packet can conform is then the time it takes for the bucket to leak exactly the amount of water delivered by
a packet, and if a packet is tested and conforms at that time, this will exactly fill the bucket once more. Thus,
once the bucket is filled, the maximum rate that packets can conform is with this interval between each packet.
Turner[1] refers to this rate as the average, implying that its inverse is the average interval. There is, however,
some ambiguity in what the average rate and interval are. Since, packets can arrive at any lower rate, this is an
upper bound, rather than a fixed value, so it could at best be called the maximum for the average rate. Also,
during the time the maximum burstiness occurs, packets can arrive with smaller intervals and thus a higher rate
than this. So, for any period less than infinity, the actual average rate can be (but isnt necessarily) greater than
this and the average interval can be (but isnt necessarily) less than the emission interval. Hence, because of this
ambiguity, the term emission interval is used hereafter. However, it is still true that the minimum value that the
long term average interval can take tends to be the emission interval.
For variable length packets, where the amount added to the bucket is proportional to the packet length, the
maximum rate at which they can conform varies according to their length: the amount that the bucket must have
leaked from full for a packet to conform is the amount the packet will add, and if this is proportional to the
packet length, so is the interval between it and the preceding packet that filled the bucket. Hence, it is not
possible to specify a specific emission interval for variable length packets, and the bandwidth limit has to be
specified explicitly, in bits or bytes per second.
Delay Variation Tolerance
It is easiest to explain what this tolerance is where packets have a fixed length. Hence, the first part of this
description assumes this, and the implications of variable packet lengths are considered separately.
The ITU-T define a limit value, , that is less than the capacity of the bucket by T (the amount by which the
bucket contents is incremented for each conforming cell), so that the capacity of the bucket is T + . This limit
value specifies how much earlier a packet can arrive than it would normally be expected if the packets were
arriving with exactly the emission interval between them.
Imagine the following situation: A bucket leaks at 1 unit of water per second, so the limit value, and the
07-Sep-16 3:38 PM
7 of 13
amount of water added by a packet, T, are effectively in units of seconds. This bucket starts off empty, so when
a packet arrives at the bucket, it does not quite fill the bucket by adding its water T, and the bucket is now
below its capacity. So when the next packet arrives the bucket only has to have drained by T for this to
conform. So the interval between these two packets can be as much as less than T.
This extends to multiple packets in a sequence: Imagine the following: The bucket again starts off empty, so the
first packet to arrive must conform. The bucket then becomes exactly full after a number of conforming packets,
N, have arrived in the minimum possible time for them to conform. For the last (the Nth) packet to conform, the
bucket must have leaked enough of the water from the preceding N 1 packets ((N 1) * T seconds worth) for
it to be exactly at the limit value at this time. Hence, the water leaked is (N 1)T , which because the leak is
one unit per second, took exactly (N 1)T seconds to leak. Thus the shortest time in which all N packets can
arrive and conform is (N 1)T seconds, which is exactly less than the time it would have taken if the
packets had been arriving at exactly the emission interval.
However, packets can only arrive with intervals less than T where the bucket is not filled by the previous
packet. If it is, then the bucket must have drained by the full amount T before the next packet conforms. So once
this tolerance has been used up by packets arriving at less than T, subsequent frames must arrive at intervals no
less than T. They may, however, arrive at greater intervals, when the bucket will not be filled by them. When
this has happened, packets may, again, arrive with intervals less than T until the tolerance is again used up.
However, since the bucket stops leaking when it is empty, there is always a limit () to how much tolerance can
be accrued by these intervals greater than T, however much greater than T they may be or however many of
them there are.
Since the limit value defines how much earlier a packet can arrive than would be expected, it is the limit on
the difference between the maximum and minimum delays from the source to the point where the conformance
test is being made (assuming the packets are generated with no jitter). Hence, the use of the term Cell Delay
Variation tolerance (CDVt) for this parameter in ATM.
As an example, a possible source of delay variation is where a number of connections (streams of packets) are
multiplexed together at the output of a switch. Assuming that the sum of the bandwidths of these connections is
less than that of the output, all of the packets that arrive can be transmitted, eventually. However, if their arrivals
are independent, e.g. because they arrive at different inputs of the switch, then several may arrive at or nearly at
the same time. Since the output can only transmit one packet at a time, the others must be queued in a buffer
until it is their turn to be transmitted. This buffer then introduces an additional delay between a packet arriving
at an input and being transmitted by the output, and this delay varies, depending on how many other packets are
already queued in the buffer. A similar situation can occur at the output of a host (in the NIC) when multiple
packets have the same or similar release times, and this delay can usually be modelled as a delay in a virtual
output buffer.
For variable length packets, where the amount of water added by a given packet is proportional to its length,
cant be seen as a limit on how full the bucket can be when a packet arrives, as this varies depending on the
packet size. However, the time it takes to drain from this level to empty is still how much earlier a packet can
arrive than is expected, when packets are transmitted at the bandwidth limit. Thus, it is still the maximum
variation in transfer delay to the point where the conformance test is being applied that can be tolerated, and
thus the tolerance on maximum delay variation.
Maximum Burst Size
The limit value or delay variation tolerance also controls how many packets can arrive in a burst, determined by
the excess depth of the bucket over the capacity required for a single packet. Hence MBS is also a measure of
07-Sep-16 3:38 PM
8 of 13
burstiness or jitter, and it is possible to specify the burstiness as an MBS and derive the limit value from this or
to specify it as a jitter/delay variation tolerance/limit value, and derive the MBS from this.
A burst or clump of packets can arrive at a higher rate than determined by the emission interval T. This may be
the line rate of the physical layer connection when the packets in the burst will arrive back-to-back. However, as
in ATM, the tolerance may be applied to a lower rate, in that case the Sustainable Cell Rate (SCR), and the burst
of packets (cells) can arrive at a higher rate, but less than the line rate of the physical layer, in that case the Peak
Cell Rate (PCR). The MBS may then be the number of cells needed to transport a higher layer packet (see
segmentation and reassembly), where the packets are transmitted with a maximum bandwidth determined by the
SCR and cells within the packets are transmitted at the PCR; thus allowing the last cell of the packet, and the
packet itself, to arrive significantly earlier than it would if the cells were sent at the SCR: transmission duration
= (MBS-1)/PCR rather than (MBS-1)/SCR. This bursting at the PCR puts a significantly higher load on shared
resources, e.g. switch output buffers, than does transmission at the SCR, and is thus more likely to result in
buffer overflows and network congestion. However, it puts a lesser load on these resources than would
transmitting at the SCR with a limit value, SCR, that allows MBS cells to be transmitted and arrive
back-to-back at the line rate.
If the limit value is large enough, then several packets can arrive in a burst and still conform: if the bucket starts
from empty, the first packet to arrive will add T, but if, by the time the next packet arrives, the contents is below
, this will also conform. Assuming that each packet takes to arrive, then if (expressed as the time it takes the
bucket to empty from the limit value) is equal to or greater than the emission interval less the minimum
interarrival time, T , the second packet will conform even if it arrives as a burst with the first. Similarly, if
is equal to or greater than (T ) 2, then 3 packets can arrive in a burst, etc.
The maximum size of this burst, M, can be calculated from the emission interval, T; the maximum jitter
tolerance, ; and the time taken to transmit/receive a packet, , as follows:[3]
Equally, the minimum value of jitter tolerance that gives a specific MBS can be calculated from the MBS as
follows:[3]
In the case of ATM, where technically MBS only relates to the SCR tolerance, in the above equation the time it
takes each packet to arrive, , is the emission interval for cells at the PCR TPCR, and the emission interval, T, is
the emission interval for the SCR TSCR. Where MBS is to be the number of cells required to transport a
segmented packet, the limit value in the above, , should be that for the SCR SCR. However, at the UNI or an
NNI, where cells at the PCR will have been subjected to delay variation, it should be the limit value for the SCR
plus that for the PCR SCR + PCR.
For variable length packets, the maximum burst size will depend on the lengths of the packets in the burst and
there is no single value for the maximum burst size. However, it is possible to specify the total burst length in
bytes, from the byte rate of the input stream, the equivalent byte rate of the leak, and the bucket depth.
Comparison with the Token Bucket Algorithm

The leaky bucket algorithm is sometimes contrasted with the token bucket algorithm. However, the above
07-Sep-16 3:38 PM
9 of 13
concept of operation for the leaky bucket as a meter may be directly compared with the token bucket algorithm,
the description of which is given in that article as the following:
A token is added to the bucket every 1/r seconds.
The bucket can hold at the most b tokens. If a token arrives when the bucket is full, it is discarded.
When a packet (network layer PDU) [sic][note 1] of "n" bytes arrives, n tokens are removed from the
bucket, and the packet is sent to the network.
If fewer than n tokens are available, no tokens are removed from the bucket, and the packet is
considered to be non-conformant.
This can be compared with the concept of operation, repeated from above:
A fixed capacity bucket, associated with each virtual connection or user, leaks at a fixed rate.
If the bucket is empty, it stops leaking.
For a packet to conform, it has to be possible to add a specific amount of water to the bucket: The
specific amount added by a conforming packet can be the same for all packets, or can be
proportional to the length of the packet.
If this amount of water would cause the bucket to exceed its capacity then the packet does not
conform and the water in the bucket is left unchanged.
As can be seen, these two descriptions are essentially mirror images of one another: one adds something to the
bucket on a regular basis and takes something away for conforming packets down to a limit of zero; the other
takes away regularly and adds for conforming packets up to a limit of the bucket's capacity. So, is an
implementation that adds tokens for a conforming packet and removes them at a fixed rate an implementation of
the leaky bucket or of the token bucket? Similarly, which algorithm is used in an implementation that removes
water for a conforming packet and adds water at a fixed rate? In fact both are effectively the same, i.e.
implementations of both the leaky bucket and token bucket, as these are the same basic algorithm described
differently. This explains why, given equivalent parameters, the two algorithms will see exactly the same
packets as conforming or nonconforming. The differences in the properties and performance of implementations
of the leaky and token bucket algorithms thus result entirely from the differences in the implementations, i.e.
they do not stem from differences in the underlying algorithms.
The points to note are that the leaky bucket algorithm, when used as a meter, can allow a conforming output
packet stream with jitter or burstiness, can be used in traffic policing as well as shaping, and can be
implemented for variable length packets.
The Leaky Bucket Algorithm as a Queue

A seminal description of the leaky bucket as a queue is given by Andrew S. Tanenbaum, in his book Computer
Networks as The leaky bucket consists of a finite queue. When a packet arrives, if there is room on the queue it
is appended to the queue; otherwise it is discarded. At every clock tick one packet is transmitted (unless the
queue is empty).[2] An implementation of the leaky bucket as a queue is therefore always a form of traffic
shaping function.
07-Sep-16 3:38 PM
10 of 13
As can be seen this implementation is restricted in that the packets are only
ever transmitted at a fixed rate. To underline this, Tanenbaum also states
that The leaky bucket algorithm enforces a rigid output pattern at the
average rate, no matter how bursty the [input] traffic is.[10] However, this
assertion is only strictly true as long as the queue does not become empty:
if the average arrival rate is less than the rate of clock ticks, or if the input
is sufficiently bursty that the losses bring the rate of the remainder below
the clock tick rate (i.e. gaps in the input stream are long enough and the
queue is small enough that it can become empty), there will be gaps in the
output stream.
A further restriction is that the leaky bucket as a queue traffic shaping
function only transmits packets on the ticks; hence, if it is used within a
network, equivalent to UPC and NPC, it also imposes a fixed phase on the
onward transmission of packets. Perversely, in the context of the transfer
delay, this imposition of a fixed phase that may, over time, differ from that
of an otherwise conforming input packet stream, constitutes a delay
variation and hence a jitter. However, jitter caused in this particular way
could only be observed when making a 2-point delay variation
measurement,[11] where the delay is measured as the transit time between
two separate measurement points, one either side of the leaky bucket as a
queue shaping function. It would not be observable to a downstream traffic
management function using, e.g., a token or leaky bucket algorithm, where
the delay variation is made as a 1-point measurement.
Figure 4: The leaky bucket as a

queue
Limiting variable length packets using the leaky bucket algorithm as a queue is significantly more complicated
than it is for fixed length packets. Tanenbaum gives a description of a byte-counting leaky bucket for variable
length packets as follows: At each tick, a counter is initialized to n. If the first packet on the queue has fewer
bytes than the current value of the counter, it is transmitted, and the counter is decremented by that number of
bytes. Additional packets may also be sent, as long as the counter is high enough. When the counter drops
below the length of the next packet on the queue, transmission stops until the next tick, at which time the
residual byte count is reset [to n] and the flow can continue.[2]
Uses
The leaky bucket as a queue can only be used in shaping traffic to a specified bandwidth with no jitter in the
output.[10] It may be used within the network, e.g. as part of bandwidth management, but is more appropriate to
traffic shaping in the network interfaces of hosts.
Parameters
In the case of the leaky bucket algorithm as a queue, the only defined limit for this algorithm is the bandwidth
of its output.[10][note 2]
The bandwidth limit for the connection may be specified in a traffic contract. A bandwidth limit may be
specified as a packet or frame rate, a byte or bit rate, or as an emission interval between the packets.
Inefficiency of the leaky-bucket as a queue implementation
07-Sep-16 3:38 PM
11 of 13
The implementation of the leaky-bucket as a queue does not use available network resources efficiently.
Because it transmits packets only at fixed intervals, there will be many instances when the traffic volume is very
low and large portions of network resources (bandwidth in particular) are not being used. Therefore no
mechanism exists in the leaky-bucket implementation as a queue to allow individual flows to burst up to port
speed, effectively consuming network resources at times when there would not be resource contention in the
network. Implementations of the token bucket and leaky bucket as a meter do, however, allow output traffic
flows to have bursty characteristics.
Comparison Between the two Versions of the Leaky Bucket Algorithm

Analysis of the two versions of the leaky bucket algorithm shows that the version as a queue is a special case of
the version as a meter.
Imagine a traffic shaping function for fixed length packets that is implemented using a fixed length queue,
forming a delay element, which is serviced using a leaky bucket as a meter. Imagine also that the bucket in this
meter has a depth equal to the amount added by a packet, i.e. has a limit value, , of zero. However, the
conformance test is only performed at intervals of the emission interval, when the packet at the head of the
queue is transmitted and its water is added. This water then leaks away during the next emission interval (or is
removed just prior to performing the next conformance test), allowing the next packet to conform then or at
some subsequent emission interval. The service function can also be viewed in terms of a token bucket with the
same depth, where enough tokens for one packet are added (if the bucket is not full) at the emission intervals.
This implementation will then receive packets with a bursty arrival pattern (limited by the queue depth) and
transmit them on at intervals that are always exact (integral) multiples of the emission interval.
However, the implementation of the leaky bucket as a meter (or token bucket) in a traffic shaping function
described above is an exact equivalent to the description of the leaky bucket as a queue:[2] the delay element of
the meter version is the bucket of the queue version; the bucket of the meter version is the process that services
the queue, and the leak is such that the emission interval is the same as the tick interval. Therefore for fixed
length packets, the implementation of the leaky bucket as a queue is of a special case of a traffic shaping
function using a leaky bucket (or token bucket) as a meter in which the limit value, , is zero and the process of
testing conformance is performed at the lowest possible rate.
The leaky bucket as a queue for variable packet lengths can also be described as equivalent to a special case of
the leaky bucket as a meter. The suggested implementation[2] can, like the fixed length implementation, be seen
as traffic shaping function in which the queue is a delay element, rather than the bucket, and the function that
services the queue is, in this case, explicitly given as a token bucket: it is decremented for conforming packets
and incremented at a fixed rate. Hence, as the leaky bucket as a meter and token bucket are equivalent, the leaky
bucket as a queue for variable packet lengths is also a special case of a traffic shaping function using a leaky
bucket (or token bucket) as a meter.
There is an interesting consequence of seeing the leaky bucket as a queue for variable packet lengths as a
specific implementation of the token bucket or leaky bucket as a meter in traffic shaping. This is that the bucket
of the meter has a depth, n, and, as is always the case with the token bucket, this depth determines the burstiness
of the output traffic (perhaps in relation to the average or minimum number of tokens required by the packets).
Hence, it is possible to quantify the burstiness of the output of this "byte counting" leaky bucket as a meter,
unless all packets are of the maximum length when it becomes pointless. However, this ability to define a
burstiness for the output is in direct contradiction to the statement that the leaky bucket (as a queue) necessarily
gives an output with a rigid rate, no matter how bursty the input.
07-Sep-16 3:38 PM
12 of 13
See also
Generic Cell Rate Algorithm
UPC and NPC
Traffic contract
Token bucket
Fluid queue
Notes
1. In traffic management, the leaky bucket is normally applied to the equivalent of ISO-OSI model layer 2 Data Link
Layer PDUs, e.g. ATM cells and Ethernet frames, which are called frames. It may be argued then that the description
of this algorithm should be given in terms of frames not packets, which are, in the ISO-OSI 7 layer model, layer 3
Network Layer PDUs. However, the term packet is commonly used generically in the descriptions of this algorithm
in the literature, and this convention is also applied here. It is not, however, intended to imply that the leaky bucket
algorithm is applied exclusively to Network Layer PDUs.
2. Traffic shaping functions include a queue that is necessarily of finite size. Hence, if he input stream exceeds some
level of burstiness dependent on the length of the queue or consistently exceeds the bandwidth limit being imposed
on the output stream, the queue will overflow and packets will (normally) be discarded: see Traffic
shaping#Overflow condition. Therefore, traffic shaping functions can be seen as applying traffic policing to the input
connection and traffic shaping to the output. They should, therefore, take a parameter for the burstiness limit on the
input additional to that or those for the leaky bucket. However, this input burstiness limit may be defaulted to a value
that is not expected to impact on normal traffic (the queue is assumed to be deep enough for all normal
circumstances), and not always specified explicitly.
References
1. Turner, J., New directions in communications (or which way to the information age?). Communications Magazine,
IEEE 24 (10): 815. ISSN 0163-6804 (https://www.worldcat.org/search?fq=x0:jrnl&q=n2:0163-6804), 1986.
2. Andrew S. Tanenbaum, Computer Networks, Fourth Edition, ISBN 0-13-166836-6, Prentice Hall PTR, 2003., page
401.
3. ATM Forum, The User Network Interface (UNI), v. 3.1, ISBN 0-13-393828-X, Prentice Hall PTR, 1995.
4. ITU-T, Traffic control and congestion control in B ISDN, Recommendation I.371, International Telecommunication
Union, 2004, Annex A, page 87.
5. ITU-T, Traffic control and congestion control in B ISDN, Recommendation I.371, International Telecommunication
Union, 2004, page 17
6. McDysan, David E. and Spohn, Darrel L., ATM : Theory and Application, ISBN 0-07-060362-6, McGraw-Hill series
on computer communications, 1995, pages 3589.
7. Andrew S. Tanenbaum, Computer Networks, Fourth Edition, ISBN 0-13-166836-6, Prentice Hall PTR, 2003, Page
400.
8. http://encyclopedia2.thefreedictionary.com/leaky+bucket+counter.
9. Intel, Intel Server Board S5400SF: Technical Product Specification, September 2007, http://download.intel.com
/support/motherboards/server/s5400sf/sb/s5400sf_tps_rev2_01.pdf.
10. Andrew S. Tanenbaum, Computer Networks, Fourth Edition, ISBN 0-13-166836-6, Prentice Hall PTR, 2003, page
402.
11. ITU-T, B-ISDN ATM layer cell transfer performance, Recommendation I.356, International Telecommunication
Union, 2000, Section 6.5.2.2 Cell delay variation between two MPs (2-point CDV), page 14.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Leaky_bucket&oldid=733093980"

Categories: Network scheduling algorithms
07-Sep-16 3:38 PM
13 of 13
This page was last modified on 5 August 2016, at 09:43.

Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may
apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia is a registered
trademark of the Wikimedia Foundation, Inc., a non-profit organization.
07-Sep-16 3:38 PM

Leaky Bucket - Wikipedia, The Free Encyclopedia

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Leaky Bucket - Wikipedia, The Free Encyclopedia

Uploaded by

Copyright:

Available Formats

Leaky bucket - Wikipedia, the free encyclopedia