Recently, two technology advances have been announced which promise to deliver significant improvements in speed on crowded or lossy networks:
- WiFox: http://news.ncsu.edu/releases/wms-gupta-wifi/
- Coded TCP: http://www.technologyreview.com/news/429722/a-bandwidth-breakthrough/
Both of these advances are based entirely in software, implying that they can be easily rolled out and installed on existing equipment – no hardware changes required. Given that technical details have yet to be announced on either method, it’s worth dissecting the claims made in the announcements to attempt to understand what these are, how they work, and more importantly, why they work. In this blog we’ll address WiFox. We addressed Coded TCP in this blog entry.
Where the Change will Happen
WiFox uses a software change on a wireless access point (AP). It’s entirely a last-hop change, and doesn’t appear to require protocol or client-side changes. This is essentially a Layer 2 solution.
What Problem is Solved
WiFox is designed for crowded Wi-Fi environments with lots of attached clients, competing for bandwidth. Unlike Ethernet switches, Wi-Fi can only support a single communication stream at a time on any given channel, even with MIMO. The situation is even worse when one remembers that channels overlap, leading to the common practice in 802.11b, g, and n (the 2.4GHz band) to use only channels 1, 6, and 11 (in the U.S.), as these are the three channels that have zero overlap. Given this limit of one communication stream at a time, contention quickly builds as more devices associate with the AP. Just like pre-switched Ethernet using dumb hubs or repeaters, contention leads to collisions, which leads to corrupted packets, and corrupted packets lead to retransmissions. Retransmissions compound the problem, as they are additional packets that need to be sent on an already crowded transmission medium. Upper layer protocols like TCP compound the issue, as they to tend to react poorly to media contention. In a perfect world, the network performance would degrade slowly, and TCP on both ends of the flow would detect the increased delay and adjust its RTT internally. However, an abrupt change in network performance – such as a collision storm or outside noise – doesn’t allow TCP the time to react. Instead, the protocol assumes that the next expected packet was lost, and sends a re-transmission. While the time-out triggering a TCP retransmission is much longer than an 802.11 retransmission, the result is the same: more packets, more slowdowns.
How this Problem is Solved
Since details haven’t been released, a lot of this section is speculation, but, assuming that the problem described above is the one being solved, it’s probably accurate.
WiFox addresses an underlying assumption in networking, that channel access should be fair. There’s a long-standing goal in networking that any given node should have as much opportunity to transmit as any other. That goal is reasonable if all nodes are likely to transmit equal amounts of traffic, but modern network usage, especially on the Web, tends heavily to the “download” model: clients send a small amount of data as a request, and servers send a large amount of data as a response. Furthermore, most traffic isn’t local: servers are on other subnets, if not on other continents. Therefore, the majority of data on any given subnet will be transmitted (from a Layer 2 perspective) from the router to the clients. On Wi-Fi, the router is most commonly the AP. Reading between the lines on the WiFox announcement, the solution seems to be tied to the send queue on the AP. If the AP has lots of packets internally waiting to transmit, then it will seize the channel to send all of its queued packets. The ability to seize the channel is part of the AP’s role in Wi-Fi. In Infrastructure Mode – using an AP – the AP coordinates all transmissions using small RTS/CTS messages with clients before each packet. All the AP has to do is stop giving permission to clients to transmit. The “magic” of WiFox comes from recognizing and leveraging this combination of factors: Web traffic patterns make the AP most likely to be the “top talker” on the subnet, it has awareness of its internal send queue, and it has the ability to suppress other nodes from transmitting until its own transmit queue is empty. The end result is that data is delivered “unfairly,” but more rapidly and more reliably to the clients.
WiFox is very simple to deploy, as it only requires installation on an AP. Its primary appeal will be Wi-Fi with lots of clients, which includes public Wi-Fi, corporate and industrial spaces, and tradeshows. However, its testing has been limited, up to a maximum of 75 clients so far. If its benefits are shown to be real outside the lab, I’d expect to see it become a standard feature in high-end APs within a few release cycles.