Transcript Document
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. 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 a TIFF (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 National LambdaRail Seattle Clev Chicago Denver Sunnyvale New York Pitts KC Wash DC Raleigh LA Phoenix Albuq. Tulsa San Diego Atlanta Dallas Jacksonville El Paso Las Cruces Pensacola San Ant. Houston Baton Rouge • 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 Node Mgr Local Admin VM1 VM2 … VMn Virtual Machine Monitor (VMM) Extending Slices to NLR Extending Slices to NLR NLR + PlanetLab User Opt-in Client NAT Server Another View NLR wavelength NLR optical switch Internet Per-Node View (NLR) Node Mgr Local Admin VR1 VR2 … Router Substrate (RS) 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