The Wi-Fi Guarantee September 9, 2010

Posted by Devin Akin in : Uncategorized , add a comment

You can handle the truth.

Because Wi-Fi uses a shared, unlicensed transport, there are no RF-related guarantees.  None.  Anyone who says different is trying to pull the wool over your eyes and deserves to be smeared in grape jelly while receiving 50 lashes with a wet noodle…except for the people who make Wi-Fi Speed Spray, because that’s still funny after 7 years.

Don’t believe the five 9’s hype…or four 9’s for that matter.  There are nein 9’s in Wi-Fi.  It’s all relative to a significant set of variables (many of which are outside of the administrator’s control), and there’s not a single Wi-Fi customer anywhere who can SHOW that their Wi-Fi system has been successfully operating for five 9’s.  It’s all theoretical marketing goo.

You can guarantee to *try* to do something.  You can guarantee that one thing can be prioritized over another, but neither is guaranteed to do anything.  You can even guarantee RF coverage, but even that not-worth-the-paper-it’s-printed-on guarantee can be diminished simply by moving some obstacles in the RF environment.  Not only is RF a shared, unlicensed transport medium, but the 802.11 protocol and the Wi-Fi Alliance certifications built around it (such as WMM) are statistical-based…not absolute.  Wi-Fi connects to Ethernet at some point, and so the uptime of the Ethernet network must also be taken into consideration.  Some vendors use cloud-based controllers (Aerohive is not one of them, though we certainly do have cloud-based management), and so if the WAN pipe goes down, cloud-based controller vendors will lose uptime.  How often is your WAN pipe down?

It all comes down to which vendor’s platform is best designed to give the customer the most reliability at a price that they are willing to pay.  Restated, it comes down to the reliability and cost of a Wi-Fi system’s architecture.

To show you what I mean, refer to the quadrants below.

Using today’s de facto standard controller-based architecture (shown in the lower-left quadrant), you can achieve a higher level of availability (top-left), but at a significant cost.  So significant, in fact, that it’s highly unlikely that you, the customer, will be willing to pay the price.  So if you cannot afford this level of high availability, what do you do?  Hint: change your architecture.  Check out the controller-less architecture in the top-right quadrant.  Regardless of what dies (APs included), a properly-designed controller-less network has no single points of failure, without the added cost of redundant anything.  It also scales linearly without an upper limit.

Back to the guarantee discussion…

Some vendors make coverage guarantees, but sometimes these guarantees aren’t what they seem.  For example, one vendor offers a -72dBm coverage guarantee, in writing.  For those who understand RF, that’s like saying, “I guarantee that this is a car” without noting whether it will crank and operate as implied.  -72dBm is 25% of the power needed for the “triple play” of voice, video, and data.  MOST vendors will tell you bluntly that you need somewhere between -65 to -67dBm of signal strength from the AP to the client in order to carry voice traffic reliably, and they are right in doing so.  We’ll split the middle and say -66dBm, which is 6dB more power than -72dBm.  +6dBm is 4 times as much power, so -66dBm is 4 times the RF power as -72dBm.  That means that this vendor’s guarantee is worthless and that they are taking advantage of the customer’s lack of understanding of RF.  Once the customer has purchased their equipment, they are stuck with it and must buy MUCH more equipment in order to make voice, video, and data work reliably.  This -72dBm guarantee is just a way to get “in the door.”  It’s unethical and dispicable to treat customers in this way.

Some vendors offer SLAs (Aerohive was the first to do this in fact), but these are not guarantees.  They are “service level assurance”, which means that the Wi-Fi system will monitor client connectivity and throughput and then act upon any problems in such a way that it will give the client the best possible chance of meeting the SLA parameters the administrator has assigned.  It’s MUCH better than not having an SLA, but it NOT a guarantee.  If you meet anyone who says different, please refer to my earlier comments regarding jelly and noodles.

Make sure you understand what each vendor is…and isn’t…saying about their system, their feature(s), and their offer.

To borrow (and to mutilate) a line from George Zimmer:

You’re going to love the way your Aerohive Wi-Fi works.  I guarantee it.

Wi-Fi Spectrum Analysis? What’s That? September 6, 2010

Posted by Devin Akin in : Uncategorized , 8comments

