BeauCoup

Abstract

Network administrators constantly monitor network trac for congestion and attacks. They need to perform a large number of measurements on the trac simultaneously, to detect dierent types of anomalies such as heavy hitters or super-spreaders. Existing techniques often focus on a single statistic (e.g., trac volume) or trafc attribute (e.g., destination IP). However, performing numerous heterogeneous measurements within the constrained memory architecture of modern network devices poses signicant challenges, due to the limited number of memory accesses allowed per packet. We propose BeauCoup, a system based on the coupon collector problem, that supports multiple distinct counting queries simultaneously while making only a small constant number of memory accesses per packet. We implement BeauCoup on PISA commodity programmable switches, satisfying the strict memory size and access constraints while using a moderate portion of other data-plane hardware resources. Evaluations show BeauCoup achieves the same accuracy as other sketch-based or sampling-based solutions using 4x fewer memory access.

Network Monitoring on Multi-Pipe Switches

“…Background on FCM-Sketch [64]. FCM-Sketch has three levels of Count-Min sketches with decreasing the number of elements and increasing element size (e.g., the 1 𝑠𝑡 level contains 2 19 8-bit entries while the 3 𝑟𝑑 level contains 2 13 32-bit entries). A packet belonging to one traffic class increases an entry by 1 at level 𝑖 only if the corresponding entry of the indexed element at level 𝑖 − 1 has reached the maximum value (e.g., an entry at level 2 is increased by 1 only if the traffic class entry at the level 1 is 255).…”

“…PipeCache brings benefits to existing multi-query monitoring systems. We implement Beaucoup [19] to support two queries at the same time: i) detecting IP source address super spreaders and ii) IPpair heavy hitters. We select these two types of queries for two reasons.…”

“…First, the traffic classes are defined at different granularities, i.e., in the super-spreader query a traffic class is an IP address while in the heavy-hitter query it is a pair of IP addresses. Second, the type of "counting" (i.e., the so-called attribute of the query [19]) is different, i.e., in the super-spreader query, we count distinct elements while in the heavy-hitter query we count the number of packets. We note that the size of the cache element in PipeCache does not necessarily increase with the number of supported queries.…”

“…Existing monitoring solutions store statistics about the forwarded traffic at different granularities, which we call monitored traffic classes, depending on the specific use case. For instance, network operators monitor each single TCP connection for rerouting large flows [3] whereas they monitor all traffic from each source IP addresses for super spreader detection [19].…”

“…Moreover, switches are equipped with internal recirculation ports that avoid consuming the bandwidth available on the external ports connected to the switch [39]. We evaluate PipeCache using existing real-world traffic traces augmenting both FCM-Sketch [64], Elastic-Sketch (ES) [74], Hy-perLogLog [25], MRAC [47], Beaucoup [19], and FlowLens [7] for different monitoring tasks: heavy-hitter detection, super-spreader detection, and entropy estimation of the flow distribution. Figure 1 shows that PipeCache reduces the memory requirements to achieve a certain accuracy level (i.e., an F1-score of 0.9 for heavyhitter detection) by up to 7x and 2x compared to a baseline deployment of Elastic-Sketch and FCM-Sketch on a 16-pipe switch, respectively.…”