#LyX 1.3 created this file. For more info see http://www.lyx.org/
\lyxformat 221
\textclass report
\begin_preamble
\input{preamble}
\end_preamble
\language english
\inputencoding auto
\fontscheme times
\graphics default
\paperfontsize 11
\spacing double
\papersize letterpaper
\paperpackage a4
\use_geometry 1
\use_amsmath 1
\use_natbib 1
\use_numerical_citations 1
\paperorientation portrait
\leftmargin 1.5in
\topmargin 0.9in
\rightmargin 1in
\bottommargin 1in
\headsep 0.17in
\footskip 0in
\secnumdepth 4
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle fancy
\layout Chapter
Technique for Multiple Path Routing
\layout Standard
\begin_inset ERT
status Collapsed
\layout Standard
\backslash
thispagestyle{empty}
\end_inset
\begin_inset ERT
status Collapsed
\layout Standard
\backslash
renewcommand
\backslash
figurename{Fig.}
\end_inset
\layout Standard
This section represents the discoveries using the User Mode Linux frame
work.
The main goal is to set up the Linux kernel to do multi-path routing, where
the kernel alternates the intermediate destination of the packet but has
the same final destination.
The Intermediate computer (proxies or gateways) sends the packet to the
correct destination.
Bottom line, setting up a system where there are multiple paths to the
destination.
\layout Standard
Within the Linux kernel, the multi-path enhancements are able to send alternate
the packets to different intermediate destinations.
For example in Fig.\SpecialChar ~
\begin_inset LatexCommand \ref{fig:Simple-web-request}
\end_inset
, 10 packets are in a simple HTTP request: six packets send from the client
and four return packets from the server.
If there are three gateways, the first gateway receives two packets (packets
one and seven); second gateway receives two packets (packets three and
eight) and; the third receives the remaining two packets (packets four
and ten).
\layout Standard
\begin_inset Float figure
placement H
wide false
collapsed false
\layout Standard
\align center
\begin_inset Graphics
filename Figures/04simpleWeb.eps
display none
\end_inset
\layout Caption
\begin_inset LatexCommand \label{fig:Simple-web-request}
\end_inset
Simple web request (left) and using multi-path routing (right)
\end_inset
\layout Standard
The ten packets transmitted are spread over the three proxies.
This is multi-path routing.
Multi-path routing the ability to spread the packet load between multiple
intermediate proxies or gateways so that the destination server does not
know about the intermediate gateways or routers.
Fig.\SpecialChar ~
\begin_inset LatexCommand \ref{fig:Small-network-with}
\end_inset
is an illustration of Multi-path routing.
\layout Standard
\begin_inset Float figure
placement H
wide false
collapsed false
\layout Standard
\align center
\begin_inset Graphics
filename Figures/06IpTunnelingThroughProxies.sxd.eps
display none
\end_inset
\layout Caption
\begin_inset LatexCommand \label{fig:Small-network-with}
\end_inset
Small network with the first IP header removed after proxy
\end_inset
\layout Standard
To follow all the standards for IP (Internet Protocol), the multi-path modificat
ions to the IP header are encapsulated in another IP header.
This technique of having two IP headers is called IP tunneling.
Fig.\SpecialChar ~
\begin_inset LatexCommand \ref{fig:IP-tunnel-packet}
\end_inset
shows a modified IP tunnel header used to route the packets.
\layout Standard
\begin_inset Float figure
placement H
wide false
collapsed false
\layout Standard
\align center
\begin_inset Graphics
filename Figures/05IpTunnelHeader.eps
display none
\end_inset
\layout Caption
\begin_inset LatexCommand \label{fig:IP-tunnel-packet}
\end_inset
IP tunnel packet header
\end_inset
\layout Standard
Four modifications were made to the individual Linux machines and to the
actual kernel to achieve multi-path routing.
The changes include: creating an IP tunnels to interface with the kernel
changes, modifying to the destination entry in the Linux kernel, and packet
buffering the incoming TCP packets.
\layout Section
Iproute2 to create IP tunnels
\begin_inset LatexCommand \label{sec:Iproute2-to-create}
\end_inset
\layout Standard
IP Tunneling is taking the packet and wrapping it with an additional IP
Header, so the packet has two IP Headers.
Generally the first IP header goes to the first packet destination; the
encapsulated header is the final destination.
\layout Standard
The main advantage to IP tunneling is hiding the packet's intermediate sender.
For this project when the packet is received by an intermediate computer
(proxy or gateway), the outer IP header is removed.
The intermediate computer removes the first IP header and forwards the
packet to the destination (according to the remaining IP header).
The remaining packet is repackaged with a new Ethernet frame and sent.
\layout Standard
Creating IP tunnels is not trivial, at first.
IP Tunnels needs to be turned on in the kernel.
The option is under the "network option" in the config menu (or .config
file).
If the IP Tunnel option is not turned on, an error messages like the ones
shown in Fig.\SpecialChar ~
\begin_inset LatexCommand \ref{fig:IP-error messages}
\end_inset
will appear.
If this error appears, check the kernel options and make sure that IP Tunnel
is selected.
Most Linux distributions have IP tunnel turned on as a module.
\layout Standard
\begin_inset Float figure
placement H
wide false
collapsed false
\layout Standard
\align center
\begin_inset Tabular
|
\begin_inset Text
\layout Standard
\paragraph_spacing single
ioctl: No such device
\layout Standard
\paragraph_spacing single
SIOCSIFADDR: No such device
\layout Standard
\paragraph_spacing single
tunl1: unknown interface: No such device
\layout Standard
\paragraph_spacing single
SIOCSIFNETMASK: No such device
\layout Standard
\paragraph_spacing single
SIOCSIFDSTADDR: No such device
\end_inset
|
\end_inset
\layout Caption
\begin_inset LatexCommand \label{fig:IP-error messages}
\end_inset
IP tunnel error messages
\end_inset
\layout Standard
There are three commands used to setup IP Tunnel
\begin_inset LatexCommand \citep{Cai2004}
\end_inset
:
\begin_inset Quotes eld
\end_inset
ifconfig
\begin_inset Quotes erd
\end_inset
,
\begin_inset Quotes eld
\end_inset
ip route
\begin_inset Quotes erd
\end_inset
and
\begin_inset Quotes eld
\end_inset
ip tunnel
\begin_inset Quotes erd
\end_inset
.
\begin_inset Quotes eld
\end_inset
ip route
\begin_inset Quotes erd
\end_inset
and
\begin_inset Quotes eld
\end_inset
ip tunnel
\begin_inset Quotes erd
\end_inset
are part of the iproute2 suite.
The iproute2 suite of utilities was designed to replace the
\begin_inset Quotes eld
\end_inset
route
\begin_inset Quotes erd
\end_inset
command.
Many technical websites state conversion is going along quick because the
adaption of the new
\begin_inset Quotes eld
\end_inset
ip route
\begin_inset Quotes erd
\end_inset
.
The
\begin_inset Quotes eld
\end_inset
route
\begin_inset Quotes erd
\end_inset
command has the routing information laid out differently and using
\begin_inset Quotes eld
\end_inset
ip route
\begin_inset Quotes erd
\end_inset
takes some adjustments.
\layout Standard
\begin_inset Float figure
placement H
wide false
collapsed false
\layout Standard
\align center
\begin_inset Tabular
|
\begin_inset Text
\layout Standard
\paragraph_spacing single
\align left
> ip tunnel add tunl1 mode ipip remote 172.31.0.172 dev eth0
\newline
> ifconfig tunl1 172.31.0.169 netmask 255.255.255.255 pointopoint 172.31.0.172 up
\newline
\SpecialChar ~
\end_inset
|
\end_inset
\layout Caption
\begin_inset LatexCommand \label{fig:IP tunnel commands}
\end_inset
IP tunnel commands
\end_inset
\layout Standard
\begin_inset Float figure
placement H
wide false
collapsed false
\layout Standard
\align center
\begin_inset Graphics
filename Figures/07TwoCompEstATun.eps
display none
\end_inset
\layout Caption
\begin_inset LatexCommand \label{Fig:Two computers establishing a tunnel}
\end_inset
Two computers establishing a tunnel
\end_inset
The commands in Fig.\SpecialChar ~
\begin_inset LatexCommand \ref{fig:IP tunnel commands}
\end_inset
are the commands needed to setup an IP Tunnel between 172.31.0.169 (client)
and 172.31.0.172 (proxy or gateway).
This establishes the tunnel and creates a device driver.
Packets are encapsulated with an additional IP header (as shown in Fig.\SpecialChar ~
\begin_inset LatexCommand \ref{Fig:Two computers establishing a tunnel}
\end_inset
).
The routing table is updated to inform the kernel where packets are heading
and if the packets need to be routed through a tunnel.
Fig.\SpecialChar ~
\begin_inset LatexCommand \ref{fig:command routing table IP tunnel}
\end_inset
is the command to update the routing table to use the IP tunnel.
\layout Standard
\begin_inset Float figure
placement H
wide false
collapsed false
\layout Standard
\align center
\begin_inset Tabular
|
\begin_inset Text
\layout Standard
\paragraph_spacing single
> ip route add 172.31.0.197 dev tunl1
\end_inset
|
\end_inset
\layout Caption
\begin_inset LatexCommand \label{fig:command routing table IP tunnel}
\end_inset
Command to update routing table for ip tunnelling
\end_inset
\layout Section
Changing the Linux network device driver
\begin_inset LatexCommand \label{sec:Changing-the-Linux}
\end_inset
\layout Standard
Fig.\SpecialChar ~
\begin_inset LatexCommand \ref{fig:Small-network-with}
\end_inset
shows how the packets are sent to an intermediate proxy (or gateway).
The standard direct connections go through the device eth0; the packets
destined for an intermediate machine through an IP tunnel are sent to device
tunl1.
The multipath routing takes advantage of using the INET's underlying device
drivers.
The modifications to the INET code alternates the IP tunnel addresses.
To make the multi-path scheme work, each outgoing packet is sent to different
tunnel device (e.g., tunl1, tunl2, tunl3, tunl4, and tunl5).
Selecting which packet goes to which tunnel device is done in the Linux
kernel in the code handling the IP header
\begin_inset LatexCommand \citep{Cai2004a}
\end_inset
.
\layout Standard
\begin_inset Float figure
placement H
wide false
collapsed false
\layout Standard
\align center
\begin_inset Graphics
filename Figures/08LinuxKernelwithmultiplenetworkdevices.eps
display none
\end_inset
\layout Caption
\begin_inset LatexCommand \label{fig:Linux kernel with multiple network devices}
\end_inset
Linux kernel with multiple network devices
\end_inset
\layout Standard
The Linux kernel receives a packet and uses pointers to the headers, and
payload stored in a structure called sk_buff.
There is a socket for each connection called an INET socket and another
overseer type socket, called a BSD socket as shown Fig\SpecialChar ~
\begin_inset LatexCommand \ref{fig:Linux kernel with multiple network devices}
\end_inset
.
The differences between the INET and BSD socket are talked about in detail
in Appendix D.
The INET socket which is responsible for the connection and has routing
information for the IP and Ethernet headers.
This information is stored in a structure called the dst_entry.
\layout Standard
The dst_entry is complex.
It is part of a bigger structure, called rtable as shown in Fig\SpecialChar ~
\begin_inset LatexCommand \ref{fig:TCP-routing-and}
\end_inset
.
Rtable stands for
\begin_inset Quotes eld
\end_inset
routing tables
\begin_inset Quotes erd
\end_inset
.
These routing tables structures work with the computer's routing table
to communicate the packet's destination and correct header and device informati
on.
Each time a packet is sent, the INET socket's dst_entry is consulted to
determine the correct header information.
The INET socket also contains the engine maintaining the SEQ and ACK numbers
for the connection stored in the tp_pinfo structure.
The dst_entry's settings for a direct connection uses the eth0 (Ethernet)
network device.
And for an IP Tunnel, the dst_entry uses the tunl (IP Tunnel) network device.
\layout Standard
Since the dst_entry is so complex, the kernel modifications relies on values
being set in the routing tables.
Actual modifications are not done to the dst_entry.
If the destination of the packet is not routed through the tunnel device
in the routing table and the multi-path routing kernel modifications are
activated, the kernel will try to route a packet with a dst_entry set for
a direct connect oppose to IP tunnel.
This will confuse the kernel and cause it to crash.
The information from the routing tables stored in the dst_entry and the
way the kernel uses this information should match.
\layout Standard
\begin_inset Float figure
placement H
wide false
collapsed false
\layout Standard
\align center
\begin_inset Graphics
filename Figures/09TCProutingandsocketstructures.eps
display none
\end_inset
\layout Caption
\begin_inset LatexCommand \label{fig:TCP-routing-and}
\end_inset
TCP routing and socket structure
\end_inset
\layout Section
Packet buffering
\begin_inset LatexCommand \label{sec:Packet-buffering}
\end_inset
\layout Standard
The Linux kernel stores outbound packets in a queue before flushing the
network device.
Multi-path routing uses multiple network devices and causes packets to
arrive out of order.
If one or multiple packets get delayed and the packet arrive out of order,
the TCP protocol sends another acknowledgment requesting a retransmission
of the delayed packet.
If this happens three times, the packet window is set to zero.
This poses a problem and is a major hit on performance.
\layout Standard
A solution to out of order packets is to queue the arriving packets and
wait for the delayed packet.
This packet buffering is done using the INET socket.
The INET socket is connection based, so there is one INET socket per connection
and is a structure containing information about the connection (e.g,.
sequence number).
\layout Standard
When the packet is queued, it is placed on the buffer in order of the sequence
number (earliest sequence number are closest to the head) and packets with
duplicate sequence numbers are removed.
When the packet with the correct sequence number arrives, the packets are
fed to the TCP processing code, one packet at a time.
The INET code stores the next expected sequence number in the ip_option.
If the next packet on the queue does not match what is expected, the buffering
continues.
\layout Standard
If the packet is lost, the expected packet will never arrive.
There are two solutions for missing packet.
The TCP timer will time out and send another acknowledgment requesting
the packet.
Another solution is limit the size of the buffer.
If the buffer size becomes greater than a given threshold, the packets
are processed as though the buffer did not exist and the TCP engine would
send another acknowledgment.
\layout Standard
To control the size of the buffer and various parameters of the multi-path
routing in the kernel, the proc file system is used to communicate with
the kernel from the application level.
\layout Section
Utilizing the Proc File System
\begin_inset LatexCommand \label{sec:Utilizing-the-Proc}
\end_inset
\layout Standard
The Linux proc file system has one purpose, to communicate information between
the Kernel and the user to fine tune the Kernel's performance.
The proc file system is not stored on the hard drive but is entirely in
memory and starts and disappears with the Kernel.
At startup the kernel populates the proc file system and mounts it to a
directory for the user and applications to have access.
For example, the IP routing table use the proc to communicate the gateway
and dev information needed to route incoming and outgoing packets properly.
When the command
\begin_inset Quotes eld
\end_inset
route
\begin_inset Quotes erd
\end_inset
is executed, the ārouteā program displays a file in the proc file system,
/proc/net/route, to the screen.
The route command just makes the contents of this file look more eye appeasing
to the user.
\layout Standard
This project uses the proc file system
\begin_inset LatexCommand \citep{Mouw2001}
\end_inset
to turn off and on the multipath routing and control other variables used
for scold loging and buffering.
Within the Linux code, a proc directory can be created in the /proc using
the command
\begin_inset Quotes eld
\end_inset
proc_mkdir.
\begin_inset Quotes erd
\end_inset
Fig.\SpecialChar ~
\begin_inset LatexCommand \ref{cap:Kernel-code-for a proc}
\end_inset
is the code to make a proc directory and populate an entry.
\layout Standard
\begin_inset Float figure
placement H
wide false
collapsed false
\layout Standard
\align center
\begin_inset Tabular
|
\begin_inset Text
\layout Standard
\paragraph_spacing single
\align left
#define MAXDATALEN 20
\newline
char bufferOnVal[MAXDATALEN + 1];
\newline
static int initScoldProc(void){
\layout Standard
\paragraph_spacing single
\align left
\SpecialChar ~
\SpecialChar ~
// creates the directory in the proc file system under /proc/sys/net/ipv4/mulipa
th
\newline
\SpecialChar ~
\SpecialChar ~
multiPathDir = proc_mkdir("sys/net/ipv4/multipath", NULL);
\newline
\SpecialChar ~
\SpecialChar ~
// creates a proc entry /proc/sys/net/ipv4/multpath/bufferOn
\newline
\SpecialChar ~
\SpecialChar ~
bufferOnProc = create_proc_entry("bufferOn", 0644, multiPathDir);
\newline
\SpecialChar ~
\SpecialChar ~
// sets the proc struct to use the following functions read, and write
\newline
\SpecialChar ~
\SpecialChar ~
// and sets the data value to char array, bufferOnVal.
\newline
\SpecialChar ~
\SpecialChar ~
bufferOnProc->data = bufferOnVal;
\newline
\SpecialChar ~
\SpecialChar ~
bufferOnProc->read_proc = procReadBufferOn;
\newline
\SpecialChar ~
\SpecialChar ~
bufferOnProc->write_proc = procWriteBufferOn;
\newline
}
\end_inset
|
\end_inset
\layout Caption
\begin_inset LatexCommand \label{cap:Kernel-code-for a proc}
\end_inset
Kernel code for a proc file system entry
\end_inset
\layout Standard
Towards the end, pointers to the functions
\begin_inset Quotes eld
\end_inset
procReadBufferOn
\begin_inset Quotes erd
\end_inset
and
\begin_inset Quotes eld
\end_inset
procWriteBufferOn
\begin_inset Quotes erd
\end_inset
are set the
\begin_inset Quotes eld
\end_inset
read_proc
\begin_inset Quotes erd
\end_inset
and
\begin_inset Quotes eld
\end_inset
write_proc.
\begin_inset Quotes erd
\end_inset
These methods are shown in the next frame.
The file system has an API for developers to use the proc file system.
Fig.\SpecialChar ~
\begin_inset LatexCommand \ref{fig:proc read and write method}
\end_inset
shows the two functions pass in for read and write.
These functions read in a pointer
\begin_inset Quotes eld
\end_inset
data
\begin_inset Quotes erd
\end_inset
and and type casts the value so the user can easily have read and write
access to the data.
\layout Standard
\begin_inset Float figure
placement H
wide false
collapsed false
\layout Standard
\align center
\begin_inset Tabular
|
\begin_inset Text
\layout Standard
\paragraph_spacing single
\align left
static int procWriteBufferOn(struct file *file, const char *buffer, unsigned
long count, void *data)
\newline
{
\newline
\SpecialChar ~
\SpecialChar ~
int len; char * inData = (char*) data;
\newline
\SpecialChar ~
\SpecialChar ~
if (count > MAXDATALEN) {
\newline
\SpecialChar ~
\SpecialChar ~
len = MAXDATALEN;
\newline
\SpecialChar ~
\SpecialChar ~
} else{
\newline
\SpecialChar ~
\SpecialChar ~
\SpecialChar ~
\SpecialChar ~
len = count;
\newline
\SpecialChar ~
\SpecialChar ~
}
\newline
\SpecialChar ~
\SpecialChar ~
// retrieve data from user
\newline
\SpecialChar ~
\SpecialChar ~
if (copy_from_user(inData, buffer, len)) {
\newline
\SpecialChar ~
\SpecialChar ~
\SpecialChar ~
\SpecialChar ~
return -EFAULT;
\newline
\SpecialChar ~
\SpecialChar ~
}
\newline
\SpecialChar ~
\SpecialChar ~
// write data to variable
\newline
\SpecialChar ~
\SpecialChar ~
inData[len] = '
\backslash
0';
\newline
\SpecialChar ~
\SpecialChar ~
sscanf(inData, "%d", &bufferOn);
\newline
\SpecialChar ~
\SpecialChar ~
//printk (KERN_CRIT "bufferOn: %d
\backslash
n", bufferOn);
\newline
\SpecialChar ~
\SpecialChar ~
return len;
\newline
}
\layout Standard
\paragraph_spacing single
\align left
static int procReadBufferOn(char *page, char ** start, off_t off, int count,
int *eof, void *data){
\newline
\SpecialChar ~
\SpecialChar ~
int len;
\newline
\SpecialChar ~
\SpecialChar ~
char *outData = (char *) data;
\newline
\SpecialChar ~
\SpecialChar ~
len = sprintf (page, "%s", outData);
\newline
\SpecialChar ~
\SpecialChar ~
//printk(KERN_CRIT "Read bufferOn %d", bufferOn); return len;
\newline
}
\end_inset
|
\end_inset
\layout Caption
\begin_inset LatexCommand \label{fig:proc read and write method}
\end_inset
Kernel code for a proc read and write methods
\end_inset
\layout Standard
To use the proc values values at the application layer, a
\begin_inset Quotes eld
\end_inset
cat
\begin_inset Quotes erd
\end_inset
command can show the contents of a variable.
The proc value can be written to using
\begin_inset Quotes eld
\end_inset
echo
\begin_inset Quotes erd
\end_inset
with a redirection.
Two examples are shown in Fig.\SpecialChar ~
\begin_inset LatexCommand \ref{fig: setting proc values}
\end_inset
\begin_inset Float figure
placement H
wide false
collapsed false
\layout Standard
\align center
\begin_inset Tabular
|
\begin_inset Text
\layout Standard
\paragraph_spacing single
\align left
\SpecialChar ~
\newline
root@walrus:/proc/sys/net/ipv4/multipath# ls
\newline
bufferOn bufferSize
\newline
root@walrus:/proc/sys/net/ipv4/multipath# cat bufferOn
\newline
0
\newline
root@walrus:/proc/sys/net/ipv4/multipath# echo "1" > bufferOn
\newline
root@walrus:/proc/sys/net/ipv4/multipath# cat bufferOn
\newline
1
\newline
\SpecialChar ~
\end_inset
|
\end_inset
\layout Caption
\begin_inset LatexCommand \label{fig: setting proc values}
\end_inset
Setting proc values
\end_inset
\layout Section
Testing using TC bandwidth limiting
\begin_inset LatexCommand \label{sec:Testing-using-TC}
\end_inset
\layout Standard
Rate limiting is a condition needed to test the multi-path routing.
Tc is a tool used for maintaining traffic
\begin_inset LatexCommand \citep{Devera2002}
\end_inset
; it is an interface to the IP chains in the kernel.
Of the different types of command line interfaces to IP chains, and tc
seems to be the easiest to set up.
The tc utility can be downloaded from the maintainers' website
\begin_inset LatexCommand \citep{Huberta}
\end_inset
and is included in newer version of Iproute2 (the software used to setup
the IP Tunnels)
\begin_inset LatexCommand \citep{Echantillac2004}
\end_inset
.
\layout Standard
The tc utility works per device.
Each device can be assigned a total bandwidth.
The bandwidth can also be partition between different outgoing IP address
using qdiscs.
For example, eth0 (default Ethernet device driver) is set to two different
destinations 128.198.60.172 and 128.198.60.173.
The total bandwidth for eth0 is 1024 kb/s.
The total bandwidth can be partitioned into a qdisc based on destination
address.
For this example, there is a one to two ratio used for the two classes.
So the qdisc with packets outbound to 128.198.60.172 (341 kbit/sec) has twice
bandwidth as the qdisc with packets bounded to 128.198.60.173 (683 kbit/sec).
\layout Standard
\begin_inset Float figure
placement H
wide false
collapsed false
\layout Standard
\align center
\begin_inset Tabular
|
\begin_inset Text
\layout Standard
\paragraph_spacing single
\align left
tc qdisc add dev eth0 root handle 1: htb default 12
\newline
tc class add dev eth0 parent 1: classid 1:1 htb rate $maxSpeed ceil $maxSpeed
\newline
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 341kbps speed ceil
1024kbps speed
\newline
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 683kbps speed ceil
1024kbps speed
\newline
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 1024kbps speed ceil
1024kbps speed
\newline
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 128.198.60.17
2 ip flowid 1:10
\newline
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 128.198.60.17
3 ip flowid 1:11
\newline
\SpecialChar ~
\end_inset
|
\end_inset
\layout Caption
\begin_inset LatexCommand \label{fig:setting up tc qdisc to limit bandwidth}
\end_inset
Setting up tc qdisc to limit bandwidth
\end_inset
\layout Standard
The Fig.\SpecialChar ~
\begin_inset LatexCommand \ref{fig:setting up tc qdisc to limit bandwidth}
\end_inset
shows the commands to set up the rate limiting using tc's qdiscs.
There are three sets of commands: set up the root for the eth0, set up
each class, and setup each filter.
\layout Standard
Finally there are additional kernel requirements when setting up the qc
utility.
Accroding the tc utilities' website
\begin_inset LatexCommand \citep{Huberta}
\end_inset
, the following QoS (Quality of Service) kernel options need to be set.
These QoS kernel options are listed in Fig.\SpecialChar ~
\begin_inset LatexCommand \ref{fig:Kernel options needed for tc to run}
\end_inset
\layout Standard
\paragraph_spacing single
\align left
\begin_inset Float figure
placement H
wide false
collapsed false
\layout Standard
\align center
\begin_inset Tabular
|
\begin_inset Text
\layout Standard
\paragraph_spacing single
\align left
#
\newline
# QoS and/or fair queueing
\newline
#
\newline
CONFIG_NET_SCHED=y
\newline
CONFIG_NET_SCH_CBQ=m
\newline
CONFIG_NET_SCH_HTB=m
\newline
CONFIG_NET_SCH_CSZ=m
\newline
CONFIG_NET_SCH_PRIO=m
\newline
CONFIG_NET_SCH_RED=m
\newline
CONFIG_NET_SCH_SFQ=m
\newline
CONFIG_NET_SCH_TEQL=m
\newline
CONFIG_NET_SCH_TBF=m
\newline
CONFIG_NET_SCH_GRED=m
\newline
\end_inset
|
\begin_inset Text
\layout Standard
\paragraph_spacing single
\align left
CONFIG_NET_SCH_DSMARK=m
\newline
CONFIG_NET_SCH_INGRESS=m
\newline
CONFIG_NET_QOS=y
\newline
CONFIG_NET_ESTIMATOR=y
\newline
CONFIG_NET_CLS=y
\newline
CONFIG_NET_CLS_TCINDEX=m
\newline
CONFIG_NET_CLS_ROUTE4=m
\newline
CONFIG_NET_CLS_ROUTE=y
\newline
CONFIG_NET_CLS_FW=m
\newline
CONFIG_NET_CLS_U32=m
\newline
CONFIG_NET_CLS_RSVP=m
\newline
CONFIG_NET_CLS_RSVP6=m
\newline
CONFIG_NET_CLS_POLICE=y
\newline
\end_inset
|
\end_inset
\layout Caption
\begin_inset LatexCommand \label{fig:Kernel options needed for tc to run}
\end_inset
Kernel options needed for tc to run
\end_inset
\the_end