Man, I hear all kinds of back-n-forth these days regarding spectrum analysis.  I’ve heard, “Cisco does it this way, and that’s the best way” and, “Aruba does it that way, and that’s best way EVER” and even,”it doesn’t really matter since it’s just a check-box on an RFP”.  Anyone associated with a vendor on this topic has to “toe the company line” since it’s a hot topic, but I have a feeling that those who are looking for Wi-Fi solutions have at least an opinion on this topic.  I’ll likely get a good poke in the ribs and a harsh look just for talking about this feature when Aerohive hasn’t released anything in this area to-date (note how I rode the fence there in my terminology, not eluding to anything, nor denying it either).  I’m probably supposed to pretend like spectrum analysis doesn’t matter or that it doesn’t exist until of course, WE launch it.  Then it’ll be expected that I make some big whoop-ti-do about it thereafter, blogging, Twittering, and touting how Aerohive’s is better than Cisco’s, Aruba’s, and even Rohde and Schwarz simply because we use spectrum-enhanced pixie dust in the manufacturing process.  I’ll borrow a line from my friend David Callisch: “Our products are constantly late cuz our engineers are perfectionists.  And it shows.”  That’s where we are on this spectrum analysis topic: we want to get it right, even if it’s late.

In case you’re a little slow, that last paragraph was filled with between-the-lines complaining about corporate marketing politics, over which I have no control or influence.  I work for ‘the man’ now, so my bark is that of a neutered wiener dog, and I have to opt to say nothing more than I care to admit .  I ask you, “how the hell can a blogger be successful by saying nothing?”  It’s a conundrum.  Suggestions welcomed.  I digress.  Moving right along…

One thing is for sure: customers almost always want more features for less money.  So I’ll make the assumption that now that AP-based spectrum analysis features exist, customers will want it in their system…provided they don’t have to pay extra to get it.  That said, some folks may be willing to pay a tad extra to get it, but my gut says that they aren’t willing to pay much.  Think of it similarly to WIPS, which is a 10/80/10 market.  10% don’t care about security, 80% want whatever is free and “good enough”, and 10% want everything that you can offer them regardless of price.  Spectrum analysis is a lot like that.  With Cisco’s spectrum analysis enabled APs costing an extra $500/AP, even Cisco knows that they can’t pitch it as, “make every AP an spectrum-analysis AP today!”  Instead, they approach it like they would dedicated WIPS sensors – a 1:4 or 1:5 smathering of spectrum-analysis APs as a phase-in approach.

Everyone should realize that spectrum analysis will soon enough, like airtime fairness and integrated rogue detection, be “table stakes” for infrastructure vendors.  The functional differential between each vendor’s spectrum analysis, WIPS, airtime fairness, and a half dozen other major features will shortly be irrelevant.  The technology is maturing just that fast.

I’d love to hear some feedback on how important spectrum analysis is to your deployment (whether it is or it isn’t important) and how you view spectrum analysis as an infrastructure-side technology.

Branch Office Wi-Fi September 2, 2010

Posted by Devin Akin in : Uncategorized , add a comment

In order to make this blog about Branch Office Wi-Fi a little easier to follow, I’m going to break it down into two sub-sections: micro branch offices (read: small) and macro branch offices (read: big).  Not all branch offices are created equal, and therefore not all Branch Office Wi-Fi solutions serve each of these two distinct markets equally well.  Here’s the gratuitous blog picture.

The Micro Branch Office

From a Wi-Fi perspective, this type of office is served with a single AP.  In order to keep costs down in organizations who have hundreds or thousands of branches, vendors who produce gateways that have integrated Wi-Fi are usually considered alongside enterprise-class Wi-Fi vendors.  While there are certainly scenarios where an organization wants to keep Wi-Fi separate from routing/switching/firewalling/gatewaying (I just made that word up), such as when the router/switch/firewall needs to be in one location and the access point needs to be in another location, but if their branch offices are tiny and won’t grow, sometimes throwing it all into one box can make sense financially so long as the necessary feature set is available in the platform.

Enterprise-class Wi-Fi vendors rarely wish to have their APs perform these types of functions, and when they do, they rarely work as well as dedicated gateways designed to do those particular non-WiFi functions.  I’ll give you an example…

Motorola has a reasonably good enterprise-class Wi-Fi solution.  Nothing super fancy.  Nothing revolutionary…but it’s not bad as Wi-Fi solutions go.  I’d certainly choose it over Cisco’s solution.  Anyhow, Motorola’s AP-7131 can be turned into a single-AP branch router.  When I first played with it, I thought, “hmmm…pretty nice…” until I tried to actually get it to work as described.  Anyone dealing with that – you have fun now.  …and don’t call me for support.   Hey, I’m not railing on Motorola actually.  Again, as enterprise-class Wi-Fi solutions go, they have a decent solution, but branch office routing isn’t their area of specialty.  It’s no different with other vendors who are trying to be everything-to-everyone.

