Deliverable A meeting report that outlines our current thinking about Private PlanetLabs and Federation. Private PlanetLabs: Opportunities and Challenges Todo –Pound out an outline (this afternoon) –Distribute paragraph generation (tonight & tomorrow)

Framework Questions What is PlanetLab? –Operational system, software package (platform), arch, community model What role PLC? –Ops, core development, specs, integration Community –Innovating on top of PL –Contributing to PL itself enablers: stable interfaces, myPLC, documentation) Goals –Scale (parallelize/amplify PLC) –Enable community

Why? Private PlanetLab –Enable customization –Localization Funding Policies Isolation Safe testing –Solve local problems Distr. Virtualization Deploy services for local users Federate –Scale ops Private regional + fed –Need more resources (cycles + net effect) Join community (peers) Buy from providers –Access to services Users, not just developers –Altruism

Risks Divergent platform (harder to code to) Divergent policies (prohibits certain slices) Fragmented from user’s perspective (harder to secure needed resources)

Strategy to Mitigate Risks Keeping common architecture makes federation is technically feasible Keeping common code base lessens code diversity risk Keeping common ops base lessens fragmentation risk (inter-NOC) Keeping common policy lessens fragmentation risk (shared AUP) Keep incentives in mind (market-based)

Software Development Issues Types –Bug fixes –Generalizations (enable new capabilities) –Specializations/Enhancements (new capabilities) Model –Patches / developer access (BSD model) Limited by build/QA process –Borrows from Linux model “Linus” decides (colored by operational requirements) Intermediate testers/integrators (private planetlabs) Well-known long-term architectural vision –Borrows from Amazon: Continuous release (node groups) Sync’ing (upgrading) private PlanetLabs

Operational Support Issues Training –Mgmt people (Best Practices) –User Education (and help desk) Inter-NOC coordination 3rd Party Management Services –Stork, CoBlitz, CoMon… Sync’ing with PLC w/out disruption

Technical Challenges PlanetLab/Cluster integration –Slice gets VM from the cluster –Slice gets a substantial chunk of the cluster Slice a wireless access point Slice a “gateway” to the Internet (e.g., BGP) Feed “live” PL measurements into Emulab Performance –Hardware-assist –Kernel mods

Technical Challenges (cont) Scheduling to support low-jitter services Generalize RSpec/NM –Alternative VM types (e.g., Xen) –Richer node types (e.g., ns -> XML) Service composition –Dependencies across federated PLs

Friday’s Agenda Source code base (Mark) Clusters (Marc) Lists –6-12 month todo list (PLC and elsewhere) Ops Code Arch/Documents –Wish list (longer term)

Extra Slides Follow

Discussion Points Motivation/Rationale Process-related issues –Software Development –Operational Support –Federation Technical Challenges

More details on “Why” slide Grow public PlanetLab –Scale operations beyond a single PLC –Make more aggregate resources available Internationalization –Accommodate different policies –Can get funding from local sources Manage distributed machines –Common point-of-pain w/ minimal “public PL” impact –Pair-wise peering will naturally follow new communities spring up Specializing/Extending –Researchers want a playground Deploying useful services in new environs

Federation Issues Refine the architecture/interfaces Peering agreements –Right resource control/allocation knobs –AUP Transitioning to independent MAs/SAs Common (seamless) user experience Internationalization –Membership agreement –Differing AUPs