Analytical Model for Congestion Control and Throughput with TCP CUBIC connections

Transcription

1 Analytical Model for Congestion Control and Throughput with TCP CUBIC connections Sudheer Poojary and Vinod Sharma Department of Electrical Communication Engineering Indian Institute of Science, Bangalore Abstract We develop a Markov model for a TCP CUBIC connection. Next we use it to obtain approximate expressions for throughput when there may be queuing in the network. Finally we provide the throughputs different TCP CUBIC and TCP NewReno connections obtain while sharing a channel when they may have different round trip delays and packet loss probabilities. Index Terms TCP CUBIC, Internet window flow control, High speed Internet. I. INTRODUCTION TCP along with UDP has been the dominant transport layer protocol for the Internet. Traditionally TCP (TCP Reno [1] and TCP NewReno [2]) has been using an AIMD (Additive Increase Multiplicative Decrease) algorithm for congestion control. In the AI phase of the algorithm, the window sizes are increased linearly at the rate of one packet per RTT (round trip time). On detection of congestion, the window size is reduced to half of its current value, this is the MD phase of the algorithm. The specifics of the AIMD algorithm can be found in [3], [4]. The AIMD algorithms have performed well and have prevented severe congestion for more than two decades [5]. However as the Internet evolves to higher speeds, it has been found that the congestion control mechanism of AIMD TCP prevents it from using the link capacity efficiently. For example, in [5] it is shown that with a 10Gbps link, the maximum data rate attained by using an AIMD TCP is 7.55Gbps. It turns out that the slow linear window growth function of the AIMD TCP is a bottleneck in the high speed, large delay environment. Thus there has been a significant amount of research on improving the TCP performance by using aggressive congestion control mechanisms. H-TCP [6], Fast TCP [7], BIC [8], CUBIC [9] are a few examples. The H-TCP algorithm changes the rate of additive increase based on time elapsed since last congestion. It behaves like TCP Reno when the time elapsed since last congestion is low but as it increases, the window growth becomes more aggressive. FAST TCP measures RTT to update its window size and uses queuing delay as a congestion signal. BIC TCP uses packet drops as a sign of congestion and then searches for the optimum sending rate using a binary search mechanism. CUBIC, like H-TCP, uses time elapsed since last congestion to update its window size via a cubic function. The high speed congestion control mechanisms are expected to utilize the link efficiently but should not do this at the expense of standard TCP, i.e., they should be fair to standard TCP. Also, RTT fairness, which is a measure of fairness in data rate of flows with different RTTs, is another measure of performance. In [9], the authors show through experiments that TCP CUBIC scores high on the above performance measures compared to other congestion control mechanisms. TCP CUBIC has also been the default congestion control mechanism on Linux since 2006 (Linux kernel ). Thus, there has been considerable work on performance evaluation of TCP CUBIC through experiments and simulations [10], [11]. However [12] seems to be the only theoretical study on CUBIC. It considers a single TCP source. A Markov model of the window size is formed. Mean window size is obtained when the packet loss process is Poisson and RTT is constant. There are a number of analytical models for AIMD TCP. In [13] and [14], the authors make deterministic models of the TCP window size evolution and obtain expressions for TCP throughput. In [15], the authors model the window size evolution as a Markov regenerative process. They also consider the effect of retransmission timeouts on the data rate of TCP. [16] considers the effect of connection establishment and slow start on TCP data transfers. They extend the steady state model of [15] to compute latencies of short as well as long lived TCP flows. [17] analytically evaluates performance of TCP Tahoe and TCP Reno sharing a link subject to random losses. In [18], the authors calculate the throughput for multiple TCP connections which share the bottleneck link with UDP connections. [19] analyzes performance of multiple TCP connections going through multiple routers with exogenous traffic. The stability of the system is proved and throughput for each TCP flow is obtained when the routers employ RED [20]. In [21], the authors develop a model for determining drop probabilities of TCP flows in a TCP/IP network. The above models hold for AIMD TCP where the window growth function is linear. However, as the window growth function for CUBIC is nonlinear, we require a different model for its analysis. In this paper, we build an analytical model for TCP CUBIC with random packet drops and constant RTT. The model is further extended to the case where there is queuing, the RTT is variable and there are multiple TCP CUBIC and NewReno connections sharing a bottleneck link. Through comparison with ns-2 simulations we show that our model has good accuracy in capturing the dynamics of TCP-CUBIC /11/$ IEEE

