The Global Communications Infrastructure: A Way Forward*

1
The Global Communications Infrastructure A Way
Forward
Tom Anderson University of Washington Larry
Peterson Princeton University Scott Shenker UC
Berkeley / ICSI Jonathan Turner Washington
University
This effort funded in part by NSF planning grant
CNS-0439842.
2
Challenges

• Security
• Known vulnerabilities lurking in the Internet
• DDoS, worms, malware
• Todays static architecture leads to patch-work
  fixes
• patches make the net harder to manage, more
  vulnerable
• spending 10-100B on security in 2004
• Need to
• change the architecture to deal with current
  threats
• make the architecture more elastic to deal with
  future threats

3
Challenges

• Reliability
• e-Commerce increasingly depends on fragile
  Internet
• much less reliable than the phone network
• risks in using the Internet for mission-critical
  operations
• barrier to ubiquitous VoIP
• Efforts to improve reliability step outside the
  architecture
• CDNs hide some failures from web surfers
• Need to
• provide more 9s of reliability between any pair
  of end points
• improve ease-of-use for non-expert users

4
Challenges

• Performance
• Scientists have significant bandwidth
  requirements
• each e-science community covets its own
  wavelength(s)
• Purpose-built solutions are not cost-effective
• being on the commodity path makes an effort
  sustainable
• Need to
• architect a general-purpose solution that
  provides bandwidth potential of underlying
  hardware to end-to-end users
• architect a solution exploits aggregate capacity

5
Challenges

• Scalability
• The whole world is becoming networked
• sensors, consumer electronic devices, embedded
  processors
• Internet has built-in assumptions about hosts
• numbers, connectivity, capabilities
• host-centric rather than data-centric
• Need to
• extend the architecture to accommodate dramatic
  growth
• extend the architecture to accommodate increased
  heterogeneity

6
Goals

• Address known architectural limits
• security
• reliability
• performance
• scalability
• Design for the future
• evolvability
• manageability

7
Barriers

• Internet has become ossified
• no competitive advantage to architectural change
• encourages ad hoc solutions that makes more
  brittle
• no obvious deployment path, even if we knew what
  to do
• Inadequate validation of potential solutions
• simulation models too simplistic
• little or no real-world experimental evaluation
• Testbed dilemma
• production testbeds real users but incremental
  change
• research testbeds radical change but no real
  users

8
Why Now?

• Active research community
• scores of architectural proposals
• ready to step up to the challenge of making it
  real
• Enabling technologies
• OS virtualization and interposition mechanisms
• overlay networks are maturing
• high-speed data pipes in the core
• fast network processors and FPGAs
• Infrastructure exists
• PlanetLab
• National Lambda Rail (NLR)

9
PlanetLab

• 460 machines spanning 210 sites and 26 countries
• nodes within a LAN-hop of gt 1M users
• Supports distributed virtualization
• each of 275 network services running in their
  own slice

10
National LambdaRail

• 10Gbps per-lambda
• Lambdas set aside for network research

11
Next Step Virtual Testbed

• Goals
• support experimental validation of new
  architectures
• simultaneously support real users and clean slate
  designs
• allow a thousand flowers to bloom
• provide plausible deployment path
• Key ideas
• virtualization
• multiple architectures on a shared infrastructure
• shared management costs
• opt-in on a per-user / per-application basis
• attract real users
• demand drives deployment / adoption

12
Virtual Testbed

• Infrastructure
• PlanetLab provides access network with global
  reach
• user desktops run proxy that allows them to
  opt-in
• treat nearby PlanetLab node as ingress router
• NLR provides high-speed backbone
• populate with programmable routers
• extend slice abstraction to these routers
• Usage model
• each architecture (service) runs in its own slice
• two modes of use
• short-term experiments
• long-running stable architectures and services

13
Slices
14
Slices
15
Slices
16
Per-Node View
Node Mgr
Local Admin
VM1
VM2
VMn

Virtual Machine Monitor (VMM)
17
Extending Slices to NLR
18
Extending Slices to NLR
19
NLR PlanetLab
20
User Opt-in
Client
Server
NAT
21
Another View
NLR wavelength
NLR optical switch
Internet
22
Per-Node View (NLR)

• Processing Engine(s)
• COTS PC
• Network Processor
• FPGA

Node Mgr
Local Admin
VR1
VR2
VRn

Router Substrate (RS)
23
Deployment Story

• Old model
• global up-take of new technology
• does not work due to ossification
• New model
• incremental deployment via user opt-in
• lowering the barrier-to-entry makes deployment
  plausible
• Process by which we define the new architecture
• purists settle on a single common architecture
• virtualization is a means
• pluralists multiplicity of continually evolving
  elements
• virtualization is an ends
• What architecture do we deploy?
• research happens

24
Architectural Thrusts

• Built-in security
• worm and virus containment, DDoS prevention,
• Knowledge/Information/Decision Plane
• managability, fault anomaly diagnosis,
  reliability,
• Network service infrastructure
• functionality, evolvability, reliability,
  heterogeneity,
• Naming and Addressing
• mobility, ease-of-use, reliability,
  evolvability,
• Global sensor network
• scalability, heterogeneity, mobility,
• e-Science infrastructure
• performance, managability, ease-of-use,

25
Summary

• Internet faces many architectural challenges
• Significant barriers have choked innovation
• ossification resists change
• research cannot be adequately validated
• We have an opportunity to act now
• many architectural ideas
• research community is willing to make it real
• necessary infrastructure and technology is
  available
• We have a plan to move forward
• opt-in / experiment-to-deployment testbed

26
Recommendations

• Build the virtual testbed
• leverage and extend PlanetLab
• initiate development of router substrate hardware
• formalize an agreement with NLR
• Fund an NSF program to design new architectures
• initially targeted at networking research
  community
• include incentives to foster consolidation
• Create larger inter-agency initiative
• broaden the community include application
  domains
• deepen the effort produce a real/usable artifact