• Save
CS5229 Lecture 7: Queue Management
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,855
On Slideshare
1,847
From Embeds
8
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
0
Likes
4

Embeds 8

http://blog.nus.edu.sg 7
http://www.slideshare.net 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Queue Management 3 October 2008 NUS CS5229, Semester 1 2008/09 1
  • 2. Not all flows are congestion controlled 3 October 2008 NUS CS5229, Semester 1 2008/09 2
  • 3. 1. Don’t need reliability, so use UDP, which has no congestion control 3 October 2008 NUS CS5229, Semester 1 2008/09 3
  • 4. 2. No incentive to limit own sending rate 3 October 2008 NUS CS5229, Semester 1 2008/09 4
  • 5. Sally Floyd and Kevin Fall “Promoting End-to-End Congestion Control in the Internet” TON, 1999 3 October 2008 NUS CS5229, Semester 1 2008/09 5
  • 6. What mechanisms can we add to the router to provide incentives for congestion control? 3 October 2008 NUS CS5229, Semester 1 2008/09 6
  • 7. Idea: Identify unresponsive flows, then drop their packets or regulate their rate. 3 October 2008 NUS CS5229, Semester 1 2008/09 7
  • 8. Note: Not scalable to large number of flows (eg in core routers). 3 October 2008 NUS CS5229, Semester 1 2008/09 8
  • 9. How to identify unresponsive flows in a router? 3 October 2008 NUS CS5229, Semester 1 2008/09 9
  • 10. Approach 1: Use TCP Throughput Equation 3 October 2008 NUS CS5229, Semester 1 2008/09 10
  • 11. The paper uses a rough approximation 3 October 2008 NUS CS5229, Semester 1 2008/09 11
  • 12. MSS: Maximum packet size in bytes over all outgoing links p: Packet drop rates over all outgoing links RTT: Twice the 1-way propagation delay of outgoing links 3 October 2008 NUS CS5229, Semester 1 2008/09 12
  • 13. The expression will overestimate the fair throughput for TCP. Thus, not all unfriendly flows will be identified. 3 October 2008 NUS CS5229, Semester 1 2008/09 13
  • 14. Approach 2: Unresponsive Flows 3 October 2008 NUS CS5229, Semester 1 2008/09 14
  • 15. Does the packet arrival rate of a flow reduce appropriately when packet drop rate increase? 3 October 2008 NUS CS5229, Semester 1 2008/09 15
  • 16. If packet drop rate increases by x%, then packet arrival rate should decrease by sqrt(x)% 3 October 2008 NUS CS5229, Semester 1 2008/09 16
  • 17. Does Not Work: when packet drop rate is constant 3 October 2008 NUS CS5229, Semester 1 2008/09 17
  • 18. Does Not Work: packet might be dropped by earlier router 3 October 2008 NUS CS5229, Semester 1 2008/09 18
  • 19. Does Not Work: A flow has an incentive to start with high throughput 3 October 2008 NUS CS5229, Semester 1 2008/09 19
  • 20. Approach 3: Flows with Disproportionate Bandwidth 3 October 2008 NUS CS5229, Semester 1 2008/09 20
  • 21. A flow should share 1/n of total bandwidth 3 October 2008 NUS CS5229, Semester 1 2008/09 21
  • 22. When congestion is low (packet drop rate is low), skewness is OK. 3 October 2008 NUS CS5229, Semester 1 2008/09 22
  • 23. Condition 1: If a flow’s bandwidth is more than ln(3n)/n of the aggregate, then it is using disproportionate share. (ln(3n)/n : magic) 3 October 2008 NUS CS5229, Semester 1 2008/09 23
  • 24. Condition 2: If a flow’s bandwidth is more than For MSS=512 and RTT=0.05s 3 October 2008 NUS CS5229, Semester 1 2008/09 24
  • 25. If a flow’s bandwidth is more than ln(3n)/n of the aggregate flow bandwidth, then it is using disproportionate share. (ln(3n)/n : magic) 3 October 2008 NUS CS5229, Semester 1 2008/09 25
  • 26. Does Not Work: flows with short RTT will be considered as disproportionate 3 October 2008 NUS CS5229, Semester 1 2008/09 26
  • 27. Does Not Work: the only flow with sustained demand (long live) will be considered as disproportionate. 3 October 2008 NUS CS5229, Semester 1 2008/09 27
  • 28. Sally Floyd and Van Jacobson “Random Early Detection Gateway for Congestion Avoidance” TON, 1993 3 October 2008 NUS CS5229, Semester 1 2008/09 28
  • 29. Router’s Queue Management 3 October 2008 NUS CS5229, Semester 1 2008/09 29
  • 30. Manages sharing of (i) buffer space (ii) bandwidth 3 October 2008 NUS CS5229, Semester 1 2008/09 30
  • 31. Q1: Which packet to drop when queue is full? 3 October 2008 NUS CS5229, Semester 1 2008/09 31
  • 32. Q2: Which packet to send next? 3 October 2008 NUS CS5229, Semester 1 2008/09 32
  • 33. FIFO + Drop Tail 3 October 2008 NUS CS5229, Semester 1 2008/09 33
  • 34. Keep a single queue 3 October 2008 NUS CS5229, Semester 1 2008/09 34
  • 35. Drop what? Drop arriving packets when queue is full 3 October 2008 NUS CS5229, Semester 1 2008/09 35
  • 36. Send what? Send the packet at head of queue 3 October 2008 NUS CS5229, Semester 1 2008/09 36
  • 37. Round Robin 3 October 2008 NUS CS5229, Semester 1 2008/09 37
  • 38. One queue per flow 3 October 2008 NUS CS5229, Semester 1 2008/09 38
  • 39. Drop what? Drop arriving packets from flow i when queue i is full 3 October 2008 NUS CS5229, Semester 1 2008/09 39
  • 40. Send what? Each flow takes turn -- send the packet at the head of the queues in a round robin manner. 3 October 2008 NUS CS5229, Semester 1 2008/09 40
  • 41. Advantages of FIFO and Drop Tail 3 October 2008 NUS CS5229, Semester 1 2008/09 41
  • 42. Simple to implement 3 October 2008 NUS CS5229, Semester 1 2008/09 42
  • 43. Scale well (no per-connection states) 3 October 2008 NUS CS5229, Semester 1 2008/09 43
  • 44. Reduce delay for a bursty connection (e.g. VoIP) 3 October 2008 NUS CS5229, Semester 1 2008/09 44
  • 45. Problems with FIFO and Drop Tail 3 October 2008 NUS CS5229, Semester 1 2008/09 45
  • 46. Problem 1 Bias against bursty traffic burstiness increases chances that the queue will overflow 3 October 2008 NUS CS5229, Semester 1 2008/09 46
  • 47. Problem 2 Global synchronization connections reduce their windows simultaneously, lowering utilization. 3 October 2008 NUS CS5229, Semester 1 2008/09 47
  • 48. Problem 3 Queue size higher bandwidth needs longer queue, increasing delay. TCP tries to keep the queue full 3 October 2008 NUS CS5229, Semester 1 2008/09 48
  • 49. Problem 4 No isolation against unresponsive flows 3 October 2008 NUS CS5229, Semester 1 2008/09 49
  • 50. Random Drop 3 October 2008 NUS CS5229, Semester 1 2008/09 50
  • 51. Keep a single queue 3 October 2008 NUS CS5229, Semester 1 2008/09 51
  • 52. Drop what? Drop random packet in the queue when queue is full 3 October 2008 NUS CS5229, Semester 1 2008/09 52
  • 53. Send what? Send the packet at head of queue 3 October 2008 NUS CS5229, Semester 1 2008/09 53
  • 54. No bias against bursty traffic -- bursty arrival causes random packets to be dropped. 3 October 2008 NUS CS5229, Semester 1 2008/09 54
  • 55. Flows with higher rate occupy more buffer spaces, have higher chance to be dropped. 3 October 2008 NUS CS5229, Semester 1 2008/09 55
  • 56. Signal flows that is congesting the network to slow down. 3 October 2008 NUS CS5229, Semester 1 2008/09 56
  • 57. Random drop recovers from congestion (full queue) by dropping packets. 3 October 2008 NUS CS5229, Semester 1 2008/09 57
  • 58. Early Random Drop 3 October 2008 NUS CS5229, Semester 1 2008/09 58
  • 59. Drop what? Drop arriving packet randomly if queue is longer than a threshold 3 October 2008 NUS CS5229, Semester 1 2008/09 59
  • 60. Early random drop avoids congestion (full queue) by dropping packets before queue is full. 3 October 2008 NUS CS5229, Semester 1 2008/09 60
  • 61. RED Random Early Detection 3 October 2008 NUS CS5229, Semester 1 2008/09 61
  • 62. Drop what? Drop arriving packet randomly if average queue length is above a threshold 3 October 2008 NUS CS5229, Semester 1 2008/09 62
  • 63. Differences 1: Use average queue length instead of instantaneous length to absorb transient congestion. 3 October 2008 NUS CS5229, Semester 1 2008/09 63
  • 64. Differences 2: Dropping probability should change dynamically depending on queue length. 3 October 2008 NUS CS5229, Semester 1 2008/09 64
  • 65. Dropping Probability 1 Average Queue Length 3 October 2008 NUS CS5229, Semester 1 2008/09 65
  • 66. 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 3 October 2008 NUS CS5229, Semester 1 2008/09 66
  • 67. (Instead of dropping packets, we can also set the ECN bit to indicate congestion) 3 October 2008 NUS CS5229, Semester 1 2008/09 67
  • 68. How to calculate average queue length? How to calculate drop probability? How to set thresholds? 3 October 2008 NUS CS5229, Semester 1 2008/09 68
  • 69. We can use exponentially weighted average. On every packet arrival: 3 October 2008 NUS CS5229, Semester 1 2008/09 69
  • 70. 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. 3 October 2008 NUS CS5229, Semester 1 2008/09 70
  • 71. 3 October 2008 NUS CS5229, Semester 1 2008/09 71
  • 72. 3 October 2008 NUS CS5229, Semester 1 2008/09 72
  • 73. We can use exponentially weighted average. On every packet arrival: 3 October 2008 NUS CS5229, Semester 1 2008/09 73
  • 74. We can use exponentially weighted average. On every packet arrival: 3 October 2008 NUS CS5229, Semester 1 2008/09 74
  • 75. What if q drops to zero and no packet arrives? m is a function of period when queue is empty 3 October 2008 NUS CS5229, Semester 1 2008/09 75
  • 76. How to calculate average queue length? How to calculate drop probability How to set thresholds? 3 October 2008 NUS CS5229, Semester 1 2008/09 76
  • 77. Dropping Probability 1 pmax Average Queue Length minth max th 3 October 2008 NUS CS5229, Semester 1 2008/09 77
  • 78. 3 October 2008 NUS CS5229, Semester 1 2008/09 78
  • 79. 3 October 2008 NUS CS5229, Semester 1 2008/09 79
  • 80. How to calculate average queue length? How to calculate drop probability How to set thresholds? 3 October 2008 NUS CS5229, Semester 1 2008/09 80
  • 81. maxth - minth should be sufficiently large otherwise average queue size can oscillate beyond maxth “need more research” for optimal value. 3 October 2008 NUS CS5229, Semester 1 2008/09 81
  • 82. Advantages of RED 3 October 2008 NUS CS5229, Semester 1 2008/09 82
  • 83. No bias against bursty flows Less global synchronization Control average queue length 3 October 2008 NUS CS5229, Semester 1 2008/09 83
  • 84. RED does not deal with unresponsive flows 3 October 2008 NUS CS5229, Semester 1 2008/09 84
  • 85. ns-2 demo 3 October 2008 NUS CS5229, Semester 1 2008/09 85
  • 86. Variations of RED 3 October 2008 NUS CS5229, Semester 1 2008/09 86
  • 87. RED biases against flow with large packet size 3 October 2008 NUS CS5229, Semester 1 2008/09 87
  • 88. We can fix this by weighting drop probability to packet size 3 October 2008 NUS CS5229, Semester 1 2008/09 88
  • 89. A router can keep one queue per flow and apply RED to each one. 3 October 2008 NUS CS5229, Semester 1 2008/09 89
  • 90. Drop probability can be weighted with the priority of the flow. 3 October 2008 NUS CS5229, Semester 1 2008/09 90
  • 91. This is known as WRED and is implemented in some Cisco routers. 3 October 2008 NUS CS5229, Semester 1 2008/09 91
  • 92. Simulation Results 3 October 2008 NUS CS5229, Semester 1 2008/09 92
  • 93. Four TCP flows starting at time 0.2, 0.4, 0.6 and 0.8 3 October 2008 NUS CS5229, Semester 1 2008/09 93
  • 94. 3 October 2008 NUS CS5229, Semester 1 2008/09 94
  • 95. 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. 3 October 2008 NUS CS5229, Semester 1 2008/09 95