Incrementally Deployable Information-Centric Networking Overview

Incrementally Deployable Information Centric Networking Seyed K. Fayazbakhsh, Yin Lin, Amin Tootoonchian, Ali Ghodsi, Teemu Koponen, Bruce Maggs, KC Ng, Vyas Sekar, Scott Shenker 1

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 S1 e.g., CCN, DONA, NDN, 4WARD . C C S2 C ICN decouples what from where Bind content names to intent Today: 1) Ask search engine for name of server holding object Equip network with content caches 2) Resolve name to network address of server 3) Send request for object to server Route based on content names e.g., find nearest replica 4

This talk is not anti-ICN I am not an opponent of ICN 5

Benefits of deploying ICN e.g., CCN, DONA, NDN, 4WARD . C C Lower latency Reduced congestion Support for mobility Intrinsic security 6

Difficulties deploying ICN e.g., CCN, DONA, NDN, 4WARD . C C Routers need to be replaced to support content-based routing and to incorporate caches 7

Motivation for this work Lower latency Reduced congestion Support for mobility Intrinsic security Benefits Can we get ICN gains without the pains? e.g., existing technologies? e.g., incrementally deployable? Routers need to be replaced to support content-based routing and to incorporate caches Difficulties 8

Approach: Attribute gains to tenets Quantitative Qualitative 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 9

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 Basis for incrementally deployable ICN 10

Outline Background and Approach Analyzing quantitative benefits Qualitative benefits Incrementally deployable ICN Discussion 11

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 Cache Placement Request Routing 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 13

Object Popularities have Zipf Distribution ith most popular item occurs with frequency proportional to 1/i 14

Simulation setup Real CDN request logs Edge Cache provisioning ~ 5% of objects per node Uniform or Proportional LRU replacement PoP-level topologies (Rocketfuel) augmented with access trees Assume name-based routing, lookup incurs zero cost 15

Request latency (hops) - Asia trace Gap between all architectures is small (< 10%) Nearest-replica routing provides almost no benefit 16

Improvement in network congestion 17

Improvement in origin server load 18

Sensitivity Analysis % gap ICN-NR - Edge Baseline Best case Normalize Double Vary Zipf parameter, cache size, popularity skew, access tree degree Even in best case, ICN-NR is only 17% better 19

Edge cache deployment Incentives are aligned Users benefit if they deploy caches Incremental deployment is facilitated Benefits come immediately and don t depend on router upgrades or other cache deployments 20

Outline Background and motivation Approach Quantitative benefits of ICN Qualitative benefits Incrementally deployable ICN Discussion 21

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? 2012 Data (Source: Bloomberg BusinessWeek) 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

Revisiting Qualitative Aspects 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) 2. Binding names to intents Use self-certifying names e.g., Magnet URI schemes Extend HTTP for crypto and other metadata 24

idICN: Content Registration Name Resolution System Register L.P.idicn.org Reverse Proxy P = Hash of public key L = content label Publish content e.g., http://en.5671 .fda627b.idicn.org/wiki/ Origin Server 25

idICN: Client Configuration Name Resolution System Proxy Edge Cache Reverse Proxy Automatic Proxy Discovery e.g., WPAD Client Origin Server 26

idICN: Content Delivery Name Resolution System Try it out: www.idicn.org 2. Name resolution 3. Rqst by address Reverse Proxy Proxy Edge Cache 5. Response + Metadata 1. Rqst L.P.idicn.org 4. Fetch 6. Response Client Origin Server 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