A Blueprint for Introducing Disruptive Technology into the Internet

Larry Peterson Princeton University / Intel Research 1

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 2

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 3

Assumption Boundary

Rest of the Internet R Untrusted Tethered High Latency High BW High Power DiffServ Trusted Wireless Low Latency Low BW Low Power IntServ

My Network

4

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 5

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 6

Overlay Network

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

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 8

Design Principles

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

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?

10

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 11

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) 12

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 13

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 14

Dynamic Slice Creation

N 1 N 2 N 3 N 4 .

.

.

N

m

acquire ticket  lease

.

.

.

Agent

candidates

Broker

description ticket reserve

Service Manager .

.

.

15

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 16

VMM: Short-term Plan

Service 1 Service 2 Service 3 Service 4 Vserver Vserver Vserver Vserver Service n Vserver Linux + Resource Isolation + Safe Raw Sockets + Instrumentation Hardware Combined Isolation and Application Interface

17

VMM: Long-term Plan

Service 1 Service 2 Service 3 Service 4 Linux Linux XP BSD Service n Linux Application Interface Isolation Kernel Hardware Isolation Interface

-

Denali

-

Xenoserver

18

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 19

SONA Revisited

• How does the network architecture evolve?

• Is the Internet experience applicable?

Overlays  Internet as Internet  Phone System 20

SONA

Internet

Today: Internet offers a single service model 21

SONA

Internet

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

SONA

Internet

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

SONA

Internet

Eventually: Popular behavior subsumed into the Internet 24

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… 25

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 26

Who

• Architecture Team – Larry Peterson (Princeton), David Culler (Berkeley), Tom Anderson (Washington), Timothy Roscoe (Intel), Frans Kaashoek (MIT) • Implementation Team – 4 @ Intel and 2+ @ 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 projects @ 40+ sites 27

More Information

pl-web1.nbgisp.com

28