The other side of that coin is when the SOHO and SMB vendors try to step up into the enterprise market.  There are quite a few in that market actually: NetGear, SonicWall, WatchGuard, Fortinet, and many more.  They all make decent UTM gear for the SMB and even for branch offices in the enterprise, but their Wi-Fi solutions (for the ones who have them) are weak.  When they move to WPA2-Enterprise with multiple APs, their solutions aren’t really worth discussing.

There’s a bit of a gap at the moment, where the SOHO/SMB vendors are trying to reach upward and the enterprise players are trying to reach downward.  The best technical fit for the customer often depends on how the customer’s network architect likes to build out their networks and what feature sets they are looking for.

The Macro Branch Office

From a Wi-Fi perspective, this type of office is served with multiple APs.  The larger the branch, the more toward enterprise-class Wi-Fi offerings customer usually lean.  There are five workable options for the macro branch:

1) Autonomous APs – many UTM vendors do this

2) Remote APs – which connect to a centralized (e.g. HQ Data Center) controller over a WAN pipe

3) Local controllers at each branch with thin APs

4) Local gateways that act like controllers with thin APs

5) Controller-less APs that coordinate the control plane among themselves

Option 1 sucks.  Don’t do it.
Option 2 is usually no better than option 1, and depending on the vendor, sometimes worse.
Option 3 is very, very expensive, though it will work fine.  Did I mention how expensive this option is?
Option 4 isn’t bad, but it depends on how well the vendor has implemented both sides of the equation (and it’s very rare that a company is good at Wi-Fi and branch office routing/firewalling).
Option 5 yields inexpensive and super-solid Wi-Fi, but doesn’t offer branch office gateway services (though it will offer firewalling and VPN).

I’m starting to wonder when those mega UTM companies that focus on security and infrastructure are going to start finding ways (OEM, acquisition, new product lines, or whatever) to approach the macro branch situation.

Has you installed lots of Branch Office Wi-Fi, faced the micro- versus macro- scenarios, struggled over finding the best solution, and care to comment on your experiences?

The Relevance of 802.11n Transmit Beamforming (TxBF) August 30, 2010

Posted by Devin Akin in : Uncategorized , add a comment

How long have we been hearing about and waiting for 802.11n Transmit Beamforming (TxBF)?  Quite a while I’ll tell ya…2 years now.  I remember it all starting with the Wi-Fi Alliance certifying equipment based on Draft 2 of the 802.11n amendment back in mid 2007.  When all of us standards geeks jumped right into the ~600 pages of changes to the 802.11-2007 standard.  When we got to the TxBF section, it was like falling into quicksand…even the most astute mind could drown in that stuff.  After a few months of re-re-reading those sections, we finally had a handle on it and began writing about it in blogs, books, whitepapers, and the like.

Since then…crickets.

* Who currently supports 802.11n TxBF?  There’s nothing on the market yet, but some new Enterprise-class Wi-Fi chipsets now have single-spatial-stream TxBF capability.

* Is there a Wi-Fi Alliance certification for (or that includes) TxBF?  No.

* When will the industry adopt 802.11n TxBF as table stakes?  No idea.  No announcements by anyone.

For 802.11n TxBF, the time of going from “No idea when” to “Table stakes” could be measured in years…or perhaps never.  Let me explain why.

Step 1:

Enterprise Wi-Fi chipset vendors like Marvell, Atheros, Broadcom, and others have to build it into their chipsets and then supply the chips and code to the AP and Client vendors.  This is happening, but only for single spatial stream transmissions at this time.

Step 2:

Enterprise equipment manufacturers like Aerohive, Aruba, Cisco, Motorola, and others have to integrate these chipset and their code into our platforms.  This goes for both infrastructure and client vendors.  This requires a new spin of hardware, which ain’t quick.

Step 3:

The Wi-Fi Alliance has to decide to put TxBF functionality into one of its Wi-Fi certifications, and perform plugfests that include it.  5 AP and 5 client vendors must participate in the process or there will be no certification.  There’s actually alot more to this step, but I’m trying to keep this brief.

