Over the past few months we have been putting our service through a series of tests run by us internally, by customers, and by third parties, and the results have been incredible! We believe it’s by far the fastest, easiest, and most reliable way to connect your distributed workforce -- employees working from home, mobile users, or branch offices -- with cloud services and on-premise resources. 

‍
We had Ananda tested against leading legacy VPN products, as well as newer “SASE” (Secure Access Service Edge) solutions. In this blog post, we will share some of our results and talk about how we are able to get such results. ‍

‍

The results

‍In case you don’t wish to read through this entire blog post, here’s the bottom line. While performance can vary from location to location, between different carriers, and even at different times of the day, we have seen speed improvements of anywhere from 100% to 2,500% (and in some extreme cases we have seen as much as 8,000%)! We are also seeing better link quality in terms of latency, jitter, and other key parameters when compared to legacy VPN solutions, SASE services, and many times even when compared to the raw Internet.

Below is a snippet of our testing. Unfortunately, we won’t be disclosing specific vendors since this has got companies into hot water recently. We encourage anyone who is curious to try to replicate our results with the few top vendors in each space (just google “top SASE providers” or “enterprise vpn solutions”.)‍

‍

Ananda vs. well-known VPN brand X

A few words about testing methodology: The test below averages out communication speeds across seven different geographical regions and providers (covering US East coast and West coast, Europe and Asia), showing the speed boost in comparison with one of the most commonly deployed VPN solutions. We used iPerf3 and wget for benchmarking. Since the Ananda network learns and optimizes the traffic over time, we let the benchmark run for a while to reach peak results.

‍

As you can see, Ananda is almost always significantly faster (over 3x on average), and can get as much as 10x and above for certain providers and geographies. In fact, in real-life scenarios Ananda would generally be faster than the above simulated scenarios. Stay tuned to more testing information.

Ananda vs. well-known SASE brand X‍

As a second test, we tested Ananda against some of the leading SASE solutions out there. Even though SASE is considered to be a more modern solution than VPN, we still saw throughput increase of 2x-3x on average for most geographies we had tested. So SASE solutions did a little better than VPNs, but were still slower. In some scenarios, most existing SASE solutions are unable to provide connectivity or can do so very inefficiently (for example, when testing communications between different cloud providers). In such cases Ananda was able to show 10x the speed or more compared to these SASE solutions.

Testing network reliability‍

Reliability is as important as speed, if not more for many use cases. Take for example many companies connecting manufacturing plants, ICS/SCADA equipment overseas with data centers and cloud services in the US or Europe. These devices are mission-critical and need the connection to be as reliable as possible, and a lot of time and expense is spent on making that happen.

Our tests showed that in addition to speed, Ananda improves on other network quality attributes and shows much more consistency over time as compared to a VPN connection or even when compared to the regular Internet when it comes to packet loss, disconnects, jitter, latency and other key parameters. Below is an example of a more reliable connection and lower latency achieved with Ananda.  

‍

How did we accomplish this? 

Below are some of the elements that go into Ananda to make it faster and more resilient. Some other elements we consider as trade secrets, so this is a partial list. 

‍

#1 A distributed vs centralized network

Ananda is not yet another centralized network, such as a VPN or a SASE implementation, whereby your traffic goes through a gateway (physical or virtual) or a set of gateways. In the case of a VPN, traffic typically goes to a gateway in the data center, and then it goes on to the destination host inside the data center (or worse yet, on to the cloud or SaaS application). In the case of SASE solutions, the SASE vendor is typically running such gateways in dozens of locations, so each packet flows to one of the nearest locations, or POPs, and then on to its final destination.

Unlike these centralized implementations, with Ananda, any two nodes can communicate directly without an intermediary gateway or proxy between them. This means in many cases the packets can take the shortest, fastest route between point A and point B, rather than taking a “detour” from point A to a gateway or POP, and then to point B. This is especially important when talking about nodes that are relatively close by, such as in the same city or state, not to mention nodes that are in the same physical data center or public cloud! Our tests we shared don’t show the full impact of such centralized architectures on performance, such as where traffic is backhauled through an enterprise VPN gateway and then goes to a cloud instance. In real life scenarios, Ananda could provide another order of magnitude boost in performance. 

