Month: October 2018

Meraki Is Now In The “F’ACK” Game

I live in Colorado, and for the past couple of years, Fracking has been a HUGE issue, both physically and politically.  I don’t really understand it, but that’s OK, I’m not going to talk about that in this post.  It’s a rabbit hole I don’t want to go to down.  I bring this up because during Mobility Field Day 3, #MFD3, Meraki introduced “FAST-ACK” and the first thing I thought of, both in name and potential impact, was fracking.

For those of you that don’t know what fracking is or didn’t click on the link earlier, fracking is the process of injecting high pressure liquid into rock deep underground to release trapped natural gas that are in tiny pockets that makes traditional drilling financially unfeasible.  It’s easy to reason both the pros and cons to this (pro = access to natural resources, con = “you are doing what?!?!”) but nonetheless, it’s a thing and it is happening.  As I sat in the Meraki presentation during #MFD3 this immediately sprang to mind.

Now that I have covered natural gas extraction using fracking, let me get to the technology of “FAST-ACK” which was quickly reducing to any number of shorter versions, but other than my witty title we are going to stick with FAST-ACK.  FAST-ACK is a patented technology that Meraki introduced at #MFD3 as a way to speed up your wireless network.  To really understand it, you need to be aware that in a traditional Ethernet connection, there is an ACK packet to a TCP packet, and that has always been there.  In wireless, there is an ACK to most frames as wireless professionals are well aware of, but there will still be a TCP ACK that happens; not to a received frame but from the client to the remote end to acknowledge that it received the TCP payload.  In wireless, it’s not flagged as an ACK, it’s a normal frame.  You would need to dig into the payload to figure out that it’s a TCP ACK.Screen Shot 2018-10-06 at 7.58.58 AM

Meraki’s approach to this is quite simple from a high level.  In order to speed up the delivery of content from a remote device (like a Netflix server), the AP will proxy the TCP ACK from wireless client to the remote end based on the fact that it received a Layer 2 ACK from the wireless client.  While the wireless client is processing the received payload to verify that it can send a TCP ACK, the remote end has already received that proxied TCP ACK and is queuing up the next batch of packets to send to the client.  This means that by the time the wireless client is ready to receive the next batch of traffic, that traffic is already cached in the AP, waiting to be sent.  Over time, this saves time and will get the client the movie they are wanting to download FASTER than the traditional manner.  According to Meraki, TCP FAST-ACK offers up to 38% improvement in throughput!  If you know me, I am a huge fan of getting people their content faster, so now you have my attention!Screen Shot 2018-10-06 at 8.09.59 AM

Now, if you are anything like the group that was in the room when all this was explained, there are some immediate questions that spring to mind, as well as additional questions that arise the more you think about it, just like with fracking in the oil and gas business.  One of the first questions, and this was covered during the presentation, was what about roaming?  Meraki has thought about that and the AP that processes the original TCP frames will cache the next batch until the client is ready to receive them.  If the client roams, the AP will transfer that TCP data to the next AP so that the new AP is ready to send it the moment the client is ready.  So that is covered, no problem.  My lingering question surrounding that is what does that do to the price of an AP when it is discovered that the AP will need additional storage to cache more and more data in certain venues, like LPV?  I could see a highly mobile environment with clients downloading a lot AND moving around a lot, there might be problems.  Time will tell, and I’m afraid that only time will tell about that.  Maybe this means that in certain environments, FAST-ACK shouldn’t be turned on.  Does that limit the market for Meraki?  Again, only time will tell.

After the presentation, as the delegates were packing up and talking, the majority of the conversation was focused on FAST-ACK and potential ramifications of this new technology.  Just like with any wireless centric conversation, there were multiple opinions and just like normal, none of them were wrong, per se, they were just different.  What happens if the client doesn’t send the TCP ACK to the remote end but asks for that payload again?  Does the AP send the next batch and then waits for the repeat batch?  All this TCP payload is numbered, so it will be received out of order, but that’s one of the reasons that TCP number is there to begin with.  If that happens, what is the trickle down effect of that?  What else suffers?  Is that throughput performance improvement worth the risk?  Again, only time will tell, because I don’t think we know what that risk is in the wild.  Too many times I have been burned with technology that works great in a lab setting or in an environment that was hand picked for testing, only to find out that in the wild, it’s not really worth the time and investment.  I’m not saying that is what is going to happen with FAST-ACK, I’m just being cautiously optimistic for the time being.

To watch the full Meraki presentation, go here and see for yourself.  To really understand the impression that FAST-ACK made on me, notice that the FAST-ACK portion doesn’t start until the 15 minute mark.  Before that there was a conversation about external antennas for ALL the radios in an AP – client serving, scanning and BLE.  If you know me at all you know that I love antennas so the fact that my first post about the Meraki presentation wasn’t about the fact that they are dealing with one of my pet peeves but instead introducing a mechanism to speed up the TCP flow should tell you something.

I still think that only time will tell on the real impact of Meraki’s FAST-ACK so if you like to be on the bleeding edge of technology, jump in and tell me how the water really is after you have done a couple laps, I am really interested in how this plays out.