Even if we get through all of these steps, we’ll still only have TxBF support for a single spatial stream (up to 72 Mbps) due to how 802.11n TxBF works.  It takes at least two radio chains to do beamforming, and so whether you have 2 or 3 radio chains, you’re only going to be transmitting one spatial stream.  Additionally, 802.11n TxBF is only good for medium range.  At close range, you don’t need beamforming because the client and the AP can hear each other perfectly well.  At longer distances there are too many reflections within the environment for the transmitter (Tx) and receiver (Rx) to characterize the channel well enough to do TxBF with any accuracy.

There is one cool thing that we can do with TxBF that’s useful in the interim though, and that is extending the distance of mesh links some.  Since interoperability with yourself isn’t too much of a problem, some vendors may choose to support TxBF on mesh backhaul links for the purpose of extending the range of such links by some modest amount…and modest is yet to be defined.

So the summary is:

It’s going to be a long while before TxBF will be used (due to client support, Wi-Fi Alliance certification, etc), and even then, it will be useful for medium range, indoors, with a single spatial stream.

Anyone care to chime in?

WLANs in K-12 – Part Deux August 26, 2010

Posted by Devin Akin in : Uncategorized , add a comment

In my previous blog, I tossed out some questions regarding WLANs in K-12, and now it’s time to talk about some technical challenges in that market.  There are three topics in particular that we hear about all of the time.

1) Compatibility with iEverythings
2) Tools for the reluctant administrator (aka the network operator)
3) Ease of management

Compatibility with iEverythings

In K-12 WLANs, diversity of the client population depends on school policy.  If the school issues client devices to students, that certainly makes things a little easier from a compatibility standpoint, but it’s an expensive proposition.  If you took only a single client device vendor as an example (let’s say Apple), then you’d have to consider iPhones, iPods, iPads, MacBooks, MacBook Pros, MacBook Airs, iMacs, Mac Minis, and Mac Pros.  Good grief.  Unfortunately, I’m not exaggerating here.  ALL of those, plus hardware, operating system, and driver variations on many of them could be connecting to the network all at the same time.  The compatibility testing for just Apple client devices could take forever.

What if we dove into HP, Lenovo, Toshiba, Blackberry, Motorola, and all the rest?  The combinations are staggering.  While the Wi-Fi Alliance certifications are designed to test basic compatibility, they aren’t comprehensive enough to help vendors avoid all compatibility problems.

Rather than tell you what I think we should do, I would like to hear from you.  What do you think vendors should do?  You’re on the front lines.  You see it every day.   You experience the pain of this problem.  We’re all ears.

Tools for the reluctant administrator

The teacher calls down to the Tech Support department and says, “Bob, I have 3 students who can’t connect…again.  Can you fix it?  I really need to get this lesson completed today, and it requires that the student visit a particular website.”  Bob laughs out loud, says that “he’ll take a look at it”, and an hour later, after asking the teacher for Mac addresses, student names, and having to walk down to the classroom to verify the symptoms, Bob finally fixes the problem….just in time for the bell to ring.  The teacher isn’t exactly happy, and the principal wonders why she isn’t getting her job done.

Enter TeacherView.  Check out my blog on it here:  http://blog.aerohive.com/blog/?p=326

Basically, TeacherView is an application that runs on the Wi-Fi infrastructure that allows a non-technical network operator, like a Teacher, to get their job done without having to understand the nuances of Wi-Fi infrastructure.  It shows each student’s connectivity status and can help the teacher maintain control of each student’s Wi-Fi and website connectivity.  It’s like giving the teacher a little IT buddy.

Are there other such tools for WLANs in K-12 that you can think of that would help solve operational problems like this?  If so, please throw them out there, and we’ll certainly take a look!  It doesn’t have to be an application.  It can be anything.  Again, we’re all ears.

Ease of Management

Sam:  “Hey Bob, can you tell me how to configure an SSID with just guest Internet access and 512 Kbps of bi-directional bandwidth?”

Bob:  “Uh, no.  I haven’t been through the class.”

Sam:  “Dude, why did we buy this stuff if it’s this hard to use?”

Bob:  “I like orange.  ….no wait, the dog ate my homework…yeah, that’s it.”

You may think this is way off-base…but it isn’t. 

The problem comes in when trying to build a GUI for the mid-market and for the large enterprise.  Large enterprise needs a large feature set to tackle a large variety of issues.  Mid-market typically needs a modest feature set.  K-12 WLANs often live right between the two, though they can skew to either side with the size of the school system.  There are a variety of ways usability can be addressed, such as:

