LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

Ready for publishing; submitting to submit@en.tldp.org momentarily.

This commit is contained in:
mabrown 2003-09-15 02:01:06 +00:00
parent c1a26440bd
commit 80cdd178fb
10 changed files with 245 additions and 117 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
LDP/howto/docbook/Traffic-Control-HOWTO/articleinfo.xml
View File

@ -57,6 +57,13 @@
<revhistory>
<revision>
<revnumber>0.7</revnumber>
<date>2002-09-14</date>
<authorinitials>MAB</authorinitials>
<revremark>incremental revisions, proofreading, ready for TLDP</revremark>
</revision>
<revision>
<revnumber>0.6</revnumber>
<date>2002-09-09</date>
@ -107,7 +114,7 @@
<para>
Traffic control encompasses the sets of mechanisms and operations by
which packets are queued for transmission/reception on a network
interface. The operations include enqueueing, policing, classifying,
interface. The operations include enqueuing, policing, classifying,
scheduling, shaping and dropping. This HOWTO provides an introduction
and overview of the capabilities and implementation of traffic control
under Linux.

58
LDP/howto/docbook/Traffic-Control-HOWTO/classful-qdiscs.xml
View File

@ -91,12 +91,23 @@ TC HTB version 3.3
</example>
<para>
</para>
<section id="qc-htb-software">
<title>Software requirements</title>
<para>
Unlike almost all of the other software discussed, &sch_htb; is a
newer queuing discipline and your distribution may not have all of the
tools and capability you need to use &sch_htb;. The kernel must
support &sch_htb;; kernel version 2.4.20 and later support it in the
stock distribution, although earlier kernel versions require patching.
To enable userland support for &sch_htb;, see &url-qdisc-htb; for an
&iproute2; patch to &tc;.
</para>
</section>
<section id="qc-htb-shaping">
<title>Shaping</title>
<para>
One of the most common applications of &sch_htb; involves shaping
(rate-limiting, capping bandwidth, throttling) transmitted traffic to
a specific rate.
transmitted traffic to a specific rate.
</para>
<para>
All shaping occurs in leaf classes. No shaping occurs in inner or
@ -166,7 +177,7 @@ TC HTB version 3.3
</entry>
</row>
<row>
<entry>inner</entry>
<entry>inner, root</entry>
<entry>&lt; &param-rate;</entry>
<entry><parameter>HTB_CAN_SEND</parameter></entry>
<entry>
@ -174,7 +185,7 @@ TC HTB version 3.3
</entry>
</row>
<row>
<entry>inner</entry>
<entry>inner, root</entry>
<entry>&gt; &param-rate;, &lt; &param-ceil;</entry>
<entry><parameter>HTB_MAY_BORROW</parameter></entry>
<entry>
@ -184,7 +195,7 @@ TC HTB version 3.3
</entry>
</row>
<row>
<entry>inner</entry>
<entry>inner, root</entry>
<entry>&gt; &param-ceil;</entry>
<entry><parameter>HTB_CANT_SEND</parameter></entry>
<entry>
@ -228,7 +239,7 @@ TC HTB version 3.3
</para>
</section>
<section id="qc-htb-params">
<title>Parameters</title>
<title>&sch_htb; class parameters</title>
<para>
</para>
<variablelist id="vl-qc-htb-params">
@ -312,6 +323,20 @@ TC HTB version 3.3
</para>
</listitem>
</varlistentry>
<varlistentry id="vl-qc-htb-params-mtu">
<term>&param-mtu;</term>
<listitem>
<para>
</para>
</listitem>
</varlistentry>
<varlistentry id="vl-qc-htb-params-prio">
<term>&param-prio;</term>
<listitem>
<para>
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
</para>
@ -352,6 +377,12 @@ TC HTB version 3.3
<xref linkend="qc-htb-borrowing"/>).
</para>
</listitem>
<listitem>
<para>
The &param-quantum; is only only used when a class is over
&param-rate; but below &param-ceil;.
</para>
</listitem>
<listitem>
<para>
The &param-quantum; should be set at MTU or higher. &sch_htb;
@ -363,22 +394,17 @@ TC HTB version 3.3
&sch_htb; will report bandwidth usage in this scenario
incorrectly. It will calculate the bandwidth used by
&param-quantum; instead of the real dequeued packet size.
This can squeue results quickly.
This can skew results quickly.
</para>
</footnote>.
</para>
</listitem>
<listitem>
<para>
For maximum granularity and most instantaneously evenly
distributed bandwidth, &param-quantum; should be as low as
possible while still no less than MTU.
</para>
</listitem>
<listitem>
<para>
The &param-quantum; is only only used when a class is over
&param-rate; but below &param-ceil;.
Parent classes lend tokens to children in increments of
&param-quantum;, so for maximum granularity and most
instantaneously evenly distributed bandwidth, &param-quantum;
should be as low as possible while still no less than MTU.
</para>
</listitem>
<listitem>

