TCP-Peach and FACK/SACK Options: Putting The Pieces Together

Transcription

1 TCP-Peach and FACK/SACK Options: Putting The Pieces Together Giacomo Morabito, Renato Narcisi, Sergio Palazzo, Antonio Pantò Dipartimento di Ingegneria Informatica e delle Telecomunicazioni University of Catania V.le A. Doria 6, Catania (ITALY) {giacomo.morabito, renato.narcisi, sergio.palazzo, antonio.panto }@diit.unict.it Abstract-TCP-Peach has recently been proposed for IP network scenarios characterized by long round trip times and high bit error rates, such as satellite networks. In the TCP- Peach congestion control scheme, Slow Start and Fast Recovery are replaced with new algorithms called Sudden Start and Rapid Recovery. In this paper protocol refinements for TCP-Peach are proposed to allow it to be utilized in cooperation with FACK/SACK options. The modified protocol has been implemented in the Linux kernel and its performance has been evaluated in an emulated satellite network environment. Performance results show that the modified TCP-Peach protocol outperforms other TCP implementations. I. INTRODUCTION It is well known that TCP has performance problems when links characterized by long propagation delays and high bit error rates, such as satellite links, are involved in an end-to-end connection [11], [2]. TCP-Peach, introduced in [1], solves the above performance problems, guaranteeing at the same time TCP-friendly behavior without violating the end-to-end semantic of transport protocols. TCP-Peach replaces the Slow Start and Fast Recovery algorithms defined in [5], [6] with Sudden Start and Rapid Recovery [1]. The two new algorithms use low-priority segments, called dummy segments, in order to probe the availability of resources in the connection path. The algorithms introduced in [1] can be used in conjunction with the SACK option but, in order to obtain the best performance working along with FACK/SACK options [8], [9], which are considered in most current TCP implementations, some further modifications are still required. In this paper we introduce the relevant modifications and assess the performance of the resulting protocol, which has been implemented in the Linux kernel [7]. We have tested the performance of the modified TCP-Peach on a physical testbed where the satellite was emulated by a Linux PC running NIST Net []. We have compared the This work was partially supported by Agenzia Spaziale Italiana (ASI) under contract ACE-ASI I/R/1797/1. performance obtained by the new protocol with that obtained using the unmodified TCP with the FACK/SACK options, as the latter has been shown to achieve the best performance among traditional TCP versions in satellite networks [4]. The experimental results show that TCP-Peach with the new modifications outperforms the traditional TCP with FACK/SACK options. In fact, TCP-Peach throughput is always higher than traditional TCP FACK/SACK throughput. The rest of the paper is organized as follows. In Section II we give the TCP-Peach protocol details which are required to understand of the paper. We will show the basic features of the FACK [9] and SACK [8] options in Section III, whereas in Section IV we will discuss the behavior of TCP-Peach in conjunction with FACK/SACK and the modifications introduced to improve it. The performance evaluation results are given in Section V. Finally, in Section VI we conclude the paper. II. TCP-PEACH TCP-Peach uses two new algorithms, namely Sudden Start and Rapid Recovery, which replace Slow Start and Fast Recovery, respectively. Some modifications are introduced in Congestion Avoidance in order to handle the arrivals of ACKs for dummy segments. The new algorithms are based on the use of dummy segments which are low-priority segments generated by the sender as copies of the last data segment transmitted. The objective of dummy segments is to probe network resource availability in the end-to-end connection. If there is congestion along the end-toend connection, dummy segments are discarded as they are carried by low-priority IP packets. If there is no congestion, dummy segments reach the receiver, which will acknowledge receipt to the sender. The sender interprets the ACKs for dummy segments as evidence that there are unused resources in the network and accordingly can increase its congestion window,. More specifically, to obtain TCP-friendly behavior by differentiating the protocol actions when ACKs for dummy segments are received, the variable wdsn is defined. It is used in such a way that TCP-Peach behaves like TCP-Reno when the network is congested. At the beginning of a new connection wdsn is set to zero and then is dynamically updated in the Rapid Recovery phase as specified below. Upon receiving an ACK for a dummy segment the value of wdsn determines the behavior of

