This is a brief tutorial on using tcng (Traffic Control Next Generation) with HTB (Hierarchical Token Bucket) to perform traffic shaping on a Linux machine.
This tutorial is intended for systems administrators who have
AT LEAST, a basic understanding of traffic control
EITHER the capability to compile iproute2 and tcng from source
OR the capability of building RPMS from provided SRPMs
EITHER a modular kernel with support for htb and dsmark
OR capability to compile a kernel with support for htb and dsmark
This article is neither comprehensive nor authoritative. The
author solicits positive and negative feedback at
additions, and further examples are always welcome.
Traffic control is the term given to the entire packet queuing subsystem in a network or network device. Traffic control consists of several distinct operations. Classifying is a mechanism by which to identify packets and place them in individual flows or classes. Policing is a mechanism by which one limits the number of packets or bytes in a stream matching a particular classification. Scheduling is the decision-making process by which packets are ordered and re-ordered for transmission. Shaping is the process by which packets are delayed and transmitted to produce an even and predictable flow rate.
These many characteristics of a traffic control system can be combined in complex ways to reserve bandwidth for a particular flow (or application) or to limit the amount of bandwidth available to a particular flow or application.
One of the key concepts of traffic control is the concept of tokens. A policing or shaping implementation needs to calculate the number of bytes or packets which have passed at what rate. Each packet or byte (depending on the implementation), corresponds to a token, and the policing or shaping implementation will only transmit or pass the packet if it has a token available. A common metaphorical container in which an implementation keeps its token is the bucket. In short, a bucket represents the both the number of tokens which can be used instantaneously (the size of the bucket), and the rate at which the tokens are replenished (how fast the bucket gets refilled).
See Section 1.2, “What is htb?” for an example of buckets in a linux traffic control system.
Under linux, traffic control has historically been a complex endeavor. The tc command line tool provides an interface to the kernel structures which perform the shaping, scheduling, policing and classifying. The syntax of this command is, however, arcane. The tcng project provides a much friendlier interface to the human by layering a language on top of the powerful tc command line tool. By writing traffic control configurations in tcng they become easily maintainable, less arcane, and importantly also more portable.
Hierarchichal Token Bucket is a classful qdisc written by Martin Devera with a simpler set of configuration parameters than CBQ. There is a great deal of documentation on the author's site and also on Stef Coene's website about HTB and its uses. Below is a very brief sketch of the HTB system.
Conceptually, HTB is an arbitrary number of token buckets arranged in a
hierarchy (yes, you probably could have figured that out without my
sentence). Let's consider the simplest scenario.
The primary egress queuing discipline on any device is known as
root qdisc will contain one class (complex
scenarios could have multiple classes attached to the
root qdisc). This single HTB class will be set
with two parameters, a
rate and a
ceil. These values should be the same for the
top-level class, and will represent the total
available bandwidth on the link.
rate means the guaranteed bandwidth
available for a given class and
ceil is short for
ceiling, which indicates the maximum bandwidth that class is allowed to
consume. Any bandwidth used between
ceil is borrowed from a parent class, hence the
be the same in the top-level class.
A number of children classes can be made under this class, each of which
can be allocated some amount of the available bandwidth from the parent
class. In these children classes, the
ceil parameter values need not be the same as
suggested for the parent class. This allows you to reserve a specified
amount of bandwidth to a particular class. It also
allows HTB to calculate the ratio of distribution of available bandwidth
to the ratios of the classes themselves. This should be more apparent
in the examples below.
Hierarchical Token Bucket implements a classful queuing mechanism for
the linux traffic control system, and provides
ceil to allow the user to control the absolute
bandwidth to particular classes of traffic as well as indicate the ratio
of distribution of bandwidth when extra bandwidth becomes available (up
Keep in mind when choosing the bandwidth for your top-level class that traffic shaping only helps if you are the bottleneck between your LAN and the Internet. Typically, this is the case in home and office network environments, where an entire LAN is serviced by a DSL or T1 connection.
In practice, this means that you should probably set the bandwidth for your top-level class to your available bandwidth minus a fraction of that bandwidth.
Traffic Control Next Generation (tcng) is a project by Werner Almesberger to provide a powerful, abstract, and uniform language in which to describe traffic control structures. The tcc parser in the tcng distribution transforms tcng the language into a number of output formats. By default, tcc will read a file (specified as an argument or as STDIN) and print to STDOUT the series of tc commands (see iproute2 below) required to create the desired traffic control structure in the kernel.
Consult the parameter reference for tcng to see the supported queuing disciplines. Jacob Teplitsky, active on the LARTC mailing list and a contributor to the tcng project, wrote the htb support for tcng.
The tcc tool can produce a number of different types of output, but this document will only consider the conventional and default output. Consult the TCNG manual for more detailed information about the use of tcng.
The tcsim tool is a traffic control simulator which accepts tcng configuration files and reads a control language to simulate the behaviour of a kernel sending and receiving packets with the specified control structures. Although tcsim is a significant portion of the tcng project, tcsim will not be covered here at all.