Incrementally deployable information centric networking
This presentation is the property of its rightful owner.
Sponsored Links
1 / 28

Incrementally Deployable Information Centric Networking PowerPoint PPT Presentation


  • 231 Views
  • Uploaded on
  • Presentation posted in: General

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.

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Incrementally deployable information centric networking

Incrementally DeployableInformation Centric Networking

Seyed K. Fayazbakhsh, Yin Lin, Amin Tootoonchian, Ali Ghodsi, TeemuKoponen, Bruce Maggs, KC Ng, Vyas Sekar, Scott Shenker


Internet service model

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”


Icn service model

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


Content retrieval

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


This talk is not anti icn

This talk is not anti-ICN

I am not an opponent of ICN


Benefits of deploying icn

Benefitsof deploying ICN

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

C

  • Lower latency

  • Reduced congestion

  • Support for mobility

  • Intrinsic security

C


Incrementally deployable information centric networking

Difficultiesdeploying ICN

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

C

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

C


Incrementally deployable information centric networking

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


Approach attribute gains to tenets

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


Key takeaways

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


Outline

Outline

  • Background and Approach

  • Analyzing quantitative benefits

  • Qualitative benefits  Incrementally deployable ICN

  • Discussion


Design space of caching

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?


Representative points in design space

Representative points in design space

Cache PlacementRequest Routing


Object popularities have zipf distribution

Object Popularities have Zipf Distribution

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


Simulation setup

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


R equest latency hops asia trace

Request latency (hops) - Asia trace

Gap between all architectures is small (< 10%)

Nearest-replica routing provides almost no benefit


Improvement in network c ongestion

Improvement in network congestion


Improvement in origin s erver l oad

Improvement in origin server load


Sensitivity analysis

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


E dge c ache deployment

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


Outline1

Outline

  • Background and motivation

  • Approach

  • Quantitative benefits of ICN

  • Qualitative benefits  Incrementally deployable ICN

  • Discussion


Design rationale

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


How big is the cdn market

How Big is the CDN Market?

2012 Data (Source: Bloomberg BusinessWeek)


Revisiting qualitative aspects

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


Incrementally deployable information centric networking

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


Incrementally deployable information centric networking

idICN: Client Configuration

Name Resolution System

Proxy

Edge

Cache

Reverse Proxy

Automatic Proxy Discovery

e.g., WPAD

Client

Origin Server


Incrementally deployable information centric networking

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


Conclusions

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


  • Login