2 the congestion window, : If wdsn=, then the congestion window is increased by one. If wdsn>, then the variable wdsn is decreased by one, whereas is left unchanged. A. Sudden Start TCP Peach enters the Sudden Start phase at the beginning of a connection and whenever a timeout expires. The Sudden Start algorithm lasts for one round trip time, RTT, then the sender enters the Congestion Avoidance phase. During the Sudden Start algorithm, the sender transmits one data packet and ( rwnd 1) dummy packets, where rwnd is the maximum value allowed for the congestion window size given by the receiver. The dummy packets reach the receiver and ACKs are thus early returned to the sender if there are unused resources in the network. The sender will receive these ACKs when the Sudden Start Algorithm is over and Congestion Avoidance is running. In this phase, the sender will increase its congestion window,, by one packet each time it receives an ACK for a dummy packet. In Fig. 1 we show the behavior of the congestion window,, for a TCP connection using the Sudden Start Algorithm. Fig. 1 was obtained using RTT =.26 sec and rwnd = 64 packets. e that reaches rwnd within two round trip times. (segments) TCP-Reno TCP-Peach t(rtt) Fig. 1. TCP-Peach and TCP-Reno behavior at the beginning of a new connection. B. Rapid Recovery Rapid Recovery replaces Fast Recovery in TCP-Peach. Upon receiving three duplicate ACKs, TCP-Peach executes the Fast Retransmit algorithm as proposed in [6] and then enters the Rapid Recovery phase which begins by halving the congestion window ; in fact, Rapid Recovery makes the initial conservative assumption that all segment losses are due to congestion. As a consequence, if we denote as the value of the congestion window when the Fast Retransmit algorithm was triggered, we have = /2 The Rapid Recovery continues as follows: the sender first sets the variable wdsn to /2, i.e., wdsn = /2 and then generates dummy segments in order to probe the availability of network resources in the end-to-end path. If the network is not congested and all the dummy segments arrive at their destination and the related ACKs are received by the sender, the arrivals of the first /2 ACKs for dummy segments cause the variable wdsn to decrease to zero. the arrivals of the other /2 ACKs for dummy segments cause the value of the congestion window,, to increase to. As a consequence, within a short period of time reaches the value it had before loss of the data segment was detected. We show the pseudocode of Rapid Recovery as given in [1] in Fig. 2 and the behavior of the congestion window,, after the detection of a segment loss due to link errors in Fig. 3. With the aim of comparison, in Fig. 4 we also show the behavior of the TCP-Reno congestion window in the same conditions. For further details about Rapid Recovery we refer the reader to [1] and [3]. Rapid_recovery() = /2; adsn = 2*adsn; wdsn=; infl_seg = ; t Retr = t; END = ; while (END = ) if (ACK_ARRIVAL) if (DATA_ACK_ARRIVAL) = + 1; infl_seg = infl_seg + 1; else if (DUMMY_ACK_ARRIVAL) if (wdsn = ) = + 1; infl_seg = infl_seg + 1; else wdsn = wdsn 1; if ( > nackseg) while ( > nackseg) send (Data_Segment); nackseg = nackseg + 1; else if (adsn > ) send (Dummy_Segment); send (Dummy_Segment); adsn = adsn 2; if (LOST_SEGMENT_ACKED) END = 1; = infl_seg; if (t > t Retr + RTO) Slow_Start(); end. Fig. 2. Rapid Recovery

