--- 1/draft-ietf-tsvwg-tcp-frto-00.txt 2006-02-05 02:05:51.000000000 +0100 +++ 2/draft-ietf-tsvwg-tcp-frto-01.txt 2006-02-05 02:05:51.000000000 +0100 @@ -1,17 +1,17 @@ Internet Engineering Task Force P. Sarolahti INTERNET DRAFT Nokia Research Center -File: draft-ietf-tsvwg-tcp-frto-00.txt M. Kojo +File: draft-ietf-tsvwg-tcp-frto-01.txt M. Kojo University of Helsinki - October, 2003 - Expires: April, 2004 + February, 2004 + Expires: August, 2004 F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering @@ -39,89 +39,101 @@ a TCP sender only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by an RTO, the F-RTO algorithm at a TCP sender monitors the incoming acknowledgements to determine whether the timeout was spurious and to decide whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in case of a spurious timeout. The F-RTO algorithm can also be applied with the SCTP protocol. +Terminology + + The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, + SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this + document, are to be interpreted as described in [RFC2119]. + 1. Introduction The TCP protocol [Pos81] has two methods for triggering retransmissions. Primarily, the TCP sender relies on incoming duplicate ACKs, which indicate that the receiver is missing some of - the data. After a required amount of successive duplicate ACKs have + the data. After a required number of successive duplicate ACKs have arrived at the sender, it retransmits the first unacknowledged segment [APS99]. Secondarily, the TCP sender maintains a retransmission timer which triggers retransmission of segments, if they have not been acknowledged within the retransmission timer expiration period. When the retransmission timer expires, the TCP sender enters the RTO recovery where congestion window is initialized to one segment and unacknowledged segments are retransmitted using the slow-start algorithm. The retransmission timer is adjusted dynamically based on the measured round-trip times [PA00]. It has been pointed out that the retransmission timer can expire spuriously and trigger unnecessary retransmissions when no segments - have been lost [GL02]. After a spurious RTO the late acknowledgements - of original segments arrive at the sender, usually triggering - unnecessary retransmissions of whole window of segments during the - RTO recovery. Furthermore, after a spurious RTO a conventional TCP - sender increases the congestion window on each late acknowledgement - in slow start, injecting a large number of data segments to the - network within one round-trip time. + have been lost [LK00, GL02, LM03]. After a spurious retransmission + timeout the late acknowledgements of original segments arrive at the + sender, usually triggering unnecessary retransmissions of whole + window of segments during the RTO recovery. Furthermore, after a + spurious retransmission timeout a conventional TCP sender increases + the congestion window on each late acknowledgement in slow start, + injecting a large number of data segments to the network within one + round-trip time. - There are a number of potential reasons for spurious RTOs. First, - some mobile networking technologies involve sudden delay peaks on - transmission because of actions taken during a hand-off. Second, - arrival of competing traffic, possibly with higher priority, on a - low-bandwidth link or some other change in available bandwidth - involves a sudden increase of round-trip time which may trigger a - spurious retransmission timeout. A persistently reliable link layer - can also cause a sudden delay when several data frames are lost for - some reason. This document does not distinguish the different causes - of such a delay, but discusses the spurious RTOs caused by a delay in - general. + There are a number of potential reasons for spurious retransmission + timeouts. First, some mobile networking technologies involve sudden + delay peaks on transmission because of actions taken during a hand- + off. Second, arrival of competing traffic, possibly with higher + priority, on a low-bandwidth link or some other change in available + bandwidth involves a sudden increase of round-trip time which may + trigger a spurious retransmission timeout. A persistently reliable + link layer can also cause a sudden delay when several data frames are + lost for some reason. This document does not distinguish the + different causes of such a delay, but discusses the spurious + retransmission timeouts caused by a delay in general. This document describes an alternative RTO recovery algorithm called "Forward RTO-Recovery" (F-RTO) to be used for detecting spurious RTOs and thus avoiding unnecessary retransmissions following the RTO. When the RTO is not spurious, the F-RTO algorithm reverts back to the conventional RTO recovery algorithm and should have similar behavior and performance. F-RTO does not require any TCP options in its operation, and it can be implemented by modifying only the TCP sender. This is different from alternative algorithms (Eifel [LK00], [LM03] and DSACK-based algorithms [BA02]) that have been suggested for detecting unnecessary retransmissions. The Eifel algorithm uses - TCP timestamps [BBJ92] for detecting a spurious timeout and the - DSACK-based algorithms require that the TCP Selective Acknowledgment - Option [MMFR96] with DSACK extension [FMMP00] is in use. With DSACK, - the TCP receiver can report if it has received a duplicate segment, - making it possible for the sender to detect afterwards whether it has - retransmitted segments unnecessarily. + TCP timestamps [BBJ92] for detecting a spurious timeout upon arrival + of the first acknowledgement after the retransmission. The DSACK- + based algorithms require that the TCP Selective Acknowledgment Option + [MMFR96] with DSACK extension [FMMP00] is in use. With DSACK, the TCP + receiver can report if it has received a duplicate segment, making it + possible for the sender to detect afterwards whether it has + retransmitted segments unnecessarily. In addition, the F-RTO + algorithm only attempts to detect and avoid unnecessary + retransmissions after an RTO. Eifel and DSACK can also be used in + detecting unnecessary retransmissions in other events, for example + due to packet reordering. When an RTO occurs, the F-RTO sender retransmits the first - unacknowledged segment normally, but tries to transmit new, - previously unsent data after that. If the next two acknowledgements - cover segments that were not retransmitted, the F-RTO sender can - declare the RTO spurious and exit the RTO recovery. However, if - either of the next two acknowledgements is a duplicate ACK, there was - no sufficient evidence of spurious RTO; therefore the F-RTO sender - retransmits the unacknowledged segments in slow start similarly to - the traditional algorithm. With a SACK-enhanced version of the F-RTO - algorithm, spurious RTOs may be detected even if duplicate ACKs - arrive after an RTO. The F-RTO algorithm only attempts to detect and - avoid unnecessary retransmissions after an RTO. Eifel and DSACK can - also be used in detecting unnecessary retransmissions in other - events, for example due to packet reordering. + unacknowledged segment as usual. Deviating from the normal operation + after a timeout, it then tries to transmit new, previously unsent + data, for the first acknowledgement that arrives after the timeout + given that the acknowledgement advances the window. If the second + acknowledgement that arrives after the timeout also advances the + window, i.e., acknowledges data that was not retransmitted, the F-RTO + sender declares the RTO spurious and exit the RTO recovery. However, + if either of the next two acknowledgements is a duplicate ACK, there + was no sufficient evidence of spurious RTO; therefore the F-RTO + sender retransmits the unacknowledged segments in slow start + similarly to the traditional algorithm. With a SACK-enhanced version + of the F-RTO algorithm, spurious RTOs may be detected even if + duplicate ACKs arrive after an RTO. The F-RTO algorithm can also be applied with the SCTP protocol [Ste00], because SCTP has similar acknowledgement and packet retransmission concepts as TCP. When a SCTP retransmission timeout occurs, the SCTP sender is required to retransmit the outstanding data similarly to TCP, thus being prone to unnecessary retransmissions and congestion control adjustments, if delay spikes occur in the network. The SACK-enhanced version of F-RTO should be directly applicable to SCTP, which has selective acknowledgements as a built-in feature. For simplicity, this document mostly refers to @@ -165,47 +177,50 @@ the highest sequence number transmitted so far in variable "send_high". 2) When the first acknowledgement after the RTO arrives at the sender, the sender chooses the following actions depending on whether the ACK advances the window or whether it is a duplicate ACK. a) If the acknowledgement is a duplicate ACK OR it is acknowledging a sequence number equal to (or above) the value - of send_high, the TCP sender MUST revert to the conventional - RTO recovery, and continue by retransmitting unacknowledged - data in slow start. The TCP sender MUST NOT enter step 3 of - this algorithm, and the SpuriousRecovery variable remains as - FALSE. + of send_high OR it does not acknowledge all of the data that + was retransmitted in step 1, the TCP sender MUST revert to the + conventional RTO recovery and continue by retransmitting + unacknowledged data in slow start. The TCP sender MUST NOT + enter step 3 of this algorithm, and the SpuriousRecovery + variable remains as FALSE. b) If the acknowledgement advances the window AND it is below the value of send_high, the TCP sender SHOULD transmit up to two new (previously unsent) segments and enter step 3 of this algorithm. If the TCP sender does not have enough unsent data, it SHOULD send only one segment. In addition, the TCP sender MAY override the Nagle algorithm and send immediately an undersized segment if needed. If the TCP sender does not have any new data to send, the TCP sender SHOULD transmit a segment from the retransmission queue. If TCP sender retransmits the first unacknowledged segment, it MUST NOT enter step 3 of this algorithm but continue with the conventional RTO recovery - algorithm. + algorithm. In this case acknowledgement of the next segment + would not unambiguously indicate that the original transmission + arrived at the receiver. 3) When the second acknowledgement after the RTO arrives at the sender, either declare the RTO spurious, or start retransmitting the unacknowledged segments. a) If the acknowledgement is a duplicate ACK, the TCP sender MUST set congestion window to no more than 3 * MSS, and continue with the slow start algorithm retransmitting unacknowledged - segments. The sender leaves SpuriousRecovery to FALSE. + segments. The sender leaves SpuriousRecovery set to FALSE. b) If the acknowledgement advances the window, i.e. it acknowledges data that was not retransmitted after the RTO, the TCP sender SHOULD declare the RTO spurious, set SpuriousRecovery to SPUR_TO and set the value of send_high variable to SND.UNA. The F-RTO sender takes cautious actions when it receives duplicate acknowledgements after an RTO. Since duplicate ACKs may indicate that segments have been lost, reliably detecting a spurious RTO is @@ -209,53 +224,56 @@ The F-RTO sender takes cautious actions when it receives duplicate acknowledgements after an RTO. Since duplicate ACKs may indicate that segments have been lost, reliably detecting a spurious RTO is difficult in the lack of additional information. Therefore the safest alternative is to follow the conventional TCP recovery in those cases. If the first acknowledgement after RTO covers the send_high point at algorithm step (2a), there is not enough evidence that a non- retransmitted segment has arrived at the receiver after the RTO. + This is a common case when a fast retransmission is lost and it has been retransmitted again after an RTO, while the rest of the unacknowledged segments have successfully been delivered to the TCP receiver before the RTO. Therefore the RTO cannot be declared spurious in this case. If the first acknowledgement after RTO does not acknowledge all of - the data that was retransmitted in step 1, the TCP sender must not - enter step 3 of this algorithm, but revert to the conventional RTO - recovery. Otherwise, a malicious receiver acknowledging partial - segments could cause the sender to declare the RTO spurious in a case - where data was lost. + the data that was retransmitted in step 1, the TCP sender reverts to + the conventional RTO recovery. Otherwise, a malicious receiver + acknowledging partial segments could cause the sender to declare the + RTO spurious in a case where data was lost. The TCP sender is allowed to send two new segments in algorithm - branch (2b), because the conventional TCP sender would retransmit two - segments after one round-trip has elapsed since the RTO. If sending - new data is not possible in algorithm branch (2b), or the receiver - window limits the transmission, it has to send something in order to - prevent the TCP transfer from stalling. In that case the following - options are available for the sender. + branch (2b), because the conventional TCP sender would transmit two + segments when the first new ACK arrives after the RTO. If sending new + data is not possible in algorithm branch (2b), or the receiver window + limits the transmission, the TCP sender has to send something in + order to prevent the TCP transfer from stalling. If no segments were + sent, the pipe between sender and receiver may run out of segments, + and no further acknowledgements arrive. If transmitting previously + unsent data is not possible, the following options are available for + the sender. - Continue with the conventional RTO recovery algorithm and do not try to detect the spurious RTO. The disadvantage is that the sender may do unnecessary retransmissions due to possible spurious RTO. On the other hand, we believe that the benefits of detecting spurious RTO in an application limited or receiver limited situations are not very remarkable. - Use additional information if available, e.g. TCP timestamps with the Eifel Detection algorithm, for detecting a spurious RTO. However, Eifel detection may yield different results from F-RTO when ACK losses and a RTO occur within the same round-trip time - [SKR02]. + [SKR03]. - Retransmit data from the tail of the retransmission queue and continue with step 3 of the F-RTO algorithm. It is possible that the retransmission is unnecessarily made, hence this option is not encouraged, except for hosts that are known to operate in an environment that is highly likely to have spurious RTOs. On the other hand, with this method it is possible to avoid several unnecessary retransmissions due to spurious RTO by doing only one retransmission that may be unnecessary. @@ -265,21 +283,21 @@ from the incoming acknowledgement whether the RTO was spurious. While this method does not send data unnecessarily, it delays the recovery by one round-trip time in cases where the RTO was not spurious, and therefore is not encouraged. - In receiver-limited cases, send one octet of new data regardless of the advertised window limit, and continue with step 3 of the F-RTO algorithm. It is possible that the receiver has free buffer space to receive the data by the time the segment has propagated through the network, in which case no harm is done. If the receiver is not - capable of receiving the segment, it rejects the segment, and sends + capable of receiving the segment, it rejects the segment and sends a duplicate ACK. If the RTO is declared spurious, the TCP sender sets the value of send_high variable to SND.UNA in order to disable the NewReno "bugfix" [FH99]. The send_high variable was proposed for avoiding unnecessary multiple fast retransmits when RTO expires during fast recovery with NewReno TCP. As the sender has not retransmitted other segments but the one that triggered RTO, the problem addressed by the bugfix cannot occur. Therefore, if there are three duplicate ACKs arriving at the sender after the RTO, they are likely to indicate a @@ -297,24 +315,24 @@ Eifel detection algorithm has a similar property, while the DSACK option can be used to detect whether the retransmitted segment was successfully delivered to the receiver. The F-RTO algorithm has a side-effect on the TCP round-trip time measurement. Because the TCP sender can avoid most of the unnecessary retransmissions after detecting a spurious RTO, the sender is able to take round-trip time samples on the delayed segments. If the regular RTO recovery was used without TCP timestamps, this would not be possible due to retransmission ambiguity. As a result, the RTO - estimator is likely have more accurate and larger values with F-RTO - than with the regular TCP after a spurious RTO that was triggered due - to delayed segments. We believe this is an advantage in the networks - that are prone to delay spikes. + estimator is likely to be more accurate and have larger values with + F-RTO than with the regular TCP after a spurious RTO that was + triggered due to delayed segments. We believe this is an advantage in + the networks that are prone to delay spikes. It is possible that the F-RTO algorithm does not always avoid unnecessary retransmissions after a spurious RTO. If packet reordering or packet duplication occurs on the segment that triggered the spurious RTO, the F-RTO algorithm may not detect the spurious RTO due to incoming duplicate ACKs. Additionally, if a spurious RTO occurs during fast recovery, the F-RTO algorithm often cannot detect the spurious RTO. However, we consider these cases relatively rare, and note that in cases where F-RTO fails to detect the spurious RTO, it performs similarly to the regular RTO recovery. @@ -386,105 +403,81 @@ those segments SHOULD be retransmitted similarly to the conventional SACK recovery algorithm [BAFW03]. If the algorithm exits with SpuriousRecovery set to SPUR_TO, send_high SHOULD be set to SND.UNA, thus allowing fast recovery on incoming duplicate acknowledgements. 4. Taking Actions after Detecting Spurious RTO Upon retransmission timeout, a conventional TCP sender assumes that outstanding segments are lost and starts retransmitting the unacknowledged segments. When the RTO is detected to be spurious, the - TCP sender should not start retransmitting based on the RTO. For + TCP sender should not continue retransmitting based on the RTO. For example, if the sender was in congestion avoidance phase transmitting new previously unsent segments, it should continue transmitting previously unsent segments after detecting spurious RTO. In addition, it is suggested that the RTO estimation is reinitialized and the RTO timer is adjusted to a more conservative value in order to avoid subsequent spurious RTOs [LG03]. - Different approaches have been suggested for adjusting the congestion - control state after a spurious RTO. This document does not - specifically recommend any of the alternatives below, but considers - the response to spurious RTO as a subject of further research. - - 1) Revert the congestion control parameters to the state before the - RTO [LG03]. This appears to be a justified decision, because it is - similar to the situation in which the RTO did not expire - spuriously. However, two concerns exists with this approach: - First, some detection mechanisms, such as F-RTO or the Eifel - Detection algorithm, do not notice the loss of the spurious - retransmission, thus introducing a small risk of violation of the - congestion control principles. Second, a spurious RTO indicates - that some part of the network was unable to deliver packets for a - while, which can be considered as a potential indication of - congestion. - - 2) Reduce congestion window to half of its earlier value but revert - slow start threshold to its earlier value [SL03]. This - alternative takes measures to validate the congestion window after - a period during which no data has been transmitted. This would be - a justified action to take if the spurious RTO is assumed to be - caused due to changes in the network conditions, such as a change - in the available bandwidth or a wireless handoff to another point - of attachment in the network. + Different approaches have been discussed for adjusting the congestion + control state after a spurious RTO in various research papers [SKR03, + GL03, Sar03] and Internet-Drafts [SL03, LG03]. The different response + suggestions vary in whether the spurious retransmission timeout + should be taken as a congestion signal, thus causing the congestion + window or slow start threshold to be reduced at the sender, or + whether the congestion control state should be fully reverted to the + state valid prior to the retransmission timeout. - 3) Reduce ssthresh and congestion window when detecting a spurious - RTO [SKR02]. For example, ssthresh and cwnd could be set to half - of their earlier values, as done with the other congestion - notification events. This alternative would be conservative enough - considering the possibility of not detecting a packet loss of the - RTO-triggered retransmission, but the TCP sender should avoid - reducing the congestion window more than once in a round-trip - time. Furthermore, if a spurious RTO occurs in the beginning of a - TCP connection, this alternative causes the slow start to be - canceled, which may sacrifice TCP performance. + This document does not give recommendation on selecting the response + alternative, but considers the response to spurious RTO as a subject + of further research. 5. SCTP Considerations - The SACK-enhanced F-RTO algorithm can be applied with the SCTP proto- - col. However, SCTP contains features that are not present with TCP - that need to be discussed when applying the F-RTO algorithm. + The basic F-RTO or the SACK-enhanced F-RTO algorithm can be applied + with the SCTP protocol. However, SCTP contains features that are not + present with TCP that need to be discussed when applying the F-RTO + algorithm. SCTP association can be multi-homed. The current retransmission pol- icy states that retransmissions should go to alternative addresses. If the retransmission was due to spurious RTO caused by a delay spike, it is possible that the acknowledgement for the retransmission arrives back at the sender before the acknowledgements of the origi- nal transmissions arrive. If this happens, a possible loss of the original transmission of the data chunk that was retransmitted due to - RTO may remain undetected when applying the F-RTO algorithm and there - was a delay spike that triggered the RTO. Because the RTO was caused - by the delay, and it was spurious in that respect, a suitable - response is to continue by sending new data. However, if the original - transmission was lost, fully reverting the congestion control parame- - ters is too aggressive. Therefore, taking conservative actions on - congestion control is recommended, if the SCTP association is multi- - homed and retransmissions go to alternative address. The information - in duplicate TSNs can be then used for reverting congestion control, - if desired [BA02]. + the spurious RTO may remain undetected when applying the F-RTO algo- + rithm. Because the RTO was caused by the delay, and it was spurious + in that respect, a suitable response is to continue by sending new + data. However, if the original transmission was lost, fully reverting + the congestion control parameters is too aggressive. Therefore, tak- + ing conservative actions on congestion control is recommended, if the + SCTP association is multi-homed and retransmissions go to alternative + address. The information in duplicate TSNs can be then used for + reverting congestion control, if desired [BA02]. Note that the forward transmissions made in F-RTO algorithm step (2b) should be destined to the primary address, since they are not retransmissions. When making a retransmission, a SCTP sender can bundle a number of unacknowledged data chunks and include them in the same packet. This needs to be considered when implementing F-RTO for SCTP. The basic principle of F-RTO still holds: in order to declare the RTO spurious, the sender must get an acknowledgement for a data chunk that was not retransmitted after the RTO. In other words, acknowledgements of data chunks that were bundled in RTO retransmission must not be used for declaring the RTO spurious. 6. Security Considerations - The main security threat regarding F-RTO is the possibility of + The main security threat regarding F-RTO is the possibility of a receiver misleading the sender to set too large a congestion window after an RTO. There are two possible ways a malicious receiver could trigger a wrong output from the F-RTO algorithm. First, the receiver can acknowledge data that it has not received. Second, it can delay acknowledgement of a segment it has received earlier, and acknowledge the segment after the TCP sender has been deluded to enter algorithm step 3. If the receiver acknowledges a segment it has not really received, the sender can be lead to declare RTO spurious in F-RTO algorithm @@ -541,68 +535,74 @@ [Ste00] R. Stewart, et. al. Stream Control Transmission Protocol. RFC 2960, October 2000. Informative References [ABF01] M. Allman, H. Balakrishnan, and S. Floyd. Enhancing TCP's Loss Recovery Using Limited Transmit. RFC 3042, January 2001. [BA02] E. Blanton and M. Allman. On Making TCP more Robust to - Packet Reordering. ACM Computer Communication Review, - 32(1), January 2002. + Packet Reordering. ACM SIGCOMM Computer Communication + Review, 32(1), January 2002. [BBJ92] D. Borman, R. Braden, and V. Jacobson. TCP Extensions for High Performance. RFC 1323, May 1992. [FH99] S. Floyd and T. Henderson. The NewReno Modification to TCP's Fast Recovery Algorithm. RFC 2582, April 1999. [FMMP00] S. Floyd, J. Mahdavi, M. Mathis, and M. Podolsky. An Exten- sion to the Selective Acknowledgement (SACK) Option to TCP. RFC 2883, July 2000. [GL02] A. Gurtov and R. Ludwig. Evaluating the Eifel Algorithm for TCP in a GPRS Network. In Proc. of European Wireless, Flo- rence, Italy, February 2002 + [GL03] A. Gurtov and R. Ludwig, Responding to Spurious Timeouts in + TCP, In Proceedings of IEEE INFOCOM 03, March 2003. + [LG03] R. Ludwig and A. Gurtov. The Eifel Response Algorithm for TCP. Internet draft "draft-ietf-tsvwg-tcp-eifel- - response-03.txt". March 2003. Work in progress. + response-04.txt". October 2003. Work in progress. [LK00] R. Ludwig and R.H. Katz. The Eifel Algorithm: Making TCP - Robust Against Spurious Retransmissions. ACM Computer Com- - munication Review, 30(1), January 2000. + Robust Against Spurious Retransmissions. ACM SIGCOMM Com- + puter Communication Review, 30(1), January 2000. [LM03] R. Ludwig and M. Meyer. The Eifel Detection Algorithm for TCP. RFC 3522, April 2003. - [SKR02] P. Sarolahti, M. Kojo, and K. Raatikainen. F-RTO: A New - Recovery Algorithm for TCP Retransmission Timeouts. Univer- - sity of Helsinki, Dept. of Computer Science. Series of Pub- - lications C, No. C-2002-07. February 2002. Available at: - http://www.cs.helsinki.fi/research/iwtcp/papers/f-rto.ps + [SKR03] P. Sarolahti, M. Kojo, and K. Raatikainen. F-RTO: An + Enhanced Recovery Algorithm for TCP Retransmission Time- + outs. ACM SIGCOMM Computer Communication Review, 33(2), + April 2003. + + [Sar03] P. Sarolahti. Congestion Control on Spurious TCP Retrans- + mission Timeouts. In Proceedings of IEEE Globecom 2003. + December 2003. [SL03] Y. Swami and K. Le. DCLOR: De-correlated Loss Recovery using SACK option for spurious timeouts. Internet draft - "draft-swami-tsvwg-tcp-dclor-01.txt". April 2003. Work in - progress. + "draft-swami-tsvwg-tcp-dclor-02.txt". September 2003. Work + in progress. Appendix A: Scenarios This section discusses different scenarios where RTOs occur and how the basic F-RTO algorithm performs in those scenarios. The interesting scenarios are a sudden delay triggering RTO, loss of a retransmitted packet during fast recovery, link outage causing the loss of several packets, and packet reordering. A performance evaluation with a more thorough analysis on a real implementation of - F-RTO is given in [SKR02]. + F-RTO is given in [SKR03]. A.1. Sudden delay The main motivation of F-RTO algorithm is to improve TCP performance when a delay spike triggers a spurious retransmission timeout. The example below illustrates the segments and acknowledgements transmitted by the TCP end hosts when a spurious RTO occurs, but no packets are lost. For simplicity, delayed acknowledgements are not used in the example. The example below reduces the congestion window and slow start threshold by half after detecting a spurious RTO.