draft-ietf-tcpm-frto-01.txt   draft-ietf-tcpm-frto-02.txt 
Internet Engineering Task Force P. Sarolahti Internet Engineering Task Force P. Sarolahti
INTERNET DRAFT Nokia Research Center INTERNET DRAFT Nokia Research Center
File: draft-ietf-tcpm-frto-01.txt M. Kojo File: draft-ietf-tcpm-frto-02.txt M. Kojo
University of Helsinki University of Helsinki
July, 2004 November, 2004
Expires: January, 2005 Expires: May, 2005
F-RTO: An Algorithm for Detecting Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
Spurious Retransmission Timeouts with TCP and SCTP Spurious Retransmission Timeouts with TCP and SCTP
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, we certify that any applicable
all provisions of Section 10 of RFC 2026. patent or other IPR claims of which we are aware have been disclosed,
and any of which we become aware will be disclosed, in accordance
with RFC 3668.
By submitting this Internet-Draft, we accept the provisions of
Section 3 of RFC 3667 (BCP 78).
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
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 algorithm window of data. This document describes the F-RTO detection algorithm
for detecting spurious TCP retransmission timeouts. F-RTO is a TCP for detecting spurious TCP retransmission timeouts. F-RTO is a TCP
skipping to change at page 2, line 31 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. F-RTO Algorithm . . . . . . . . . . . . . . . . . . . . . . . 5 2. F-RTO Algorithm . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 The Algorithm . . . . . . . . . . . . . . . . . . . . . 5 2.1 The Algorithm . . . . . . . . . . . . . . . . . . . . . 5
2.2 Discussion . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Discussion . . . . . . . . . . . . . . . . . . . . . . 6
3. SACK-enhanced version of the F-RTO algorithm . . . . . . . . 8 3. SACK-enhanced version of the F-RTO algorithm . . . . . . . . 8
4. Taking Actions after Detecting Spurious RTO . . . . . . . . . 10 4. Taking Actions after Detecting Spurious RTO . . . . . . . . . 10
5. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix A: Scenarios . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A: Scenarios . . . . . . . . . . . . . . . . . . . . . . 14
Appendix B: SACK-enhanced F-RTO and Fast Recovery . . . . . . . . 19 Appendix B: SACK-enhanced F-RTO and Fast Recovery . . . . . . . . 19
Appendix C: Discussion on Window Limited Cases . . . . . . . . . 20 Appendix C: Discussion on Window Limited Cases . . . . . . . . . 20
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 incoming triggering retransmissions. First, the TCP sender relies on incoming
duplicate ACKs, which indicate that the receiver is missing some of duplicate ACKs, which indicate that the receiver is missing some of
the data. After a required number of successive duplicate ACKs have the data. After a required number of successive duplicate ACKs have
skipping to change at page 5, line 37 skipping to change at page 5, line 37
2.1. The Algorithm 2.1. The Algorithm
A TCP sender MAY implement the basic F-RTO algorithm, and if it A TCP sender MAY implement the basic F-RTO algorithm, and if it
chooses to apply the algorithm, the following steps MUST be taken chooses to apply the algorithm, the following steps MUST be taken
after the retransmission timer expires. If the sender implements some after the retransmission timer expires. If the sender implements some
loss recovery algorithm other than Reno or NewReno [FHG04], F-RTO loss recovery algorithm other than Reno or NewReno [FHG04], F-RTO
algorithm SHOULD NOT be entered when earlier fast recovery is algorithm SHOULD NOT be entered when earlier fast recovery is
underway. underway.
1) When RTO expires, the TCP sender SHOULD retransmit the first 1) When RTO expires, retransmit the first unacknowledged segment and
unacknowledged segment and set SpuriousRecovery to FALSE. Also, set SpuriousRecovery to FALSE. Also, store the highest sequence
the TCP SHOULD store the highest sequence number transmitted so number transmitted so far in variable "recover".
far in variable "recover".
2) When the first acknowledgment after the RTO retransmission arrives 2) When the first acknowledgment after the RTO retransmission arrives
at the sender, the sender chooses the following actions depending at the sender, the sender chooses the following actions depending
on whether the ACK advances the window or whether it is a on whether the ACK advances the window or whether it is a
duplicate ACK. duplicate ACK.
a) If the acknowledgment is a duplicate ACK OR it acknowledges a a) If the acknowledgment is a duplicate ACK OR it acknowledges a
sequence number equal to the value of "recover" OR it does not sequence number equal to the value of "recover" OR it does not
acknowledge all of the data that was retransmitted in step 1, acknowledge all of the data that was retransmitted in step 1,
the TCP sender MUST revert to the conventional RTO recovery and revert to the conventional RTO recovery and continue by
continue by retransmitting unacknowledged data in slow start. retransmitting unacknowledged data in slow start. Do not enter
step 3 of this algorithm. The SpuriousRecovery variable remains
The TCP sender MUST NOT enter step 3 of this algorithm, and the as FALSE.
SpuriousRecovery variable remains as FALSE.
b) Else, if the acknowledgment advances the window AND it is below b) Else, if the acknowledgment advances the window AND it is below
the value of "recover", the TCP sender SHOULD transmit up to the value of "recover", transmit up to two new (previously
two new (previously unsent) segments and enter step 3 of this unsent) segments and enter step 3 of this algorithm. If the TCP
algorithm. If the TCP sender does not have enough unsent data, sender does not have enough unsent data, it can send only one
it SHOULD send only one segment. In addition, the TCP sender segment. In addition, the TCP sender MAY override the Nagle
MAY override the Nagle algorithm [Nag84] and immediately send a algorithm [Nag84] and immediately send a segment if needed.
segment if needed. Note that sending two segments in this step Note that sending two segments in this step is allowed by TCP
is allowed by TCP congestion control requirements [APS99]: An congestion control requirements [APS99]: An F-RTO TCP sender
F-RTO TCP sender simply chooses different segments to transmit. simply chooses different segments to transmit.
If the TCP sender does not have any new data to send, or the If the TCP sender does not have any new data to send, or the
advertised window prohibits new transmissions, the recommended advertised window prohibits new transmissions, the recommended
action is to skip step 3 of this algorithm and continue with action is to skip step 3 of this algorithm and continue with
slow start retransmissions following the conventional RTO slow start retransmissions following the conventional RTO
recovery algorithm. However, alternative ways of handling the recovery algorithm. However, alternative ways of handling the
window limited cases that could result in better performance window limited cases that could result in better performance
are discussed in Appendix C. are discussed in Appendix C.
3) When the second acknowledgment after the RTO retransmission 3) When the second acknowledgment after the RTO retransmission
arrives at the sender, the TCP sender either declares the timeout arrives at the sender, the TCP sender either declares the timeout
spurious, or starts retransmitting the unacknowledged segments. spurious, or starts retransmitting the unacknowledged segments.
a) If the acknowledgment is a duplicate ACK, the TCP sender MUST a) If the acknowledgment is a duplicate ACK, set the congestion
set the congestion window to no more than 3 * MSS, and continue window to no more than 3 * MSS, and continue with the slow
with the slow start algorithm retransmitting unacknowledged start algorithm retransmitting unacknowledged segments.
segments. Congestion window can be set to 3 * MSS, because two Congestion window can be set to 3 * MSS, because two round-trip
round-trip times have elapsed since the RTO, and a conventional times have elapsed since the RTO, and a conventional TCP sender
TCP sender would have increased cwnd to 3 during the same time. would have increased cwnd to 3 during the same time. Leave
The sender leaves SpuriousRecovery set to FALSE. SpuriousRecovery set to FALSE.
b) If the acknowledgment advances the window, i.e. it acknowledges b) If the acknowledgment advances the window, i.e. it acknowledges
data that was not retransmitted after the timeout, the TCP data that was not retransmitted after the timeout, declare the
sender SHOULD declare the timeout spurious, set timeout spurious, set SpuriousRecovery to SPUR_TO and set the
SpuriousRecovery to SPUR_TO and set the value of "recover" value of "recover" variable to SND.UNA, the oldest
variable to SND.UNA, the oldest unacknowledged sequence number unacknowledged sequence number [Pos81].
[Pos81].
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. Since duplicate ACKs acknowledgments after a retransmission timeout. Since duplicate ACKs
may indicate that segments have been lost, reliably detecting a 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 TCP information. Therefore, it is prudent to follow the conventional TCP
recovery in those cases. recovery in those cases.
skipping to change at page 7, line 27 skipping to change at page 7, line 26
sender reverts to the conventional RTO recovery. Otherwise, a sender reverts to the conventional RTO recovery. Otherwise, a
malicious receiver acknowledging partial segments could cause the malicious receiver acknowledging partial segments could cause the
sender to declare the timeout spurious in a case where data was lost. sender to declare the timeout spurious in a case where data was lost.
The TCP sender is allowed to send two new segments in algorithm The TCP sender is allowed to send two new segments in algorithm
branch (2b), because the conventional TCP sender would transmit two branch (2b), because the conventional TCP sender would transmit two
segments when the first new ACK arrives after the RTO retransmission. segments when the first new ACK arrives after the RTO retransmission.
If sending new data is not possible in algorithm branch (2b), or the If sending new data is not possible in algorithm branch (2b), or the
receiver window limits the transmission, the TCP sender has to send receiver window limits the transmission, the TCP sender has to send
something in order to prevent the TCP transfer from stalling. If no something in order to prevent the TCP transfer from stalling. If no
segments were sent, the pipe between sender and receiver may run out segments were sent, the pipe between sender and receiver might run
of segments, and no further acknowledgments would arrive. In this out of segments, and no further acknowledgments would arrive.
case the recommendation is to revert to the conventional RTO recovery Therefore, in the window limited case the recommendation is to revert
with slow start retransmissions, but Appendix C discusses some to the conventional RTO recovery with slow start retransmissions.
alternative solutions for window limited situations. Appendix C discusses some alternative solutions for window limited
situations.
If the retransmission timeout is declared spurious, the TCP sender If the retransmission timeout is declared spurious, the TCP sender
sets the value of the "recover" variable to SND.UNA in order to allow sets the value of the "recover" variable to SND.UNA in order to allow
fast retransmit [FHG04]. The "recover" variable was proposed for fast retransmit [FHG04]. The "recover" variable was proposed for
avoiding unnecessary multiple fast retransmits when RTO expires avoiding unnecessary multiple fast retransmits when RTO expires
during fast recovery with NewReno TCP. As the sender does not during fast recovery with NewReno TCP. As the sender does not
retransmit other segments but the one that triggered the timeout, the retransmit other segments but the one that triggered the timeout, the
problem of unnecessary multiple fast retransmits [FHG04] cannot problem of unnecessary multiple fast retransmits [FHG04] cannot
occur. Therefore, if there are three duplicate ACKs arriving at the occur. Therefore, if there are three duplicate ACKs arriving at the
sender after the timeout, they are likely to indicate a packet loss, sender after the timeout, they are likely to indicate a packet loss,
skipping to change at page 8, line 48 skipping to change at page 8, line 47
in most of the cases when packet reordering or packet duplication is in most of the cases when packet reordering or packet duplication is
present. The difference to the basic F-RTO algorithm is that the present. The difference to the basic F-RTO algorithm is that the
sender may declare timeout spurious even when duplicate ACKs follow sender may declare timeout spurious even when duplicate ACKs follow
the RTO, if the SACK blocks acknowledge new data that was not the RTO, if the SACK blocks acknowledge new data that was not
transmitted after the RTO retransmission. transmitted after the RTO retransmission.
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 enabled for a TCP connection, a TCP sender MAY implement the
SACK-enhanced F-RTO algorithm. If the sender applies the SACK-enhanced F-RTO algorithm. If the sender applies the
SACK-enhanced F-RTO algorithm, it MUST follow the steps below. This SACK-enhanced F-RTO algorithm, it MUST follow the steps below. This
algorithm SHOULD NOT be applied, if the TCP sender is already in loss algorithm SHOULD NOT be applied, if the TCP sender is already in SACK
recovery when retransmission timeout occurs. However, it should be loss recovery when retransmission timeout occurs. However, it should
possible to apply the principle of F-RTO within certain limitations be possible to apply the principle of F-RTO within certain
also when retransmission timeout occurs during existing loss limitations also when retransmission timeout occurs during existing
recovery. While this is a topic of further research, Appendix B loss recovery. While this is a topic of further research, Appendix B
briefly discusses the related issues. briefly discusses the related issues.
1) When the RTO expires, the TCP sender SHOULD retransmit the first 1) When the RTO expires, retransmit the first unacknowledged segment
unacknowledged segment and set SpuriousRecovery to FALSE. Variable and set SpuriousRecovery to FALSE. Set variable "recover" to
"recover" is set to indicate the highest segment transmitted so indicate the highest segment transmitted so far. Following the
far. Following the recommendation in SACK specification [MMFR96], recommendation in SACK specification [MMFR96], reset the SACK
the SACK scoreboard SHOULD be reset. scoreboard.
2) Wait until the acknowledgment for the data retransmitted due to 2) Wait until the acknowledgment for the data retransmitted due to
the timeout arrives at the sender. If duplicate ACKs arrive before the timeout arrives at the sender. If duplicate ACKs arrive before
the cumulative acknowledgment for retransmitted data, adjust the the cumulative acknowledgment for retransmitted data, adjust the
scoreboard according to the incoming SACK information but stay in scoreboard according to the incoming SACK information but stay in
step 2 waiting for the next new acknowledgment. If RTO expires step 2 waiting for the next new acknowledgment. If RTO expires
again, go to step 1 of the algorithm. again, go to step 1 of the algorithm.
a) if a cumulative ACK acknowledges a sequence number equal to a) if a cumulative ACK acknowledges a sequence number equal to
"recover", the TCP sender SHOULD revert to the conventional RTO "recover", revert to the conventional RTO recovery and set
recovery and it MUST set congestion window to no more than 2 * congestion window to no more than 2 * MSS, like a regular TCP
MSS, like a regular TCP would do. The sender MUST NOT enter would do. Do not enter step 3 of this algorithm.
step 3 of this algorithm.
b) else, if a cumulative ACK acknowledges a sequence number b) else, if a cumulative ACK acknowledges a sequence number
smaller than "recover" but larger than SND.UNA, the TCP sender smaller than "recover" but larger than SND.UNA, transmit up to
SHOULD transmit up to two new (previously unsent) segments and two new (previously unsent) segments and proceed to step 3. If
proceed to step 3. If the TCP sender is not able to transmit the TCP sender is not able to transmit any previously unsent
any previously unsent data due to receiver window limitation or data due to receiver window limitation or because it does not
because it does not have any new data to send, the recommended have any new data to send, the recommended action is to not
action is to not enter step 3 of this algorithm but continue enter step 3 of this algorithm but continue with slow start
with slow start retransmissions following the conventional RTO retransmissions following the conventional RTO recovery
recovery algorithm. 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 C. In this handling window limited cases discussed in Appendix C. In this
case, the TCP sender should also follow the recommendations case, the TCP sender should also follow the recommendations
concerning acknowledgments of retransmitted segments given in concerning acknowledgments of retransmitted segments given in
Appendix B. Appendix B.
3) The next acknowledgment arrives at the sender. Either duplicate 3) The next acknowledgment arrives at the sender. Either duplicate
ACK or a new cumulative ACK advancing the window applies in this ACK or a new cumulative ACK advancing the window applies in this
step. step.
a) if the ACK acknowledges sequence number above "recover", either a) if the ACK acknowledges sequence number above "recover", either
in SACK blocks or as a cumulative ACK, the sender MUST set in SACK blocks or as a cumulative ACK, set congestion window to
congestion window to no more than 3 * MSS and proceed with the no more than 3 * MSS and proceed with the conventional RTO
conventional RTO recovery, retransmitting unacknowledged recovery, retransmitting unacknowledged segments. Take this
segments. The sender SHOULD take this branch also when the branch also when the acknowledgment is a duplicate ACK and it
acknowledgment is a duplicate ACK and it does not acknowledge does not acknowledge any new, previously unacknowledged data
any new, previously unacknowledged data below "recover" in the below "recover" in the SACK blocks. Leave SpuriousRecovery set
SACK blocks. The sender leaves SpuriousRecovery set to FALSE. to FALSE.
b) if the ACK does not acknowledge sequence numbers above b) if the ACK does not acknowledge sequence numbers above
"recover" AND it acknowledges data that was not acknowledged "recover" AND it acknowledges data that was not acknowledged
earlier either with cumulative acknowledgment or using SACK earlier either with cumulative acknowledgment or using SACK
blocks, the TCP sender SHOULD declare the timeout spurious and blocks, declare the timeout spurious and set SpuriousRecovery
set SpuriousRecovery to SPUR_TO. The retransmission timeout can to SPUR_TO. The retransmission timeout can be declared
be declared spurious, because the segment acknowledged with spurious, because the segment acknowledged with this ACK was
this ACK was transmitted before the timeout. transmitted before the timeout.
If there are unacknowledged holes between the received SACK blocks, If there are unacknowledged holes between the received SACK blocks,
those segments SHOULD be retransmitted similarly to the conventional those segments are retransmitted similarly to the conventional SACK
SACK recovery algorithm [BAFW03]. If the algorithm exits with recovery algorithm [BAFW03]. If the algorithm exits with
SpuriousRecovery set to SPUR_TO, "recover" SHOULD be set to SND.UNA, SpuriousRecovery set to SPUR_TO, "recover" is set to SND.UNA, thus
thus allowing fast recovery on incoming duplicate acknowledgments. allowing fast recovery on incoming duplicate acknowledgments.
4. Taking Actions after Detecting Spurious RTO 4. Taking Actions after Detecting Spurious RTO
Upon retransmission timeout, a conventional TCP sender assumes that Upon retransmission timeout, a conventional TCP sender assumes that
outstanding segments are lost and starts retransmitting the outstanding segments are lost and starts retransmitting the
unacknowledged segments. When the retransmission timeout is detected unacknowledged segments. When the retransmission timeout is detected
to be spurious, the TCP sender should not continue retransmitting to be spurious, the TCP sender should not continue retransmitting
based on the timeout. For example, if the sender was in congestion based on the timeout. For example, if the sender was in congestion
avoidance phase transmitting new previously unsent segments, it avoidance phase transmitting new previously unsent segments, it
should continue transmitting previously unsent segments after should continue transmitting previously unsent segments after
skipping to change at page 12, line 25 skipping to change at page 12, line 23
A common case for a retransmission timeout is that a fast A common case for a retransmission timeout is that a fast
retransmission of a segment is lost. If all other segments have been retransmission of a segment is lost. If all other segments have been
received, the RTO retransmission causes the whole window to be received, the RTO retransmission causes the whole window to be
acknowledged at once. This case is recognized in F-RTO algorithm acknowledged at once. This case is recognized in F-RTO algorithm
branch (2a). However, if the receiver only acknowledges one segment branch (2a). However, if the receiver only acknowledges one segment
after receiving the RTO retransmission, and then the rest of the after receiving the RTO retransmission, and then the rest of the
segments, it could cause the timeout to be declared spurious when it segments, it could cause the timeout to be declared spurious when it
is not. Therefore, it is suggested that when an RTO expires during is not. Therefore, it is suggested that when an RTO expires during
fast recovery phase, the sender would not fully revert the congestion fast recovery phase, the sender would not fully revert the congestion
window even if the timeout was declared spurious, but reduce the window even if the timeout was declared spurious, but reduce the
congestion window to 1. However, the sender can take actions to avoid congestion window to 1.
unnecessary retransmissions normally. If a TCP sender implements a
burst avoidance algorithm that limits the sending rate to be no
higher than in slow start, this precaution is not needed, and the
sender may apply F-RTO normally.
If there are more than one segments missing at the time when a If there are more than one segments missing at the time when a
retransmission timeout occurs, the receiver does not benefit from retransmission timeout occurs, 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 then have to go through another recovery period to sender would then 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. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
skipping to change at page 20, line 35 skipping to change at page 20, line 35
When spurious timeout is detected according to the rules given above, When spurious timeout is detected according to the rules given above,
it may be possible that the response algorithm needs to consider this it may be possible that the response algorithm needs to consider this
case separately, for example in terms of what segments to retransmit case separately, for example in terms of what segments to retransmit
after RTO expires, and whether it is safe to revert the congestion after RTO expires, and whether it is safe to revert the congestion
control parameters in this case. This is considered as a topic of control parameters in this case. This is considered as a topic of
future research. future research.
Appendix C: Discussion on Window Limited Cases Appendix C: Discussion on Window Limited Cases
When the advertised window limits the transmission of two new When the advertised window limits the transmission of two new
previously unsent segments, or there are no new data to sent, it was previously unsent segments, or there are no new data to send, it was
recommended in F-RTO algorithm step (2b) that the TCP sender would recommended in F-RTO algorithm step (2b) that the TCP sender would
continue with conventional RTO recovery algorithm. The disadvantage continue with conventional RTO recovery algorithm. The disadvantage
of doing this is that the sender may continue unnecessary of doing this is that the sender may continue unnecessary
retransmissions due to possible spurious timeout. This section retransmissions due to possible spurious timeout. This section
briefly discusses the options that can potentially result in better briefly discusses the options that can potentially result in better
performance when transmitting previously unsent data is not possible. performance when transmitting previously unsent data is not possible.
- The TCP sender could reserve an unused space of a size of one or - The TCP sender could reserve an unused space of a size of one or
two segments in the advertised window to ensure the use of two segments in the advertised window to ensure the use of
algorithms such as F-RTO or Limited Transmit [ABF01] in window algorithms such as F-RTO or Limited Transmit [ABF01] in window
skipping to change at page 22, line 6 skipping to change at page 22, line 6
http://www.cs.helsinki.fi/u/sarolaht/ http://www.cs.helsinki.fi/u/sarolaht/
Markku Kojo Markku Kojo
University of Helsinki University of Helsinki
Department of Computer Science Department of Computer Science
P.O. Box 26 P.O. Box 26
FIN-00014 UNIVERSITY OF HELSINKI FIN-00014 UNIVERSITY OF HELSINKI
Finland Finland
Phone: +358 9 1914 4179 Phone: +358 9 1914 4179
EMail: markku.kojo@cs.helsinki.fi EMail: markku.kojo@cs.helsinki.fi
IPR Disclosure Agreement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/