HTB link at the bottom seem to point to same article...
The Hierarchical Token Bucket section of this page really does not belong here. This page discusses the Token Bucket algorithm, not some specific operating system's implementation of it. —Preceding unsigned comment added by 188.8.131.52 (talk) 00:41, 18 September 2008 (UTC)
- I concur, this section needs to be removed to a separate cross referenced entry. Graham Fountain 14:27, 19 October 2010 (UTC) —Preceding unsigned comment added by Graham.Fountain (talk • contribs)
- I agree too. HTB as a qdisc implementation should be moved to another more relevant article. Also, the article is lacking information with regards to the burstiness equation presented. There is no clear indication on what symbols b,M and r are. --Ltsampros (talk) 09:20, 23 December 2010 (UTC)
Comparison with the Leaky Bucket Algorithm
The section titled Traffic shaping algorithms (leaky bucket versus token bucket) needs to be addressed. Its discussion of the leaky bucket algorithm makes it clear that it refers only to the leaky bucket as a queue rather than the more general leaky bucket as a meter. This, presumably, follows Tanenbaum's description of the leaky bucket as a queue in Computer Networks, which is given therein as though this queue form were the only one there is. However, comparison of Tanenbaum's peculiar description with Turner's original (which is quoted in the section leaky bucket#The Leaky Bucket Algorithm as a Meter) shows that they are quite dissimilar and that, by Turner's description, burstiness in the output is not necessarily eliminated unless Turner's threshold is set to the increment for one packet (the bucket depth is set to one packets worth of water/fluid). Any greater thershold or deeper bucket can then result in a busty output.
In fact, as the page on the leaky bucket attests, the token bucket and leaky bucket as a meter are actually mirror images of one another and thus exactly equivalent: the token bucket adds tokens at a fixed rate and takes them out for each conforming packet, frame, or cell (Layer 2 PDU = frame); the leaky bucket loses fluid/water at a fixed rate and adds it in for each conforming packet. So, as is asked on that page, is an implementation that removes tokens regularly and adds tokens for a conforming packet an implementation of the leaky bucket or of the token bucket? In fact it is both, as they are equivalent and, given the same parameters, will see exactly the same packets as conforming and nonconforming.
Also this entry clearly confuses the token bucket with one of its applications, namely traffic shaping. Whereas, as a method for testing the conformance of a packet to a rate and jitter (bandwidth and burstiness), it is applicable to both traffic shaping and traffic policing, and probably to event counting, etc. As a result, the section High level view needs to be re-written in consideration of all possible uses, e.g. in the context of a conformance test.