BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
We sat down with Bruce Davie, a principal engineer at VMware, to discuss the how the company will enable Network Functions Virtualization (NFV). In this Q&A on the VMware NFV strategy, find out how the virtualization pioneer is optimizing its hypervisor to support NFV workloads and enhancing the service chaining capabilities of its NSX network virtualization software. Also find out how VMware will help telecoms orchestrate NFV services.
Telecom providers are telling you they want lower latency in hypervisors for NFV. How are you approaching this problem?
Bruce Davie: Going all way back to beginning of virtualization, the big question was how much overhead do I have to pay for having hypervisors in the first place, compared to running my workload on bare metal? So we've been optimizing performance for the entire lifetime of the company.
But there are tradeoffs when you turn the latency knob all the way to 11 [in a hypervisor]. You start turning off things that might help you be more efficient, use less power, get higher throughput. So, you can't say I want my hypervisor to be low latency and that's that. You have to say for some workloads, " I'm going to turn the knobs to get low latency and I'm willing to give up some other things to get that."
Improving latency or any kind of performance is always about finding the 10 little things that are each taking up a little bit of the budget and finding ways to improve them. There is no single magic bullet to get low latency.
A prototype we have worked on turns the latency as far as you can turn it to try get 100%, with worst case latency down to [the] 20 microsecond level. That's what I would call the extreme latency cases for something like nuclear reactor control, where you would make that choice rather than having other tradeoffs like efficiency or throughput.
We've made huge advances from ESXi 5.1 to 5.5. We have code that's written but not yet shipping that makes more advances.
What are the tradeoffs associated with pushing down latency in the hypervisor?
Davie: Take interrupt coalescing as an example. Normally, [a hypervisor] coalesces interrupts. Instead of the first interrupt coming and waking up the CPU, you can take several interrupts together and then wake it up. That's good for efficiency, but not so good for latency because that first interrupt had to wait for the next couple of interrupts. By coalescing interrupts, you do effectively less work per interrupt, but latency is worse. You turn it on and you get better efficiency, and if you turn it off [there is less latency]]. So, we give people the knob to make that choice. And efficiency and throughput can be kind of related because if you are inefficient, you are ultimately burning CPU cycles that might have been used for doing something else, like throughput.
Telecom providers have also requested higher throughput for small packets. Could you describe this problem?
Davie: You have to do a certain amount work on any packet, independent of how large it is. When you are doing large packets you can get a lot of throughput by doing relatively few packets per second. What happens with small packets is, you are still doing the same number of packets per second you were doing with large packets, but your throughput is going down because the number of bytes per packet is going down.
That's the kind of thing where you look at all the operations that you do on a per-packet basis, as opposed to per-byte basis. For us, it's mostly about providing enough [throughputs] to fully utilize all the resources on the server. It's really hard for an x86 machine to compete against a router full of ASICs, which is why there will be hardware vendors building switches for the foreseeable future.
In the NFV environment, you've got a server that has compute, networking, I/O -- a whole lot of things. And you want make sure you are using them all efficiently. A good use of that server would be [a] CPU running at 100% and a NIC that is loaded to 100%. Exactly how you get there depends on what workload you are running on the CPU. [In tests we have discussed at VMware], the CPU operation was trivial. It would receive the packet and transmit the packet. So there is not much useful computation being done. A much more likely thing would be the thing running inside the guest OS is actually a firewall or evolved packet core function which is doing quite a lot of computation on each packet. So you want that CPU to be completely busy and to be able feed packets to it fast enough to keep it busy.
We're able to get to 4 million packets per second range for short packets in the next release. That would keep a lot of CPUs busy for a lot of [NFV] applications.
How does NSX contribute to the VMware NFV strategy?
Davie: The thing where there is the most interesting work to do is around service chaining. We have some good capabilities today, but we definitely have some thoughts on what we could do to be more powerful in that area.
There are only a very small number of things you can do conceptually for service chaining. I think the most important thing is that you need a system for creating abstract topologies to interconnect the virtual network functions, which is exactly what NSX does.
Essentially, a service chain is a topology of services, and NSX creates virtual topologies to interconnect VMs, which is a very fine place to run your virtual network functions. Traditionally, people might have done it with things like VLANs, just like people did things like segmentation with VLANs. Obviously we view NSX as a much better solution for building these topologies in a programmatic way.
The second thing you need for a service chain is a metadata channel to pass information from one point in the service chain to another. A good example here is that maybe the first block in a service chain gets a whole lot of information on what handset initiated a call and what the user's profile is. Some kind of classification goes on at the start of the service chain. [You] end up with this index that tells you that this user belongs to class 732 and somewhere down the chain I'm going to do something special for this user because he belongs to that class. He'll get to the video optimization stage of the service chain and I'm going to give him the premium video optimizer
You need to pass that metadata along the chain so the classification needed back here can be leveraged by some other function further down the chain. There is really only one place to put the metadata. You've got to put it in a packet header that travels with the packet. But, it probably doesn''t need to be in the packet itself because you don't want to modify the user's packet [and] given that [NSX] encapsulates packets in a virtualization header, that's the perfect place to put it.
We've recently published an Internet draft about an encapsulation header called GENEVE. GENEVE is effectively VXLAN plus flexible option [fields]. So those flexible options give you a great place to put metadata. You can think of that metadata as being something that the virtual network function at [the] beginning of the classification could write into the [GENEVE option field]. It travels along with [the] packet in [an] encapsulation header. It's handed off to another virtual network function that can now read that metadata and do something scheduled for the packet based on that.
Is this something that's possible to do in VXLAN but is better to do in GENEVE?
Davie: It's less obvious where you could put that in VXLAN. I was talking to somebody who had done it by putting it in an IP option. You do run out of places to put it if you are in a fixed header. One thing people have talked about doing is carrying a VLAN header along with the packet inside VXLAN. It's not ideal because it's still a pretty short field.
Are there other VMware NFV initiatives you can share?
Davie: The other place where there is a big piece for VMware to play in NFV is around orchestration. That's where I see the least maturity in terms of products. People are kind of doing demo level orchestration at the moment. That's an area where we could leverage some tools we have and do things through OpenStack to provide some validated capabilities.
You mentioned there are NFV trials happening with your hypervisor. Are you seeing any uptake of NSX?
Davie: The NSX team gets pulled in to discuss many of these NFV trials, in part because of the recognition of needing some of what NSX brings, and also because we're the networking team and they want that expertise.
But some pilots are so small that the agility benefits of NSX are less necessary. You can get away without agility when things are really small-scale. As people are planning their bigger pilots, I think that's where they will see the benefits of having an automated network virtualization component.
Are you building relationships with virtual network function vendors?
Davie: We've been building relationships with virtual network function vendors for a long time. If you asked anybody from VMware what our NFV strategy was a year ago, it would mostly [have] been around partnerships with traditional network equipment manufacturers.
What's the timeline on delivering a hypervisor that is ready for NFV?
Davie: I would say the hypervisor is ready today for a lot of telco applications. Part of the challenge is you have to really validate solutions [to] make the latency requirements on applications. I think with the low latency settings in ESXi 5.5, we can meet the requirements for of a lot of NFV applications, [including evolved packet core and customer-premises equipment].
Are there areas of NFV that remain a challenge for your hypervisor?
Davie: Virtualizing the radio access network is one that we view as a pretty tough latency challenge. It's kind of in the same category as high-frequency trading. I think [VMware CEO] Pat [Gelsinger] has said he wants 100% of applications to be virtualized. He's put the stake in the ground, like Kennedy saying we're going to the moon in 10 years. I think we can meet those numbers, but they do require some fairly extreme tuning of the hypervisor that would produce some other downsides. So virtualizing the radio access network is something we see as being a little way out for us at the moment.
What we need from NFV orchestration
Where SDN and NFV connect
SDN and NFV in mobile networks