Datacenters have traditionally been architected as a collection of servers wherein each server aggregates a fixed amount of computing, memory, storage, and communication resources. In this paper, we advocate an alternative construction in which the resources within a server are disaggregated and the datacenter is instead architected as a collection of standalone resources.Disaggregation brings greater modularity to datacenter infrastructure, allowing operators to optimize their deployments for improved efficiency and performance. However, the key enabling or blocking factor for disaggregation will be the network since communication that was previously contained within a single server now traverses the datacenter fabric. This paper thus explores the question of whether we can build networks that enable disaggregation at datacenter scales.

Modern commodity hardware architectures, with their multiple multi-core CPUs and high-speed system interconnects, exhibit tremendous power. In this paper, we study performance limitations when building both software routers and software virtual routers on such systems. We show that the fundamental performance bottleneck is currently the memory system, and that through careful mapping of tasks to CPU cores, we can achieve forwarding rates of 7 million minimum-sized packets per second on mid-range server-class systems, thus demonstrating the viability of software routers. We also find that current virtualisation systems, when used to provide forwarding engine virtualisation, yield aggregate performance equivalent to that of a single software router, a tenfold improvement on current virtual router platform performance. Finally, we identify principles for the construction of high-performance software router systems on commodity hardware, including full router virtualisation support.

Abstract-In this paper, we evaluate the performance of a software IP router forwarding plane inside the Xen virtual machine monitor environment with a view to identifying (some) design issues in Virtual Routers. To this end, we evaluate and compare the forwarding performance of two identical Linux software router configurations, run either above the Xen Hypervisor or within vanilla Linux. Even with minimal sized packets, we show that the Xen Dom0 privileged domain offers near native forwarding performance at the condition that the sollicitation to unpriviledged domains stay minimal, whereas Xen unprivileged domains offer very poor performance in every cases. This shows that an important design principle for virtual router platforms must be to handle all forwarding, for all virtual routers, onto the same forwarding engine, in order to avoid much detrimental per-packet context switching.

In this paper we investigate the building of a virtual router platform that ensures isolation and fairness between concurrent virtual routers. Recent developments in commodity x86 hardware enable us to take advantage of the flexibility and wealth of resources available to a software router in order to build a virtual router platform. Using commodity x86 hardware we show that it is viable to run highly experimental and untrusted router systems along side a production router on the same hardware platform without sacrificing performance. We investigate the extent to which we can isolate a virtual router running experimental code from other virtual routers.

Most network deployments respond to changing application, workload, and policy requirements via the deployment of specialized network appliances or "middleboxes". Despite the critical role that middleboxes play in introducing new network functionality, they have been surprisingly ignored in recent efforts for designing networks that are amenable to innovation. We make the case that enabling innovation in middleboxes is at least as important, if not more important, as that for traditional switches and routers. To this end, our vision is a world with software-centric middlebox implementations running on general-purpose hardware platforms that are managed via open and extensible management APIs. While these principles have been applied in other contexts, they introduce unique opportunities and challenges in the context of middleboxes that we highlight in this paper.