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 • 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

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 9’s 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 > 1M users • Supports distributed virtualization • each of 275 network services running in their own slice

10. Seattle Clev Chicago New York Pitts Denver Sunnyvale KC Wash DC Raleigh Tulsa LA Albuq. Phoenix San Diego Atlanta Dallas Jacksonville El Paso - Las Cruces Pensacola Baton Rouge Houston San Ant. 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