* Having 2 GUI interfaces, one for each market
* Hide complex features until they are needed
* Expect admins to just learn the enterprise GUI and feature set

Which do you think Wi-Fi infrastructure manufacturers should do as a general rule?  Is there a 4th option?  Do you hate your GUI?  I’d love to hear some feedback on usability, GUI, and even deployability.  Whatever would make your life easier.

WLANs in K-12 can be a tricky beast, and the more the manufacturer knows about the problems you face, the better we can help you address your issues.  We’re ready.  Fire away!

WLANs in K-12 August 23, 2010

Posted by Devin Akin in : Uncategorized , add a comment

There’s alot to say about WLANs in K-12 – perhaps more than this blog can summarize, BUT… a requirement for brevity has never slowed me down before, so here goes…

Blogs get boring without pictures, so I’m including one just to make the blog look better.  Once you look at it, ask yourself if you feel better about this blog just because there was a picture.

This blog is going to make some statements and pose some questions about three topics that are related to WLANs in K-12.  We’d love to hear some informed and first-hand answers from the audience (especially those who operate or install WLANs in K-12) on answers to the questions, opinions, problems, concerns, and more.  Think of this blog as somewhat of a poll mixed with a discussion.

TOPIC #1

Let’s start by discussing the good folks who operate WLANs in K-12.  Since K-12 organizations run the gamut in size and wealth, the training and experience of the network managers/administrators vary widely as well.  Some rely heavily on their providers (whether it’s the manufacturer or the Value Added Reseller (VAR)) to recommend the right solution and then to design, install, and test it.  At the other end of the spectrum, some administrators in K-12 have years of experience in IT and have taking a liking to Wi-Fi over the last several years, which has yielded them some deep and useful experience.

Question:

With that broad of a range of knowledge and experience, should Wi-Fi infrastructure manufacturers be designing their platforms for the least common denominator, for the most sophisticated user, somewhere between the two, or a full combination of both?

Some aspects to keep in mind while answering this question are:

* Graphical User Interface (GUI)
* Architecture & design simplicity
* Deployment flexibility & simplicity
* Troubleshooting simplicity

TOPIC #2

Let’s discuss the kind of user density that WLANs in K-12 have to cope with.  The rule-of-thumb is one AP for every two classrooms, though there are occasions when the customer might desire one AP per classroom for reasons like higher performance and longevity of the Wi-Fi installation.  There are usually around 30 students in a classroom – sometimes a few more or a few less, but generally-speaking, 30 is a good number.  That means that APs need to support, on average, 60 connections.  Those connections could be all data, all video, or perhaps a combination of the two.  Additionally, those same APs have to handle staff (teachers, administrators, etc.) and guest connections, which could be voice, video, and/or data.  The worst-case scenario may be as high as 100 connections per AP, and handling the “triple play” for 100 simultaneous users on an AP isn’t for the faint of heart.  There are many parts and pieces to handling that kind of client density with mixed PHYs (802.11a/b/g/n): Airtime fairness (uplink and downlink), uplink/downlink flow balancing, bandsteering, load balancing, minimizing roaming, thinning out unnecessary control frames, affecting granular QoS per-application/per-station, and oodles more.

Many Wi-Fi infrastructures fail miserably under those conditions, even though their spec sheets say otherwise.

Questions:

How much testing is actually done to prove that these features (if the vendor claims to have them) work before a purchase is made?  How much does that depend on the experience & training of the network administrator or their trusted MFR or VAR?

Some aspects to keep in mind while answering these questions are:

* Many network administrators are over-worked because the school is under-staffed
* Time is money, and spending alot of time on testing might sometimes seem wasteful
* Many network administrators don’t have the know-how, software, or hardware to test complex features

TOPIC #3

The last topic is about integration with backend systems (Ethernet switches, authentication systems, remote access, etc.).  This is a monstrous topic rolled in a tiny summary.  There are two sides to this fence.  First, many of these technologies are mature and well-known, though their implementations can sometimes be overwhelming.  Second, for large school systems, backend systems can still be very complex and extremely diverse with so many competitors and everyone doing things slightly different.  I have definitely seen some K-12 administrators who make the impossible look simple, but I’ve also seen some who couldn’t administer an unmanaged, SOHO Ethernet switch (kind of like that guy who was trying to change modes on our ISC).  802.1X/EAP with RADIUS and Directory Services is the most common stumbling block we see as K-12 (in general) moves toward using enterprise-class Wi-Fi infrastructure instead of SOHO equipment, but there are certainly others.

