Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Wireless Network Head-to-Head: Cisco Vs. Meru: Page 6 of 15

After our meeting, we began retesting, this time in an RF isolation chamber that removed any possibility of interference from other networks, using the latest Meru code. We shared packet traces with both Cisco and Meru, a standard practice during comparative reviews.

The next day, Cisco came back to us with more evidence of incorrect 802.11 duration fields, this time related to the 802.11 CTS-to-Self (Clear-to-Send-to-Self) standard. Note that though Cisco did look at our traces and point out duration-field anomalies, all testing happened independently in our lab.

When confronted with this new information, Meru clarified its previous position. While we interpreted Meru's initial statement as a denial that it was manipulating duration field values, it subsequently clarified that its response to our initial question was factually correct, that it was not manipulating the duration value of DATA frames. However, it was changing duration values in CONTROL frames. We were told that the company was simply taking advantage of new enhancements to the 802.11 standard included in the 802.11e QoS standard. Specifically, Meru referenced 802.11e's ability to transmit multiple frames using a TXOP (Transmission Opportunity), but our understanding is that this technique is reserved for 802.11e devices. Cisco was more direct, asserting that Meru is not implementing all the protocol elements required for 802.11e standards compliance, notable the "TXOP Limit" field required in 802.11e beacon packets. A subsequent e-mail exchange with Epstein eventually resulted in no response to a question we posed ,about whether Meu was employing all mandaory elements of 802.11e. We interpreted that silence as a decision not to respond to our question. More than a week later, just prior to our filing deadline, we finally heard back from Epstein, who defended the company's products as being fully compliant with 802.11 standards and apologized for the slow response, attributing it to a broken laptop the prevented him from connecting to the company's VPN.

Have we discovered Meru's secret formula? We're not sure. We know that Meru's architecture allows it to exert significant control over the manner in which 802.11 clients gain access to the network, and manipulating the duration field values appears to be a reasonable way to accomplish such a feat. It's conceivable that there are alternative explanations for how Meru is able to prioritize wireless traffic, but the company was unwilling to provide a full explanation, citing that information as proprietary. However, by not disclosing the details, it is inviting industry speculation that it is not adhering to standards."

Not The First Time, Not The Last