Andy C. Bavier

PlanetLab: an overlay testbed for broad-coverage services

PlanetLab is a global overlay network for developing and accessing broad-coverage network services. Our goal is to grow to 1000 geographically distributed nodes, connected by a disverse collection of links. PlanetLab allows multiple service to run concurrently and continuously, each in its own slice of PlanetLab. This paper discribes our initial implementation of PlanetLab, including the mechanisms used to impelment virtualization, and the collection of core services used to manage PlanetLab.

Container-based operating system virtualization: a scalable, high-performance alternative to hypervisors

Hypervisors, popularized by Xen and VMware, are quickly becoming commodity. They are appropriate for many usage scenarios, but there are scenarios that require system virtualization with high degrees of both isolation and efficiency. Examples include HPC clusters, the Grid, hosting centers, and PlanetLab. We present an alternative to hypervisors that is better suited to such scenarios. The approach is a synthesis of prior work on resource containers and security containers applied to general-purpose, time-shared operating systems. Examples of such container-based systems include Solaris 10, Virtuozzo for Linux, and Linux-VServer. As a representative instance of container-based systems, this paper describes the design and implementation of Linux-VServer. In addition, it contrasts the architecture of Linux-VServer with current generations of Xen, and shows how Linux-VServer provides comparable support for isolation and superior system efficiency.

A routing underlay for overlay networks

We argue that designing overlay services to independently probe the Internet--with the goal of making informed application-specific routing decisions--is an untenable strategy. Instead, we propose a shared routing underlay that overlay services query. We posit that this underlay must adhere to two high-level principles. First, it must take cost (in terms of network probes) into account. Second, it must be layered so that specialized routing services can be built from a set of basic primitives. These principles lead to an underlay design where lower layers expose large-scale, coarse-grained static information already collected by the network, and upper layers perform more frequent probes over a narrow set of nodes. This paper proposes a set of primitive operations and three library routing services that can be built on top of them, and describes how such libraries could be useful to overlay services.

Trellis: a platform for building flexible, fast virtual networks on commodity hardware

We describe Trellis, a platform for hosting virtual networks on shared commodity hardware. Trellis allows each virtual network to define its own topology, control protocols, and forwarding tables, while amortizing costs by sharing the physical infrastructure. Trellis synthesizes two container-based virtualization technologies, VServer and NetNS, as well as a new tunneling mechanism, EGRE, into a coherent platform that enables high-speed virtual networks. We describe the design and implementation of Trellis and evaluate its packet-forwarding rates relative to other virtualization technologies and native kernel forwarding performance.

Using PlanetLab for network research: myths, realities, and best practices

PlanetLab is a continuously-evolving global network research testbed that is simultaneously used by hundreds of researchers for diverse tasks, ranging from short-term self-contained experiments among PlanetLab nodes to continuously-running Web-accessible services with tens of thousands of non-PlanetLab users. While PlanetLab cannot provide a perfectly-customized environment for every experiment, it has been changing over time, and the base of knowledge of how to best utilize it has also been growing. As a result, many of the early observations researchers made about PlanetLab would change if rechecked today. In this paper, we discuss these issues and explain whether they remain, have been addressed via PlanetLabs evolution, or can be avoided by the use of best practices. Where possible, we provide quantitative evidence showing the realities of PlanetLab and possible research avenues to further broaden the opportunities for using PlanetLab in network research.

Predicting MPEG execution times

This paper reports on a set of experiments that measure the amount of CPU processing needed to decode MPEG-compressed video in software. These experiments were designed to discover indicators that could be used to predict how many cycles are required to decode a given frame. Such predictors can be used to do more accurate CPU scheduling. We found that by considering both frame type and size, it is possible to construct a linear model of MPEG decoding with R2 values of 0.97 and higher. Moreover, this model can be used to predict decoding times at both the frame and packet level that are almost always accurate to within 25% of the actual decode times. This is a surprising result given the large variability in MPEG decoding times, and suggests that it is feasible to design systems that make quality of service guarantees for MPEG-encoded video.

Decentralized trust management and accountability in federated systems

In this paper, we describe three key problems for trust management in federated systems and present a layered architecture for addressing them. The three problems we address include how to express and verify trust in a flexible and scalable manner, how to monitor the use of trust relationships over time, and how to manage and reevaluate trust relationships based on historical traces of past behavior. While previous work provides the basis for expressing and verifying trust, it does not address the concurrent problems of how to continuously monitor and manage trust relationships over time. These problems close the loop on trust management and are especially relevant in the context of federated systems where remote resources can be acquired across multiple administrative domains and used in potentially undesirable ways (e.g., to launch denial-of-service attacks).

Scheduling computations on a software-based router

Recent efforts to add new services to the Internet have increased the interest in software-based routers that are easy to extend and evolve. This paper describes our experiences implementing a software-based router, with a particular focus on the main difficulty we encountered: how to schedule the routers CPU cycles. The scheduling decision is complicated by the desire to differentiate the level of service for different packet flows, which leads to two fundamental conflicts: (1) assigning processor shares in a way that keeps the processes along the forwarding path in balance while meeting QoS promises, and (2) adjusting the level of batching in a way that minimizes overhead while meeting QoS promises.

Joust: a platform for liquid software

The authors describe a Java-based platform for liquid software, called Joust, that is specifically designed to support low-level, communication-oriented systems and to avoid the limitations of general-purpose OSs. The authors contrast the platform requirements for communication-oriented liquid software with those of computation-oriented software, identify the limitations of current platforms, and outline the benefits of Joust. They also offer an overview of Scout (the underlying OS upon which Joust is built), its runtime system, and its just-in-time (JIT) compiler.

Constructing end-to-end paths for playing media objects

This paper describes a framework for constructing network services for accessing media objects. The framework, called end-to-end media paths, provides a new approach for building multimedia applications from component pieces. Based on input from the user and resource requirements from the media object, the system first discovers the sequence of nodes (end-to-end path) that both connect the source device to the sink device and possess sufficient resources to play the object. It then configures the individual nodes along this path with the modules (path segment) that implement the service.