mirror of https://github.com/tLDP/LDP
421 lines
18 KiB
XML
421 lines
18 KiB
XML
<!-- start of file -->
|
|
|
|
<!-- This .xml file is part of the Traffic-Control-HOWTO document -->
|
|
|
|
<!-- $Id$ -->
|
|
|
|
<!--
|
|
|
|
The article was authored by Martin A. Brown <martin@linux-ip.net>
|
|
for the linux community, and has been released under the GNU Free
|
|
Documentation License (GFDL) through The Linux Documentation
|
|
Project (TLDP).
|
|
|
|
This was initially authored while Martin A. Brown worked for
|
|
SecurePipe, Inc.
|
|
|
|
This HOWTO is likely available at the following address:
|
|
|
|
http://tldp.org/HOWTO/Traffic-Control-HOWTO/
|
|
|
|
-->
|
|
|
|
<!-- conventions used in this documentation....
|
|
|
|
- each section is a separate file
|
|
|
|
-->
|
|
|
|
<section id="overview">
|
|
|
|
<title>Overview of Concepts</title>
|
|
<para>
|
|
This section will
|
|
<link linkend="o-what-is">introduce traffic control</link> and
|
|
<link linkend="o-why-use">examine reasons for it</link>,
|
|
identify a few
|
|
<link linkend="o-advantages">advantages</link> and
|
|
<link linkend="o-disadvantages">disadvantages</link> and
|
|
introduce key concepts used in traffic control.
|
|
</para>
|
|
|
|
<section id="o-what-is">
|
|
<title>What is it?</title>
|
|
<para>
|
|
Traffic control is the name given to the sets of queuing systems and
|
|
mechanisms by which packets are received and transmitted on a router.
|
|
This includes deciding which (and whether) packets to accept at what
|
|
rate on the input of an interface and determining which packets to
|
|
transmit in what order at what rate on the output of an interface.
|
|
</para>
|
|
<para>
|
|
In the overwhelming majority of situations, traffic control consists of
|
|
a single queue which collects entering packets and dequeues them as
|
|
quickly as the hardware (or underlying device) can accept them. This
|
|
sort of queue is a &sch_fifo;.
|
|
</para>
|
|
<note>
|
|
The default qdisc under Linux is the &link-sch_pfifo_fast;, which is
|
|
slightly more complex than the &link-sch_fifo;.
|
|
</note>
|
|
<para>
|
|
There are examples of queues in all sorts of software. The queue is a
|
|
way of organizing the pending tasks or data (see also
|
|
<xref linkend="o-queues"/>). Because network links typically carry data
|
|
in a serialized fashion, a queue is required to manage the outbound
|
|
data packets.
|
|
</para>
|
|
<para>
|
|
In the case of a desktop machine and an efficient webserver sharing the
|
|
same uplink to the Internet, the following contention for bandwidth may
|
|
occur. The web server may be able to fill up the output queue on the
|
|
router faster than the data can be transmitted across the link, at which
|
|
point the router starts to drop packets (its buffer is full!). Now, the
|
|
desktop machine (with an interactive application user) may be faced with
|
|
packet loss and high latency. Note that high latency sometimes leads to
|
|
screaming users! By separating the internal queues used to service
|
|
these two different classes of application, there can be better sharing
|
|
of the network resource between the two applications.
|
|
</para>
|
|
<para>
|
|
Traffic control is the set of tools which allows the user to have
|
|
granular control over these queues and the queuing mechanisms of a
|
|
networked device. The power to rearrange traffic flows and packets with
|
|
these tools is tremendous and can be complicated, but is no substitute
|
|
for adequate bandwidth.
|
|
</para>
|
|
<para>
|
|
The term Quality of Service (QoS) is often used as a synonym for traffic
|
|
control.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="o-why-use">
|
|
<title>Why use it?</title>
|
|
<para>
|
|
Packet-switched networks differ from circuit based networks in one very
|
|
important regard. A packet-switched network itself is stateless. A
|
|
circuit-based network (such as a telephone network) must hold state
|
|
within the network. IP networks are stateless and packet-switched
|
|
networks by design; in fact, this statelessness is one of the
|
|
fundamental strengths of IP.
|
|
</para>
|
|
<para>
|
|
The weakness of this statelessness is the lack of differentiation
|
|
between types of flows. In simplest terms, traffic control allows an
|
|
administrator to queue packets differently based on attributes of the
|
|
packet. It can even be used to simulate the behaviour of a
|
|
circuit-based network. This introduces statefulness into the stateless
|
|
network.
|
|
</para>
|
|
<para>
|
|
There are many practical reasons to consider traffic control, and many
|
|
scenarios in which using traffic control makes sense. Below are some
|
|
examples of common problems which can be solved or at least ameliorated
|
|
with these tools.
|
|
</para>
|
|
<para>
|
|
The list below is not an exhaustive list of the sorts of solutions
|
|
available to users of traffic control, but introduces the
|
|
types of problems that can be solved by using traffic control to
|
|
maximize the usability of a network connection.
|
|
</para>
|
|
<itemizedlist>
|
|
<title>Common traffic control solutions</title>
|
|
<listitem>
|
|
<para>
|
|
Limit total bandwidth to a known rate; &link-sch_tbf;,
|
|
&link-sch_htb; with child class(es).
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Limit the bandwidth of a particular user, service or client;
|
|
&link-sch_htb; classes and &elements-classifying; with a
|
|
&linux-filter;. traffic.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Maximize TCP throughput on an asymmetric link; prioritize
|
|
transmission of ACK packets, &link-wondershaper;.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Reserve bandwidth for a particular application or user;
|
|
&link-sch_htb; with children classes and &elements-classifying;.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Prefer latency sensitive traffic; &link-sch_prio; inside an
|
|
&link-sch_htb; class.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Managed oversubscribed bandwidth; &link-sch_htb; with borrowing.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Allow equitable distribution of unreserved bandwidth; &link-sch_htb;
|
|
with borrowing.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Ensure that a particular type of traffic is dropped; &linux-policer;
|
|
attached to a &linux-filter; with a &linux-drop; action.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>
|
|
Remember, too that sometimes, it is simply better to purchase more
|
|
bandwidth. Traffic control does not solve all problems!
|
|
</para>
|
|
<para>
|
|
</para>
|
|
</section>
|
|
|
|
<section id="o-advantages">
|
|
<title>Advantages</title>
|
|
<para>
|
|
When properly employed, traffic control should lead to more predictable
|
|
usage of network resources and less volatile contention for these
|
|
resources. The network then meets the goals of the traffic control
|
|
configuration. Bulk download traffic can be allocated a reasonable
|
|
amount of bandwidth even as higher priority interactive traffic is
|
|
simultaneously
|
|
serviced. Even low priority data transfer such as mail can
|
|
be allocated bandwidth without tremendously affecting the other classes
|
|
of traffic.
|
|
</para>
|
|
<para>
|
|
In a larger picture, if the traffic control configuration represents
|
|
policy which has been communicated to the users, then users (and,
|
|
by extension, applications) know what to expect from the network.
|
|
</para>
|
|
<para>
|
|
</para>
|
|
</section>
|
|
|
|
<section id="o-disadvantages">
|
|
<title>Disdvantages</title>
|
|
<para>
|
|
</para>
|
|
<para>
|
|
Complexity is easily one of the most significant disadvantages of using
|
|
traffic control. There are ways to become familiar with traffic control
|
|
tools which ease the learning curve about traffic control and its
|
|
mechanisms, but identifying a traffic control misconfiguration can be
|
|
quite a challenge.
|
|
</para>
|
|
<para>
|
|
Traffic control when used appropriately can lead to more equitable
|
|
distribution of network resources. It can just as easily be installed
|
|
in an inappropriate manner leading to further and more divisive
|
|
contention for resources.
|
|
</para>
|
|
<para>
|
|
The computing resources required on a router to support a traffic
|
|
control scenario need to be capable of handling the increased cost of
|
|
maintaining the traffic control structures. Fortunately, this is a
|
|
small incremental cost, but can become more significant as the
|
|
configuration grows in size and complexity.
|
|
</para>
|
|
<para>
|
|
For personal use, there's no training cost associated with the use of
|
|
traffic control, but a company may find that purchasing more bandwidth
|
|
is a simpler solution than employing traffic control. Training
|
|
employees and ensuring depth of knowledge may be more costly than
|
|
investing in more bandwidth.
|
|
</para>
|
|
<para>
|
|
Although
|
|
traffic control on packet-switched networks covers a larger conceptual
|
|
area, you can think of traffic control as a way to provide [some of] the
|
|
statefulness of a circuit-based network to a packet-switched network.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="o-queues">
|
|
<title>Queues</title>
|
|
<para>
|
|
Queues form the backdrop for all of traffic control and are the integral
|
|
concept behind scheduling. A queue is a location (or buffer) containing
|
|
a finite number of items waiting for an action or service. In
|
|
networking, a queue is the place where packets (our units) wait to be
|
|
transmitted by the hardware (the service). In the simplest model,
|
|
packets are transmitted in a first-come first-serve basis
|
|
<footnote>
|
|
<para>
|
|
This queueing model has long been used in civilized countries to
|
|
distribute scant food or provisions equitably. William Faulkner is
|
|
reputed to have walked to the front of the line for to fetch his
|
|
share of ice, proving that not everybody likes the FIFO model, and
|
|
providing us a model for considering priority queuing.
|
|
</para>
|
|
</footnote>.
|
|
In the discipline of computer networking (and more generally
|
|
computer science), this sort of a queue is known as a &sch_fifo;.
|
|
</para>
|
|
<para>
|
|
Without any other mechanisms, a queue doesn't offer any promise for
|
|
traffic control. There are only two interesting actions in a queue.
|
|
Anything entering a queue is enqueued into the queue. To remove an item
|
|
from a queue is to dequeue that item.
|
|
</para>
|
|
<para>
|
|
A queue becomes much more interesting when coupled with other mechanisms
|
|
which can delay packets, rearrange, drop and prioritize packets in
|
|
multiple queues. A queue can also use subqueues, which allow for
|
|
complexity of behaviour in a scheduling operation.
|
|
</para>
|
|
<para>
|
|
From the perspective of the higher layer software, a packet is simply
|
|
enqueued for transmission, and the manner and order in which the
|
|
enqueued packets are transmitted is immaterial to the higher layer. So,
|
|
to the higher layer, the entire traffic control system may appear as a
|
|
single queue
|
|
<footnote>
|
|
<para>
|
|
Similarly, the entire traffic control system appears as a queue or
|
|
scheduler to the higher layer which is enqueuing packets into this
|
|
layer.
|
|
</para>
|
|
</footnote>.
|
|
It is only by examining the internals of this layer that
|
|
the traffic control structures become exposed and available.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="o-flows">
|
|
<title>Flows</title>
|
|
<para>
|
|
A flow is a distinct connection or conversation between two hosts. Any
|
|
unique set of packets between two hosts can be regarded as a flow.
|
|
Under TCP the concept of a connection with a source IP and port and
|
|
destination IP and port represents a flow. A UDP flow can be similarly
|
|
defined.
|
|
</para>
|
|
<para>
|
|
Traffic control mechanisms frequently separate traffic into classes of
|
|
flows which can be aggregated and transmitted as an aggregated flow
|
|
(consider DiffServ). Alternate mechanisms may attempt to divide
|
|
bandwidth equally based on the individual flows.
|
|
</para>
|
|
<para>
|
|
Flows become important when attempting to divide bandwidth equally among
|
|
a set of competing flows, especially when some applications deliberately
|
|
build a large number of flows.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="o-tokens">
|
|
<title>Tokens and buckets</title>
|
|
<anchor id="o-buckets" xreflabel="Tokens and buckets"/>
|
|
<para>
|
|
Two of the key underpinnings of a &elements-shaping; mechanisms are
|
|
the interrelated concepts of tokens and buckets.
|
|
</para>
|
|
<para>
|
|
In order to control the rate of dequeuing, an implementation can count
|
|
the number of packets or bytes dequeued as each item is dequeued,
|
|
although this requires complex usage of timers and measurements to limit
|
|
accurately. Instead of calculating the current usage and time, one
|
|
method, used widely in traffic control, is to generate tokens at a
|
|
desired rate, and only dequeue packets or bytes if a token is available.
|
|
</para>
|
|
<para>
|
|
Consider the analogy of an amusement park ride with a queue of people
|
|
waiting to experience the ride. Let's imagine a track on which carts
|
|
traverse a fixed track. The carts arrive at the head of the queue at a
|
|
fixed rate. In order to enjoy the ride, each person must wait for an
|
|
available cart. The cart is analogous to a token and the person is
|
|
analogous to a packet. Again, this mechanism is a rate-limiting or
|
|
&elements-shaping; mechanism. Only a certain number of people can
|
|
experience the ride in a particular period.
|
|
</para>
|
|
<para>
|
|
To extend the analogy, imagine an empty line for the amusement park
|
|
ride and a large number of carts sitting on the track ready to carry
|
|
people. If a large number of people entered the line together many
|
|
(maybe all) of them could experience the ride because of the carts
|
|
available and waiting. The number of carts available is a concept
|
|
analogous to the bucket. A bucket contains a number of tokens and can
|
|
use all of the tokens in bucket without regard for passage of time.
|
|
</para>
|
|
<para>
|
|
And to complete the analogy, the carts on the amusement park ride (our
|
|
tokens) arrive at a fixed rate and are only kept available up to the
|
|
size of the bucket. So, the bucket is filled with tokens according to
|
|
the rate, and if the tokens are not used, the bucket can fill up. If
|
|
tokens are used the bucket will not fill up. Buckets are a key concept
|
|
in supporting bursty traffic such as HTTP.
|
|
</para>
|
|
<para>
|
|
The &link-sch_tbf; qdisc is a classical example of a shaper (the section
|
|
on &sch_tbf; includes a diagram which may help to visualize the token
|
|
and bucket concepts). The &sch_tbf; generates ¶m-rate; tokens and
|
|
only transmits packets when a token is available. Tokens are a generic
|
|
shaping concept.
|
|
</para>
|
|
<para>
|
|
In the case that a queue does not need tokens immediately, the tokens
|
|
can be collected until they are needed. To collect tokens indefinitely
|
|
would negate any benefit of shaping so tokens are collected until a
|
|
certain number of tokens has been reached. Now, the queue has tokens
|
|
available for a large number of packets or bytes which need to be
|
|
dequeued. These intangible tokens are stored in an intangible bucket,
|
|
and the number of tokens that can be stored depends on the size of the
|
|
bucket.
|
|
</para>
|
|
<para>
|
|
This also means that a bucket full of tokens may be available at any
|
|
instant. Very predictable regular traffic can be handled by small
|
|
buckets. Larger buckets may be required for burstier traffic, unless
|
|
one of the desired goals is to reduce the burstiness of the
|
|
&concepts-flows;.
|
|
</para>
|
|
<para>
|
|
In summary, tokens are generated at rate, and a maximum of a bucket's
|
|
worth of tokens may be collected. This allows bursty traffic to be
|
|
handled, while smoothing and shaping the transmitted traffic.
|
|
</para>
|
|
<para>
|
|
The concepts of tokens and buckets are closely interrelated and are used
|
|
in both &link-sch_tbf; (one of the &classless-qdiscs;) and
|
|
&link-sch_htb; (one of the &classful-qdiscs;).
|
|
Within the &tcng; language, the use of two- and three-color meters is
|
|
indubitably a token and bucket concept.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="o-packets">
|
|
<title>Packets and frames</title>
|
|
<anchor id="o-frames"/>
|
|
<para>
|
|
The terms for data sent across network changes depending on the layer
|
|
the user is examining. This document will rather impolitely (and
|
|
incorrectly) gloss over the technical distinction between
|
|
packets and frames although they are outlined here.
|
|
</para>
|
|
<para>
|
|
The word frame is typically used to describe a layer 2 (data link) unit
|
|
of data to be forwarded to the next recipient. Ethernet interfaces, PPP
|
|
interfaces, and T1 interfaces all name their layer 2 data unit a frame.
|
|
The frame is actually the unit on which traffic control is performed.
|
|
</para>
|
|
<para>
|
|
A packet, on the other hand, is a higher layer concept, representing
|
|
layer 3 (network) units. The term packet is preferred in this
|
|
documentation, although it is slightly inaccurate.
|
|
</para>
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<!-- end of file -->
|