SDProber: Software Defined Prober Sivaramakrishnan Ramanathan 1 , - - PowerPoint PPT Presentation

sdprober software defined prober
SMART_READER_LITE
LIVE PREVIEW

SDProber: Software Defined Prober Sivaramakrishnan Ramanathan 1 , - - PowerPoint PPT Presentation

SDProber: Software Defined Prober Sivaramakrishnan Ramanathan 1 , Yaron Kanza 2 and Balachander Krishnamurthy 2 1 University of Southern California 2 AT&T Labs Research 1 Delay Measurements Persistent delays in networks cause adverse


slide-1
SLIDE 1

SDProber: Software Defined Prober

Sivaramakrishnan Ramanathan1, Yaron Kanza2 and Balachander Krishnamurthy2

1University of Southern California 2AT&T Labs Research

1

slide-2
SLIDE 2

Delay Measurements

  • Persistent delays in networks cause adverse effects
  • Disrupts quality of service in applications impacting revenue
  • Delay measurements needs to be done constantly
  • Trade-off between detection time and measurement cost
  • Lack of measurements increases detection time
  • Frequent measurements affect the network
  • Network operator needs to balance between measurement cost and

detection time

2

slide-3
SLIDE 3

Measurements with bounds

  • Bounding measurements can help in balancing the measurement cost

and detection time to the network operator

  • Lower bound specifies the minimum number of inspections which needs to

be performed on link

  • Upper bound limits the the number of inspections performed on link
  • Existing tools such as ping and traceroute cannot apply such bounds
  • Depends on the underlying routing algorithm which is inflexible
  • Finding the optimal solution with pre-defined path solution is NP-hard

3

slide-4
SLIDE 4

SDProber – Software defined prober

  • SDProber allows adaptable and efficient delay measurements in

networks with bounded constraints

  • SDProber uses probe packets to estimate the time taken for traversing

every link

  • Probes in SDProber take a pseudo-random walk in a weighted graph
  • Avoids complex computation
  • Weights are adapted to satisfy rate constraints on links
  • send more probe packets to links where lower bounds are not satisfied
  • send less probe packets to links where upper bounds are satisfied

4

slide-5
SLIDE 5

SDProber – System Overview

Add mirroring/forwarding rules S1 S2 Time of arrival from S1 : t1 Time of arrival from S2 : t2 Delay=t2-t1

5

slide-6
SLIDE 6

SDProber – Pseudo random walk

  • For every probe packet, the initial starting node and each traversing

link are selected randomly

  • By altering the initial node weights or weights on choosing the next

node, SDProber can control how probe packets inspect the network

  • Easily adapts to changes in probing constraints or network
  • Reduces costs
  • Implementation of Random walk is done using Openvswitches group

tables and forwarding rules

6

slide-7
SLIDE 7

SDProber – Pseudo random walk

  • SDProber uses binary exponential backoff to adjust weights
  • Initial node weights and link weights are adjusted
  • Doubled/halved when probing rates are less/more than constraint

Destination MAC

  • f probe packet

Destination MAC mirrored probe packet Forward to Group Table in ALL mode Forward packet to collector Decrement TTL and forward to Group Table in SELECT mode Change DST MAC, update UDP SRC port and forward to collector Forward to port P1 Forward to port P2 Forward to port Pn W1 W2 Wn

Match Action Group table in ALL mode Group table in SELECT mode

7

Guides different types

  • f probe packets

Mirrors probe packets Implements random walk

slide-8
SLIDE 8

Evaluation: Competing approaches

  • Two approaches that use shortest path to send probe packets
  • In each approach, the probe packet is mirrored at every node it

traverses

  • Random Pair Selection (RPS)
  • For every iteration, source and destination pairs are selected randomly and

probe packets are sent through the shortest path between them

  • At every iteration, source and destination pairs are selected from pairs which

have not been selected before

  • Greedy Path Selection
  • At each iteration, pairs of source and destination are selected such that the

