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