re: Futzing the ProtocolHow do you know the methods were sound? Can you even name what the methods were? Can you show how Meru got more access to the medium?
Let me ask you this. Say you have an access point that has its backoff set to 256 slots. And you put another one next to it that does the standard behavior. And then you run the same traffic downstream. One wins. One loses. The winner looks like he cheated, but that's because the scheduling is opportunistic according to the standard and the loser really cheated to make their point. Both Cisco and Meru probably sent their engineers and made their own code, so both had opportunity, but Cisco has a great incentive to hobble their own AP in this one unique test that wasn't a part of the main tests, as the article states. Only complex air trace analysis would show that Cisco rate-limited their code. I see motive and opportunity for Cisco to cheat. Inquiring minds want to know!
You name names so easily. Why don't you be a real man or woman and name yourself?
I suspect you have sour grapes because you must have been fired from Meru. That would explain your intricate knowledge of all of their management, and your constant desire to mention their names. Bury your axe elsewhere.
Who cares about this secret sauce discussion? I want more tests, real tests with real devices with all vendors participating. Besides, if what you say is true and there is no such thing as secret sauce, then why does anyone care about Cisco's claims for patented RF management whatnots and Aruba's constant talk of security? Perhaps each of these vendors does have something unique to offer, and you just don't like one of the vendors personally.
re: Futzing the ProtocolA Meru paid shill or a marketing critter made tall claims about Meru's secret sauce and trade secrets. I challenged that and I believe my challenge was logical and rational. It is likely that secret sauce is more likeky a protocol violation than any worthy intellectual property. And Dave's response is to dismiss my challenge with a "who cares about this secret sauce discussions?" Isn't that telling something about Dave and his affiliations?
Dave, you acknowledge my intricate knowledge of Meru and its management practices. I believe therefore I've earned credibility that Meru hasn't yet. So I'll consider your demand to name myself after you have first asked Meru and its founders to answer or admit to the numerous questions posed in this discussion already. Should you want to further establish my credibility, ask around and you'll find my points are verifiable to the last letter.
Lastly, Cisco's patented RF management is...patented. Review the patent and contest that, if you don't care for it. Aruba and Cisco, unlike Meru, are open to third-party evals and bakeoffs. They don't fall back on a defence of "secret sauce" only to dismiss it with a "who cares?" when challenged.
With Meru's flawed genetic history how can one expect intellectual honesty or rigor?
As for your imperious order that I "bury my axe elsewhere"--you are not king and nobody your slave. Instead of presuming axes and agendas why don't you deal with the facts I've laid out?
re: Futzing the ProtocolGood call, let's argue facts. You make the conclusion that Meru is most likely violating the protocol. What sort of violation is it? Neither Dave Molta nor Network Computing were able to describe it. All they could do was mention a side-by-side test and a suspicion that they silence the air by inflating Duration fields. I want to see AiroPeek of this Cisco and Meru interference test.
(By the way, PCF, which Aruba used in Network World, inflates the Duration field as a part of the standard. That's why the standard has Duration fields. I don't think inflating the Duration fields are important, only whether APs hog more than an installer would expect and control. If I turn the power level up on my AP and put a big antenna on it, I kill my neighbor's AP. But I can turn it off and be nice if I want to be.)
I don't care about secret sauce discussions because you are bloviating. I doubt Meru has any wonderful secret sauce, but I doubt it matters, if they can do better in deployments. I don't get paid by any wireless vendor, unlike you must have been, and probably still are.
So, should I ask the founders of Meru? Why bother? You take shots at everyone from the safety of your anonymity. I don't care if they screwed anyone over. Larry Ellison is supposedly a jerk, and yet we use Oracle. I can't convince my boss to not buy from a vendor because of the founder. Now, if the salesman is a jerk, that's a whole nother beast.
You are right that Meru doesn't do any evals. That bothers me. I don't think people doing guerilla evals (such as Farpoint did) is right. But I would love to see someone do another head to head, with Aruba, Cisco, and Meru's full support, and then we will see.
As for your axe, I never said I was king. I said I was Dave. But, I think that no one is learning anything from your complaining about founders. The real issue is whether Meru is violating a standard, whether it's a minor thing or a major part of their solution, whether Cisco cheated to try to crush a competitor, and whether this has anything to do with the networks I have to install. I want to learn. You, on the other hand, are already full of answers.
If you know how Meru is cheating, tell us. If you know how Cisco does their RF better, tell us. If you don't, then go take a nickel and call someone.
re: Futzing the ProtocolInnuendos and accusations that I'm getting paid by a wireless vendor, have an ax to grind against Meru, etc. amuse and only highlight the defensiveness, paranoia, opacity, and other traits readily observable at Meru starting with its founders. Ignoring those distractions here are some observations that help take this discussion forward.
The Network Computing article mentions several occations where Meru shifted its explanation, wasn't forthcoming with an answer, or used the "it is proprietary"/"secret sauce" gambit as an explanation (also seen here in a prior posting). Not to mention the "my dog ate the homework" with a modern twist involving broken laptops and VPNs.
When all that emerges from a company with a questionable genetic history it is pertinent for Meru's customers, employees, and investors (current and future) to know about the management dysfunctionality that started with the founders and continues to this day. I've presented numerous facts, all readily confirmable, that highlight that aspect of Meru.
Numerous industry stalwarts have attempted to figure out Meru's much-touted "secret sauce" and concluded it is nothing but a set of (shifting) protocol violations. Meru has problems interoperating with others, they shift their explanations and keep referring to their "secret sauce" instead of filing patents, their architecture is different from everyone else, they don't participate in standard, industry-wide third-party tests, they don't do evals (a normal industry practice), etc. Their credibility is in tatters. At this stage the burden of proof is on Meru to answer questions and explain themselves and especially so given their history.
Trying to decipher and pin down Meru will be successful with some cooperation from them or when their bluster comes crashing down. Until then it will be a pointless exercise as their product is buggy, their support non-existent, their standards compliance questionable, and their explanations inconsistent.
Yes, I can show that Meru got more access to the medium. Read my first post. It outlines a test that would show how to find out if a vendor is getting more access. On a side note, it is the same test that the authors ran. I wrote my post before reading the actual test.
You are saying that Cisco changed their AP's for the test? Seriously?
Here is why Cisco wouldn't do it. Lowering the contention windowGÇÖs n value increases the chances of collisions. Dramatically. So, letGÇÖs say Cisco was devious and changed their window to 2 to the 3rd -1, giving them 8 slots to choose from (0-7). This would increase the collision rate significantly when they were used in conjunction with each other.
Wired vendors were accused of this for the CSMA/CD. That is fine, because in a switched network, there is a one to one ratio for devices even having the chance of a collision.
In a wireless network, if a vendor wanted to be faster and changed their contention window, it would be great if there were only a few devices. But with an entire network of their devices the only thing that would happen is an increase in collisions.
Cisco didn't adjust their contention window. Meru is either messing with duration values or the contention window. Oh, Meru could mess with their own contention window because if two AP's randomized the same number, it (the controller) could prevent a collision that would normally occur. I bet a nickel that is part of their secret sauce.
It's good to see that you are willing to discuss real information, rather than hype. But, I think you did not follow what I said very well, and so I should elaborate.
First off, there's no real way of knowing what happened, until Network Computing stops hiding behind their magazine and publishes the full traces of the test. Just mentioning that they "ran a test" doesn't cut it. Yes, we're all speculating then.
Now, it's been a while since I've dug around CSMA...I'm an RF guy by training. But, I understand it all pretty well. What I was saying is that Cisco probably increased, not lowered, their backoff. That would make Cisco do, say, 256 slots for themselves, and 16 slots for the other guys. Now, 256 slots won't show up on a Cisco by itself test very easily, but place it next to any standard device, and the standard device will kill it. It's the same argument you made, but I am assuming that Cisco would tune down their AP to prove the point they've tried to make for years.
Now, you don't know that Cisco didn't adjust things and Meru did, because it's all relative. What I would do is suggest one more test.
Take the same APs, making sure they still show the behavior. Now, change the Meru AP out for an Aruba AP. Or a Linksys AP. If the problem still happens, then I'm right and you're wrong. If the problem doesn't happen, then you may be right.
Either way, we don't know because we don't have the information in front of us. And that makes me upset. We can resolve this with some good, old fashioned research, rather than reporters or analysts running tests that are above their heads.
BTW, changing backoffs are no longer cheating. I was surprised to learn that 802.11e lets the AP pick whatever backoff it wants. But that's what it says. Anyone can pick any backoff for any traffic class. The laptop has to follow the AP, though.
Sit back and chill on these arguments...not really into the Meru, Cisco , Aruba things these days but I must say that the team that everyone emulates (attitude, execution, practices is the Airespace team). That book was written on Nortech Drive and more than two years later folks are still getting their asses kicked by Airespace 101. This is too funny!
Give it up, the originals are always that, original! Airespace folks are ruthless, over - the - top, balls in a wheelbarrel type of folks! Dude, I tried to help Aruba out and did but it just ain't gonna happen! Can walk on water but can't raise the dead!
Look, the mission now is to get some equity out of the remaining wifi switch startups! My assessment:
1) Trapeze - no love for ya'. Anytime you steal an innovators idea and try to use it angainst them you are DOOMED! Everybody is gonna' get the G2 and totally hate ya'!
2) Aruba - founders ---too young, but pioneering. Arrogance and culture got to ya'. Little kids from Ohio will sit in a lab and totally destroy your architecture and ego because of an elevator conversation. This is real... and you underestimated the intelligence of people without something that you recognize....for whatever reason. VC's just need to snag it bag it. Everyone that I see popping up from there these days are either people that were destroyed or displaced from the early days....
3) Airespace folks --- much love and hate for ya'. But, you were the ones that were over the top. You deserve it and I would not have a beer with you in a bar because you are ruthless (smile). Now, for those of you that are ready to roll out of Cisco, or Aruba my advice is to dig deep and hard. Stay together and roll as a team. You really don't need VC's or crazy ego's to get things done these days. Lot's of opportunities and you can (if you chose) moon the system.
Going back to the pool and chilling for a bit....just waiting for something cool to pop out of here. Geez !!!!
Can you help me understand your statements on Aruba? Who are the kids from Ohio? Who did the Arubans underestimate?
Also, what innovation did Trapeze steal? Didn't Netscreen jump into an existing market (stealing innovation) with straightforward enhancements and do well.
I am neutral toward all these companies, but I'm trying to understand what's underneath your thoughts.
Let me ask you this. Say you have an access point that has its backoff set to 256 slots. And you put another one next to it that does the standard behavior. And then you run the same traffic downstream. One wins. One loses. The winner looks like he cheated, but that's because the scheduling is opportunistic according to the standard and the loser really cheated to make their point. Both Cisco and Meru probably sent their engineers and made their own code, so both had opportunity, but Cisco has a great incentive to hobble their own AP in this one unique test that wasn't a part of the main tests, as the article states. Only complex air trace analysis would show that Cisco rate-limited their code. I see motive and opportunity for Cisco to cheat. Inquiring minds want to know!