The Design Principles of PlanetLabLarry Peterson Timothy RoscoePrinceton University Intel Research – BerkeleyABSTRACTPlanetLab is a geographically distributed platform fordeploying, evaluating, and accessing planetary-scale net-work services. PlanetLab is a shared community effortby a large international group of researchers, each ofwhom gets access to one or more isolated slices of Plan-etLab’s global resources. Because we deployed Planet-Lab and started supporting users before we fully un-derstood what its architecture would be, being able toevolve the system became a requirement. This paperexamines the set of design principles that guided thisevolution. Some of these principles were explicit at theproject outset, and others have become crystallized asthe platform has developed.1. INTRODUCTIONPlanetLab is a globally distributed computing plat-form shared, built, and maintained by a community ofresearchers at 300 sites in more than 30 countries. Inexchange for hosting a small number of nodes (servers),participants obtain access to a share of resources acrossthe entire platform for deploying and evaluating planetary-scale network services [4]. In addition, the platform it-self, including the essential services required to operateit, is a communal design work in progress and an inter-esting research area in its own right.In this paper we concentrate on the design princi-ples of PlanetLab. By “design principles”, we meanthe rules we have come to recognize and formulate thatguide our decisions about how to put the platform to-gether. In contrast, we use the term “architecture” todenote the composition of the platform itself, in otherwords the end result of these decisions. We do not de-scribe PlanetLab’s architecture in this paper other thanto illustrate the consequences of our design principles.The architecture of the platform at time of writing isdescribed in several PlanetLab Design Notes (PDNs)and academic publications [1].Of course, the boundary between design principlesand high-level architectural features is somewhat arbi-trary. Nonetheless, we have found it useful to try totease the two apart. It is comparatively rare for the doc-umentation of large systems to include an attempt toreflect on the thought processes of its architects, DavidClark’s description of the Internet design philosophy [2]being one notable example.The evolving design of PlanetLab has been an at-tempt at principled pragmatism. The principles wepresent here did not, in general, predate the implemen-tation of PlanetLab, though some were explicit from theoutset. Instead, they have co-evolved with the architec-ture itself, and thus we expect them, like the architec-ture itself, to continue to change over time.2. GOALSUnderlying the design principles are the high-levelgoals of PlanetLab. From the beginning [4], we haveidentified three:• to provide a platform for researchers to experimentwith planetary-scale network services;• to provide a platform for novel network services tobe deployed and serve a real user community; and• to catalyze the evolution of the Internet into aservice-oriented architecture.It should be clear that these goals are highly syn-ergistic and reinforcing: early experiments with ideaslead to the deployment of new network services, andthe availability of a rich set of network services effec-tively changes the nature of the Internet. There are,however, subtle tensions between the three. For ex-ample, a platform that supports only short-term ex-periments would likely be designed differently than onethat must also support continuously-running services.We hope to support both workloads, but with a biastowards the latter. Similarly, a platform that supportsa collection of services developed by the research com-munity need not necessarily consider the full range ofscalability, security, and autonomy issues that must beaddressed by a platform which aspires to become theconduit through which users interact with the Internet.The balance-point between these two goals is difficult to11define: we must continue to push the scalability, secu-rity, robustness, and decentralization that an Internet-scale architecture requires, but at the same time, ensurethat the evolution of the architecture is driven by therequirements of the running system rather some ideal-ized vision.3. TERMINOLOGYThe design principles guiding the evolution of Plan-etLab as a platform have been formulated at the sametime as the architecture itself has crystallized. Conse-quently, while nominally independent of the current ar-chitecture of PlanetLab, it is convenient to describe andillustrate the design principles in the context of Planet-Lab as it currently exists. For that reason, we describebriefly here how PlanetLab’s architecture looks today;readers familiar with PlanetLab internals may observethat the current architecture does not always adhere tothe principles we describe here.PlanetLab users who wish to deploy applications ac-quire a slice, which is a collection of virtual machines(VMs) spread around the world. The VMs are imple-mented on physical machines by some OS mechanism orvirtual machine monitor (VMM), and controlled by an-other entity, the node manager, which is responsible forcreating and destroying slices. We sometimes call usethe term sliver to refer to the instantiation of a slice ona give node. There are also special infrastructure sliceswhich perform essential functions on each node (suchas providing a local site administrator’s interface to thenode).Collectively, the node managers and infrastructureservices, together with the (currently centralized) ac-count management and node installation functions, formthe control plane of PlanetLab.Of course, PlanetLab is at least two things: the entireensemble of contributed services and running applica-tions on the platform, and the narrower set of main-tained facilities that support the entire ensemble. By“architecture” in this paper we mean the structure ofthe core subset, maintained by the PlanetLab supportteam. However, we feel the design principles we outlinehere are applicable to other services above this layer inthe platform.4. DISTRIBUTED VIRTUALIZATIONPlanetLab services and applications run in a slice ofthe platform: a set of nodes on which the service re-ceives a fraction of each node’s resources, in the form ofa virtual machine (VM). Virtualization and virtual ma-chines are, of course, well-established concepts. Whatis new