1 / 28

Incrementally Deployable Information Centric Networking

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.

gerda
Download Presentation

Incrementally Deployable Information Centric Networking

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. Incrementally DeployableInformation Centric Networking Seyed K. Fayazbakhsh, Yin Lin, Amin Tootoonchian, Ali Ghodsi, TeemuKoponen, Bruce Maggs, KC Ng, Vyas Sekar, Scott Shenker

  2. 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”

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

  4. 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 2) Resolve name to network address of server 3) Send request for object to server • Equip network with content caches • Route based on content names • e.g., find nearest replica

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

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

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

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

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

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

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

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

  13. Representative points in design space Cache PlacementRequest Routing

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

  15. Simulation setup Edge Real CDN request logs 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

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

  17. Improvement in network congestion

  18. Improvement in origin server load

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

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

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

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

  23. How Big is the CDN Market? 2012 Data (Source: Bloomberg BusinessWeek)

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

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

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

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

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