1. Less Pain, Most of the Gain: Incrementally Deployable ICN 1 Seyed K. Fayazbakhsh, Yin Lin, Amin Tootoonchian, Ali Ghodsi, Teemu Koponen, Bruce Maggs, KC Ng, Vyas Sekar, Scott Shenker Presented by: Nirali Mistry Tushar Sharma

2. Internet’s Architecture - what we know Core Abstraction: Interfaces identified by IP address Data (bytes) flows between interfaces Stateless wherever possible (fast) This result in internet which is Host centric (end to end) Focus on who to communicate with

3. ICN Commnication model Key Ideas: Clients send request asking for named data Routers in network requests towards publishers Any node with a cached copy can provide corresponding information object This result in internet which: Declares information as first-class Focus on what within a communication

4. A high-level view of ICN 4 Equip network with content caches Decouple “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: Fetch from server IP

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

6. 6 Pains of deploying ICN C C Routers need to be upgraded Routing needs to be content based e.g., CCN, DONA, NDN, 4WARD ….

7. 7 Motivation for this work Lower latency Reduced congestion Support for mobility Intrinsic security Routers need to be upgraded with caches Routing needs to be content based Can we get ICN gains without the pains? e.g., existing technologies? e.g., incrementally deployable? Gains Pains

8. Approach: Attribute gains to tenets 8 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

9. Heavy Tailed Workload The simulated logs followZipf distribution Size of the r th occurance is inversely proportinalto its rank In other words, y ∝ r − b But why does it matter?

10. Key Takeaways To achieve quantitative benefits:  Just cache at the “edge”  With Zipf-like workloads, pervasive caching and nearest-replica routing don’t add much To achieve qualitative benefits:  Build on HTTP 10 Basis for incrementally deployable ICN

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

12. Design space of caching Quantiative benefits are largely due to caching Two key dimensions to this design space: – Cache placement c E.g., everywhere? Edge? 12

13. Request routing E.g., shortest path, nearest replica? 13

14. Representative points in design space 14 ICN-SPEverywhereShortest path to origin ICN-NREverywhereNearest replica EdgeOnly at edge nodesShortest path to origin Edge-CoopOnly at edge nodesShortest path to origin Edge neighbors alone Cache Placement Request Routing

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

16. Request latency 16 Gap between architectures is small (< 10%) Similar results for congestion + server load Telstra Sprint Level3 AT&T % improvement over “no-cache”

17. Sensitivity Analysis 17 Baseline Even in best case, ICN-NR is only 17% better % gap ICN-NR - Edge Best caseNormalize Double Gap can be easily reduced

18. Implications of Edge Caching Incrementally deployable – Domains get benefits without relying on others Incentive deployable – Domains’ users get benefits if domain deploys caches 18

19. Background and motivation Approach Quantitative benefits of ICN Qualitative benefits  Incrementally deployable ICN Discussion 19 Outline

20. Revisiting Qualitative Aspects 2. Binding names to intents 20 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 names e.g., “Magnet” URI schemes Extend HTTP for “crypto” and other metadata

21. Name Resolution System Proxy Edge 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 21

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

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

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

25. Things we didn’t understand! Percentage don’t speak much – Eg. Performance gap of 9% ? Future devices will have “long tail”. Why? 25

26. References [1]Seyed Fayazbakhsh, Amin Tootoonchian, Yin Lin, Ali Ghodsi, KC Ng, Bruce Maggs, Vyas Sekar, Scott Shenker. Less Pain, Most of the Gain: Incrementally Deployable ICN. in SIGCOMM 2013. [2]Dirk Trossen and Alexandros Kostopoulos. Techno-Economic Aspects of Information-Centric Networking in Journal of Information Policy. [3]Bengt Ahlgren Information-centric networking and relaton to legal and regulatory issues by SAIL.

27. Thank you Questions? 27