Yiannis Yiakoumis

Carving research slices out of your production networks with OpenFlow

1. SLICED PROGRAMMABLE NETWORKS OpenFlow [4] has been demonstrated as a way for researchers to run networking experiments in their production network. Last year, we demonstrated how an OpenFlow controller running on NOX [3] could move VMs seamlessly around an OpenFlow network [1]. While OpenFlow has potential [2] to open control of the network, only one researcher can innovate on the network at a time. What is required is a way to divide, or slice, network resources so that researchers and network administrators can use them in parallel. Network slicing implies that actions in one slice do not negatively affect other slices, even if they share the same underlying physical hardware. A common network slicing technique is VLANs. With VLANs, the administrator partitions the network by switch port and all traffic is mapped to a VLAN by input port or explicit tag. This coarse-grained type of network slicing complicates more interesting experiments such as IP mobility or wireless handover. Here, we demonstrate FlowVisor, a special purpose OpenFlow controller that allows multiple researchers to run experiments safely and independently on the same production OpenFlow network. To motivate FlowVisor’s flexibility, we demonstrate four network slices running in parallel: one slice for the production network and three slices running experimental code (Figure 1). Our demonstration runs on real network hardware deployed on our production network at Stanford and a wide-area test-bed with a mix of wired and wireless technologies.

Slicing home networks

Despite the popularity of home networks, they face a number of systemic problems: (i)Broadband networks are expensive to deploy; and it is not clear how the cost can be shared by several service providers; (ii) Home networks are getting harder to manage as we connect more devices, use new applications, and rely on them for entertainment, communication and work|it is common for home networks to be poorly managed, insecure or just plain broken; and (iii) It is not clear how home networks will steadily improve, after they have been deployed, to provide steadily better service to home users. In this paper we propose slicing home networks as a way to overcome these problems. As a mechanism, slicing allows multiple service providers to share a common infrastructure; and supports many policies and business models for cost sharing. We propose four requirements for slicing home networks: bandwidth and traffic isolation between slices, independent control of each slice, and the ability to modify and improve the behavior of a slice. We explore how these requirements allow cost-sharing, outsourced management of home networks, and the ability to customize a slice to provide higher-quality service. Finally, we describe an initial prototype that we are deploying in homes.

Making use of all the networks around us: a case study in android

Poor connectivity is common when we use wireless networks on the go. A natural way to tackle the problem is to take advantage of the multiple network interfaces on our mobile devices, and use all the networks around us. Using multiple networks at a time makes makes possible faster connections, seamless connectivity and potentially lower usage charges. The goal of this paper is to explore how to make use of all the networks with todays technology. Specifically, we prototyped a solution on an Android phone. Using our prototype, we demonstrate the benefits (and difficulties) of using multiple networks at the same time.

Putting home users in charge of their network

Policy-makers, ISPs and content providers are locked in a debate about who can control the Internet traffic that flows into our homes. In this paper we argue that the user, not the ISP or the content provider, should decide how traffic is prioritized to and from the home. Home users know most about their preferences, and if they can express them well to the ISP, then both the ISP and user are better off. To test the idea we built a prototype that lets users express highlevel preferences that are translated to low-level semantics and used to control the network.

Scheduling packets over multiple interfaces while respecting user preferences

Now that our smartphones have multiple interfaces (WiFi, 3G, 4G, etc.), we have preferences for which interfaces an application may use. We may prefer to stream video over WiFi because it is fast, but VoIP over 3G because it gives continued connectivity. We also have relative preferences, such as giving Netflix twice as much capacity as Dropbox. This means our mobile devices need to schedule packets in keeping with our preferences while making use of all the capacity available. This is the natural domain of fair queuing, and this paper is about the design of a packet scheduler to meet these requirements. We show that traditional fair queueing schedulers cannot take into account a users preferences for some interfaces over others. We present a novel packet scheduler called miDRR that meets our needs by generalizing DRR for multiple interfaces. We demonstrate a prototype running in Linux and show that it works correctly and can easily run at the speeds we need.

BeHop: a testbed for dense WiFi networks

We present BeHop, a wireless testbed for dense WiFi networks often seen in residential and enterprise settings. BeHop aims to provide insights on the operation of dense deployments, and evaluate how different WiFi management strategies affect user experience and network behavior. It has sufficient flexibility to let us try different management techniques and setups (e.g. residential or enterprise, client or infrastructure-driven operation). It is deployed at a university dorm, where it acts as the main network for a diverse set of users and devices, exposing practical insights and implications on the operation of the network. In this paper we discuss the design and implementation of BeHop, and share our early experience over a five-month period.

Neutral Net Neutrality

Should applications receive special treatment from the network? And if so, who decides which applications are preferred? This discussion, known as net neutrality, goes beyond technology and is a hot political topic. In this paper we approach net neutrality from a users perspective. Through user studies, we demonstrate that users do indeed want some services to receive preferential treatment; and their preferences have a heavy-tail: a one-size-fits-all approach is unlikely to work. This suggests that users should be able to decide how their traffic is treated. A crucial part to enable user preferences, is the mechanism to express them. To this end, we present network cookies, a general mechanism to express user preferences to the network. Using cookies, we prototype Boost, a user-defined fast-lane and deploy it in 161 homes.