One Sketch to Rule Them All: Rethinking Network Flow Monitoring - - PowerPoint PPT Presentation

one sketch to rule them all rethinking network flow
SMART_READER_LITE
LIVE PREVIEW

One Sketch to Rule Them All: Rethinking Network Flow Monitoring - - PowerPoint PPT Presentation

One Sketch to Rule Them All: Rethinking Network Flow Monitoring with UnivMon Zaoxing Liu, Antonis Manousis, Greg Vorsanger, Vyas Sekar, and Vladimir Braverman Many Monitoring Requirements Traffic Engineering Anomaly Detection Flow Size


slide-1
SLIDE 1

One Sketch to Rule Them All: Rethinking Network Flow Monitoring with UnivMon

Zaoxing Liu, Antonis Manousis, Greg Vorsanger, Vyas Sekar, and Vladimir Braverman

slide-2
SLIDE 2

Many Monitoring Requirements

2

Traffic Engineering

“Flow Size Distribution”

Anomaly Detection

“Entropy”, “Traffic Changes”

Worm Detection

“SuperSpreaders”

Accounting

“Heavy Hitters”

  • Who’s sending a lot more traffic than 10min ago? (Change)
  • Who’s sending a lot from 10.0.1.0/16? (Heavy Hitter)
  • Are you being DDoS-ed?
slide-3
SLIDE 3

Traditional: Packet Sampling

1 6 1 3 1

1

Flow reports

1

Prior work: Not good for fine-grained analysis!

1 1 3 1 6 1 1 1 1 3 1 6 1 1

1 2

Sample packets at random, group into flows

FlowId Counter

Flow = Packets with same pattern Source and Destination Address and Ports

Estimate: FSD, Entropy, Heavy Hitters …

3

slide-4
SLIDE 4

Alternative: App-Specific Sketches

Packet Processing Counter Data Structures Application-Level Metric

Heavy Hitter Entropy Superspreader

Higher Complexity with more applications Higher development time as new applications appear Tight Binding between monitoring data and control plane

….

Packet Processing Counter Data Structures Application-Level Metric Packet Processing Counter Data Structures Application-Level Metric

….

Traffic

4 Pre-deployed Algorithms

slide-5
SLIDE 5

Motivating Question

5

XO XOR Today AN AND

Can we achieve this

e.g., NetFlow e.g., Sketches

Generality Late Binding Fidelity

slide-6
SLIDE 6

UnivMon Vision

Control Plane Data Plane

  • One Sketch for multiple tasks
  • Naturally Late-binding

6

Packet Processing “General” Sketch

App 1

Application-specific Computation

App n

…... Traffic Update Counters Configure Report

slide-7
SLIDE 7

Many Natural Challenges!

Does such a construction exist? If it exists, is it feasible to implement? Does it extend to a network-wide setting?

e.g., Multiple paths, Multiple dimensions

Is it competitive w.r.t. custom algorithms?

7

slide-8
SLIDE 8

This Talk

Does such a construction exist? If it exists, is it feasible to implement? Does it extend to a network-wide setting?

e.g., Multiple paths, Multiple dimensions

Is it competitive w.r.t. custom algorithms?

8

slide-9
SLIDE 9

This Talk

Does such a construction exist? If it exists, is it feasible to implement? Does it extend to a network-wide setting?

e.g., Multiple paths, Multiple dimensions

Is it competitive w.r.t. custom algorithms?

9

slide-10
SLIDE 10

Concept of Universal Streaming

1 3 3 1 5 1 1 2 4 6 5

…...

10

frequency vector < f1,f2 … fn >

  • Basic Streaming Algorithms:

Frequency Moments Fk = ∑ 𝑔

# $ % #&'

F2 : AMS Sketch, Count Sketch …... One algorithm solves one problem

  • Universal Streaming?

1 3 3 1 5 1 1 2 4 6 5

…... frequency vector < f1,f2 … fn >

