frottle: Packet Scheduling and QoS for Wireless Networks
*** Summary ***
frottle is an open source GNU project to control traffic on wireless networks. Such control eliminates the common hidden-node effect even on large scale wireless networks. frottle is currently only available for Linux wireless gateways using iptables firewalls queue functionality, with plans to develop a windows client in the future.
frottle works by scheduling the traffic of each client so that one client does not swamp the Access Point to the extent where it loses sight of other clients. The scheduling of packets also prevents clients with stronger signals from receiving bandwidth bias. The unbiased allocation of traffic is dependant on all traffic passing through the frottle master.
Frottle has been developed and tested on the large community wireless network of WaFreeNet. We have found running frottle has given us a significant improvment in the network usability.
Testing results and further documentation can be found at:
http://www.wafreenet.org/?page=frottle
*** Operation ***
frottle operates at the IP layer, simulating a token ring network of sorts. Access to the network is controlled by the frottle master, sending each client a control packet (token) which contains information about how much data can be sent at this time.
Each client recieves its token and sends any required data, one at a time. This eliminates collisions, and with a reasonable signal packetloss is virtually zero. Also, since each client gets a limited slice of the bandwidth, everyone can get fair access regardless of their signal strength.
Whilst this mechanism does result in increased latency, overall network performance and utilisation can significantly increase.
*** Additional Features ***
Traffic queues built in to frottle assign different, dynamic priorities to different traffic. Most traffic has a default priority. Traffic to/from specified ports (and ICMP packets) are made high priority. Traffic for connections that have done more than 2 MB of data and have a rate of more than 5 KB/s are made low priority. When a client is polled, high priority traffic is send first, then default, then low until the poll quota is used.
Realtime info on each clients performance is available from the master in a html file and optionally at each client in a similar html file. (The names and locations of these files is set in /etc/frottle.conf.)
*** Independent user testemonial by SteveH ***
"I have a poor connection to the access point. I have a low snr (varies
from 7 to 11 dB) and rarely achieve better than a 2 Mb/s connection.
When we were running without any form of QOS I was often struggling to
achieve transfer rates of 3 kB/s. During testing of the current frottle
I am able to get my share of bandwidth. My transfer rates now average
80 kB/s download and 35 kB/s upload. Peaks for these are about double
this. The end result is a network which is usable and reliable."
*** WiCCP ***
We have also run WiCCP (http://patraswireless.net/software.html) for a test period of several weeks on our network, with a developer participating in testing and providing updates. WiCCP is the only other project we could find that has similar goals to Frottle. We wanted to compare WiCCP to Frottle so that we could use the better performing technology on our network.
Here is an extract from an email from Marcus that is a summary of the sort of results we saw:
"Now - in terms of performance comparison, Ive been monitoring my
latency and packetloss to Hills Hub. Over the past few weeks (testing
both WiCCP and frottle), my SNR has been terrible - between 4 to 6.
This is a pretty extreme circumstance, but it has highlighted some
differences:
WiCCP: avg packetloss ~ 15%, avg latency ~ 300ms
frottle: avg packetloss ~ 6%, avg latency ~ 150ms
I have not tested throughput with frottle in these poor conditions,
though throughput with WiCCP was reasonable. I can however see that
total Hills Hub bandwidth usage was much higer with frottle:
WiCCP: peak (2 hour avg) downloads ~ 100kB/sec, uploads ~ 50kB/sec
frottle: peak (2 hour avg) downloads ~ 250kB/sec, uploads ~ 180kB/sec
...
My 6% packetloss with frottle is due to VERY poor SNR ... it's an RF
error. Without frottle/WiCCP, the packetloss in my poor conditions
would be more like 90%.
Based on our observations, we will continue developing and using frottle on HillsHub, however keeping an eye on WiCCP and continuing to support their development/testing in any way we can. The above comments only relate to our environment, WiCCP may well be a better solution than frottle in other environments.
*** Contributions ***
Credit is due to:
Marcus (http://planetaxis-web.sytes.net/wireless/) for the concept
and proof of concept Perl program
ChrisK (http://www.narx.net/~chrisk/WaFreeNet/) for developing the
current C version of frottle
All the HillsHub connectees for their support in testing during
development.
Feedback, questions, praise and gifts can be sent to the developer (frottle@wafreenet.org)