pectations and certainly were not at par with existing physical routers in relation to throughput, packet loss, and jitter. This exercise provided valuable insight into the obstacles to be overcome before implementing packet processing VNFs on a generic server platform. Both the hypervisor within the server, and the virtual router code, suffered from bottlenecks that contributed to limited performance and was sus- ceptible to unpredictable packet loss and jitter. For example, running a canned traffic performance benchmark test on a physical router in a static state typically shows very similar results each time (e.g., with a 100 MB/s throughput and up to 0.01% packet loss, the results are usually consistent). But in the virtual implementation, with the initial server testing, the results could vary widely from test to test. While some of these impairments were significantly reduced when additional CPU resources were allocated to the VNF, the additional cost of CPUs makes it cost prohibitive to vir- tualize the function. Within the server's hypervisor, a packet needed to go through additional processing that con- tributed to cost in terms of overall performance. The packet processing throughput of the hyper- visor itself was far less than what was typically observed with physical appliances, let alone when adding a VF on top of the hypervisor-the hypervisor itself became the first bottleneck to overcome. By temporarily eliminating the bottleneck of the hypervisor by using more CPU resources, then found that the throughput of the vRouter was also significantly lower. The data showed us that while a physical box provided well-known vendors support up to 1G of traffic, the virtual Building the Network of the Future environment using the same amount of processing power (i.e., CPU) was severely limited. The packet-processing capability in the virtual environment ranged from 200 to 350 Mbps depending across various vendor vRouters. In addition, it was unclear how and at what cost (in terms of performance), one can use S