3 (segments) TCP-Reno TCP-Peach Time(sec) Fig 3. Comparison Between the Congestion Window of TCP-Reno and TCP-Peach after Detection of a Segment Loss due to Link Errors. been transmitted. The transmission window is the sequence of bytes from the first byte which has not been acknowledged to high_seq. More than one packet loss can occur within a transmission window; if this is the case, the selective ACKs received during Rapid Recovery do not acknowledge all the bytes in sequential order. As a consequence, holes of unacknowledged data are created in the transmission window, as shown in Fig. 4. During this phase all unacknowledged segments with a sequential number lower than the last SACKed segment are immediately retransmitted by the function tcp_fack_retransmit. Transmission window The Rapid Recovery phase is terminated when the ACK of the retransmitted data segment is received. Accordingly, in TCP-Peach the duration of Rapid Recovery is approximately equal to the round trip time, RTT. Moreover, if we assume an uniform arrival time distribution for ACKs, dummy segments are transmitted in the first half of the round trip time. In Section IV we will show that the timing is different when the FACK/SACK option [8], [9] is implemented. III. SACK AND FACK With the cumulative acknowledgment scheme used by TCP, the sender can only learn about a single lost packet per round trip time. This is a great limitation in the case of multiple losses in a window of data, its consequence being poor performance. Through the Selective Acknowledgment (SACK) mechanism the data receiver informs the sender about all the segments that have arrived successfully, so the sender only needs to retransmit only segments that have actually been lost. The Forward Acknowledgment (FACK) algorithm is designed to be used with the SACK option. FACK uses the additional information provided by SACK to keep an explicit count of the total number of bytes of data outstanding in the network. The FACK option provides an improvement in performance in the case of multiple losses in a single window of data and reduces the overall burstiness of TCP. IV. TCP-PEACH AND SACK/FACK OPTIONS A straightforward implementation of both SACK and FACK options would have detrimental effects on TCP- Peach performance. This is due to the mutual impairment between Rapid Recovery and the FACK/SACK options, as will be explained in this section. When Rapid Recovery is executed the value of the congestion window,, is halved and inflated by three in order to take the arrivals of the duplicated ACKs into account, and the variable denoted high_seq is set equal to the sequential number of the first byte which has not yet segments Out of window S- (a) t (RTT) tcp_fack_retransmit nackseg S- Fig. 4. SACK and FACK S- Out of window Rapid Recovery is terminated when an ACK arrives which acknowledges a byte with a sequential number higher than high_seq. The sender then enters in Congestion Avoidance phase. This behavior is different from that expected in the original TCP-Peach, which considers the Rapid Recovery phase as completed when an ACK for the retransmitted packet is received t (RTT) Fig. 5. The and nackseg behavior of TCP Peach without (a) and with the FACK/SACK option In more detail, if the FACK/SACK option is implemented in TCP-Peach in its original form [1], there are two major problems: Arrivals of SACKs trigger a decrease in the number of unacknowledged segments, nackseg, and a simultaneous inflation of. Accordingly, the time period while <nackseg and, therefore, dummy segments are transmitted is much shorter than RTT/2, which would be the duration expected in the original TCP-Peach. More precisely, in the case of a single loss, if all the SACKs arrive uniformly the duration of the above time interval is approximately RTT/4, as shown in Fig. 5. As a result, the number of dummy segments transmitted during Rapid Recovery is too low and does not segments nackseg

4 allow the return of to the value it had before the segment loss was detected. In the case of multiple losses, the duration of Rapid Recovery is much longer than RTT, which is the value expected in the original TCP-Peach. Therefore, most of the ACKs for dummy segments arrive during Rapid Recovery and not during Congestion Avoidance, as assumed by TCP-Peach logic [1]. This causes problems because at the end of Rapid Recovery arrivals of ACKs for dummy segments received during this phase do not increment the value. We therefore modified the original TCP-Peach as follows. The variables wdsn and adsn are initially set to half of the value fixed in [1]: wdns = /4 adsn = /2 Moreover, a new variable called num_dummy, which keeps track of the number of dummy segments transmitted by the sender, is defined. This variable is used in such a way that in the Congestion Avoidance phase the value of the congestion window,, is set to if all the dummy segments transmitted during the Rapid Recovery are ACKed. Also, in the Rapid Recovery algorithm another new variable, called dummy_line, is defined in order to distinguish ACKs for dummy segments transmitted during the current Rapid Recovery phase from those transmitted during previous phases of Rapid Recovery or Sudden Start. At the beginning of each Rapid Recovery phase the value of dummy_line is set to the current time plus the estimated round trip time, RTT. The acknowledgements for dummy segments received before dummy_line are considered to relate to dummy segments transmitted during the previous Rapid Recovery or Sudden Start phases and are treated accordingly as in [1], i.e., as shown in Fig. 2. Instead, the ACKs for dummy segments received during a Rapid Recovery phase after dummy_line are related to dummy segments transmitted during the current phase and are treated as they would be treated during the Congestion Avoidance phase as modified in [1]. As a consequence, ACKs for dummy segments are interpreted correctly, regardless of whether they are received during the Congestion Avoidance or Rapid Recovery phase. In Fig. 6 we show the congestion window,, behavior after a segment loss due to link errors has been detected. Fig. 6 was obtained considering a round trip time of approximately 55 ms Fig. 6. behavior after a segment loss due to link errors V. PERFORMANCE EVALUATION We implemented TCP-Peach, with the modifications given in the previous section, on the TCP/IP stack of the Linux kernel. The software can be downloaded from: The protocol throughput performance was evaluated on the testbed shown in Fig. 7. FTP Sender S Time (sec) GNU/Linux with NIST Net Satellite Network Emulator Fig. 7. The testbed FTP Receiver R The sender S transfers files of a size s [bytes] to the receiver R in a connection path passing through a GEO satellite. The GEO satellite was emulated by a Linux PC running the NIST Net node []. The delay introduced by NIST Net was set to 275 ms, which results in a round trip time higher than 55 ms; the capacity was set to 3 Kbytes/sec and we used different packet loss probability values ranging from to.5. We ran experiments with many values of s; however, for reason of space, in this paper we only show the results obtained when s is equal to 25 Kbytes and 2 Mbytes. In Fig. 8 (a) and we show the average throughput and file delivery time, i.e., the time required to complete the file transfer, which depends on the segment loss probability introduced by the NIST Net node when s is equal to 2

