1. 1 Queue Management Hamed Khanmirza Principles of Networking University of Tehran

2. 2 Why Queuing? When too many packets contented for one link –Queues overflows –Packets will be dropped congested –The network is said congested Issues –Congestion Avoidance –Congestion Control 10 Mbps 15 Mbps

3. 3 Queuing Mechanisms FIFO with DropTail is used in the routers –Important distinction: FIFO: scheduling discipline Drop-tail: drop policy Drawbacks –Global Synchronization –No penalty for ill sources (or non-TCP) –No policing: send more packets get more service –Burst or multiple consecutive packet drops –Leaves responsibility of congestion control to ends (e.g., TCP)

4. 4 Traditional Internet –Congestion control mechanisms at end-systems, mainly implemented in TCP –Routers play little role Design active router queue management to aid congestion control –Router has unified view of queuing behavior –Routers can distinguish between propagation and persistent queuing delays –Routers can decide on transient congestion, based on workload Components –Queue Manager –Queue Scheduler Queuing Mechanisms

5. 5 Queue Management Mechanisms

6. 6 Queue Management Mech. Mechanisms –DEC Bit –RED –BLUE

7. 7 DECbit Basic ideas: –On congestion, router sets congestion indication (CI) bit on packet –Receiver relays bit to sender –Sender adjusts sending rate Key design questions: –When to set CI bit? –How does sender respond to CI?

8. 8 Setting CI Bit AVG queue length = (previous busy+idle + current interval)/(averaging interval) Previous cycleCurrent cycle Averaging interval Current time Time Queue length

9. 9 DECbit Routers Router tracks average queue length –Regeneration cycle: queue goes from empty to non-empty to empty –Average from start of previous cycle Not long-time Causes to bias –Compromise between sensitivity and stability Acks carry bit back to source Source averages across acks in window –Congestion if > 50% of bits set –Will detect congestion earlier than TCP

10. 10 DECbit Evaluation Relatively easy to implement No per-connection state Stable Assumes cooperative sources Conservative window increase policy BUT, the problems still remain…

11. 11 RED (Random Early Detection)

12. 12 RED Algorithm Maintain running average of queue length –Byte mode vs. packet mode For each packet arrival –Calculate average queue size (avg) –If min th <= avg < max th Calculate probability P a With probability P a –Mark the arriving packet Else if max th <= avg –Mark the arriving packet

13. 13 RED Operation Min thresh Max thresh Average Queue Length min th max th max P 1.0 Avg queue length P(drop)

14. 14 Queue Estimation Standard EWMA: –avg = (1-w q ) avg + w q qlen –Special fix for idle periods – why? Upper bound on w q depends on min th –Want to ignore transient congestion –Can calculate the queue average if a burst arrives Set w q such that certain burst size does not exceed min th Lower bound on w q to detect congestion relatively quickly Typical w q = 0.002

15. 15 Thresholds min th determined by the utilization requirement –Tradeoff between queuing delay and utilization Relationship between max th and min th –Want to ensure that feedback has enough time to make difference in load –Depends on average queue increase in one RTT –Paper suggest ratio of 2

16. 16 Packet Marking Marking probability based on queue length –P b = max p (avg - min th ) / (max th - min th ) Just marking based on P b can lead to clustered marking –Could result in synchronization –Better to bias P b by history of unmarked packets –P a = P b /(1 - count*P b )

17. 17 Random Early Detection (RED) Detect incipient congestion, allow bursts Keep power (throughput/delay) high –Keep average queue size low –Assume hosts respond to lost packets Avoid window synchronization –Randomly mark packets Avoid bias against bursty traffic Some protection against ill-behaved users

18. 18 BLUE

19. 19 Blue Uses packet loss and link idle events instead of average queue length – why? –Hard to decide what is transient and what is severe with queue length –Based on observation that RED is often forced into drop-tail mode –Adapt to how bursty and persistent congestion is by looking at loss/idle events

20. 20 Blue Basic Algorithm d1 >> d2  why ? –More critical to react quickly to increase in load

21. 21 Comparison: Blue vs. RED Blue advantages –More stable marking rate & queue length –Avoids dropping packets –Much better behavior with small buffers

22. 22 Stochastic Fair Blue Same objective as RED Penalty Box –Identify and penalize misbehaving flows Create L hashes with N bins each –Each bin keeps track of separate marking rate (p m ) –Rate is updated using standard technique and a bin size –Flow uses minimum p m of all L bins it belongs to –Non-misbehaving flows hopefully belong to at least one bin without a bad flow Large numbers of bad flows may cause false positives

23. 23

24. 24 SFB

25. 25 Stochastic Fair Blue Can differentiate between approx. N L flows Bins do not actually map to buffers –Each bin only keeps drop rate –Can statistically multiplex buffers to bins –Works well since Blue handles small queues –Has difficulties when large number of misbehaving flows –Also has difficulties when a large number of connections with varying round-trip times are used with SFB

26. 26 Stochastic Fair Blue False positives can continuously penalize same flow Solution: moving hash function over time –Bad flow no longer shares bin with same flows –Quickly react to non-responsive flows which become TCP- friendly. –Is history reset  does bad flow get to make trouble until detected again? No, can perform hash warmup in background

27. 27 Other Approaches

28. 28 RED with Penalty Box Takes advantage of the fact that high bandwidth flows see proportionally larger amounts of packet loss. By keeping a finite log of recent packet loss events, this algorithm identifies flows which are non- responsive based on the log. Flows which are identified as being non-responsive are then rate-limited using other mechanisms like CBQ Problems –Multiple non-responsive flows (Large log file) –one or few high bandwidth flow –Penalized flows remain in “Penalty Box” !

29. 29 FRED (Flow RED) Keep state for flows based on instantaneous queue occupancy. If a flow continually occupies a large amount of the queue’s buffer space, it is detected and limited to a smaller amount of the buffer space. Problems –Keeps state for flows which have packets queued. Large buffer is needed –Dealing with large number of non-responsive flows Polluted logs Missing ability to distinguish TCP-friendly flows or non-responsive flows.

30. 30 RED with per-flow Queueing Keep state for active flows Problems –Requires O (N) buffer –Hardware requirements

31. 31 SFQ ( Stochastic Fair Queueing ) Like SFB with 1 level of Bins Has multiple queues Maps flows to queues

32. 32 CSFQ (Core-Stateless Fair Queueing) Keeps no state in the core of the network Per-flow accounting and marking at the edges –Estimates rate of the flow at ingress –Attach info. To every packet Probabilistic dropping at the core –calculates a dropping probability which is derived from an estimate of a fair share of the bottleneck link capacity and the rate of the flow as identified in the label. Problems –Header overhead –Edge and core routers must aware of same labeling and dropping scheme