Question:

What are some technical advancements that you’d like to see that would ease administrators’ pain with integrating with backend systems?

Some aspects to keep in mind while answering these questions are:

* Other than connectivity into the Ethernet and 802.1X/EAP authentication, what are other pain points?
* Many new advancements are being made on the RF and 802.11 protocol fronts that make applications work better.
* Infrastructure-aware applications that address non-technical operators, rather than just administrators, are now available.
* There are various architectures available now (In-the-LAN controllers, cloud-based controllers, & controller-less) to choose from, and each integrates differently)

Again, this is just a discussion/poll to get some valuable feedback from the audience of this blog.  This feedback will help us understand what problems you’re experiencing, what ideas you have, and how to build more applicable products.

Thanks for your participation!

There’s A Role For That August 19, 2010

Posted by Devin Akin in : Uncategorized , add a comment

APs have so many modes these days that it’s easy to forget that a few of them even exist.  I remember when Cisco’s 1200 series running IOS first introduced a bunch of operating roles.  I went through them trying to figure out how the AP would behave when using that role.  It was kinda cool actually.  Now it’s the wild west.  APs can connect to anything, be anywhere, and perform so many operations that it’s almost shocking.  What about those roles now?

You want to connect wireless clients on both 2.4 and 5 GHz simultaneously?

Piece of cake.  There’s a role for that.

You want to connect a remote AP to the HQ network via VPN while providing wireless access and split tunneling?

There’s a role for that.

You want to connect some wired devices to the wireless network via mesh backhaul while still serving wireless clients off of the same AP?

Yes, there’s even a role for that.

There’s a role for almost everything now. If you can dream it up, at least one AP vendor will make it for you.  Why else would vendors put VPN servers and clients in APs?   What bugs me is when a role is made into a mode, and the mode limits functionality.  What I mean is that many vendors will give you a selection of operating MODES, and when the AP is put into one of those modes, many of the features of the other modes are now missing.  You read things like, “In Mode-X, you get blah, blah, and blah features but you don’t get blah, blah, and blah features.”  Sometimes a vendor might have 5-6 operating modes, and each will have some things and will be missing some things.  Then, over the course of many revs of code, they add features from one mode to another mode…all while creating new modes that have very little.  Basically these modes pigeon hole the user, forcing them to make a choice on what they must give up to get what they have to have.

Shouldn’t you be able to define a role for the AP and not lose any functionality?  Basically what I’m saying is that I want all of my features, all of the time.  I paid for those features, and I want to use them whenever I feel like it.

I’ll give you a couple of real-world examples of feature loss from our competitors’ playbooks:

*  You can have distributed forwarding, but if you try to do it with more than 32 APs, you lose your stateful firewall filtering.

*  You can have remote AP functionality, but not with fast/secure roaming between APs.

So, I’m all for the AP playing lots of roles, as that provides deployment flexibility.  I’m not for locking those roles into feature-limited and functionality-constrained operational modes.  That’s sucky.

Will Someone Please Make An App For That? August 16, 2010

Posted by Devin Akin in : Uncategorized , 2comments

My saga of moving to iEverything continues…

Now that the acute pain has subsided from the fruit-basket-turnover that was switching from a Blackberry to an iPhone4, I’ve begun the long march toward switching from a PC to a MacBook Pro (MBP).  My kids are now on iPhones, I’m begging my wife to switch to an iPhone (she’s as much of a Blackberry hound as I’ve been for about 12 years), I have an iPad, I load iTunes on everything, and I carry around an AirPort Express everywhere.  I just snagged a MBP, and my friend Keith convinced me (and rightly so) to use Me.com for synchronizing calendaring, contacts, iDisk, and the rest.  I’m almost there…close enough to feel it!

With the MBP, I have to learn the OS, find and learn the apps, wait on Microsoft to come out with Office 2011 (because my OCD issue won’t let me use something that’s just about to be obsolete like Office 2008), wait for about a half dozen other vendors to finalize their betas of my favorite apps (e.g. SnagIt, UltraEdit, and a few more), and then all of the rest of the things you have to do to make the switch (like figuring out how to map drives, add/remove apps, do automated backups, getting all of your Windows-only apps (NetStress, The Bat!, NitroPDF, etc.) running on Win7 inside Parallels, and all of that crap).  Even after you “switch”, you really haven’t switched due to some of your beloved apps being Windoze-only.  Thank goodness for Parallels.

