ame kernel, it is possible that one guest operation can affect the functionality of other guest applications on the same machine. Hypervisor- based approaches do not pose this issue because guest VMs do not share any kernel code (they each have their own guest OS). More work is needed to find an optimal host OS configuration where multiple network functions can efficiently use the container-based environment. As container technology becomes more mature and VNF vendors evolve to provide container- ized network functions, service providers will be in a good position to leverage the new container- based approach to further simplify and enable faster delivery of software services. With the existing state of container technology, nonpacket forwarding VNFs that do not have complex kernel require- ments, are suitable for containerization. 10.2.2 INCREASING PACKET PROCESSING CAPABILITIES Once we figure out the mechanisms to virtualize a set of network functions via a hypervisor, the next step is to determine the overall performance of the VNF. Since the customer requirements (and expectations) for network elements do not change based on implementation (i.e., physical or virtual), the overall performance goal is to be as good as, or better than, the physical environment, especially to dispel the prevailing perception that x86 platforms cannot perform at the same level as purpose-built hardware. The initial performance work focused on the most basic network function, the vRouter (virtual router). The vRouter is considered to be a necessary VNF building block for other higher-level VNFs such as vFirewall, vWANx, etc. The primary focus was to assess speed of processing packets while maintaining acceptable levels of packet loss, latency, and jitter. At the initial stage of the investigation, baseline performance data were collected, with no x86 packet optimization techniques enabled on the platform. While the baseline results were consistent across multiple vendors, they were severely limited when compared with the modeled ex