TRANSMISSION control protocol (TCP), a reliable transport

Microscopic Behaviors of TCP Loss Recovery using Lost Retransmission Detection Beomjoon Kim, Yong-Ho Kim, Min-Seok Oh, and Jin-Sung Choi Standardization and System Research Group (SSRG), LG Electronics Inc. LG R&D Complex, 33 Hogye-1dong, Dongan-gu, Anyang-shi, Kyongki-do, 431-749, Korea Email: {beom, ronnykim, minoh, jinsungc}@lge.com Abstract As today s networks evolve towards an IP-based integrated network, the role of transmission control protocol (TCP) has been increasing as well. As a well-known issue, the performance of TCP is affected by its loss recovery mechanism that is comprised of two algorithms; fast retransmit and fast recovery. Although (RTO) caused by multiple packet losses can be avoided by the modified fast recovery algorithm of TCP NewReno or selective acknowledgement (SACK) option, RTO cannot be avoided if a retransmitted packet is lost. To cope with the problem, Lost Retransmission Detection (LRD) has been proposed for each TCP in [9], []. In this paper, we evaluate the LRD algorithm by tracing TCP sender s behaviors for several scenarios where a retransmitted packet is lost. In addition, we consider the conservation of packets rule to advocate that LRD does not violate fairness with TCP connections that do not support the LRD algorithm. Index Terms transmission control protocol (TCP), loss recovery, (RTO), lost retransmission detection (LRD) I. INTRODUCTION TRANSMISSION control protocol (TCP), a reliable transport layer protocol used in the Internet, provides a function of congestion control to avoid so-called congestion collapses [1]. In TCP congestion control [2], a function for a TCP sender to detect and recover a packet loss is implemented, and called loss recovery in simple. The loss recovery mechanism is based on two basic algorithms of fast retransmit and fast recovery. If loss recovery is successful, a sender need not wait for (RTO) expiry in which the sender is not allowed to transmit a packet. The fast retransmit algorithm [1], [2] makes it possible for TCP sender to retransmit a packet loss immediately if it receives three duplicate acknowledgements (ACKs) for the packet loss. The fast recovery algorithm [2] that is implemented in TCP Reno prevents a link connecting a sender and a receiver from going empty after fast retransmit. By adopting fast recovery, a few new packets can be transmitted, thereby avoiding the need to restart in slow start after all packet losses are recovered. In TCP loss recovery, it has been a major challenge to decrease the number of RTOs that may occur if loss recovery fails. The effect of RTO on TCP performance, e.g. throughput, can be explained by the following two facts; a sender transmits few packets till it expires. a sender shall restart in slow start mode with the initial value of congestion window (cwnd). Consequently, frequent RTOs degrade TCP performance more severely. In a certain situation, RTO may occur unnecessarily, e.g., even if pipe [1] is still available. These unnecessary RTOs can be classified into three groups. First, if multiple packets are lost in a window at the same time, then all the packet losses cannot be recovered without RTO in most cases. It is because the initial fast recovery algorithm implemented in TCP Reno is optimized for a single packet loss in a window. In order to retransmit multiple packets, TCP Reno requires to receive three duplicate ACKs for each packet loss. However, since it reduces its window by half every time it retransmits a packet loss, it is almost impossible to recover multiple packet losses by fast retransmit. This challenge has been a main driver for efforts to optimize the fast recovery algorithm, and two solutions appear; TCP NewReno [3], [4] and using selective acknowledgement (SACK) option [], [6]. The fast recovery algorithm is slightly modified in the implementation of TCP NewReno. During fast recovery, a TCP NewReno sender does not exit fast recovery when it receives a partial acknowledgement, which acknowledges some but not all of the packets that are outstanding at the start of the fast recovery period. Thus, when multiple packets are lost, TCP NewReno can recover one packet loss per a round trip time (RTT) until all of packet losses have been retransmitted. Another alternative to handle multiple packet losses is using selective acknowledgement (SACK) option [], [6]. Although some additive bytes are needed to include SACK information in each duplicate ACK, the sender supporting SACK option can be informed about all of the packets that have arrived successfully, so that it needs to retransmit only the packets that have been lost. Second, if a packet is lost in a window that is very small, then three duplicate ACKs may not be received to trigger a fast retransmit. This situation can be experienced frequently in the connection of short Web transfer using the HyperText Transfer Protocol (HTTP) [7]. According to [11], about 8% of timeouts belong to this class. In recent, Limited Transmit is proposed in [8], which makes it possible to trigger a fast retransmit if only a single duplicate ACK can be received. Using Limited Transmit, most RTOs within this class can be avoided as long as RTO does not expire until the third duplicate ACK arrives. Finally, RTO occurs unnecessarily when a retransmitted -783-878-6//$. (C) IEEE

