1 / 20

PlanetLab: a Petri dish for the next Internet

PlanetLab: a Petri dish for the next Internet. Timothy Roscoe Intel Research at Berkeley. What is PlanetLab?. An open, shared testbed for Developing Deploying Accessing - planetary-scale services. What would you do if you had Akamai’s infrastructure?. Motivation.

pamelia-asker
Download Presentation

PlanetLab: a Petri dish for the next Internet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PlanetLab: a Petri dish for the next Internet Timothy Roscoe Intel Research at Berkeley

  2. What is PlanetLab? • An open, shared testbed for • Developing • Deploying • Accessing - planetary-scale services. What would you do if you had Akamai’s infrastructure? PlanetLab

  3. Motivation • New class of applications emerging that spread over sizable fraction of the web • Architectural components starting to emerge • The next Internet will be created as an overlay on the current one • It will be defined by services, not transport • There is NO vehicle to try out the next n great ideas in this area PlanetLab

  4. Guidelines (1) • Thousand viewpoints on “the cloud” is what matters • not the thousand servers • not the routers, per se • not the pipes PlanetLab

  5. Guidelines (2) • and you must have the vantage points of the crossroads • co-location centers, peering points, etc. PlanetLab

  6. Guidelines (3) • Each service needs an overlay covering many points • logically isolated • Many concurrent services and applications • must be able to slice nodes => VM per service • service has a slice across large subset • Must be able to run each service / app over long period to build meaningful workload • traffic capture/generator must be part of facility • Consensus on “a node” more important than “which node” PlanetLab

  7. Guidelines (4) • Test-lab as a whole must be up a lot • global remote administration and management • redundancy within • Each service will require own management capability • Testlab nodes cannot “bring down” their site • not on forwarding path • Relationship to firewalls and proxies is key PlanetLab

  8. Guidelines (5) • Storage has to be a part of it • edge nodes have significant capacity • Needs a basic well-managed capability • Initial ‘core’ of ~100 stable, supported sites. • May grow to less managed contributors in time PlanetLab

  9. Initial core team: Intel Research: David Culler Timothy Roscoe Brent Chun Mic Bowman Princeton: Larry Peterson Mike Wawrzoniak University of Washington: Tom Anderson Steven Gribble See website for all the rest… PlanetLab

  10. Brazil Some signed-up Planet-Lab Sites Uppsala UBC Copenhagen UW Cambridge WI Chicago UPenn Amsterdam Harvard Utah Intel Seattle Karlsruhe Tokyo Intel MIT Intel OR Beijing Barcelona Intel Berkeley Cornell CMU ICIR Princeton UCB St. Louis Columbia Duke UCSB Washu KY UCLA GIT Rice UCSD UT ISI Canterbury Melbourne PlanetLab

  11. Implementers and Users • PlanetLab community seems to divide into two groups at this stage: • Folks who want to build this • Folks who want to use this • Both have diverse and promising research agendas PlanetLab

  12. Implementation Research Issues • Sliceability: distributed virtualization • Isolation and resource control • Security and integrity: exposed machines • Management of a very large, widely dispersed system • Instrumentation and measurement • Building blocks and primitives PlanetLab

  13. Confluence of Technologies • Cluster-based management • Overlay and P2P networks • Virtual machines and sandboxing • Service composition frameworks • Internet measurement • Packet processors • Colo services • Web services  The time is now. PlanetLab

  14. Emerging applications • Content distribution • Peer-to-Peer networks • Global storage • Mobility services • Etc. etc. Vibrant research community embarking on new direction and none can try out their ideas. PlanetLab

  15. Overlapping Phases of Development 2003 2004 2005 0: seed 1: get API & interfaces right 2: get underlying arch. and impl. right PlanetLab

  16. Development trajectory • Node operating system • Start with Linux • Add isolation and resource management • Controlled access to raw sockets • Create new “thin” VMM API • Eventually, invert the APIs • Distributed components • Will run in slices on the platform • Community will be enlisted to contribute PlanetLab

  17. The Plan • Intel Research is seeding the effort • Success: adoption and growth of the research community and creation of novel network services • Bring in NSF, Darpa, industry partners • Create a non-profit or consortium to manage PlanetLab by late 2004 • PlanetLab takes on a life of its own • Services define the next Internet • Organization manages the central core PlanetLab

  18. What PlanetLab will enable: • Open infrastructure for next generation of wide-area (“planetary-scale”) services • Foundation on which the next Internet can emerge • Think beyond TCP/IP/BGP/DNS/etc. • Different kind of network testbed • Focus and mobilize the Network / Systems research communities to define the emerging Internet. PlanetLab

  19. Current status • Sites coming up each week • Second “underground” meeting in August (SIGCOMM) • Website and lists online http://www.planet-lab.org/ PlanetLab

  20. What can YOU do for PlanetLab? • Be a part of the design process • As designers, look at the platform architecture • As users, participate in defining the requirements • We are looking for all the input we can get. PlanetLab

More Related