Active Queue Management

Active Queue Management
Rong Pan Cisco System EE384y Spring Quarter 2008 Good afternoon, Today, I am going to talk about an active queue management scheme which aims to approximate fair bandwidth allocation. This is a joint work by Konstantinos Psounis, myself and my advisor Balaji Prabhakar.

Outline Queue Management Traditional Queue Management
Drop as a way to feedback to TCP sources Part of a closed-loop Traditional Queue Management Drop Tail Problems Active Queue Management RED CHOKe AFD Here is the outline of my talk. First, I am going to give the background behind this work. Pointing out what kind of the problem that we are trying to solve. Then, I will introduce the choke algorithm. The acronym will become clear once I explain how the scheme works. It is a randomized algorithm in which no state information needs to be maintained. After introducing the CHOKe algorithm, the simulation result will be presented to show the performance of CHOKe. Analytical models were also developed to give us insights into CHOKe’s behavior. I will briefly mention it. We also studied how to use the CHOKe algorithm in a real system. In the implementation section our proposal will be discussed. At the end of the talk, I will give a summary.

Queue Management: Drops/Marks - A Feedback Mechanism To Regulate End TCP Hosts
End hosts send TCP traffic -> Queue size Network elements, switches/routers, generate drops/marks based on their queue sizes Drops/Marks: regulation messages to end hosts TCP sources respond to drops/marks by cutting down their windows, i.e. sending rate

TCP+Queue Management - A closed-loop control system
W/R C _ + q  N  + _ 0.5 - p Time Delay Queue Management + 1

Drop Tail - problems Lock out Full queue Bias against bursty traffic
Global synchronization

Tail Drop Queue Management Lock-Out
Max Queue Length

Tail Drop Queue Management Full-Queue
Only drop packets when queue is full long steady-state delay

Bias Against Bursty Traffic
Max Queue Length

Tail Drop Queue Management Global Synchronization
Max Queue Length

Alternative Queue Management Schemes
Drop from front on full queue Drop at random on full queue both solve the lock-out problem both have the full-queues problem

Active Queue Management Goals
Solve tail-drop problems no lock-out behavior no full queue no bias against bursty flow no global synchronization Provide better QoS at network nodes low steady-state delay lower packet dropping

Random Early Detection (RED)
Arriving packet AvgQsize > Minth? no Admit the new packet yes AvgQsize > Maxth? no yes end Drop the new packet Admit packet with a probability p end end

RED Dropping Curve 1 Drop Probability maxp minth maxth
minth maxth Average Queue Size

Effectiveness of RED - Lock-Out & Global Synchronization
Packets are randomly dropped Each flow has the same probability of being discarded

Effectiveness of RED - Full-Queue & Bias against bursty traffic
Drop packets probabilistically in anticipation of congestion not when queue is full Use qavg to decide packet dropping probability: allow instantaneous bursts

What QoS does RED Provide?
Lower buffer delay: good interactive service qavg is controlled to be small Given responsive flows: packet dropping is reduced early congestion indication allows traffic to throttle back before congestion Given responsive flows: fair bandwidth allocation

Bad News - unresponsive end hosts
udp tcp tcp Connectionless; Best-Effort The Internet The Internet protocol delivers connectionless, best-effort service. It depends on the transport layer protocol like TCP to provide good service under heavy load. However, as the Internet grows, there are more and more packet radio and packet video applications running through the Internet. These types of traffic don’t back off as the TCP flows do. Also there are badly implemented TCPs which don’t back off properly either. If the network is not congested, all these type of applications can coexist without affecting each other. However, if the network is congested, unresponsive flows could take up all the scarce network bandwidth and starve out the adaptive flows.

