Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)
RFC 4138
| Document | Type |
RFC - Experimental
(August 2005; No errata)
Updated by RFC 5682
Was draft-ietf-tcpm-frto (tcpm WG)
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Replaces | draft-ietf-tsvwg-tcp-frto | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4138 (Experimental) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Jon Peterson | ||
| Send notices to | faber@isi.edu, mallman@icir.org | ||
Network Working Group P. Sarolahti
Request for Comments: 4138 Nokia Research Center
Category: Experimental M. Kojo
University of Helsinki
August 2005
Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
Spurious Retransmission Timeouts with TCP and the
Stream Control Transmission Protocol (SCTP)
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Spurious retransmission timeouts cause suboptimal TCP performance
because they often result in unnecessary retransmission of the last
window of data. This document describes the F-RTO detection
algorithm for detecting spurious TCP retransmission timeouts. F-RTO
is a TCP sender-only algorithm that does not require any TCP options
to operate. After retransmitting the first unacknowledged segment
triggered by a timeout, the F-RTO algorithm of the TCP sender
monitors the incoming acknowledgments to determine whether the
timeout was spurious. It then decides whether to send new segments
or retransmit unacknowledged segments. The algorithm effectively
helps to avoid additional unnecessary retransmissions and thereby
improves TCP performance in the case of a spurious timeout. The
F-RTO algorithm can also be applied to the Stream Control
Transmission Protocol (SCTP).
Sarolahti & Kojo Experimental [Page 1]
RFC 4138 Forward RTO-Recovery August 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . 4
2. F-RTO Algorithm . . . . . . . . . . . . . . . . . . . . . 4
2.1. The Algorithm . . . . . . . . . . . . . . . . . . . 5
2.2. Discussion . . . . . . . . . . . . . . . . . . . . 6
3. SACK-Enhanced Version of the F-RTO Algorithm . . . . . . 8
4. Taking Actions after Detecting Spurious RTO . . . . . . . 10
5. SCTP Considerations . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References. . . . . . . . . . . . . . . . 12
8.2. Informative References. . . . . . . . . . . . . . . 13
Appendix A: Scenarios . . . . . . . . . . . . . . . . . . . . 15
Appendix B: SACK-Enhanced F-RTO and Fast Recovery . . . . . . 20
Appendix C: Discussion of Window-Limited Cases . . . . . . . 21
1. Introduction
The Transmission Control Protocol (TCP) [Pos81] has two methods for
triggering retransmissions. First, the TCP sender relies on incoming
duplicate ACKs, which indicate that the receiver is missing some of
the data. After a required number of successive duplicate ACKs have
arrived at the sender, it retransmits the first unacknowledged
segment [APS99] and continues with a loss recovery algorithm such as
NewReno [FHG04] or SACK-based loss recovery [BAFW03]. Second, the
TCP sender maintains a retransmission timer which triggers
retransmission of segments, if they have not been acknowledged before
the retransmission timeout (RTO) expires. When the retransmission
timeout occurs, the TCP sender enters the RTO recovery where the
congestion window is initialized to one segment and unacknowledged
segments are retransmitted using the slow-start algorithm. The
retransmission timer is adjusted dynamically, based on the measured
round-trip times [PA00].
It has been pointed out that the retransmission timer can expire
spuriously and cause unnecessary retransmissions when no segments
have been lost [LK00, GL02, LM03]. After a spurious retransmission
timeout, the late acknowledgments of the original segments arrive at
the sender, usually triggering unnecessary retransmissions of a whole
window of segments during the RTO recovery. Furthermore, after a
spurious retransmission timeout, a conventional TCP sender increases
the congestion window on each late acknowledgment in slow start.
This injects a large number of data segments into the network within
one round-trip time, thus violating the packet conservation principle
[Jac88].
Show full document text