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

RRest of the InternetMy Network

UntrustedTethered

High LatencyHigh BW

High PowerDiffServ

TrustedWirelessLow LatencyLow BWLow PowerIntServ

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

N3

N4

Nm

N1

N2

.

.

.

Agent Broker

.

.

.

.

.

.

candidates

reserve

description

ticket

description

desc

riptio

n

acquireticket lease

ServiceManager

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

CombinedIsolation andApplicationInterface

+ 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

ApplicationInterface

IsolationInterface- 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 overlaysProblem: Overlays perform redundant tasks

23

SONA

Internet

Over Time: Common base services emergeThey 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– 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

28

More Information

pl-web1.nbgisp.com