764 lines
20 KiB
HTML
764 lines
20 KiB
HTML
<!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
|
|
> |