Heavy-Hitter Detection Entirely in the Data Plane VIBHAALAKSHMI - PowerPoint PPT Presentation

Heavy-Hitter Detection Entirely in the Data Plane VIBHAALAKSHMI SIVARAMAN SRINIVAS NARAYANA, ORI ROTTENSTREICH, MUTHU MUTHUKRSISHNAN, JENNIFER REXFORD 1

Heavy Hitter Flows Flows above a certain threshold of total packets “Top - k ” flows by size Port: 22, Count: 100 Port: 30, Count: 200 k = 2 Port: 15, Count: 200 Port: 80, Count: 100 2

Why detect heavy hitters? Trouble-shooting and anomaly detection Dynamic routing or scheduling of heavy flows f1 f1 Flow Count f2 f2 f1 100 f2 75 f3 5 3

Problem Statement Restrict processing to data plane Low data plane state High accuracy Line-rate packet processing 4

Emerging Programmable Switches Programmable switches with stateful memory Basic arithmetic on stored state Pipelined operations over multiple stages State carried in packets across stages Stage 2 Stage 1 Stage 3 Stage 4 Packet p 5

Constraints Small, deterministic time budget for packet processing at each stage Limited number of accesses to stateful memory per stage Limited amount of memory per stage No packet recirculation 6

Existing Work Technique Pros Cons Sampling-based (Netflow, Small “flow memory” to Underestimates counts sflow, Sample & Hold) track heavy flows for heavy flows Sketching-based (Count, Statistics for all flows in No flow identifier to Count-Min, Reversible) single data structure count association Counting-based ( Space Summary structure with Occasional updates to Saving , Misra-Gries) heavy flow ids and multiple counters counters 7

Motivation: Space-Saving Algorithm 1 O ( k ) space to store heavy flows Provable guarantees on accuracy Evict the minimum to insert new flow Multiple reads but exactly one write per packet 1 Metwally, Ahmed, Divyakant Agrawal, and Amr El Abbadi. "Efficient computation of frequent and top-k elements in data streams." International Conference on Database Theory . Springer Berlin Heidelberg, 2005. 8

Space Saving Algorithm Flow Id Packet Flow Id Packet High accuracy Count Count Exactly one write K1 4 K1 4 K2 2 K2 2 K3 7 K3 7 New K4 10 Key K6 K4 10 K5 1 Entire table scan K6 2 Complex data structures 9

Towards HashPipe Technique Pros Cons Space-Saving High accuracy; Exactly one Entire table scan; write-back Complex data structures HashParallel Sample fixed number of Multiple reads per stage; locations; Approximate Dependent write-back minimum Sequential Minimum Hash table spread across Multiple passes through Computation multiple stages; Sample one the pipeline location per stage 10

Our Solution - HashPipe Always insert new key in the first stage Hash to index to a location Carry evicted key to the next stage Stage 2 Stage 3 Stage 1 K2 3 G 4 A 5 New key K D 15 K3 3 K1 4 E 25 H 10 B 6 h 1 (K) -> K1 C 10 F 100 I 9 11

Our Solution - HashPipe At each later stage, carry current minimum key Hash on carried key to index to a location Compare against key in location for local minimum Stage 2 Stage 3 Stage 1 D 3 G 4 A 5 E 15 K3 3 K 1 (K1, 4) K2 25 H 10 B 6 C 10 F 100 I 9 12

HashPipe At any table stage, retain the heavier hitter h 2 (K1) -> K2 Max (K1, K2) -> K2 Stage 1 Stage 2 Stage 3 A 5 D 3 G 4 K 1 E 15 K3 3 (K1, 4) B 6 K2 25 H 10 C 10 F 100 I 9 13

HashPipe At any table stage, retain the heavier hitter h 3 (K1) -> K3 Max (K1, K3) -> K1 Stage 1 Stage 2 Stage 3 A 5 D 3 G 4 (K1, 4) K 1 E 15 K3 3 B 6 K2 25 H 10 C 10 F 100 I 9 14

HashPipe At any table stage, retain the heavier hitter High accuracy Eventually evict a relatively small flow Single pass One read/write per stage Stage 1 Stage 2 Stage 3 A 5 D 3 G 4 K 1 E 15 K1 4 B 6 K2 25 H 10 C 10 F 100 I 9 Duplicates 15

HashPipe Summary Split hash table into d stages Condition Stage 1 Stages 2 - d Empty Insert with value 1 Insert key and value carried Match Increment value by 1 Coalesce value carried with value in table Mismatch Insert new key with value 1, Keep key with higher value evict and carry key in table and carry the other 16

Implementation Prototyped on P4 Packet Register Hash on metadata arrays packet header Stage 2 Stage 3 Stage 1 New key K K2 3 G 4 A 5 D 15 H 3 K1 4 (K1, 4) E 25 K3 10 B 6 C 10 F 100 I 9 Conditional updates to compute minimum 17

Evaluation Setup Top- k 5 tuples on CAIDA traffic traces with 500M packets 50 trials, each 20 s long with 10M packets and 400,000 flows Memory allocated: 10 KB to 100 KB; k value: 60 to 300 Metrics: false negatives, false positives, count estimation error 18

Tuning HashPipe k = 210 5040 flowids maintained in table 19

HashPipe Accuracy 5-10% false negatives for detecting heavy hitters 20

HashPipe Accuracy 5-10% false negatives for the detecting heavy hitters 4500 flow counters on traces with 400,000 flows 21

HashPipe Accuracy 5-10% false negatives for the detecting heavy hitters 4500 flow counters on traces with 400,000 flows 22

Competing Schemes Sample and Hold ◦ Sample packets of new flows ◦ Increment counters for all packets of a flow once sampled Count-Min Sketch ◦ Increment counters for every packet at d hashed locations ◦ Estimate using minimum among d location ◦ Track heavy hitters in cache 23

HashPipe vs. Existing Solutions 24

HashPipe vs Existing Solutions 25

HashPipe vs Existing Solutions 26

Contributions and Future Work Contributions: o Heavy hitter detection on programmable data planes o Pipelined hash table with preferential eviction of smaller flows o P4 prototype - https://github.com/vibhaa/iw15-heavyhitters Future Work: o Analytical results and theoretical bounds o Controlled experiments on synthetic traces 27

THANK YOU vibhaa@princeton.edu 28

Backup Slides 29

P4 prototype – Stage 1 30

P4 prototype – Stage 2 onwards 31

HashPipe vs Idealized Schemes Performance of three schemes is comparable HashPipe may o utperform SpaceSaving 32

Programmable Switches New switches that allow us to run novel algorithms Barefoot Tofino, RMT, Xilinx, Netronome, etc. Languages like P4 to program the switches 33