draft-ietf-tcpm-rfc4138bis-02.txt   draft-ietf-tcpm-rfc4138bis-03.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-02.txt M. Kojo draft-ietf-tcpm-rfc4138bis-03.txt M. Kojo
Expires: January 2009 University of Helsinki Intended status: Proposed Standard University of Helsinki
K. Yamamoto Expires: March 2009 K. Yamamoto
M. Hata M. Hata
NTT Docomo NTT Docomo
9 September 2008
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 35 skipping to change at page 1, line 38
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 January 2009. This Internet-Draft will expire on March 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 17 skipping to change at page 3, line 17
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 . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8
3. SACK-Enhanced Version of the F-RTO Algorithm. . . . . . . . . 10 3. SACK-Enhanced Version of the F-RTO Algorithm. . . . . . . . . 10
4. Taking Actions after Detecting Spurious RTO . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 15
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
A. Discussion of Window-Limited Cases. . . . . . . . . . . . . . 15 A. Discussion of Window-Limited Cases. . . . . . . . . . . . . . 15
B. List of Changes . . . . . . . . . . . . . . . . . . . . . . . 16 B. List of Changes . . . . . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Normative References . . . . . . . . . . . . . . . . . . . . . . 17 Normative References . . . . . . . . . . . . . . . . . . . . . . 17
Informative References . . . . . . . . . . . . . . . . . . . . . 17 Informative References . . . . . . . . . . . . . . . . . . . . . 17
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 19 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 5, line 17 skipping to change at page 5, line 18
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 the 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) [Ste07] 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.
1.1. Conventions and Terminology 1.1. Conventions and Terminology
skipping to change at page 6, line 28 skipping to change at page 6, line 30
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 a 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 [APB08]. 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. If the TCP sender is already in set SpuriousRecovery to FALSE. If the TCP sender is already in
RTO recovery AND "recover" is larger then SND.UNA (the oldest RTO recovery AND "recover" is larger than or equal to SND.UNA
unacknowledged sequence number [Pos81]), do not enter step 2 of (the oldest unacknowledged sequence number [Pos81]), do not enter
this algorithm. Instead, store the highest sequence number step 2 of this algorithm. Instead, store the highest sequence
transmitted so far in variable "recover" and continue with slow number transmitted so far in variable "recover" and continue with
start retransmissions following the conventional RTO recovery slow start retransmissions following the conventional RTO
algorithm. 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, store the highest sequence number arrives at the TCP sender, store the highest sequence number
transmitted so far in variable "recover". The TCP sender chooses transmitted so far in variable "recover". The TCP sender chooses
one of the following actions, depending on whether the ACK one of the following actions, depending on whether the ACK
advances the window or whether it is a duplicate 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
skipping to change at page 10, line 30 skipping to change at page 10, line 30
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. Following the recommendation and set SpuriousRecovery to FALSE. Following the recommendation
in SACK specification [MMFR96], reset the SACK scoreboard. If in SACK specification [MMFR96], reset the SACK scoreboard. If
"RecoveryPoint" is larger than SND.UNA, do not enter step 2 of "RecoveryPoint" is larger than or equal to SND.UNA, do not enter
this algorithm. Instead, set variable "RecoveryPoint" to step 2 of this algorithm. Instead, set variable "RecoveryPoint"
indicate the highest sequence number transmitted so far and to indicate the highest sequence number transmitted so far and
continue with slow start retransmissions following the continue with slow start retransmissions following the
conventional RTO recovery algorithm. 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. When a new expires again, go to step 1 of the algorithm. When a new
acknowledgment arrives, set variable "RecoveryPoint" to indicate acknowledgment arrives, set variable "RecoveryPoint" to indicate
skipping to change at page 14, line 42 skipping to change at page 14, line 42
the fast recovery phase, the sender would not fully revert the the fast recovery phase, the sender would not fully revert the
congestion window even if the timeout was declared spurious. congestion window even if the timeout was declared spurious.
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. IANA Considerations
This document has no actions for IANA.
8. Acknowledgements
The authors would like to thank Alfred Hoenes, Ilpo Jarvinen and The authors would like to thank Alfred Hoenes, Ilpo Jarvinen and
Murari Sridharan for 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.
skipping to change at page 16, line 16 skipping to change at page 16, line 25
- 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 from RFC 4138 are summarized below, apart from minor editing
apart from minor editing and language improvements. and language improvements.
Changes from draft-ietf-tcpm-rfc4138bis-01:
* Modified the basic F-RTO algorithm and SACK-enhanced F-RTO * Modified the basic F-RTO algorithm and SACK-enhanced F-RTO
algorithm to prevent the TCP sender from applying F-RTO algorithm if algorithm to prevent the TCP sender from applying F-RTO algorithm if
retransmission timer expires when an earlier RTO recovery is retransmission timer expires when an earlier RTO recovery is
underway, except when RTO expires multiple times for the same underway, except when RTO expires multiple times for the same
segment. segment.
Changes from draft-ietf-tcpm-rfc4138bis-00:
* Added back the original SACK-algorithm from RFC 4138 after the
common feedback to have the SACK-algorithm in the document.
Clarified the algorithm a bit, and added one paragraph of
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
data but are not duplicate acknowledgements data but are not duplicate acknowledgements
Changes from RFC 4138: * Clarified the SACK-algorithm a bit, and added one paragraph of
description of the basic idea of the algorithm.
* Removed description of the SACK-enhanced algorithm
* Removed SCTP considerations * Removed SCTP considerations
* Removed earlier Appendix sections, except Appendix C from RFC * Removed earlier Appendix sections, except Appendix C from RFC
4138, which is now Appendix A 4138, which is now Appendix A
* Clarified text about the possible response algorithms * Clarified text about the possible response algorithms
* Added section that summarizes the evaluation of RFC 4138 * Added section that summarizes the evaluation of RFC 4138
References References
Normative References Normative References
[APS99] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion [APS99] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999. Control", RFC 2581, April 1999.
[APB07] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [APB08] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", Internet-Draft "draft-ietf-tcpm- Control", Internet-Draft "draft-ietf-tcpm-
rfc2581bis-03.txt", rfc2581bis-04.txt",
September 2007. April 2008.
[BAFW03] Blanton, E., Allman, M., Fall, K., and L. Wang, "A [BAFW03] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
Conservative Selective Acknowledgment (SACK)-based Loss Conservative Selective Acknowledgment (SACK)-based Loss
Recovery Algorithm for TCP", RFC 3517, April 2003. Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[FHG04] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno [FHG04] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
Modification to TCP's Fast Recovery Algorithm", RFC 3782, Modification to TCP's Fast Recovery Algorithm", RFC 3782,
skipping to change at page 18, line 7 skipping to change at page 17, line 50
[ABF01] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing [ABF01] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
TCP's Loss Recovery Using Limited Transmit", RFC 3042, TCP's Loss Recovery Using Limited Transmit", RFC 3042,
January 2001. January 2001.
[BA04] Blanton, E. and M. Allman, "Using TCP Duplicate Selective [BA04] Blanton, E. and M. Allman, "Using TCP Duplicate Selective
Acknowledgement (DSACKs) and Stream Control Transmission Acknowledgement (DSACKs) and Stream Control Transmission
Protocol (SCTP) Duplicate Transmission Sequence Numbers Protocol (SCTP) Duplicate Transmission Sequence Numbers
(TSNs) to Detect Spurious Retransmissions", RFC 3708, (TSNs) to Detect Spurious Retransmissions", RFC 3708,
February 2004. February 2004.
[BBA06] J. Blanton, E. Blanton, and M. Allman. Using Spurious [BBA06] Blanton, J., Blanton, E., and M. Allman, "Using Spurious
Retransmissions to Adapt the Retransmission Timeout, Retransmissions to Adapt the Retransmission Timeout",
Internet-Draft "draft-allman-rto-backoff-04.txt", December Internet-Draft "draft-allman-rto-backoff-04.txt", December
2006. Work in progress. 2006. Work in progress.
[BBJ92] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions [BBJ92] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, May 1992.
[FMMP00] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An [FMMP00] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option Extension to the Selective Acknowledgement (SACK) Option
for TCP", RFC 2883, July 2000. for TCP", RFC 2883, July 2000.
[GL02] A. Gurtov and R. Ludwig. Evaluating the Eifel Algorithm [GL02] Gurtov A. and R. Ludwig, "Evaluating the Eifel Algorithm
for TCP in a GPRS Network. In Proc. of European Wireless, for TCP in a GPRS Network", In Proc. European Wireless,
Florence, Italy, February 2002. Florence, Italy, February 2002.
[GL03] A. Gurtov and R. Ludwig, Responding to Spurious Timeouts [GL03] Gurtov A. and R. Ludwig, "Responding to Spurious Timeouts
in TCP. In Proceedings of IEEE INFOCOM 03, San Francisco, in TCP", In Proc. IEEE INFOCOM 03, San Francisco, CA, USA,
CA, USA, March 2003. March 2003.
[Jac88] V. Jacobson. Congestion Avoidance and Control. In [Jac88] Jacobson, V., "Congestion Avoidance and Control", In
Proceedings of ACM SIGCOMM 88. Proc. ACM SIGCOMM 88.
[Hok05] A. Hokamura, et al. "Performance Evaluation of F-RTO and [Hok05] Hokamura, A., et al., "Performance Evaluation of F-RTO and
Eifel Response Algorithms over W-CDMA packet network". Eifel Response Algorithms over W-CDMA packet network", In
Wireless Personal Multimedia Communications (WPMC'05), Proc. Wireless Personal Multimedia Communications
(WPMC'05),
Sept. 2005. Sept. 2005.
[KYHS07] M. Kojo, K. Yamamoto, M. Hata, and P. Sarolahti. [KYHS07] Kojo, M., Yamamoto, K., Hata, M., and P. Sarolahti,
Evaluation of RFC 4138. Internet-draft "Evaluation of RFC 4138", Internet-draft
"draft-kojo-tcpm-frto-eval-00.txt", June 2007. Work "draft-kojo-tcpm-frto-eval-00.txt", 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] Ludwig R. 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.
[Nag84] Nagle, J., "Congestion Control in IP/TCP Internetworks", [Nag84] Nagle, J., "Congestion Control in IP/TCP Internetworks",
RFC 896, January 1984. RFC 896, January 1984.
[SK05] P. Sarolahti and M. Kojo, "Forward RTO-Recovery (F-RTO): [SK05] Sarolahti, P. and M. Kojo, "Forward RTO-Recovery (F-RTO):
An Algorithm for Detecting Spurious Retransmission An Algorithm for Detecting Spurious Retransmission
Timeouts with TCP and the Stream Control Transmission Timeouts with TCP and the Stream Control Transmission
Protocol (SCTP), RFC 4138, August 2005. Protocol (SCTP)", RFC 4138, August 2005.
[SKR03] P. Sarolahti, M. Kojo, and K. Raatikainen. F-RTO: An [SKR03] Sarolahti, P., Kojo, M., and K. Raatikainen, "F-RTO: An
Enhanced Recovery Algorithm for TCP Retransmission Enhanced Recovery Algorithm for TCP Retransmission
Timeouts. ACM SIGCOMM Computer Communication Review, Timeouts", ACM SIGCOMM Computer Communication Review,
33(2), April 2003. 33(2), April 2003.
[Sar03] P. Sarolahti. Congestion Control on Spurious TCP [Sar03] P. Sarolahti, P., "Congestion Control on Spurious TCP
Retransmission Timeouts. In Proceedings of IEEE Globecom Retransmission Timeouts", In Proc. of IEEE Globecom
2003, San Francisco, CA, USA. December 2003. 2003, San Francisco, CA, USA. December 2003.
[SL03] Y. Swami and K. Le, "DCLOR: De-correlated Loss Recovery [SL03] Swami Y. and K. Le, "DCLOR: De-correlated Loss Recovery
using SACK Option for Spurious Timeouts", Expired using SACK Option for Spurious Timeouts", Expired
Internet-Draft, September 2003. Internet-Draft, September 2003.
[Ste00] R. Stewart, et. al. Stream Control Transmission Protocol, [Ste07] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 2960, October 2000. RFC 4960, September 2007.
[Yam05] K. Yamamoto, et al. "Effects of F-RTO and Eifel Response [Yam05] Yamamoto, K., et al., "Effects of F-RTO and Eifel Response
Algorithms for W-CDMA and HSDPA networks". Wireless Algorithms for W-CDMA and HSDPA networks", In Proc.
Personal Multimedia Communications (WPMC'05), Wireless
Sept. 2005. Personal Multimedia Communications (WPMC'05), September
2005.
AUTHORS' ADDRESSES AUTHORS' ADDRESSES
Pasi Sarolahti Pasi Sarolahti
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FI-00045 NOKIA GROUP FI-00045 NOKIA GROUP
Finland Finland
Phone: +358 50 4876607 Phone: +358 50 4876607
Email: pasi.sarolahti@nokia.com Email: pasi.sarolahti@nokia.com
skipping to change at page 21, line 7 skipping to change at page 21, line 7
Email: yamamotokaz@nttdocomo.co.jp Email: yamamotokaz@nttdocomo.co.jp
Max Hata Max Hata
NTT Docomo, Inc. NTT Docomo, Inc.
3-5 Hikarinooka, Yokosuka, Kanagawa, 239-8536, Japan 3-5 Hikarinooka, Yokosuka, Kanagawa, 239-8536, Japan
Phone: +81-46-840-3812 Phone: +81-46-840-3812
Email: hatama@s1.nttdocomo.co.jp Email: hatama@s1.nttdocomo.co.jp
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
 End of changes. 31 change blocks. 
64 lines changed or deleted 65 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/