1
GENI Design Document 05-02
presented by Park HoSung
Overcoming Barriers to
Disruptive Innovation in Networking
April 28th, 2009
2
Introduction• Why are researchers proposing large
scale projects to develop and dis-cover alternatives to today’s Inter-net?
• As one of Internet surfers, I am satis-fied with current Internet
April 28th, 2009
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 changesApril 28th, 2009
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.April 28th, 2009
5
What is GENI?• Global Environment for Network Innovations
– experimental suite for Network Science and En-gineering experiments
• enhances experimental research in network-ing and distributed systems
• gives opportunity to experiment without fixed assumptions or requirements at a large scale with real user population
April 28th, 2009
6
What is this paper?• Report of NSF workshop
– Overcoming Barriers to Disruptive Innovation in Net-working
• 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 ex-plicit solutions
April 28th, 2009
7
Future Internet• We need changes in Internet
• Two approaches
– Incrementally evolve the network
– Create a new Internet architecture
April 28th, 2009
8
Incremental evolution• Followed this path for nearly 30 years– so many patches– point-solutions result in increased com-
plexity– step outside original Internet architecture
• Remember spaghetti codes in young days
April 28th, 2009
9
Pessimism about Innova-tion
• Modifications to routers and host SW
• Hard to reach consensus among ISPs
• Lack of incentives for deployments
• Costs for upgrading the infrastruc-ture
April 28th, 2009
10
But• Short term solutions are expedient but even-
tually 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 28th, 2009
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.
April 28th, 2009
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
April 28th, 2009
13
Security• Network traffic must be viewed as
adversarial rather than cooperative
• Solve security problem in Internet it-self
• Make Internet trustworthy– critical infrastructure– commerce, education, personal produc-
tivityApril 28th, 2009
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
April 28th, 2009
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
April 28th, 2009
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 moveApril 28th, 2009
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 be-tween location and identity
April 28th, 2009
18
Address Binding Ap-proach
• Topology independent identifier– HIP (Host Identity Protocol)• provides each end host with a cryptographi-
cally secure identifier• IP address is ephemeral locator to route
April 28th, 2009
connect to
011-99XX-1XXX
connect to
Current IP HIP
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)
April 28th, 2009
20
End Host Assumptions Ap-proaches
• Sensor overlay – allows a set of agents to recreate
schemes top of Internet connectivity
• Delay tolerant overlay– being developed by the DTN project
April 28th, 2009
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 multi-
ple users and of the ISPs
April 28th, 2009
22
Control and Management• Operational complexity plagues to-
day’s Internet
• decision making logic and data plane are tightly coupled– forces point solutions to be invented– complexity increased
April 28th, 2009
23
Control and Management Ap-proaces
• 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 28th, 2009
24
Meeting Application Require-ments
• narrow-waisted hourglass model
April 28th, 2009
• a minimal and carefully chosen set
•high and low level tech-nologies can coexist
• evolve rapidly
• demands of new applica-tion cannot be met
25
Meeting Application Requirements Ap-proaches
• widen the waist of the hourglass
April 28th, 2009
• 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 Ap-proaches
• 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 28th, 2009
27
Meeting Application Requirements Ap-proaches
• move the narrow waist to a lower level of the protocol stack
April 28th, 2009
• contains a collection of physical re-sources
• virtualization is a key fea-ture
• IP would become just one of many network architec-ture
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
April 28th, 2009
29
Overlay and Virtualiza-tion
• seeds of hope– architectural innovation
• effective and inexpensive
• large scale live experimentation
• commercial overlay hosting lowers entrance barrier – recall web hosting service
April 28th, 2009
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 re-search testbed
April 28th, 2009
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
April 28th, 2009
32
Testbed• allocate resources to slices
• slices must not interfere with each other
April 28th, 2009
33
Testbed Design Principle• Service/Architecture neutrality
• End-system diversity
• Ease of user access
• Sustainability and incentives
• Inter-slice composition
• Policy and governance
April 28th, 2009
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
April 28th, 2009
35
Departure Point• Emulab, Netbed– allocate and configure heterogeneous
end system resources and network re-sources together
April 28th, 2009
36
Recommendations• NSF should foster disruptive innova-
tion in networking
• move ideas into practice, rather than being satisfied with paper design
April 28th, 2009
37
Recommendations1. Immediately initiate a research pro-
gram on experimental architectural re-search in networking
2. Foster experimental validation of new architectural research in networking
3. Fund the development and deployment of suitable testbeds
April 28th, 2009
we need investment
validation environ-ment
meta testbed
38
Recommendations4. Start a process that will lead to substan-
tial increases in funding for a broad multi- disciplinary effort in this area over the next few years
5. Find ways to promote synergy and convergence among architectural visions
6. Help the community learn from industry
April 28th, 2009
multi-disciplinary ef -fort
convergence rather than divergence
interaction
39
Conclusion• Disruptive innovation approach• meta testbed
• reinvention of the wheel?
It is worth to do
April 28th, 2009
40
Q&A
Thank You
April 28th, 2009