2 TCP 1 Δ 1 ACKs III. WINDOW DYNAMICS OF TCP CUBIC TCP CUBIC, unlike TCP Reno has a cubic window growth function given by TCP N Data :. Data Fig. 1. Router Δ N C ACKs System with N TCP connections sharing a link The paper is organised as follows. Section II describes the system model. Section III makes a simple model of TCP CUBIC window flow control. It is then extended in Section IV to the case where there may be queuing and we obtain an approximation of the mean window size and the throughput obtained. In Section V we use these approximations to obtain throughputs and mean window sizes when multiple TCP CUBIC and NewReno connections share a link. Section VI concludes the paper. II. SYSTEM MODEL We consider the system shown in Fig 1. It has N TCP connections using TCP CUBIC (some perhaps TCP NewReno). They pass through a router/base station with link speed C bps. Each connection is transmitting a long file, i.e., it always has a packet to send. Each packet of connection i gets lost in transmission with probability p i 0 independently of others. (This is a likely scenario if the link is wireless). The connection i also has other propagation delay Δ i which may be a combination of other (non-bottleneck) link propagation and/or processing delays in the network. We will take Δ i sto be constant. This is a standard building block for a possibly larger network and is commonly considered in literature ([12], [15]). The main performance measure for this system is the throughputs obtained by the different TCP connections. To obtain the throughputs of different connections in this setup, we proceed as follows. First we consider a single TCP CUBIC connection and obtain its throughput when there is no queuing delay (i.e., the RTT is constant). To obtain its throughput, we study the window dynamics of TCP CUBIC which is quite different from AIMD TCP connections. In particular, we obtain the mean window size E[W ] of the connection when the packets are dropped with probability p and there is a fixed RTT Δ. Then the throughput is E[W ]/RT T. Next we generalize the setup to include queuing delays. Finally we consider the multiple TCP scenario and also integrate the dynamics of TCP NewReno. W cubic (W 0,t)=C(t K) 3 + W 0 (1) where W 0 is the window size at the last congestion epoch (the last instant there was a drop), t is the time elapsed since last congestion, K = 3 (W 0 β/c), C is a constant called the CUBIC parameter and β is another constant called the multiplicative drop factor. When there is a packet drop, the window is reduced to (1 β)w 0. The CUBIC function is chosen such that just after congestion the window size grows steeply towards W 0 which is the window size at which last congestion happened and then increasing slowly as the window size is near to W 0.The window size W 0 is deemed to be the steady state and hence the increase is slow near W 0. If the window size stays for a fair amount of time near W 0 without congestion, the window size further increases steeply to identify a new steady state. As the window size evolution in CUBIC is independent of RTT, CUBIC is RTT-fair. TCP CUBIC also incorporates TCP-friendly behaviour into its operation. A high speed protocol is called TCP-friendly if it is fair to standard TCP (AIMD TCP), i.e., does not steal bandwidth from standard TCP. To achieve both link efficiency and TCP friendliness, TCP CUBIC uses two window growth functions. When it is operating in TCP friendly region it evolves as W reno (W 0,t)=W 0 (1 β)+3 β t 2 β RT T. (2) The congestion window is updated when an ACK is received. On receipt of an ACK, equations (1) and (2) are evaluated to identify the mode of operation. If W reno (W 0,t) is larger than W cubic (W 0,t), then CUBIC operates in the TCP friendly region and uses eqn. (2), else it uses the cubic window growth function in eqn. (1). The details of TCP CUBIC operation can be found in [9]. We construct a model for CUBIC based on equations (1) and (2). We consider the case where the packet losses are random. Such a scenario would be common when the end systems use wireless links which are subject to random packet losses. We first consider the case where the link capacity is sufficiently large such that there is no queuing. Hence the RTT is constant in this case. In this setup it is convenient to assume that all the ACKs reach the TCP source at the same time (at the end of the RTT). Then if a packet is lost, its effect on the window size is also seen at the end of the RTT. This happens if the RTT is much larger than the transmission time. Let the window size at the beginning of the k th RTT period be W k. The window size at the congestion epoch preceding the k th RTT is denoted by W k. The time elapsed since the preceding congestion epoch (in multiples of RTT) is denoted by D k. We see that {(W k,d k)} forms a discrete time countable state (since D k is a multiple of RTT) Markov process.

