1 A Blueprint for Introducing Disruptive Technology into the Internet Larry Peterson Princeton University / Intel Research

2 Claims Network/Application distinction is blurring –pressure to move intelligence into the network Full integration will result in a new –service-oriented network architecture However… –the Internet is increasingly ossified

3 Take 1: Extensible Routers Local (node-centric) perspective Motivating examples –discontinuity at assumption boundaries –e.g., trust, performance, address space,… Additional factor –emerging hardware –e.g., network processors Goals –extend router with new services –achieve robust performance on diverse hardware

4 R Rest of the Internet My Network Untrusted Tethered High Latency High BW High Power DiffServ Trusted Wireless Low Latency Low BW Low Power IntServ Assumption Boundary

5 Take 1: Extensible Routers Local (node-centric) perspective Motivating examples –discontinuity at assumption boundaries –e.g., trust, performance, address space,… Additional factor –emerging hardware –e.g., network processors Goals –extend router with new services –achieve robust performance on diverse hardware

6 Take 2: PlanetLab Global (network-wide) perspective Motivating examples –geographically distributed services (e.g., DHT, CDN) –network measurement and anomaly detection Fundamental advantages –latency (proximity) –multi-lateralization –decentralized control

7 Overlay Network 1000 viewpoints on the network includes both edge sites and network crossroads

8 Dual Roles Research testbed –large set of geographically distributed machines –diverse & realistic network conditions Deployment platform –services: design  evaluation  client base –nodes: proxy path  physical path

9 Design Principles Slice-ability (distributed virtualization) Distributed Control of Resources Unbundled Management Application-Centric Interfaces

10 Slice-ability Each service runs in a slice of PlanetLab –distributed set of resources (network of virtual machines) –allows services to run continuously VM monitor on each node enforces slices –limits fraction of node resources consumed –limits portion of name spaces consumed Issue: global resource discovery –how do applications specify their requirements? –how do we map these requirements onto a set of nodes?

11 Distributed Control of Resources At least two interested parties –service producers (researchers)  decide how their services are deployed over available nodes –service consumers (users)  decide what services run on their nodes At least two contributing factors –fair slice allocation policy  both local and global components (see above) –knowledge about node state  freshest at the node itself

12 Unbundled Management Partition management into orthogonal services –resource discovery –monitoring node health –topology management –manage user accounts and credentials –software distribution Issues –management services run in their own slice –allow competing alternatives –engineer for innovation (define minimal interfaces)

13 Application-Centric Interfaces Inherent problems –stable platform versus research into platforms –writing applications for temporary testbeds –integrating testbeds with desktop machines Approach –adopt popular API (Linux) and evolve implementation –eventually separate isolation and application interfaces –provide generic “shim” library for desktops

14 Growth Strategy Phase0: Seeding the testbed –100 centrally managed machines –pure testbed (no expected client workload) Phase1: Scaling up the testbed –grow to 1000 nodes with user-provided hardware –continuously running services (researchers as clients) Phase2: Cultivating a user community –non-researchers as clients –PlanetLab spinoffs interpreted as success

15 Dynamic Slice Creation N3N3 N4N4 NmNm N1N1 N2N AgentBroker candidates reserve description ticket description acquire ticket  lease Service Manager

16 Virtual Machines Security –prevent unauthorized access to state Familiar API –forcing users to accept a new API is death Isolation –contain resource consumption Performance –don’t want to be apologetic

17 VMM: Short-term Plan Hardware Linux Vserver Service 1 Vserver Service 2 Vserver Service 3 Vserver Service 4 Vserver Service n Combined Isolation and Application Interface + Resource Isolation + Safe Raw Sockets + Instrumentation

18 VMM: Long-term Plan Hardware Isolation Kernel Linux Service 1 Linux Service 2 XP Service 3 BSD Service 4 Linux Service n Application Interface Isolation Interface - Denali - Xenoserver

19 VM Experiences Security –the kernel is the least of our worries Programming Interface –how many do we really need? Isolation –bandwidth today, but memory soon Performance –pressure to add capabilities to the kernel

20 SONA Revisited How does the network architecture evolve? Is the Internet experience applicable? Overlays  Internet as Internet  Phone System

21 SONA Internet Today: Internet offers a single service model

22 SONA Internet New Model: Applications subscribe to service overlays Problem: Overlays perform redundant tasks

23 SONA Internet Over Time: Common base services emerge They expose rich interfaces

24 SONA Internet Eventually: Popular behavior subsumed into the Internet

25 Routing/Topology Service Example of how the process might evolve… –each service independently discovers a topology –shared topology probing mechanism  e.g., Scriptroute –share topology information across layers  e.g., BGP feed from the Internet –a set of common sub-services emerge  for a given node, tell me who’s nearby  for a given node pair, tell me the routes between them –and the winner is…

26 Performance Separate the Control and Data Planes –PlanetLab defines a VM for a new control plane –extensible router defines a VM for the data plane –a new control/data interface emerges

27 Who Architecture Team –Larry Peterson (Princeton), David Culler (Berkeley), Tom Anderson (Washington), Timothy Roscoe (Intel), Frans Kaashoek (MIT) Implementation Team Intel and Princeton Contributing Community –VMM: Hand (Cambridge), Gribble (Washington) –DHT: Stoica (Berkeley), Druschel (Rice), Morris (MIT) –Resource Brokers: Vahdat (Duke), Wroclawski (MIT) –Applications: Pai (Princeton), Hellerstein (Berkeley) User Community: dozens of 40+ sites

28 More Information pl-web1.nbgisp.com