0 Delayed Congestion Response Protocols Thesis By Sumitha Bhandarkar Under the Guidance of Dr. A. L. N. Reddy

1 Layout of the presentation Introduction to “TCP-Friendliness” Motivation for Delayed Congestion Response Protocols Delayed Congestion Response Protocols Conclusions And Future Work Related Work

2 Introduction to “TCP-Friendliness” Stability of internet depends on protocols that respond to congestion Congestion Control Algorithm of TCP results in drastic changes in sending rate When used with real-time audio/video application, this will cause drastic changes in user perceived quality UDP looks like a good alternative for such applications

3 Introduction to “TCP-Friendliness” (contd.) Extensive use of UDP could result in Extreme unfairness to existing TCP applications Congestion collapse of the internet Lot of interest in new class of protocols called “TCP-Friendly” Protocols “TCP-Friendliness” indicates that the protocol chooses to send at a rate no higher than TCP under similar conditions of round trip delays and packet losses

4 Introduction to “TCP-Friendliness” (contd.) An analytical model for TCP was developed by J. Padhye et. al. which shows - T = S R  2p/3 + T RTO (3  3p/8) p ( p 2 ) T :Throughput S :Packet Size R :Round Trip Time T RTO :Retransmission Timeout p :Loss Rate

5 Introduction to “TCP-Friendliness” (contd.) Simplified Throughput Equation  3/2 T = R *  p In a very general sense a protocol which maintain the sending rate to at most some constant over the square root of the packet loss rate is said to be “TCP-friendly”.

6 Motivation For Delayed Congestion Response Protocols Congestion in the network is notified to the protocol, in most cases, through packet drops. TCP as well as most of the TCP-friendly protocols reduce the sending rate once and as soon as allowed by protocol design, when a packet drop is noticed. By delaying congestion response by ‘  ’ RTTs, the transport protocol can provide application with an early warning regarding an impending reduction in sending rate.

7 Motivation For Delayed Congestion Response Protocols (contd.) Smart applications can be designed to combine Early Notification with buffering techniques to provide smooth output. For applications that cannot take advantage of early notification, smooth sending rate can be provided by reducing the congestion window smoothly, during the period ‘  ’ after a packet drop. By studying the time scales over which we can delay the congestion response insight can be gained regarding the time scales for defining “TCP-Friendliness”.

8 C w n d Delayed Congestion Response Protocols Protocols where response to congestion is deliberately delayed by ‘  ’ RTTs when a congestion is notified. Congestion control dynamics characterized by (f 1 (t), f 2 (t), ,  ). f 1 (t) f 2 (t) Pkt Drop   Time

9 DCR-I f 2 (t) is an increasing function For simplicity of implementation and analysis we set f 1 (t) as an additive function. f 2 (t) = f 1 (t). C w n d f 1 (t) f 2 (t) Pkt Drop   Time

10 DCR-I Thus we have, f 1 (t):w t+R  w t +  ;  > 0 f 2 (t) :w t+R  w t +  ;  > 0, t drop < t < t drop +  w tdrop +    * w tdrop +  -  ;  < 1 w t is the congestion window at time t Ris the RTT ,  and  are constants

11 C w n d f 1 (t) f 2 (t) Pkt Drop  Time DCR-I Steady State Analysis A Throughput = Number of packets between two successive drops Time between two successive drops t2+t2+ t1t1 t2t2

12 DCR-I Steady State Analysis (contd.)  (  /2 ) ( 1 +  ) / ( 1 -  ) = R  p Comparing with the TCP-equation, the condition of TCP- Friendliness is : 3 ( 1 -  )  = ( 1 +  ) Infinite number of values can be chosen for  and  that satisfy the above condition. We chose  = 1 and  = 1/2 since it is makes DCR-I very similar to TCP-reno.

13 DCR-I Implementation Testing platform was ns-2 Modifications were made to the existing TCP-reno. When congestion in the network was notified, the time-to- response was noted. Congestion window was continuously increased until the time-to- response, at which time it was cut down by half.

14 DCR-D Primary aim of DCR-D is to provide smooth response. f 2 (t) is thus chosen to be a decreasing function and  is set to1. C w n d f 1 (t) f 2 (t) Pkt Drop  Time

15 DCR-D We have, f 1 (t):w t+R  w t +  ;  > 0 f 2 (t) :w t+R   * w t ; 0 <  < 1, t drop < t <t drop +  w t is the congestion window at time t Ris the RTT ,  and  are constants

