Vladimir Andrei Olteanu

In-Net: in-network processing for the masses

Network Function Virtualization is pushing network operators to deploy commodity hardware that will be used to run middlebox functionality and processing on behalf of third parties: in effect, network operators are slowly but surely becoming in-network cloud providers. The market for innetwork clouds is large, ranging from content providers, mobile applications and even end-users. We show in this paper that blindly adopting cloud technologies in the context of in-network clouds is not feasible from both the security and scalability points of view. Instead we propose In-Net, an architecture that allows untrusted endpoints as well as content-providers to deploy custom in-network processing to be run on platforms owned by network operators. In-Net relies on static analysis to allow platforms to check whether the requested processing is safe, and whether it contradicts the operators policies. We have implemented In-Net and tested it in the wide-area, supporting a range of use-cases that are difficult to deploy today. Our experience shows that In-Net is secure, scales to many users (thousands of clients on a single inexpensive server), allows for a wide-range of functionality, and offers benefits to end-users, network operators and content providers alike.

Efficiently migrating stateful middleboxes

Middleboxes that hold per-flow state and perform Layer 4+ processing are widely deployed in the Internet today: a recent study shows their presence on at least a third of the studied paths [5]. These middleboxes provide functionality ranging from security to performance optimization, and are becoming ubiquitous with time. To reduce costs and enable fast functionality updates there is an ongoing trend of migrating away from specialized hardware implementations of middleboxes to software running on commodity servers [9]. Programmable switches (such as OpenFlow) coupled with x86 machines have been proposed as the natural architecture to create scalable middleboxes that are also easy to deploy and update [3]. The basic recipe is very simple: a collection of x86 servers are connected to an OpenFlow switch, which is in turn “on-path” for the traffic. The servers implement distributedly the functionality of a single middlebox (possibly in virtual machines), such as carrier-grade NAT or firewall. The programmable switch is a key ingredient, splitting load between the machines. To make such distributed middleboxes scalable, we need ways to seamlessly move processing and its associated flow state between local or remote servers. This would allow the platform to deal with load surges by adding servers, and to efficiently scale down by shutting machines off. Processing could even be migrated to different middleboxes in other parts of the world to optimize other aspects such as userperceived delay.

Lost in Network Address Translation: Lessons from Scaling the World's Simplest Middlebox

To understand whether the promise of Network Function Virtualization can be accomplished in practice, we set out to create a software version of the simplest middlebox that keeps per flow state: the NAT. While there is a lot of literature in the wide area of SDN in general and in scaling middleboxes, we find that by aiming to create a NAT good enough to compete with hardware appliances requires a lot more care than we had thought when we started our work. In particular, limitations of OpenFlow switches force us to rethink load balancing in a way that does not involve the centralized controller at all. The result is a solution that can sustain, on six low-end commodity boxes, a throughput of 40Gbps with 64B packets, on par with industrial offerings but at a third of the cost. To reach this performance, we designed and implemented our NAT from scratch to be migration friendly and optimized for common cases (inbound traffic, many mappings). Our experience shows that OpenFlow-based load balancing is very limited in the context of NATs (and by relation NFV), and that scalability can only be ensured by keeping the controller out of the data plane.

Datacenter Scale Load Balancing for Multipath Transport

Multipath TCP traffic is on the rise with recent deployments by Apple and Samsung on mobile phones. Despite this, MPTCP adoption on servers is falling behind and the major problem is that Multipath TCP does not work with existing datacenter load balancers. In this work we present MPLB, a distributed load balancer for Multipath TCP traffic. MPLB uses stateless software multiplexers to direct traffic to backend servers and is resilient to mux and network failures, as well as backend server churn. We have implemented and tested MPLB, finding it can handle 6Mpps per machine with minimum-sized packets, seamlessly scale-out or in and gracefully handle mux failures.