Traffic monitoring in software
dataplane: a generic accuracyaware adaptive solution
Daphné Tuncer
Department of Computing
Imperial College London (UK)dtuncer@ic.ac.uk
18/02/2020

Collaborative work with

Gioacchino Tangari (leading efforts – Macquarie University)
Marinos Charalambides (UCL)
George Pavlou (UCL)

D. Tuncer2

Managing networks is hard
Online SocialMedia
SmartCities

Rich Multimedia
Distribution
Device configuration
Traffic analysis
Job schedulingfunctionfunctionfunction
Traffic engineering
VM
migration
Path management
functionfunction
Firmware upgrade
function
Energy savings
function
Server selectionfunction
function

Complex systems
challenging to manage
D. Tuncer

Computation and Storage
Services
Online Gaming

Demand agility, flexibility,
adaptability and reactivity
3

Advances in networking have brought promises

Enable reactive behaviour in
response to emerging
requirements

New opportunities for effective network resource management
Quickly adapt and react to network and traffic dynamics
Configuration flexibility
Express high-level operators’ policies

D. Tuncer

4

A key functionality: monitoring
Goal: provide efficiency
Management System

Management
functionsTraffic loadbalancing
Anomalydetection………

Monitoring

Energy-saving
managementCollect statistics
from the network
resources
D. Tuncer

Apply new configurationsin the network
5

What is efficient monitoring?
Detailed information
Identify congestion, DDoS attacks, unresponsive servers, …

Timely reports
Detect short-lived episodes, support fast resourcereconfigurations, …

D. Tuncer

6

Well, easy?...
Reality: hard to produce detailed and timely reports
Hardware & resource constraints
Large scale settings
Massive and dynamic network traffic

On top of that constraints on the monitoring system
Scalability requirements
Good accuracy/resource usage trade-offs
Firestone et al. “a physical core sells for $0.10-0.11/hr, […] a maximum potential
revenue of around $900/yr” [FirestoneNSDI18]

Designing efficient monitoring for software-based networks
D. Tuncer

7

Traffic monitoring in software dataplane

Measurement Task: involves a set ofMonitoring States
operations (e.g., sum bytes)
State1 : Count
State 2: Count + Heavy HitterState 3: Count + Heavy Hitter + Retransmission
State 4: Count + Heavy Hitter + Retransmission + Bursty Flow
State 5: Count + Heavy Hitter + Retransmission + Bursty Flow + Latency Change
D. Tuncer

8

Traffic monitoring in software dataplane

D. Tuncer

9Traffic monitoring in software dataplane

Limited total time budget available=> Potential packet loss at the buffers in case of bottlenecks
Monitoring States
S1 26 ns for processing
S2 87 ns for processing
S3 96 ns for processing
S4 122 ns for processing
S5 163 ns for processing
D. Tuncer

10

Traffic monitoring in software dataplane

Limited total
time budgetoperations
available at runHow to reconfigure
monitoring=> Potential
at thebuffer(s) in conditions?
case of bottlenecks
time topacket
copelosswithemergingMonitoring States
S1 26 ns for processing
S2 87 ns for processing
S3 96 ns for processing
S4 122 ns for processing
S5 163 ns for processing
D. Tuncer

11

Solution: adapting monitoring at run-time
Detect changes in operating conditions in a timely manner
Dynamically reconfigure (per flow) measurement
operations
Monitoring States
S1
S2
S3
S4
Adjust packet
S5processing time

Monitoring States
S1
S2
S3
S4
S5

No need of overprovisioning
D. Tuncer

12

Yes, but how do you…
1. Preserve monitoring report accuracy?
2. Avoid packet starvation (i.e., all packets processed intime)?
3. Guarantee low computation overhead (no more than 1%CPU-time)?

D. Tuncer

13Key idea: estimating per-packet processing time
Total expected time of a packet in the monitoring pipeline
Packet rate

Retrieval of existing flow
entry information based onwhether this is in cache(Hit) or memory (Miss)

Insertion of a newflow entry

Targeted per packet time

D. Tuncer

14

MONA

D. Tuncer

15

Time profiling and estimation
Benchmarking of retrieval andinsertion times

Based on sampling

D. Tuncer

16Adaptation routineCountCount +Bursty FlowCount + Bursty Flow +Latency Change

