1 / 40

GENI Design Document 05-02 presented by Park HoSung

Overcoming Barriers to Disruptive Innovation in Networking. GENI Design Document 05-02 presented by Park HoSung. Introduction. Why are researchers proposing large scale projects to develop and discover alternatives to today’s Internet?

jarvis
Download Presentation

GENI Design Document 05-02 presented by Park HoSung

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related