G-sum = ∑ 𝑕(𝑔

#) % #&'

Universality: arbitrary g() function? (A stream of length m with n unique items)

slide-11
SLIDE 11

Theory of Universal Streaming [BO’10, BO’13]

Thm 1: There exists a universal approach to estimate G-sum when g() function is non-decreasing such that g(0)=0, and 𝑕(𝑔

#)

doesn’t grow monotonically faster than 𝑔

#2 .

11

Thm 2: A universal sketch construction can be used to estimate G- sum with high probability using polylogarithmic memory.

slide-12
SLIDE 12

Intuition of Universal Sketch

12

Informal Definition: Item 𝑗 is a 𝑕-heavy hitter if changing its frequency 𝑔

# significantly affects its G-sum.

Case 1: there is one sufficiently large a 𝑕-heavy hitter Most of mass is concentrated in this heavy hitter. Use L2 Heavy-Hitter algorithm to find such a heavy hitter. Case 2: there is NO single sufficiently large 𝑕-heavy hitter Find heavy hitters on a series of sampled substreams of increasingly smaller size.

slide-13
SLIDE 13

Universal Sketch Data Structure

1 3 3 1 5 1 1 2 4 6 5 1 1 5 1 1 2 5 2

L2 Heavy Hitter(HH) Alg (1,4), (3,2),(5,2) (1,4), (5,2),(2,1) …... (2,1) (5,2), (2,1) 1 log(n)

…...

2 5 5

Levels

Heavy Hitter Alg Heavy Hitter Alg Heavy Hitter Alg Heavy Hitter Alg

In Parallel

Heavy Hitters and Counters

13

Generate log(n) substreams by zero-one hash funcs H1….Hlog(n) Count-Sketch etc. Estimated G-sum

slide-14
SLIDE 14

This Talk

Does such a construction exist? If it exists, is it feasible to implement? Does it extend to a network-wide setting?

e.g., Multiple paths, Multiple dimensions

Is it competitive w.r.t. custom algorithms?

14

slide-15
SLIDE 15

How to Map to P4

1 3 3 1 5 1 1 2 4 6 5 1 1 5 1 1 2

(1,4), (3,2),(5,2) (1,4), (5,2),(2,1) …... (2,1) 1 log(n)

…...

2 5

Heavy Hitter Alg Heavy Hitter Alg Heavy Hitter Alg

15

Estimated G-sum

Sampling Sketching Top-K App-Estimation …...

slide-16
SLIDE 16

Mapping to P4

16

Sampling Sketching Top-K App-Estimation

P4 Hash Funcs P4 Registers Hash Funcs + P4 Registers Custom Libraries

slide-17
SLIDE 17

Top-K Stage on Switch

17

HW Complexity (need Priority Queue) Storage/Comm Overhead (report to controller) Hard in hardware

Sampling Sketching Top-K App-Estimation

slide-18
SLIDE 18

Split Top-K Stage

18

Sampling Sketching Top-K App-Estimation

HW Complexity (w/o Priority Queue) Storage/Comm. Overhead (report to controller) Several MBs more

slide-19
SLIDE 19

19

Sampling (Hash func)

Sketching P4 register

App 1

Application-specific Computation

App n

…... Traffic Update Counters

Implementation Summary

Top-K Possible keys Top-K

Sketching Sampling Top-K App-Estimation

slide-20
SLIDE 20

This Talk

Does such a construction exist? If it exists, is it feasible to implement? Does it extend to a network-wide setting?

e.g., Multiple paths, Multiple dimensions

Is it competitive w.r.t. custom algorithms?

20

slide-21
SLIDE 21

Network-wide Problem

21

O1 O2 A B D1 D2

N nodes D dimensions (e.g., src, srcdst)

Trivial sol: place D*N sketches Our goal: Place s sketches, where s<<D*N One-big-switch abstraction

D D D D D D One sketch for each dim

𝐸 2 𝐸 2

slide-22
SLIDE 22

This talk

Does such a construction exist? If it exists, is it feasible to implement? Does it extend to a network-wide setting?

e.g., Multiple paths, Multiple dimensions

Is it competitive w.r.t. custom algorithms?

22

slide-23
SLIDE 23

Evaluation Setup

  • Traces: CAIDA backbone traces
  • Split into different “epoch” durations
  • Memory setup: 600KB—5MB
  • Application metrics: HH, Change, DDoS, etc.
  • Custom algorithms from OpenSketch

23

slide-24
SLIDE 24

UnivMon is Competitive Per-App

Max error gap < 3.6%; Results hold across multiple traces

24

N/A

slide-25
SLIDE 25

Clear advantages when handling more applications

25

UnivMon Better for Larger Portfolio

slide-26
SLIDE 26

Memory needs are reasonable

200 300 5s 30s 1m 5m Memory Usage (KB) Monitoring Time Interval

OS-trace1 OS-trace2 OS-trace3 OS-trace4 OS-trace5 UM-trace1 UM-trace2 UM-trace3 UM-trace4 UM-trace5

Slow increase (logarithmically) and supports larger windows

26

slide-27
SLIDE 27
  • Network management needs many metrics
  • Traditional: Generality XOR Fidelity
  • E.g., NetFlow vs Custom Sketches
  • New opportunity: Universal Sketches!
  • Generality AND Fidelity AND Late Binding
  • UnivMon brings this opportunity to fruition
  • Practical, realizable in P4
  • Comparable (and better) than custom
  • Amenable to “network-wide” abstractions
  • Many exciting future directions:
  • Theoretical improvements, Native multidimensional, etc.

Conclusions

27

slide-28
SLIDE 28

Network-wide coordination helps

28

500 1000 1500 2000 ATT-N.A. GEANT BellSouth Average Memory(KB) Network Wide Evaluation (600KB per sketch) Ingress Greedy-D.&C. Q.&S. UnivMon