Summary

  • PlanetLab’s slice was a network-wide container assembled from fractions of resources on many nodes. It gave a service a coherent operating identity without giving it ownership of any physical machine.
  • Control remained layered. A global service could request and assemble a slice, but node managers, schedulers, host policies and local admission decisions determined what actually ran.
  • Freedom to experiment was coupled to isolation, resource accounting and a chain of responsibility. A global abstraction was credible only when an external packet or local resource cost could still be traced back to a principal.

One account crossed machines; ownership did not

In the early 2000s, a network researcher who wanted to test a service at Internet scale faced a social problem before a technical one. Accounts had to be borrowed from colleagues. Machines sat in different institutions. A program that behaved well on three friendly servers might fail under long paths, uneven load or the policies of a host that had never met its author.

PlanetLab turned that informal favour network into shared infrastructure. A research group could obtain an account that spanned many sites and deploy one service across them. The project called the resulting object a slice.

The word was precise. In the 2004 operating-system paper, a service received a fraction of each participating node’s resources in a virtual machine. Those local virtual machines formed one compound entity. The slice looked, from the service’s point of view, like a distributed set of private machines. Yet the authors called that privacy an illusion maintained by isolation. No machine changed owner. No campus surrendered its network. No global name converted a local contribution into global property.

This distinction is easy to lose because the abstraction was useful. A service manager could address the slice as a whole, install software across it and treat its scattered components as one deployment. But the slice was not a hidden supercomputer. It was a composition of bounded local grants.

A sliver was the fact beneath the slice

PlanetLab’s design vocabulary made the composition visible. A virtual machine consumed a portion of one node’s CPU, memory, storage and network capacity. That local portion was a sliver. A slice was the network of those virtual machines and slivers across participating nodes.

Much of the service remained deliberately unspecified. PlanetLab did not dictate a single overlay topology. It did not require every slice to use one language or runtime. It exposed enough local mechanism for researchers to build their own distributed service above the ordinary Internet.

This was autonomy with a hard lower boundary. A slice could choose how its components talked to one another; it could not wish new CPU cycles into a loaded host. It could choose its software; it could not grant itself root over the shared machine. It could ask for nodes in many places; it could not make an offline node answer.

An early design note expressed the distinction through tickets and leases. A ticket described a node, an amount of resources and a time window. Presenting it could produce a lease, but only subject to the node’s admission policy. The note was an ongoing draft, not a timeless description of every PlanetLab release. Its constitutional insight nevertheless remains clear: a global allocator could carry a claim to the door, while the local node retained the last operational decision.

The centre assembled; the nodes decided

PlanetLab was not a fairy tale of total decentralisation. Its initial architecture included PlanetLab Central, a front end that contacted the node manager on each selected machine. The node manager created and controlled local virtual machines. Privileged code still existed, and bootstrapping could not be implemented by an infinite regress of replaceable services.

At the same time, the nodes belonged to universities, laboratories and other autonomous organisations. The 2006 experience report made this a design requirement: each organisation had to retain some control over how its resources were used, and the platform had to minimise central control if it wanted participation to grow.

The slice therefore crossed an authority boundary on every node. A global view could say that a service should have a component in Princeton, Berkeley or elsewhere. Actual execution depended on the corresponding local manager, resource state, scheduler and host limit. A stale global view could not override a machine that had no capacity. The record described an intended slice; running code disclosed the live one.

Isolation had more than one job

Calling a slice isolated could conceal several different promises. Resource isolation tried to stop one service’s CPU, memory, disk or bandwidth use from unduly damaging another. Security isolation tried to prevent namespace interference or access across slices. A stable programming base tried to stop an unprivileged service from changing the machinery underneath its neighbours.

These were not interchangeable. A service might be securely separated yet suffer variable latency on a busy node. It might receive a fair share of CPU without receiving a reservation. It might remain correct in its own VM while a host bandwidth cap changed its observed throughput.

The operational papers are unusually candid about this gap. Best effort had seemed sufficient at first; heavy load and volatile performance made that assumption expensive. PlanetLab used fair sharing, explicit reservations and token-based scheduling. Memory pressure could cause a watchdog to reset a large consumer. Host sites could cap outbound traffic. One 2006 experiment saw a 74-millisecond underlying path turn into overlay round trips ranging from 76 to 135 milliseconds before special CPU treatment. Reservations and real-time scheduling narrowed most of the gap, but did not abolish kernel activity or every source of jitter.