16 t2+t2+ C w n d f 1 (t) f 2 (t) Pkt Drop Time DCR-D Steady State Analysis Throughput = Number of packets between two successive drops Time between two successive drops N1N1 N2N2 t1t1 t2t2

17 DCR-D Steady State Analysis (contd.) Set K =  , the factor by which the congestion window is decreased over the period of ‘  ’ RTTs 1 = R (  2p(1-K)/  (1+K) + p  ( [2(1-K)/lnK(1+K)] + 1 ) ) The above equation is TCP-Friendly if second term in the denominator is negligible

18 DCR-D Steady State Analysis (contd.) Condition for TCP-Friendliness is : p  2. (1-K) + 1 = 0 lnK (1+K) For different values of K, the results of the above equation is given as follows -

19 DCR-D Steady State Analysis (contd.) With K = 0.8, the throughput equation can be written as 1 = R (  2p(1-K)/  (1+K) * p  ) Second term in the denominator is negligible. Comparing the above equation with TCP equation we have, 3 ( 1-K)  = (1+K) With K = 0.8,  = 0.333

20 DCR-D Implementation Testing platform was ns-2 with modifications made to the existing TCP-reno. Two modes of operation Increase mode : seeking bandwidth using f 1 (t) Decrease mode : reducing bandwidth using f 2 (t) On congestion notification start a delay timer for ‘  ’ RTTs and get into decrease mode. When the delay timer expires return to Increase mode.

21 DCR-D Implementation(contd.) While entering the decrease mode note down the target value of the congestion window to be achieved at the end of decrease mode. If packet is dropped in decrease mode, Reset the delay timer. Reduce the congestion window to its target value drastically. Set a new delay timer to take care of latest congestion. Note down the current target value. Reasoning: Packet drop during decrease mode indicates high level of congestion. Thus drastic reduction in congestion window is required as compared to the smooth reduction using f 2 (t).

22 DCR-D Congestion Window Evolution at High Droprates C w n d Target Value Pkt Drop Time Pkt Drop Original Timer New Timer

23 DCR-C f 2 (t) is an constant function C w n d f 1 (t) Pkt Drop   Time f 2 (t)

24 DCR-C We have, f 1 (t):w t+R  w t +  ;  > 0 f 2 (t) :w t+R  w t ; t drop < t <t drop +  w tdrop +    * w tdrop +  -  ;  < 1 w t is the congestion window at time t Ris the RTT ,  and  are constants Analysis shows this protocol cannot be TCP-Friendly. So simulations were not conducted for this protocol.

25 Simulation Topology R1 Src 1 R2 Sink 1 Sink 2 Sink n Src 2 Src n Bottleneck Link B Mbps D ms

26 Simulation Results DCR-I Fairness Index at Different Droprates

27 Simulation Results DCR-I Fairness Index at Different Buffer Sizes

28 Simulation Results DCR-I Fairness Index with mixed workload

29 Simulation Results DCR-I Sample per-flow droprates for mixed workload

30 Simulation Results DCR-I Fairness Index at Different Droprates with Drop Tail Router

31 Simulation Results DCR-I Sample values of per-flow droprates (Drop Tail Router)

32 Simulation Results DCR-I Effects of Clock Resolution

33 Simulation Results DCR-D Fairness Index at Different Droprates

34 Simulation Results DCR-D Fairness Index at Different Buffer Sizes

35 Simulation Results DCR-D Fairness Index with mixed workload

36 Simulation Results DCR-D Sample per-flow droprates for mixed workload

37 Simulation Results DCR-D Fairness Index at Different Droprates with Drop Tail Router

38 Simulation Results DCR-D Sample values of per-flow droprates (Drop Tail Router)

39 Simulation Results DCR-D Effects of Clock Resolution

40 Simulation Results DCR-D Effects of Clock Resolution With Compensated 

41 Simulation Results Measure of smoothness Protocols used with real-time audio-video application require smooth sending rates Use coefficient of variance as a measure of smoothness Note throughput at  intervals of time For each flow compute the cov as (standard deviation) / (mean) of these values For the protocol, the cov is the average cov of all the flows using that protocol.

42 Simulation Results DCR-D Coefficient of Variance at Different Droprates (  = 0.5s)

43 Simulation Results DCR-D Coefficient of Variance at Different values of  (p = 0.1%)

44 Conclusions In this thesis, we have, provided the general frame work for Delayed Congestion Response protocols. examined three cases in particular and shown through analysis and simulations that two of these can be TCP-friendly for a wide range of network parameters. Using DCR-D, shown that sending rate can be made smoother through the proper design of the function f 2 (t).