packet is lost. Most TCP implementations have no mechanism to detect and recover a lost retransmission. In recent works presented in [9], [], Lost Retransmission Detection (LRD) is proposed; duplicate acknowledgement counting (DAC) for TCP Reno and NewReno and SACK+ for TCP using SACK option. However, since the loss recovery performance of LRD is evaluated only in a numerical way in these works, the practical situation where LRD benefits cannot be shown obviously. Therefore, this paper shows the microscopic behaviors of each TCP sender using LRD for several scenarios where a retransmission is lost in a similar way as [12] In addition, we discuss the issue of consistency and fairness with existing TCP implementations. The rest of this paper is organized as follows. Section II describes the proposed algorithm for lost retransmission detection with discussion of consistency with the existing TCP congestion control principle. Section III contains the simulation results for two different scenarios where the proposed algorithm is applied to each TCP. Finally, some conclusions are summarized in Section IV. If three duplicate ACKs are received, After fast retransmit, set i=1; W D =cwnd; D i =W D -1 For every new packet transmission during fast recovery, D i+1 =D i+1 +1; More than D i duplicate ACKs are received? No A normal ACK is received? Yes Exit fast recovery Yes No Retransmit the ith packet If another packet is retransmitted, i = i +1; II. LOST RETRANSMISSION DETECTION (LRD) In LRD operations, the packets sent after a retransmitted packet play a key role to determine whether the retransmitted packet is delivered successfully or not. Due to cumulative strategy of TCP [1], [2], the sender without SACK option cannot be informed of which packet and how many packets are lost till it receives a duplicate or partial ACK [3], [12]. In the case of using SACK option, the sender can be aware of the exact number and sequence of packet losses by SACK information in each duplicate ACK [], [6], [12]. In this section, we describe the behavior of LRD when it is applied to TCP NewReno and TCP SACK. A. Duplicate Acknowledgement Counting DAC is designed for TCP not supporting SACK option such as TCP Reno and NewReno. Every time TCP sender retransmits a packet, it keeps a variable to store the number of duplicate ACKs that the sender expects to receive if the retransmitted packet is transmitted well. Also, the sender keeps the congestion window size just before the fast retransmit in another variable, which is denoted by W D. During fast recovery, the sender counts the number of duplicate ACKs for a retransmission. If it receives more duplicate ACKs than the stored value for the retransmission, it determines that its retransmission is lost again and retransmits it immediately without waiting for RTO. We denote the expected number of duplicate ACKs for the ith packet loss in a window by D i. When the sender retransmits the first lost packet in a window by fast retransmit, it is not aware of how many packets are lost in the window, but only knows that at least one packet is lost. Therefore, D 1 is always equal to W D 1. When there are multiple packet losses, DAC can be applied as well. In these cases, D j for j 2 is equal to the number of new packets transmitted after the retransmission of the jth. In Fig. 1, we show the flow chart of DAC operation. Fig. 1. Flow chart of DAC. B. TCP SACK+ As similar as DAC, TCP SACK+ detects whether a retransmitted packet is lost or not based on new packets transmitted after the retransmitted packet. As mentioned above, however, TCP sender that supports SACK option can maintain the exact sequence number of a, even if there are multiple packet losses in a window. Therefore, detecting a lost retransmission is rather simpler than DAC because the sender with SACK option need not count the number of duplicate ACKs. Whenever a sender performs a retransmission, it just stores the highest sequence number of the packets that have been already transmitted for future comparison. In a window, we denote the highest sequence number when the hth packet is retransmitted by S h. If the right edge of the first SACK block [] included in any duplicate ACK is greater than S h, it means that the retransmitted hth packet loss is not successful. As a result, if there is at least a new packet transmitted after a retransmission, a sender can decide whether the retransmission is lost or not based on the information in a duplicate ACK that the new packet generates. C. Consistency with Conventional TCP Congestion Control Conservation of packets [1] is a very critical issue because packets put into networks too aggressively may bring about another network congestion. That is, if a network is so congested that no more packets should be put into the network, the sender should wait for RTO expiry. From the aspect of the principle, LRD is perfectly consistent with additive-increase-multiplicative-decrease (AIMD) scheme specified in [2]. As described above, a lost retransmission is detected based on the packets transmitted after the retransmission. It means that, if congestion is so heavy that no -783-878-6//$. (C) IEEE

