Résumé

  • Une slice PlanetLab réunissait des fractions de calcul, de mémoire, de stockage et de réseau réparties sur plusieurs nœuds. Elle formait un objet mondial sans devenir propriétaire d’aucune machine physique.
  • L’intention globale ne suffisait jamais : le gestionnaire de chaque nœud, l’état local des ressources, l’ordonnanceur et les règles de l’établissement hôte déterminaient l’exécution réelle.
  • La liberté d’expérimenter reposait sur deux contreparties : isoler les usages concurrents et conserver une chaîne de responsabilité reliant toute activité visible au principal qui l’avait déclenchée.

L’objet mondial était fait de permissions locales

Au début des années 2000, déployer un service sur une grande partie de l’Internet consistait souvent à demander des comptes à des collègues. Cette méthode produisait quelques machines amicales, pas une infrastructure reproductible. Elle ne permettait ni de comparer proprement deux expériences, ni de savoir comment un programme réagirait à des distances, des charges et des administrations différentes.

PlanetLab a industrialisé cette coopération. Un groupe de recherche pouvait obtenir une présence sur de nombreux sites et exploiter l’ensemble sous une même identité de service. Cet ensemble s’appelait une slice.

Le terme ne désignait pas une grande machine secrète. Dans l’article NSDI de 2004, le service reçoit sur chaque nœud une fraction de ressources, matérialisée par une machine virtuelle. Le regroupement de ces VM devient une entité composite. Pour l’utilisateur, il entretient l’illusion d’un parc privé distribué. Le mot « illusion » est décisif : l’isolation rend l’expérience praticable, elle ne transfère ni le serveur, ni le réseau local, ni le pouvoir de l’institution qui les fournit.

La slice était donc un contrat de composition. Son nom mondial rendait les morceaux utilisables ensemble ; il ne changeait pas leur titre local.

Sous la slice, chaque nœud ne promettait qu’un sliver

La terminologie de PlanetLab empêchait de confondre les niveaux. La part locale allouée à une VM — cycles CPU, mémoire, disque et capacité réseau — était un sliver. La slice était le réseau de ces VM et de ces slivers.

Cette architecture laissait au service une large liberté. L’environnement ne lui imposait pas une topologie de tunnels unique. Il ne prescrivait pas un langage commun à toutes les expériences. Un chercheur pouvait définir son propre overlay et installer les composants adaptés à son hypothèse.

Mais cette autonomie s’arrêtait au bord du nœud. Le service pouvait choisir sa topologie sans créer de capacité supplémentaire. Il pouvait demander un site sans obliger une machine saturée à répondre. Il pouvait disposer d’un espace isolé sans obtenir les privilèges système du serveur partagé.

Une note de conception de 2002 rendait ce partage particulièrement explicite. Un ticket décrivait une ressource, un nœud et une durée ; sa présentation pouvait donner lieu à un bail. La décision finale appartenait néanmoins au contrôle d’admission du nœud, selon l’état courant et la politique locale. Cette note portait le statut de brouillon évolutif. Elle ne doit pas être présentée comme le fonctionnement immuable de toutes les versions, mais elle fixe une frontière intellectuelle nette : l’allocation globale propose, le nœud dispose.

PlanetLab Central ne supprimait pas l’autonomie des hôtes

Le projet ne fut jamais une décentralisation sans centre. Dans l’architecture initiale, PlanetLab Central contactait les gestionnaires de nœuds afin d’y créer les VM locales. Des fonctions privilégiées restaient nécessaires pour amorcer la plateforme, appliquer des limites et établir le premier environnement d’exécution.

En parallèle, les machines étaient fournies par des organisations autonomes. Le bilan OSDI de 2006 en tire une exigence directe : chaque organisation devait conserver une part de contrôle sur l’utilisation de ses ressources, et la croissance du système dépendait d’une réduction du contrôle central.

Chaque composant d’une slice franchissait ainsi une limite d’autorité. Le registre central pouvait afficher un nœud parmi les destinations prévues. Seuls le gestionnaire local, l’état réel de la machine et les règles de l’hôte pouvaient confirmer qu’un sliver vivait encore. Une vue globale périmée n’était pas du calcul disponible.

Cette différence oppose le service déclaré au service exécuté. La première vue est commode ; la seconde est la seule qui puisse porter une expérience.

« Isolé » ne voulait pas dire « dédié »

PlanetLab devait résoudre plusieurs formes d’interférence. L’isolation des ressources cherchait à limiter les effets d’un service sur le CPU, la mémoire, le disque ou la bande passante d’un autre. L’isolation de sécurité séparait les espaces de noms et les données. Une base d’exécution stable empêchait une slice de modifier le système dont dépendaient ses voisines.

Ces promesses ne se substituaient pas les unes aux autres. Une VM pouvait être correctement cloisonnée et subir une latence variable. Une slice pouvait recevoir une part équitable sans bénéficier d’une réservation. Un programme pouvait être exact dans son espace tout en mesurant un débit borné par la politique du site.

L’expérience opérationnelle a corrigé l’optimisme initial du « best effort ». Les pics de charge et les performances volatiles ont conduit à des mécanismes de partage équitable, à des réservations explicites et à un ordonnancement par jetons. Sous forte pression mémoire, un gardien pouvait réinitialiser la VM la plus gourmande. Les sites pouvaient plafonner le trafic sortant.

