1. Sally Floyd and Van Jacobson
“Random Early Detection
Gateway for Congestion
Avoidance” "
TON, 1993
11 September 2009
CS5229, Semester 1 2009/10
1

2. Router’s "
Queue Management
11 September 2009
CS5229, Semester 1 2009/10
2

3. Manages sharing of "
(i) buffer space"
(ii) bandwidth
11 September 2009
CS5229, Semester 1 2009/10
3

4. Q1: Which packet to drop "
(and when to drop) ?
11 September 2009
CS5229, Semester 1 2009/10
4

5. Q2: Which packet to send next?
11 September 2009
CS5229, Semester 1 2009/10
5

6. FIFO + Drop Tail
11 September 2009
CS5229, Semester 1 2009/10
6

7. Keep a single queue
11 September 2009
CS5229, Semester 1 2009/10
7

8. Drop what/when? "
Drop arriving packets "
when queue is full
11 September 2009
CS5229, Semester 1 2009/10
8

9. Send what? "
Send the packet at "
head of queue
11 September 2009
CS5229, Semester 1 2009/10
9

10. Round Robin
11 September 2009
CS5229, Semester 1 2009/10
10

11. One queue per flow
11 September 2009
CS5229, Semester 1 2009/10
11

12. Drop what/when? !
Drop arriving packets from "
flow i when queue i is full
11 September 2009
CS5229, Semester 1 2009/10
12

13. Send what? "
Each flow takes turn -- send the
packet at the head of the queues in
a round robin manner.
11 September 2009
CS5229, Semester 1 2009/10
13

14. Advantages of "
FIFO and Drop Tail
11 September 2009
CS5229, Semester 1 2009/10
14

15. Simple to implement
11 September 2009
CS5229, Semester 1 2009/10
15

16. Scale well"
(no per-connection states)
11 September 2009
CS5229, Semester 1 2009/10
16

17. Reduce delay for a bursty
connection"
(e.g. VoIP)
11 September 2009
CS5229, Semester 1 2009/10
17

18. Problems with "
FIFO and Drop Tail
11 September 2009
CS5229, Semester 1 2009/10
18

19. Problem 1!
Bias against bursty traffic"
burstiness increases chances that the queue will
overflow
11 September 2009
CS5229, Semester 1 2009/10
19

20. Problem 2!
Global synchronization"
connections reduce their windows simultaneously,
lowering utilization.
11 September 2009
CS5229, Semester 1 2009/10
20

21. Problem 3!
Queue size"
higher bandwidth needs longer "
queue, increasing delay. "
TCP tries to keep the queue full.
11 September 2009
CS5229, Semester 1 2009/10
21

22. Problem 4!
No isolation against "
unresponsive flows
11 September 2009
CS5229, Semester 1 2009/10
22

23. Random Drop
11 September 2009
CS5229, Semester 1 2009/10
23

24. Keep a single queue
11 September 2009
CS5229, Semester 1 2009/10
24

25. Drop what/when? "
Drop random packet in the queue "
when queue is full
11 September 2009
CS5229, Semester 1 2009/10
25

26. Send what? "
Send the packet at "
head of queue
11 September 2009
CS5229, Semester 1 2009/10
26

27. No bias against bursty traffic -- "
bursty arrival causes random packets to
be dropped.
11 September 2009
CS5229, Semester 1 2009/10
27

28. Flows with higher rate occupy
more buffer spaces, have higher
chance to be dropped.
11 September 2009
CS5229, Semester 1 2009/10
28

29. Signal flows that is congesting the
network to slow down.
11 September 2009
CS5229, Semester 1 2009/10
29

30. Random drop recovers from
congestion (full queue) by
dropping packets.
11 September 2009
CS5229, Semester 1 2009/10
30

31. Early Random Drop
11 September 2009
CS5229, Semester 1 2009/10
31

32. Drop what/when? "
Drop arriving packet randomly
when queue is longer than a
threshold
11 September 2009
CS5229, Semester 1 2009/10
32

33. Early random drop avoids
congestion (full queue) by
dropping packets before queue is
full.
11 September 2009
CS5229, Semester 1 2009/10
33

34. RED"
Random Early Detection
11 September 2009
CS5229, Semester 1 2009/10
34