Scheduling & Queue Management
What routers want to do? isolate unresponsive flows (e.g. UDP) provide Quality of Service to all users Two ways to do it scheduling algorithms: e.g. FQ, CSFQ, SFQ queue management algorithms with fairness enhancement: e.g. CHOKe, AFD, WRED To solve the problem mentioned above, routers adopt measures to isolate unresponsive flows and to provide Quality of Service to all users. There are generally two types of router algorithms associated with the congestion control. One is the scheduling algorithm, such as the well-known Fair queueing. And more recent algorithms like core stateless fair queueing and stocastic fair queueing. The other type is the queue management algorithms, especially active queue management schemes, exemplified by Random Early Detection(RED), and recent Flow RED(FRED) and Stable RED(SRED).

Active Queue Manament With Enhancement to Fairness
FIFO Approximate fair bandwidth allocation Provide isolation from unresponsive flows Be as simple as RED The goal of our work is to design a router method that can provide isolation from unresponsive flows similar to what FQ does, as well as be simple to implement as RED. Of course we want to keep all the good features that RED has.

CHOKe RED yes yes no Drop both matched packets end Draw a packet at
random from queue Flow id same as the new packet id ? Drop the new packet Admit packet with a probability p AvgQsize > Maxth? CHOKe RED Arriving packet AvgQsize > Minth? no Admit the new packet yes AvgQsize > Maxth? no yes end Drop the new packet Admit packet with a probability p CHOKe is based on RED. So let’s review the basic RED algorithm which is shown in the flow chart. Routers keep track of the average queue size, and mark two thresholds: the minimum threshold and the maximum threshold. If the average queue size is below the minth, a new arriving packet is queued at end of the FIFO. If the maximum queue size is exceeded, the incoming packet is dropped. If the average queue size is between the minth and maxth, then an arriving packet will be dropped probabilistically based on where average queue size sits. Closer to the minth, lower drop probability. Closer to the maximum threshold, higher drop probability. CHOKe added random samplings into the algorithm. It kicks in when the average queue size is above the minimum threshold. When a packet arrives, a packet is drawn randomly from the queue and compare its flow id with the incoming packet. If they agree, both packets are dropped. Otherwise, it hands over to RED, meaning drop the incoming packet probabilistically based on the average queue size. If the average queue size is above the maximum threshold, the arriving packet is dropped. It is not necessary to choose only one sample. More samples can be chosen. Drop all the ones that match the incoming flow id. end end

Random Sampling from Queue
UDP flow We have just seen how CHOKe works. I want to give some intuition why it might be able to penalize unresponsive flows. Since a non-adaptive flows don’t back off when there is a congestion. So it takes up more space in the buffer. For the example here, the red packets are from an unresponsive source and green, yellow and blue packets are from three different TCP flows. As a result, if we choose a packet at random from the queue, it is more likely from the unresponsive flows. Then we compare the flow id of the arriving packet with this sample, if they are equal, drop both. Since it takes a pair to make dropping happen, the scheme can compensate for errors and less likely to hurt TCP flows. Let me give a simple example, let’s say there are two flows in the buffer, a UDP flow takes 90% of the buffer space, a TCP flow takes 10% the buffer space. This means that the scheme could make an error about 10% when it catches the TCP flow. However a matching between two packets would mean 81% catching the UDP flow, only 1% would hurt the TCP flow. CHOKe stands for choose and Keep for TCP flows, and choose and kill for UDP flows. A randomly chosen packet more likely from the unresponsive flow Adversary can’t fool the system

Comparison of Flow ID Compare the flow id with the incoming packet
more acurate Reduce the chance of dropping packets from a TCP-friendly flows. We have just seen how CHOKe works. I want to give some intuition why it might be able to penalize unresponsive flows. Since a non-adaptive flows don’t back off when there is a congestion. So it takes up more space in the buffer. For the example here, the red packets are from a unresponsive source and green, yellow and blue packets are from three different TCP flows. As a result, if we choose a packet at random from the queue, it is more likely from the unresponsive flows. Then we compare the flow id of the arriving packet with this sample, if they are equal, drop both. Since it takes a pair to make dropping happen, the scheme can compensate for errors and less likely to hurt TCP flows. Let me give a simple example, let’s say there are two flows in the buffer, a UDP flow takes 90% of the buffer space, a TCP flow takes 10% the buffer space. This means that the scheme could make an error about 10% when it catches the TCP flow. However a matching between two packets would mean 81% catching the UDP flow, only 1% would hurt the TCP flow. CHOKe stands for choose and Keep for TCP flows, and choose and kill for UDP flows.

