8. Rules, Guidelines and Approaches

8.1. General Rules of Linux Traffic Control

There are a few general rules which ease the study of Linux traffic
control.
Traffic control structures under Linux are the same whether the initial
configuration has been done with tcng or with tc.

Any router performing a shaping function should be the bottleneck on
the link, and should be shaping slightly below the maximum available
link bandwidth. This prevents queues from forming in other routers,
affording maximum control of packet latency/deferral to the shaping
device.

A device can only shape traffic it transmits
[10]. Because the traffic has already been received on an
input interface, the traffic cannot be shaped. A traditional
solution to this problem is an ingress policer.

Every interface must have a qdisc. The default qdisc
(the pfifo_fast qdisc) is used when another qdisc is not
explicitly attached to the interface.

One of the classful qdiscs added to an interface with no children
classes typically only consumes CPU for no benefit.

Any newly created class contains a FIFO.
This qdisc can be replaced explicitly with any other qdisc. The
FIFO qdisc will be removed implicitly if a child class is
attached to this class.

Classes directly attached to the root qdisc can be used to
simulate virtual circuits.

8.2. Handling a link with a known bandwidth

HTB is an ideal qdisc to use on a link with a known
bandwidth, because the innermost (root-most) class can be set to the
maximum bandwidth available on a given link. Flows can be further
subdivided into children classes, allowing either guaranteed bandwidth
to particular classes of traffic or allowing preference to specific
kinds of traffic.

8.3. Handling a link with a variable (or unknown) bandwidth

In theory, the PRIO scheduler is an ideal match for links with
variable bandwidth, because it is a work-conserving qdisc (which
means that it provides no shaping). In the case of a link
with an unknown or fluctuating bandwidth, the PRIO scheduler
simply prefers to dequeue any available packet in the highest priority
band first, then falling to the lower priority queues.

8.4. Sharing/splitting bandwidth based on flows

Of the many types of contention for network bandwidth, this is one of
the easier types of contention to address in general. By using the
SFQ qdisc, traffic in a particular queue can be separated into
flows, each of which will be serviced fairly (inside that queue).
Well-behaved applications (and users) will find that using SFQ and
ESFQ are sufficient for most sharing needs.

The Achilles heel of these fair queuing algorithms is a misbehaving user
or application which opens many connections simultaneously (e.g., eMule,
eDonkey, Kazaa). By creating a large number of individual flows, the
application can dominate slots in the fair queuing algorithm. Restated,
the fair queuing algorithm has no idea that a single application is
generating the majority of the flows, and cannot penalize the user.
Other methods are called for.

8.5. Sharing/splitting bandwidth based on IP

For many administrators this is the ideal method of dividing bandwidth
amongst their users. Unfortunately, there is no easy solution, and it
becomes increasingly complex with the number of machine sharing a
network link.

To divide bandwidth equitably between N IP
addresses, there must be N classes.

[10]
In fact, the
Intermediate Queuing Device
(IMQ) simulates an output device onto which traffic
control structures can be attached. This clever solution allows
a networking device to shape ingress traffic in the same fashion
as egress traffic. Despite the apparent contradiction of the
rule, IMQ appears as a device to the kernel. Thus, there has
been no violation of the rule, but rather a sneaky
reinterpretation of that rule.