Incrementally deployable information centric networking
Download
1 / 28

Incrementally Deployable Information Centric Networking - PowerPoint PPT Presentation


  • 301 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Incrementally Deployable Information Centric Networking' - gino


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


Difficultiesdeploying ICN

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

C

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

C


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




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


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


idICN: Client Configuration

Name Resolution System

Proxy

Edge

Cache

Reverse Proxy

Automatic Proxy Discovery

e.g., WPAD

Client

Origin Server


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


ad