1

Incrementally Deployable Information Centric Networking

Seyed K. Fayazbakhsh, Yin Lin, Amin Tootoonchian, Ali Ghodsi, Teemu Koponen, Bruce Maggs,

KC Ng, Vyas Sekar, Scott Shenker

Internet Service Model

The 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

ICN Service Model

Given a request for named content, the network attempts to locate and retrieve the content

Example request: retrieve DSAK832NSKAWKW282

Names may be bound to content cryptographically

3

Content Retrieval

4

• Equip network with content caches

ICN decouples “what” from “where”C

S1

S2

• Bind content names to intent

• Route based on content namese.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

This talk is not anti-ICN

I am not an opponent of ICN

5

Benefits of deploying ICN

6

C

C

• Lower latency• Reduced congestion• Support for mobility• Intrinsic security

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

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 ….

8

Motivation for this work• Lower latency• Reduced congestion• Support for mobility• Intrinsic security

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

Benefits

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

Approach: Attribute gains to tenets

9

• Lower latency• Reduced congestion• Support for mobility• Intrinsic security

• Decouple “what” from “where”• Bind content names to intent• Equip network with content caches• Route based on content names

Quantitative Qualitative

Key Takeaways• To achieve quantitative benefits:Just cache at the “edge”With Zipf-like object popularities, pervasive caching and nearest-replica routing don’t add much

• To achieve qualitative benefits:Build on HTTP

10

Basis for incrementally deployable ICN

• Background and Approach

• Analyzing quantitative benefits

• Qualitative benefits Incrementally deployable ICN

• Discussion

11

Outline

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 routing• E.g., shortest path, nearest replica?

12

Representative points in design space

13

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 originEdge neighbors alone

Cache Placement Request Routing

Object Popularities have Zipf Distribution

14

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

Simulation setup

15

PoP-level topologies (Rocketfuel) augmented with access trees

Real CDNrequest logs

LRU replacement

Assume name-based routing, lookup incurs zero cost

Cache provisioning~ 5% of objects per nodeUniform or Proportional

Edge

Request latency (hops) - Asia trace

16

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

Improvement in network congestion

17

Improvement in origin server load

18

Sensitivity Analysis

19

Baseline

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

% gap ICN-NR - Edge

Best case Normalize Double

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

Edge cache deployment

• Incentives are alignedUsers benefit if they deploy caches

• Incremental deployment is facilitatedBenefits come immediately and don’t depend on router upgrades or other cache deployments

20

• Background and motivation

• Approach

• Quantitative benefits of ICN

• Qualitative benefits Incrementally deployable ICN

• Discussion

21

Outline

Design Rationale

• Parties that benefit should bear the costs– Consumers deploy ICN-aware proxies/caches– Content providers register names of objects

• ISPs leverage their existing investments in infrastructure

22

How Big is the CDN Market?

Revenues Earnings

Akamai 1.374B 204M

Chinanet 46.6M 3.0M

Limelight 180.2M (30M)

Level 3 6.376B (422M)

Netflix 3.6B 17.2M

2012 Data (Source: Bloomberg BusinessWeek)

Revisiting Qualitative Aspects

2. Binding names to intents

24

1. 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 namese.g., “Magnet” URI schemes

Extend HTTP for “crypto” and other metadata

Name Resolution System

Reverse Proxy

Origin Server

Publishcontent

Register L.P.idicn.org

idICN: Content Registration

L = content label

P = Hash of public key

25

e.g., http://en.5671….fda627b.idicn.org/wiki/

Name Resolution System

ProxyEdge Cache Reverse

Proxy

Automatic Proxy Discoverye.g., WPAD

Origin Server

idICN: Client Configuration

Client 26

Name Resolution System

ProxyEdge

Cache

Reverse Proxy

1. Rqst L.P.idicn.org

Origin Server

2. Name resolution

6. Response

3. Rqst by address

5. Response + Metadata

idICN: Content Delivery

Client

4. Fetch

Try it out: www.idicn.org

27

Conclusions• Motivation: 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” solutions– Pervasive caching, nearest-replica routing not needed

• Can get qualitative benefits with existing techniques– With existing HTTP + HTTP-based extensions– Incrementally deployable + backwards compatible

• idICN design: one possible feasible realization– Open issues: economics, other benefits, future workloads ..

28