GENI Design Document 05-02 presented by Park HoSung

1. Overcoming Barriers to Disruptive Innovation in Networking GENI Design Document 05-02 presented by Park HoSung

2. Introduction • Why are researchers proposing large scale projects to develop and discover alternatives to today’s Internet? • As one of Internet surfers, I am satisfied with current Internet

3. Introduction • Phone system and the air traffic control system are available 99.999% of time • Internet is available 99.9% or less • Think about KAIST WLAN • Would you have tele-surgery over Internet? • And many other problems ... We need changes

4. Introduction • Network is so subtle • It is best understood through extensive live experiment • hard to experiment • We can’t validate proposed solutions. • We need a well-made testbed.

5. What is GENI? • Global Environment for Network Innovations • experimental suite for Network Science and Engineering experiments • enhances experimental research in networking and distributed systems • gives opportunity to experiment without fixed assumptions or requirements at a large scale with real user population

6. What is this paper? • Report of NSF workshop • Overcoming Barriers to Disruptive Innovation in Networking • Not a conference paper. It’s a report • Result of participants’ consideration • Not a solution. It’s an opinion • It will be a descriptive presentation without explicit solutions

7. Future Internet • We need changes in Internet • Two approaches • Incrementally evolve the network • Create a new Internet architecture

8. Incremental evolution • Followed this path for nearly 30 years • so many patches • point-solutions result in increased complexity • step outside original Internet architecture • Remember spaghetti codes in young days

9. Pessimism about Innovation • Modifications to routers and host SW • Hard to reach consensus among ISPs • Lack of incentives for deployments • Costs for upgrading the infrastructure

10. But • Short term solutions are expedient but eventually harmful • Inability to adapt to new requirement • New uses and abuses make Internet different fromoriginal design • We have to create a new Internet • In an intentional way rather than by accident

11. Outcome possibility • From multiple new architectures → convergence on a single architecture → no consensus → ideas can be applied to today’s Internet • Who knows? • But It will not harmful in any case.

12. Lessons from current Internet • Minimize trust assumptions • view traffic as adversarial, not friendly • Enable user choice • consider competition and economic incentives • Allow for edge diversity • sensors and mobile devices • Design for network transparency • worth to do for users and administrators • Meet application requirements • Add functionality to the network

13. Security • Network traffic must be viewed as adversarial rather than cooperative • Solve security problem in Internet itself • Make Internet trustworthy • critical infrastructure • commerce, education, personal productivity

14. Security Approaches • Prevent denial of service by allowing a receiver to control who can send packets to it • Make firewalls a fully recognized component of the architecture

15. Economic Incentives • Lack of an overall architectural framework for flow of payments • barrier to future investment in the Internet • barrier to the overall economic health • Use user’s choice • competition on the players • Make the direction of payment flow explicit

16. Address Binding • A way in which nodes are identified to direct traffic toward them • Tight coupling between IP address and end hosts during 20 years • used not only as a routing locator but also as a host identifier • Problems occur when end hosts move

17. Current Address Binding • Mobile IP • inefficient forwarding mechanism • For expediency • End hosts change IP addresses each time they move • We need to remove the coupling between location and identity

18. Address Binding Approach • Topology independent identifier • HIP (Host Identity Protocol) • provides each end host with a cryptographically secure identifier • IP address is ephemeral locator to route connect to 011-99XX-1XXX connect to HIP Current IP

19. End Host Assumptions • Traditional assumptions • usually connected • don’t move very often • identified by static names (addresses) • connected for instantaneous communications • Problems • mobile nodes • long delay (poorly and intermittently connected)

20. End Host Assumptions Approaches • Sensor overlay • allows a set of agents to recreate schemes top of Internet connectivity • Delay tolerant overlay • being developed by the DTN project

21. User-level Route Choice • Routing in an opaque manner • user can’t express the choice • If we can choose routes • improvement of availability and performance • need to • resolve the conflicts between the preferences of multiple users and of the ISPs

22. Control and Management • Operational complexity plagues today’s Internet • decision making logic and data plane are tightly coupled • forces point solutions to be invented • complexity increased

23. Control and Management Approaces • Separate control logic from data plane • What if market considers opaqueness a feature rather than a limitation • market wants to hide everything • needs to consider how to enforce that transparency

24. Meeting Application Requirements • narrow-waisted hourglass model • a minimal and carefully chosen set • high and low level technologies can coexist • evolve rapidly • demands of new application cannot be met

25. Meeting Application Requirements Approaches • widen the waist of the hourglass • additional functionality in core forwarding service • dominating research for 10 years • risk to the stability and coherence of the Internet architecture

26. Meeting Application Requirements Approaches • add a layer to the architecture (overlay) • move functionality from infrastructure to multiple overlays • construct with application-level requirement in mind • unanswered question • what is the universally shared environment to support overlays?

27. Meeting Application Requirements Approaches • move the narrow waist to a lower level of the protocol stack • contains a collection of physical resources • virtualization is a key feature • IP would become just one of many network architecture

28. Testbed • enable to create, deploy, evaluate novel architecture • must run at scale • carry real user and traffic • meta testbed • host a heterogeneous collection of testbeds

29. Overlay and Virtualization • seeds of hope • architectural innovation • effective and inexpensive • large scale live experimentation • commercial overlay hosting lowers entrance barrier • recall web hosting service

30. Testbed • multiple network architecture and services • as few restriction as possible • include a diversity of links and nodes • connection of arbitrary edge devices • bridge between production testbed and research testbed

31. Testbed Key Concepts • Links • physical links, MPLS paths, IP tunnels • nodes • provide collection of memory, processing and storage resources (VM or dedicated M) • edge devices • participate in multiple networks • slice • substrate resources bound to a particular experimental network

32. Testbed • allocate resources to slices • slices must not interfere with each other

33. Testbed Design Principle • Service/Architecture neutrality • End-system diversity • Ease of user access • Sustainability and incentives • Inter-slice composition • Policy and governance

34. Departure Point • PlanetLab • node virtualization • global resource management • research in networ services • X-bone, 6-bone • core capabilities for network virtualization • supported by multiple OS

35. Departure Point • Emulab, Netbed • allocate and configure heterogeneous end system resources and network resources together

36. Recommendations • NSF should foster disruptive innovation in networking • move ideas into practice, rather than being satisfied with paper design

37. Recommendations • Immediately initiate a research program on experimental architectural research in networking • Foster experimental validation of new architectural research in networking • Fund the development and deployment of suitable testbeds we need investment validation environment meta testbed

38. Recommendations • Start a process that will lead to substantial increases in funding for a broad multi- disciplinary effort in this area over the next few years • Find ways to promote synergy and convergence among architectural visions • Help the community learn from industry multi-disciplinary effort convergence rather than divergence interaction

39. Conclusion • Disruptive innovation approach • meta testbed • reinvention of the wheel? It is worth to do

40. Q&A Thank You