PlanetLab Architecture Larry Peterson Princeton University

Roadmap Yesterday –Code + Design Principles Today –Defined Architecture + Standardization Process Tomorrow –Clusters –Federation –ISP (overlays on layer 2 networks)

Meta-Issue Reference Model –describes PlanetLab-like systems Architecture –narrow waist (universal agreement) –by convention Implementation –what we happen to run today –alternatives possible tomorrow

Owner 1 Owner 2 Owner 3 Owner N... Slice Authority Management Authority Software updates Auditing data Create slices... U S E R S PlanetLab Nodes Service Providers Request a slice New slice ID Access slice Identify slice users (resolve abuse) Learn about nodes Principals

Architectural Elements Node MA NM + VMM node database Node Owner VM SCS SA slice database VM Service Provider

Architecture vs Implementation Linux: implementation –well-defined VM types (default on all nodes?) –VM template (keys, bootscript) Node Manager: narrow waist –VMM-specific implementation of common interface (rspec) –stacked vs flat? pl_conf: architecture by convention –supports remote interface/protocol (ticket) –depends on name space for SAs (narrow waist) PLC-as-MA: implementation –independent MAs real soon now –share fate for foreseeable future PLC-as-SA: implementation –advantage of common slice authority –decouple naming from slice creation

PlanetLab Compliant Node –support node manager interface –pl_conf (accepts PLC-as-SA tickets) –at least one known VM type (base type?) –owner VM to make root allocation decision (ops on NM) –audit service Management Authority –secure boot –audit service –responsive support team Slice Authority –creates slices and/or returns tickets –auditing capability

Breakout Session Questions Group C’s notes

Questions 1.What challenges do we face in extending PlanetLab to support: –clusters –autonomous regions (e.g., EU, Japan) –private PlanetLabs 2.What is the solution space for these problems? 3.How do these solutions affect the PlanetLab architecture? 4.What roadmap gets us to where we want to be without breaking anything?

Challenges (1) Requires IP address per node (in the DB) –Have to NAT on shared machines –Mobility Node Owner - what’s the interface? –Keep resources private –Fine-grain control for exceptional cases –Enable select services the owner wants to run –Enable “side agreements” Opportunistically exploit available capacity –Desktops –Unused cluster nodes –Perhaps largely motivated by private PL’s (Condor) Value is providing a consistent base level (the VM) –Users may want to name sites, not nodes Provide incentives to make more nodes available public PL –Dedicated machines –Opportunistic nodes (from cluster)

Challenges (2) When private and public PL meet… –Private VMs come and go on short notice –Policy/usage problems (PL currently in DMZ) –Clusters easier than desktops Sometimes public and sometimes private Runs slices from both local and public SA Owner has to be able to specify how much to commit to each Need incentives to provide resources to public PL Private vs Regional –One public PL and many Private PLs, all federating –Who manages a site’s public nodes? Public MA if dedicates nodes (e.g., PLC continues to manage) –Owner retains right to make root resource allocation decision –Sites may be happy to let PLC manage their nodes (business model!) Private MA if exploiting a dynamic setting (e.g., cluster) –In the limit PLC manages no nodes (just a public research SA) –PLC needs to learn set of available nodes (MA has an interface to export) Some ISP-like entity manages the nodes on a set of sites’ behalf

Challenges (3) Incentives –Markets –Policies (short-term fixes) Change node-to-slice ratio –Measure aggregate cpu/net usage (course grained) »Account for benefit provided to the local site (true cost) »Account for free bandwidth (e.g., Internet2) –Contribute additional nodes and additional bandwidth –Risk: reigning in heavy users causes light users to contribute less –May need exchange rate between bw and cpu… markets Mandate use of admission control at crunch time –Could be an exception to the Allow site-specific “side” agreements –Public PL is just one “side” agreement –PLC can’t mediate all side agreements (implementation limit) A new SA could mediate side agreements between a set of sites –Other consortiums form (virtual organizations)

Challenges (4) Wireless –Multiple interfaces (not unique to wireless) –Schedule in time since not virtualizable at MAC level –Incentives to provide access to unique capability (e.g., WiMax) Side agreements with other wireless sites Fold into the incentive mechanism –Flea market for virtual organizations Management as system scales –Help sites better manage their nodes (be more responsive) –Generally, need better management tools (at PLC too)