frottle: Packet Scheduling and QoS for Wireless Networks

*** Summary ***

	./configure
	./make
	./make install


*** Detail **

*** Requirements ***

To compile frottle you will need iptables installed. You will also need the 
development IPQ library (part of iptables) installed. 

To do this, download the correct iptables source tarball 
(http://www.iptables.org/) to match your installed iptables (if you didn't 
install from a tarball). Do the usual "make" ("make install" if starting from 
scratch) and then "make install-devel".


*** Installation ***
Once you have iptables and IPQ installed you can compile frottle using the 
standard "./configure", "make" and "make install" commands. 

There is a 'feature' in iptables which may cause make to fail. If you get errors 
like:

	/usr/include/net/if.h:45: parse error before `0x1'
	/usr/include/net/if.h:111: redefinition of `struct ifmap'
	etc 

Then you need to edit /usr/include/linux/netfilter_ipv4/ip_queue.h and change 
"#include <net/if.h>" to "#include <linux/if.h>".


*** Client Configuration ***

1) iptables

You will need to add some rules to your firewall (iptables) script. Assuming the
wireless interface is eth1, some general requiremetns are:

	modprobe iptable_filter # load module 
	modprobe ip_queue # load module 

	iptables -A INPUT -p UDP -i eth1 --sport 999 -j ACCEPT 	# Allow control packets in
	iptables -A OUTPUT -p UDP -o eth1 --dport 999 -j ACCEPT # Allow control packets directly out 
	iptables -A OUTPUT -p ALL -o eth1 -j QUEUE 		# frottle the outbound packets 
	iptables -A FORWARD -p ALL -o eth1 -j QUEUE 		# frottle the outbound packets 


It is important that all outbound traffic (on the wieless interface) other than 
control packets are given the QUEUE target.  Failure to do so will bypass frottle 
and contribute to collisions/performance problems. You may however add other 
rules to block unwanted outbound traffic.

2) frottle.conf

To configure frottle edit the file /etc/frottle.conf. There are comments in that
file to help you. Then just run frottle from the command line, after first 
starting your firewall (see above). 

A typical client frottle.conf will have entries something like this: 

	# Run in client mode
	clientmode 1 
	# Daemonise, ie run in the background (optional)
	# (Quit frottle with 'killall -TERM frottle' if you use this)
	daemon 1 
	# The IP of the master
	# (use the other end of your /30 to HH)
	masterip 10.60.0.2 
	# Specify any ports you want to be high priority
	# (This only effects your outgoing traffic)
	hiports 22,53,7001,5223 
	# Set your wireless interface
	winterface eth1 
	# If an http server is available,
	# set a filename for a stats file output (optional)
	statsfile /var/www/html/frottle.html 


*** Master Configuration ***

For the best performance, all wireless traffic must be controlled by the frottle
master. This is achieved within wafreenet by running a server PC attached to the
access point and having a /30 (255.255.255.252) route to each client. Any client
traffic therefore passes from the client -> AP -> server, and back out if
required to other clients.  (Note: do not forget to disable ICMP redirects, 
i.e. "/bin/echo "1" > /proc/sys/net/ipv4/conf/all/accept_redirects".)

The server PC is setup as a frottle master, and is able to regulate the flow of 
inbound packets (which cause the most collisions).  The master also operates in
a 'selfclient' mode where data being transmitted by the server (and effectivly
all data being transmitted by the access point) is also regulated by frottle. 


1) iptables

You will need to add the following to your firewall (iptables) script.  These are
similar to the client, except the UDP direction is reversed. 

	modprobe iptable_filter # load module
	modprobe ip_queue # load module

	iptables -A INPUT -p UDP -i eth1 --dport 999 -j ACCEPT 	# Allow control packets in 
	iptables -A OUTPUT -p UDP -o eth1 --sport 999 -j ACCEPT # Allow control packets directly out 
	iptables -A OUTPUT -p ALL -o eth1 -j QUEUE 		# frottle outbound packets 
	iptables -A FORWARD -p ALL -o eth1 -j QUEUE 		# frottle outbound packets 

2) frottle.conf

A typical master frottle.conf will have entries something like this: 

	# Run in master mode
	mastermode 1 
	# Run as a self client as well
	selfclient 1 
	# Daemonise, ie run in the background (optional)
	# (Quit frottle with 'killall -TERM frottle' if you use this)
	daemon 1 
	# Sepcify any ports you want to be high priority
	# (This only effects your outgoing traffic)
	hiports 22,53,7001,5223 
	# If a http server is available,
	# set a filename for an info file output (optional)
	infofile /var/www/html/frottle-master.html 
	# If a http server is available,
	# set a filename for a stats file output (optional)
	statsfile /var/www/html/frottle-stats.html 


Polling parameters in the masters frottle.conf can be specified to fine tune the
usage of bandwidth. 

	# Polling parameters
	pollparams 60000,10,6000,7,5000,5,4000 
	# Time to wait for client response
	timeout 100 


The performance of the network can be seen from these parameters and the 
'poll/sec' as displayed on the client stats page. 

The polling cycle is basically the alternation of 'master sends data', 
'master receives data' (from the next client) ad infinitum. The point is the 
master sends data to any client between each poll. 

Based on the queuing priorities and high ports, pings (as is all ICMP) are 
always high priority. Therefore, when a client sends an echo request to the 
master, the echo reply will come back pretty quickly. The main delay is in the 
client waiting to be polled so that it can send the echo request. So therefore, 
if you are getting 8 polls/sec, your ping time can be anything up to (and just 
over) 125 mS depending when in the poll loop the echo request was queued. 

The default polling parameters are currently "60000,10,6000,7,5000,5,4000". 
This breaks down as follows: 

	60000 	The number of bytes the master (self-client) can send per poll 
		loop. This number is divided by the number of clients and that 
		much data can be sent between each poll.
	10,6000 The max number of packets,bytes that a client with a data rate
		of 5.5 Mb/s or over can send per poll 
	7,5000  The max number of packets,bytes that a client with a data rate
		of 2 Mb/s can send per poll 
	5,4000  The max number of packets,bytes that a client with a data rate 
		of less than 1 Mb/s can send per poll 


Therefore, if you have a 5.5 Mb/s connection and you are getting 6 polls/sec you 
should be able to send at a raw data speed of (6 x 6000) 36,000 B/s (35.2 KB/s). 

4 polls per second at the client is (near enough) 4 poll loops per sec, therefore
the master will be able to send at a raw data speed of (4 x 60000) 240,000 B/s 
(234 KB/s). 

*** Note - One exception to this rule is if a client still has packets queued 
after the completion of its poll sequence. In this case it will get an extra 
poll, resulting in twice the polls/sec than other clients and twice the data rate. 

The polling parameters can be changed dynamically, and we have experimented with 
different settings. Reducing the byte limit per poll does increase the polls/sec 
and therefore reduce latency. However a larger percentage of the time is spent 
on frottle overheads and less actual data throughput is achieved. It would be 
simple to come up with different polling parameters for different usages 
(uploading vs downloading vs gaming, etc) and have a cron job make the changes 
at set times. 


