Big Switch today announced the release of its SDN products, and while there’s no question the company has some good stuff, I’m still not convinced they have ENOUGH stuff. The fundamental question of SDN isn’t how control of devices is exercised, it’s how a system of devices can be organized into the coordinated behavior we call a “service”. That’s a question that’s gotten a lot more complicated recently as other initiatives aimed at offloading functionality from the network developed.
I’ve blogged a lot over the past year about SDN, and recently I’ve blogged a lot about Network Function Virtualization (NFV). One of the points I’ve been making on both is that while everyone seems to profess love for the notions, so far all we have is furtive blowing of kisses and no concrete proposals of marriage. We need not only concrete proposals to implement each, we need something to implement BOTH. There can’t be two independent network revolutions.
Amid all the network romanticism I’ve finally found an example of substantive progress with a French company, 6WIND. These guys are the first to present an explicit NFV position and obviously the first to link a solution to both SDN and NFV. In fact, I think they may have a more interesting contribution to SDN than players who are normally associated with the concept.
Both SDN and NFV propose to do more network features in the cloud, and while there’s a lot of intuitive benefit in doing that there’s also a potential problem. Servers are not real-time devices, particularly when you add in the operating systems that were designed to run business applications and not real-time processes. How, then, can we expect them to perform when they have to take on real-time burdens? Probably not well.
Interestingly, if we look at a modern computer device, we see an increasingly sophisticated multi-core processor with increased capabilities in handling I/O of all types, including communications. As we start to give servers a real role in communication either by implementing virtual network segmentation on them or (in the case of NFV) actually hosting network features on them, we run into real-time issues created not by the hardware but by the real-time inefficiencies of the software. 6WIND’s goal is to solve the real-time network problem for modern multi-core servers and appliances.
The idea behind 6WINDGate, as the product is known, is to place a set of “fast-path” packet tools between the chip-level communications support and the hypervisor or operating system. These tools integrate with the OSs to accelerate the handling of communications protocols by the higher layers, significantly improving packet-handling performance and (perhaps most important) making packet-handling deterministic—independent of the load placed on the hardware by the higher-layer elements. You need determinism in the cloud or the use of resources by one virtual machine will contaminate the performance of another in an unpredictable way, destroying the fundamental requirements of multi-tenancy, which is independence of application elements from each other.
This capability is useful in three ways; first, you can use it to improve how servers manage things like virtual networks, and second you can use it to host network-related applications like firewall, NAT, DHCP, and even IMS components. Second, you could use it to create a network appliance, as some appliance vendors already do using 6WIND software. The best thing is that when you visualize network functionality as a hardware overlay usable either by servers or embedded-control-based appliances, you can decide where to host things—network or server—based on all the possible technical and business considerations. If operators really want to drive NFV to the ultimate hosting of all non-packet-forwarding functionality on servers, that’s fine. If they want some tightly coupled things hosted on appliances optimized and located for maximum performance, that’s fine too. In theory, a “service cloud” could be created from the software with network devices and servers both playing their optimized role, and with a common orchestration process putting it all together. That’s compatible with the vision that the NFV operators show in their white paper, but it’s also at the minimum a better way of migrating from current discrete-device networks to a more server-hosted model.
I think this is the start of something big, a trend to optimize servers/devices for the cloud in general and the “service cloud” of network operators in particular. 6WIND is showing that we can host network features, even those just above forwarding, right in the cloud, and that satisfies basic NFV goals. But they also show that we can create servers/devices that can provide under-the-OS-and-hypervisor services that are exceptionally efficient (dare we call these “underware”?) These could serve as a model for how a basic cloud would evolve to become a service cloud because in theory any kind of service that needs fast-path implementation could be hosted this way.
You can even consider whether generalized cloud trends like the Nicira-style virtual networking might create a reason to think of a cloud server as being very different from a VM server, and some fast-path cross-OS functionality like 6WINDs being the difference. Intuitively I think we all believe that the cloud, because it’s different, will drive differences in server technology. This may be how that happens.
For VMware, who bought Nicira, and for Brocade who bought Vyatta, 6WIND poses some compelling questions. Can we expect servers, which have for decades been shedding communications functionality because of performance issues, suddenly embrace that functionality with no changes? Seems unlikely, and if it is then they need to be thinking about these same fast-path issues, and quickly.