Dropping Mechanism Drop packets (both incoming and matching samples )
More arrival -> More Drop Give users a disincentive to send more

Simulation Setup S(1) D(1) S(2) 10Mbps 10Mbps D(2) m TCP m TCP Sources
Sinks S(m) 1Mbps D(m) S(m+1) D(m+1) After the discussion of how the algorithm works, now let’s see how it performs in a network. This is a simple network set up with one congested link at 1Mbps. All the other links are running at 10Mbps. TCP and UDP sources are at the left side and their corresponding sinks are at the right side. n UDP Sources n UDP Sinks S(m+n) D(m+n)

Network Setup Parameters
32 TCP flows, 1 UDP flow All TCP’s maximum window size = 300 All links have a propagation delay of 1ms FIFO buffer size = 300 packets All packets sizes = 1 KByte RED: (minth,maxth) = (100,200) packets Here is the setup parameters. There are total 32 TCP flows, and one UDP flow in the network. TCP window sizes are set to be 300 so that they can always send packets if there is enough bandwidth. All links have a propagation delay of 1ms. FIFO queue size is 300 packets. All packet sizes equal to 1KB. The minth and maxth are setup to 1/3 and 2/3 of the buffer size as suggested in RED.

32 TCP, 1 UDP (one sample) 74.1% 23.0% 99.6%
Here is the plot which shows a flow’s throughput when the UDP sending rate changes. The x-axis is the UDP flow’s arrival rate which ranges from 100Kbps, 10% of the link bandwidth to 10Mbps, 10 times the link bandwidth.And y-axis is a flow’s throughput. In RED, as the UDP flow becomes more and more aggressive, it could take away the whole link bandwidth. In CHOKe, the UDP flow gets dropped by 23% even when it sends at 10% of the link bandwidth. It gets penalized even more when it sends at 10 times the link bandwidth. It reaches its maximum throughput when it sends at the bottleneck link bandwidth, the throughput is around 260kbps. Per TCP flow’s throughput stays pretty much the same.

32 TCP, 5 UDP (5 samples) In the previous simulation, we saw how CHOKe with one sample behaves when there is only one UDP flow. How does it perform when there are more than 1 UDP flow? The performance is shown in the two red lines. CHOKe with one sample fails to penalize UDP flows. The red line on the top is the total UDP throughput. TCP flows can’t get their fair share throughput. However, with more samples, 5, blue lines in this figure, the CHOKe algorithm is able to identify the unresponsive flows and penalize them. The top blue line is the TCP throughput, which shows they regain their fair share bandwidth. TCP’s throughput improves from … to … UDP’s throughput drop down dramatically accordingly.

How Many Samples to Take?
R1 R2 Rk Maxth avg minth Different samples for different Qlenavg # samples  when Qlenavg close to minth # samples when Qlenavg close to maxth But we don’t know how many UDP flow traffic are active at the routers. How do we decide the number of samples that are needed? We divide the region between the minth and maxth into several sub-regions: R1, R2.. Rk. Choose different number of samples when the average queue size is at different regions. For example, if in R1, choose one sample, in R2 choose three samples, etc. In our simulation, we use 8 sub-regions, the number of sample is 1, 3, 5, 7, …. And I will refer to it as self-adjusting CHOKe.

