1 / 24

Less Pain, Most of the Gain: Incrementally Deployable ICN

Less Pain, Most of the Gain: Incrementally Deployable ICN. Seyed K. Fayazbakhsh , Yin Lin, Amin Tootoonchian , Ali Ghodsi , Teemu Koponen , Bruce Maggs , KC Ng, Vyas Sekar, Scott Shenker. Presenter: Onur Ascigil. A high-level view of ICN. S1. e.g., CCN, DONA, NDN, 4WARD …. C. C.

vida
Download Presentation

Less Pain, Most of the Gain: Incrementally Deployable ICN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Less Pain, Most of the Gain:Incrementally DeployableICN Seyed K. Fayazbakhsh, Yin Lin, Amin Tootoonchian, Ali Ghodsi, TeemuKoponen, Bruce Maggs, KC Ng, Vyas Sekar, Scott Shenker Presenter: Onur Ascigil

  2. A high-level view of ICN S1 e.g., CCN, DONA, NDN, 4WARD …. C C S2 C • Decouple “what” from “where” • Bind content names to intent Today: Fetch from server IP • Equip network with content caches • Route based on content names • e.g., find nearest replica

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

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

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

  6. Heavy-tailed Workloads • Request logs collected from 3 CDNs in US, Europe and Asia. • ith popular object has a request probability proportional to .

  7. A Simple Caching Experiment • Distribution topology from the content server is a tree. • A simple experiment with a binary tree with 6 levels: • Pick a leaf node randomly as the origin of the request • If the leaf node does not have the object in its cache, it routes it toward the origin server.

  8. Caching Strategies • Edge vs ICN.

  9. Routing Strategies • SP vs NR routing. • Scoped NR: NR routing within a small neighborhod.

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

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

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

  13. Design space of caching • Quantiative benefits are largely due to caching • Two key dimensions to this design space: • Cache placement • E.g., everywhere? Edge? • Request routing • E.g., shortest path, nearest replica?

  14. Representative points in design space Cache PlacementRequest Routing

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

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

  17. Sensitivity Analysis % gap ICN-NR - Edge Best case Normalize Baseline Double Even in best case, ICN-NR is only 17% better 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

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

  20. Revisiting Qualitative Aspects • Decouple names from locations 2. Binding names to intents 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. 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

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

  23. 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. RqstL.P.idicn.org 4. Fetch 6. Response Client Origin Server

  24. Conclusions • Motivation: Gains of ICN with less pain • Latency, congestion, security • Without changes to routers or routing! • End-to-end argumentapplied 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 ..

More Related