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

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

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

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) https://ultrabpm.wordpress.com

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

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

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

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

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.

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

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

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. 

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

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

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

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

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

Thank you! Questions?