+ All Categories
Home > Documents > CCN Caching and Routing - KRnet · OSPF extensions for ... for NDN GENI deployment Source: Jim...

CCN Caching and Routing - KRnet · OSPF extensions for ... for NDN GENI deployment Source: Jim...

Date post: 07-May-2018
Category:
Upload: phamnguyet
View: 223 times
Download: 0 times
Share this document with a friend
43
CCN Caching and Routing Taekyoung Taekyoung Kwon & Kwon & Kideok Kideok Cho Cho ([email protected] [email protected] , , [email protected] [email protected] ) Seoul National University Seoul National University 2012. 6. 26. 2012. 6. 26. KRnet KRnet 2012 2012
Transcript

CCN Caching and Routing

TaekyoungTaekyoung Kwon & Kwon & KideokKideok ChoCho(([email protected]@snu.ac.kr, , [email protected]@mmlab.snu.ac.kr))Seoul National UniversitySeoul National University2012. 6. 26.2012. 6. 26.

KRnetKRnet 20122012

Contents

1. CCN Research Activities

2. CCN Caching

3. CCN Routing

2

Named Data Networking (NDN) in US

Focused Areas NDN application & Demo

Audio Conferencing Tool Lighting Control

NDN routing OSPF extensions for NDN Greedy routing over testbed ns-3 simulation

Scalable Forwarding

NDN for Lighting Control

OSPF Extensions for NDN

GENI deployment

Source: Jim Thornton, “NDN Project Progress Report”, AsiaFI NDN Hands-on Workshop 2012

3

CCN Research in Europe

Many organizations are working on CCN Including Bell Labs, Orange Labs, INRIA, UPMC …

Research areas Bandwidth & storage modeling Congestions/flow control Content caching performance Wireless CCN/Mobility

Window-based flow control*

*Source: G. Carofiglio and M. Gallo, and L. Muscariello,“ICP: Design and Evaluation of an Interest Control Protocol for Content-Centric

Networking,” In Proc. INFOCOM NOMEN Workshop 2012.

**Source: B. Weber, I. Ju, and S. Catanzariti,CCN lab proof of concept and potential use cases for CCN

CCNx Community Meeting 2011Seamless mobility with CCN**

4

CCN Research in Asia

Asian activities AsiaFI ICN WG from 2011 summer CJK collaboration for the NDN research AsiaFI NDN hands-on workshop in March, 2012

NDN research in China HTTP-NDN Gateway Congestion Control PIT compression for scalability Optimal Caching algorithm Collaboration with PARC, UCLA, Huawei NDN testbed in Tsinghua Univ.

Source: Jun Bi, “NDN Research in Tsinghua University”, AsiaFI NDN Hands-on Workshop 2012

5

Design Choices in Caching

Design Choices in CCN Caching

Choice Description

What to cache Decide which content files (or chunks) will be cached in the in-network storages

What to replace Decide which content (or chunk) will be replaced when the in-network storage is full and a new item is needed to

be cachedWhere to cache Decide the caching location (i.e., CCN router(s)) within

the networks

Cooperation between routers

Caching/replacement/locating decision is madewith/without a cooperation between routers

Unit of caching Content caching can be done in the unit of a chunk or a content

7

Choice 1: What to Cache

1. Cache All 2. Cache Probabilistically

3. Cache Selectively

All incoming content files are cached

Incoming content files are cached with a certain probability

Only selected content files are cached (popular one or unpopular one)

In-network storage

CCN routercontent

Cache AllCache All

All incomingcontents

In-network storage

CCN router

content

Cache ProbabilisticallyCache Probabilistically

Cache w/probabilityp(·)p(·)

In-network storage

CCN routercontent

Cache SelectivelyCache Selectively

Select w/criteria

˅˅

f(·)f(·)

˅˅

8

Choice 2: What to replace

1. LRU 2. LFU 3. Priority (e.g., Age)Least recently used content file will be replaced

Least frequently used content file will be replaced

A victim content file will be chosen based on the priority such as age

In-network storage

CCN router

LRULRU

Victim

Leastrecentlyused

In-network storage

CCN router

LFULFU

Victim

(15)

(11)

(17)Access

In-network storage

CCN router

AgeAge--basedbased

Victim

(5)

(3)

(0)

Agecounter

9

Choice 3: Where to cache

1. All CCN routers 2. Specific routerAll CCN routers along the data path will cache the content file

Specific router(s) will cache the content file

Cache at all Cache at all CCN routersCCN routers Cache at specific routersCache at specific routers

1. Edge CCN router

2. CCN router w/the highest degree

10

Choice 4: Cooperation

1. Cooperative 2. Non-CooperativeCCN routers will cooperate explicitly or implicitly to perform caching

