Existing Wi-Fi Has Potential Packet Loss Issue

By Eric Griffith

November 09, 2006

Vendors think the negligible performance hit is written off by low expectations for WLANs, and that 802.11n is the fix.

The physical layer of the 802.11a and 11g standards has an "unavoidable packet loss issue," according to vendors VeriWave and Aruba Networks.

VeriWave discovered the issue this past summer during product testing, and reported it with Aruba to the IEEE 802.11 Working Group's meeting last September.

"One of our tests is a throughput test, which is defined in wired and wireless worlds as the maximum forwarding rate with zero loss," says Eran Karoly, vice president of marketing at testing company VeriWave. "Loss shouldn't be an issue with 802.11n networks... because each packet is retransmitted. It is corruptible, lossy, but has strong instruments for re-transmission if a packet doesn't arrive."

Apparently, however, the company found (double negative alert) "non-zero packet loss" in testing, which Aruba wireless architect Partha Narasimhan said was more evident due to the extreme nature of the test. He's been working with Wi-Fi for five years and never saw a hint of this, but adds that "the tests were never run this long at this capacity. We just suddenly discovered this now because of that."

The issue, specifically, is in the PLCP header in every packet sent over 802.11. Each PLCP header has fields that calculate the rate and the length of the packet, and that header's only protection comes from a single parity bit. Karoly says there are many ways the PLCP header can become corrupted, for very legitimate reasons. However, the one paraity bit can't detect the error. VeriWave estimates that the frequency of "undetected header corruption" could be as high as 50% of the time on any WLAN network, be it a home, hotspot or enterprise.

The example they use is a 100 bit OFDM packet sent at 54 megabits per second (Mbps). If an error happens with the PLCP header due to channel noise, the packet could convert to a different size and length. The receiver will be blinded for 5.5 milliseconds (ms) while it waits to receive a bigger packet; meanwhile, the transmitter is resending the packet over and over, waiting for acknowledgment of reception. Eventually, the transmitter quits. And the packet doesn't get sent at all.

Sounds dire, but both companies say it's not a major issue. In fact, it has probably been around for a long time, going unnoticed.

"For most people, the good and bad of wireless is lower expectations," says Narasimhan. "That's one of the reasons why the effects aren't noticed. It's probably happening, not every so often, but a couple of times an hour in normal traffic usage." He figures the tests that revealed the problem compressed a few hours of traffic through a WLAN into a minute or two to see the result.

"Where it is critical is voice," Narasimhan says. "Most data applications have tolerance for delays. But you'll see it during voice if you lose enough packets." He says it's not about the number of users, just the amount of traffic they generate.

VeriWave says it could also be crucial in roaming from access point to access point.

What's the solution for existing Wi-Fi? Not much, especially since it's gone unnoticed for so long. "We've tried to be pragmatic," says Karoly. "We don't think the 802.11 committee will change anything in the 802.11a/b/g specification. Where something can be done is 802.11n, as it is still fluid."

Narasimhan is a member of the IEEE 802.11 Working Group, and he says that the protections against this kind of thing are weak in existing 802.11a/b/g products, but that 802.11n has "better protection." He says the IEEE has to look and see if it's sufficient enough. "We don't want to make the same mistake on this [with 11n]," he says.

The 802.11 Working Group meets again next week in Dallas, Texas.

Karoly says, "[VeriWave is] not trying to make a big deal out of it. It can be solved in the future."



Comment and Contribute
(Maximum characters: 1200). You have
characters left.