<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML
><HEAD
><TITLE
>Rules, Guidelines and Approaches</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="Classful Queuing Disciplines (qdiscs)"
HREF="classful-qdiscs.html"><LINK
REL="NEXT"
TITLE="Scripts for use with QoS/Traffic Control"
HREF="scripts.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="classful-qdiscs.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="scripts.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="section"
><H1
CLASS="section"
><A
NAME="rules"
></A
>8. Rules, Guidelines and Approaches</H1
><P
> </P
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="r-general"
></A
>8.1. General Rules of Linux Traffic Control</H2
><P
> 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 <A
HREF="software.html#s-tcng"
><B
CLASS="command"
>tcng</B
></A
> or with <A
HREF="software.html#s-iproute2-tc"
><B
CLASS="command"
>tc</B
></A
>.
</P
><P
></P
><UL
><LI
><P
> 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.
</P
></LI
><LI
><P
> A device can only shape traffic it transmits
<A
NAME="AEN1189"
HREF="#FTN.AEN1189"
><SPAN
CLASS="footnote"
>[1]</SPAN
></A
>. 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.
</P
></LI
><LI
><P
> Every interface must have a <A
HREF="components.html#c-qdisc"
><TT
CLASS="constant"
>qdisc</TT
></A
>. The default qdisc
(the <A
HREF="classless-qdiscs.html#qs-pfifo_fast"
><TT
CLASS="constant"
>pfifo_fast</TT
></A
> qdisc) is used when another qdisc is not
explicitly attached to the interface.
</P
></LI
><LI
><P
> One of the <A
HREF="classful-qdiscs.html"
>classful qdiscs</A
> added to an interface with no children
classes typically only consumes CPU for no benefit.
</P
></LI
><LI
><P
> Any newly created class contains a <A
HREF="classless-qdiscs.html#qs-fifo"
>FIFO</A
>.
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.
</P
></LI
><LI
><P
> Classes directly attached to the <TT
CLASS="constant"
>root</TT
> qdisc can be used to
simulate virtual circuits.
</P
></LI
><LI
><P
> A <A
HREF="components.html#c-filter"
><TT
CLASS="constant"
>filter</TT
></A
> can be attached to classes or one of the
<A
HREF="classful-qdiscs.html"
>classful qdiscs</A
>.
</P
></LI
></UL
><P
> </P
><P
> </P
><P
> </P
><P
> </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="r-known-bandwidth"
></A
>8.2. Handling a link with a known bandwidth</H2
><P
> HTB is an ideal <A
HREF="components.html#c-qdisc"
><TT
CLASS="constant"
>qdisc</TT
></A
> 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.
</P
><P
> </P
><P
> </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="r-unknown-bandwidth"
></A
>8.3. Handling a link with a variable (or unknown) bandwidth</H2
><P
> In theory, the PRIO scheduler is an ideal match for links with
variable bandwidth, because it is a work-conserving <A
HREF="components.html#c-qdisc"
><TT
CLASS="constant"
>qdisc</TT
></A
> (which
means that it provides no <A
HREF="elements.html#e-shaping"
>shaping</A
>). 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.
</P
><P
> </P
><P
> </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="r-sharing-flows"
></A
>8.4. Sharing/splitting bandwidth based on flows</H2
><P
> 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.
</P
><P
> 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.
</P
><P
> </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="r-sharing-ips"
></A
>8.5. Sharing/splitting bandwidth based on IP</H2
><P
> 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.
</P
><P
> To divide bandwidth equitably between <TT
CLASS="parameter"
><I
>N</I
></TT
> IP
addresses, there must be <TT
CLASS="parameter"
><I
>N</I
></TT
> classes.
</P
><P
> </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.AEN1189"
HREF="rules.html#AEN1189"
><SPAN
CLASS="footnote"
>[1]</SPAN
></A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
> In fact, the
<A
HREF="software.html#s-imq"
>Intermediate Queuing Device
(IMQ)</A
> 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.
</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="classful-qdiscs.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="scripts.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Classful Queuing Disciplines (<A
HREF="components.html#c-qdisc"
><TT
CLASS="constant"
>qdisc</TT
></A
>s)</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
> </TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Scripts for use with QoS/Traffic Control</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
