Upload
ambrose-crawford
View
218
Download
0
Embed Size (px)
Citation preview
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
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
22
SONA
Internet
New Model: Applications subscribe to service overlaysProblem: Overlays perform redundant tasks
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