In his 2015 outlook for network functions virtualization (NFV), SDxCentral co-founder Roy Chua points out that performance is going to be an unpleasant surprise for some users.

Martin Taylor, CTO of Metaswitch, agrees. What's needed, he thinks, is a dialogue between the vendors creating virtual network functions (VNFs) and the vendors developing NFV infrastructure.

The issue is that performance can degrade significantly when a software application moves to the cloud. “Open vSwitch performance is, at the moment, very poor, in our experience,” Taylor says. “It can be as much as 50 times worse-performing that bare metal.”

The few NFV deployments that are in production have tended to be in VMware-based environments, running without much problem, Taylor says. The problems arise in OpenStack and Open vSwitch environments. Carriers dabbling there are likely to find some unpleasant surprises when it comes to NFV performance, he thinks.

Metaswitch has a stake in this, of course. Perimeta, the company's virtual session border controller (SBC), is the kind of application that can run into this performance barrier. It handles high volumes of small packets — so rather than being compute-intensive, it's network-intensive. That's a problem in virtual environments, as Taylor explains in a blog posting published Tuesday.

Part of the reason is a lack of control. “When we're running the software on bare metal, when we can control the environment, we can run it extremely well,” Taylor tells SDxCentral.

NFV, however, strips away that control. Metaswitch is at the mercy of whatever hardware its products are running on. More importantly, NFV introduces infrastructure — elements of networking and storage, in particular — that a VNF has to cooperate with.

Combined, those factors hammer performance, Taylor says.

This hasn't gone unnoticed. In November, the OPNFV alliance kicked off a proposal to characterize VNF performance, especially in light of the fact that Open vSwitch was not designed for telco needs. Intel, which is keenly aware of the performance limitations of Open vSwitch, helped get the effort rolling.

The Open vSwitch team has also been working to improve performance, as was explained at a recent conference in Palo Alto, Calif. Moreover, Intel has given up on its fork of Open vSwitch, which could eventually mean good things when it comes to OVS performance on x86 chips.

But NFV poses a problem that might be beyond the OVS team's scope. Namely: to get the most out of a virtual switch, you need a lot of low-level configuration — and that stuff gets abstracted away by OpenStack, Taylor says. The lack of fine-tuning limits the amount of performance you can wring from the switch.

So far, most of this discussion has been smoothed over by a simple “API” line drawn on an NFV diagram. That's not enough, Taylor says.

“We have to remember that there are some codependencies here. Depending what software that vSwitch comprises, you may need some driver software in the virtual machine that's housing that virtual network function,” Taylor says.

Metaswitch has gotten good performance out of Perimeta by using single root I/O virtualization (SR-IOV), an extension to the PCI Express standard. It bypasses the hypervisor to run the virtual machine on bare metal. But this method has its limitations, such as the inability to migrate a virtual machine while it's running. SR-IOV “works, but it's clunky,” Taylor says. “You're bypassing the software that makes the cloud cloudy.”

Another option Metaswitch has tried is the acceleration software provided by 6WIND. The result was “outstanding” performance, “not all the way back to bare-metal performance, but close enough to it,” Taylor says. The tradeoff is that the 6WIND software doesn't quite match the performance of the SR-IOV option, and it eats up a lot of processing power, Taylor writes in his blog entry.

“The good news is that we have verified we can get to a level of performance with Perimeta that is more than a match for session border controllers on proprietary hardware,” he says.

Taylor thinks this issue has been underappreciated because most telcos are at Square One with OpenStack, nailing the basics of getting the environment running. That means there's some time to get that VNF/NFV dialogue going, to find out what's needed from the network stack.

“We're hoping that other VNF vendors will share their knowhow,” Taylor says.