45 Conclusions (contd.) Regarding the TCP-Friendliness we have shown,  1/  p is necessary but not sufficient condition for determining TCP-Friendliness. TCP-Friendliness depends on the underlying buffer management scheme. TCP-Friendliness is affected by the type of workload on the system, even in the presence of an active buffer management scheme.

46 Future Work Work needs to be done in synthesizing the general equations to provide proper guidelines for choosing the values of (f 1 (t), f 2 (t), ,  ). Substantial work needs to be still done to characterize TCP- Friendliness

47 Questions ???

48 Related Work “ModelingTCP Throughput: A simple Model and its Empirical Validation” by J.Padhye, V. Firoiu, D.Towsley and J.Kurose. Developed an Analytical Model for TCP’s congestion control mechanism in terms of loss rate and RTT Captures the behavior of fast retransmit and the timeout mechanism. Evaluated using network traces obtained from the internet.

49 Related Work (contd.) “Equation-Based Congestion Control for Unicast Applications” by Sally Floyd, Mark Handley, Jitendra Padhye, and Joerg Widmer. Directly based on the TCP control Equation. Receiver provides feed back for RTT calculations. Receiver calculates loss event rate and feeds it back to sender. Sender takes care of RTT calculations, retransmission ( if required) and adapts the sending rate based on the equation.

50 Related Work (contd.) “Equation-Based Congestion Control for Unicast Applications” by Sally Floyd, Mark Handley, Jitendra Padhye, and Joerg Widmer. How to calculate the loss rate ? Instantaneous Values vary too much and are too noisy Averaged value could dampen the response to congestion. Limited History Weighted Average was used with history of previous 8 loss events out of which latest 4 were weighted heavily. Requires 4 to 8 round trip times to halve its sending rate in response to persistent congestion

51 Related Work (contd.) “Equation-Based Congestion Control for Unicast Applications” by Sally Floyd, Mark Handley, Jitendra Padhye, and Joerg Widmer. Shown to be TCP-Friendly over a wide range of parameters. Reduces variations in the sending rate compared to TCP. Loss rate calculations based on heuristics. Implementation is complex and requires modification of sender and receiver.

52 Related Work (contd.) “LDA+ TCP-Friendly Adaptation: A Measurement and Comparison Study” by Sisalem, D. and Wolisz, A. Also uses TCP control equations to compute sending rate, but at the application level. Uses Real-Time Protocol (RTP) for collecting loss and delay statistics. Shown via simulations and experiments on the public internet to be TCP-Friendly.

53 Related Work (contd.) “LDA+ TCP-Friendly Adaptation: A Measurement and Comparison Study” by Sisalem, D. and Wolisz, A. Application level solution which provides closed feedback requiring no implementation of separate transport layer protocol. Therefore, an attractive option. Depends on RTP messages to obtain loss rates, cannot change fast enough in case of rapid changes in the network. Receiver report uses 8 bits for loss information setting a limit of for minimum loss rate.

54 Related Work (contd.) “TCP-friendly Congestion Control for Real-time Streaming Applications” by D. Bansal and H. Balakrishnan. Congestion Control Equations written in the form of binomial equations I : w t+R  w t +  / w t k ;  > 0 D: w t+  t  w t -  w t l ; 0 <  < 1 Irefers to increase in window D refers to decrease in window w t is the congestion window at time t RRTT  and  constants

55 Related Work (contd.) “TCP-friendly Congestion Control for Real-time Streaming Applications” by D. Bansal and H. Balakrishnan. Covers the entire class of linear controls k= 0, l = 1  AIMD k= -1, l = 1  MIMD k= -1, l = 0  MIAD k= 0, l = 0  AIAD Steady State Analysis shows T  1/ p 1/(k + l + 1) This class of protocols will be TCP-Friendly when k + l = 1 and l  1 (called the k + l rule)

56 Related Work (contd.) “TCP-friendly Congestion Control for Real-time Streaming Applications” by D. Bansal and H. Balakrishnan. Simulations with two implementations namely Inverse Increase/Additive Decrease (k = 1, l = 0) and SQRT (k = 1/2, l = 1/2) were shown to be TCP-friendly Equations indicate that several TCP-Friendly protocols can be designed based on the application requirement, provided they follow the k+l rule. Important observation: TCP-Friendliness does not necessarily indicate TCP-Compatibility.

57 DCR-I Simulation Results (contd.) Effect of RED parameters

58 DCR-I Simulation Results (contd.) Effect of RED parameters (contd.)