‍

Even if your network is blazing fast, if it stops working, speed doesn’t really matter. From a reliability perspective, a software-based, distributed architecture removes the reliance on the vendor to provide the actual network’s “data plane” that can be a single point of failure. If your SD-WAN device (either virtual or physical) fails, you’re done. If the SASE POP is down, you’ll either get disconnected or move to a less ideal POP. The Ananda architecture just doesn’t have all these potential points of failure, as it doesn’t rely on any hardware or POPs to capture network traffic.

‍

#2 Optimizing protocols

Many of the protocols we use on a daily basis were never designed for use over the WAN, as they are too “chatty” or unreliable. VPNs introduce tunneling protocols that slow down your traffic even further.

Without going into all the secret sauce involved, Ananda can tweak the protocols to make them more “friendly” to the WAN and essentially create a LAN over the WAN that allows these protocols over it. Our tunneling protocol used is also more modern and doesn’t introduce the same issues as the old IPSEC and similar VPN tunneling protocols.

#3 Optimizing routing 

When applicable, Ananda can accelerate traffic further by introducing Nitro™ relays as waypoints to force superior routing of the communications. This is especially useful over longer distances. How does that work?

In addition to facilitating direct connections among its network nodes, Ananda is able to dynamically spin up Nitro™ relays in hundreds of locations across multiple public clouds to be used for additional traffic acceleration. Using machine learning, Ananda may determine that taking a route from a source node, through a Nitro relay (or multiple relays) in a specific location, and on to the destination node provides better link quality.  In which case, Ananda will choose this Nitro-assisted connection option. This method improves on the Internet’s routing both in terms of connection speed and connection reliability. And since Ananda is using multiple cloud providers, even if there’s a localized issue with a certain cloud providers, carrier, or region, it can use another to provide the greatest resiliency. Switching over does not disconnect your connection because it’s seamless to the Ananda overlay network.

‍

#4 Creating a self-optimization network

Nodes on the Ananda private network continuously test for an optimal connection. This connection might be a direct connection, a connection that goes through a Nitro™ relay in one of hundreds of locations, or involve different encapsulation protocols. Depending on nodes’ locations, carriers, peering, network congestion, ISP quality of service, and other parameters such a decision is made. For example, an Ananda node A wishing to connect to a node B will do the following:

·  Receive a list of candidate connection options from the Ananda control plane.

·  Test each option and compare the throughput, packet loss, jitter, and other parameters: a direct connection, a connection via one or more relays, and a connection using different protocols.

·  Choose the best combination and forward packet over the chosen connection.

·  Keep revisiting continuously and switch over as needed. 

In our tests, it was clear how switching to the best connection route and protocol significantly improved performance, and also made the connection much more resistant to underlying issues with the Internet.

One more thing…

One more thing about performance. We are constantly working on improving it, and we have a lot in the works. Expect our releases in the coming months to deliver significant performance boosts going beyond what we had reported on here!

If all you have is a hammer, everything looks like a nail.

This pretty much sums up much of what I’ve seen in recent years in the fields of networking and security.

The first firewall was created over 30 years ago, in the late ‘80s. It was followed by the VPN just a few years later. At the time, it made sense! Since the creators of the Internet gave absolutely no thought to key aspects, such as security when they designed it, something had to be done. So, if you wanted to connect your network to the outside world you put a firewall gateway in place. If you were outside the network, you use a VPN. And voilà!

Flash forward to today. And as I’m sure you’d agree, the network has changed.

Our enterprise, our workforce, are far more distributed than ever before and the perimeter is long gone. Not to mention how every single person is working remotely these days because of COVID-19! Users, devices, resources are everywhere – some still in the old HQ, but there are now also many branch offices, remote employees, third parties, mobile users, public clouds, SaaS applications and more.