I will make the official and full switchover sometime in October.  Microsoft will decide when.  Right now, I’m mid-stroke between my beloved Lenovo and my crazy-cool MBP, and being mildy OCD (such that everything is black/white in my world), I’m struggling emotionally.  The only thing that’s supposed to be mix-n-match is a set of golf clubs, and outside of that, I’m a purist.

Something I’m interested to see is the Wi-Fi compatibility and speed of all of these iEverythings.  I’ve found some OSX apps that give you a little throughput information, but nothing fancy…I mean, one of them is $16, so what do you expect?  I’d love to see some Wi-Fi protocol analyzers made natively for OSX.  Wireshark requires a bunch of fancy hacking to get it running, and even then it’s missing important features.  Fluke/AirMagnet Wi-Fi Analyzer Pro, Tamosoft CommView for Wi-Fi, and Wildpackets OmniPeek don’t have an OSX version.  Oy.  Where’s the love?  Don’t they know that Apple is now bigger than Microsoft and has $46B in the bank?  Somebody even needs to make a protocol analyzer, site survey tool, and spectrum analysis tool for OSX and iPad OS already! 

Over the last few years, iPhone apps have been plenty, but OSX apps have been few.  Surely I’m not the only person on the planet going through this process, so hopefully there will be lots more OSX apps soon.  To be honest, I’m mostly concerned with diagnostic and Wi-Fi networking related apps.  That’s my little world, and there’s just not much to be had in the way of Apple apps.

Anybody want to share their experience, some things they’ve discovered going through this process, or some cool apps that would help me out?

If you really want to help a brother out, tell your favorite app vendors to make an OSX and/or iPad version of whatever cool apps they make.  Jobs and company is here to stay and there’s gold in them there apps.

Distributed Software Download August 12, 2010

Posted by Devin Akin in : Uncategorized , add a comment

A Tale of Two APs August 9, 2010

Posted by Devin Akin in : Uncategorized , add a comment

Once upon a time, in a land far, far away, there lived an Autonomous AP (A-AP).  A-AP was one of many unfriendly, forgetful, uncommunicative folks in his community.  New folks in town (let’s call them clients) would occasionally drop by to visit with each AP in A-AP’s neighborhood, but when they were ready to leave his home, to visit with a neighbor, A-AP couldn’t introduce them.  As you can imagine, this made it very slow for the clients to get to know everyone in the neighborhood.  What’s worse is that A-AP’s neighbors had exactly the same personality challenges (how do you like that politically-correct name?), and if a client ever visited A-AP’s house twice, it would have to re-introduce itself all over again.  This A-AP society, consisting completely of loners, wasn’t exactly the most client-friendly place in the world.  When there was news about a new client to share within the neighborhood, nobody would find out until the client showed up on their doorstep, and when they left, even that A-AP would forget that the client had ever been there.  Steeped in tradition, A-APs just refused to talk to each other, so clients found it molasses-in-winter slow to integrate into the community and eventually gave up in frustration.  It was a dreadful existence.

Meanwhile, back at the ranch…  We join a Coordinated AP (C-AP) family in the middle of their evening meal…

C-AP-1: You see C-AP-2, when Client-7 arrived at my house this morning, I had already been notified by Headquarters (HQ) that it was coming to my house, and that when it arrived, I was supposed to have specific Internet and phone restrictions in place for it already.

C-AP-2: I see what you’re saying C-AP-1, but does HQ always notify us ahead of time about all of these restrictions when a new Client comes to town?

C-AP-1: Yes, and since there could be lots of different User Profiles defined by HQ, someone from HQ will have to call and tell you which profile to use for the new Client.

C-AP-2: I see!  That’s easy enough.  So what about when the Client moves between houses?

C-AP-1: As soon as the Client arrives at your house, drop me and everyone else who lives right around you a quick email letting us know that the client is there, and give us it’s User Profile information.  We’ll all be ready for it if it decides to swing by any of our houses.  We’ll then do the same if it comes by our house.

—————–

I’d like to introduce you to the Coordinated AP (C-AP).  There are actually two kinds of C-APs: controller-based and controller-less.  The control-plane, whether implemented in software and hardware, or just software only, is the set of functions that allow APs to communicate and coordinate among themselves.

