{"draft":"draft-ietf-tcpm-rfc4138bis-04","doc_id":"RFC5682","title":"Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP","authors":["P. Sarolahti","M. Kojo","K. Yamamoto","M. Hata"],"format":["ASCII","HTML"],"page_count":"19","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"TCP Maintenance and Minor Extensions","abstract":"The purpose of this document is to move the F-RTO (Forward\r\nRTO-Recovery) functionality for TCP in RFC 4138 from\r\nExperimental to Standards Track status.  The F-RTO support for Stream\r\nControl Transmission Protocol (SCTP) in RFC 4138 remains with\r\nExperimental status.  See Appendix B for the differences between this\r\ndocument and RFC 4138.\r\n\r\nSpurious retransmission timeouts cause suboptimal TCP performance\r\nbecause they often result in unnecessary retransmission of the last\r\nwindow of data.  This document describes the F-RTO detection\r\nalgorithm for detecting spurious TCP retransmission timeouts.  F-RTO\r\nis a TCP sender-only algorithm that does not require any TCP options\r\nto operate.  After retransmitting the first unacknowledged segment\r\ntriggered by a timeout, the F-RTO algorithm of the TCP sender\r\nmonitors the incoming acknowledgments to determine whether the\r\ntimeout was spurious.  It then decides whether to send new segments\r\nor retransmit unacknowledged segments.  The algorithm effectively\r\nhelps to avoid additional unnecessary retransmissions and thereby\r\nimproves TCP performance in the case of a spurious timeout.  [STANDARDS-TRACK]","pub_date":"September 2009","keywords":["[--------]","SACK","transmission control protocol","loss recovery"],"obsoletes":[],"obsoleted_by":[],"updates":["RFC4138"],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC5682","errata_url":null}