1. NICE: Network-oriented Information-centric Centrality for Efficiency in Cache Management
Junaid Ahmed Khan, Cedric Westphal, J.J. Garcia-Luna-Aceves and Yacine Ghamri-Doudane
ACM ICN 2018, Boston, MA, USA
22nd September 2018

2. Overview Introduction and Motivation NICE Cache Management
Content Replacement Strategy
Numerical Evaluation
Results
Conclusions and Future Work

3. Introduction and Motivation
Information Centric Networking (ICN) enables caching of content at the network edge
Edge devices (routers, small cells, Wifi APs, etc.) cache content closer to consumers
Limited storage at the devices requires it to replace cached content using known cache eviction strategies or/and variants:
LRU: Least Recently Used
LFU: Least Frequently Used
FIFO: First In-First Out

4. Introduction and Motivation
Coordinated caching increases content availability in the network
Place popular content at better connected nodes
Connectivity in the network graph structure measured using:
Centrality metric (Degree, Closeness, Betweeness, Eigenvector)

5. Introduction and Motivation
Centrality-based placement fails to capture the ICN structure:
Consumer should be connected to “content” not a specific node
Bridge as an example of Betweenness
The key point is this: graph centrality is static. It doesn't depend on anything but the graph topology. But as the illustrative examples show, it really depends on where the content is placed. That's what NICE centrality is about: it's a centrality measure that evolves with the content placement.
Need for a new way to consider centrality, and to use it for content placement approach

6. NICE – Network oriented Information-centric Centrality for Efficiency
Define an ICN-specific centrality measure that evaluates the consumers’ reachability to content rather than to nodes in the network
NICE Closeness
NICE Betweenness
Cache management approach where a node adds content to its cache to increase the overall content reachability to consumers
NICE content replacement policy

7. NICE Closeness – Example
Assume content x1, x2, x3, ... with probability distribution p1 > p2 > p3 > cached at nodes v1, v2 ,v3, v4
Origin server with costly link
If we consider traditional Closeness centrality
Node v2 has the highest closeness centrality
Most popular content is two hops away from the user
It’s not clear it is an optimal content placement policy

8. NICE – Closeness Closeness centrality redefined:
Weighted by the popularity of the content
Inverse of the sum of the distance from the users to the content
Add popularity
u - user
x - content

9. NICE - Betweenness Betweenness centrality redefined:
Sum of the ratio of
The number of shortest paths from all users to all content objects that passes through the node
To the total number of shortest paths between all the (user,content) pairs
Weighted by the popularity of each content object.

10. NICE Betweenness – Example
Server that holds a copy of all the content
v1, v5 and v6 are caching nodes
(a), (b) and (c) are user nodes
Traditional Betweenness centrality does capture the network behavior
Not all nodes are caching
NICE betweenness for v6 computed as: S+N/2
For simplicity we have assumed on this figure that the content is distributed in blocks, where the capacity Cc is divided into C content objects that are the same at all caching nodes, and S content objects that are unique to this cache
for ease of explanation only, that all content is equally likely.
Computing the betweenness centrality between all the nodes does not capture that only (a), (b) or (c) issue requests, nor that only v1,v5,v6 and S can respond to these interests.
The user (a) will send traffic to v6 only for the content that is specific to v6. The common content C will be served by v1 for user (a). For this v6-specific content, half of the requests from (a) will go to v6, and half will go to S, as both are four hops away from (a) and therefore both are on the shortest path to this content. Therefore the contribution from (a) is S/2, as all S content are equally likely.
For user (b), there are three paths to the content that is v6-specific:v7 −v5 −v3 −S, orv7 −v5 −v3 −v6 orv7 −v5 − v8 −v6. Two out of these three paths end at v6 therefore (b)’s contribution is 2S/3.
Finally, user (c) sends requests for the content that is v1-specific through either the 3-hop path to v1 or the two 3-hop paths to S, including one through v6 for a total of S/3. All the v6-specific requests from (c) end up at v6 for a total of S. Half of the common content C from (c) ends up at v6, the other half goes to v5, adding C/2. Finally, the rest of the content requests go to the server S and half of these follow a path through v6 (the other half goes through v5), adding (N − C − 3S)/2
S/2+2S/3+(N-C-3S)/2=
Summing all these contributions yield S + N /2

11. NICE Computation Computing NICEb(v) can be difficult:
Content catalog X may be very large and requires knowing the content placement and popularity
We propose performing an offline computation for a combination of caches first
Scales with the number of caches, not with the number of content, can be done offline and only once
There are 2{c1,...,cm } potential combinations of caches content can belong to
Let cp an element of 2{c1,...,cm }
Compute once the NICE value of a single item of popularity 1 located at the caches in cp and no other item anywhere else
Compute NICEcp(v) for all such cp cache combinations
Network operator can set a limit on the number of copies for any piece of content
Therefore we do not have to compute the NICE value for every cp ∈ 2{c1,...,cm }
A content object x will belong at any point of time to one cache set cp
We only need to look up the cache permutation cp(x) of content x

12. NICE Content Replacement
Distributed content replacement at each node
Pair-wise comparison between the item that has the smallest contribution to NICE centrality vs the new item it considers for the cache
Nodes compute a new content x’s contribution to its NICE value
Find the difference between its current and new NICE value
If caching the new content increases the NICE value, add it to the cache
Content placement is complex to evaluate. So we only do a pair-wise comparison between the item that has the smallest contribution to NICE centrality (it's additive) vs the new item we consider for the cache. 
[That's what the algorithm should be doing] And this pair-wise comparison is two terms (an addition, a subtraction) that can be computed ahead of time (minus the p_x's) based on possible cache placements. 

13. NICE Content Replacement
For each new content y arrival:
If the node’s NICE score is increased by adding the item
Find the already cached content z yielding the minimum NICE score for the node
Replace z by the new content y
Increasing the node’s NICE score makes the content more reachable

14. Numerical Evaluation
Evaluation for cache hits and hop count in comparison with:
Centrality-based cache management approach
Non-Centrality based
LRU
Simulations
NS-3 based ndnSIM [1] simulator
3 Topologies with 2,986 nodes in each
Realistic traces of nodes in 6 X 6 km2 area in Cologne, Germany [2]
~30% caching nodes (25*36=900 nodes)
1. S. Mastorakis, A. Afanasyev, and L. Zhang, "On the Evolution of ndnSIM: an Open-Source Simulator for NDN Experimentation," ACM SIGCOMM Computer Communication Review (CCR), July 2017 
2. S. Uppoor, O. Trullols-Cruces, M. Fiore, J.M. Barcelo-Ordinas, Generation and Analysis of a Large-scale Urban Vehicular Mobility Dataset, IEEE Transactions on Mobile Computing, Vol.13, No.5, May 2014

15. Result: Cache Hits
NICE compared to existing centrality based, LRU w/without collaboration approach:
Varying Zipf parameter for 3 different topologies
NICE outperformed existing centrality and LRU-based approaches

16. Hop count (distance to content) results show NICE performs:
Result: Hop count
Hop count (distance to content) results show NICE performs:
Relatively similar to centrality-based approach
Better than LRU-based approaches

17. Conclusion and Future Directions
Existing centrality metrics aren’t suited for ICNs
Nodes topological connectivity is considered rather than its ability to provide content to consumers
NICE- A centrality-based cache management approach proposed
Cache popular content at nodes capable to facilitate content to consumers
Content replacement policy at the network edge
NICE evaluated using topolgies for up to 2,986 nodes
Outperformed existing centrality based and LRU-based cache replacement
Further work is to study NICE under mobility

18. Thank you!
Questions?