packets should be transmitted, TCP sender to which LRD is applied does not transmit additive packets by detecting a lost retransmission. It can be justified by the fact that, in such a congested situation, the packets after the retransmission would be likely to be lost as well. However, since a lost retransmission detected means that there was a serious congestion, the proposed algorithm decreases cwnd and slow-start-threshold (ssthresh) twice after recovery of a lost retransmission as specified in [2]. 1 III. RESULTS AND DISCUSSION In this section, we show the results obtained from both the simulations and numerical analysis. For simplicity, each TCP where LRD is applied is denoted by a + sign such as TCP Reno+, NewReno+, and SACK+. A. Simulation Model LRD implemented using ns simulator. We choose rather a simple model, where a sender and receiver are connected with a link of 1Mbps and msec, because its main purpose is to investigate the detailed behaviors of LRD when it is applied to each TCP. The size of a packet is assumed to be constant, 1Kbytes. After detecting a lost retransmission, the sender decreases its cwnd again as discussed in Section II-C. Simulations were performed for two scenarios where specific packets were forced to be lost as in [12]. For DAC, we consider only the case when it is applied to TCP NewReno because the fast recovery algorithm of TCP Reno has an inherent problem for multiple packet losses [3], [], [12]. Suppose that two packets are lost and the first retransmission is lost. Even if the lost retransmission can be recovered by DAC, it consumes the packets that are going to generate duplicate ACKs to trigger the second fast retransmit, which invokes RTO. Consequently, if DAC is applied to TCP Reno, it is useful only for the case where there is a single packet loss in a window. B. TCP NewReno+ In Fig. 2-(a), the loss recovery behavior of TCP NewReno is shown when a single packet is lost and its retransmission is also lost. At about.7 second, packets 7 14 are transmitted with cwnd of 8 and packet 7 is dropped. When the sender receives the third duplicate ACK at about.9 second, it retransmits packet 7 by fast retransmit. The last duplicate ACK for packet 7 inflates the usable window [12] to 11(= 8/2 +7) so that newly included packets 17 are transmitted. Because the sender cannot perceive that the retransmission of packet 7 has been lost, it just transmits three new packets per every RTT in accordance with receiving the same number of duplicate ACKs till an eventual RTO occurs. It can be seen that the sender restarts in slow start at about 2 second. 1 For a retransmission loss caused by transmission error in a wireless channel, the second decrement is not essential. However, since there is no solution to decide explicitly whether a packet loss is due to congestion or corruption, the proposed algorithm is designed to regard all packet losses as network congestion. 4 4. 1 1. 2 2. 3 4 4 (a) TCP NewReno second retransmission of packet 7. 1 1. 2 2. 3 (b) TCP NewReno+ Fig. 2. Packet transmission behaviors of TCP NewReno and NewReno+ during fast recovery for a single packet loss and its retransmission loss. (RTT=msec) In Fig. 2-(b), we show the behavior of TCP NewReno using DAC for the same scenario as Fig. 2-(a). The sender sets D 1 to 7(= 8 1) when it retransmits packet 7. When the sender receives the eighth duplicate ACK corresponding to the receiver s receipt of packet at about 1.3 second, it can be informed that the retransmitted packet 7 is lost again because it receives more duplicate ACKs than D 1. It can be seen that the sender retransmits packet 7 again at about 1.3 second. After the retransmission, the sender halves cwnd and ssthresh again to be 2(= 4/2 ). Two more duplicate ACKs by packet 16 and 17 inflate the window to be four but no packets can be transmitted because all packets in the window are outstanding. At about 1. second, an ACK that acknowledges all packets up to packet 17 brings the sender out of fast recovery and congestion avoidance starts with cwnd of 2. We repeated the simulations for two packet losses and the -783-878-6//$. (C) IEEE