5 Mbytes. In each figure two curves are drawn: one gives the values obtained by TCP-Peach with the FACK/SACK option, the other gives the values obtained using the unmodified Linux TCP/IP protocol stack, which uses the FACK/SACK option by default. In both Fig. 8 (a) and our modifications can be seen to provide much better performance. In Fig. 9 (a) and we show an analogous situation when small files, i.e., s is equal to 25 KB, are transferred. Here again, TCP-Peach achieves much better performance. throughput (bytes/sec) (a) Packet Error Rate (xe-2) Packet Error Rate (xe-2) Packet Error Rate (xe-2) Fig. 9 Average throughput (a) and delivery time (s = 25 Kbytes) ACKNOWLEDGMENTS The authors would like to thank Fabio Angelino for his help in obtaining the performance results Packet Error Rate (xe-2) Fig. 8. Average throughput (a) and delivery time (s = 2 Mbytes) VI. CONCLUSIONS TCP-Peach is a novel TCP protocol introduced in [1] to increase throughput in satellite IP networks. In this paper we have introduced some modifications to TCP-Peach required for it to be used together with FACK/SACK options [8], [9]. The resulting protocol was implemented in the Linux kernel and extensively tested. We ran several experiments on a physical testbed emulating the case where a GEO satellite is involved in the end-to-end communication. The GEO satellite was emulated by a node introducing an appropriate delay and packet loss probability. To this end a Linux PC running NistNET [] was used. Performance results have shown that the throughput of modified TCP-Peach is always higher than that of traditional TCP implementations. the delivery time of modified TCP-Peach is always shorter than that of traditional TCP implementations. REFERENCES [1] I.F. Akyldiz, G. Morabito, and S. Palazzo, TCP-Peach: a new Congestion Control scheme for satellite networks, IEEE/ACM Transaction on Networking, Vol. 9, No. 3, pp , June 21. [2] I.F. Akyildiz, G. Morabito, and S. Palazzo, Research issues for Transport protocols in satellite IP networks, IEEE Personal Communications, Vol. 8, No. 3, pp , June 21. [3] I. F. Akyildiz, G. Morabito, S. Palazzo, TCP-Peach for satellite networks: analytical model and performance evaluation, International Journal of Satellite Communications. Vol. 19, No. 5, September 21. [4] T. R. Henderson and R. H. Katz, Transport protocols for Internet- Compatible satellite networks, IEEE JSAC, Vol. 17, No. 2, pp , February [5] V. Jacobson. Congestion Avoidance and Control. In Proc. Of ACM Sigcomm 88, August [6] V. Jacobson. Congestion Avoidance and Control. Technical Report, April 199. [7] ftp://ftp.kernel.org/pub/linux/kernel/v2.2/linux tar.gz [8] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, TCP Selective Acknowledgement Options. IETF RFC 218, April [9] M. Mathis and J. Mahdavi, Forward Acknowledgement: refining TCP Congestion Control, In Proc. of ACM Sigcomm 96, August [] [11] C. Partridge and T.J. Shepard, TCP/IP performance over satellite links, IEEE Network Magazine. Vol. 11, No. 5, pp , September/October 1997.