sum of min-rate values of all unvisited links on paths is maximum

8

slide-9
SLIDE 9

Evaluation: Setup

  • Tested on 196 nodes + 243 links real topology
  • Probing iteration was launched every 30 seconds
  • Evaluated results on three probing profiles(small, medium, large)

having different min-rate, max-rate

  • Network operators could choose probing rates based on SLA or historically

analyzing delays

9

slide-10
SLIDE 10

Evaluation: Control over inspection

  • Red line indicates the probability of traversing through link
  • Blue line is the number of probe packets which traversed each link
  • Error is ±10% from expected value

20 40 60 80 100 120 140 160 180 200 . 2 . 4 . 6 . 8 . 1 . 1 2

  • Avg. number of probe packets

Probabilities Small Medium Large Expected

10

slide-11
SLIDE 11

Evaluation: Cost effectiveness

  • For each method, we increased the number of emitted probe packets

per iteration till min-rate constraints are satisfied

  • SDProber sends 4—12 times fewer probe packets than RPS and greedy
  • While satisfying min-rates on all links, SDProber sends 10—62 times fewer

excess probe packets than RPS and greedy

200 400 600 800 1000 1200 1400 1600

Small Medium Large

  • Avg. number of probe packets

per edge

Probing profiles SDProber Greedy RPS 200 400 600 800 1000 1200 1400 1600

Small Medium Large

  • Avg. number of excess

probe packets sent per edge

Probing profiles SDProber Greedy RPS

11

slide-12
SLIDE 12

Conclusion

  • SDProber provides an efficient and flexible delay measurements with

measurement constraints on inspection rates

  • SDProber uses probe packets to estimate delay on links
  • Probes take a pseudo random walk
  • Weights are adapted using binary exponential backoff to satisfy

inspection rate constraints

  • Evaluated SDProber on a real world ISP topology to show SDProber’s

control over probe packets and cost effectiveness

12

slide-13
SLIDE 13

Evaluation: Detection time

  • SDProber detects delays twice as fast as greedy
  • Links with low weights are visited last in greedy
  • SDProber and RPS have comparable detection time
  • But RPS sends more packets to satisfy rate constraints

20 40 60 80 100 120 140 160 1 2 3 4 5 6 7 8 9 1 Time (s) % of delayed links Greedy RPS SDProber

13

slide-14
SLIDE 14

Evaluation: Learning

  • Varied % of historically delayed links
  • When there are more historically delayed links, increasing ⍺ reduces

detection time by 2—6%

  • When there are no historically delayed links, increasing alpha

increases detection time by 4%

10 20 30 40 50 60 70 80 90

0% FDL 50% FDL 100% FDL

Time (s)

α2 α2.4 α2.8 α3.2 α3.6 α4

14

slide-15
SLIDE 15

Choosing probing profiles

  • Using SLA associated with customers
  • 99.9% uptime equates to 45 minutes of down time per month
  • Network operators can set the min-rate of probing such that the delayed links

are detected with guarantees

  • Using historical delay data
  • Links which have history of congestion can be probed more

15

slide-16
SLIDE 16

Guarantees and convergence

  • SDProber attempts to satisfy rate constraints with minimum

violations given several parameters (TTL, packets available per iteration)

  • Inspecting each link can provide tighter guarantees
  • But is expensive, requires more probe agents and is inefficient
  • Random walk provides guarantees on inspection, provided there are

enough probe packets per iteration

  • Binary exponential backoff helps in expediting the satisfaction of

constraints

  • There is no convergence – measurements are continuous and constraints are

used as a driving factor for faster detection with low costs

16

slide-17
SLIDE 17

Timestamp

  • SDProber detects persistent delays in WAN where delays are usually

in milliseconds

  • Delay between switches and collector can be estimated using ping
  • Delays on link could therefore be bounded
  • Using historical measurements, delays greater than a particular threshold can

be alerted to the network operator

  • Timestamping can be done on packets using INT
  • Requires that there is clock synchronization at all switches

17