Cite this RFC:TXT | XML | BibTeX
DOI: https://doi.org/10.17487/RFC5682
Discuss this RFC: Send questions or comments to the mailing listtcpm@ietf.org
Other actions:Submit Errata | Find IPR Disclosures from the IETF | View History of RFC 5682
The purpose of this document is to move the F-RTO (ForwardRTO-Recovery) functionality for TCP in RFC 4138 fromExperimental to Standards Track status. The F-RTO support for StreamControl Transmission Protocol (SCTP) in RFC 4138 remains withExperimental status. See Appendix B for the differences between thisdocument and RFC 4138.
Spurious retransmission timeouts cause suboptimal TCP performancebecause they often result in unnecessary retransmission of the lastwindow of data. This document describes the F-RTO detectionalgorithm for detecting spurious TCP retransmission timeouts. F-RTOis a TCP sender-only algorithm that does not require any TCP optionsto operate. After retransmitting the first unacknowledged segmenttriggered by a timeout, the F-RTO algorithm of the TCP sendermonitors the incoming acknowledgments to determine whether thetimeout was spurious. It then decides whether to send new segmentsor retransmit unacknowledged segments. The algorithm effectivelyhelps to avoid additional unnecessary retransmissions and therebyimproves TCP performance in the case of a spurious timeout. [STANDARDS-TRACK]
For the definition ofStatus,seeRFC 2026.
For the definition ofStream, seeRFC 8729.