32
LDP/howto/docbook/Traffic-Control-HOWTO/classless-qdiscs.xml
View File

@ -29,7 +29,8 @@
<para>
Each of these queuing disciplines can be used as the primary qdisc on an
interface, or can be used inside a leaf class of a &classful-qdiscs;.
These are the fundamental schedulers used under Linux.
These are the fundamental schedulers used under Linux. Note that the
default scheduler is the &link-sch_pfifo_fast;.
</para>
<para>
</para>
@ -45,7 +46,9 @@
The FIFO algorithm forms the basis for the default qdisc on all Linux
network interfaces (&link-sch_pfifo_fast;). It performs no shaping or
rearranging of packets. It simply transmits packets as soon as it can
after receiving and queuing them.
after receiving and queuing them. This is also the qdisc used inside
all newly created classes until another qdisc or a class replaces the
&sch_fifo;.
</para>
<mediaobject id="img-qs-fifo">
<imageobject>
@ -59,16 +62,17 @@
</imageobject>
</mediaobject>
<para>
A real FIFO qdisc must, however, have a size limit to prevent it from
overflowing in case it is unable to dequeue packets as quickly as it
receives them. Linux implements two basic FIFO &linux-qdisc;s, one
based on bytes, and one on packets. Regardless of the type of FIFO
used, the size of the queue is defined by the parameter
A real FIFO qdisc must, however, have a size limit (a buffer size) to
prevent it from overflowing in case it is unable to dequeue packets as
quickly as it receives them. Linux implements two basic FIFO
&linux-qdisc;s, one based on bytes, and one on packets. Regardless of
the type of FIFO used, the size of the queue is defined by the parameter
<parameter>limit</parameter>. For a &sch_pfifo; the unit is understood
to be packets and for a &sch_bfifo; the unit is understood to be bytes.
</para>
<example id="ex-qs-fifo-limit">
<title>Specifying a FIFO <parameter>limit</parameter></title>
<title>Specifying a <parameter>limit</parameter> for a packet
or byte FIFO</title>
<programlisting>
<prompt>[root@leander]# </prompt><userinput>cat bfifo.tcc</userinput>
<computeroutput>/*
@ -145,8 +149,7 @@ tc qdisc add dev eth0 handle 2:0 parent 1:0 pfifo limit 30</computeroutput>
which are dequeued in a round-robin fashion. Because there is the
possibility for unfairness to manifest in the choice of hash function,
this function is altered periodically. Perturbation (the parameter
<parameter>perturb</parameter>) describes this periodically altered hash
function.
<parameter>perturb</parameter>) sets this periodicity.
</para>
<mediaobject id="img-qs-sfq">
<imageobject>
@ -200,6 +203,11 @@ tc qdisc add dev eth0 handle 2:0 parent 1:0 sfq perturb 10</computeroutput>
<para>
Conceptually, this qdisc is no different than &sch_sfq; although it
allows the user to control more parameters than its simpler cousin.
This qdisc was conceived to overcome the shortcoming of &sch_sfq;
identified above. By allowing the user to control which hashing
algorithm is used for distributing access to network bandwidth, it
is possible for the user to reach a fairer real distribution of
bandwidth.
</para>
<example id="ex-qs-esfq-usage">
<title>&sch_esfq; usage</title>
@ -232,8 +240,8 @@ HASHTYPE := { classic | src | dst }
<section id="qs-tbf">
<title>TBF, Token Bucket Filter</title>
<para>
This qdisc is built on &concepts-tokens; and &concepts-buckets;, which
are key concepts involved with &elements-shaping;. To limit the speed
This qdisc is built on &concepts-tokens; and &concepts-buckets;. It
simply shapes traffic transmitted on an interface. To limit the speed
at which packets will be dequeued from a particular interface, the
&sch_tbf; qdisc is the perfect solution. It simply slows down
transmitted traffic to the specified rate.

86
LDP/howto/docbook/Traffic-Control-HOWTO/components.xml
View File

@ -106,8 +106,9 @@
</para>
<para>
The &classless-qdiscs; can contain no classes, nor is it possible to
attach filter to a classless qdisc. Because a it contains no children
of any kind, the utility &elements-classifying; is pointless.
attach filter to a classless qdisc. Because a classless qdisc contains
no children of any kind, there is no utility to &elements-classifying;.
This means that no filter can be attached to a classless qdisc.
</para>
<para>
A source of terminology confusion is the usage of the terms
@ -130,7 +131,7 @@
created, and only exists as an object onto which a &linux-filter; can be
attached. For practical purposes, the &ingress-qdisc; is merely a
convenient object onto which to attach a &linux-policer; to limit the
amount of traffic accepted into a network.
amount of traffic accepted on a network interface.
</para>
<para>
In short, you can do much more with an egress qdisc because it contains
@ -159,9 +160,9 @@
scenarios.
</para>
<para>
Any class can also have multiple &linux-filter;s attached to it, which
allows the selection of a child class or the use of a filter to
reclassify or drop traffic entering a particular class.
Any class can also have an arbitrary number of &linux-filter;s attached
to it, which allows the selection of a child class or the use of a
filter to reclassify or drop traffic entering a particular class.
</para>
<para>
A leaf class is a terminal class in a qdisc. It contains a qdisc
@ -174,7 +175,7 @@
<section id="c-filter">
<title><constant>filter</constant></title>
<para>
The filter is one of the most complex elements in the Linux
The filter is the most complex component in the Linux
traffic control system. The filter provides a convenient mechanism for
gluing together several of the key elements of traffic control. The
simplest and most obvious role of the filter is to classify
@ -182,12 +183,24 @@
user to classify packets into an output queue with either several
different filters or a single filter.
</para>
<itemizedlist>
<listitem>
<para>
A filter must contain a &linux-classifier; phrase.
</para>
</listitem>
<listitem>
<para>
A filter may contain a &linux-policer; phrase.
</para>
</listitem>
</itemizedlist>
<para>
Filters can be attached either to &linux-qdisc;s or to &linux-class;es,
however the enqueued packet always enters the root qdisc first.
After the filter attached to the root qdisc has been traversed,
the packet may be directed to any subclasses (which can have their own
filters) where the packet may continue its classification process.
Filters can be attached either to classful &linux-qdisc;s or to
&linux-class;es, however the enqueued packet always enters the root
qdisc first. After the filter attached to the root qdisc has been
traversed, the packet may be directed to any subclasses (which can have
their own filters) where the packet may undergo further classification.
</para>
<!-- FIXME; discussion not complete here -->
<para>
@ -204,7 +217,9 @@
</para>
<para>
The classifiers are tools which can be used as part of a &linux-filter;
to identify characteristics of a packet or a packet's metadata.
to identify characteristics of a packet or a packet's metadata. The
Linux classfier object is a direct analogue to the basic operation and
elemental mechanism of traffic control &elements-classifying;.
</para>
</section>
@ -213,27 +228,17 @@
<para>
This elemental mechanism is only used in Linux traffic control as part
of a &linux-filter;. A policer calls one action above and another
action below the specified rate. This can be used to set up a set of
cascading policers to simulate a three-color meter.
action below the specified rate. Clever use of policers can simulate
a three-color meter. See also
<xref linkend="diagram"/>.
</para>
<para>
Although both &elements-policing; and &elements-shaping; are basic
elements of traffic control for limiting bandwidth usage a policer will
never delay traffic. It can only perform an action based on specified
criteria.
criteria. See also
<xref linkend="ex-s-iproute2-tc-filter"/>.
</para>
<!--
<example id="ex-c-police-action">
<title>Example of a policer</title>
<programlisting>
<prompt>[root@leander]# </prompt><userinput>tc filter add dev ppp0 parent 1:0 protocol all prio 4 \</userinput>
<prompt>&gt; </prompt> <userinput>u32 match u32 0x0 0x0 at 0 classid 1:7 \</userinput>
<prompt>&gt; </prompt> <userinput>police index 3 rate 32000bps burst 10240 mpu 0 action drop/continue</userinput>
</programlisting>
</example>
-->
<para>
</para>
<para>
@ -264,12 +269,13 @@
<para>
There are, however, places within the traffic control system where a
packet may be dropped as a side effect. For example, a packet will be
dropped if the scheduler employed uses this methood to control flows as
dropped if the scheduler employed uses this method to control flows as
the &link-sch_gred; does.
</para>
<para>
A shaper or scheduler which runs out of its allocated buffer space may
have to drop a packet during a particularly bursty or overloaded period.
Also, a shaper or scheduler which runs out of its allocated buffer space
may have to drop a packet during a particularly bursty or overloaded
period.
</para>
<para>
</para>
@ -280,8 +286,7 @@
<para>
Every &linux-class; and classful &linux-qdisc; (see also
<xref linkend="classful-qdiscs"/>) requires a unique identifier within
the traffic control structure. Note that &classless-qdiscs; do not
require a handle. This unique identifier is known as a
the traffic control structure. This unique identifier is known as a
handle and has two constituent members, a major number and a minor
number. These numbers can be assigned arbitrarily by the user in
accordance with the following rules
@ -293,8 +298,9 @@
</footnote>.
</para>
<para>
</para>
<variablelist>
<title>Rules for numbering handles for classes and qdiscs</title>
<title>The numbering of handles for classes and qdiscs</title>
<varlistentry>
<term><parameter>major</parameter></term>
<listitem>
@ -303,7 +309,7 @@
user may use an arbitrary numbering scheme, however all objects in
the traffic control structure with the same parent must share a
<parameter>major</parameter> handle number. Conventional
numbering schemes start at 1 for devices attached to the
numbering schemes start at 1 for objects attached directly to the
&root-qdisc;.
</para>
</listitem>
@ -312,7 +318,7 @@
<term><parameter>minor</parameter></term>
<listitem>
<para>
This parameter unambigously identifies the object as a qdisc (if
This parameter unambiguously identifies the object as a qdisc if
<parameter>minor</parameter> is 0. Any other value identifies the
object as a class. All classes sharing a parent must have unique
<parameter>minor</parameter> numbers.
@ -320,10 +326,16 @@
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
The special handle ffff:0 is reserved for the &ingress-qdisc;.
</para>
<para>
The handle is used as the target in <parameter>classid</parameter> and
<parameter>flowid</parameter> phrases of &tc; &linux-filter; statements.
These handles are external identifiers for the objects, usable by
userland applications. The kernel maintains internal identifiers for
each object.
</para>
</section>
<!--

29
LDP/howto/docbook/Traffic-Control-HOWTO/elements.xml
View File

@ -58,6 +58,10 @@
parameters burst and cburst.
</para>
</footnote>.
One of the advantages of shaping bandwidth is the ability to control
latency of packets. The underlying mechanism for shaping to a rate is
typically a token and bucket mechanism. See also
<xref linkend="o-tokens"/> for further detail on tokens and buckets.
</para>
</section>
@ -89,7 +93,7 @@
<section id="e-classifying">
<title>Classifying</title>
<para>
Classifiers sort traffic into output queues.
Classifiers sort or separate traffic into queues.
</para>
<para>
Classifying is the mechanism by which packets are separated for
@ -129,6 +133,12 @@
dropped.
</para>
<para>
A policer is a yes/no question about the rate at which traffic is
entering a queue. If the packet is about to enter a queue below a given
rate, take one action (allow the enqueuing). If the packet is about to
enter a queue above a given rate, take another action. Although the
policer uses a token bucket mechanism internally, it does not have the
capability to delay a packet as a &elements-shaping; mechanism does.
</para>
</section>
@ -147,16 +157,17 @@
<section id="e-marking">
<title>Marking</title>
<para>
Marking is a mechanism by which the packet (or packet meta-data?) is
identified.
Marking is a mechanism by which the packet is altered.
</para>
<note>
This is not &fwmark;. The &iptables; target &ipt-mark; and the
&ipchains; &ipc-mark; are used to modify packet metadata, not the packet
itself.
</note>
<para>
FIXME - I need to determine whether marking is for local use only or if
the packet itself is altered (DiffServ domain?) - FIXME
</para>
<para>
<foreignphrase>N.B.</foreignphrase>, this is not
<constant>fwmark</constant>
Traffic control marking mechanisms install a DSCP on the packet
itself, which is then used and respected by other routers inside an
administrative domain (usually for DiffServ).
</para>
</section>

17
LDP/howto/docbook/Traffic-Control-HOWTO/links.xml
View File

@ -127,6 +127,23 @@
and general documentation on the behaviour of the Linux IP layer.
</para>
</listitem>
<listitem>
<para>
<ulink url="http://www.almesberger.net/cv/papers.html">Werner
Almesberger's Papers</ulink>
</para>
<para>
Werner Almesberger is one of the main developers and champions of
traffic control under Linux (he's also the author of &tcng;, above).
One of the key documents describing the entire traffic control
architecture of the Linux kernel is his Linux Traffic Control -
Implementation Overview which is available in
<ulink url="http://www.almesberger.net/cv/papers/tcio8.pdf">PDF</ulink>
or
<ulink url="http://www.almesberger.net/cv/papers/tcio8.ps.gz">PS</ulink>
format.
</para>
</listitem>
<listitem>
<para>
<ulink url="http://diffserv.sourceforge.net/">Linux DiffServ

94
LDP/howto/docbook/Traffic-Control-HOWTO/overview.xml
View File

@ -48,24 +48,31 @@
<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.
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>
Queues exist in software on any networked system. On an outbound
network interface, a web server may be able to fill up the output queue
very quickly, meaning that the queuing mechanism will transmit as fast
as it can to the hardware, but that may be slower than the software can
supply data. This would leave a full queue between the software and the
hardware. There's nothing intrinsically wrong with this, but the
super-efficient web server may be hogging transmit bandwidth from a
slower mail server.
</para>
<para>
On the other hand, a network interface may be able to supply packets to
the operating system faster than the operating system can accept the
packets. Here again, the packets will build up in a queue. These are
two simplistic examples of the already existing queues in a networked
device.
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
@ -233,18 +240,19 @@
<section id="o-queues">
<title>Queues</title>
<para>
Queues form the backdrop for all of traffic control.
Practically speaking, a queue is a 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
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 to fetch his share,
proving that the FIFO model doesn't always suit the consumer.
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
@ -258,14 +266,24 @@
</para>
<para>
A queue becomes much more interesting when coupled with other mechanisms
which can delay, rearrange, drop and prioritize multiple queues.
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. It is only by examining the internals of this layer that
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>
@ -273,11 +291,11 @@
<section id="o-flows">
<title>Flows</title>
<para>
A flow is a distinct connection between two hosts. Any unique set of
packets (perhaps representing a conversation) 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.
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
@ -314,7 +332,8 @@
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.
&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
@ -347,16 +366,21 @@
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 depend on the size of the
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 is available at any
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
@ -372,7 +396,7 @@
<para>
The terms for data sent across network changes depending on the layer
the user is examining. This document will rather impolitely (and
somewhat incorrectly) gloss over the technical distinction between
incorrectly) gloss over the technical distinction between
packets and frames although they are outlined here.
</para>
<para>

2
LDP/howto/docbook/Traffic-Control-HOWTO/rules.xml
View File

@ -40,7 +40,7 @@
<itemizedlist>
<listitem>
<para>
Any device performing a shaping function should be the bottleneck on
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

17
LDP/howto/docbook/Traffic-Control-HOWTO/shorthand.ent
View File

@ -43,6 +43,17 @@
<!ENTITY iproute2
'<command>iproute2</command>' >
<!ENTITY fwmark
'<constant>fwmark</constant>' >
<!ENTITY ipt-mark
'<constant>MARK</constant>' >
<!ENTITY ipc-mark
'<option>--mark</option>' >
<!ENTITY iptables
'<command>iptables</command>' >
<!ENTITY ipchains
'<command>ipchains</command>' >
<!ENTITY tcng
'<command>tcng</command>' >
<!ENTITY link-tcng
@ -123,6 +134,8 @@
<!ENTITY root-qdisc
'<constant>root</constant> qdisc' >
<!ENTITY param-mpu
'<parameter>mpu</parameter>' >
<!ENTITY param-rate
'<parameter>rate</parameter>' >
<!ENTITY param-ceil
@ -139,6 +152,10 @@
'<parameter>quantum</parameter>' >
<!ENTITY param-r2q
'<parameter>r2q</parameter>' >
<!ENTITY param-mtu
'<parameter>mtu</parameter>' >
<!ENTITY param-prio
'<parameter>prio</parameter>' >
<!ENTITY link-htb-param-rate
'<link linkend="vl-qc-htb-params-rate"><parameter>rate</parameter></link>' >
<!ENTITY link-htb-param-ceil

18
LDP/howto/docbook/Traffic-Control-HOWTO/software.xml
View File

@ -181,7 +181,9 @@ where OBJECT := { qdisc | class | filter }
The &linux-handle; is a user-specified number of the form
<replaceable>major</replaceable>:<replaceable>minor</replaceable>.
The minor number for any queueing discipline handle must always be
zero (0).
zero (0). An acceptable shorthand for a &linux-qdisc; handle is
the syntax "1:", where the minor number is assumed to be zero (0)
if not specified.
</para>
</callout>
<callout
@ -190,6 +192,7 @@ where OBJECT := { qdisc | class | filter }
<para>
This is the queuing discipline to attach, &sch_htb; in this
example. Queuing discipline specific parameters will follow this.
In the example here, we add no qdisc-specific parameters.
</para>
</callout>
</calloutlist>
@ -256,7 +259,7 @@ where OBJECT := { qdisc | class | filter }
id="ex-s-itcc-htb-only-text">
<para>
This is a class specific parameter. Consult
<xref linkend="qc-htb"/> for more detail on this parameter.
<xref linkend="qc-htb"/> for more detail on these parameters.
</para>
</callout>
</calloutlist>
@ -325,7 +328,8 @@ where OBJECT := { qdisc | class | filter }
arearefs="ex-s-itcf-classifier"
id="ex-s-itcf-classifier-text">
<para>
This is a &linux-classifier;.
This is a &linux-classifier;, and is a required phrase in every
&tc; &linux-filter; command.
</para>
</callout>
<callout
@ -350,7 +354,8 @@ where OBJECT := { qdisc | class | filter }
arearefs="ex-s-itcf-police"
id="ex-s-itcf-police-text">
<para>
This is the &linux-policer;.
This is the &linux-policer;, and is an optional phrase in every
&tc; &linux-filter; command.
</para>
</callout>
<callout
@ -367,14 +372,15 @@ where OBJECT := { qdisc | class | filter }
id="ex-s-itcf-burst-text">
<para>
The &param-burst; is an exact analog to &param-burst; in
&link-sch_htb; (the burst concept is a &concepts-buckets; concept).
&link-sch_htb; (&param-burst; is a &concepts-buckets; concept).
</para>
</callout>
<callout
arearefs="ex-s-itcf-mpu"
id="ex-s-itcf-mpu-text">
<para>
The minimum policed unit.
The minimum policed unit. To count all traffic, use an
&param-mpu; of zero (0).
</para>
</callout>
<callout xreflabel="action parameter"