The Citrix NetScaler Product Group had a very interesting presentation at Network Field Day 11 (NFD11). They started with possibly one of the most provocative statements of any vendor: “Networking is better done in software.”
Their perspective is that network functions should be dynamically instantiated, provisioned on demand, and centrally controlled. To achieve these characteristics, network functions must be software defined. They are working on converged management of Application Delivery Controllers, VPN gateways, SD-WAN, and WAN optimization, delivered by their NetScaler appliance, which is available as a hardware appliance, virtual appliance, and a multi-tenant appliance. There are also tie-ins with other Citrix products, but were not discussed.
The NetScaler example
The Citrix NetScaler is a good example of the migration from custom hardware (i.e. custom ASICs) to software. There is a virtual appliance implementation and a multi-tenant appliance. The hardware-based platforms use off-the-shelf hardware, including NICs and SSL accelerators, coupled with their optimized and customized OS. They introduced a couple of new terms (to me at least). The first term is “triscale,” comprised of three scaling components.
- Scale Up – scaling to higher bandwidths as needed.
- Scale In – reducing hardware appliance sprawl, by scaling the hardware to handle up to 115:1 ratios of software to hardware. (This was the second term I hadn’t heard before.)
- Scale Out – providing up to 32X parallel implementations, supporting up to 5.1Tbps, including RAID-like protection.
There are no hardware dependencies, so the same software runs on their breadth of platforms. The only ASICs in the hardware platforms are for SSL acceleration. A side benefit of a software implementation is that it is easily deployed into cloud environments. The flexibility of the software-based system is becoming a powerful feature, and customers are becoming much more accepting of software systems. Of course, there is the benefit of rapid feature evolution because the software isn’t tied to custom hardware.
The NetScaler OS
How was the software Operating System for NetScaler done? They started with a stock Berkeley Software Distribution (BSD) Unix OS, but then determined that it wasn’t fast enough. So they built their own network stack.
My personal perspective is that there is some risk in this approach because it implies a whole new set of bugs and vulnerabilities. It also provides the opportunity for greater benefits. For example, they switched from interrupt driven network I/O to polling to allow more buffering of incoming data. The result is a real-time system. They showed performance graphs of 1.2M connections with latency under 1.3ms. As testimony to scaling up and out, the system can handle over 50M concurrent connections.
The system is highly instrumented, collecting metrics on many internal operations. System console access gets enough CPU time when the box is heavily loaded so that the administrator can’t be locked out by a DoS attack. Being able to control the system while under heavy load is very important (ask anyone with significant time on other gear about the necessity of providing good console access during heavy loads, such as with “debug all”). An additional software enhancement is that the filtering and packet processing policies are compiled into code, resulting in fast execution.
Putting it all together
What about the Citrix NetScaler claim that networking is better done in software? The industry is certainly moving in that direction. NetScaler has been doing software-based networking for many years. An added benefit is that raw x86 CPU performance has reached the point where it is “good enough” for the majority of cases.
Sure, there are still places where custom ASIC hardware can’t easily be replaced. But we’re finding that optimized software, distributed across multiple CPU cores, is becoming competitive.
I see two major advantages to the NetScaler products. First, they are automatically “future-proofed” due to their software-based implementation. No forklift upgrade is needed. VM implementations can easily be migrated to new, faster hardware as it becomes available. In addition, distributing the functionality across the infrastructure, placing it where it is needed, simplifies configurations and allows smaller, less powerful implementations to provide better performance.
Second, software’s rapid development cycles provides new functionality more easily than with systems that require hardware upgrades. I’m convinced that we’re likely to see more migration to software in the future.
Disclosure
I didn’t receive any compensation from Citrix to write this article. However, they indirectly paid for my travel to NFD11, lodging, and meals. Vendors typically give the delegates various gifts, mostly of small value. We occasionally get a piece of networking hardware that might be of significant value.