Two strategies
Greedy: adaptation applied to random sets of flow-entries
Low-States-First (LSF): downgrade in priority flows mapped toless advanced monitoring states (except s1)

D. Tuncer

17

Monitoring accuracy control
Objective:
To re-adjust flow allocations in order to satisfy a global
accuracy threshold for all tasks

Two main steps:
1. To quantify the effect of adaptations on report accuracy

2. To recover accuracy gaps by re-adjusting flow allocation

D. Tuncer

18

Task generic online accuracy estimation
Accuracy estimated through the recall

Let’s expand N^Miss# flows dropped fortask i from adaptation

unknown# events for a missing flow

Objective: find an estimator for X^Miss
D. Tuncer

19

Task generic online accuracy estimation (con’t)
Our solution: risk minimization strategy

Best estimator for X^Miss = one minimizing risk function R

D. Tuncer

20

Recovering accuracy gaps
Solution: the Richs give to the Poors
Re-allocation of flows from monitoring states with rich tasks tomonitoring states with poor tasks

D. Tuncer

21

MONA implementation• Implemented in C
Generic monitoring pipeline based on a single flow-table• Flow-table realized as a hash-table
Table size = 2^20 entries to limit hash collisions• Flow-entry size = 64 bytes (fit within a single cache)• Packet trace generated based on reported flow statistics
in Facebook data centers [RoySIGCOMM15]

D. Tuncer

22

MONA evaluation setup
Evaluation with four measurement tasks
Heavy Hitter detection (HH)
Bursty flow detection (Bursty)
Latency Change detection (LatChange)
ReTransmission detection (RTx)

Two monitoring state configurations

D. Tuncer

23

How do we validate MONA?
1. How does adaptive traffic monitoring perform in termsof packet loss risk and adaptation responsiveness ?
2. What is the impact of monitoring adaptation andaccuracy control on the measurement tasks?
3. What are the throughput limiting factors for MONA?
4. What is the overhead of our solution?

D. Tuncer

24

MONA robustness to changing conditions

MONA prevents packet loss and preserves packet balance

D. Tuncer

25

MONA measurement tasks accuracy

MONA maintains monitoring report accuracy
D. Tuncer

26MONA throughput limiting factors
Impact of hash collisions

D. Tuncer

Impact of uniform traffic(DoS attack)27

MONA overhead

MONA enables short timescale re-configurations (every 10ms),
with no additional processor core(s) and minimal CPU-timeoverhead (~1-2%),
D. Tuncer

28

Concluding remarks
1. Timely and accurate resource monitoring fundamental
for any network management system
2. Self-adaptive monitoring approaches as drivers toresponsiveness and flexibility
3. Our solution: MONA
Adaptive monitoring framework offering resilience to bottlenecks+ preservation of monitoring accuracy

D. Tuncer

29

Used references[FirestoneNSDI18] D. Firestone, et al., "Azure accelerated networking: SmartNICs in thepublic cloud," 15th USENIX Symposium on Networked Systems Design and Implementation(NSDI), 2018.

[RoySIGCOMM15] A. Roy, et al., "Inside the social network's (datacenter) network,"
Proceedings of the 2015 ACM Conference on Special Interest Group on Data
Communication (SIGCOMM), 2015.

D. Tuncer

30

Our papers[TON20] G. Tangari, M. Charalambides, D. Tuncer, G. Pavlou, "Accuracy-Aware Adaptive
Traffic Monitoring for Software Dataplanes, " to appear in IEEE Transactions on Networking(ToN), 2020.
[TNSM18] G. Tangari, D. Tuncer, M. Charalambides, Y. Qi and G. Pavlou, "Self-Adaptive
Decentralized Monitoring in Software-Defined Networks," in IEEE Transactions on Networkand Service Management (TNSM), 2018.

[CNSM17] G. Tangari, M. Charalambides, D. Tuncer, G. Pavlou, "Adaptive Traffic Monitoringfor Software Dataplanes," in the Proc. of the 13th IFIP/IEEE International Conference on
Network and Service Management (CNSM'17), Tokyo, Japan, November 2017.

[IM17] G. Tangari, D. Tuncer, M. Charalambides and G. Pavlou, "Decentralized Monitoringfor Large-Scale Software-Defined Networks," to appear in the Proc. of the IFIP/IEEE
Integrated Management Symposium (IM'17), Lisbon, Portugal, May 2017.
D. Tuncer

31