Just to elaborate a bit, the article James sent around was not the original
Meru-Cisco feature story but rather a column that reports on results of
subsequent testing. In this column, I reported three things. First, Cisco
was unsuccessful in getting the Wi-Fi Alliance to rescind Meru's
certification. Since WFA certifies interoperability rather than standards
compliance, this is not proof that Meru isn't stretching standards a bit but
it still casts a cloud over Cisco's allegations. Second, I reported findings
from subsequent tests where we added Aruba to the mix and found that Cisco's
performance also cratered when co-located with Aruba gear. Again, that could
indicate that Aruba is also somehow playing foul as well (Cisco speculated
that they might be using a variation of PCF interframe spacing, though Aruba
denied it) but it doesn't look that way to me. Finally, we decided to re-run
these interference tests with different mixes of clients, using Atheros,
Broadcom, and Intel chipsets. We found significant differences in the
performance results. Atheros-based clients performed best.
 
The broader issues here relate to standards compliance (e.g., to what degree
can a vendor selectively implement certain elements of a QoS standard?) and,
perhaps more importantly, performance issues with Wi-Fi that may arise in
the future as the density of deployed networks results in increasing levels
of co-channel interference. I am particuarly concerned about the
intersection between private enterprise WLANs and public metro Wi-Fi
networks. It may not be a big problem today but I wonder if it will be a
problem in the future. We understand that our tests represent worst-case
scenarios that few enterprises currently experience but sometimes there is
value in pointing out the worst-case situations.
 
If there's a silver lining here, it may be that 11n is likely to push most
enterprises towards more pervasive 5 GHz deployments, where co-channel
interference is not such a big issue.
 
dm


  _____  

From: Peter Morrissey [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 14, 2007 11:03 AM
To: [email protected]
Subject: Re: [WIRELESS-LAN] Cisco vs. Meru article



I'm with you Jamie. Standards are extremely important, but only to the
extent that they serve the consumer. You still have to buy the whole system
from one vendor, so what is the difference? As long as the clients will be
interoperable, then I don't think it really matters. I could be missing
something, but that is my take on the whole thing. Meru appears to offer
some compelling QOS features.

 

Pete Morrissey

Syracuse University

 


  _____  


From: Jamie Savage [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 14, 2007 10:50 AM
To: [email protected]
Subject: [WIRELESS-LAN] Cisco vs. Meru article

 


Hi, 
   The attached article was in the May 28th issue of Network Computing.
Regarding Meru vs. Cisco and the possibility of interference with co-located
APs.   I'd be interested in any commentary.  We're currently a Cisco shop
(autonomous APs) and realize we're heading for a forklift wireless change in
the near future (most of our fat APs can't be converted to thin).  Even if
Meru violates the 802.11 standard (as claimed by Cisco), as we control the
airspace on campus, I guess we don't care if we cause interference issues
with devices (ie..rogues) that shouldn't be there in the first place. 

...........comments anyone?...........thx...............J 



James Savage                                   York University           
Senior Communications Tech.       108 Steacie Building
[EMAIL PROTECTED]                            4700 Keele Street
ph: 416-736-2100 ext. 22605            Toronto, Ontario
fax: 416-736-5701                                M3J 1P3, CANADA 

********** Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/groups/. 


**********
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

Reply via email to