4. Components of Linux Traffic Control
Table 1. Correlation between traffic control elements and Linux
components
traditional element | Linux component |
---|
shaping | The class offers shaping capabilities. |
scheduling | A qdisc is a scheduler. Schedulers
can be simple such as the FIFO or
complex, containing classes and other
qdiscs, such as HTB. |
classifying | The filter object performs the
classification through the agency of a
classifier object. Strictly speaking,
Linux classifiers cannot exist outside
of a filter. |
policing | A policer exists in the Linux traffic
control implementation only as part of a
filter. |
dropping | To drop traffic requires a
filter with a policer which
uses "drop" as an action. |
marking | The dsmark qdisc is used for
marking. |
4.1. qdisc
Simply put, a qdisc is a scheduler
(Section 3.2). Every output interface needs a
scheduler of some kind, and the default scheduler is a FIFO.
Other qdiscs available under Linux will rearrange the packets entering
the scheduler's queue in accordance with that scheduler's rules.
The qdisc is the major building block on which all of Linux traffic
control is built, and is also called a queuing discipline.
The classful qdiscs can contain classes, and provide a handle
to which to attach filters. There is no prohibition on using a
classful qdisc without child classes, although this will usually consume
cycles and other system resources for no benefit.
The classless qdiscs can contain no classes, nor is it possible to
attach filter to a classless qdisc. Because a classless qdisc contains
no children of any kind, there is no utility to classifying.
This means that no filter can be attached to a classless qdisc.
A source of terminology confusion is the usage of the terms
root qdisc and ingress qdisc. These are not
really queuing disciplines, but rather locations onto which traffic
control structures can be attached for egress (outbound traffic) and
ingress (inbound traffic).
Each interface contains both. The primary and more common is the
egress qdisc, known as the root qdisc. It can contain any
of the queuing disciplines (qdiscs) with potential
classes and class structures. The overwhelming majority of
documentation applies to the root qdisc and its children. Traffic
transmitted on an interface traverses the egress or root qdisc.
For traffic accepted on an interface, the ingress qdisc is traversed.
With its limited utility, it allows no child class to be
created, and only exists as an object onto which a filter can be
attached. For practical purposes, the ingress qdisc is merely a
convenient object onto which to attach a policer to limit the
amount of traffic accepted on a network interface.
In short, you can do much more with an egress qdisc because it contains
a real qdisc and the full power of the traffic control system. An
ingress qdisc can only support a policer. The remainder of the
documentation will concern itself with traffic control structures
attached to the root qdisc unless otherwise specified.
4.2. class
Classes only exist inside a classful qdisc (e.g., HTB
and CBQ). Classes are immensely flexible and can always
contain either multiple children classes or a single child qdisc
.
There is no prohibition against a class containing a classful qdisc
itself, which facilitates tremendously complex traffic control
scenarios.
Any class can also have an arbitrary number of filters attached
to it, which allows the selection of a child class or the use of a
filter to reclassify or drop traffic entering a particular class.
A leaf class is a terminal class in a qdisc. It contains a qdisc
(default FIFO) and will never contain a child class. Any
class which contains a child class is an inner class (or root class) and
not a leaf class.
4.3. filter
The filter is the most complex component in the Linux
traffic control system. The filter provides a convenient mechanism for
gluing together several of the key elements of traffic control. The
simplest and most obvious role of the filter is to classify
(see Section 3.3) packets. Linux filters allow the
user to classify packets into an output queue with either several
different filters or a single filter.
Filters can be attached either to classful qdiscs or to
classes, however the enqueued packet always enters the root
qdisc first. After the filter attached to the root qdisc has been
traversed, the packet may be directed to any subclasses (which can have
their own filters) where the packet may undergo further classification.
4.4. classifier
Filter objects, which can be manipulated using tc, can use several
different classifying mechanisms, the most common of which is the
u32 classifier. The u32 classifier allows the user to
select packets based on attributes of the packet.
The classifiers are tools which can be used as part of a filter
to identify characteristics of a packet or a packet's metadata. The
Linux classfier object is a direct analogue to the basic operation and
elemental mechanism of traffic control classifying.
4.5. policer
This elemental mechanism is only used in Linux traffic control as part
of a filter. A policer calls one action above and another
action below the specified rate. Clever use of policers can simulate
a three-color meter. See also
Section 10.
Although both policing and shaping are basic
elements of traffic control for limiting bandwidth usage a policer will
never delay traffic. It can only perform an action based on specified
criteria. See also
Example 5.
4.6. drop
This basic traffic control mechanism is only used in Linux traffic
control as part of a policer. Any policer attached to
any filter could have a drop action.
| The only place in the Linux traffic control system where a packet can be
explicitly dropped is a policer. A policer can limit packets enqueued
at a specific rate, or it can be configured to drop all traffic matching
a particular pattern
.
|
There are, however, places within the traffic control system where a
packet may be dropped as a side effect. For example, a packet will be
dropped if the scheduler employed uses this method to control flows as
the GRED does.
Also, a shaper or scheduler which runs out of its allocated buffer space
may have to drop a packet during a particularly bursty or overloaded
period.
4.7. handle
Every class and classful qdisc (see also
Section 7) requires a unique identifier within
the traffic control structure. This unique identifier is known as a
handle and has two constituent members, a major number and a minor
number. These numbers can be assigned arbitrarily by the user in
accordance with the following rules
.
The numbering of handles for classes and qdiscs
- major
This parameter is completely free of meaning to the kernel. The
user may use an arbitrary numbering scheme, however all objects in
the traffic control structure with the same parent must share a
major handle number. Conventional
numbering schemes start at 1 for objects attached directly to the
root qdisc.
- minor
This parameter unambiguously identifies the object as a qdisc if
minor is 0. Any other value identifies the
object as a class. All classes sharing a parent must have unique
minor numbers.
The special handle ffff:0 is reserved for the ingress qdisc.
The handle is used as the target in classid and
flowid phrases of tc filter statements.
These handles are external identifiers for the objects, usable by
userland applications. The kernel maintains internal identifiers for
each object.