The point of this blog isn’t to rail on controllers (though I’m happy to do that pretty much all the time), but rather to clearly explain the difference between autonomous and coordinated APs.  Autonomous APs don’t talk to each other.  Controller-based Coordinated APs share information with the controller, which in turn shares it with other APs.  Controller-less Coordinated APs share information directly with each other.  Hardware controllers and control protocol suites both get the job done, but there are clear advantages in many scenarios to operating the control plane with protocols rather than hardware/software.  That’s a long-winded discussion for another day.

—————–

The Motivation:

I’ve found it very disturbing that Cisco, Aruba, and Meru have all recently told potential customers for whom we were competing, that Aerohive sells autonomous APs.  Nothing could be a bigger fabrication and further from the truth.  They are grasping at anything that would allow them to be more competitive, and in this case, they’re just being dishonest.  You might think, “perhaps they don’t understand your technology well enough to articulate it”, but that’s absolutely not the case.  Each of these vendors understand our technology well enough to know that what they do in hardware and software, we do in inter-AP protocols.  They understand what we do well enough, in fact, to be putting major resources into replicating what we do.  Aerohive’s control plane is far more robust than theirs (no single points of failure, no bottlenecks, lower cost, etc), and therefore they are banking on, and preying on, the ignorance of the customer base in order to be competitive against Aerohive while they attempt to build what we already have.  Then suddenly, they’ll act as though it’s always been their plan and that they are the only company in the world who knows anything about controller-less technology.

This kind of repugnant spin says that they care more about making money than solving customer problems, being honest with and building a relationship with their customers, and maintaining their integrity.  Lest you think I’m making this stuff up, I have the competitive vendor documentation in my possession to prove it.  It’s a seriously sad state of affairs, no?  At Aerohive, we take a different approach (as usual).  Competitors have what they have, and they do what they do.  Our job is to offer the customer something that better solves their problems, regardless of what our competitors have or do.

If you hear “Aerohive” and “Autonomous APs” in the same sentence from a competitor, yea in the same paragraph, push back.  It’s spin.  Here is a step-by-step progression over AP types over the last 10 years:

1)    Autonomous – Standalone APs, managed individually

2)    Autonomous – Standalone APs, managed with a Wireless Network Management System (WNMS)

3)    Controller-based – Dependent APs, coordinated and managed by a single controller

4)    Controller-based – Dependent APs, coordinated by one or more controllers, which are managed by WNMS

5)    Controller-based – Dependent APs, coordinated by a group of controllers, managed by WNMS, that are adapted to help transition the WLAN to high-throughput, mission-critical support

6)    Controller-less – Intelligent APs, managed by WNMS, that use inter-AP protocols to coordinate all control tasks for high throughput, deployment flexibility, and mission-critical support

One vendor in particular, who, for now, will remain nameless, has even said that our APs are 2nd generation, while there controller is 4th generation.  Where in the hell do they come up with this stuff?  I’ll bet this vendor skips 5th and 6th generation and goes straight for 7th generation in their next product line. Oy vey.

The truth of the matter is that most (at least the smart ones) of Aerohive’s competitors are moving from step-5 above to step-6 above as we speak.  It simply has to happen.  There’s just too many compelling reasons why controller-less is the next generation of Wi-Fi to deny it.

search

RSS Feed

• Recent Posts

  • The Wi-Fi Guarantee
  • Wi-Fi Spectrum Analysis? What’s That?
  • Branch Office Wi-Fi
  • The Relevance of 802.11n Transmit Beamforming (TxBF)
  • WLANs in K-12 – Part Deux

• Archive of the Hive Mind

  Select Month September 2010 August 2010 July 2010 June 2010 May 2010 April 2010 March 2010 February 2010 January 2010 December 2009

• Aerohive Tweets

  • New Jersey School District Expands its Wireless Network - http://bit.ly/cBUi2D 2 weeks ago
  • A Tale of Two APs...Once upon a time in a land far, far away, there lived an Autonomous AP (A-AP)...http://blog.aerohive.com/blog/?p=415 4 weeks ago
  • TeacherView: Aerohive's innovative new application to make it easy to manage Wi-Fi in the classroom http://www2.aerohive.com/teacherview 1 month ago
  • Aerohive's free Wi-Fi planner - now more intuitive UI, AP auto placement & improved reporting. Register at http://www.aerohive.com/planner 2 months ago
  • Need convincing that controller-less is the future of Wi-Fi architecture? Read the latest blog post from Devin Akin - http://bit.ly/ajaLNu 3 months ago

© 2010 Aerohive Networks, Inc.