Equation-Based Congestion Control for Unicast Applications Sally Floyd, Mark Handley, Jitendra Padhye and Jörg Widmer Cuong Le 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

PART 1:TCP Congestion Control

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. The key idea: 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.

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 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. TFRC solves this problem by setting the send rate to: – If a loss occurred, slowstart is stopped.

PART 3:Evaluating TFRC

Does TFRC work? To demonstrate the feasibility of large-scale deployment of TFRC we 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? The graphs below illustrate this coexistence and smoothness.

PART 4:Related and Future Work

Related Work Existing TCP equation-based and non-equation based protocols that address congestion control: RAP, TEAR, SCTP, DCCP, binomial congestion control, TFRCP, etc.). Alternative strategy to TCP’s: – Predict when congestion is about to happen. – Reduce rate before packets start being discarded. Random Early Detection (RED). Explicit Congestion Notification (ECN).

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).

PART 5: Discussion

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?