Overcoming the Internet Impasse through Virtualization

1. Overcoming the Internet Impasse through Virtualization Written by Thomas Anderson, Larry Peterson, Scott Shenker, Jonathan Turner IEEE Computer, April 2005 Presented by Eunsang Cho 2008. 09. 22.

2. Overview • Motivation and proposal of virtual testbed • Current approaches to evaluate new architecture • Physical testbeds • Overlays • Virtual testbeds • Basic components • Proxy, service hosting, quality of service • Inspiration, future plan • Deployment • Means or ends • Conclusion

3. Motivation • Today’s Internet is facing many challenges. • Internet’s increasing ubiquity and centrality has brought with it a number of challenges. • But, Internet is so successful. • It is hard to change its architecture. • This has led to an increasing number of ad hoc workarounds.

4. Impasse • Nevertheless, there seems little hope for major architectural changes – altering its basic architecture. • Impasse of the current Internet • Evaluation issue • Traditional testbeds have limitations. • Deployment issue • It is needed that an agreement of ISPs.

5. Overcoming the Impasse • Three separate requirements • Easy experiment with new architectures on live traffic • A plausible deployment path for putting validated architectural ideas into practice. • Comprehensive solutions, addressing the broad range of current architectural problems

6. Proposal • Virtual testbed • Supporting multiple simultaneous architectures • Serving all the communication needs of clients and servers • No need for universal architectural agreement • So more plausible scenario

7. Current Approaches • Simulation and emulation • Without live traffic • Physical testbeds • Overlays

8. Physical Testbeds • Production testbeds • Internet2 • Users have no choice about participating the experiment. Example of Internet2 – CalREN of CENIC

9. Physical Testbeds • Research testbeds • DETER (Defense Technology Experimental Research) • Lack of real traffic • Using synthetically generated traffic • Utilizing dedicated transmission links • Involves substantial cost DETER uses Emulab.

10. Overlays PlanetLab node architecture • PlanetLab • Advantages • Not limited geographically • Usage is voluntary • Not involve significant expenditures • Disadvantages • Overlays have been seen as a way to deploy narrow fixes to specific problems. • Overlays have been architecturally tame. • IP is assumed for the interoverlay protocol. • No dramatic architectural advancement. PlanetLab node distribution

11. Virtual Testbed • Two basic components • Overlay substrate • Set of dedicated but multiplexed overlay nodes • The effort for the overlay is amortized across the many concurrently running experiments. • Drastically lowering the barrier to entry that an individual researcher faces • Client-proxy mechanism • A host can use it to opt in to a particular experiment running on a specific substrate overlay. • It treats a nearby overlay node as the host’s first-hop router. • These two features resolve the barrier-to-entry and architectural limitations that overlays faced.

12. Virtual Testbed • Some issues to explore • PlanetLab nodes clearly cannot compete with custom hardware. • Achieving sufficiently high throughput rates on PlanetLab nodes is challenging. • Overlay’s Virtual links cannot compete with dedicated links.

13. Proxy • Either return the true IP address or fake IP address • For the fake IP addresses, the proxy can forward the packets to the nearest virtual testbed (VT) node, the ingress node. • The VT node can then do whatever it wants. • At the far end of the VT, the egress node reconverts the packet into Internet format for delivery to the server. • As a network address translater (NAT)

14. Service Hosting • Service hosting to the clients outside VT • VT provides DNS resolution. • Some security issues must be resolved. • How to respect server address-based policy restrictions when the overlay shields the source’s IP address

15. Quality of Service • Drawback • VT cannot control the quality of service (QoS) for packets traversing the virtual testbed. • However, it is not a fatal flaw. • Relative QoS • Simulation and emulation can effectively evaluate QoS. • Many other issues that involve routing and addressing warrant more urgent attention and better suit the VT approach.

16. Inspiration • Ideas from • X-Bone • VT uses suite of tools supporting automated establishment and management of overlays. • The virtual Internet • Allows multiple levels of virtualization • But it remains closely tied to the current Internet architecture. • But different emphasis • VT focuses the virtualization of overlay nodes themselves. (vs. X-Bone) • VT does not tied to current Internet, it aims radically different architectures. (vs. virtual Internet)

17. Future Plan • A high-perfomance backbone • Using dedicated MPLS tunnels on Internet2 • A set of scalable substrate routers and links provided through the National LambdaRail (NLR) National LambdaRail

18. Future Plan • Two major advantages of high-speed backbone with PlanetLab • PlanetLab-based overlays serve as an access network for the backbone, bringing traffic from a large user community on to the backbone. • Developing and deploying the hardware does not gate the architectural work.

19. Deployment • Traditional, discredited deployment • A next-generation architecture • Validation on a traditional testbed • Magical process of consensus and daring • Adopted by ISPs and router vendors alike

20. Deployment • New deployment alternative • A new-generation service provider (NGSP) chooses a new architecture. • NGSP constructs an overlay supporting that architecture. • NGSP distributes proxy software to access its overlay. • If overlay is successful, NGSP offers direct access or current ISPs begin to support this new architecture.

21. Deployment • Overlays offer an opportunity to radically change the architecture. • A single daring NGSP or long-running VT could accomplish this. • Seamless migration • Substantial advantage  attract more user  VT to dedicated • Collection of narrowly targeted overlay  coordination is needed.

22. Virtualization:Means or Ends • The virtual testbed approach uses virtualization in two ways. • Virtual links is equivalent to a native network. • This frees users from their local ISP. • Network providers no longer need to deploy new functionality at every node. • Multiplexing overlay nodes greatly reduces the barrier to entry for any particular experiment.

23. Virtualization:Means or Ends • Means • Architectural changes are rare. • Virtualization is means for architectural change. • Purist view • Architecture must have flexibility.

24. Virtualization:Means or Ends • Ends • Internet changes constantly, with many coexisting components. • Virtualization can play a central role to support many components and constant change. • Pluralist view • Flexibility derives from adding or augmenting overlays.

25. Conclusion • The canonical story of adopting new promising architecture evaluated by testbed experiments is no longer applies. • Narrow-focused research, empirical or incremental studies is insufficient to meet new Internet challenges. • Virtual testbed fosters a renaissance in applied architectural research that extends beyond incrementally deployable designs.