4 4 4 4. 1 1. 2 2. 3 (a) TCP NewReno. 1 1. 2 2. 3 (a) TCP SACK 4 4 4 4 second retransmission of packet 12 second retransmission of packet 7. 1 1. 2 2. 3 (b) TCP NewReno+ Fig. 3. Packet transmission behaviors of TCP NewReno and NewReno+ during fast recovery for two packet losses and the second retransmitted packet loss. (RTT=msec) results are shown in Fig. 3. In these simulations, two packets, packet 7 and 12, are lost and the retransmitted packet 12 is lost again. TCP NewReno s behaviors shown in Fig. 3-(a) can be explained in the same way as Fig. 2-(a); RTO occurs eventually at about 2.3 second. In the case of using DAC as shown in Fig. 3-(b), when the sender receives a partial ACK for packet 12, D 1 that was set to 7 may be cleared because the partial ACK assures that the retransmitted packet 7 has been transmitted successfully. Note that only 6 duplicate ACKs have been received for packet 7 at this time. After retransmitting packet 12, the sender sets D 2 =2since it has transmitted two packets, packet and 16, after packet 7. Because packet 17 delivers the third duplicate ACK for packet 12, the sender retransmits packet 12 again because it has received more duplicate ACKs than expected. When an ACK that acknowledges all packets up to packet 17. 1 1. 2 2. 3 (b) TCP SACK+ Fig. 4. Packet transmission behaviors of TCP SACK and SACK+ during fast recovery for a single packet loss and its retransmission loss. (RTT=msec) is received, congestion avoidance follows with cwnd of 2. C. TCP SACK+ In Fig. 4, we compare the loss recovery behaviors of TCP SACK+ to TCP SACK when a single packet is lost and its retransmission is also lost. At about.7 second, packets 7 14 are transmitted with cwnd of 8 and packet 7 is dropped. When the sender receives three duplicate ACKs at about.9 second, the sender retransmits packet 7, and sets cwnd to 4(= 8/2 ) and pipe [], [6] to (= 8 3). The last duplicate ACK decreases pipe to one so that three new packets, packet, 16, and 17, are transmitted after the retransmission. Because the retransmitted packet 7 is lost again, the sender receives several repetitive duplicate ACKs per RTT until RTO occurs as shown in Fig. 4-(a) In the case of TCP SACK+ as shown in Fig. 4-(b), the sender sets S 1 to 14 when it retransmits packet 7. The eighth -783-878-6//$. (C) IEEE

4 4. 1 1. 2 2. 3 4 4 (a) TCP SACK second retransmission of packet 12. 1 1. 2 2. 3 (b) TCP SACK+ Fig.. Packet transmission behaviors of TCP SACK and SACK+ during fast recovery for two packet losses and the second retransmitted packet loss. (RTT=msec) duplicate ACK includes SACK information where the first block starts with packet 8 and ends with packet. At this time, because the right edge of the block is greater than the stored value in S 1, the sender retransmits packet 7 again at about 1.3 second. After the retransmission, the sender halves cwnd again to be 2(= 4/2 ). Therefore, even if two more duplicate ACKs by packet 16 and 17 decreases pipe to be 2, no packets are allowed to be transmitted. At about 1. second, the second retransmission delivers an ACK that acknowledges all packets up to packet 17, which brings the sender out of fast recovery and congestion avoidance starts with cwnd of 2. We repeated the same simulation for two packet losses, and the results are shown in Fig.. In this scenario, two packets, packet 7 and packet 12, are lost and the retransmitted packet 12 is lost again. After fast retransmit of packet 7, the fifth duplicate ACK decreases pipe to 3 so that the sender is allowed to transmit one packet. The final duplicate ACK decreases pipe again and packet is allowed to be transmitted. After RTT, one partial ACK and one duplicate ACK for packet 12 are received, which decrease pipe by three, 2 and three new packets, packet 16, 17, and 18, are transmitted. Because the retransmitted packet 12 has been lost, the sender cannot exit fast recovery but RTO occurs eventually at about 2.3 second. For TCP SACK+ shown in Fig. -(b), the sender sets S 1 = S 2 = 14 when it retransmits packet 7 and 12. After RTT, the sender receives a partial ACK that acknowledges packet 12, which means that the retransmitted packet 7 is delivered successfully. Therefore, S 1 may be cleared. When the seventh duplicate ACK by packet is received, its SACK information indicates that the first block starts with packet 13 and ends with packet, which is greater than S 2. Therefore, the sender transmits the second retransmission of packet 12 (instead of packet 18) at about 1.3 second. An ACK that acknowledges all packets up to packet 17 brings the sender out of fast recovery and congestion avoidance starts with cwnd of 2. IV. CONCLUSION In this paper, we have shown the detailed behavior of the LRD algorithm that enables TCP to detect and recover lost retransmission. Although LRD benefits only for a limited situation, it contributes to make TCP more robust with simple modifications in that LRD enables TCP implementations to avoid unnecessary RTO due to retransmitted packet loss. In addition, we have discussed that the LRD algorithm should be designed not to harm AIMD principle and fairness with other TCP implementations that do not use LRD by keeping conservation of packets rule. A number avenues for future work remain. First, according to queue management schemes such as droptail or random early detection (RED) [17] and with changing levels of congestion, the likelihood of a retransmitted packet loss may have some variation. Therefore, we need to conduct an experiment over practical networks to investigate whether LRD is really useful or not. Second, over a network where out-of-order delivery is prevalent, TCP performance may rather be degraded due to several unnecessary retransmissions. It may be relieved by increasing the number of duplicate ACKs that are necessary to decide a retransmission loss in the same way that three duplicate ACKs have to be received to trigger a fast retransmit. Third, our proposed algorithm can be enhanced to recover all retransmitted packet losses. If there is no new packet transmitted after a retransmitted packet, LRD cannot be triggered. If LRD is modified to always transmit a new packet after a retransmitted packet in the similar way that Limited Transmit transmits a new packet every time a duplicate ACK is received, all lost retransmission can be detected. REFERENCES [1] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM 88, pp. 314 329, 1988. 2 Note that a partial acknowledgement decreases pipe by two [6], [12]. -783-878-6//$. (C) IEEE