Each CCN router will make caching decision autonomously

Cooperative CachingCooperative Caching

Consider neighbors’contents during caching

NonNon--Cooperative CachingCooperative Caching

There might be redundantcontents at nearby routers

Explicitcooperation

Implicitcooperation

11

Choice 5: Unit of Caching

1. A chunk 2. A content A caching decision will be applied to a single chunk of a content file

The same caching decision will be applied to all chunks of a content file

In-network storage

CCN router

In-network storage

CCN router

Some chunks of a content file might not be cached

Meta-information for the cached content should be maintained in the unit of a chunk

The chunks of a content file will be cached together

Meta-information for the cached content can be reduced (one entry for a content file)

12

A Case Study

WAVE: Popularity-based and Collaborative In-network Caching*

*K. Cho, M. Lee, K. Park, T. T. Kwon, Y. Choi, and S. Pack,“WAVE: Popularity-based and Collaborative In-network Caching for Content-Oriented Networks,”

in Proc. IEEE INFOCOM NOMEN Workshop, Florida, USA, March 2012.

WAVE Overview

Distribute content chunks to the routers Distribute chunks as the content request changes To make “the cache hits of contents” happen earlier (closer to

end users)

As a consequence, Network utilization will be improved: the number of duplicate

content delivery (thus total traffic volume) can be reduced End users will experience reduced latency for content download The overhead of cache management will be reduced

14

Main issues in caching

What to Cache?

Cache All

What to Replace?Where to Cache?

Cache Selectively

Cache Popular Ones

LRU

LFU

LRFU

Priority

All CON Nodes

Specific CON Node

Cache Popular Ones WAVEWAVE

15

Design Principles of WAVE

• More chunks to be cached for more popular contents• WAVE exponentially increases the number of chunks to be

cached as the access count increases

Popularity-based

• No prior knowledge of content access patterns• WAVE uses only two counters per content file to decide

cachingSimple

• No central server for caching decision• In WAVE, content caching is decided by each CON router

independently with its local informationDecentralized

16

WAVE Algorithm: What to cache

As the access count of a content file increases, WAVE exponentially increases the number of chunks of the content file to be cached

Mark content chunkto be cached

Increase window size

17

CMW:CMW State (n):

cached:1 42 3 5 76 8 109 1211

1 2 30

While serving chunk 4 to chunk 12, mark chunks 4 to chunk 7.Update cached and n.

If an already distributed chunk (e.g., 6) is requested again, rewind cached and n.Next time, only chunk 6 and 7 will be marked to be cached again.

CMW:CMW State (n):

cached:1 42 3 5 76 8 109 1211

1 2 30

CMW:CMW State (n):

cached:1 42 3 5 76 8 109 1211

1 2 30

Caching Example in a Router

18

What to replace, Where to cache

What to replace WAVE uses least recently used (LRU) and maintains access

history in the unit of a content to find a victim to be replaced WAVE replaces the last chunk for the incoming chunk

Where to cache The content chunks are cached towards the direction where the

content request comes considering the spatial locality WAVE caches content chunks in a hop-by-hop manner to fully

utilize the in-network storages

19

WAVE Operation Illustration

End Host

OriginalServer

CONRouter

Content

ContentChunk

ContentRequest

CachedChunk

(1)

ContentRetrieval

CBAH1

H2H3

(4)

CBAH1

H2H3

CBAH1

H2H3

(8)

(3)

(7)

(11)(10) (9)

(6) (5)

(2)

20

Simulation Environments

Simulation EnvironmentsSimulator Discrete event-driven simulatorTopology 1 transit domain and 5 stub domains generated using

GT-ITMNumber of routers & end hosts

55 routers & 1,000 end hosts

Content distribution Randomly distributed 100,000 contents (1GBytes, 100 chunks)

Request distribution Zipf distribution with parameter 1.0Cache size 10GBytesContent Routing En-route Cache Model (shortest path to the original

server)Comparison Client-Sever, CDN, AllCache, UniCache, ProbCache

21

Comparison

What to cache Where to cache What to replace

WAVE ExponentiallyIncreasing number of chunks

Next downstream CON router

LRU*

AllCache(Cache all)

All incoming chunks All CON routers LRU

ProbCache(Probabilistic caching)

Incoming chunks with a certain probability

All CON routers LRU

UniCache(Uniform caching)

Incoming chunks One CON router along the returning path

LRU

CDN Popular contents**(Top x%)

One CDN server per AS(at the best position)

N/A

Client-Server N/A N/A N/A

*: Results with LFU show similar performances**: The total # of files stored in CDN servers is

the same as those of other schemes22

Simulation Results (1/2)

