Easy as ABC : A Lightweight Centrality-Based Caching Strategy for - PowerPoint PPT Presentation

Easy as ABC : A Lightweight Centrality-Based Caching Strategy for Information-Centric IoT Jakob Pfender , Alvin Valera, Winston K. G. Seah 26 September 2019 School of Engineering and Computer Science Victoria University of Wellington

Introduction & Motivation

Caching in Information-Centric IoT Benefjts • Fast information retrieval • Reduced congestion • Stability • Decentralisation 1

Caching in Information-Centric IoT Benefjts Challenges • Fast information retrieval • Limited memory • Reduced congestion • Limited processing power • Stability • Limited battery life • Decentralisation • Limited bandwidth • Unreliable links 1

Where should content be cached?

Multihop Topology Types in IoT Producer Relay Consumer Core topology Edge topology 2

Centrality-Based Caching Strategies

Centrality-Based Caching Strategies • Use caching node’s betweenness centrality to decide where to cache content • Betweenness centrality: The number of times a given node lies on one of the paths between all pairs of nodes in the network • Centrality indicates node’s importance in the network 3

Centrality-Based Caching Strategies 0 ∑ C B ( v ) = σ ′ i , j ( v ) , where 25 i ̸ = v ̸ = j ∈ V { 1 , if v on path ( i , j ) i , j ( v ) = σ ′ 0 , otherwise. 0 11 23 32 • Interest packets record maximum 0 14 C B ( v ) among nodes they encounter 6 • Returning Data is cached at all nodes whose C B ( v ) is equal to or greater than maximum 25 0 3

Betw and EgoBetw

Betw • Each node’s C B ( v ) is assigned 0 0.23 manually ( a priori ) or through exchange of neighbour information 0 0.1 • For automatic assignment, every 0.21 0.29 node needs full information about every other node 0 0.13 0.1 • Full recalculation required if topology changes 0.23 0 4

Betw • Signifjcant overhead: 0 0.23 • Communication • Memory • Computation 0 0.1 • Complexity: 0.21 0.29 n 2 ) • Messaging: ( O n 2 ) • Memory: ( O 0 0.13 n 2 ) • Computational: O ( 0.1 • Not feasible for constrained networks 0.23 0 4

EgoBetw • Distributed solution • Ego network : A node’s one-hop neighbours and the links between them • Centrality is calculated only for each node’s ego network • Approximates actual centrality 5

EgoBetw • Distributed solution 0 0.44 • Ego network : A node’s one-hop neighbours and the links between them 0 0.38 0.29 0.39 • Centrality is calculated only for each node’s ego network 0 0.38 • Approximates actual centrality 0.25 0.39 0 5

Betw and EgoBetw — Comparison 0 0 0.23 0.44 0 0.1 0 0.38 0.21 0.29 0.29 0.39 0 0.13 0 0.38 0.1 0.25 0.23 0.39 0 0 6

Betw and EgoBetw — Comparison • Loss of granularity between 0 0.44 absolute node centralities, but relative centralities mostly preserved 0 0.38 • Reduced complexity 0.29 0.39 • Messaging: O ( n ) • Memory: d 2 ) ( d ≤ n − 1) ( O 0 0.38 d 2 ) • Computational: O 0.25 ( • Dynamic topologies slightly easier to manage 0.39 0 7

Betw and EgoBetw — Summary • Betw is infeasible for constrained hardware • Existing research fjnds that EgoBetw delivers satisfactory approximation • But its overhead is still signifjcant ! 8

Our Goal

Our Goal Find a caching strategy that approximates the advantages of centrality-based caching while subject to the constraint that it must be feasible to implement and run on typical IoT hardware with extremely limited memory and processing power . 9

Approximate Betweenness Centrality

Approximate Betweenness Centrality (ABC) • Each node approximates its own 0 0 centrality during runtime • Using information piggy-backed onto normal ICN packets 0 0 • Interest packets are extended to 0 0 carry UID of original requesting 0 0 node 0 0 0 10

Approximate Betweenness Centrality (ABC) • Receiving an Interest means a node 0 0 4 knows it is on the path between producer and consumer • Each Interest from a new consumer 0 0 2 or to a new producer increases the 0 2 0 node’s knowledge 0 0 2 • Over time, nodes can approximate 0 their own centrality 0 2 0 10

Approximate Betweenness Centrality (ABC) • Receiving an Interest means a node 0 0 6 4 knows it is on the path between producer and consumer • Each Interest from a new consumer 0 0 5 2 or to a new producer increases the 0 2 4 2 0 node’s knowledge 0 0 5 2 • Over time, nodes can approximate 0 1 their own centrality 0 3 2 0 10

Approximate Betweenness Centrality (ABC) • Receiving an Interest means a node 0 10 0 6 4 knows it is on the path between producer and consumer • Each Interest from a new consumer 0 0 2 7 5 or to a new producer increases the 0 2 0 7 2 4 node’s knowledge 0 5 7 0 2 • Over time, nodes can approximate 0 1 2 their own centrality 3 2 6 0 0 10

Approximate Betweenness Centrality (ABC) • Introduces a convergence time 0 10 0 6 4 ( ≤ 60 s ), but gets rid of a priori setup phase • Signifjcantly reduced complexity: 0 0 7 5 2 • Messaging: O ( 1 ) 0 2 4 0 2 7 • Memory: O ( p ) ( p ≤ n ( n − 1 )) • Computational: O ( 1 ) 0 5 0 2 7 • Can handle dynamic topologies by 0 2 1 using time-outs • Centrality values refmect actual 3 6 2 0 traffjc patterns 0 10

ABC — Complexity Comparison Strategy Messaging overhead Memory overhead Computational overhead n 2 ) n 2 ) n 2 ) Betw ( ( ( O O O d 2 ) d 2 ) EgoBetw O ( n ) ( ( O O ABC O ( 1 ) O ( p ) O ( 1 ) d : Node degree ( d ≤ n − 1 ) p : Number of paths ( p ≤ n ( n − 1 )) 11

Evaluation

• Grenoble site: 380 M3 nodes distributed evenly in a single building, realistic indoor conditions (multipath, refmection, absorption, interference) • Choose 50 nodes randomly for each experiment • Nodes can cache up to 5 objects Evaluation — Experiment Setup • All experiments conducted on FIT IoT-LAB open testbed using M3 nodes • STM32 (ARM Cortex M3), 512 kB ROM, 64 kB RAM, Atmel AT86RF231 2.4 GHz transceiver on IEEE 802.15.4 • Simple RIOT-OS application using CCN-lite as ICN implementation, modifjed to support the difgerent caching strategies 12

Evaluation — Experiment Setup • All experiments conducted on FIT • Grenoble site: ∼ 380 M3 nodes IoT-LAB open testbed using M3 nodes distributed evenly in a single building, realistic indoor conditions (multipath, • STM32 (ARM Cortex M3), 512 kB refmection, absorption, interference) ROM, 64 kB RAM, Atmel AT86RF231 2.4 GHz transceiver on IEEE • Choose 50 nodes randomly for each 802.15.4 experiment • Simple RIOT-OS application using • Nodes can cache up to 5 objects CCN-lite as ICN implementation, modifjed to support the difgerent caching strategies 12

• Every node periodically requests content from producers following uniform distribution • Content is cached according to selected caching strategy • Strategies evaluated: Cache Everything Everywhere (CEE), Leave Copy Down (LCD), Betw , EgoBetw , ABC Evaluation — Experiment Description • Build core and edge topologies using routing algorithms and FIB assignment • All nodes act as producers, consumers, and relays • Multihop setup, average path length 3–4 hops 13

Evaluation — Experiment Description • Build core and edge topologies • Every node periodically requests using routing algorithms and FIB content from producers following assignment uniform distribution • All nodes act as producers, • Content is cached according to consumers, and relays selected caching strategy • Multihop setup, average path • Strategies evaluated: Cache length 3–4 hops Everything Everywhere (CEE), Leave Copy Down (LCD), Betw , EgoBetw , ABC 13

Evaluation — Cache Hit Rate 100 100 90 90 Cache hit rate, core topology Cache hit rate, edge topology 80 80 70 70 60 60 50 50 CEE LCD ABC EgoBetw Betw CEE LCD ABC EgoBetw Betw Core topology Edge topology 14

Evaluation — Hop Count Reduction 4 4 Strategy Strategy CEE CEE LCD LCD ABC ABC EgoBetw EgoBetw 3 3 Betw Betw Hops to hit Hops to hit 2 2 1 1 1 2 3 4 5 1 2 3 4 5 Distance to source (in hops) Distance to source (in hops) 15 Core topology Edge topology

Evaluation — Latency Reduction 60 60 Strategy Strategy CEE CEE LCD LCD 50 50 ABC ABC EgoBetw EgoBetw Betw Betw Latency reduction (in ms) Latency reduction (in ms) 40 40 30 30 20 20 10 10 0 0 1 2 3 4 5 1 2 3 4 5 Distance to source (in hops) Distance to source (in hops) 16 Core topology Edge topology

Conclusions

• ABC not expected to outperform existing centrality strategies because it relies on less accurate information • If the topology type is known & • However, its complexity is static , other strategies may be signifjcantly lower while results optimal remain acceptable • Centrality strategies are a strong • It is viable to implement on option if topology is unknown or constrained devices and is mutable consistent across topologies Conclusions • Centrality strategies ofger signifjcant benefjts for content delivery latency regardless of network topology 17