Presentation on theme: "Equation-Based Congestion Control for Unicast Applications Sally Floyd, Mark Handley, Jitendra Padhye and Jörg Widmer Presented by Ankur Upadhyaya for."— Presentation transcript:
Equation-Based Congestion Control for Unicast Applications Sally Floyd, Mark Handley, Jitendra Padhye and Jörg Widmer Presented by Ankur Upadhyaya for CPSC 538A
Presentation Outline PART 1: TCP Congestion Control PART 2:Equation-Based Congestion Control with TFRC PART 3:Evaluating TFRC PART 4:Related and Future Work PART 5:Discussion
What is congestion? If several packets arriving at a router contend for an outgoing link, some must be queued in a buffer. Router Flow 1 Flow 2 Destination
What is congestion? When the router buffer fills, new packets must be dropped. When such losses become common, congestion is said to occur. Router Flow 1 Flow 2 Destination
How is congestion handled on the Internet? The predominant approach is the congestion control mechanism employed by TCP. Initially, however, TCP implementations did not address the problem of congestion. The result was the frequent congestion collapse of the Internet.
How is congestion handled on the Internet? The current stability of the Internet depends on TCP’s end-to-end congestion control. Note that TCP has many different implementations (e.g. TCP Vegas, TCP Reno, TCP Tahoe, Sack TCP, etc.). While implementing the same protocol, these can still have substantially different behaviors.
How does TCP congestion control work? TCP congestion control consists of three mechanisms: (1)Additive Increase/Multiplicative Decrease (AIMD) (2)Slowstart (3)Fast Retransmit and Fast Recovery
What is AIMD? Number of packets a sender can put on the network is limited not only by the advertised send window but also by a congestion window. Slowly (additively) increase the congestion window size as long as there is no congestion. Typically, the congestion window is increased by one packet for each window sent without a packet drop. Quickly (multiplicatively) decrease the congestion window size once congestion is detected. Typically, the congestion window is halved for each window containing a packet drop.
What is AIMD? AIMD results in the “saw-tooth” pattern shown below in the plot of sending rate versus time.
What is slowstart? The slow linear growth provided by additive increase is inappropriate when we are ramping up a TCP connection from a standing start. Slowstart increases the sending rate exponentially by putting two packets on the network for each acknowledgement received. Source Destination
Fast Retransmit and Fast Recovery Fast retransmit and fast recovery are performance optimizations not directly relevant to our discussion of TFRC.
Fast Retransmit and Fast Recovery Fast recovery work by always sending the ACK for the last packet received in a contiguous sequence. This way the source can use repeated ACKs to infer a probable loss and immediately retransmit, rather than waiting for an explicit timeout. Source Destination ACK 2ACK 1ACK 2 ACK 6 PACKET 1PACKET 2PACKET 3PACKET 4PACKET 5PACKET 6PACKET 3
Fast Retransmit and Fast Recovery When AIMD and slow start were originally combined, the congestion window size was always dropped to its minimum value upon detecting congestion. Slow start was then used to raise the sending rate to one-half the window size at which congestion was detected. Additive increase was used from there. Fast recovery uses ACKs already in the pipe to allow us to drop directly to one-half the window size at which congestion was detected. Essentially, we skip the slow start in the step above.
What is wrong with TCP? TCP’s AIMD results in an unstable sending rate. This is unsuitable for some real-time applications. TCP congestion control is coupled with a service model that is too rich for many real-time applications. It can be argued, for example, that retransmission- based reliability is not desirable for streaming video.
PART 2: Equation-Based Congestion Control with TFRC
Are we limited to TCP congestion control? While the multiplicative decrease of ½ used by TCP is sufficient to control congestion it is not necessarily a requirement. In fact, a less aggressive and more stable factor of 7 / 8 is suitable. This opens the door to consideration of mechanisms not based on AIMD and so, possibly more stable. One such mechanism is equation-based congestion control.
What is equation-based congestion control? In equation-based congestion control, the maximum acceptable sending rate is given by a control equation. The control equation expresses the maximum acceptable sending rate as a function of parameters that (1) are derived from receiver feedback and (2) characterize the level of network congestion. The sender adapts to ensure that it is working within the maximum acceptable rate.
What is TFRC? TFRC stands for TCP Friendly Rate Control. TFRC is a best-effort transport protocol for unicast traffic that employs equation-based congestion control. The point of TFRC is to provide a more smoothly changing sending rate while still remaining responsive to network congestion. It achieves this – albeit at the cost of a more moderate response to transient changes in the level of network congestion.
Does TFRC play nicely with TCP? If TFRC is to be deployed in the general Internet, it will have to compete with TCP traffic. Thus, TFRC must use a control equation that ensures TCP-compatible flows. A flow is TCP-compatible if in its steady state it uses no more bandwidth than a conformant TCP operating under comparable conditions. If not TCP-compatible, TFRC could starve TCP traffic in a FIFO queue.
Does TFRC play nicely with TCP? At the same time TFRC must also be aggressive enough to ensure that it is not starved by TCP in a FIFO queue. In general, acceptable performance can only be achieved for multiple flows competing in a FIFO queue if they have comparable sending rates.
What is the TFRC control equation? Given the requirement of TCP-compatibility, TFRC uses the TCP response function as its control equation. This function characterizes the steady- state sending rate of TCP as a function of the round-trip time and steady-state loss event rate. Note that a loss event is defined as the dropping of one or more packets within a single round-trip time.
What is the TFRC control equation? One formulation of the TCP response function is: This gives an upper bound T on the sending rate in bytes/second as a function of the packet size s, round-trip time R, steady state loss event rate p and the TCP timeout value t RTO.
How do we compute the control equation parameters? Recall that the control equation parameters are derived from receiver feedback. The receiver sends this feedback at least once per RTT, if it received packets in that RTT. Note that if the sender fails to receive feedback after several RTTs, it begins to slow the sending rate and ultimately stops altogether.
Computing R To compute R, the sender labels each packet with a sequence number. The feedback returned by the receiver contains the most recent sequence number received along with the time since it was received. From this, the sender derives a measurement of R’ of R.
Computing R The sender updates an exponentially weighted moving average (EWMA), SRTT, with R’ using a weight w: SRTT new = w * R’ + ( 1 – w ) * SRTT old SRTT is taken as R in the control equation.
Computing t RTO t RTO is computed as follows, where SRTT is the current EWMA of the RTT and RTT var is the variance of the RTT measurements taken thus far: t RTO = 4RTT’ Note that this is exactly how TCP initially seeds t RTO.
Computing t RTO It is important to remember that tRTO is only relevant as a control equation parameter. Because TFRC is unreliable, there are no retransmissions taking place!
Computing p p is computed at the receiver and forwarded to the sender in periodic feedback. The Average Loss Interval method is used to compute p. A loss interval is defined as the number of packets between loss events.
Average Loss Interval computes a weighted average of loss rate over the last n loss intervals, with equal weights on the n / 2 most recent intervals. The loss intervals are numbered i = 0, 1, … n, where s 0 is the most recent loss interval and s n is the oldest. Note that s 0 is not yet terminated by a loss. Computing p
Let w i be the weight for s i. Note that w 0 = 1. The other w i can be calculated as: Thus, for n = 8, w 1 through w 8 are 1, 1, 1, 1, 0.8, 0.6, 0.4, 0.2, respectively.
Computing p Now, we compute the average loss interval, ŝ, as follows: ŝ = max(ŝ (1,n), ŝ (0,n-1) ) Note that we compute both ŝ (1,n) and ŝ (0,n-1) and take a maximum only because ŝ 0 is not yet terminated by a loss. We only want to count it if it is large enough to increase the average.
Computing p A technique called history discounting is applied to the Average Loss Interval to ensure a more timely response to a sustained decrease in congestion. In history discounting, the weights given to older loss intervals are smoothly discounted once s 0 has grown to twice the size of the average interval. Finally, we compute p as 1 / ŝ.
How exactly does TFRC use the control equation? Each time the receiver sends feedback, the sender will update the parameters R, t RTO and p and compute a new value of T. If the current sending rate, T actual is less than T, then sender will raise T actual as close to T as possible, thereby exploiting the available network capacity. If T actual is more than T, then the sender will reduce T actual until it is less than or equal to T.
How does this achieve smoother congestion control? Use of the Average Loss Interval method to compute p ensures that this parameter is insulated from any abrupt changes. Given the control equation, it is clear that T, as a function of p, is similarly smooth. As T governs the sending rate, the desired stability is achieved.
How does this achieve smoother congestion control? In fact, it has been shown that with a fixed RTT and no history discounting, TFRC’s sending rate increases by at most 0.14 packets/RTT. Once history discounting is applied, this goes up to 0.22 packets/RTT. It has also been shown that TFRC requires from 4 to 8 RTTs to halve its sending rate in response to persistent congestion.
How does this achieve smoother congestion control? This smoothness is illustrated in the figure below. Note that here, the loss rate is 1% before time 6, 10% until time 9 and 0.5% thereafter.
Some key refinements to TFRC (1)Controlling inter-packet spacing to improve stability. (2)Implementing slowstart for TFRC.
Controlling Inter-Packet Spacing to Improve Stability If the EWMA weight for R is too high, TFRC reacts strongly to changes in RTT. This can lead to oscillations if we have a small number of TFRC flows sharing a high-bandwidth link. Why? If the EMWA weight for R is too low, short term oscillations in sending rate can arise. Why? It turns out that these problems can be solved by appropriately setting the inter-packet spacing (i.e. the time in which a single packet is sent).
Controlling Inter-Packet Spacing to Improve Stability The inter-packet spacing is set as in the equation below. Here R 0 is the most recent RTT sample and M is the average of the square-roots of the RTTs, calculated using the EWMA using the same constant used to calculate the mean RTT.
Controlling Inter-Packet Spacing to Improve Stability The smoothing effect of this optimization can be seen in the graphs below.
Implementing Slowstart for TFRC In TCP’s slowstart, the send rate’s overshoot of the network capacity is limited to twice the network capacity by only putting out two packets onto the network for each ACK received. Because TFRC does not use explicit ACKs, however, it does not have this natural self-limiting property.
Implementing Slowstart for TFRC TFRC solves this problem by having the receiver feed back the rate at which packets arrived during the last measured RTT. If a loss occurred, slowstart is stopped. Otherwise, the send rate is set to:
Does TFRC work? To demonstrate the feasibility of large-scale deployment of TFRC you would need to: (1)Show that it performs well in isolation. (2)Show that it performs well over a wide range of network conditions. (3)Show that it coexists well with many kinds of TCP traffic of different flavors.
Does TFRC work? Based on extensive tests on the Internet, the Dummynet network emulator and the ns network simulator, TFRC meets these three conditions remarkably well.
Does TFRC work? The graphs below illustrate this coexistence and smoothness.
Some Important Metrics Two important metrics used in the performance evaluation of TFRC are: (1)Coefficient of Variance (CoV) (2)Equivalence (e δ, a, b (t))
Coefficient of Variance (CoV) The Coefficient of Variance is simply the standard deviation divided by the mean for a particular set of measurements. This serves as a normalized measure of variability.
Equivalence (e δ, a, b (t)) Define the send rate R δ, F (t) of a data flow F using s-byte packets at time t at a timescale δ as:
Equivalence (e δ, a, b (t)) Then, the equivalence e δ, a, b (t) can be used to compare the send rates of two flows a and b at time t with timescale δ. Note that by using a minimum we get a value normalized between 0 and 1.
Related Work Active Queue Management is an area in which congestion is dealt with by first anticipating it at the bottleneck routers. Random Early Detection (RED) is a predominant example of this approach. Explicit Congestion Notification is an approach to congestion control in which flows are directly informed of congestion by bottleneck routers.
Related Work Congestion control for multicast is an active area of research. Bullet is an example of a multicast system that attempts to address congestion. There are numerous equation-based and non- equation based protocols that address congestion (e.g. RAP, TEAR, SCTP, DCCP, binomial congestion control, TFRCP, etc.).
Future Work Researching how the choice of control equation and parameters can be placed on a more rigorous foundation. Some contend that control theory may be relevant in this regard (e.g. XCP). Application of equation-based technique to multicast congestion control. Explore performance of equation-based techniques in an environment with Explicit Congestion Notification (ECN).
Future Work Study of duplex traffic under TFRC.
Discussion What were the main contributions of the work? What were the advantages and disadvantages of the approach? How does it compare to the other papers and related work? What are potential avenues for improvement?