Incrementally Deployable - PowerPoint Presentation

Slide1

Incrementally Deployable Information Centric Networking

1

Seyed K. Fayazbakhsh, Yin Lin, Amin Tootoonchian, Ali Ghodsi, Teemu Koponen, Bruce Maggs, KC Ng, Vyas Sekar, Scott Shenker

Slide2

Internet Service ModelThe network makes its best effort to deliver every datagram to the destination address specified in its header

Example address: 128.2.205.42

“the narrow waist of IP”2

Slide3

ICN Service ModelGiven a request for named content, the network attempts to locate and retrieve the content

Example request: retrieve DSAK832NSKAWKW282

Names may be bound to content cryptographically3

Slide4

Content Retrieval4

Equip network with content caches

ICN decouples

“what” from “where”

C

S1

S2

Bind content names to intent

Route based on content names

e.g., find nearest replica

C

C

e.g., CCN, DONA, NDN, 4WARD ….

Today:

1) Ask search engine for name of server holding object

2) Resolve name to network address of server

3) Send request for object to server

Slide5

This talk is not anti-ICN

I am not an opponent of ICN

5

Slide6

Benefits of deploying ICN

6

C

C

Lower latency

Reduced congestion

Support for mobility

Intrinsic security

e.g., CCN, DONA, NDN, 4WARD ….

Slide7

7

Difficulties

deploying ICN

C

C

Routers need to be

replaced to support content-based routing and to incorporate caches

e.g., CCN, DONA, NDN, 4WARD ….

Slide8

8

Motivation for this work

Lower latencyReduced congestionSupport for mobilityIntrinsic security

Can we get ICN gains without the pains?e.g., existing technologies? e.g., incrementally deployable?

Benefits

Difficulties

Routers need to be replaced to support content-based routing and to incorporate caches

Slide9

Approach: Attribute gains to tenets

9

Lower latencyReduced congestionSupport for mobilityIntrinsic security

Decouple “what” from “where”

Bind content names to intentEquip network with content cachesRoute based on content

names

Quantitative

Qualitative

Slide10

Key TakeawaysTo achieve quantitative benefits:

Just cache at the “edge”With

Zipf-like object popularities, pervasive caching and nearest-replica routing don’t add muchTo achieve qualitative benefits:Build on HTTP10

Basis for incrementally deployable ICN

Slide11

Background and Approach

Analyzing quantitative benefits

Qualitative benefits  Incrementally deployable ICNDiscussion11

Outline

Slide12

Design space of caching Quantitative benefits are largely due to caching

Two key dimensions in this design space:

Cache placement E.g., everywhere? Edge?Request routingE.g., shortest path, nearest replica?12

Slide13

Representative points in design space13

ICN-SP

Everywhere

Shortest path to origin

ICN-NR

Everywhere

Nearest replica

Edge

Only

at edge nodes Shortest path to origin

Edge-Coop

Only

at edge nodes

Shortest

path to origin

Edge

neighbors alone

Cache Placement

Request Routing

Slide14

Object Popularities have Zipf Distribution

14

ith most popular item occurs with frequency proportional to 1/iα

Slide15

Simulation setup15

PoP

-level topologies (Rocketfuel) augmented with access trees

Real CDN

r

equest logs

LRU replacement

Assume name-based routing, lookup incurs zero cost

Cache provisioning

~ 5% of objects per nodeUniform or ProportionalEdge

Slide16

Request latency (hops) - Asia trace

16

Gap between all architectures is small (< 10%)Nearest-replica routing provides almost no benefit

Slide17

Improvement in network congestion

17

Slide18

Improvement in origin server load

18

Slide19

Sensitivity Analysis

19

BaselineEven in best case, ICN-NR is only 17% better

% gap ICN-NR - Edge

Best case

NormalizeDouble

Vary

Zipf parameter, cache size, popularity skew, access tree degree

Slide20

Edge cache deployment

Incentives are aligned

Users benefit if they deploy cachesIncremental deployment is facilitatedBenefits come immediately and don’t depend on router upgrades or other cache deployments20

Slide21

Background and motivation

Approach

Quantitative benefits of ICNQualitative benefits  Incrementally deployable ICNDiscussion

21Outline

Slide22

Design RationaleParties that benefit should bear the costsConsumers deploy ICN-aware proxies/caches

Content providers register names of objectsISPs leverage their existing investments in infrastructure

22

Slide23

How Big is the CDN Market?

2012 Data (Source: Bloomberg BusinessWeek)

Slide24

Revisiting Qualitative Aspects2

. Binding names to intents

24

Decouple names from locations

Build on HTTP

Can be viewed as providing “get-by-name” abstraction

Can reuse existing web protocols

(e.g., proxy discovery)

Use self-certifying names

e.g., “Magnet” URI schemes

Extend HTTP for “crypto”

and other

metadata

Slide25

Name Resolution System

Reverse Proxy

Origin Server

Publish

content

Register

L.P.idicn.org

idICN

: Content Registration

L = content labelP = Hash of public key 25e.g., http://en.5671….fda627b.idicn.org/wiki/

Slide26

Name Resolution System

Proxy

Edge Cache

Reverse ProxyAutomatic Proxy Discovery

e.g., WPAD

Origin Server

idICN

: Client Configuration

Client

26

Slide27

Name Resolution System

Proxy

EdgeCache

Reverse Proxy

1.

Rqst

L.P.idicn.org

Origin Server2. Name resolution6. Response3. Rqst

by address

5

. Response + Metadata

idICN

: Content Delivery

Client

4. Fetch

Try it out:

www.idicn.org

27

Slide28

ConclusionsMotivation: Gains of ICN with less pain

Latency, congestion, security Without changes to routers or routing!

End-to-end argument applied to ICN design space Can get most quantitative benefits with “edge” solutionsPervasive caching, nearest-replica routing not neededCan get qualitative benefits with existing techniquesWith existing HTTP + HTTP-based extensionsIncrementally deployable + backwards compatibleidICN design: one possible feasible realizationOpen issues: economics, other benefits, future workloads ..

28