Overcoming Barriers to Disruptive Innovation in Networking GENI
Overcoming Barriers to Disruptive Innovation in Networking GENI Design Document 05 -02 presented by Park Ho. Sung April 28 th, 2009 1
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 April 28 th, 2009 2
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 April 28 th, 2009 3
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. April 28 th, 2009 4
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 April 28 th, 2009 5
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 April 28 th, 2009 6
Future Internet • We need changes in Internet • Two approaches – Incrementally evolve the network – Create a new Internet architecture April 28 th, 2009 7
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 April 28 th, 2009 8
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 April 28 th, 2009 9
But • Short term solutions are expedient but eventually harmful • Inability to adapt to new requirement • New uses and abuses make Internet different from original design • We have to create a new Internet – In an intentional way rather than by accident April 28 th, 2009 10
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. April 28 th, 2009 11
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 April 28 th, 2009 12
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 April 28 th, 2009 13
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 April 28 th, 2009 14
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 April 28 th, 2009 15
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 April 28 th, 2009 16
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 April 28 th, 2009 17
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 -99 XX-1 XXX April 28 th, 2009 Current IP HIP 18
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) April 28 th, 2009 19
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 April 28 th, 2009 20
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 April 28 th, 2009 21
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 April 28 th, 2009 22
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 April 28 th, 2009 23
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 April 28 th, 2009 24
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 April 28 th, 2009 25
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? April 28 th, 2009 26
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 April 28 th, 2009 27
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 April 28 th, 2009 28
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 April 28 th, 2009 29
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 April 28 th, 2009 30
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 April 28 th, 2009 31
Testbed • allocate resources to slices • slices must not interfere with each other April 28 th, 2009 32
Testbed Design Principle • Service/Architecture neutrality • End-system diversity • Ease of user access • Sustainability and incentives • Inter-slice composition • Policy and governance April 28 th, 2009 33
Departure Point • Planet. Lab – node virtualization – global resource management – research in networ services • X-bone, 6 -bone – core capabilities for network virtualization – supported by multiple OS April 28 th, 2009 34
Departure Point • Emulab, Netbed – allocate and configure heterogeneous end system resources and network resources together April 28 th, 2009 35
Recommendations • NSF should foster disruptive innovation in networking • move ideas into practice, rather than being satisfied with paper design April 28 th, 2009 36
Recommendations 1. Immediately initiate a research program on experimental architectural research in we need investment networking 2. Foster experimental validation of new architectural research in networking validation environment 3. Fund the development and deployment of suitable testbeds meta testbed April 28 th, 2009 37
Recommendations 4. Start a process that will lead to substantial increases in funding for a broad multidisciplinary effort in this area over the next few years multi-disciplinary effort 5. Find ways to promote synergy and convergence among architectural visions convergence rather than divergence 6. Help the community learn from industry interaction April 28 th, 2009 38
Conclusion • Disruptive innovation approach • meta testbed • reinvention of the wheel? It is worth to do April 28 th, 2009 39
Q&A Thank You April 28 th, 2009 40
- Slides: 40