Author: Nan Hua, Bill Lin, Jun (Jim) Xu, Haiquan (Chuck) Zhao Publisher: ANCS’08 Presenter: Yun-Yan Chang Date:2011/02/23 1

 Introduction  Design of BRICK ◦ Basic idea ◦ Rank indexing ◦ Handling increment ◦ Handling overflow  Performance evaluation  Conclusion 2

 Present a novel active statistics counter architecture called BRICK (Bucketized Bank Indexed Counter).  BRICK ◦ Store variable width counters entirely in SRAM while supporting fast access. ◦ Exploit statistical multiplexing technique.  Group a fixed number of randomly selected counters into a bucket by an indexing scheme. 3

◦ Figure 1 shows the effect of statistical multiplexing  Each horizontal layer of bricks corresponds to a bucket  The length of bricks corresponds to the real counter widths. 4 Figure 1: BRICK wall (conceptual baseline scheme)

 Randomly bundle N counters into h buckets, B 1, B 2,..., B h, where each bucket holds k counters and N = hk. 5 Figure2: (b) Bucket structure

 When access the y th counter, apply the index y to permuted index i by a permutation function π : {1...N} →{1...N}.  The corresponding counter C i can then be found in the l th bucket B l, where l =. 6 Figure2:(a) index permutation

 Each bucket contains p sub-counter arrays A 1, A 2,..., A p to store the 1 st, 2 nd,..., p th sub-counters. ◦ Assume the worst-case counter width is divided into p parts, which refer to as “sub-counters". 7 Figure 3: (a) Within a bucket, segmentation of variable-width counters into sub-counter arrays.

 For each counter, use indexing scheme to identify locations of sub-counters across the different sub- counter arrays. 8 Figure3: (b) Compact representation of variable-width counters.

 Algorithm for get the value of i th counter. 9 ※ rank(I j, a): return the number of 1 in bit-string I j, count form I j [1] to I j [a].

 Increment algorithm 10 ※ varshift(s, j, c): bit-string s, start from j th bit, shift right c times.

11 32 ※ varshift(s, j, c): bit-string s, start from j th bit, shift right c times.

 Extend data structure with full-size buckets F 1, F 2,..., F J, each bucket F t is organized as k full- size counters. ◦ When a bucket overflow occurs for some B l, the next available full-size bucket F t is allocated to store its k counters, where t is just +1 of the last allocated full-size bucket. ◦ Use a flag f l to set to indicate the overflowed buckets. ◦ The index of the full-size bucket F t is stored in a field labeled t, which is associated with B l. 12

 Memory costs and lower bounds  S l :memory cost of each bucket  S : total memory cost ◦ Lower bound of memory 13 Ci: denote counter and counter value M: sum of counter values N: number of counters

 Numerical results with various configurations  The number of entries decreases exponentially as we go to the higher sub-counter arrays. (main compression) 14

 Numerical results with various configurations  The amount of extra storage only decreases slightly with additional levels in the BRICK implementation. 15

16

 Results for real Internet trace  USC: around 18.9 million packets, 1.1 million flows.  UNC: around 32.6 million packets, 1.24 million flows. 17 Worst-case counter width Total storage requirement USCUNC Naïve25 bits/counter3.85 MB4.40 MB BRICK10 bits/counter1.39 MB1.63 MB

 BRICK is SRAM-efficient yet allows for fast counter lookup and increment.  Index filed only requires small number of extra bits per bucket. 18