<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML
><HEAD
><TITLE
>Overview of Concepts</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="Traffic Control HOWTO"
HREF="index.html"><LINK
REL="PREVIOUS"
TITLE="Introduction to Linux Traffic Control"
HREF="intro.html"><LINK
REL="NEXT"
TITLE="Traditional Elements of Traffic Control"
HREF="elements.html"></HEAD
><BODY
CLASS="section"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Traffic Control HOWTO: </TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="intro.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="elements.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="section"
><H1
CLASS="section"
><A
NAME="overview"
></A
>2. Overview of Concepts</H1
><P
> This section will
<A
HREF="overview.html#o-what-is"
>introduce traffic control</A
> and
<A
HREF="overview.html#o-why-use"
>examine reasons for it</A
>,
identify a few
<A
HREF="overview.html#o-advantages"
>advantages</A
> and
<A
HREF="overview.html#o-disadvantages"
>disadvantages</A
> and
introduce key concepts used in traffic control.
</P
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="o-what-is"
></A
>2.1. What is it?</H2
><P
> 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.
</P
><P
> 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 FIFO.
</P
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
>The default qdisc under Linux is the <A
HREF="classless-qdiscs.html#qs-pfifo_fast"
><TT
CLASS="constant"
>pfifo_fast</TT
></A
>, which is
slightly more complex than the <A
HREF="classless-qdiscs.html#qs-fifo"
>FIFO</A
>.
</TD
></TR
></TABLE
></DIV
><P
> There are examples of queues in all sorts of software. The queue is a
way of organizing the pending tasks or data (see also
<A
HREF="overview.html#o-queues"
>Section 2.5</A
>). Because network links typically carry data
in a serialized fashion, a queue is required to manage the outbound
data packets.
</P
><P
> 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.
</P
><P
> 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.
</P
><P
> The term Quality of Service (QoS) is often used as a synonym for traffic
control.
</P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="o-why-use"
></A
>2.2. Why use it?</H2
><P
> 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.
</P
><P
> 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.
</P
><P
> 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.
</P
><P
> 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.
</P
><P
></P
><P
><B
>Common traffic control solutions</B
></P
><UL
><LI
><P
> Limit total bandwidth to a known rate; <A
HREF="classless-qdiscs.html#qs-tbf"
>TBF</A
>,
<A
HREF="classful-qdiscs.html#qc-htb"
>HTB</A
> with child class(es).
</P
></LI
><LI
><P
> Limit the bandwidth of a particular user, service or client;
<A
HREF="classful-qdiscs.html#qc-htb"
>HTB</A
> classes and <A
HREF="elements.html#e-classifying"
>classifying</A
> with a
<A
HREF="components.html#c-filter"
><TT
CLASS="constant"
>filter</TT
></A
>. traffic.
</P
></LI
><LI
><P
> Maximize TCP throughput on an asymmetric link; prioritize
transmission of ACK packets, <A
HREF="scripts.html#sc-wondershaper"
>wondershaper</A
>.
</P
></LI
><LI
><P
> Reserve bandwidth for a particular application or user;
<A
HREF="classful-qdiscs.html#qc-htb"
>HTB</A
> with children classes and <A
HREF="elements.html#e-classifying"
>classifying</A
>.
</P
></LI
><LI
><P
> Prefer latency sensitive traffic; <A
HREF="classful-qdiscs.html#qc-prio"
>PRIO</A
> inside an
<A
HREF="classful-qdiscs.html#qc-htb"
>HTB</A
> class.
</P
></LI
><LI
><P
> Managed oversubscribed bandwidth; <A
HREF="classful-qdiscs.html#qc-htb"
>HTB</A
> with borrowing.
</P
></LI
><LI
><P
> Allow equitable distribution of unreserved bandwidth; <A
HREF="classful-qdiscs.html#qc-htb"
>HTB</A
>
with borrowing.
</P
></LI
><LI
><P
> Ensure that a particular type of traffic is dropped; <A
HREF="components.html#c-police"
><TT
CLASS="constant"
>policer</TT
></A
>
attached to a <A
HREF="components.html#c-filter"
><TT
CLASS="constant"
>filter</TT
></A
> with a <A
HREF="components.html#c-drop"
><TT
CLASS="constant"
>drop</TT
></A
> action.
</P
></LI
></UL
><P
> Remember, too that sometimes, it is simply better to purchase more
bandwidth. Traffic control does not solve all problems!
</P
><P
> </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="o-advantages"
></A
>2.3. Advantages</H2
><P
> 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.
</P
><P
> 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.
</P
><P
> </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="o-disadvantages"
></A
>2.4. Disdvantages</H2
><P
> </P
><P
> 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.
</P
><P
> 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.
</P
><P
> 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.
</P
><P
> 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.
</P
><P
> 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.
</P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="o-queues"
></A
>2.5. Queues</H2
><P
> 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
<A
NAME="AEN220"
HREF="#FTN.AEN220"
><SPAN
CLASS="footnote"
>[1]</SPAN
></A
>.
In the discipline of computer networking (and more generally
computer science), this sort of a queue is known as a FIFO.
</P
><P
> 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.
</P
><P
> 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.
</P
><P
> 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
<A
NAME="AEN225"
HREF="#FTN.AEN225"
><SPAN
CLASS="footnote"
>[2]</SPAN
></A
>.
It is only by examining the internals of this layer that
the traffic control structures become exposed and available.
</P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="o-flows"
></A
>2.6. Flows</H2
><P
> 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.
</P
><P
> 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.
</P
><P
> 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.
</P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="o-tokens"
></A
>2.7. Tokens and buckets</H2
><A
NAME="o-buckets"
></A
><P
> Two of the key underpinnings of a <A
HREF="elements.html#e-shaping"
>shaping</A
> mechanisms are
the interrelated concepts of tokens and buckets.
</P
><P
> 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.
</P
><P
> 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
<A
HREF="elements.html#e-shaping"
>shaping</A
> mechanism. Only a certain number of people can
experience the ride in a particular period.
</P
><P
> 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.
</P
><P
> 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.
</P
><P
> The <A
HREF="classless-qdiscs.html#qs-tbf"
>TBF</A
> qdisc is a classical example of a shaper (the section
on TBF includes a diagram which may help to visualize the token
and bucket concepts). The TBF generates <TT
CLASS="parameter"
><I
>rate</I
></TT
> tokens and
only transmits packets when a token is available. Tokens are a generic
shaping concept.
</P
><P
> 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.
</P
><P
> 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
<A
HREF="overview.html#o-flows"
>flows</A
>.
</P
><P
> 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.
</P
><P
> The concepts of tokens and buckets are closely interrelated and are used
in both <A
HREF="classless-qdiscs.html#qs-tbf"
>TBF</A
> (one of the <A
HREF="classless-qdiscs.html"
>classless qdiscs</A
>) and
<A
HREF="classful-qdiscs.html#qc-htb"
>HTB</A
> (one of the <A
HREF="classful-qdiscs.html"
>classful qdiscs</A
>).
Within the <B
CLASS="command"
>tcng</B
> language, the use of two- and three-color meters is
indubitably a token and bucket concept.
</P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="o-packets"
></A
>2.8. Packets and frames</H2
><A
NAME="o-frames"
></A
><P
> 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.
</P
><P
> 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.
</P
><P
> 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.
</P
></DIV
></DIV
><H3
CLASS="FOOTNOTES"
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN220"
HREF="overview.html#AEN220"
><SPAN
CLASS="footnote"
>[1]</SPAN
></A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
> 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.
</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN225"
HREF="overview.html#AEN225"
><SPAN
CLASS="footnote"
>[2]</SPAN
></A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
> Similarly, the entire traffic control system appears as a queue or
scheduler to the higher layer which is enqueuing packets into this
layer.
</P
></TD
></TR
></TABLE
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="intro.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="elements.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Introduction to Linux Traffic Control</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
> </TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Traditional Elements of Traffic Control</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
