draft-ietf-tcpm-rfc4138bis-01.txt   draft-ietf-tcpm-rfc4138bis-02.txt 
Internet Engineering Task Force P. Sarolahti Internet Engineering Task Force P. Sarolahti
INTERNET-DRAFT Nokia Research Center INTERNET-DRAFT Nokia Research Center
draft-ietf-tcpm-rfc4138bis-01.txt M. Kojo draft-ietf-tcpm-rfc4138bis-02.txt M. Kojo
Expires: May 2008 University of Helsinki Expires: January 2009 University of Helsinki
K. Yamamoto K. Yamamoto
M. Hata M. Hata
NTT Docomo NTT Docomo
18 November 2007
Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
Spurious Retransmission Timeouts with TCP Spurious Retransmission Timeouts with TCP
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 38 skipping to change at page 1, line 35
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 2008. This Internet-Draft will expire on January 2009.
Abstract Abstract
Spurious retransmission timeouts cause suboptimal TCP performance Spurious retransmission timeouts cause suboptimal TCP performance
because they often result in unnecessary retransmission of the last because they often result in unnecessary retransmission of the last
window of data. This document describes the F-RTO detection window of data. This document describes the F-RTO detection
algorithm for detecting spurious TCP retransmission timeouts. F-RTO algorithm for detecting spurious TCP retransmission timeouts. F-RTO
is a TCP sender-only algorithm that does not require any TCP options is a TCP sender-only algorithm that does not require any TCP options
to operate. After retransmitting the first unacknowledged segment to operate. After retransmitting the first unacknowledged segment
triggered by a timeout, the F-RTO algorithm of the TCP sender triggered by a timeout, the F-RTO algorithm of the TCP sender
skipping to change at page 3, line 11 skipping to change at page 3, line 11
or retransmit unacknowledged segments. The algorithm effectively or retransmit unacknowledged segments. The algorithm effectively
helps to avoid additional unnecessary retransmissions and thereby helps to avoid additional unnecessary retransmissions and thereby
improves TCP performance in the case of a spurious timeout. improves TCP performance in the case of a spurious timeout.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions and Terminology. . . . . . . . . . . . . . . 5 1.1. Conventions and Terminology. . . . . . . . . . . . . . . 5
2. Basic F-RTO Algorithm . . . . . . . . . . . . . . . . . . . . 5 2. Basic F-RTO Algorithm . . . . . . . . . . . . . . . . . . . . 5
2.1. The Algorithm. . . . . . . . . . . . . . . . . . . . . . 6 2.1. The Algorithm. . . . . . . . . . . . . . . . . . . . . . 6
2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8
3. SACK-Enhanced Version of the F-RTO Algorithm. . . . . . . . . 9 3. SACK-Enhanced Version of the F-RTO Algorithm. . . . . . . . . 10
4. Taking Actions after Detecting Spurious RTO . . . . . . . . . 11 4. Taking Actions after Detecting Spurious RTO . . . . . . . . . 12
5. Evaluation of RFC 4138 and Differences to this 5. Evaluation of RFC 4138 and Differences to this
Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 14
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
A. Discussion of Window-Limited Cases. . . . . . . . . . . . . . 14 A. Discussion of Window-Limited Cases. . . . . . . . . . . . . . 15
B. List of Changes . . . . . . . . . . . . . . . . . . . . . . . 15 B. List of Changes . . . . . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Normative References . . . . . . . . . . . . . . . . . . . . . . 16 Normative References . . . . . . . . . . . . . . . . . . . . . . 17
Informative References . . . . . . . . . . . . . . . . . . . . . 17 Informative References . . . . . . . . . . . . . . . . . . . . . 17
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 18 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 20 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The Transmission Control Protocol (TCP) [Pos81] has two methods for The Transmission Control Protocol (TCP) [Pos81] has two methods for
triggering retransmissions. First, the TCP sender relies on triggering retransmissions. First, the TCP sender relies on
incoming duplicate ACKs, which indicate that the receiver is missing incoming duplicate ACKs, which indicate that the receiver is missing
some of the data. After a required number of successive duplicate some of the data. After a required number of successive duplicate
ACKs have arrived at the sender, it retransmits the first ACKs have arrived at the sender, it retransmits the first
unacknowledged segment [APS99] and continues with a loss recovery unacknowledged segment [APS99] and continues with a loss recovery
algorithm such as NewReno [FHG04] or SACK-based loss recovery algorithm such as NewReno [FHG04] or SACK-based loss recovery
skipping to change at page 5, line 15 skipping to change at page 5, line 15
second acknowledgment that arrives after the timeout advances the second acknowledgment that arrives after the timeout advances the
window (i.e., acknowledges data that was not retransmitted), the F- window (i.e., acknowledges data that was not retransmitted), the F-
RTO sender declares the timeout spurious and exits the RTO recovery. RTO sender declares the timeout spurious and exits the RTO recovery.
However, if either of these two acknowledgments is a duplicate ACK, However, if either of these two acknowledgments is a duplicate ACK,
there will not be sufficient evidence of a spurious timeout. there will not be sufficient evidence of a spurious timeout.
Therefore, the F-RTO sender retransmits the unacknowledged segments Therefore, the F-RTO sender retransmits the unacknowledged segments
in slow start similarly to the traditional algorithm. in slow start similarly to the traditional algorithm.
With a SACK-enhanced version of the F-RTO algorithm, spurious With a SACK-enhanced version of the F-RTO algorithm, spurious
timeouts may be detected even if duplicate ACKs arrive after an RTO timeouts may be detected even if duplicate ACKs arrive after an RTO
retransmission. Even though this document only specifies F-RTO retransmission. Even though this document only specifies the F-RTO
algorithm for TCP, the algorithm can also be applied to the Stream algorithm for TCP, the algorithm can also be applied to the Stream
Control Transmission Protocol (SCTP) [Ste00] that has acknowledgment Control Transmission Protocol (SCTP) [Ste00] that has acknowledgment
and packet retransmission concepts similar to TCP. Considerations on and packet retransmission concepts similar to TCP. Considerations on
applying F-RTO for SCTP are discussed in RFC 4138 [SK05]. applying F-RTO for SCTP are discussed in RFC 4138 [SK05].
This document is organized as follows. Section 2 describes the This document is organized as follows. Section 2 describes the
basic F-RTO algorithm, and the SACK-enhanced F-RTO algorithm is basic F-RTO algorithm, and the SACK-enhanced F-RTO algorithm is
given in Section 3. Section 4 discusses the possible actions to be given in Section 3. Section 4 discusses the possible actions to be
taken after detecting a spurious RTO and Section 5 discusses the taken after detecting a spurious RTO and Section 5 discusses the
security considerations. security considerations.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
and if the TCP sender gets an acknowledgment for a segment that was and if the TCP sender gets an acknowledgment for a segment that was
not retransmitted due to timeout, the F-RTO algorithm declares a not retransmitted due to timeout, the F-RTO algorithm declares a
timeout spurious. The actions taken in response to a spurious timeout spurious. The actions taken in response to a spurious
timeout are not specified in this document, but we discuss some timeout are not specified in this document, but we discuss some
alternatives in Section 4. This section introduces the algorithm alternatives in Section 4. This section introduces the algorithm
and then discusses the different steps of the algorithm in more and then discusses the different steps of the algorithm in more
detail. detail.
Following the practice used with the Eifel Detection algorithm Following the practice used with the Eifel Detection algorithm
[LM03], we use the "SpuriousRecovery" variable to indicate whether [LM03], we use the "SpuriousRecovery" variable to indicate whether
the retransmission is declared spurious by the sender. This the retransmission is declared spurious by the sender. This variable
variable can be used as an input for a corresponding response can be used as an input for a corresponding response algorithm. With
algorithm. With F-RTO, the value of SpuriousRecovery can be either F-RTO, the value of SpuriousRecovery can be either SPUR_TO
SPUR_TO (indicating a spurious retransmission timeout) or FALSE (indicating a spurious retransmission timeout) or FALSE (indicating
(indicating that the timeout is not declared spurious), and the TCP that the timeout is not declared spurious), and the TCP sender
sender should follow the conventional RTO recovery algorithm. should follow the conventional RTO recovery algorithm. In addition,
we use the "recover" variable specified in the NewReno algorithm
[FHG04].
2.1. The Algorithm 2.1. The Algorithm
A TCP sender implementing the basic F-RTO algorithm MUST take the A TCP sender implementing the basic F-RTO algorithm MUST take the
following steps after the retransmission timer expires. If the following steps after the retransmission timer expires. If the
retransmission timer expires again during the execution of the F-RTO retransmission timer expires again during the execution of the F-RTO
algorithm, the TCP sender MUST re-start the algorithm processing algorithm, the TCP sender MUST re-start the algorithm processing
from step 1. If the sender implements some loss recovery algorithm from step 1. If the sender implements some loss recovery algorithm
other than Reno or NewReno [FHG04], the F-RTO algorithm SHOULD NOT other than Reno or NewReno [FHG04], the F-RTO algorithm SHOULD NOT
be entered when earlier fast recovery is underway. be entered when earlier fast recovery is underway.
The F-RTO algorithm takes different actions based on whether an The F-RTO algorithm takes different actions based on whether an
incoming acknowledgement advances the cumulative acknowledgement incoming acknowledgement advances the cumulative acknowledgement
point for an received in-order segment, or whether it is a duplicate point for a received in-order segment, or whether it is a duplicate
acknowledgement to indicate an out-of-order segment. Duplicate acknowledgement to indicate an out-of-order segment. Duplicate
acknowledgement is defined in [APB07]. The F-RTO algorithm does not acknowledgement is defined in [APB07]. The F-RTO algorithm does not
specify actions for receiving a segment that does not acknowledge specify actions for receiving a segment that does not acknowledge
new data but is not a duplicate acknowledgement. The TCP sender new data but is not a duplicate acknowledgement. The TCP sender
SHOULD ignore such segments and wait for a segment that either SHOULD ignore such segments and wait for a segment that either
acknowledges new data or is a duplicate acknowledgment. acknowledges new data or is a duplicate acknowledgment.
1) When RTO expires, retransmit the first unacknowledged segment and 1) When RTO expires, retransmit the first unacknowledged segment and
set SpuriousRecovery to FALSE. Also, store the highest sequence set SpuriousRecovery to FALSE. If the TCP sender is already in
number transmitted so far in variable "recover". RTO recovery AND "recover" is larger then SND.UNA (the oldest
unacknowledged sequence number [Pos81]), do not enter step 2 of
this algorithm. Instead, store the highest sequence number
transmitted so far in variable "recover" and continue with slow
start retransmissions following the conventional RTO recovery
algorithm.
2) When the first acknowledgment after the RTO retransmission 2) When the first acknowledgment after the RTO retransmission
arrives at the TCP sender, the TCP sender chooses one of the arrives at the TCP sender, store the highest sequence number
following actions, depending on whether the ACK advances the transmitted so far in variable "recover". The TCP sender chooses
window or whether it is a duplicate ACK. one of the following actions, depending on whether the ACK
advances the window or whether it is a duplicate ACK.
a) If the acknowledgment is a duplicate ACK OR the a) If the acknowledgment is a duplicate ACK OR the
Acknowledgement field covers "recover" but not more than Acknowledgement field covers "recover" but not more than
"recover" OR the acknowledgment does not acknowledge all of "recover" OR the acknowledgment does not acknowledge all of
the data that was retransmitted in step 1, revert to the the data that was retransmitted in step 1, revert to the
conventional RTO recovery and continue by retransmitting conventional RTO recovery and continue by retransmitting
unacknowledged data in slow start. Do not enter step 3 of unacknowledged data in slow start. Do not enter step 3 of
this algorithm. The SpuriousRecovery variable remains as this algorithm. The SpuriousRecovery variable remains as
FALSE. FALSE.
skipping to change at page 8, line 5 skipping to change at page 8, line 14
2.2. Discussion 2.2. Discussion
The F-RTO sender takes cautious actions when it receives duplicate The F-RTO sender takes cautious actions when it receives duplicate
acknowledgments after a retransmission timeout. Because duplicate acknowledgments after a retransmission timeout. Because duplicate
ACKs may indicate that segments have been lost, reliably detecting a ACKs may indicate that segments have been lost, reliably detecting a
spurious timeout is difficult due to the lack of additional spurious timeout is difficult due to the lack of additional
information. Therefore, it is prudent to follow the conventional information. Therefore, it is prudent to follow the conventional
TCP recovery in those cases. TCP recovery in those cases.
The condition in step 1 prevents the execution of the F-RTO
algorithm in case a previous RTO recovery is underway when the
retransmission timer expires, except in case the retransmission
timer expires multiple times for the same segment. If RTO expires
during an earlier RTO-based loss recovery, acknowledgements for
retransmitted segments may falsely lead the TCP sender to declare
the timeout spurious.
If the first acknowledgment after the RTO retransmission covers the If the first acknowledgment after the RTO retransmission covers the
"recover" point at algorithm step (2a), there is not enough evidence "recover" point at algorithm step (2a), there is not enough evidence
that a non-retransmitted segment has arrived at the receiver after that a non-retransmitted segment has arrived at the receiver after
the timeout. This is a common case when a fast retransmission is the timeout. This is a common case when a fast retransmission is
lost and has been retransmitted again after an RTO, while the rest lost and has been retransmitted again after an RTO, while the rest
of the unacknowledged segments were successfully delivered to the of the unacknowledged segments were successfully delivered to the
TCP receiver before the retransmission timeout. Therefore, the TCP receiver before the retransmission timeout. Therefore, the
timeout cannot be declared spurious in this case. timeout cannot be declared spurious in this case.
If the first acknowledgment after the RTO retransmission does not If the first acknowledgment after the RTO retransmission does not
skipping to change at page 9, line 47 skipping to change at page 10, line 19
using the SACK option, the TCP sender detects spurious timeouts in using the SACK option, the TCP sender detects spurious timeouts in
most of the cases when packet reordering or packet duplication is most of the cases when packet reordering or packet duplication is
present. If the SACK blocks acknowledge new data that was not present. If the SACK blocks acknowledge new data that was not
transmitted after the RTO retransmission, the sender may declare the transmitted after the RTO retransmission, the sender may declare the
timeout spurious, even when duplicate ACKs follow the RTO. timeout spurious, even when duplicate ACKs follow the RTO.
Given that the TCP Selective Acknowledgment Option [MMFR96] is Given that the TCP Selective Acknowledgment Option [MMFR96] is
enabled for a TCP connection, a TCP sender MAY implement the SACK- enabled for a TCP connection, a TCP sender MAY implement the SACK-
enhanced F-RTO algorithm. If the sender applies the SACK-enhanced enhanced F-RTO algorithm. If the sender applies the SACK-enhanced
F-RTO algorithm, it MUST follow the steps below. This algorithm F-RTO algorithm, it MUST follow the steps below. This algorithm
SHOULD NOT be applied if the TCP sender is already in SACK loss SHOULD NOT be applied if the TCP sender is already in loss recovery
recovery when retransmission timeout occurs. when retransmission timeout occurs.
The steps of the SACK-enhanced version of the F-RTO algorithm are as The steps of the SACK-enhanced version of the F-RTO algorithm are as
follows. If the retransmission timer expires again during the follows. If the retransmission timer expires again during the
execution of the SACK-enhanced F-RTO algorithm, the TCP sender MUST execution of the SACK-enhanced F-RTO algorithm, the TCP sender MUST
re-start the algorithm processing from step 1. re-start the algorithm processing from step 1.
1) When the RTO expires, retransmit the first unacknowledged segment 1) When the RTO expires, retransmit the first unacknowledged segment
and set SpuriousRecovery to FALSE. Set variable "RecoveryPoint" and set SpuriousRecovery to FALSE. Following the recommendation
to indicate the highest segment transmitted so far. Following the in SACK specification [MMFR96], reset the SACK scoreboard. If
recommendation in SACK specification [MMFR96], reset the SACK "RecoveryPoint" is larger than SND.UNA, do not enter step 2 of
scoreboard. this algorithm. Instead, set variable "RecoveryPoint" to
indicate the highest sequence number transmitted so far and
continue with slow start retransmissions following the
conventional RTO recovery algorithm.
2) Wait until the acknowledgment of the data retransmitted due to 2) Wait until the acknowledgment of the data retransmitted due to
the timeout arrives at the sender. If duplicate ACKs arrive the timeout arrives at the sender. If duplicate ACKs arrive
before the cumulative acknowledgment for retransmitted data, before the cumulative acknowledgment for retransmitted data,
adjust the scoreboard according to the incoming SACK information. adjust the scoreboard according to the incoming SACK information.
Stay in step 2 and wait for the next new acknowledgment. If RTO Stay in step 2 and wait for the next new acknowledgment. If RTO
expires again, go to step 1 of the algorithm. expires again, go to step 1 of the algorithm. When a new
acknowledgment arrives, set variable "RecoveryPoint" to indicate
the highest sequence number transmitted so far.
a) if the Cumulative Acknowledgement field covers "RecoveryPoint" a) If the Cumulative Acknowledgement field covers "RecoveryPoint"
but not more than "RecoveryPoint", revert to the conventional but not more than "RecoveryPoint", revert to the conventional
RTO recovery and set the congestion window to no more than 2 * RTO recovery and set the congestion window to no more than 2 *
MSS, like a regular TCP would do. Do not enter step 3 of this MSS, like a regular TCP would do. Do not enter step 3 of this
algorithm. algorithm.
b) else, if the Cumulative Acknowledgement field does not cover b) Else, if the Cumulative Acknowledgement field does not cover
"RecoveryPoint" but is larger than SND.UNA, transmit up to two "RecoveryPoint" but is larger than SND.UNA, transmit up to two
new (previously unsent) segments and proceed to step 3. If new (previously unsent) segments and proceed to step 3. If
the TCP sender is not able to transmit any previously unsent the TCP sender is not able to transmit any previously unsent
data -- either due to receiver window limitation or because it data -- either due to receiver window limitation or because it
does not have any new data to send -- the recommended action does not have any new data to send -- the recommended action
is to refrain from entering step 3 of this algorithm. Rather, is to refrain from entering step 3 of this algorithm. Rather,
continue with slow start retransmissions following the continue with slow start retransmissions following the
conventional RTO recovery algorithm. conventional RTO recovery algorithm.
It is also possible to apply some of the alternatives for It is also possible to apply some of the alternatives for
handling window-limited cases discussed in Appendix A. handling window-limited cases discussed in Appendix A.
3) The next acknowledgment arrives at the sender. Either a 3) The next acknowledgment arrives at the sender. Either a
duplicate ACK or a new cumulative ACK (advancing the window) duplicate ACK or a new cumulative ACK (advancing the window)
applies in this step. Other types of ACKs are ignored without any applies in this step. Other types of ACKs are ignored without any
action. action.
a) if the Cumulative Acknowledgement field or a SACK block covers a) If the Cumulative Acknowledgement field or a SACK block covers
more than "RecoveryPoint", set the congestion window to no more than "RecoveryPoint", set the congestion window to no
more than 3 * MSS and proceed with the conventional RTO more than 3 * MSS and proceed with the conventional RTO
recovery, retransmitting unacknowledged segments. Take this recovery, retransmitting unacknowledged segments. Take this
branch also when the acknowledgment is a duplicate ACK and it branch also when the acknowledgment is a duplicate ACK and it
does not acknowledge any new, previously unacknowledged data does not acknowledge any new, previously unacknowledged data
below "RecoveryPoint" in the SACK blocks. Leave below "RecoveryPoint" in the SACK blocks. Leave
SpuriousRecovery set to FALSE. SpuriousRecovery set to FALSE.
b) if the Cumulative Acknowledgement field or a SACK block in the b) If the Cumulative Acknowledgement field or a SACK block in the
ACK does not cover more than "RecoveryPoint" AND it ACK does not cover more than "RecoveryPoint" AND it
acknowledges data that was not acknowledged earlier (either acknowledges data that was not acknowledged earlier (either
with cumulative acknowledgment or using SACK blocks), declare with cumulative acknowledgment or using SACK blocks), declare
the timeout spurious and set SpuriousRecovery to SPUR_TO. The the timeout spurious and set SpuriousRecovery to SPUR_TO. The
retransmission timeout can be declared spurious, because the retransmission timeout can be declared spurious, because the
segment acknowledged with this ACK was transmitted before the segment acknowledged with this ACK was transmitted before the
timeout. timeout.
If there are unacknowledged holes between the received SACK blocks, If there are unacknowledged holes between the received SACK blocks,
those segments are retransmitted similarly to the conventional SACK those segments are retransmitted similarly to the conventional SACK
skipping to change at page 11, line 33 skipping to change at page 12, line 7
algorithm, but by utilizing the additional information from the SACK algorithm, but by utilizing the additional information from the SACK
option. When a genuine retransmission timeout occurs during a steady option. When a genuine retransmission timeout occurs during a steady
state of a connection, it can be assumed that there are no segments state of a connection, it can be assumed that there are no segments
left in the pipe. Otherwise, the acknowledgments triggered by these left in the pipe. Otherwise, the acknowledgments triggered by these
segments would have triggered the SACK loss recovery or transmission segments would have triggered the SACK loss recovery or transmission
of new segments. Therefore, if the F-RTO sender receives of new segments. Therefore, if the F-RTO sender receives
acknowledgements for segments transmitted before the retransmission acknowledgements for segments transmitted before the retransmission
timeout in response to the two new segments sent at the algorithm timeout in response to the two new segments sent at the algorithm
step 2, the normal operation of TCP has been just delayed, and the step 2, the normal operation of TCP has been just delayed, and the
retransmission timeout is considered spurious. Note that this retransmission timeout is considered spurious. Note that this
reasoning works only when the TCP sender is not in SACK loss reasoning works only when the TCP sender is not in loss recovery at
recovery at the time the retransmission timeout occurs. the time the retransmission timeout occurs. The condition in step 1
checking that "RecoveryPoint" is larger than SND.UNA prevents the
execution of the F-RTO algorithm in case a previous loss recovery,
either RTO recovery or SACK loss recovery, is underway when the
retransmission timer expires. It, however, allows the execution of
the F-RTO algorithm, if the retransmission timer expires multiple
times for the same segment.
4. Taking Actions after Detecting Spurious RTO 4. Taking Actions after Detecting Spurious RTO
Upon a retransmission timeout, a conventional TCP sender assumes Upon a retransmission timeout, a conventional TCP sender assumes
that outstanding segments are lost and starts retransmitting the that outstanding segments are lost and starts retransmitting the
unacknowledged segments. When the retransmission timeout is unacknowledged segments. When the retransmission timeout is
detected to be spurious, the TCP sender should not continue detected to be spurious, the TCP sender should not continue
retransmitting based on the timeout. For example, if the sender was retransmitting based on the timeout. For example, if the sender was
in congestion avoidance phase transmitting new, previously unsent in congestion avoidance phase transmitting new, previously unsent
segments, it should continue transmitting previously unsent segments segments, it should continue transmitting previously unsent segments
skipping to change at page 14, line 13 skipping to change at page 14, line 44
Instead, the sender would reduce the congestion window to 1. Instead, the sender would reduce the congestion window to 1.
If there is more than one segment missing at the time of a If there is more than one segment missing at the time of a
retransmission timeout, the receiver does not benefit from retransmission timeout, the receiver does not benefit from
misleading the sender to declare a spurious timeout because the misleading the sender to declare a spurious timeout because the
sender would have to go through another recovery period to sender would have to go through another recovery period to
retransmit the missing segments, usually after an RTO has elapsed. retransmit the missing segments, usually after an RTO has elapsed.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Alfred Hoenes and Ilpo Jarvinen for The authors would like to thank Alfred Hoenes, Ilpo Jarvinen and
the comments on this document. Murari Sridharan for the comments on this document.
We are also thankful to Reiner Ludwig, Andrei Gurtov, Josh Blanton, We are also thankful to Reiner Ludwig, Andrei Gurtov, Josh Blanton,
Mark Allman, Sally Floyd, Yogesh Swami, Mika Liljeberg, Ivan Arias Mark Allman, Sally Floyd, Yogesh Swami, Mika Liljeberg, Ivan Arias
Rodriguez, Sourabh Ladha, Martin Duke, Motoharu Miyake, Ted Faber, Rodriguez, Sourabh Ladha, Martin Duke, Motoharu Miyake, Ted Faber,
Samu Kontinen, and Kostas Pentikousis who gave valuable feedback Samu Kontinen, and Kostas Pentikousis who gave valuable feedback
during the preparation of RFC 4138, the precursor of this document. during the preparation of RFC 4138, the precursor of this document.
Appendix Appendix
A. Discussion of Window-Limited Cases A. Discussion of Window-Limited Cases
skipping to change at page 15, line 14 skipping to change at page 15, line 42
[SKR03]. [SKR03].
- Retransmit data from the tail of the retransmission queue and - Retransmit data from the tail of the retransmission queue and
continue with step 3 of the F-RTO algorithm. It is possible that continue with step 3 of the F-RTO algorithm. It is possible that
the retransmission will be made unnecessarily. Furthermore, the the retransmission will be made unnecessarily. Furthermore, the
operation of the SACK-based F-RTO algorithm would need to consider operation of the SACK-based F-RTO algorithm would need to consider
this case separately, to not use the retransmitted segment to this case separately, to not use the retransmitted segment to
indicate spurious timeout. Given these considerations, this option indicate spurious timeout. Given these considerations, this option
is not recommended. is not recommended.
- Send a zero-sized segment below SND.UNA, similar to TCP Keep-Alive - Send a zero-sized segment below SND.UNA, similar to a TCP Keep-
probe, and continue with step 3 of the F-RTO algorithm. Because Alive probe, and continue with step 3 of the F-RTO algorithm.
the receiver replies with a duplicate ACK, the sender is able to Because the receiver replies with a duplicate ACK, the sender is
detect whether the timeout was spurious from the incoming able to detect whether the timeout was spurious from the incoming
acknowledgment. This method does not send data unnecessarily, but acknowledgment. This method does not send data unnecessarily, but
it delays the recovery by one round-trip time in cases where the it delays the recovery by one round-trip time in cases where the
timeout was not spurious. Therefore, this method is not timeout was not spurious. Therefore, this method is not
encouraged. encouraged.
- In receiver-limited cases, send one octet of new data, regardless - In receiver-limited cases, send one octet of new data, regardless
of the advertised window limit, and continue with step 3 of the F- of the advertised window limit, and continue with step 3 of the F-
RTO algorithm. It is possible that the receiver will have free RTO algorithm. It is possible that the receiver will have free
buffer space to receive the data by the time the segment has buffer space to receive the data by the time the segment has
propagated through the network, in which case no harm is done. If propagated through the network, in which case no harm is done. If
the receiver is not capable of receiving the segment, it rejects the receiver is not capable of receiving the segment, it rejects
the segment and sends a duplicate ACK. the segment and sends a duplicate ACK.
B. List of Changes B. List of Changes
Changes between different document versions are summarized below, Changes between different document versions are summarized below,
apart from minor editing and language improvements. apart from minor editing and language improvements.
Changes from draft-ietf-tcpm-rfc4138bis-01:
* Modified the basic F-RTO algorithm and SACK-enhanced F-RTO
algorithm to prevent the TCP sender from applying F-RTO algorithm if
retransmission timer expires when an earlier RTO recovery is
underway, except when RTO expires multiple times for the same
segment.
Changes from draft-ietf-tcpm-rfc4138bis-00: Changes from draft-ietf-tcpm-rfc4138bis-00:
* Added back the original SACK-algorithm from RFC 4138 after the * Added back the original SACK-algorithm from RFC 4138 after the
common feedback to have the SACK-algorithm in the document. common feedback to have the SACK-algorithm in the document.
Clarified the algorithm a bit, and added one paragraph of Clarified the algorithm a bit, and added one paragraph of
description of the basic idea of the algorithm. description of the basic idea of the algorithm.
* Clarified behavior on multiple timeouts. * Clarified behavior on multiple timeouts.
* Added a paragraph on acknowledgements that do not acknowledge new * Added a paragraph on acknowledgements that do not acknowledge new
skipping to change at page 17, line 46 skipping to change at page 18, line 36
[Jac88] V. Jacobson. Congestion Avoidance and Control. In [Jac88] V. Jacobson. Congestion Avoidance and Control. In
Proceedings of ACM SIGCOMM 88. Proceedings of ACM SIGCOMM 88.
[Hok05] A. Hokamura, et al. "Performance Evaluation of F-RTO and [Hok05] A. Hokamura, et al. "Performance Evaluation of F-RTO and
Eifel Response Algorithms over W-CDMA packet network". Eifel Response Algorithms over W-CDMA packet network".
Wireless Personal Multimedia Communications (WPMC'05), Wireless Personal Multimedia Communications (WPMC'05),
Sept. 2005. Sept. 2005.
[KYHS07] M. Kojo, K. Yamamoto, M. Hata, and P. Sarolahti. [KYHS07] M. Kojo, K. Yamamoto, M. Hata, and P. Sarolahti.
Evaluation of RFC 4138. Evaluation of RFC 4138. Internet-draft
Internet-draft "draft-kojo-tcpm-frto-eval-00.txt", "draft-kojo-tcpm-frto-eval-00.txt", June 2007. Work
June 2007. Work in progress. in progress.
[LG04] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm [LG04] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm
for TCP", RFC 4015, February 2005. for TCP", RFC 4015, February 2005.
[LK00] R. Ludwig and R.H. Katz. The Eifel Algorithm: Making TCP [LK00] R. Ludwig and R.H. Katz. The Eifel Algorithm: Making TCP
Robust Against Spurious Retransmissions. ACM SIGCOMM Robust Against Spurious Retransmissions. ACM SIGCOMM
Computer Communication Review, 30(1), January 2000. Computer Communication Review, 30(1), January 2000.
[LM03] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm [LM03] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm
for TCP", RFC 3522, April 2003. for TCP", RFC 3522, April 2003.
 End of changes. 25 change blocks. 
53 lines changed or deleted 85 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/