• WAVE achieves the smallest average hop count between a host and a content-holding place

– Resulting in faster content retrieval• By exploiting in-network storages, WAVE can

cache the contents at CON routers which are closer to the end hosts than the CDN servers

• WAVE achieves the smallest inter-ISP traffic volume (except for CDN)

• Since CDN stores most popular contents in advance, it can achieve smaller inter-ISP traffic volume than WAVE

– WAVE downloads contents from outside the ISP at least once

23

Simulation Results (2/2)

• Less than half (42.8%) of chunks are replaced without being accessed in WAVE due to its popularity-based chunk caching algorithm

– Resulting in efficient cache management

• In the other schemes, more than 87% of content chunks are not accessed before being replaced

• WAVE achieves the highest cache hit ratio than the other schemes (both 1st hop router and on average)

– By caching the popular chunks more (exponentially increasing caching)

• AllCache shows the lowest cache hit ratio due to its popularity-blind and aggressive caching

42.8%91.9%

87.1%

96.0%

24

Summary: Caching

Many choices in designing CCN caching What to cache/replace Where to cache Cooperation Unit of caching

A case study of CCN caching WAVE is a simple and decentralized caching algorithm in

content-oriented networks WAVE exponentially increases the number of cached chunks of

a content to achieve high cache hit ratio, and low cache replacement count

25

CCN Routing

Routing in CCN/NDN

27

No IP addresses No DNS

Use content names for forwarding Content name (or content ID) is a routing entry

names face/cnn.com 1

/nytimes.com 2…

face 1

face 2

/cnn.com/us/image.jpg

Interest packet/cnn.com

/nytimes.com

IP networking vs. CCN

Network prefixDestination Next Hop

192.168.0.0/16 Router C

Content Name Next Hop

/a.com/b.jpg Router C

/a.com/b.jpg

Content name

Forwarding Info. Base (FIB)

29

CCN Routing Principle

30

IP is Lookup-by-name

CCN is Route-by-name No indirection, better availability Huge scalability concern

Global-scale and flat routing may not be feasible At least billions of contents Some aggregation may be possible

E.g. hierarchical names like URLs cnn.com/video/a.avi cnn.com/video/b.avi

CCN routing: LPM

An interest will be forwarded to a face with longest prefix matching (LPM)

31

names face/cnn.com 1

/cnn.com/us 2…

face 1

face 2

/cnn.com/us/image.jpg

Interest packet/cnn.com

/cnn.com/us

Hierarchy for scalability

32

Some assumptions A host name (or publisher) is present in a content name

E.g. cnn.com/asia/news.avi A host is connected to a particular ISP

E.g. cnn.com is a subscriber to sprint.com

sprint.comatt.com

client1 cnn.comclient2

Number of ISPs

10s of thousands (90K in 2030)

33

Basic idea

Concatenate ISP name and content name E.g. sprint.com/cnn.com/asia/news.av

Routers have (only) routing entries of all ISPs for publishers outside 90K entries for inter-domain routing is ok A router in att.com will look at sprint.com only

Routers also have routing entries of publishers inside Number of hosts in an ISP is a concern now

A router in att.com will look at host name att.com/nytimes.com/news/logo.gif att.com/nbc.com/news/index.html

34

Number of host names

Billions (4G in 2030)

35

Number of hosts per ISP

100s of million hosts in the largest ISP Assuming Zipf distribution of hosts among ISPs

334 million hosts per ISP in 2030

How can we handle so many routing entries?

36

Split the hostname space

Virtual Aggregation [NSDI ’09]

37

Number of routers in an ISP

May exceed 1 million [PAM ’10]

38

Number of routing entries

Can then be reduced to Current number of routing entries in IP routing By Virtual Aggregation

Route stretch should be investigated

39

Another issue

A host can change its ISP Old ISP may send a reply to the interest for the host The reply can contain the new ISP’s name

Or there can be a mapping system

A host can have multiple ISPs Aka multi-homing A mapping system contains the list of all the

connected ISPs May return the closest ISP

40

Further Research

If a router in att.com caches some objects whose names start with /cnn.com/us Can it advertise /att.com/cnn.com/us even if it is not complete?

Interest packet can be forwarded to both faces If cache hit, data packets will arrive early

41

sprint.comatt.com

client /cnn.com/cnn.com/us

Summary: Routing

Flat routing of all content names is not feasibleWe may need to exploit some hierarchical

structure in content names for scalable routing Two-level hierarchy: ISP and publisher CCN’s key benefit is somewhat compromised

We predict the numbers of ISPs and hosts in 2030

We can make CCN routing as scalable as IP routing At cost of route stretch

Other issues to solve42


Recommended