32 TCP, 5 UDP (self-adjusting)
This is the simulation result when there are 32 TCP and 5 UDP flows. The green line is the total TCP throughput and the red line is the total UDP throughput. It is obvious that the self-adjusting CHOKe is able to decide the number of samples required and have the same and slightly better performance than CHOKe with 5 samples.

Analytical Model discards from the queue permeable tube with leakage
This is the comparison between our model and the ns simulation. The green line is the UDP throughput obtained from the ns simulation, the red line is calculated using our model. As shown in the figure, they are very close. permeable tube with leakage

Fluid Analysis N: the total number of packets in the buffer
Li(t): the survival rate for flow i packets Li(t)t - Li(t +t)t = i t Li(t)t /N - dLi(t)/dt = i Li(t) N Li(0) = i (1-pi ) Li(D) = i (1-2pi ) This is the comparison between our model and the ns simulation. The green line is the UDP throughput obtained from the ns simulation, the red line is calculated using our model. As shown in the figure, they are very close.

Model vs Simulation - multiple TCPs and one UDP
This is the comparison between our model and the ns simulation. The green line is the UDP throughput obtained from the ns simulation, the red line is calculated using our model. As shown in the figure, they are very close.

Fluid Model - Multiple samples
Multiple samples are chosen Li(t)t - Li(t +t)t = Mi t Li(t)t /N - dLi(t)/dt = Mi Li(t) N Li(0) = i (1-pi )M Li(D) = i (1-pi )M - Mi pi This is the comparison between our model and the ns simulation. The green line is the UDP throughput obtained from the ns simulation, the red line is calculated using our model. As shown in the figure, they are very close.

Two Samples - multiple TCPs and one UDP

Two Samples - multiple TCPs and two UDP

What If We Use a Small Amount of State?

AFD: Goal Approximate weighted bandwidth allocation
Not only AQM, approximate WDRR scheduling Provide soft queues in addition to physical queues Keep the state requirement small Be simple to implement

AFD Algorithm: Details (Basic Case: Equal Share)
Di = Drop Probability for Class i Arriving Packets Qlen 1-Di Qref Class i Di Mfair = f(Qlen, Qlen_old,Qref) Fair Share Mi = Arrival estimate for Class i (Bytes over interval Ts) If Mi > Mfair : Di > 0 such that Mi (1-Di) = Mfair If Mi  Mfair : No Drop (Di = 0)

AFD Algorithm: Details (General Case)
Di = Drop Probability for Class i Arriving Packets Qlen 1-Di Qref Class i Di Mfair = f(Qlen, Qlen_old,Qref) Fair Share Mi = Arrival estimate for Class i (Bytes over interval Ts) If Mi > Mfair : Di > 0 such that Mi (1-Di) = F(Mfair,Mini,Maxi,Wi, …) If Mi  F(Mfair,Mini,Maxi,Wi, …): No Drop (Di = 0)

Not Per-Flow State Fraction of flows
A natural question arises whether we have to keep a table entry for each flow? The answer is No. Here is why. Recent trace data shows that Like the distribution of file sizes, the flow rate distribution is also long-tailed, For example in this plot, we show the cumulative fraction of bytes as a function of Cumulative fraction of flows. There are total three trace data which were obtained from a backbone link of a national lab, a T3 peering link, a FDDI ring. These data depicts That 10% of flows send 60-90% of the total data. So we only need to keep state For those unresponsive flows, the rest of flows can be ignored since they shouldn’t Incur drops anyway. Therefore, we only need to keep state on the order of… Fraction of flows State requirement on the order of # of unresponsive flows Elephant Traps (developed jointly Stanford and Cisco)

AFD Solution: Details Based on 3 simple mechanisms
estimate per “class” arrival rate counting per “class” bytes over fixed intervals ( Ts ) potential averaging over multiple intervals estimate deserved departure rate (so as to achieve the proper bandwidth allocation for each class) observation of queue length as measure of congestion perform selective dropping (pre-enqueue) to drive arrival rate to the desired departure rate

