draft-ietf-tcpm-rfc4138bis-04.txt   rfc5682.txt 
Internet Engineering Task Force P. Sarolahti
INTERNET-DRAFT Nokia Research Center
draft-ietf-tcpm-rfc4138bis-04.txt M. Kojo
Intended status: Proposed Standard University of Helsinki
Updates: 4138 K. Yamamoto
Expires: April 2009 M. Hata
NTT Docomo
30 October 2008 Network Working Group P. Sarolahti
Request for Comments: 5682 Nokia Research Center
Updates: 4138 M. Kojo
Category: Standards Track University of Helsinki
K. Yamamoto
M. Hata
NTT Docomo
September 2009
Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
Spurious Retransmission Timeouts with TCP Spurious Retransmission Timeouts with TCP
Status of this Memo Abstract
By submitting this Internet-Draft, each author represents that any The purpose of this document is to move the F-RTO (Forward
applicable patent or other IPR claims of which he or she is aware RTO-Recovery) functionality for TCP in RFC 4138 from
have been or will be disclosed, and any of which he or she becomes Experimental to Standards Track status. The F-RTO support for Stream
aware will be disclosed, in accordance with Section 6 of BCP 79. Control Transmission Protocol (SCTP) in RFC 4138 remains with
Experimental status. See Appendix B for the differences between this
document and RFC 4138.
Internet-Drafts are working documents of the Internet Engineering Spurious retransmission timeouts cause suboptimal TCP performance
Task Force (IETF), its areas, and its working groups. Note that because they often result in unnecessary retransmission of the last
other groups may also distribute working documents as Internet- window of data. This document describes the F-RTO detection
Drafts. 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.
Internet-Drafts are draft documents valid for a maximum of six Status of This Memo
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/ietf/1id-abstracts.txt. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at RFC 5682 F-RTO September 2009
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 2009. Copyright and License Notice
Abstract Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
The purpose of this document is to move the F-RTO functionality for This document is subject to BCP 78 and the IETF Trust's Legal
TCP in RFC 4138 from Experimental to Standards Track status. The F- Provisions Relating to IETF Documents
RTO support for SCTP in RFC 4138 remains with Experimental status. (http://trustee.ietf.org/license-info) in effect on the date of
See Appendix B for the differences between this document and RFC publication of this document. Please review these documents
4138. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Spurious retransmission timeouts cause suboptimal TCP performance Table of Contents
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.
Table of Contents 1. Introduction ....................................................3
1.1. Conventions and Terminology ................................5
2. Basic F-RTO Algorithm ...........................................5
2.1. The Algorithm ..............................................5
2.2. Discussion .................................................7
3. SACK-Enhanced Version of the F-RTO Algorithm ....................9
3.1. The Algorithm ..............................................9
3.2. Discussion ................................................11
4. Taking Actions after Detecting Spurious RTO ....................11
5. Evaluation of RFC 4138 .........................................12
6. Security Considerations ........................................13
7. Acknowledgments ................................................14
Appendix A. Discussion of Window-Limited Cases ....................15
Appendix B. Changes since RFC 4138 ................................16
References ........................................................16
Normative References ...........................................16
Informative References .........................................17
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 RFC 5682 F-RTO September 2009
1.1. Conventions and Terminology. . . . . . . . . . . . . . . 5
2. Basic F-RTO Algorithm . . . . . . . . . . . . . . . . . . . . 5
2.1. The Algorithm. . . . . . . . . . . . . . . . . . . . . . 6
2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8
3. SACK-Enhanced Version of the F-RTO Algorithm. . . . . . . . . 10
3.1. The Algorithm. . . . . . . . . . . . . . . . . . . . . . 10
3.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 12
4. Taking Actions after Detecting Spurious RTO . . . . . . . . . 12
5. Evaluation of RFC 4138. . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 15
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
A. Discussion of Window-Limited Cases. . . . . . . . . . . . . . 15
B. Changes since RFC 4138. . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Normative References . . . . . . . . . . . . . . . . . . . . . . 17
Informative References . . . . . . . . . . . . . . . . . . . . . 17
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The Transmission Control Protocol (TCP) [Pos81] has two methods for The Transmission Control Protocol (TCP) [Pos81] has two methods for
triggering retransmissions. First, the TCP sender relies on triggering retransmissions. First, the TCP sender relies on incoming
incoming duplicate ACKs, which indicate that the receiver is missing duplicate acknowledgments (ACKs), which indicate that the receiver is
some of the data. After a required number of successive duplicate missing some of the data. After a required number of successive
ACKs have arrived at the sender, it retransmits the first duplicate ACKs have arrived at the sender, it retransmits the first
unacknowledged segment [APS99] and continues with a loss recovery unacknowledged segment [APB09] and continues with a loss recovery
algorithm such as NewReno [FHG04] or SACK-based loss recovery algorithm such as NewReno [FHG04] or SACK-based (Selective
[BAFW03]. Second, the TCP sender maintains a retransmission timer Acknowledgment) loss recovery [BAFW03]. Second, the TCP sender
which triggers retransmission of segments, if they have not been maintains a retransmission timer that triggers retransmission of
acknowledged before the retransmission timeout (RTO) occurs. When segments, if they have not been acknowledged before the
the retransmission timeout occurs, the TCP sender enters the RTO retransmission timeout (RTO) occurs. When the retransmission timeout
recovery where the congestion window is initialized to one segment occurs, the TCP sender enters the RTO recovery where the congestion
and unacknowledged segments are retransmitted using the slow-start window is initialized to one segment and unacknowledged segments are
algorithm. The retransmission timer is adjusted dynamically, based retransmitted using the slow-start algorithm. The retransmission
on the measured round-trip times [PA00]. timer is adjusted dynamically, based on the measured round-trip times
[PA00].
It has been pointed out that the retransmission timer can expire It has been pointed out that the retransmission timer can expire
spuriously and cause unnecessary retransmissions when no segments spuriously and cause unnecessary retransmissions when no segments
have been lost [LK00, GL02, LM03]. After a spurious retransmission have been lost [LK00, GL02, LM03]. After a spurious retransmission
timeout, the late acknowledgments of the original segments arrive at timeout, the late acknowledgments of the original segments arrive at
the sender, usually triggering unnecessary retransmissions of a the sender, usually triggering unnecessary retransmissions of a whole
whole window of segments during the RTO recovery. Furthermore, window of segments during the RTO recovery. Furthermore, after a
after a spurious retransmission timeout, a conventional TCP sender spurious retransmission timeout, a conventional TCP sender increases
increases the congestion window on each late acknowledgment in slow the congestion window on each late acknowledgment in slow start.
start. This injects a large number of data segments into the This injects a large number of data segments into the network within
network within one round-trip time, thus violating the packet one round-trip time, thus violating the packet conservation principle
conservation principle [Jac88]. [Jac88].
There are a number of potential reasons for spurious retransmission There are a number of potential reasons for spurious retransmission
timeouts. First, some mobile networking technologies involve sudden timeouts. First, some mobile networking technologies involve sudden
delay spikes on transmission because of actions taken during a hand- delay spikes on transmission because of actions taken during a hand-
off. Second, a hand-off may take place from a low latency path to a off. Second, a hand-off may take place from a low latency path to a
high latency path, suddenly increasing the round-trip time beyond high latency path, suddenly increasing the round-trip time beyond the
the current RTO value. Third, on a low-bandwidth link the arrival current RTO value. Third, on a low-bandwidth link the arrival of
of competing traffic (possibly with higher priority), or some other competing traffic (possibly with higher priority), or some other
change in available bandwidth, can cause a sudden increase of the change in available bandwidth, can cause a sudden increase of the
round-trip time. This may trigger a spurious retransmission round-trip time. This may trigger a spurious retransmission timeout.
timeout. A persistently reliable link layer can also cause a sudden A persistently reliable link layer can also cause a sudden delay when
delay when a data frame and several retransmissions of it are lost a data frame and several retransmissions of it are lost for some
for some reason. This document does not distinguish between the reason. This document does not distinguish between the different
different causes of such a delay spike. Rather, it discusses the causes of such a delay spike. Rather, it discusses the spurious
spurious retransmission timeouts caused by a delay spike in general. retransmission timeouts caused by a delay spike in general.
This document describes the F-RTO detection algorithm for TCP. It is RFC 5682 F-RTO September 2009
based on the detection mechanism of the "Forward RTO-Recovery" (F-
RTO) algorithm [SKR03] that is used for detecting spurious
retransmission timeouts and thus avoids unnecessary retransmissions
following the retransmission timeout. When the timeout is not
spurious, the F-RTO algorithm reverts back to the conventional RTO
recovery algorithm, and therefore has similar behavior and
performance. In contrast to alternative algorithms proposed for
detecting unnecessary retransmissions (Eifel [LK00], [LM03] and
DSACK-based algorithms [BA04]), F-RTO does not require any TCP
options for its operation, and it can be implemented by modifying
only the TCP sender. The Eifel algorithm uses TCP timestamps
[BBJ92] for detecting a spurious timeout upon arrival of the first
acknowledgment after the retransmission. The DSACK-based algorithms
require that the TCP Selective Acknowledgment Option [MMFR96], with
the DSACK extension [FMMP00], is in use. With DSACK, the TCP
receiver can report if it has received a duplicate segment, enabling
the sender to detect afterwards whether it has retransmitted
segments unnecessarily. The F-RTO algorithm only attempts to detect
and avoid unnecessary retransmissions after an RTO. Eifel and DSACK
can also be used for detecting unnecessary retransmissions caused by
other events, such as packet reordering.
When the retransmission timer expires, the F-RTO sender retransmits This document describes the F-RTO detection algorithm for TCP. It is
the first unacknowledged segment as usual [APS99]. Deviating from based on the detection mechanism of the "Forward RTO-Recovery"
the normal operation after a timeout, it then tries to transmit new, (F-RTO) algorithm [SKR03] that is used for detecting spurious
previously unsent data for the first acknowledgment that arrives retransmission timeouts and thus avoids unnecessary retransmissions
after the timeout, given that the acknowledgment advances the following the retransmission timeout. When the timeout is not
window. If the second acknowledgment that arrives after the timeout spurious, the F-RTO algorithm reverts back to the conventional RTO
advances the window (i.e., acknowledges data that was not recovery algorithm, and therefore has similar behavior and
retransmitted), the F-RTO sender declares the timeout spurious and performance. In contrast to alternative algorithms proposed for
exits the RTO recovery. However, if either of these two detecting unnecessary retransmissions (Eifel [LK00, LM03] and DSACK-
acknowledgments is a duplicate ACK, there will not be sufficient based (Duplicate SACK) algorithms [BA04]), F-RTO does not require any
evidence of a spurious timeout. Therefore, the F-RTO sender TCP options for its operation, and it can be implemented by modifying
retransmits the unacknowledged segments in slow start similarly to only the TCP sender. The Eifel algorithm uses TCP timestamps [BBJ92]
the traditional algorithm. With a SACK-enhanced version of the F-RTO for detecting a spurious timeout upon arrival of the first
algorithm, spurious timeouts may be detected even if duplicate ACKs acknowledgment after the retransmission. The DSACK-based algorithms
arrive after an RTO retransmission. require that the TCP Selective Acknowledgment Option [MMFR96], with
the DSACK extension [FMMP00], is in use. With DSACK, the TCP
receiver can report if it has received a duplicate segment, enabling
the sender to detect afterwards whether it has retransmitted segments
unnecessarily. The F-RTO algorithm only attempts to detect and avoid
unnecessary retransmissions after an RTO. Eifel and DSACK can also
be used for detecting unnecessary retransmissions caused by other
events, such as packet reordering.
This document specifies the F-RTO algorithm for TCP only, replacing When the retransmission timer expires, the F-RTO sender retransmits
the F-RTO functionality with TCP in RFC 4138 [SK05] and moving it the first unacknowledged segment as usual [APB09]. Deviating from
from Experimental to Standards Track status. The algorithm can also the normal operation after a timeout, it then tries to transmit new,
be applied to the Stream Control Transmission Protocol (SCTP) previously unsent data for the first acknowledgment that arrives
[Ste07] that has acknowledgment and packet retransmission concepts after the timeout, given that the acknowledgment advances the window.
similar to TCP. The considerations on applying F-RTO to SCTP are If the second acknowledgment that arrives after the timeout advances
discussed in RFC 4138, but the F-RTO support for SCTP remains with the window (i.e., acknowledges data that was not retransmitted), the
Experimental status. F-RTO sender declares the timeout spurious and exits the RTO
recovery. However, if either of these two acknowledgments is a
duplicate ACK, there will not be sufficient evidence of a spurious
timeout. Therefore, the F-RTO sender retransmits the unacknowledged
segments in slow start similar to the traditional algorithm. With a
SACK-enhanced version of the F-RTO algorithm, spurious timeouts may
be detected even if duplicate ACKs arrive after an RTO
retransmission.
This document is organized as follows. Section 2 describes the basic This document specifies the F-RTO algorithm for TCP only, replacing
F-RTO algorithm, and the SACK-enhanced F-RTO algorithm is given in the F-RTO functionality with TCP in RFC 4138 [SK05] and moving it
Section 3. Section 4 discusses the possible actions to be taken from Experimental to Standards Track status. The algorithm can also
after detecting a spurious RTO and Section 5 discusses the security be applied to the Stream Control Transmission Protocol (SCTP) [Ste07]
considerations. that has acknowledgment and packet retransmission concepts similar to
TCP. The considerations on applying F-RTO to SCTP are discussed in
RFC 4138, but the F-RTO support for SCTP remains with Experimental
status.
RFC 5682 F-RTO September 2009
This document is organized as follows. Section 2 describes the basic
F-RTO algorithm, and the SACK-enhanced F-RTO algorithm is given in
Section 3. Section 4 discusses the possible actions to be taken
after detecting a spurious RTO. Section 5 summarizes the experience
with F-RTO implementations and the experimental results, and Section
6 discusses the security considerations.
1.1. Conventions and Terminology 1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for protocols. [RFC2119] and indicate requirement levels for protocols.
2. Basic F-RTO Algorithm 2. Basic F-RTO Algorithm
A timeout is considered spurious if it would have been avoided had A timeout is considered spurious if it would have been avoided had
the sender waited longer for an acknowledgment to arrive [LM03]. F- the sender waited longer for an acknowledgment to arrive [LM03].
RTO affects the TCP sender behavior only after a retransmission F-RTO affects the TCP sender behavior only after a retransmission
timeout. Otherwise, the TCP behavior remains the same. When the timeout. Otherwise, the TCP behavior remains the same. When the
retransmission timer expires, the F-RTO algorithm monitors incoming retransmission timer expires, the F-RTO algorithm monitors incoming
acknowledgments and if the TCP sender gets an acknowledgment for a acknowledgments, and if the TCP sender gets an acknowledgment for a
segment that was not retransmitted due to the timeout, the F-RTO segment that was not retransmitted due to the timeout, the F-RTO
algorithm declares a timeout spurious. The actions taken in response algorithm declares a timeout spurious. The actions taken in response
to a spurious timeout are not specified in this document, but we to a spurious timeout are not specified in this document, but we
discuss some alternatives in Section 4. This section introduces the discuss some alternatives in Section 4. This section introduces the
algorithm and then discusses the different steps of the algorithm in algorithm and then discusses the different steps of the algorithm in
more detail. more detail.
Following the practice used with the Eifel Detection algorithm Following the practice used with the Eifel Detection algorithm
[LM03], we use the "SpuriousRecovery" variable to indicate whether [LM03], we use the "SpuriousRecovery" variable to indicate whether
the retransmission is declared spurious by the sender. This variable the retransmission is declared spurious by the sender. This variable
can be used as an input for a corresponding response algorithm. With can be used as an input for a corresponding response algorithm. With
F-RTO, the value of SpuriousRecovery can be either SPUR_TO F-RTO, the value of SpuriousRecovery can be either SPUR_TO
(indicating a spurious retransmission timeout) or FALSE (indicating (indicating a spurious retransmission timeout) or FALSE (indicating
that the timeout is not declared spurious and the TCP sender should that the timeout is not declared spurious and the TCP sender should
follow the conventional RTO recovery algorithm). In addition, we use follow the conventional RTO recovery algorithm). In addition, we use
the "recover" variable specified in the NewReno algorithm [FHG04]. the "recover" variable specified in the NewReno algorithm [FHG04].
2.1. The Algorithm 2.1. The Algorithm
A TCP sender implementing the basic F-RTO algorithm MUST take the A TCP sender implementing the basic F-RTO algorithm MUST take the
following steps after the retransmission timer expires. If the following steps after the retransmission timer expires. If the
retransmission timer expires again during the execution of the F-RTO retransmission timer expires again during the execution of the F-RTO
algorithm, the TCP sender MUST re-start the algorithm processing algorithm, the TCP sender MUST re-start the algorithm processing from
from step 1. If the sender implements some loss recovery algorithm step 1. If the sender implements some loss recovery algorithm other
other than Reno or NewReno [FHG04], the F-RTO algorithm SHOULD NOT than Reno or NewReno [FHG04], the F-RTO algorithm SHOULD NOT be
be entered when earlier fast recovery is underway. entered when earlier fast recovery is underway.
The F-RTO algorithm takes different actions based on whether an RFC 5682 F-RTO September 2009
incoming acknowledgement advances the cumulative acknowledgement
point for a received in-order segment, or whether it is a duplicate
acknowledgement to indicate an out-of-order segment. Duplicate
acknowledgement is defined in [APB08]. The F-RTO algorithm does not
specify actions for receiving a segment that neither acknowledges
new data nor is a duplicate acknowledgement. The TCP sender SHOULD
ignore such segments and wait for a segment that either acknowledges
new data or is a duplicate acknowledgment.
1) When the retransmission timer expires, retransmit the first The F-RTO algorithm takes different actions based on whether an
unacknowledged segment and set SpuriousRecovery to FALSE. If the incoming acknowledgment advances the cumulative acknowledgment point
TCP sender is already in RTO recovery AND "recover" is larger for a received in-order segment, or whether it is a duplicate
than or equal to SND.UNA (the oldest unacknowledged sequence acknowledgment to indicate an out-of-order segment. Duplicate
number [Pos81]), do not enter step 2 of this algorithm. Instead, acknowledgment is defined in [APB09]. The F-RTO algorithm does not
store the highest sequence number transmitted so far in variable specify actions for receiving a segment that neither acknowledges new
"recover" and continue with slow start retransmissions following data nor is a duplicate acknowledgment. The TCP sender SHOULD ignore
the conventional RTO recovery algorithm. such segments and wait for a segment that either acknowledges new
data or is a duplicate acknowledgment.
2) When the first acknowledgment after the RTO retransmission 1) When the retransmission timer expires, retransmit the first
arrives at the TCP sender, store the highest sequence number unacknowledged segment and set SpuriousRecovery to FALSE. If the
transmitted so far in variable "recover". The TCP sender chooses TCP sender is already in RTO recovery AND "recover" is larger than
one of the following actions, depending on whether the ACK or equal to SND.UNA (the oldest unacknowledged sequence number
advances the window or whether it is a duplicate ACK. [Pos81]), do not enter step 2 of this algorithm. Instead, store
the highest sequence number transmitted so far in variable
"recover" and continue with slow-start retransmissions following
the conventional RTO recovery algorithm.
a) If the acknowledgment is a duplicate ACK OR the 2) When the first acknowledgment after the RTO retransmission arrives
Acknowledgement field covers "recover" but not more than at the TCP sender, store the highest sequence number transmitted
"recover" OR the acknowledgment does not acknowledge all of so far in variable "recover". The TCP sender chooses one of the
the data that was retransmitted in step 1, revert to the following actions, depending on whether the ACK advances the
conventional RTO recovery and continue by retransmitting window or whether it is a duplicate ACK.
unacknowledged data in slow start. Do not enter step 3 of
this algorithm. The SpuriousRecovery variable remains as
FALSE.
b) Else, if the acknowledgment advances the window AND the a) If the acknowledgment is a duplicate ACK, OR the Acknowledgment
Acknowledgement field does not cover "recover", transmit up to field covers "recover" but not more than "recover", OR the
two new (previously unsent) segments and enter step 3 of this acknowledgment does not acknowledge all of the data that was
algorithm. If the TCP sender does not have enough unsent data, retransmitted in step 1, revert to the conventional RTO
it can send only one segment. In addition, the TCP sender MAY recovery and continue by retransmitting unacknowledged data in
override the Nagle algorithm [Nag84] and immediately send a slow start. Do not enter step 3 of this algorithm. The
segment if needed. Note that sending two segments in this step SpuriousRecovery variable remains as FALSE.
is allowed by TCP congestion control requirements [APS99]: An
F-RTO TCP sender simply chooses different segments to
transmit.
If the TCP sender does not have any new data to send, or the b) Else, if the acknowledgment advances the window AND the
advertised window prohibits new transmissions, the recommended Acknowledgment field does not cover "recover", transmit up to
action is to skip step 3 of this algorithm and continue with two new (previously unsent) segments and enter step 3 of this
slow start retransmissions, following the conventional RTO algorithm. If the TCP sender does not have enough unsent data,
recovery algorithm. However, alternative ways of handling the it can send only one segment. In addition, the TCP sender MAY
window-limited cases that could result in better performance override the Nagle algorithm [Nag84] and immediately send a
are discussed in Appendix A. segment if needed. Note that sending two segments in this step
is allowed by TCP congestion control requirements [APB09]: an
F-RTO TCP sender simply chooses different segments to transmit.
3) When the second acknowledgment after the RTO retransmission If the TCP sender does not have any new data to send, or the
arrives at the TCP sender, the TCP sender either declares the advertised window prohibits new transmissions, the recommended
timeout spurious, or starts retransmitting the unacknowledged action is to skip step 3 of this algorithm and continue with
segments. slow-start retransmissions, following the conventional RTO
a) If the acknowledgment is a duplicate ACK, set the congestion RFC 5682 F-RTO September 2009
window to no more than 3 * MSS, and continue with the slow
start algorithm retransmitting unacknowledged segments. The
congestion window can be set to 3 * MSS, because two round-
trip times have elapsed since the RTO, and a conventional TCP
sender would have increased cwnd to 3 during the same time.
Leave SpuriousRecovery set to FALSE.
b) If the acknowledgment advances the window (i.e., if it recovery algorithm. However, alternative ways of handling the
acknowledges data that was not retransmitted after the window-limited cases that could result in better performance
timeout), declare the timeout spurious, set SpuriousRecovery are discussed in Appendix A.
to SPUR_TO, and set the value of the "recover" variable to
SND.UNA (the oldest unacknowledged sequence number [Pos81]). 3) When the second acknowledgment after the RTO retransmission
arrives at the TCP sender, the TCP sender either declares the
timeout spurious, or starts retransmitting the unacknowledged
segments.
a) If the acknowledgment is a duplicate ACK, set the congestion
window to no more than 3 * MSS (where MSS indicates Maximum
Segment Size), and continue with the slow-start algorithm
retransmitting unacknowledged segments. The congestion window
can be set to 3 * MSS, because two round-trip times have
elapsed since the RTO, and a conventional TCP sender would have
increased cwnd to 3 during the same time. Leave
SpuriousRecovery set to FALSE.
b) If the acknowledgment advances the window (i.e., if it
acknowledges data that was not retransmitted after the
timeout), declare the timeout spurious, set SpuriousRecovery to
SPUR_TO, and set the value of the "recover" variable to SND.UNA
(the oldest unacknowledged sequence number [Pos81]).
2.2. Discussion 2.2. Discussion
The F-RTO sender takes cautious actions when it receives duplicate The F-RTO sender takes cautious actions when it receives duplicate
acknowledgments after a retransmission timeout. Because duplicate acknowledgments after a retransmission timeout. Because duplicate
ACKs may indicate that segments have been lost, reliably detecting a ACKs may indicate that segments have been lost, reliably detecting a
spurious timeout is difficult due to the lack of additional spurious timeout is difficult due to the lack of additional
information. Therefore, it is prudent to follow the conventional information. Therefore, it is prudent to follow the conventional TCP
TCP recovery in those cases. recovery in those cases.
The condition in step 1 prevents the execution of the F-RTO The condition in step 1 prevents the execution of the F-RTO algorithm
algorithm in case a previous RTO recovery is underway when the in case a previous RTO recovery is underway when the retransmission
retransmission timer expires, except in case the retransmission timer expires, except in case the retransmission timer expires
timer expires multiple times for the same segment. If the multiple times for the same segment. If the retransmission timer
retransmission timer expires during an earlier RTO-based loss expires during an earlier RTO-based loss recovery, acknowledgments
recovery, acknowledgements for retransmitted segments may falsely for retransmitted segments may falsely lead the TCP sender to declare
lead the TCP sender to declare the timeout spurious. the timeout spurious.
If the first acknowledgment after the RTO retransmission covers the If the first acknowledgment after the RTO retransmission covers the
"recover" point at algorithm step (2a), there is not enough evidence "recover" point at algorithm step (2a), there is not enough evidence
that a non-retransmitted segment has arrived at the receiver after that a non-retransmitted segment has arrived at the receiver after
the timeout. This is a common case when a fast retransmission is the timeout. This is a common case when a fast retransmission is
lost and has been retransmitted again after an RTO, while the rest lost and has been retransmitted again after an RTO, while the rest of
of the unacknowledged segments were successfully delivered to the
TCP receiver before the retransmission timeout. Therefore, the
timeout cannot be declared spurious in this case.
If the first acknowledgment after the RTO retransmission does not RFC 5682 F-RTO September 2009
acknowledge all of the data that was retransmitted in step 1, the
TCP sender reverts to the conventional RTO recovery. Otherwise, a
malicious receiver acknowledging partial segments could cause the
sender to declare the timeout spurious in a case where data was
lost.
The TCP sender is allowed to send two new segments in algorithm the unacknowledged segments were successfully delivered to the TCP
branch (2b) because the conventional TCP sender would transmit two receiver before the retransmission timeout. Therefore, the timeout
segments when the first new ACK arrives after the RTO cannot be declared spurious in this case.
retransmission. If sending new data is not possible in algorithm
branch (2b), or if the receiver window limits the transmission, the
TCP sender has to send something in order to prevent the TCP
transfer from stalling. If no segments were sent, the pipe between
sender and receiver might run out of segments, and no further
acknowledgments would arrive. Therefore, in the window-limited
case, the recommendation is to revert to the conventional RTO
recovery with slow start retransmissions. Appendix A discusses some
alternative solutions for window-limited situations.
If the retransmission timeout is declared spurious, the TCP sender If the first acknowledgment after the RTO retransmission does not
sets the value of the "recover" variable to SND.UNA in order to acknowledge all of the data that was retransmitted in step 1, the TCP
allow fast retransmit [FHG04]. The "recover" variable was proposed sender reverts to the conventional RTO recovery. Otherwise, a
for avoiding unnecessary, multiple fast retransmits when the malicious receiver acknowledging partial segments could cause the
retransmission timer expires during fast recovery with NewReno TCP. sender to declare the timeout spurious in a case where data was lost.
Because the F-RTO sender retransmits only the segment that triggered
the timeout, the problem of unnecessary multiple fast retransmits
[FHG04] cannot occur. Therefore, if three duplicate ACKs arrive at
the sender after the timeout, they probably indicate a packet loss,
and thus fast retransmit should be used to allow efficient recovery.
If there are not enough duplicate ACKs arriving at the sender after
a packet loss, the retransmission timer expires again and the sender
enters step 1 of this algorithm.
When the timeout is declared spurious, the TCP sender cannot detect The TCP sender is allowed to send two new segments in algorithm
whether the unnecessary RTO retransmission was lost. In principle, branch (2b) because the conventional TCP sender would transmit two
the loss of the RTO retransmission should be taken as a congestion segments when the first new ACK arrives after the RTO retransmission.
signal. Thus, there is a small possibility that the F-RTO sender If sending new data is not possible in algorithm branch (2b), or if
will violate the congestion control rules, if it chooses to fully the receiver window limits the transmission, the TCP sender has to
revert congestion control parameters after detecting a spurious send something in order to prevent the TCP transfer from stalling.
timeout. The Eifel detection algorithm has a similar property, If no segments were sent, the pipe between sender and receiver might
while the DSACK option can be used to detect whether the run out of segments, and no further acknowledgments would arrive.
retransmitted segment was successfully delivered to the receiver. Therefore, in the window-limited case, the recommendation is to
revert to the conventional RTO recovery with slow-start
retransmissions. Appendix A discusses some alternative solutions for
window-limited situations.
The F-RTO algorithm has a side-effect on the TCP round-trip time If the retransmission timeout is declared spurious, the TCP sender
measurement. Because the TCP sender can avoid most of the sets the value of the "recover" variable to SND.UNA in order to allow
unnecessary retransmissions after detecting a spurious timeout, the fast retransmit [FHG04]. The "recover" variable was proposed for
sender is able to take round-trip time samples on the delayed avoiding unnecessary, multiple fast retransmits when the
segments. If the regular RTO recovery was used without TCP retransmission timer expires during fast recovery with NewReno TCP.
timestamps, this would not be possible due to the retransmission Because the F-RTO sender retransmits only the segment that triggered
ambiguity. As a result, the RTO is likely to have more accurate and the timeout, the problem of unnecessary multiple fast retransmits
larger values with F-RTO than with the regular TCP after a spurious [FHG04] cannot occur. Therefore, if three duplicate ACKs arrive at
timeout that was triggered due to delayed segments. We believe this the sender after the timeout, they probably indicate a packet loss,
is an advantage in networks that are prone to delay spikes. and thus fast retransmit should be used to allow efficient recovery.
If there are not enough duplicate ACKs arriving at the sender after a
packet loss, the retransmission timer expires again and the sender
enters step 1 of this algorithm.
There are some situations where the F-RTO algorithm may not avoid When the timeout is declared spurious, the TCP sender cannot detect
unnecessary retransmissions after a spurious timeout. If packet whether the unnecessary RTO retransmission was lost. In principle,
reordering or packet duplication occurs on the segment that the loss of the RTO retransmission should be taken as a congestion
triggered the spurious timeout, the F-RTO algorithm may not detect signal. Thus, there is a small possibility that the F-RTO sender
the spurious timeout due to incoming duplicate ACKs. Additionally, will violate the congestion control rules, if it chooses to fully
if a spurious timeout occurs during fast recovery, the F-RTO revert congestion control parameters after detecting a spurious
algorithm often cannot detect the spurious timeout because the timeout. The Eifel Detection algorithm has a similar property, while
segments that were transmitted before the fast recovery trigger the DSACK option can be used to detect whether the retransmitted
duplicate ACKs. However, we consider these cases rare, and note segment was successfully delivered to the receiver.
that in cases where F-RTO fails to detect the spurious timeout, it
retransmits the unacknowledged segments in slow start, and thus RFC 5682 F-RTO September 2009
performs similarly to the regular RTO recovery.
The F-RTO algorithm has a side effect on the TCP round-trip time
measurement. Because the TCP sender can avoid most of the
unnecessary retransmissions after detecting a spurious timeout, the
sender is able to take round-trip time samples on the delayed
segments. If the regular RTO recovery was used without TCP
timestamps, this would not be possible due to the retransmission
ambiguity. As a result, the RTO is likely to have more accurate and
larger values with F-RTO than with the regular TCP after a spurious
timeout that was triggered due to delayed segments. We believe this
is an advantage in networks that are prone to delay spikes.
There are some situations where the F-RTO algorithm may not avoid
unnecessary retransmissions after a spurious timeout. If packet
reordering or packet duplication occurs on the segment that triggered
the spurious timeout, the F-RTO algorithm may not detect the spurious
timeout due to incoming duplicate ACKs. Additionally, if a spurious
timeout occurs during fast recovery, the F-RTO algorithm often cannot
detect the spurious timeout because the segments that were
transmitted before the fast recovery trigger duplicate ACKs.
However, we consider these cases rare, and note that in cases where
F-RTO fails to detect the spurious timeout, it retransmits the
unacknowledged segments in slow start, and thus performs the same as
the regular RTO recovery.
3. SACK-Enhanced Version of the F-RTO Algorithm 3. SACK-Enhanced Version of the F-RTO Algorithm
This section describes an alternative version of the F-RTO algorithm This section describes an alternative version of the F-RTO algorithm
that uses the TCP Selective Acknowledgment Option [MMFR96]. By that uses the TCP Selective Acknowledgment Option [MMFR96]. By using
using the SACK option, the TCP sender detects spurious timeouts in the SACK option, the TCP sender detects spurious timeouts in most of
most of the cases when packet reordering or packet duplication is the cases when packet reordering or packet duplication is present.
present. If the SACK blocks acknowledge new data that was not If the SACK information acknowledges new data that was not
transmitted after the RTO retransmission, the sender may declare the transmitted after the RTO retransmission, the sender may declare the
timeout spurious, even when duplicate ACKs follow the RTO. timeout spurious, even when duplicate ACKs follow the RTO.
3.1. The Algorithm 3.1. The Algorithm
Given that the TCP Selective Acknowledgment Option [MMFR96] is Given that the TCP Selective Acknowledgment Option [MMFR96] is
enabled for a TCP connection, a TCP sender MAY apply the SACK- enabled for a TCP connection, a TCP sender MAY apply the SACK-
enhanced F-RTO algorithm. If the sender applies the SACK-enhanced enhanced F-RTO algorithm. If the sender applies the SACK-enhanced
F-RTO algorithm, it MUST follow the steps below. This algorithm F-RTO algorithm, it MUST follow the steps below. This algorithm
SHOULD NOT be applied if the TCP sender is already in loss recovery SHOULD NOT be applied if the TCP sender is already in loss recovery
when a retransmission timeout occurs. when a retransmission timeout occurs.
The steps of the SACK-enhanced version of the F-RTO algorithm are as The steps of the SACK-enhanced version of the F-RTO algorithm are as
follows. If the retransmission timer expires again during the follows. If the retransmission timer expires again during the
execution of the SACK-enhanced F-RTO algorithm, the TCP sender MUST execution of the SACK-enhanced F-RTO algorithm, the TCP sender MUST
re-start the algorithm processing from step 1. re-start the algorithm processing from step 1.
1) When the retransmission timer expires, retransmit the first RFC 5682 F-RTO September 2009
unacknowledged segment and set SpuriousRecovery to FALSE.
Following the recommendation in the SACK specification [MMFR96],
reset the SACK scoreboard. If "RecoveryPoint" is larger than or
equal to SND.UNA, do not enter step 2 of this algorithm. Instead,
set variable "RecoveryPoint" to indicate the highest sequence
number transmitted so far and continue with slow start
retransmissions following the conventional RTO recovery
algorithm.
2) Wait until the acknowledgment of the data retransmitted due to 1) When the retransmission timer expires, retransmit the first
the timeout arrives at the sender. If duplicate ACKs arrive unacknowledged segment and set SpuriousRecovery to FALSE.
before the cumulative acknowledgment for retransmitted data, Following the recommendation in the SACK specification [MMFR96],
adjust the scoreboard according to the incoming SACK information. reset the SACK scoreboard. If "RecoveryPoint" is larger than or
Stay in step 2 and wait for the next new acknowledgment. If the equal to SND.UNA, do not enter step 2 of this algorithm. Instead,
retransmission timeout expires again, go to step 1 of the set variable "RecoveryPoint" to indicate the highest sequence
algorithm. When a new acknowledgment arrives, set variable number transmitted so far and continue with slow-start
"RecoveryPoint" to indicate the highest sequence number retransmissions following the conventional RTO recovery algorithm.
transmitted so far.
a) If the Cumulative Acknowledgement field covers "RecoveryPoint" 2) Wait until the acknowledgment of the data retransmitted due to the
but not more than "RecoveryPoint", revert to the conventional timeout arrives at the sender. If duplicate ACKs arrive before
RTO recovery and set the congestion window to no more than 2 * the cumulative acknowledgment for retransmitted data, adjust the
MSS, like a regular TCP would do. Do not enter step 3 of this scoreboard according to the incoming SACK information. Stay in
algorithm. step 2 and wait for the next new acknowledgment. If the
retransmission timeout expires again, go to step 1 of the
algorithm. When a new acknowledgment arrives, set variable
"RecoveryPoint" to indicate the highest sequence number
transmitted so far.
b) Else, if the Cumulative Acknowledgement field does not cover a) If the Cumulative Acknowledgment field covers "RecoveryPoint"
"RecoveryPoint" but is larger than SND.UNA, transmit up to two but not more than "RecoveryPoint", revert to the conventional
new (previously unsent) segments and proceed to step 3. If RTO recovery and set the congestion window to no more than 2 *
the TCP sender is not able to transmit any previously unsent MSS, like a regular TCP would do. Do not enter step 3 of this
data -- either due to receiver window limitation or because it algorithm.
does not have any new data to send -- the recommended action
is to refrain from entering step 3 of this algorithm. Rather,
continue with slow start retransmissions following the
conventional RTO recovery algorithm.
It is also possible to apply some of the alternatives for b) Else, if the Cumulative Acknowledgment field does not cover
handling window-limited cases discussed in Appendix A. "RecoveryPoint" but is larger than SND.UNA, transmit up to two
new (previously unsent) segments and proceed to step 3. If the
TCP sender is not able to transmit any previously unsent data
-- either due to receiver window limitation or because it does
not have any new data to send -- the recommended action is to
refrain from entering step 3 of this algorithm. Rather,
continue with slow-start retransmissions following the
conventional RTO recovery algorithm.
3) The next acknowledgment arrives at the sender. Either a It is also possible to apply some of the alternatives for
duplicate ACK or a new cumulative ACK (advancing the window) handling window-limited cases discussed in Appendix A.
applies in this step. Other types of ACKs are ignored without any
action.
a) If the Cumulative Acknowledgement field or a SACK block covers 3) The next acknowledgment arrives at the sender. Either a duplicate
more than "RecoveryPoint", set the congestion window to no ACK or a new cumulative ACK (advancing the window) applies in this
more than 3 * MSS and proceed with the conventional RTO step. Other types of ACKs are ignored without any action.
recovery, retransmitting unacknowledged segments. Take this
branch also when the acknowledgment is a duplicate ACK and it
does not acknowledge any new, previously unacknowledged data
below "RecoveryPoint" in the SACK blocks. Leave
SpuriousRecovery set to FALSE.
b) If the Cumulative Acknowledgement field or a SACK block in the a) If the Cumulative Acknowledgment field or the SACK information
ACK does not cover more than "RecoveryPoint" AND it covers more than "RecoveryPoint", set the congestion window to
acknowledges data that was not acknowledged earlier (either no more than 3 * MSS and proceed with the conventional RTO
with cumulative acknowledgment or using SACK blocks), declare recovery, retransmitting unacknowledged segments. Take this
the timeout spurious and set SpuriousRecovery to SPUR_TO. The branch also when the acknowledgment is a duplicate ACK and it
retransmission timeout can be declared spurious, because the does not acknowledge any new, previously unacknowledged data
segment acknowledged with this ACK was transmitted before the
timeout.
If there are unacknowledged holes between the received SACK blocks, RFC 5682 F-RTO September 2009
those segments are retransmitted similarly to the conventional SACK
recovery algorithm [BAFW03]. If the algorithm exits with below "RecoveryPoint" in the SACK information. Leave
SpuriousRecovery set to SPUR_TO, "RecoveryPoint" is set to SND.UNA, SpuriousRecovery set to FALSE.
thus allowing fast recovery on incoming duplicate acknowledgments.
b) If the Cumulative Acknowledgment field or a SACK information in
the ACK does not cover more than "RecoveryPoint" AND it
acknowledges data that was not acknowledged earlier (either
with cumulative acknowledgment or using SACK information),
declare the timeout spurious and set SpuriousRecovery to
SPUR_TO. The retransmission timeout can be declared spurious,
because the segment acknowledged with this ACK was transmitted
before the timeout.
If there are unacknowledged holes between the received SACK
information, those segments are retransmitted similarly to the
conventional SACK recovery algorithm [BAFW03]. If the algorithm
exits with SpuriousRecovery set to SPUR_TO, "RecoveryPoint" is set to
SND.UNA, thus allowing fast recovery on incoming duplicate
acknowledgments.
3.2. Discussion 3.2. Discussion
The SACK enhanced algorithm works on the same principle as the basic The SACK-enhanced algorithm works on the same principle as the basic
algorithm, but by utilizing the additional information from the SACK algorithm, but by utilizing the additional information from the SACK
option. When a genuine retransmission timeout occurs during a steady option. When a genuine retransmission timeout occurs during a steady
state of a connection, it can be assumed that there are no segments state of a connection, it can be assumed that there are no segments
left in the pipe. Otherwise, the acknowledgments triggered by these left in the pipe. Otherwise, the acknowledgments triggered by these
segments would have triggered the SACK loss recovery or transmission segments would have triggered the SACK loss recovery or transmission
of new segments. Therefore, if the F-RTO sender receives of new segments. Therefore, if the F-RTO sender receives
acknowledgements for segments transmitted before the retransmission acknowledgments for segments transmitted before the retransmission
timeout in response to the two new segments sent at the algorithm timeout in response to the two new segments sent at the algorithm
step 2, the normal operation of TCP has been just delayed, and the step 2, the normal operation of TCP has been just delayed, and the
retransmission timeout is considered spurious. Note that this retransmission timeout is considered spurious. Note that this
reasoning works only when the TCP sender is not in loss recovery at reasoning works only when the TCP sender is not in loss recovery at
the time the retransmission timeout occurs. The condition in step 1 the time the retransmission timeout occurs. The condition in step 1
checking that "RecoveryPoint" is larger than or equal to SND.UNA checking that "RecoveryPoint" is larger than or equal to SND.UNA
prevents the execution of the F-RTO algorithm in case a previous prevents the execution of the F-RTO algorithm in case a previous loss
loss recovery, either RTO recovery or SACK loss recovery, is recovery, either RTO recovery or SACK loss recovery, is underway when
underway when the retransmission timer expires. It, however, allows the retransmission timer expires. It, however, allows the execution
the execution of the F-RTO algorithm, if the retransmission timer of the F-RTO algorithm, if the retransmission timer expires multiple
expires multiple times for the same segment. times for the same segment.
4. Taking Actions after Detecting Spurious RTO 4. Taking Actions after Detecting Spurious RTO
Upon a retransmission timeout, a conventional TCP sender assumes Upon a retransmission timeout, a conventional TCP sender assumes that
that outstanding segments are lost and starts retransmitting the outstanding segments are lost and starts retransmitting the
unacknowledged segments. When the retransmission timeout is unacknowledged segments. When the retransmission timeout is detected
detected to be spurious, the TCP sender should not continue to be spurious, the TCP sender should not continue retransmitting
retransmitting based on the timeout. For example, if the sender was based on the timeout. For example, if the sender was in congestion
in congestion avoidance phase transmitting new, previously unsent
segments, it should continue transmitting previously unsent segments
in congestion avoidance.
There are currently two alternatives specified for a spurious RFC 5682 F-RTO September 2009
timeout response algorithm, the Eifel Response Algorithm [LG04], and
an algorithm for adapting the retransmission timeout after a
spurious RTO [BBA06]. If no specific response algorithm is
implemented, the TCP SHOULD respond to spurious timeout
conservatively, applying the TCP congestion control specification
[APS99]. Different response algorithms for spurious retransmission
timeouts have been analyzed in some research papers [GL03, Sar03]
and IETF documents [SL03].
5. Evaluation of RFC 4138 avoidance phase transmitting new, previously unsent segments, it
should continue transmitting previously unsent segments in congestion
avoidance.
F-RTO was first specified in an Experimental RFC 4138 that has been There are currently two alternatives specified for a spurious timeout
implemented in a number of operating systems since it was published. response algorithm, the Eifel Response Algorithm [LG05], and an
Gained experience has been documented in a separate document algorithm for adapting the retransmission timeout after a spurious
[KYHS07], and can be summarized as follows. RTO [BBA06]. If no specific response algorithm is implemented, the
TCP SHOULD respond to spurious timeout conservatively, applying the
TCP congestion control specification [APB09]. Different response
algorithms for spurious retransmission timeouts have been analyzed in
some research papers [GL03, Sar03] and IETF documents [SL03].
If the TCP sender employs F-RTO, it is able to detect spurious RTOs 5. Evaluation of RFC 4138
and avoid the unnecessary retransmission of the whole window of
data. Because F-RTO avoids the unnecessary retransmissions after a
spurious RTO, it is able to adhere to the packet conservation
principle, unlike a regular TCP that enters the slow-start recovery
unnecessarily an inappropriately restarts the ACK clock while there
are segments outstanding in the network. When a spurious RTO has
been detected, a sender can select an appropriate congestion control
response instead of setting the congestion window to one segment.
Because F-RTO avoids unnecessary retransmissions, it is able to take
the RTT of the delayed segments into account when calculating the
RTO estimate, which may help in avoiding further spurious
retransmission timeouts.
Experimental results with the basic F-RTO have been reported in an F-RTO was first specified in an Experimental RFC (RFC 4138) that has
emulated network using a Linux implementation [SKR03]. Also been implemented in a number of operating systems since it was
different congestion control responses along with the SACK-enhanced published. Gained experience has been documented in a separate
version of F-RTO were tested in a similar environment [Sar03]. There document [KYHS07], and can be summarized as follows.
are publications analyzing F-RTO performance over commercial W-CDMA
networks, and in an emulated HSDPA network [Yam05, Hok05]. Also
Microsoft reported positive experiences with their implementation of
F-RTO in the IETF-68 meeting.
It is known that some spurious RTOs may remain undetected by F-RTO If the TCP sender employs F-RTO, it is able to detect spurious RTOs
if duplicate acknowledgements arrive at the sender immediately after and avoid the unnecessary retransmission of the whole window of data.
the spurious RTO, for example due to packet reordering or packet Because F-RTO avoids the unnecessary retransmissions after a spurious
loss. There are rare corner cases where F-RTO could "hide" a packet RTO, it is able to adhere to the packet conservation principle,
loss and therefore lead to inappropriate behavior with non- unlike a regular TCP that enters the slow-start recovery
conservative congestion control response: first, if a massive packet unnecessarily and inappropriately restarts the ACK clock while there
reordering occurred so that the acknowledgement of RTO are segments outstanding in the network. When a spurious RTO has
retransmission arrived at the sender before the acknowledgments of been detected, a sender can select an appropriate congestion control
original transmissions, the sender might not detect the loss of the response instead of setting the congestion window to one segment.
segment that triggered the RTO. Second, a malicious receiver could Because F-RTO avoids unnecessary retransmissions, it is able to take
lead F-RTO to make a wrong conclusion after an RTO by acknowledging the round-trip time of the delayed segments into account when
segments it has not received. Such receiver would, however, risk calculating the RTO estimate, which may help in avoiding further
breaking the consistency of the TCP state between the sender and spurious retransmission timeouts.
receiver, causing the connection to become unusable, which cannot be
of any benefit to the receiver. Therefore we believe it is not
likely that receivers would start employing such tricks in a
significant scale. Finally, loss of the unnecessary RTO
retransmission cannot be detected without using some explicit
acknowledgement scheme such as DSACK. This is common to the other
mechanisms for detecting spurious RTO, as well as to regular TCP
that does not use DSACK. We note that if the congestion control
response to spurious RTO is conservative enough, the above corner
cases do not cause problems due to increased congestion.
6. Security Considerations Experimental results with the basic F-RTO have been reported in an
emulated network using a Linux implementation [SKR03]. Also,
different congestion control responses along with the SACK-enhanced
version of F-RTO were tested in a similar environment [Sar03]. There
are publications analyzing F-RTO performance over commercial Wideband
Code Division Multiple Access (W-CDMA) networks, and in an emulated
High-Speed Downlink Packet Access (HSDPA) network [Yam05, Hok05].
Also, Microsoft reported positive experiences with their
implementation of F-RTO at the IETF-68 meeting.
The main security threat regarding F-RTO is the possibility that a It is known that some spurious RTOs may remain undetected by F-RTO if
receiver could mislead the sender into setting too large a duplicate acknowledgments arrive at the sender immediately after the
congestion window after an RTO. There are two possible ways a spurious RTO, for example due to packet reordering or packet loss.
malicious receiver could trigger a wrong output from the F-RTO There are rare corner cases where F-RTO could "hide" a packet loss
algorithm. First, the receiver can acknowledge data that it has not
received. Second, it can delay acknowledgment of a segment it has
received earlier, and acknowledge the segment after the TCP sender
has been deluded to enter algorithm step 3.
If the receiver acknowledges a segment it has not really received, RFC 5682 F-RTO September 2009
the sender can be led to declare spurious timeout in the F-RTO
algorithm, step 3. However, because the sender will have an
incorrect state, it cannot retransmit the segment that has never
reached the receiver. Therefore, this attack is unlikely to be
useful for the receiver to maliciously gain a larger congestion
window.
A common case for a retransmission timeout is that a fast and therefore lead to inappropriate behavior with non-conservative
retransmission of a segment is lost. If all other segments have congestion control response: first, if a massive packet reordering
been received, the RTO retransmission causes the whole window to be occurred so that the acknowledgment of RTO retransmission arrived at
acknowledged at once. This case is recognized in F-RTO algorithm the sender before the acknowledgments of original transmissions, the
branch (2a). However, if the receiver only acknowledges one segment sender might not detect the loss of the segment that triggered the
after receiving the RTO retransmission, and then the rest of the RTO. Second, a malicious receiver could lead F-RTO to make a wrong
segments, it could cause the timeout to be declared spurious when it conclusion after an RTO by acknowledging segments it has not
is not. Therefore, it is suggested that, when an RTO occurs during received. Such a receiver would, however, risk breaking the
the fast recovery phase, the sender would not fully revert the consistency of the TCP state between the sender and receiver, causing
congestion window even if the timeout was declared spurious. the connection to become unusable, which cannot be of any benefit to
Instead, the sender would reduce the congestion window to 1. the receiver. Therefore, we believe it is not likely that receivers
would start employing such tricks on a significant scale. Finally,
loss of the unnecessary RTO retransmission cannot be detected without
using some explicit acknowledgment scheme such as DSACK. This is
common to the other mechanisms for detecting spurious RTO, as well as
to regular TCP that does not use DSACK. We note that if the
congestion control response to spurious RTO is conservative enough,
the above corner cases do not cause problems due to increased
congestion.
If there is more than one segment missing at the time of a 6. Security Considerations
retransmission timeout, the receiver does not benefit from
misleading the sender to declare a spurious timeout because the
sender would have to go through another recovery period to
retransmit the missing segments, usually after an RTO has elapsed.
7. IANA Considerations The main security threat regarding F-RTO is the possibility that a
receiver could mislead the sender into setting too large a congestion
window after an RTO. There are two possible ways a malicious
receiver could trigger a wrong output from the F-RTO algorithm.
First, the receiver can acknowledge data that it has not received.
Second, it can delay acknowledgment of a segment it has received
earlier, and acknowledge the segment after the TCP sender has been
deluded to enter algorithm step 3.
This document has no actions for IANA. If the receiver acknowledges a segment it has not really received,
the sender can be led to declare spurious timeout in the F-RTO
algorithm, step 3. However, because the sender will have an
incorrect state, it cannot retransmit the segment that has never
reached the receiver. Therefore, this attack is unlikely to be
useful for the receiver to maliciously gain a larger congestion
window.
8. Acknowledgements A common case for a retransmission timeout is that a fast
retransmission of a segment is lost. If all other segments have been
received, the RTO retransmission causes the whole window to be
acknowledged at once. This case is recognized in F-RTO algorithm
branch (2a). However, if the receiver only acknowledges one segment
after receiving the RTO retransmission, and then the rest of the
segments, it could cause the timeout to be declared spurious when it
is not. Therefore, it is suggested that, when an RTO occurs during
The authors would like to thank Alfred Hoenes, Ilpo Jarvinen and RFC 5682 F-RTO September 2009
Murari Sridharan for the comments on this document.
We are also thankful to Reiner Ludwig, Andrei Gurtov, Josh Blanton, the fast recovery phase, the sender would not fully revert the
Mark Allman, Sally Floyd, Yogesh Swami, Mika Liljeberg, Ivan Arias congestion window even if the timeout was declared spurious.
Rodriguez, Sourabh Ladha, Martin Duke, Motoharu Miyake, Ted Faber, Instead, the sender would reduce the congestion window to 1.
Samu Kontinen, and Kostas Pentikousis who gave valuable feedback
during the preparation of RFC 4138, the precursor of this document.
Appendix If there is more than one segment missing at the time of a
retransmission timeout, the receiver does not benefit from misleading
the sender to declare a spurious timeout because the sender would
have to go through another recovery period to retransmit the missing
segments, usually after an RTO has elapsed.
A. Discussion of Window-Limited Cases 7. Acknowledgments
When the advertised window limits the transmission of two new The authors would like to thank Alfred Hoenes, Ilpo Jarvinen, and
previously unsent segments, or there are no new data to send, it is Murari Sridharan for the comments on this document.
recommended in F-RTO algorithm step (2b) that the TCP sender
continue with the conventional RTO recovery algorithm. The
disadvantage is that the sender may continue unnecessary
retransmissions due to possible spurious timeout. This section
briefly discusses the options that can potentially improve
performance when transmitting previously unsent data is not
possible.
- The TCP sender could reserve an unused space of a size of one or We are also thankful to Reiner Ludwig, Andrei Gurtov, Josh Blanton,
two segments in the advertised window to ensure the use of Mark Allman, Sally Floyd, Yogesh Swami, Mika Liljeberg, Ivan Arias
algorithms such as F-RTO or Limited Transmit [ABF01] in receiver Rodriguez, Sourabh Ladha, Martin Duke, Motoharu Miyake, Ted Faber,
window-limited situations. On the other hand, while doing this, Samu Kontinen, and Kostas Pentikousis who gave valuable feedback
the TCP sender should ensure that the window of outstanding during the preparation of RFC 4138, the precursor of this document.
segments is large enough for proper utilization of the available
pipe.
- Use additional information if available, e.g., TCP timestamps with RFC 5682 F-RTO September 2009
the Eifel Detection algorithm, for detecting a spurious timeout.
However, Eifel detection may yield different results from F-RTO
when ACK losses and an RTO occur within the same round-trip time
[SKR03].
- Retransmit data from the tail of the retransmission queue and Appendix A. Discussion of Window-Limited Cases
continue with step 3 of the F-RTO algorithm. It is possible that
the retransmission will be made unnecessarily. Furthermore, the
operation of the SACK-based F-RTO algorithm would need to consider
this case separately, to not use the retransmitted segment to
indicate spurious timeout. Given these considerations, this option
is not recommended.
- Send a zero-sized segment below SND.UNA, similar to a TCP Keep- When the advertised window limits the transmission of two new
Alive probe, and continue with step 3 of the F-RTO algorithm. previously unsent segments, or there are no new data to send, it is
Because the receiver replies with a duplicate ACK, the sender is recommended in F-RTO algorithm step (2b) that the TCP sender continue
able to detect whether the timeout was spurious from the incoming with the conventional RTO recovery algorithm. The disadvantage is
acknowledgment. This method does not send data unnecessarily, but that the sender may continue unnecessary retransmissions due to
it delays the recovery by one round-trip time in cases where the possible spurious timeout. This section briefly discusses the
timeout was not spurious. Therefore, this method is not options that can potentially improve performance when transmitting
encouraged. previously unsent data is not possible.
- In receiver-limited cases, send one octet of new data, regardless - The TCP sender could reserve an unused space of a size of one or
of the advertised window limit, and continue with step 3 of the F- two segments in the advertised window to ensure the use of
RTO algorithm. It is possible that the receiver will have free algorithms such as F-RTO or Limited Transmit [ABF01] in receiver
buffer space to receive the data by the time the segment has window-limited situations. On the other hand, while doing this,
propagated through the network, in which case no harm is done. If the TCP sender should ensure that the window of outstanding
the receiver is not capable of receiving the segment, it rejects segments is large enough for proper utilization of the available
the segment and sends a duplicate ACK. pipe.
B. Changes since RFC 4138 - Use additional information if available, e.g., TCP timestamps with
the Eifel Detection algorithm, for detecting a spurious timeout.
However, Eifel detection may yield different results from F-RTO
when ACK losses and an RTO occur within the same round-trip time
[SKR03].
Changes from RFC 4138 are summarized below, apart from minor editing - Retransmit data from the tail of the retransmission queue and
and language improvements. continue with step 3 of the F-RTO algorithm. It is possible that
the retransmission will be made unnecessarily. Furthermore, the
operation of the SACK-based F-RTO algorithm would need to consider
this case separately, to not use the retransmitted segment to
indicate spurious timeout. Given these considerations, this option
is not recommended.
* Modified the basic F-RTO algorithm and the SACK-enhanced F-RTO - Send a zero-sized segment below SND.UNA, similar to a TCP Keep-
algorithm to prevent the TCP sender from applying the F-RTO Alive probe, and continue with step 3 of the F-RTO algorithm.
algorithm if the retransmission timer expires when an earlier RTO Because the receiver replies with a duplicate ACK, the sender is
recovery is underway, except when the retransmission timer expires able to detect whether the timeout was spurious from the incoming
multiple times for the same segment. acknowledgment. This method does not send data unnecessarily, but
it delays the recovery by one round-trip time in cases where the
timeout was not spurious. Therefore, this method is not
encouraged.
* Clarified behavior on multiple timeouts. - In receiver-limited cases, send one octet of new data, regardless
of the advertised window limit, and continue with step 3 of the
F-RTO algorithm. It is possible that the receiver will have free
buffer space to receive the data by the time the segment has
* Added a paragraph on acknowledgements that do not acknowledge new RFC 5682 F-RTO September 2009
data but are not duplicate acknowledgements.
* Clarified the SACK-algorithm a bit, and added one paragraph of propagated through the network, in which case no harm is done. If
description of the basic idea of the algorithm. the receiver is not capable of receiving the segment, it rejects
the segment and sends a duplicate ACK.
* Removed SCTP considerations. Appendix B. Changes since RFC 4138
* Removed earlier Appendix sections, except Appendix C from RFC Changes from RFC 4138 are summarized below, apart from minor
4138, which is now Appendix A. editing and language improvements.
* Clarified text about the possible response algorithms. * Modified the basic F-RTO algorithm and the SACK-enhanced F-RTO
algorithm to prevent the TCP sender from applying the F-RTO
algorithm if the retransmission timer expires when an earlier RTO
recovery is underway, except when the retransmission timer expires
multiple times for the same segment.
* Added section that summarizes the evaluation of RFC 4138. * Clarified behavior on multiple timeouts.
References * Added a paragraph on acknowledgments that do not acknowledge new
data but are not duplicate acknowledgments.
Normative References * Clarified the SACK-algorithm a bit, and added one paragraph of
description of the basic idea of the algorithm.
[APS99] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion * Removed SCTP considerations.
Control", RFC 2581, April 1999.
[APB08] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion * Removed earlier Appendix sections, except Appendix C from RFC 4138,
Control", Internet-Draft "draft-ietf-tcpm- which is now Appendix A.
rfc2581bis-04.txt",
April 2008.
[BAFW03] Blanton, E., Allman, M., Fall, K., and L. Wang, "A * Clarified text about the possible response algorithms.
Conservative Selective Acknowledgment (SACK)-based Loss
Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate * Added section that summarizes the evaluation of RFC 4138.
Requirement Levels", BCP 14, RFC 2119, March 1997.
[FHG04] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno References
Modification to TCP's Fast Recovery Algorithm", RFC 3782,
April 2004.
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Normative References
Selective Acknowledgement Options", RFC 2018,
October 1996.
[PA00] Paxson, V. and M. Allman, "Computing TCP's Retransmission [APB09] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Timer", RFC 2988, November 2000. Control", RFC 5681, September 2009.
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC [BAFW03] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
793, September 1981. Conservative Selective Acknowledgment (SACK)-based Loss
Recovery Algorithm for TCP", RFC 3517, April 2003.
Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ABF01] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing RFC 5682 F-RTO September 2009
TCP's Loss Recovery Using Limited Transmit", RFC 3042,
January 2001.
[BA04] Blanton, E. and M. Allman, "Using TCP Duplicate Selective [FHG04] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
Acknowledgement (DSACKs) and Stream Control Transmission Modification to TCP's Fast Recovery Algorithm", RFC 3782,
Protocol (SCTP) Duplicate Transmission Sequence Numbers April 2004.
(TSNs) to Detect Spurious Retransmissions", RFC 3708,
February 2004.
[BBA06] Blanton, J., Blanton, E., and M. Allman, "Using Spurious [MMFR96] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Retransmissions to Adapt the Retransmission Timeout", Selective Acknowledgment Options", RFC 2018, October 1996.
Internet-Draft "draft-allman-rto-backoff-04.txt", December
2006. Work in progress.
[BBJ92] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions [PA00] Paxson, V. and M. Allman, "Computing TCP's Retransmission
for High Performance", RFC 1323, May 1992. Timer", RFC 2988, November 2000.
[FMMP00] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An [Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC
Extension to the Selective Acknowledgement (SACK) Option 793, September 1981.
for TCP", RFC 2883, July 2000.
[GL02] Gurtov A. and R. Ludwig, "Evaluating the Eifel Algorithm Informative References
for TCP in a GPRS Network", In Proc. European Wireless,
Florence, Italy, February 2002.
[GL03] Gurtov A. and R. Ludwig, "Responding to Spurious Timeouts [ABF01] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
in TCP", In Proc. IEEE INFOCOM 03, San Francisco, CA, USA, TCP's Loss Recovery Using Limited Transmit", RFC 3042,
March 2003. January 2001.
[Jac88] Jacobson, V., "Congestion Avoidance and Control", In [BA04] Blanton, E. and M. Allman, "Using TCP Duplicate Selective
Proc. ACM SIGCOMM 88. Acknowledgement (DSACKs) and Stream Control Transmission
Protocol (SCTP) Duplicate Transmission Sequence Numbers
(TSNs) to Detect Spurious Retransmissions", RFC 3708,
February 2004.
[Hok05] Hokamura, A., et al., "Performance Evaluation of F-RTO and [BBA06] Blanton, J., Blanton, E., and M. Allman, "Using Spurious
Eifel Response Algorithms over W-CDMA packet network", In Retransmissions to Adapt the Retransmission Timeout", Work
Proc. Wireless Personal Multimedia Communications in Progress, December 2006.
(WPMC'05),
Sept. 2005.
[KYHS07] Kojo, M., Yamamoto, K., Hata, M., and P. Sarolahti, [BBJ92] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
"Evaluation of RFC 4138", Internet-draft for High Performance", RFC 1323, May 1992.
"draft-kojo-tcpm-frto-eval-00.txt", June 2007. Work
in progress.
[LG04] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm [FMMP00] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
for TCP", RFC 4015, February 2005. Extension to the Selective Acknowledgement (SACK) Option
for TCP", RFC 2883, July 2000.
[LK00] Ludwig R. and R.H. Katz, "The Eifel Algorithm: Making TCP [GL02] Gurtov A. and R. Ludwig, "Evaluating the Eifel Algorithm
Robust Against Spurious Retransmissions", ACM SIGCOMM for TCP in a GPRS Network", In Proc. European Wireless,
Computer Communication Review, 30(1), January 2000. Florence, Italy, February 2002.
[LM03] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm [GL03] Gurtov A. and R. Ludwig, "Responding to Spurious Timeouts
for TCP", RFC 3522, April 2003. in TCP", In Proc. IEEE INFOCOM 03, San Francisco, CA, USA,
March 2003.
[Nag84] Nagle, J., "Congestion Control in IP/TCP Internetworks", [Jac88] Jacobson, V., "Congestion Avoidance and Control", In Proc.
RFC 896, January 1984. ACM SIGCOMM 88.
[SK05] Sarolahti, P. and M. Kojo, "Forward RTO-Recovery (F-RTO): RFC 5682 F-RTO September 2009
An Algorithm for Detecting Spurious Retransmission
Timeouts with TCP and the Stream Control Transmission
Protocol (SCTP)", RFC 4138, August 2005.
[SKR03] Sarolahti, P., Kojo, M., and K. Raatikainen, "F-RTO: An [Hok05] Hokamura, A., et al., "Performance Evaluation of F-RTO and
Enhanced Recovery Algorithm for TCP Retransmission Eifel Response Algorithms over W-CDMA packet network", In
Timeouts", ACM SIGCOMM Computer Communication Review, Proc. Wireless Personal Multimedia Communications
33(2), April 2003. (WPMC'05), Sept. 2005.
[Sar03] P. Sarolahti, P., "Congestion Control on Spurious TCP [KYHS07] Kojo, M., Yamamoto, K., Hata, M., and P. Sarolahti,
Retransmission Timeouts", In Proc. of IEEE Globecom "Evaluation of RFC 4138", Work in Progress, November 2007.
2003, San Francisco, CA, USA. December 2003.
[SL03] Swami Y. and K. Le, "DCLOR: De-correlated Loss Recovery [LG05] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for
using SACK Option for Spurious Timeouts", Expired TCP", RFC 4015, February 2005.
Internet-Draft, September 2003.
[Ste07] Stewart, R., Ed., "Stream Control Transmission Protocol", [LK00] Ludwig R. and R.H. Katz, "The Eifel Algorithm: Making TCP
RFC 4960, September 2007. Robust Against Spurious Retransmissions", ACM SIGCOMM
Computer Communication Review, 30(1), January 2000.
[Yam05] Yamamoto, K., et al., "Effects of F-RTO and Eifel Response [LM03] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for
Algorithms for W-CDMA and HSDPA networks", In Proc. TCP", RFC 3522, April 2003.
Wireless
Personal Multimedia Communications (WPMC'05), September
2005.
AUTHORS' ADDRESSES [Nag84] Nagle, J., "Congestion control in IP/TCP internetworks",
RFC 896, January 1984.
Pasi Sarolahti [SK05] Sarolahti, P. and M. Kojo, "Forward RTO-Recovery (F-RTO):
Nokia Research Center An Algorithm for Detecting Spurious Retransmission Timeouts
P.O. Box 407 with TCP and the Stream Control Transmission Protocol
FI-00045 NOKIA GROUP (SCTP)", RFC 4138, August 2005.
Finland
Phone: +358 50 4876607
Email: pasi.sarolahti@nokia.com
Markku Kojo [SKR03] Sarolahti, P., Kojo, M., and K. Raatikainen, "F-RTO: An
University of Helsinki Enhanced Recovery Algorithm for TCP Retransmission
P.O. Box 68 Timeouts", ACM SIGCOMM Computer Communication Review,
FI-00014 UNIVERSITY OF HELSINKI 33(2), April 2003.
Finland
Email: kojo@cs.helsinki.fi
Kazunori Yamamoto [Sar03] Sarolahti, P., "Congestion Control on Spurious TCP
NTT Docomo, Inc. Retransmission Timeouts", In Proc. of IEEE Globecom 2003,
3-5 Hikarinooka, Yokosuka, Kanagawa, 239-8536, Japan San Francisco, CA, USA. December 2003.
Phone: +81-46-840-3812
Email: yamamotokaz@nttdocomo.co.jp
Max Hata [SL03] Swami Y. and K. Le, "DCLOR: De-correlated Loss Recovery
NTT Docomo, Inc. using SACK Option for spurious timeouts", Work in Progress,
3-5 Hikarinooka, Yokosuka, Kanagawa, 239-8536, Japan September 2003.
Phone: +81-46-840-3812
Email: hatama@s1.nttdocomo.co.jp
Full Copyright Statement [Ste07] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
Copyright (C) The IETF Trust (2008). [Yam05] Yamamoto, K., et al., "Effects of F-RTO and Eifel Response
Algorithms for W-CDMA and HSDPA networks", In Proc.
Wireless Personal Multimedia Communications (WPMC'05),
September 2005.
This document is subject to the rights, licenses and restrictions RFC 5682 F-RTO September 2009
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on Authors' Addresses
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property Pasi Sarolahti
Nokia Research Center
P.O. Box 407
FI-00045 NOKIA GROUP
Finland
Phone: +358 50 4876607
EMail: pasi.sarolahti@iki.fi
The IETF takes no position regarding the validity or scope of any Markku Kojo
Intellectual Property Rights or other rights that might be claimed University of Helsinki
to pertain to the implementation or use of the technology described P.O. Box 68
in this document or the extent to which any license under such FI-00014 UNIVERSITY OF HELSINKI
rights might or might not be available; nor does it represent that Finland
it has made any independent effort to identify any such rights. Phone: +358 9 19151305
Information on the procedures with respect to rights in RFC EMail: kojo@cs.helsinki.fi
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Kazunori Yamamoto
assurances of licenses to be made available, or the result of an NTT Docomo, Inc.
attempt made to obtain a general license or permission for the use 3-5 Hikarinooka, Yokosuka, Kanagawa, 239-8536, Japan
of such proprietary rights by implementers or users of this Phone: +81-46-840-3812
specification can be obtained from the IETF on-line IPR repository EMail: yamamotokaz@nttdocomo.co.jp
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any Max Hata
copyrights, patents or patent applications, or other proprietary NTT Docomo, Inc.
rights that may cover technology that may be required to implement 3-5 Hikarinooka, Yokosuka, Kanagawa, 239-8536, Japan
this standard. Please address the information to the IETF at ietf- Phone: +81-46-840-3812
ipr@ietf.org. EMail: hatama@s1.nttdocomo.co.jp
 End of changes. 135 change blocks. 
741 lines changed or deleted 719 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/