Difference between revisions of "Token bucket"
Onnowpurbo (talk | contribs) |
Onnowpurbo (talk | contribs) |
||
(One intermediate revision by the same user not shown) | |||
Line 34: | Line 34: | ||
In other words, HTB is very useful to limit a client's [[download]]/[[upload]] rate. Thus, the limited client cannot saturate the total bandwidth. | In other words, HTB is very useful to limit a client's [[download]]/[[upload]] rate. Thus, the limited client cannot saturate the total bandwidth. | ||
+ | |||
+ | |||
+ | ==Referensi== | ||
+ | |||
+ | * http://www.docum.org/docum.org/tests/htb/burst/ - Busrt & Cburst di HTB | ||
== References == | == References == | ||
Line 51: | Line 56: | ||
*[[Rate limiting]] | *[[Rate limiting]] | ||
*Congestion Avoidance in [[Broadband Networks]] | *Congestion Avoidance in [[Broadband Networks]] | ||
+ | * [[Bandwidth Manajemen Menggunakan HTB]] |
Latest revision as of 05:10, 9 August 2010
A token bucket is a common algorithm used to control the amount of data that is injected into a network, allowing for bursts of data to be sent. Although it has several uses, it is best understood in the context of network traffic shaping or rate limiting.
Traffic shaping algorithms (leaky bucket versus token bucket)
Two predominant methods for shaping traffic exist: a leaky bucket implementation and a token bucket implementation. Sometimes they are mistakenly lumped together under the same name. Both these schemes have distinct properties and are used for distinct purposes [1]. They differ principally in that the leaky bucket imposes a hard limit on the data transmission rate, whereas the token bucket allows a certain amount of burstiness while imposing a limit on the average data transmission rate.
High level view
The token bucket is a control mechanism that dictates when traffic can be transmitted, based on the presence of tokens in the bucket--an abstract container that holds aggregate network traffic to be transmitted. The bucket contains tokens, each of which can represent a unit of bytes or a single packet of predetermined size. Tokens in the bucket are removed ("cashed in") for the ability to send a packet. The network administrator specifies how many tokens are needed to transmit how many bytes. When tokens are present, a flow is allowed to transmit traffic. If there are no tokens in the bucket, a flow cannot transmit its packets. Therefore, a flow can transmit traffic up to its peak burst rate if there are adequate tokens in the bucket and if the burst threshold is configured appropriately.
The token bucket algorithm
The algorithm can be conceptually understood as follows:
- A token is added to the bucket every <math>1/r</math> 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) 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.
The algorithm allows bursts of up to b bytes, but over the long run the output of conformant packets is limited to the constant rate, <math>r</math>. Non-conformant packets can be treated in various ways:
- They may be dropped.
- They may be enqueued for subsequent transmission when sufficient tokens have accumulated in the bucket.
- They may be transmitted, but marked as being non-conformant, possibly to be dropped subsequently if the network is overloaded.
To calculate the time for which the Token Bucket Algorithm allows burst of maximum possible size, assume that the capacity of the Token Bucket is C bytes, the token arrival rate is R bytes/second and the maximum possible transmission rate is M bytes/second and S is the number of seconds for which it is possible to transmit at maximum rate. Then, the following equality holds <math>C + R*S = M*S</math> which gives <math>S = C / (M - R)</math> seconds
Implementers of this algorithm on platforms lacking the clock resolution necessary to add a single token to the bucket every <math>1/r</math> seconds may want to consider an alternative formulation. Given the ability to update the token bucket every S milliseconds, the number of tokens to add every S milliseconds = <math>(r*S)/1000</math>.
Hierarchical token bucket
This is a faster replacement for the class-based queueing qdisc (queuing discipline) in Linux.
Description
HTBs help in controlling the use of the outbound bandwidth on a given link. HTB allows using one single physical link to simulate multiple slower links and to send different kinds of traffic on different simulated links. In both cases, one has to specify how to divide the physical link into simulated links and how to decide which simulated link a given packet is to be sent across.
In other words, HTB is very useful to limit a client's download/upload rate. Thus, the limited client cannot saturate the total bandwidth.
Referensi
- http://www.docum.org/docum.org/tests/htb/burst/ - Busrt & Cburst di HTB
References
- "Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice" by John Evans, Clarence Filsfils (Morgan Kaufmann, 2007, ISBN 0-12-370549-5)
- Ferguson P., Huston G., Quality of Service: Delivering QoS on the Internet and in Corporate Networks, John Wiley & Sons, Inc., 1998. ISBN 0-471-24358-2.
- Andrew S. Tanenbaum, Computer Networks, 3rd Edition, Prentice-Hall, 1996.
- Linux HTB Home Page http://luxik.cdi.cz/~devik/qos/htb/ ...
- Implementation of the token bucket algorithm in python: http://code.activestate.com/recipes/511490/
See also
- Leaky bucket
- Traffic shaping
- Rate limiting
- Congestion Avoidance in Broadband Networks
- Bandwidth Manajemen Menggunakan HTB