Mixed Traffic with Different Levels of Unresponsiveness
RED treats everyone the same, as a result, flow’s will get uneven bandwidth. Hence, their throughputs represent the levels of unresponsiveness. The highest is group 5 and the last group is the most responsive one. CHOKe can limit and penalize unresponsive flows, however it can’t provide equal share to all users. For example, in this simulation setup, there are 7 groups of flows with different level of unresponsiveness. CHOKe penalizes The most aggressive flow, as a result, help lifting up the other flow’s throughput. However, it is obvious From the plot that CHOKe can’t provide equal share. AFD can approximate equal bandwidth partitioning. AFD-FT, a randomized simple design of AFD can achieve the same result.

Drop Probabilities (note differential dropping)

Different Number of TCP Flows in Each Class
50 100 150 200 time 50 100 150 200 time 20 TCP Flows 15 TCP Flows After the discussion of how the algorithm works, now let’s see how it performs in a network. This is a simple network set up with one congested link at 1Mbps. All the other links are running at 10Mbps. TCP and UDP sources are at the left side and their corresponding sinks are at the right side. Class 3 Class 4 50 100 150 200 time 50 100 150 200 time

Different Class Throughput Comparison
After the discussion of how the algorithm works, now let’s see how it performs in a network. This is a simple network set up with one congested link at 1Mbps. All the other links are running at 10Mbps. TCP and UDP sources are at the left side and their corresponding sinks are at the right side.

Queue Length After the discussion of how the algorithm works, now let’s see how it performs in a network. This is a simple network set up with one congested link at 1Mbps. All the other links are running at 10Mbps. TCP and UDP sources are at the left side and their corresponding sinks are at the right side.

Mfair After the discussion of how the algorithm works, now let’s see how it performs in a network. This is a simple network set up with one congested link at 1Mbps. All the other links are running at 10Mbps. TCP and UDP sources are at the left side and their corresponding sinks are at the right side.

AFD Implementation Issues
Monitor Arrival Rate Determine Drop Probability Maximize Link Utilization The last implementation issue is how to handle packets with variable lengths. We can measure the packet length as number of quanta. The quantum size is relatively small.

Arrival Monitoring Keep a counter for each class
Count the data arrivals (in bytes) of each class in 10ms interval: arvi Arrival rate of each class is updated every 10ms mi = mi(1-1/2c)+arvi c determines the average window

Implementing the Drop Function
If Mi  Mfair then Di = 0 Otherwise, rewrite the drop function as Suppose we have predetermined drop levels, find the one such that Di* Mi = (Mi – Mfair)

Implementing the Drop Function
Drop levels are: 1/32, 1/16, 3/32… Suppose mi = 100, mfair = 62.0 => Di = 0.380, 0.0 1.0 Di We choose the higher value using binary search 0.375 0.406

AFD - Summary Ideal FQ AFD CHOKe RED Fairness Simplicity
We can see that AFD provides equal bandwidth partitioning in a wide variety of unresponsive settings. The state requirement is limited. Simplicity Equal share is approximated in a wide variety of settings The state requirement is limited

Summary Traditional Queue Management Active Queue Management
Drop Tail, Drop Front, Drop Random Problems: lock-out, full queue, global synchronization, bias against bursty traffic Active Queue Management RED: can’t handle unresponsive flows CHOKe: penalize unresponsive flows AFD: provides approximate fairness with limited states Now, I would like to conclude my talk. We have shown that CHOKe is a stateless, randomized algorithm. It can identify and penalize unresponsive flows simultaneously and therefore protect TCP-friendly flows. It is very easy to implement as well. Thank you very much for attention.

Active Queue Management

Similar presentations

Presentation on theme: "Active Queue Management"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Active Queue Management

Similar presentations

Presentation on theme: "Active Queue Management"— Presentation transcript:

Similar presentations

About project

Feedback