Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)
RFC 4138

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

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 retransmission