Congestion Control Algorithms for a Wireless Router

This post came out of research I did while trying to determine whether there was any advantage to switching TCP congestion control algorithms on my home wireless router (Linksys WRT350N). It turned out to be a fairly interesting topic, though it may not be applicable to anything aside from wireless routers (or other devices that concentrate traffic from both wireless and wired devices, both between each other and the Internet). If you are still interested, by all means read on.


TCP Vegas is what I would call a successor to TCP Reno/NewReno (which are the most commonly used congestion control algorithms on the net today). It uses a new method to estimate the bandwidth of the link in order to better reduce congestion and increase overall link utilization. In theory, this would be great and we would all enable Vegas right away. However, there are two issues which should be considered.


First, when a TCP Vegas connection shares a link with a TCP Reno connection (which as I said above was the most common algorithm currently in use), the Vegas connection will mistakenly detect much more congestion than actually exists, due to its interaction with how the Reno algorithm uses buffer space. The result is that the TCP Vegas connection backs off, and gets an unfairly small slice of the total available bandwidth.


Second, Vegas inherits Reno's problems when dealing with wireless networks. Basically, all these different algorithms are designed to allow many machines to communicate over TCP without overloading the bandwidth of the link between them. They watch out for packets that are never received, and interpret those missing packets as a sign that the link is congested. They then throttle down the rate at which they exchange packets so that packets are no longer being lost.


The problem with doing this over a wireless link is that, often times if a packet is lost it is not because there is congestion. Instead, it is more likely to have been a channel error (such as wireless interference, echos, etc). Westwood measures the bandwidth of the link in a way such that it is able to maintain high transfer rates when a channel error causes packet loss, but handles congestion-based losses similarly to Reno. Vegas does not have the ability to distinguish between different sources of packet loss, and so, like Reno, has significantly reduced performance on typical wireless links.


If you need to manage bandwidth between many sources on your network and assure better fairness, Vegas is excellent. However, while it may be excellent at supplementing or even replacing QoS, it will incur a penalty in available bandwidth (actually, link utilization) between your network and the Internet, and will significantly degrade overall wireless performance.


References:
http://www.signal.uu.se/Research/PCCWIP/Visbyrefs/Mascolo_Visby04.ppt
http://utopia.duth.gr/~ppapadim/ppts/aina06.ppt
http://cnlab.kaist.ac.kr/lectures/2007-cs540-spring/slides/new-tcps.pdf
http://www.cs.ucla.edu/NRL/hpi/tcpw/tcpw_papers/crb-slides.pdf
http://www.soi.wide.ad.jp/class/20060035/slides/07/
http://wiki.hsc.com/TCP

Trackbacks

Trackback URL for this entry is: http://blog.case.edu/bes7/mt-tb.cgi/18310

Comments

very useful article

Posted by cheapwirelessrouter on September 15, 2008 10:37 PM

Post a comment