Giacomo Morabito, Renato Narcisi, Sergio Palazzo, Antonio Pantò. Dipartimento di Ingegneria Informatica e delle Telecomunicazioni. University of Catania.
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, 95125 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 TCPPeach 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 2.2.17 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 2.2.17 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 [10]. We have compared the This work was partially supported by Agenzia Spaziale Italiana (ASI) under contract ACE-ASI I/R/1797/01.
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, cwnd. 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
the congestion window, cwnd: • If wdsn=0, then the congestion window is increased by one. • If wdsn>0, then the variable wdsn is decreased by one, whereas cwnd 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, cwnd, by one packet each time it receives an ACK for a dummy packet. In Fig. 1 we show the behavior of the congestion window, cwnd, for a TCP connection using the Sudden Start Algorithm. Fig. 1 was obtained using RTT = 0.26 sec and rwnd = 64 packets. Note that cwnd reaches rwnd within two round trip times. 80 TCP-Reno TCP-Peach
70
cwnd (segments)
60 50 40 30 20 10 0
1
2
3
4
5
6
7
8
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 cwnd; in fact, Rapid Recovery makes the initial conservative assumption that all segment losses are due to congestion. As a consequence, if we denote as cwnd0 the value of the congestion window when the Fast Retransmit algorithm was triggered, we have
cwnd = cwnd0/2 The Rapid Recovery continues as follows: the sender first sets the variable wdsn to cwnd0/2, i.e., wdsn = cwnd0/2 and then generates cwnd0 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 cwnd0/2 ACKs for dummy segments cause the variable wdsn to decrease to zero. • the arrivals of the other cwnd0/2 ACKs for dummy segments cause the value of the congestion window, cwnd, to increase to cwnd0. As a consequence, within a short period of time cwnd 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, cwnd, 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() cwnd = cwnd/2; adsn = 2*adsn; wdsn=cwnd; infl_seg = 0; tRetr = t; END = 0; while (END = 0) if (ACK_ARRIVAL) if (DATA_ACK_ARRIVAL) cwnd = cwnd + 1; infl_seg = infl_seg + 1; else if (DUMMY_ACK_ARRIVAL) if (wdsn = 0) cwnd = cwnd + 1; infl_seg = infl_seg + 1; else wdsn = wdsn –1; end; end; if (cwnd > nackseg) while (cwnd > nackseg) send (Data_Segment); nackseg = nackseg + 1; end; else if (adsn > 0) send (Dummy_Segment); send (Dummy_Segment); adsn = adsn – 2; end; if (LOST_SEGMENT_ACKED) END = 1; cwnd = cwnd – infl_seg; end; end; if (t > tRetr + RTO) Slow_Start(); end; end; end.
Fig. 2. Rapid Recovery
60 TCP-Reno TCP-Peach 50
cwnd (segments)
40
30
20
10
0
0
0.5
1
1.5
2
2.5
Time(sec)
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.
Fig 3. Comparison Between the Congestion Window of TCP-Reno and TCP-Peach after Detection of a Segment Loss due to Link Errors.
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 TCPPeach 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, cwnd, 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
Out of window
Not acked
S-acked
Not acked
S-acked
Not acked
Not acked
Not acked
S-acked
Out of window
Fig. 4. SACK and FACK
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. (a)
60
(b)
60
cwnd nackseg
cwnd nackseg 50
50
40
40
segments
III. SACK AND FACK
tcp_fack_retransmit
segments
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.
Transmission window
30
30
20
20
10
10
0
0
0.5
1
1.5
t (RTT)
2
2.5
0 0
0.5
1
1.5
2
2.5
t (RTT)
Fig. 5. The cwnd and nackseg behavior of TCP Peach without (a) and with (b) 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 cwnd. Accordingly, the time period while cwnd
