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)
|
|
---|---|---|---|
Authors | Markku Kojo , Pasi Sarolahti | ||
Last updated | 2013-03-02 | ||
Replaces | draft-ietf-tsvwg-tcp-frto | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4138 (Experimental) | |
Action Holders |
(None)
|
||
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]. Sarolahti & Kojo Experimental [Page 2] RFC 4138 Forward RTO-Recovery August 2005 There are a number of potential reasons for spurious retransmissionShow full document text