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.
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!
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.