[2] M. Allman, W. Paxon, and W. Stevens, TCP Congestion Control, RFC 81, 1. [3] Janey C. Hoe, Improving the Start-up Behavior of a Congestion Control Scheme for TCP, ACM SIGCOMM 96, 1996. [4] S. Floyd and T. Henderson, The NewReno Modification to TCP s Fast Recovery Algorithm, RFC 82, 1999. [] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, TCP Selective Acknowledgement Options, RFC 18, 1997. [6] E. Blanton, M. Allman, K. Fall, and L. Wang, A Conservative Selective Acknowledgement (SACK) -based Loss Recovery Algorithm for TCP, RFC 17, 3. [7] H. Balakrishnan, Venkata Padmanabhan, Srinivasan Seshan, Mark Stemm, and Randy Katz, TCP Behavior of a Busy Web Server: Analysis and Improvements, IEEE INFOCOM 98, 1998. [8] M. Allman, H. Balakrishnan, and S. Floyd, Enhancing TCP s Loss Recovery Using Limited Transmit, RFC 42, 1. [9] B. Kim and J. Lee, Retransmission Loss Recovery by Duplicate Acknowledgement Counting, IEEE Comm. Letters, vol. 8, no. 1, pp. 69 71, Jan. 4. [] B. Kim, D. Kim, and J. Lee, Lost Retransmission Detection for TCP SACK, IEEE Comm. Letters, vol. 8, no. 9, pp. 6 62, Sep. 4. [11] D. Lin and H. T. Kung, TCP Fast Recovery Strategies: Analysis and Improvements, IEEE INFOCOM 98, pp. 263 271, 1998. [12] K. Fall and S. Floyd, Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, ACM Com. Comm. Rev., vol. 26, no. 3, pp. 21, 1996. [13] R. Braden, Requirements for Internet Hosts, RFC 1122, 1989. [14] A. Kumar, Comparative Performance Analysis of Versions of TCP in a Local Network with a Lossy Link, IEEE/ACM Trans. Networking, vol. 6, no. 4, pp. 48 498, 1998. [] J. Padhye, V. Firoiu, D. F. Towsley, and J. F. Kurose, Modeling TCP Reno Performance: A Simple Model and Its Empirical Validation, IEEE/ACM Trans. Networking, vol. 8, no. 2, pp. 133 14,. [16] B. Kim and J. Lee A Simple Model for TCP Loss Recovery Performance over Wireless Networks, Journal of Comm. and Net. (JCN), vol. 6, no. 3, pp. 2 244, Sep. 4. [17] S. Floyd and V. Jacobson, Random Early Detection Gateways for Congestion Avoidance, IEEE/ACM Trans. Networking, vol. 1, no. 4, pp. 397 413, Aug. 1993. -783-878-6//$. (C) IEEE