In the mean time, I think I need to re-think the name of my blog.  The fact that I typed an entire blog post centered around TCP ACK’s might mean that maybe I DO know squat about networking.



Why the Wi-Fi Alliance Numbering Scheme “Matters”

So yesterday, the 3rd of October, 2018, the Wi-Fi Alliance announced a new numbering scheme to define their certifications instead of the traditional 802.11a/b/g/n/ac/ax terminology everyone as used for the past 20 years.  Had you given me a heads up I could have predicted how the Wi-Fi professionals I associate with would respond, and I wasn’t disappointed.  In grand fashion, the majority of them lambasted the Wi-Fi Alliance for coming up with such a needless and pointless “thing” and questioned why they were wasting their time on such a thing when they could be doing things Wi-Fi professionals have been begging for for years.  If you haven’t seen the actual release, you can read about it here.

As the day wore on, there were some voices in the crowd that started to question the outrage and jokes and general negative comments that came out.  Questions like “why do you care, this isn’t intended for you” and “why can’t you just deal with this?”  After getting a not as restful sleep as I would have hoped for, I want to tackle this question today with an argument I have been using for years.

What you say actually matters!

Here is my argument, and I use it on people who understand networking much more than wireless, because that’s who I deal with on a day to day basis.  When someone plugs a network cable into a network switch and a device, generally it will auto-negotiate the connection speed.  The speed that is negotiates at is set at a pretty small number.  The traditional speed chart you can see on a switch looks something similar to this:


On my newer “M-Gig” switches, it actually looks like this:


Now, counting up the different numbers we see, we can safely say that these devices will negotiate a connection speed of one of six possibilities.  Somewhere between 10BaseTX and 10GBaseTX, but that rate has only SIX possible answers.  Guess what, there is an IEEE standard for each of those, but only the geeky among the wireless community knows what those are (802.3ab for 1000BaseTX if you care; I had to Google it.)  I bet if I asked some of the route / switch CCIE’s in my office they could tell you what each standard was (maybe, I didn’t ask) because that is their business.

Since no one in the general public buys network switches, no one cares what 802.3ab is.  There isn’t some alliance out there trying to promote some “certification” using 802.whatever to sell stuff.

Wireless is different.

I mean it’s somewhat different, but different enough that it really, REALLY matters.  Every year there are launch parties for new consumer devices that tout the latest and greatest device and how it is so much better than it’s competitors.  Up until yesterday, the Wi-Fi part of those new devices were relegated to using 802.11acW2 or 802.11ax, or “802.11an” (not a real thing, it supposed to show 802.11n that is 5 GHz capable.  See the confusion?)  Now, thanks to the Wi-Fi Alliance, all we have to say is “Wi-Fi 5″ or Wi-Fi 6” to say what the capabilities are.  From my Mom’s point of view, that’s easy for her to understand.  “6 is better than 5, so I go with 6.”

One slight problem with that.  Remember the 802.3ab comment from 2 paragraphs ago?  How wired switching only negotiated at 6 different speeds (more like 3 but I want to give the wired guys as good a shot as possible)?  Ever really looked at the wireless connection speed negotiation table?  If you haven’t, it looks like this: Notebook-Resources-001This is from the Wireless LAN Professionals Custom Field Notebook, and it is so cool that if I really like you, this is what I will be giving you for Christmas this year.  If you don’t want to wait to see if I really like you, go buy one here.  I use mine multiple times a week, much more than I originally thought.

Anyways, to save you the trouble of counting the different negotiated speeds, the table lists 232 possible connections speeds, based on 11 different criteria.  232 for wireless, 6 for wired.  If you are a marketing professional, this is the type of table that serves exactly ZERO purpose for you.  If you are a wireless professional, you use this table almost every day.

Different responsibilities, different use cases, different requirements.

Marketing people can’t sell a chart with 232 possibilities based on 11 different criteria.  They needed something much more simple, and the Wi-Fi Alliance delivered.  Yes, it wasn’t for professionals, but this is why we care, and more importantly, why it matters.

As Wi-Fi professionals we have to talk to the people that this is intended for.  We have to answer questions when the executive gets back from their latest conference and asks what will it take to get to “Wi-Fi 6” or better yet, “Wi-Fi 7” because they need to out perform their associates on LinkedIn.  Maybe you work for a VAR and your angst comes from having to answer an RFP that lists these in the criteria, but nothing about security.

Bottom line – professionals like to keep things very detailed and technical because that’s how it works.  It’s not a secret, there are books and classes out there for those inclined to learn all the details.  Just like any other profession, you can learn what all of it means if you put in the time and the effort.

We don’t ask building architects or structural engineers to dumb down their profession for the average person on the street; we trust them to do their job correctly.  If not, there are major ramifications.  Of course architects and structural engineers don’t need to market what they do to the average person on the street, but Wi-Fi professionals have to, albeit in a round about sort of way.

Are the new naming conventions going to go away?  Of course not, they are already out there.  Will someone use them?  Of course they will, it shows how smart they are.  Will Wi-Fi professionals complain about it?  Of course we will, we complain about everything.  Bottom line – let us complain because we know at the end of the day, it’s just one more thing we will get to explain to people about the magic that we do.