BLUE

1
BLUE Stochastic Fair BLUE (SFB)

• 1 BLUE A New Class of Active Queue Management
  Algorithms
• 2 Stochastic Fair Blue A Queue Management
  Algorithm for Enforcing Fairness
• -- by W. Chang, D. Kandlur, D. Saha and K. Shin
• Presenter Chunyu Hu Feb. 26, 2002

2
Overview

• Part I BLUE
• Motivation
• Algorithm
• Simulations
• Observations Conclusions

• Part II Stochastic Fair BLUE (SFB)
• Motivation
• Algorithm
• Simulation
• Comparisons
• Conclusions

3
Part I. Motivation

• Weakness of the TCPs congestion control scheme
• -- backoff after packet loss
• A solution RED
• Idea
• detect congestion early and notify the end hosts
• Congestion Indicator Queue length

4
Part I. Motivation

• A solution RED
• Pro Keep average queue size low and allow
  occasional bursts
• Con
• Possible underutilization of link capacity in
  case of serious burstness
• Need considerable buffer space
• however, add end-to-end delay and delay jitter
• Cannot differ congestion caused by a large number
  of sources or by a single aggressive source
• Difficulty in setting parameters adaptively

5
Part I. BLUEs Objective

• Minimize packet loss and queueing delay
• Avoid global synchronization of sources
• Maintain high link utilization
• Remove biases against bursty sources
• HOW ?

6
Part I. BLUEs Algorithm (I)

• Upon Packet loss ( or Qlen gt L) event
• if (now last_update ) gt freeze_time ) then
• pm pm d1
• last_update now
• Upon link idle event
• if (now- last_update) gt freeze_time ) then
• pm pm d2
• last_update now

7
Part I. BLUEs Algorithm (II)

• Update trigger events
• Packet loss increase dropping probability
• Link idle decrease dropping probability
• Parameters
• freeze_time update frequency, could be
  randomized to avoid global synchronization

8
Part I. BLUEs Algorithm (III)

• Parameters
• d1 increment step
• d2 decrement step
• d1 is signification larger than d2
• backoff more aggressively

9
Part I. Simulation Scenario (I)
10
Part I. Simulation Scenario (II)

• Traffic 5 connections, pareto on/off src.
  with ECN.
• RED
• (minth, maxth) (20, 80) of the queue size
• maxp 1
• wq 0.002, 0.002, 0.02 and 0.2, for R1, R2, R3
  and R4, respectively

11
Part I. Simulation Scenario (III)

• BLUE
• (freeze_time, d1, d2)
• (10ms, 0.0025, 0.00025),
• (100ms, 0.0025, 0.00025),
• (10ms, 0.02, 0.002), and
• (100ms, 0.02, 0.002), for B1, B2, B3 and B4,
  respectively

12
Part I. Simulation Results

• Loss rates
• Link utilization

13
Part I. Observations

• BLUE loses much less packets
• BLUE needs a small amount of buffer space
• RED itself performs better with small wq,
• -- less dependent on the queue size (like BLUE)
• or at certain operating points
• -- deterministic mark every marks (like BLUE)
• BLUE maintains the queue length more stable

14
Part I. Conclusions

• Pro
• packet loss -- BLUE outperforms RED significantly
  with less buffer
• Avoid the global synchronization -- BLUE does
  better
• Eliminate biases against bursty sources -- BLUE
  does equal well
• Con
• Failing scenario when every packet is marked,
  but the sources are still overloading the bottle
  neck link
• (for both BLUE and RED)

15
Part II. Stochastic Fair BLUE (SFB)

16
Part II. SFB Motivation

• Goal Protect TCP flows against non-responsive
  flows
• Basic idea Detect non-responsive flows and limit
  their rates so that they do not impact the
  performance of responsive flows

17
Part II. SFB Algorithm

• Bloom Filter BLUE

18
Digression Bloom Filter (I)

• www.cs.wisc.edu/cao/papers/summary-cache/node8.ht
  ml
• Definition A probabilistic algorithm to quickly
  test membership in a large set using multiple
  hash functions into a single array of bits.
• invented by Burton Bloom in 1970
• Application Web caching, word-spelling check,
  etc.

19
Digression Bloom Filter (II)

• Algorithm
• Insert. A k-bit vector A is hashed into k bits in
  the m-bit filter using a set of k hash functions.
  The mapped position is marked with 1.
• Insert n vectors in all.
• Query whether a vector B has already been
  inserted.
• Map B into the filter, check whether all the
  mapped positions are marked with 1. If yes,
  return success.

20
Digression Bloom Filter (III)

• False Positive decide a match is falsely
  successful.
• Pfalse positive
• An example

21
Digression Bloom Filter (IV)

• Application in SFB
• The filter is an L-level, N-bin-per-level bins
  matrix. Every bin is specified by the size.
• Every flow is mapped into a bin in each level
  using an L-array of hash functions with the flow
  identifier as the identifier.
• Pfalse positive 1 ( 1 1/B ) M L
• M -- of malicious flows.
• The larger M, the larger Pfalse positive.

22
22Part II. Simulations

• Scenario (transmission delay 10ms)
• Compared with RED, SRED, SFQRED
• SFB Parameters
• Buffer size 200KB,
• 2 levels, 23 bins
• Bin size 13

23
Part II. Simulation Results (I)

• Loss rate

24
Part II. Simulation Results (II)

• Bandwidth

25
Part II. Observations

• SFB loses significant less packets and maintain
  fairness
• RED and SRED cant protect responsive flows
  effectively
• SFQ RED can rate-limit non-responsive flows,
  but loses fairness due to partitioning of buffer
• SFB performs worse as of non-responsive flows
  increases

26
Part II. Future Improvements

• Moving hashing function
• Periodically or randomly reset bins and change
  the hash functions
• -- mitigate the effects of misclassification
• -- quickly react to non-responsive flows that
  become TCP-friendly
• RTT sensitivity
• large of flows having varying RTT

27
Part II. Comparisons

• Compared with
• RED with Penalty Box
• FRED
• RED with per-flow Queueing
• Stochastic Fair Queueing
• Core-Stateless Fair Queueing
• Win in buffer size, adaptability, less overhead,
  etc.

28
Conclusions

• BLUE manages congestion control better with more
  information (packet loss and link utilization
  history).
• Enhanced with Bloom Filter, SFB can protect
  responsive flows effectively.