BRICK: A Novel Exact Active Statistics Counter Architecture

1. BRICK: A Novel Exact Active Statistics Counter Architecture Author: Nan Hua, Bill Lin, Jun (Jim) Xu, Haiquan (Chuck) Zhao Publisher: ANCS’08 Presenter:Yun-Yan Chang Date:2011/02/23

2. Outline • Introduction • Design of BRICK • Basic idea • Rank indexing • Handling increment • Handling overflow • Performance evaluation • Conclusion

3. Introduction • Present a novel activestatistics counter architecture called BRICK (BucketizedBank 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.

4. Introduction • 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. Figure 1: BRICK wall (conceptual baseline scheme)

5. Basic idea • Randomly bundle N counters into h buckets, B1, B2, ..., Bh, where each bucket holds k counters and N =hk. Figure2: (b) Bucket structure

6. Basic idea • When access the yth counter, apply the index y to permuted index i by a permutation function π : {1...N} →{1. . .N}. • The corresponding counter Ci can then be found in the lth bucket Bl , where l = . Figure2:(a) index permutation

7. Basic idea • Each bucket contains p sub-counter arrays A1, A2, ..., Ap to store the 1st, 2nd, ..., pth sub-counters. • Assume the worst-case counter width is divided intop parts, which refer to as “sub-counters". Figure 3: (a) Within a bucket, segmentation of variable-width counters into sub-counter arrays.

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

9. Rank indexing • Algorithm for get the value of ith counter. • ※rank(Ij, a): return the number of 1 in bit-string Ij, count form Ij[1] to Ij[a].

10. Handle increment • Increment algorithm ※varshift(s, j, c): bit-string s, start from jth bit, shift right c times.

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

12. Handle overflow • Extenddatastructure with full-sizebuckets F1, F2, ... , FJ, each bucket Ft is organized ask full-size counters. • When a bucket overflow occurs for some Bl , the next availablefull-size bucket Ft is allocated to store its k counters, wheret is just +1 of the last allocated full-size bucket. • Use a flag fl to set to indicate the overflowed buckets. • The indexof the full-size bucket Ft is stored in a field labeled t, which isassociated with Bl.

13. Performance evaluation • Memory costs and lower bounds • Sl :memory cost of each bucket • S : total memory cost • Lower bound of memory Ci: denote counter and counter value M: sum of counter values N: number of counters

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

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

16. Performance evaluation

17. Performance evaluation • 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.

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