That measurement is not a verdict on the whole platform. It is evidence of what the slice never promised by itself. A namespace spanning the world did not make the world dedicated.

Accountability was part of the permission to experiment

PlanetLab’s users could emit traffic from machines inside institutions they did not belong to and toward networks that had not volunteered for the experiment. Internet mapping could trigger intrusion alarms. A throughput test could consume a campus gateway’s capacity. Even legitimate research could impose costs on strangers.

The design response was not merely to filter more traffic. The 2004 paper required resource accounting and after-the-fact attribution of actions, not only quantities, to slices. The later design-principles paper described a chain of responsibility: externally visible activity had to map back through the slice to the responsible user.

That chain made broad delegation tolerable. A host did not need a separate trust relationship with every researcher. It needed enforceable limits, a way to identify the principal behind an action and a party able to respond. The slice was therefore both a freedom boundary and an evidence boundary.

If the chain broke, the global abstraction became dangerous. A packet would still leave the node, but the institution bearing the complaint could no longer say which service sent it, under whose authority, with which resource grant or through which control path. Isolation without attribution protected processes while abandoning responsibility.

Unbundled management made the manager replaceable—up to a point

PlanetLab’s second important move was to separate the low-level node mechanism from network-wide management services. Slice creation, resource discovery, monitoring and software distribution could be implemented by services running above the local operating base. Several alternatives could evolve in parallel rather than receiving one permanent privileged throne.

The design principle was to keep only local abstractions in the node operating system and build global abstractions through services. Interfaces exported by the privileged base should be explicit and shareable. That reduced the number of functions that had to be trusted as unique.

It did not eliminate the unique core. Something still had to create a local VM, enforce limits and bootstrap the first service. The authors acknowledged this. The meaningful achievement was not authority-free infrastructure; it was a smaller and more inspectable authority boundary.

This is where PlanetLab meets a present-day lesson from Heng Lu’s Minimum Initial Specification and Running-Code Primacy. A common layer is healthiest when it defines only the local invariants needed for safe composition. Broader services may compete, change or disappear. Their records do not acquire the power to manufacture local capacity, and their global name does not become title to the machines below.

That is an editorial comparison, not a claim that PlanetLab’s authors were applying Heng Lu’s later doctrine. The historical record stands on its own.

PlanetLab anticipated the cloud; it did not own the future

Princeton’s 2026 retrospective reports that PlanetLab eventually reached 1,353 nodes at 717 sites in 48 countries and officially shut down in 2020. Peterson’s own bounded formulation is the useful one: PlanetLab did not create the cloud, but it anticipated it.

It anticipated a world in which users request an abstract resource, software is deployed across remote machines, multiple tenants share physical capacity, and the operating system beneath the service matters less than the contract exposed above it. It also exposed the questions that polished cloud interfaces can hide: which local machine granted the resource, which policy can refuse it, what performance class was actually allocated, who may reset it, and who answers when its traffic harms someone else?

PlanetLab should not be turned into the sole ancestor of virtual machines, containers, content delivery or cloud orchestration. Those histories are wider. Its distinct contribution was to make the global resource abstraction run in public, under uneven load, across autonomous owners, with real outsiders affected by the result.

The project ended. The problem it clarified did not. Any platform that offers a global object above other people’s infrastructure still has to prove that the object is composed from valid local grants, that local refusals remain visible and that responsibility survives the abstraction.

Peterson’s role belongs inside a collaborative system

Larry Peterson was a central organiser, architect and operator of PlanetLab, and Princeton now names him Robert E. Kahn Professor, Emeritus and Senior Research Scholar. But the work was never his alone.

The 2002 blueprint was written with Tom Anderson, David Culler and Timothy Roscoe. The 2004 operating-system paper lists Andy Bavier, Mic Bowman, Brent Chun, David Culler, Scott Karlin, Steve Muir, Peterson, Roscoe, Tammo Spalink and Mike Wawrzoniak. The 2006 experience paper belongs to Peterson, Bavier, Marc E. Fiuczynski and Muir. The dynamic-slice note was an Architecture Team document edited by Peterson and Amin Vahdat with additional named contributors.

That collective attribution is not ceremonial. PlanetLab’s subject was how independent people and institutions could share a system without pretending to become one owner. Its authorship should preserve the same fact.

Sources