The Global Communications Infrastructure: A Way Forward*

Tom AndersonUniversity of Washington

Larry PetersonPrinceton University

Scott ShenkerUC Berkeley / ICSI

Jonathan TurnerWashington University

*This effort funded in part by NSF planning grant CNS-0439842.

Challenges• Security

– Known vulnerabilities lurking in the Internet• DDoS, worms, malware

– Today’s 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

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 9’s of reliability between any pair of end points

• improve ease-of-use for non-expert users

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

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

Goals• Address known architectural limits

– security– reliability– performance– scalability

• Design for the future– evolvability– manageability

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

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)

PlanetLab

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

• 460 machines spanning 210 sites and 26 countries nodes within a LAN-hop of > 1M users

• Supports distributed virtualization each of 275 network services running in their own slice

Denver

Seattle

Sunnyvale

LA

San Diego

Chicago Pitts

Wash DC

Raleigh

Jacksonville

Atlanta

KC

Baton Rouge

El Paso - Las Cruces

Phoenix

Pensacola

Dallas

San Ant.Houston

Albuq. Tulsa

New YorkClev

National LambdaRail

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

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

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

Slices

Slices

Slices

Per-Node View

Virtual Machine Monitor (VMM)

NodeMgr

LocalAdmin

VM1 VM2 VMn…

Extending Slices to NLR

Extending Slices to NLR

NLR + PlanetLab

User Opt-inClient

ServerNAT

Another View

Internet

NLR wavelength

NLR optical switch

Per-Node View (NLR)

Router Substrate (RS)

NodeMgr

LocalAdmin

VR1 VR2 VRn…

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

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…

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

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

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