35. Drop what/when? !
Drop arriving packet randomly
when average queue length "
is above a threshold
11 September 2009
CS5229, Semester 1 2009/10
35

36. Differences: Use average queue
length instead of instantaneous
length to absorb transient
congestion.
11 September 2009
CS5229, Semester 1 2009/10
36

37. Differences: Dropping probability
changes dynamically depending
on queue length.
11 September 2009
CS5229, Semester 1 2009/10
37

38. Dropping Probability
1
Average Queue Length
11 September 2009
CS5229, Semester 1 2009/10
38

39. foreach incoming packet X"
calc average queue length"
if minth < average < maxth"
calc p "
drop X with probability p"
else if average > maxth"
drop X
11 September 2009
CS5229, Semester 1 2009/10
39

40. (Instead of dropping packets, we
can also mark a packet to indicate
congestion)
11 September 2009
CS5229, Semester 1 2009/10
40

41. How to calculate average queue
length?"
How to calculate drop probability?"
How to set thresholds?
11 September 2009
CS5229, Semester 1 2009/10
41

42. We can use exponentially weighted
average. On every packet arrival:
11 September 2009
CS5229, Semester 1 2009/10
42

43. Large wq : A burst of packets will
cause avg to increase too fast, hit
the max threshold"
Small wq : avg increases too slowly
and we are unable to detect initial
stage of congestions.
11 September 2009
CS5229, Semester 1 2009/10
43

44. 11 September 2009
CS5229, Semester 1 2009/10
44

45. 11 September 2009
CS5229, Semester 1 2009/10
45

46. We can use exponentially weighted
average. On every packet arrival:
11 September 2009
CS5229, Semester 1 2009/10
46

47. What if q drops to zero and no
packet arrives?
m is a function of period when
queue is empty
11 September 2009
CS5229, Semester 1 2009/10
47

48. How to calculate average queue
length?"
How to calculate drop probability"
How to set thresholds?
11 September 2009
CS5229, Semester 1 2009/10
48

49. Dropping Probability
1
pmax
Average
Queue Length
minth maxth
11 September 2009
CS5229, Semester 1 2009/10
49

50. 11 September 2009
CS5229, Semester 1 2009/10
50

51. 11 September 2009
CS5229, Semester 1 2009/10
51

52. How to calculate average queue
length?"
How to calculate drop probability?"
How to set thresholds?
11 September 2009
CS5229, Semester 1 2009/10
52

53. maxth - minth should be sufficiently"
large otherwise average queue size
can oscillate beyond maxth"
“need more research” for optimal
value.
11 September 2009
CS5229, Semester 1 2009/10
53

54. Advantages of RED
11 September 2009
CS5229, Semester 1 2009/10
54

55. No bias against bursty flows"
Less global synchronization"
Control average queue length
11 September 2009
CS5229, Semester 1 2009/10
55

56. RED does not deal with
unresponsive flows
11 September 2009
CS5229, Semester 1 2009/10
56

57. ns-2 demo
11 September 2009
CS5229, Semester 1 2009/10
57

58. Variations of RED
11 September 2009
CS5229, Semester 1 2009/10
58

59. RED biases against flow with small
packet size
11 September 2009
CS5229, Semester 1 2009/10
59

60. We can fix this by weighting drop
probability to packet size
11 September 2009
CS5229, Semester 1 2009/10
60

61. A router can keep one queue per
flow and apply RED to each one.
11 September 2009
CS5229, Semester 1 2009/10
61

62. Drop probability can be weighted
with the priority of the flow.
11 September 2009
CS5229, Semester 1 2009/10
62

63. This is known as WRED and is
implemented in some Cisco routers.
11 September 2009
CS5229, Semester 1 2009/10
63

64. Simulation"
Results
11 September 2009
CS5229, Semester 1 2009/10
64

65. Four TCP flows starting at time 0.2, 0.4, 0.6 and 0.8
11 September 2009
CS5229, Semester 1 2009/10
65

66. 11 September 2009
CS5229, Semester 1 2009/10
66

67. Conclusion:"
RED increases throughput, reduces
delay, controls average queue
sizes, reduces global sync, and is
fairer to bursty traffic. It is deployed
in routers today."
But careful tuning of parameters is
needed.
CS5229, Semester 1 2009/10
11 September 2009
67