Dans une expérience publiée en 2006, un chemin sous-jacent à 74 ms produisait, dans l’overlay, des allers-retours entre 76 et 135 ms avant traitement CPU particulier. La réservation et l’ordonnancement temps réel réduisaient fortement la dispersion, sans éliminer toute activité du noyau. Ce résultat ne note pas PlanetLab dans son ensemble. Il montre simplement qu’un identifiant mondial n’était pas une garantie de machine dédiée.

L’audit rendait l’ouverture soutenable

Un utilisateur PlanetLab pouvait émettre du trafic depuis une université qu’il ne connaissait pas vers un réseau qui n’avait jamais accepté l’expérience. Une mesure cartographique pouvait déclencher une alerte d’intrusion. Un test de débit pouvait occuper une liaison de campus. La légitimité scientifique du but n’effaçait pas le coût subi ailleurs.

L’architecture exigeait donc plus qu’un filtrage. L’article de 2004 demandait une comptabilité des ressources et la possibilité d’attribuer après coup des actions — pas seulement des quantités — à une slice. Le texte sur les principes de conception parle ensuite d’une chaîne de responsabilité : une activité visible depuis l’extérieur devait remonter jusqu’à l’utilisateur responsable.

Cette preuve remplaçait des milliers de relations de confiance bilatérales. L’établissement hôte n’avait pas à connaître personnellement chaque chercheur s’il pouvait faire appliquer ses limites, identifier le principal derrière un paquet et obtenir une réponse en cas d’incident.

La slice était donc à la fois un espace d’autonomie et un reçu. Si le reçu disparaissait, l’abstraction mondiale protégeait encore le processus, mais plus l’institution qui devait répondre du dommage.

Dépaqueter la gestion réduisait le noyau d’autorité

PlanetLab séparait les mécanismes locaux des services de gestion à l’échelle du réseau. La création de slices, la découverte de ressources, la surveillance ou la distribution logicielle pouvaient évoluer sous forme de services au-dessus d’une petite base locale. Plusieurs implémentations pouvaient coexister plutôt qu’hériter d’un privilège unique et permanent.

Le principe était de ne placer directement dans l’OS que les abstractions du nœud. Les abstractions mondiales devaient être composées par des services utilisant des interfaces explicites et partageables. Cela rendait une partie de la gestion remplaçable.

Une partie seulement. Il fallait toujours créer la VM locale, appliquer les limites et amorcer le premier service. Les auteurs reconnaissaient ce noyau irréductible. Leur apport n’était pas de nier le privilège, mais d’en réduire l’étendue et de rendre sa frontière observable.

Le rapprochement contemporain avec la spécification initiale minimale et la primauté du code en fonctionnement, dans les notes de Heng Lu, se situe ici. La couche commune est plus solide lorsqu’elle ne garantit que les invariants nécessaires à une composition sûre ; les services globaux peuvent évoluer sans transformer leur registre en droit de propriété sur les machines. Il s’agit d’une grille d’analyse actuelle, pas d’une influence historique attribuée aux auteurs de PlanetLab.

Anticiper le cloud n’est pas l’avoir inventé

Le récit rétrospectif de Princeton publié en 2026 indique que PlanetLab a atteint 1 353 nœuds dans 717 sites et 48 pays avant sa fermeture officielle en 2020. Peterson formule lui-même la portée avec prudence : PlanetLab n’a pas créé le cloud, mais l’a anticipé.

La plateforme a effectivement rendu familière une opération devenue ordinaire : demander une ressource abstraite, déployer à distance, partager du matériel entre plusieurs utilisateurs et raisonner sur un service plutôt que sur la machine physique. Elle a aussi rendu visibles les questions que les interfaces modernes lissent : quel hôte a accordé la ressource, avec quelle classe de service, qui peut la refuser ou la réinitialiser, et qui répond de son trafic ?

PlanetLab n’est pas l’ancêtre unique des VM, des conteneurs, des CDN ou de l’orchestration. Son expérience distinctive fut de mettre l’abstraction mondiale à l’épreuve d’hôtes autonomes, d’une capacité rare, de charges réelles et de tiers affectés.

Le projet pouvait s’arrêter sans invalider cette leçon. La fonction utile n’était pas l’immortalité de l’institution, mais la capacité à composer des autorisations locales vérifiables.

Un travail collectif autour de Larry Peterson

Larry Peterson fut un organisateur, un architecte et un opérateur central de PlanetLab. Princeton le présente aujourd’hui comme Robert E. Kahn Professor, Emeritus and Senior Research Scholar. Cette place ne transforme pas une œuvre collective en invention solitaire.

Le texte fondateur de 2002 porte aussi les noms de Tom Anderson, David Culler et Timothy Roscoe. L’article NSDI de 2004 réunit Andy Bavier, Mic Bowman, Brent Chun, David Culler, Scott Karlin, Steve Muir, Peterson, Roscoe, Tammo Spalink et Mike Wawrzoniak. Le retour d’expérience OSDI de 2006 est signé Peterson, Bavier, Marc E. Fiuczynski et Muir. La note sur les slices vient de l’équipe d’architecture, sous la direction éditoriale de Peterson et Amin Vahdat, avec plusieurs contributeurs nommés.

Respecter cette pluralité convient au sujet : PlanetLab cherchait précisément à faire fonctionner un système commun sans inventer un propriétaire unique.

Sources