Is there a packet performance problem lurking behind NFV that could make the deployment of virtual functions in a typical IT-based cloud environment that much more complicated?
Metaswitch Networks thinks so, and the vendor is hoping to draw attention to what it sees as performance problems that could challenge the implementation of NFV, according to the company's CTO Martin Taylor.
By raising the issue and also laying out software and hardware fixes, Metaswitch wants to get telecom service providers talking about it and sharing their thoughts on which approach they prefer.
Taylor first spoke to me of his company's concerns back in November. Now he's brought them to light in his Metaswitch blog, which you can read here.
Specifically, Metaswitch found in its testing that network-intensive functions, such as those associated with user plane functionality -- versus control plane -- suffer performance issues when they are implemented in a typical IT-based cloud environment because that type of infrastructure is limited in its ability to handle heavy network workloads.
Many of its telecom service provider customers aren't aware of those limitations, Taylor says, and may be in for a nasty shock when they try to virtualize some functions on an OpenStack environment, for example.
"When we talk to telcos about what they are doing with OpenStack and the cloud environment for NFV, we find that they are obsessed with orchestration," Taylor told me back in November. "But our experience shows that there are these pretty serious performance issues lurking under the covers. Telcos might get a nasty shock when trying to do some virtualized network functions."
Metaswitch encountered these issues in the process of running its Perimeta session border controller, which handles both control plane and user plane functions. While the SBC runs fine on bare metal, its performance in a virtualized environment suffers because of the inefficiency of the data path between the physical network and the virtual machines. That path is provided by Open vSwitch software, which grew up in the IT environment and can't handle the million packets per second workload of a network SBC, according to Taylor.
The hardware fix essentially bypasses the vSwitch by establishing a data path between the physical network and the VM using Ethernet NIC (network interface card) technology called Single Root Input/Output Virtualization (SR-IOV). This approach is probably the most efficient, but it doesn't support overlay-based network virtualization, which is commonly used in migrating massive telecom networks to virtualization.
The software fix, which does support overlays but is less efficient than the hardware option, uses a commercially accelerated vSwitch to create a software-based data path between a conventional Ethernet NIC and the virtual machines, Taylor explains. The shared memory can be used to reduce or eliminate packet copying, thus make processing more efficient.
"We need the telcos to start to home in on what are their preferred options," he said. "We want the market to choose one."
— Carol Wilson, Editor-at-Large, Light Reading