3 The TCP sending rate is also constrained by the buffer space available at the receiver. The receiver notifies this to the sender during the initial handshake. The sender s congestion window size is then restricted to be less than (say) W max. Hence, W k is given as W k = W k (W k = w,d k = d) = min(w max, max(w cubic (w,d),w reno (w,d))) where, the functions W cubic (w,d) and W reno (w,d) are specified in equations (1) and (2) respectively. The process {(W k,d k)} evolves as (3) W k+1 = W k,d k+1 = D k +1 (4) if there is no packet loss in the k th RTT and as W k+1 = W k (1 β), D k+1 =0 (5) if some of the packets in the k th RTT are lost. (We ignore the effect of multiple packet drops in an RTT. We will see that it will have negligible effect on window dynamics for packet loss probabilities of practical interest). The probability of atleast one drop in the k th RTT period, when the window size is W k packets, is given by 1 (1 p) W k. This together with (4), (5) provides the transition matrix P of the Markov chain {(W k,d k)}. Since W k 1, the minimum probability of loss is p and maximum window size is W max <. Thus the state (1, 0) is reachable from any state in {(W k,d k)} within N steps with probability p N where N is the smallest integer with W max (1 β) N 1. This implies that the mean inter-arrival time of state (1, 0) is finite. Thus {(W k,d k} is an irreducible positive recurrent Markov chain with a unique stationary distribution π. Then, E[W ]= (1 β)w max (d= w =1 d=0 ) W k (w,d)π(w,d). (6) The average window sizes that we obtain using the above analysis for different values of RT T and packet error rate p are shown in Fig. 2. We also include the results via ns-2 simulation. For the ns-2 simulations, we set the bottleneck link capacity to be 1 Gbps which causes negligible queuing. We see a close match between the theoretical values and the ns-2 simulations. Once steady state E[W ] is obtained, the throughput in this setup (since RTT is fixed) is E[W ]/RT T packets/sec. We observe that for TCP Reno in this setup, E[W ] does not change with RTT; only with p. But for TCP CUBIC it is increasing with RTT for any given p. This is what gives it better throughput than TCP Reno for large RTT. In the next section we extend our model to the case where there is queuing and hence the RTT is not constant. IV. WINDOW DYNAMICS AND THROUGHPUT WITH VARIABLE RTT When the queuing delays at the router/base station are not negligible, computing TCP throughput is more complicated. In EW E[W] vs RTT for TCP CUBIC with random packet losses with packet error rate = p 70 p = (model) p = (model) 60 p = (model) p = (model) p = (ns 2) 50 p = (ns 2) p = (ns 2) 40 p = (ns 2) Fig RTT Average window sizes obtained using the Analytical model [22], the following M/GI/1 approximation was used for TCP Reno and was found to provide a good approximation. When RTT is constant, E[W ] for TCP Reno (at the end of RTT) depends on packet loss probability p but not on the RTT. Then the throughput obtained is E[W ]/RT T. If there is random RTT due to queuing delay then we approximate the TCP throughput by E[W ]/E[RT T ] λ packets/sec where E[RT T ] is the steady state mean RTT. However, we do not know E[RT T ]. This is approximated by E[RT T ]=Δ+E[S], (7) where E[S] is the mean sojourn time in an M/GI/1 queue with rate λ and the service time distribution same as the transmission time distribution in our system. Thus if the packet lengths in the TCP connection are iid with a generic length s, and its mean and second moment given by E[s] and E[s 2 ], from M/GI/1 results ([23]), we obtain E[S] = λe[s2 ] 2C 2 (1 ρ) + E[s] C where ρ = λe[s] C. Solving the system of equations (8) λ = E[W ],E[RT T ]=Δ+E[S] (9) E[RT T ] with E[S] given in (8) we obtain λ and E[RT T ] (and hence E[S]). It is worth remarking that in general an M/GI/1 queue will not give a good approximation to a TCP connection due to the window flow control of TCP. But (8) and (9) together capture that dynamics. Since the above approximation worked well for TCP Reno, we would like to use it for TCP CUBIC also. The difference in this case, as mentioned above, is that E[W ] depends on RTT. In the last section we computed E[W ] as a function of RTT and p when RTT was fixed. We use the same relationship now but replace RTT by E[RT T ] (this is an approximation which will be validated via ns-2 simulations). We write this relationship as E[W ]=g p (E[RT T ]) (10)

4 EW E[W] vs Δ for TCP CUBIC, link capacity = 10Mbps, link packet error rate = p NS2, p = 0.01 MG1 model, p = 0.01 NS2, p = MG1 model, p = Δ (Propagation delay) Fig. 3. Comparison of average window sizes obtained through the model and ns-2 for variable RTT Throughput Throughput vs Δ for TCP CUBIC, link capacity = 10Mbps, link packet error rate = p NS2, p = 0.01 MG1 model, p = 0.01 NS2, p = MG1 model, p = Δ (Propagation delay) Fig. 4. Comparison of throughput obtained through the model and ns-2 for variable RTT when we keep the packet loss probability p fixed. Although we do not have a closed form expression for g p, we compute g p (E[RT T ]) numerically as in the last section. We solve equations (8), (9) and (10) simultaneously to find λ, E[RT T ] and E[W ]. The results thus obtained are compared with ns-2 simulations with the same parameters. We use the Linux TCP CUBIC code incorporated into ns-2 ([24]) for our simulations. We compare the average window sizes obtained using the model and using ns-2 simulations in Fig. 3 for packet error probabilities p = 0.01 and The throughputs are compared in Fig. 4. The link capacity C is 10 Mbps and the packet size is 1050 bytes. (C is kept 10Mbps to have non-negligible queuing delay.) We see a close match between theory and simulations. In the next section, we use the model and the M/GI/1 approximation to get results for multiple TCP connections with different RTT and different probabilities of packet loss. V. THROUGHPUT AND AVERAGE WINDOW SIZES FOR MULTIPLE TCP CONNECTIONS Now we consider the system shown in Fig. 1 where multiple TCP connections 1, 2,,N share a single link. The TCP connection i is subject to random packet losses with rate p i and has a total propagation delay (i.e., from the source node to the destination node and back) of Δ i outside the queue. The shared link is the bottleneck link with capacity C bps. Initially we assume that all connections use TCP CUBIC. We will include TCP NewReno later. We use the M/GI/1 approximation to evaluate the sojourn time in the queue at the router. The average RTT for connection i is given by E[RT T i ]= λe[s2 ] 2C 2 (1 ρ) + E[s] C +Δ i (11) when E[s] and E[s 2 ] are the overall mean packet length and its second moment and λ packets/sec is the overall throughput. If λ i is the throughput of TCP connection i, then E[s] = i λ i λ E[s i], E[s 2 ]= i Then the mean window size of i th connection is λ i λ E[s2 i ]. (12) E[W i ]=g pi (E[RT T i ]) (13) and its throughput is approximated by λ i = E[W i] E[RT T i ]. (14) We can solve (11), (13) and (14) to obtain λ i, E[W i ] and E[RT T i ] for i =1, 2,,N. If some of the TCP connections (say connection i) areusing TCP NewReno, then we will still use the above system of equations except that g pi in (13) becomes a constant (i.e., independent of E[RT T i ]), equal to E[W i ] corresponding to its p i. There are several approximations available for E[W i ] for TCP NewReno. We use in our computation an expression from [14]. Table I compares results obtained using our model and ns- 2 simulations for the average window sizes E[W 1 ], E[W 2 ] for two TCP CUBIC connections with loss probabilities and propagation delays as mentioned in the table. The bottleneck link capacity is 2 Mbps (which provides substantial queuing delays). The Tables II, III compare the throughputs and the average RTT respectively. The approximations for throughput are better than for E[W ] and RTT. Next, we provide results for three TCP CUBIC connections. Tables IV and V compare the average window sizes and throughputs respectively. In this case connection i (i =1, 2, 3) experiences packet drop probability p i and propagation delay Δ i. The bottleneck link capacity is set to 5 Mbps. The approximations in this case are better. We have also compared the results for 10Mbps and 100Mbps link speeds. The approximations improve with link speed. These results are omitted due to lack of space. Tables VI and VII compare the average window sizes and throughputs for two TCP connections, one CUBIC and the other NewReno, sharing a link. Both the connections are subject to the same loss rate p =0.005 and same propagation delay Δ. We see that CUBIC is fair to NewReno at low RTTs but as the propagation delay, and hence the RTT, increases the data rates for CUBIC are much higher than NewReno. VI. CONCLUSIONS AND FUTURE WORK This paper develops an analytical model for TCP CU- BIC with fixed RTT and random packet losses. Through comparison with ns-2 simulations, we show that the model captures the dynamics of TCP CUBIC fairly well. We get the

5 TABLE I AVERAGE WINDOW SIZES FOR TWO TCP CONNECTIONS WITH BOTTLENECK LINK CAPACITY = 2 MBPS p 1,p 2 Δ 1, Δ 2 EW 1,EW 2 EW 1,EW TABLE II THROUGHPUTS FOR TWO TCP CONNECTIONS WITH BOTTLENECK LINK CAPACITY = 2 MBPS p 1,p 2 Δ 1, Δ 2 λ 1,λ 2 λ 1,λ TABLE III AVERAGE RTT FOR TWO TCP CONNECTIONS WITH BOTTLENECK LINK CAPACITY = 2 MBPS p 1,p 2 Δ 1, Δ 2 RT T 1,RTT 2 RT T 1,RTT TABLE IV AVERAGE WINDOW SIZES FOR THREE TCP CONNECTIONS WITH BOTTLENECK LINK CAPACITY = 5 MBPS Connection i p i Δ i EW i EW i (NS2) (Theory) TABLE V THROUGHPUT FOR THREE TCP CONNECTIONS WITH BOTTLENECK LINK CAPACITY = 5 MBPS Connection i p i Δ i λ i λ i (NS2) (Theory) TABLE VI AVERAGE WINDOW SIZE FOR CUBIC AND NEWRENO CONNECTIONS WITH BOTTLENECK LINK CAPACITY = 2 MBPS, 1 GBPS Link Speed Δ EW 1,EW 2 EW 1,EW 2 CUBIC, NewReno CUBIC, NewReno 2Mbps Gbps average window size, throughput and average RTT for TCP connections with variable RTT, i.e., connections subject to non-negligible queueing by approximation of the router with a M/GI/1 queue. We also obtain the above quantities for multiple TCP connections sharing a common bottleneck link. Finally we model the scenario where the TCP CUBIC connections share a link with TCP NewReno connections. The results using the model closely match the results obtained through ns-2 simulations. Further work would consider TCP connections going through multiple bottleneck links. TABLE VII THROUGHPUT FOR CUBIC AND NEWRENO CONNECTIONS WITH PACKET ERROR RATE, P = Bottleneck Link Speed Δ λ 1,λ 2 λ 1,λ 2 CUBIC, NewReno CUBIC, NewReno 2Mbps Gbps

6 REFERENCES [1] M. Allman, V. Paxson, and W. Stevens, TCP Congestion Control, RFC 2581 (Proposed Standard), Internet Engineering Task Force, Apr [2] S. Floyd and T. Henderson, The NewReno Modification to TCP s Fast Recovery Algorithm, RFC 2582 (Experimental), Internet Engineering Task Force, Apr [3] V. Jacobson, Congestion avoidance and control, in Symposium proceedings on Communications architectures and protocols, ser. SIG- COMM 88. New York, NY, USA: ACM, 1988, pp [4] R. Jain, K. K. Ramakrishnan, and D.-M. Chiu, Innovations in internetworking. Norwood, MA, USA: Artech House, Inc., 1988, ch. Congestion avoidance in computer networks with a connectionless network layer, pp [5] G. Huston, Gigabit TCP, Internet Protocol Journal, [6] R. N. Shorten and D. J. Leith, H-TCP: TCP for high-speed and longdistance networks, in Proc. PFLDnet, Argonne, 2004., [7] C. Jin, D. Wei, S. H. Low, J. Bunn, H. D. Choe, J. C. Doyle, H. Newman, S. Ravot, and S. Singh, Fast TCP: From theory to experiments, IEEE Network, vol. 19, pp. 4 11, [8] L. Xu, K. Harfoush, and I. Rhee, Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks, in INFOCOM 04, [9] S. Ha, I. Rhee, and L. Xu, CUBIC: a new TCP-friendly high-speed TCP variant, SIGOPS Oper. Syst. Rev., vol. 42, pp , July [10] M. Bateman, S. Bhatti, G. Bigwood, D. Rehunathan, C. Allison, T. Henderson, and D. Miras, A comparison of TCP behaviour at high speeds using ns-2 and linux, in Proceedings of the 11th communications and networking simulation symposium, ser. CNS 08. New York, NY, USA: ACM, 2008, pp [11] M. C. Weigle, P. Sharma, and J. Freeman IV, Performance of competing high-speed TCP flows, in Proceedings of NETWORKING, Coimbra, Portugal, may 2006, pp [12] W. Bao, V. W. S. Wong, and V. C. M. Leung, A Model for Steady State Throughput of TCP CUBIC, in GLOBECOM, 2010, pp [13] T. Bonald, Comparison of TCP Reno and TCP Vegas: efficiency and fairness, Performance Evaluation, vol , pp , [14] M. Mathis, J. Semke, J. Mahdavi, and T. Ott, The macroscopic behavior of the TCP congestion avoidance algorithm, SIGCOMM Comput. Commun. Rev., vol. 27, pp , July [15] J. Padhye, V. Firoiu, D. F. Towsley, and J. F. Kurose, Modeling TCP Reno Performance: A Simple Model and Its Empirical Validation, IEEE/ACM Transactions on Networking, vol. 8, pp , [16] N. Cardwell, S. Savage, and T. Anderson, Modeling TCP latency, in in IEEE INFOCOM, 2000, pp [17] T. V. Lakshman and U. Madhow, The performance of TCP/IP for networks with high bandwidth-delay products and random loss, IEEE/ACM Trans. Netw., vol. 5, pp , June [18] V. Sharma and A. Gupta, Performance analysis of routers with TCP and UDP connections with priority and RED control, in Proceedings of the 15th international conference on Computer communication, ser. ICCC 02. Washington, DC, USA: International Council for Computer Communication, 2002, pp [19] V. Sharma and P. Purkayastha, Stability and Analysis of TCP Connections with RED Control and Exogenous Traffic, Queueing Syst. Theory Appl., vol. 48, pp , November [20] S. Floyd and V. Jacobson, Random early detection gateways for congestion avoidance, IEEE/ACM Trans. Netw., vol. 1, pp , August [21] E. Altman, K. Avrachenkov, and C. Barakat, TCP Network Calculus: The case of large delay-bandwidth product, in in Proceedings of IEEE Infocom, [22] K. Anand and V. Sharma, Computing TCP Throughput in a UMTS Network, in IEEE WCNC, 2008, pp [23] D. Bertsekas and R. Gallager, Data Networks 2nd Edition. Prentice- Hall, Inc., [24] D. X. Wei and P. Cao, NS-2 TCP-Linux: an NS-2 TCP implementation with congestion control algorithms from Linux, in WNS2 06: Proceeding from the 2006 workshop on ns-2: the IP network simulator. New York, NY, USA: ACM Press, 2006, p. 9.