But those who created the firewall, followed by the VPN, and later the SD-WAN, and even the most recent emerging “SASE” platforms, still have a hammer and treat everything like a nail. Do you have a problem with network security? Connectivity? Speed? Throw an appliance at it! The appliance may have changed. It may no longer be a physical box, but rather a virtual one. It may no longer reside on your enterprise network and may have moved into the vendor’s datacenter (or “POP”). But it’s still a hammer: IP traffic goes in, the centralized “box” does something to it, and then it goes out the other end. We are forcing the same 30-year old, centralized paradigm on an almost completely distributed enterprise, hoping it’ll work (Spoiler: No, it doesn’t work that well! And our customers agree).

This is yet another reason we at Ananda Networks have set to rebuild the network from the ground up. We are on a mission to make the network blazing fast, fully secured, and a joy to use. Stay tuned!

When it comes to what's been plaguing the Internet, we’ve all been treating the symptoms, not the cause.

Let’s start with a quick history review.

The ‘60s

The Internet’s first prototype appeared in the late ‘60s. On October 29, 1969, ARPAnet delivered its first message between two computers (incidentally, that message read “LOGIN”, but it crashed the network and ended up only delivering the first two characters).

The ‘70s

Fast-forward to the ‘70s. This is when ARPANet adopted TCP/IP that allowed for the first time for multiple networks to communicate.

The ‘80

A couple more significant steps were made in the 80s, namely gateway-to-gateway protocol and BGP (border gateway protocol) made it possible to more robustly connect separate networks together. The latter was famously jotted down on 3 napkins over lunch… (see image above)

.

.

.

2020 

This was pretty much it. Our network’s architecture was conceived almost 60 years ago and evolved until about 30 years ago. And this is largely what we are still using today!

But while the Internet was designed decades ago, how we are using it greatly evolved in the years since. This internet was invented for totally different use cases than the ones we are using it for today. Its requirements were very different as well (such as redundancy in the event of a nuclear war!).

Nobody was thinking about performance. Nobody was even thinking about security.

This is because no one expected we will use the Internet for making Zoom calls, hailing a taxi, doing e-commerce or streaming Netflix. No one expected it to connect a highly distributed workforce. So, we are constantly trying to “force” the internet to do “unnatural” things. Things it was never designed to do. Instead of fixing the network, we have put in place many “patches” to make up for its original design flaws (for example: firewalls, VPNs, SD-WAN, MPLS, NAC, CASB, and many more.) This led us to think, is there a better way? (spoiler: yes, there is!)

This is one of the reasons why we at Ananda Networks have set to rebuild the network from the ground up. We are on a mission to make the network blazing fast, fully secured, and a joy to use. Stay tuned, as we will be revealing what our team has been working on for the past year.

On the off chance you haven't noticed, a generational shift is happening before our eyes, resulting in a truly distributed workforce. It’s no longer just a handful of employees on the road or working from home intermittently. In fact, you, the reader, are highly likely to be reading this blog post from home as we speak. Twitter, Quora, and many others are becoming “remote-first” companies. And while COVID-19 may have accelerated this phenomenon, it is here to stay and will likely be with us after the pandemic is over.

So what’s the difference between this new ‘distributed workforce’ and the good old ‘remote access’ paradigm? A distributed workforce means employees en mass are now working from home, and home may be far away from your company’s old headquarters. The notion of the branch office is disappearing and transforming into its individual employees that may or may not be at a physical branch. In other words, the individual user is now the network edge. What’s more, this new distributed workforce is no longer just using “remote access” tools or VPNs to connect to the datacenter. Rather, the resources employees need to access are distributed as well, and include primarily the company’s public cloud instances and third-party SaaS applications.

This means there are new and tougher requirements around performance, security, and not less important - the experience of the end-user, all happening without giving organizations too much time to prepare. Our old network, our remote access, and our security tools were not designed for this new world. Stay tuned, as we will be revealing what our team has been working on for the past year to enable the distributed workforce.