Presented by Ankur Upadhyaya for CPSC 538A

1. Equation-Based Congestion Control for Unicast ApplicationsSally Floyd, Mark Handley, Jitendra Padhye and Jörg Widmer Presented by Ankur Upadhyaya for CPSC 538A

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

3. PART 1: TCP Congestion Control

4. Flow 1 Router Destination Flow 2 What is congestion? • If several packets arriving at a router contend for an outgoing link, some must be queued in a buffer.

5. Flow 1 Router Destination Flow 2 What is congestion? • When the router buffer fills, new packets must be dropped. When such losses become common, congestion is said to occur.

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

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

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

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

10. What is AIMD? • AIMD results in the “saw-tooth” pattern shown below in the plot of sending rate versus time.

11. Source Destination 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.

12. Fast Retransmit and Fast Recovery • Fast retransmit and fast recovery are performance optimizations not directly relevant to our discussion of TFRC.

13. PACKET 1 PACKET 2 PACKET 3 PACKET 4 PACKET 5 PACKET 6 PACKET 3 Source Destination ACK 6 ACK 1 ACK 2 ACK 2 ACK 2 ACK 2 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.

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

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

16. PART 2: Equation-Based Congestion Control with TFRC

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

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

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

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

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

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

23. 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 tRTO.

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

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

26. Computing R • The sender updates an exponentially weighted moving average (EWMA), SRTT, with R’ using a weight w: SRTTnew = w * R’ + ( 1 – w ) * SRTTold • SRTT is taken as R in the control equation.

27. Computing tRTO • tRTO is computed as follows, where SRTT is the current EWMA of the RTT and RTTvar is the variance of the RTT measurements taken thus far: tRTO = 4RTT’ • Note that this is exactly how TCP initially seeds tRTO.

28. Computing tRTO • 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!

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

30. Computing p • 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 s0 is the most recent loss interval and sn is the oldest. Note that s0 is not yet terminated by a loss.

31. Computing p • Let wi be the weight for si. Note that w0 = 1. The other wi can be calculated as: • Thus, for n = 8, w1 through w8 are 1, 1, 1, 1, 0.8, 0.6, 0.4, 0.2, respectively.

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

33. 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 s0 has grown to twice the size of the average interval. • Finally, we compute p as 1/ŝ.

34. How exactly does TFRC use the control equation? • Each time the receiver sends feedback, the sender will update the parameters R, tRTO and p and compute a new value of T. • If the current sending rate, Tactual is less than T, then sender will raise Tactual as close to T as possible, thereby exploiting the available network capacity. • If Tactual is more than T, then the sender will reduce Tactual until it is less than or equal to T.

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

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

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

38. Some key refinements to TFRC • (1) Controlling inter-packet spacing to improve stability. • (2) Implementing slowstart for TFRC.

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

40. Controlling Inter-Packet Spacing to Improve Stability • The inter-packet spacing is set as in the equation below. Here R0 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.

41. Controlling Inter-Packet Spacing to Improve Stability • The smoothing effect of this optimization can be seen in the graphs below.

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

43. 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:

44. PART 3: Evaluating TFRC

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

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

47. Does TFRC work? • The graphs below illustrate this coexistence and smoothness.

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

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

50. 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: