draft-ietf-tcpm-frto-02.txt   rfc4138.txt 
Internet Engineering Task Force P. Sarolahti
INTERNET DRAFT Nokia Research Center Network Working Group P. Sarolahti
File: draft-ietf-tcpm-frto-02.txt M. Kojo Request for Comments: 4138 Nokia Research Center
Category: Experimental M. Kojo
University of Helsinki University of Helsinki
November, 2004 August 2005
Expires: May, 2005
Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
Spurious Retransmission Timeouts with TCP and SCTP Spurious Retransmission Timeouts with TCP and the
Stream Control Transmission Protocol (SCTP)
Status of this Memo
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been disclosed,
and any of which we become aware will be disclosed, in accordance
with RFC 3668.
By submitting this Internet-Draft, we accept the provisions of
Section 3 of RFC 3667 (BCP 78).
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six 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 Status of This Memo
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This memo defines an Experimental Protocol for the Internet
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
Spurious retransmission timeouts cause suboptimal TCP performance, Spurious retransmission timeouts cause suboptimal TCP performance
because they often result in unnecessary retransmission of the last because they often result in unnecessary retransmission of the last
window of data. This document describes the F-RTO detection algorithm window of data. This document describes the F-RTO detection
for detecting spurious TCP retransmission timeouts. F-RTO is a TCP algorithm for detecting spurious TCP retransmission timeouts. F-RTO
sender-only algorithm that does not require any TCP options to is a TCP sender-only algorithm that does not require any TCP options
operate. After retransmitting the first unacknowledged segment to operate. After retransmitting the first unacknowledged segment
triggered by a timeout, the F-RTO algorithm at a TCP sender monitors triggered by a timeout, the F-RTO algorithm of the TCP sender
the incoming acknowledgments to determine whether the timeout was monitors the incoming acknowledgments to determine whether the
spurious and to decide whether to send new segments or retransmit timeout was spurious. It then decides whether to send new segments
unacknowledged segments. The algorithm effectively helps to avoid or retransmit unacknowledged segments. The algorithm effectively
additional unnecessary retransmissions and thereby improves TCP helps to avoid additional unnecessary retransmissions and thereby
performance in case of a spurious timeout. The F-RTO algorithm can improves TCP performance in the case of a spurious timeout. The
also be applied to SCTP. F-RTO algorithm can also be applied to the Stream Control
Transmission Protocol (SCTP).
Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2
2. F-RTO Algorithm . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . 4
2.1 The Algorithm . . . . . . . . . . . . . . . . . . . . . 5 2. F-RTO Algorithm . . . . . . . . . . . . . . . . . . . . . 4
2.2 Discussion . . . . . . . . . . . . . . . . . . . . . . 6 2.1. The Algorithm . . . . . . . . . . . . . . . . . . . 5
3. SACK-enhanced version of the F-RTO algorithm . . . . . . . . 8 2.2. Discussion . . . . . . . . . . . . . . . . . . . . 6
4. Taking Actions after Detecting Spurious RTO . . . . . . . . . 10 3. SACK-Enhanced Version of the F-RTO Algorithm . . . . . . 8
5. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. Taking Actions after Detecting Spurious RTO . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. SCTP Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix A: Scenarios . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References. . . . . . . . . . . . . . . . 12
Appendix B: SACK-enhanced F-RTO and Fast Recovery . . . . . . . . 19 8.2. Informative References. . . . . . . . . . . . . . . 13
Appendix C: Discussion on Window Limited Cases . . . . . . . . . 20 Appendix A: Scenarios . . . . . . . . . . . . . . . . . . . . 15
Appendix B: SACK-Enhanced F-RTO and Fast Recovery . . . . . . 20
Appendix C: Discussion of Window-Limited Cases . . . . . . . 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 incoming triggering retransmissions. First, the TCP sender relies on incoming
duplicate ACKs, which indicate that the receiver is missing some of duplicate ACKs, which indicate that the receiver is missing some of
the data. After a required number of successive duplicate ACKs have the data. After a required number of successive duplicate ACKs have
arrived at the sender, it retransmits the first unacknowledged arrived at the sender, it retransmits the first unacknowledged
segment [APS99] and continues with a loss recovery algorithm such as segment [APS99] and continues with a loss recovery algorithm such as
NewReno [FHG04] or SACK-based loss recovery [BAFW03]. Second, the TCP NewReno [FHG04] or SACK-based loss recovery [BAFW03]. Second, the
sender maintains a retransmission timer which triggers retransmission TCP sender maintains a retransmission timer which triggers
of segments, if they have not been acknowledged before the retransmission of segments, if they have not been acknowledged before
retransmission timeout (RTO) expires. When the retransmission timeout the retransmission timeout (RTO) expires. When the retransmission
occurs, the TCP sender enters the RTO recovery where the congestion timeout occurs, the TCP sender enters the RTO recovery where the
window is initialized to one segment and unacknowledged segments are congestion window is initialized to one segment and unacknowledged
retransmitted using the slow-start algorithm. The retransmission segments are retransmitted using the slow-start algorithm. The
timer is adjusted dynamically based on the measured round-trip times retransmission timer is adjusted dynamically, based on the measured
[PA00]. 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 whole the sender, usually triggering unnecessary retransmissions of a whole
window of segments during the RTO recovery. Furthermore, after a window of segments during the RTO recovery. Furthermore, after a
spurious retransmission timeout a conventional TCP sender increases spurious retransmission timeout, a conventional TCP sender increases
the congestion window on each late acknowledgment in slow start, the congestion window on each late acknowledgment in slow start.
injecting a large number of data segments to the network within one This injects a large number of data segments into the network within
round-trip time, thus violating the packet conservation principle one round-trip time, thus violating the packet 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 delay spikes on transmission because of actions taken during a
hand-off. Second, arrival of competing traffic, possibly with higher hand-off. Second, given a low-bandwidth link or some other change in
priority, on a low-bandwidth link or some other change in available available bandwidth, arrival of competing traffic (possibly with
bandwidth can cause a sudden increase of round-trip time which may higher priority) can cause a sudden increase of round-trip time.
trigger a spurious retransmission timeout. A persistently reliable This may trigger a spurious retransmission timeout. A persistently
link layer can also cause a sudden delay when a data frame and reliable link layer can also cause a sudden delay when a data frame
several retransmissions of it are lost for some reason. This document and several retransmissions of it are lost for some reason. This
does not distinguish between the different causes of such a delay document does not distinguish between the different causes of such a
spike, but discusses the spurious retransmission timeouts caused by a delay spike. Rather, it discusses the spurious retransmission
delay spike in general. timeouts caused by a delay spike in general.
This document describes the F-RTO detection algorithm. It is based on This document describes the F-RTO detection algorithm. It is based
the detection mechanism of the "Forward RTO-Recovery" (F-RTO) on the detection mechanism of the "Forward RTO-Recovery" (F-RTO)
algorithm [SKR03] that is used for detecting spurious retransmission algorithm [SKR03] that is used for detecting spurious retransmission
timeouts and thus avoiding unnecessary retransmissions following the timeouts and thus avoids unnecessary retransmissions following the
retransmission timeout. When the timeout is not spurious, the F-RTO retransmission timeout. When the timeout is not spurious, the F-RTO
algorithm reverts back to the conventional RTO recovery algorithm and algorithm reverts back to the conventional RTO recovery algorithm,
therefore has similar behavior and performance. In contrast to and therefore has similar behavior and performance. In contrast to
alternative algorithms proposed for detecting unnecessary alternative algorithms proposed for detecting unnecessary
retransmissions (Eifel [LK00], [LM03] and DSACK-based algorithms retransmissions (Eifel [LK00], [LM03] and DSACK-based algorithms
[BA04]), F-RTO does not require any TCP options for its operation, [BA04]), F-RTO does not require any TCP options for its operation,
and it can be implemented by modifying only the TCP sender. The and it can be implemented by modifying only the TCP sender. The
Eifel algorithm uses TCP timestamps [BBJ92] for detecting a spurious Eifel algorithm uses TCP timestamps [BBJ92] for detecting a spurious
timeout upon arrival of the first acknowledgment after the timeout upon arrival of the first acknowledgment after the
retransmission. The DSACK-based algorithms require that the TCP retransmission. The DSACK-based algorithms require that the TCP
Selective Acknowledgment Option [MMFR96] with the DSACK extension Selective Acknowledgment Option [MMFR96], with the DSACK extension
[FMMP00] is in use. With DSACK, the TCP receiver can report if it has [FMMP00], is in use. With DSACK, the TCP receiver can report if it
received a duplicate segment, making it possible for the sender to has received a duplicate segment, enabling the sender to detect
detect afterwards whether it has retransmitted segments afterwards whether it has retransmitted segments unnecessarily. The
unnecessarily. The F-RTO algorithm only attempts to detect and avoid F-RTO algorithm only attempts to detect and avoid unnecessary
unnecessary retransmissions after an RTO. Eifel and DSACK can also be retransmissions after an RTO. Eifel and DSACK can also be used for
used for detecting unnecessary retransmissions caused by other detecting unnecessary retransmissions caused by other events, such as
events, for example packet reordering. packet reordering.
When an RTO expires, the F-RTO sender retransmits the first When an RTO expires, the F-RTO sender retransmits the first
unacknowledged segment as usual [APS99]. Deviating from the normal unacknowledged segment as usual [APS99]. Deviating from the normal
operation after a timeout, it then tries to transmit new, previously operation after a timeout, it then tries to transmit new, previously
unsent data, for the first acknowledgment that arrives after the unsent data, for the first acknowledgment that arrives after the
timeout given that the acknowledgment advances the window. If the timeout, given that the acknowledgment advances the window. If the
second acknowledgment that arrives after the timeout also advances second acknowledgment that arrives after the timeout advances the
the window, i.e., acknowledges data that was not retransmitted, the window (i.e., acknowledges data that was not retransmitted), the F-
F-RTO sender declares the timeout spurious and exits the RTO RTO sender declares the timeout spurious and exits the RTO recovery.
recovery. However, if either of these two acknowledgments is a However, if either of these two acknowledgments is a duplicate ACK,
duplicate ACK, there is no sufficient evidence of a spurious timeout; there will not be sufficient evidence of a spurious timeout.
therefore the F-RTO sender retransmits the unacknowledged segments in Therefore, the F-RTO sender retransmits the unacknowledged segments
slow start similarly to the traditional algorithm. With a in slow start similarly to the traditional algorithm. With a
SACK-enhanced version of the F-RTO algorithm, spurious timeouts may SACK-enhanced version of the F-RTO algorithm, spurious timeouts may
be detected even if duplicate ACKs arrive after an RTO be detected even if duplicate ACKs arrive after an RTO
retransmission. retransmission.
The F-RTO algorithm can also be applied to the Stream Control The F-RTO algorithm can also be applied to the Stream Control
Transmission Protocol (SCTP) [Ste00], because SCTP has similar Transmission Protocol (SCTP) [Ste00], because SCTP has acknowledgment
acknowledgment and packet retransmission concepts as TCP. For and packet retransmission concepts similar to TCP. For convenience,
convenience, this document mostly refers to TCP, but the algorithms this document mostly refers to TCP, but the algorithms and other
and other discussion are valid for SCTP as well. discussion are valid for SCTP as well.
This document is organized as follows. Section 2 describes the basic This document is organized as follows. Section 2 describes the basic
F-RTO algorithm. Section 3 outlines an optional enhancement to the F-RTO algorithm. Section 3 outlines an optional enhancement to the
F-RTO algorithm that takes advantage of the TCP SACK option. Section F-RTO algorithm that takes advantage of the TCP SACK option. Section
4 discusses the possible actions to be taken after detecting a 4 discusses the possible actions to be taken after detecting a
spurious RTO. Section 5 gives considerations on applying F-RTO with spurious RTO. Section 5 gives considerations on applying F-RTO with
SCTP, and Section 6 discusses the security considerations. SCTP, and Section 6 discusses the security considerations.
1.1. Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119].
2. F-RTO Algorithm 2. 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]. the sender waited longer for an acknowledgment to arrive [LM03].
F-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 RTO timeout. Otherwise, the TCP behavior remains the same. When the RTO
expires the F-RTO algorithm monitors incoming acknowledgments and expires, the F-RTO algorithm monitors incoming acknowledgments and if
declares a timeout spurious, if the TCP sender gets an acknowledgment the TCP sender gets an acknowledgment for a segment that was not
for a segment that was not retransmitted due to timeout. The actions retransmitted due to timeout, the F-RTO algorithm declares a timeout
taken in response to a spurious timeout are not specified in this spurious. The actions taken in response to a spurious timeout are
document, but we discuss some alternatives in Section 4. This section not specified in this document, but we discuss some alternatives in
introduces the algorithm and then discusses the different steps of Section 4. This section introduces the algorithm and then discusses
the algorithm in more detail. the different steps of the algorithm in 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, when the (indicating a spurious retransmission timeout) or FALSE (indicating
timeout is not declared spurious, and the TCP sender should follow that the timeout is not declared spurious), and the TCP sender should
the conventional RTO recovery algorithm. follow the conventional RTO recovery algorithm.
2.1. The Algorithm 2.1. The Algorithm
A TCP sender MAY implement the basic F-RTO algorithm, and if it A TCP sender MAY implement the basic F-RTO algorithm. If it chooses
chooses to apply the algorithm, the following steps MUST be taken to apply the algorithm, the following steps MUST be taken after the
after the retransmission timer expires. If the sender implements some retransmission timer expires. If the sender implements some loss
loss recovery algorithm other than Reno or NewReno [FHG04], F-RTO recovery algorithm other than Reno or NewReno [FHG04], the F-RTO
algorithm SHOULD NOT be entered when earlier fast recovery is algorithm SHOULD NOT be entered when earlier fast recovery is
underway. underway.
1) When RTO expires, retransmit the first unacknowledged segment and 1) When RTO expires, retransmit the first unacknowledged segment and
set SpuriousRecovery to FALSE. Also, store the highest sequence set SpuriousRecovery to FALSE. Also, store the highest sequence
number transmitted so far in variable "recover". number transmitted so far in variable "recover".
2) When the first acknowledgment after the RTO retransmission arrives 2) When the first acknowledgment after the RTO retransmission arrives
at the sender, the sender chooses the following actions depending at the sender, the sender chooses one of the following actions,
on whether the ACK advances the window or whether it is a depending on whether the ACK advances the window or whether it is
duplicate ACK. a duplicate ACK.
a) If the acknowledgment is a duplicate ACK OR it acknowledges a a) If the acknowledgment is a duplicate ACK OR it acknowledges a
sequence number equal to the value of "recover" OR it does not sequence number equal to the value of "recover" OR it does not
acknowledge all of the data that was retransmitted in step 1, acknowledge all of the data that was retransmitted in step 1,
revert to the conventional RTO recovery and continue by revert to the conventional RTO recovery and continue by
retransmitting unacknowledged data in slow start. Do not enter retransmitting unacknowledged data in slow start. Do not enter
step 3 of this algorithm. The SpuriousRecovery variable remains step 3 of this algorithm. The SpuriousRecovery variable
as FALSE. remains as FALSE.
b) Else, if the acknowledgment advances the window AND it is below b) Else, if the acknowledgment advances the window AND it is below
the value of "recover", transmit up to two new (previously the value of "recover", transmit up to two new (previously
unsent) segments and enter step 3 of this algorithm. If the TCP unsent) segments and enter step 3 of this algorithm. If the
sender does not have enough unsent data, it can send only one TCP sender does not have enough unsent data, it can send only
segment. In addition, the TCP sender MAY override the Nagle one segment. In addition, the TCP sender MAY override the
algorithm [Nag84] and immediately send a segment if needed. Nagle algorithm [Nag84] and immediately send a segment if
Note that sending two segments in this step is allowed by TCP needed. Note that sending two segments in this step is allowed
congestion control requirements [APS99]: An F-RTO TCP sender by TCP congestion control requirements [APS99]: An F-RTO TCP
simply chooses different segments to transmit. sender simply chooses different segments to transmit.
If the TCP sender does not have any new data to send, or the If the TCP sender does not have any new data to send, or the
advertised window prohibits new transmissions, the recommended advertised window prohibits new transmissions, the recommended
action is to skip step 3 of this algorithm and continue with action is to skip step 3 of this algorithm and continue with
slow start retransmissions following the conventional RTO slow start retransmissions, following the conventional RTO
recovery algorithm. However, alternative ways of handling the recovery algorithm. However, alternative ways of handling the
window limited cases that could result in better performance window-limited cases that could result in better performance
are discussed in Appendix C. are discussed in Appendix C.
3) When the second acknowledgment after the RTO retransmission 3) When the second acknowledgment after the RTO retransmission
arrives at the sender, the TCP sender either declares the timeout arrives at the sender, the TCP sender either declares the timeout
spurious, or starts retransmitting the unacknowledged segments. spurious, or starts retransmitting the unacknowledged segments.
a) If the acknowledgment is a duplicate ACK, set the congestion a) If the acknowledgment is a duplicate ACK, set the congestion
window to no more than 3 * MSS, and continue with the slow window to no more than 3 * MSS, and continue with the slow
start algorithm retransmitting unacknowledged segments. start algorithm retransmitting unacknowledged segments. The
Congestion window can be set to 3 * MSS, because two round-trip congestion window can be set to 3 * MSS, because two round-trip
times have elapsed since the RTO, and a conventional TCP sender times have elapsed since the RTO, and a conventional TCP sender
would have increased cwnd to 3 during the same time. Leave would have increased cwnd to 3 during the same time. Leave
SpuriousRecovery set to FALSE. SpuriousRecovery set to FALSE.
b) If the acknowledgment advances the window, i.e. it acknowledges b) If the acknowledgment advances the window (i.e., if it
data that was not retransmitted after the timeout, declare the acknowledges data that was not retransmitted after the
timeout spurious, set SpuriousRecovery to SPUR_TO and set the timeout), declare the timeout spurious, set SpuriousRecovery to
value of "recover" variable to SND.UNA, the oldest SPUR_TO, and set the value of the "recover" variable to SND.UNA
unacknowledged sequence number [Pos81]. (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. Since duplicate ACKs acknowledgments after a retransmission timeout. Because duplicate
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 TCP information. Therefore, it is prudent to follow the conventional TCP
recovery in those cases. recovery in those cases.
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 it 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 have successfully been delivered to the unacknowledged segments were successfully delivered to the TCP
the TCP receiver before the retransmission timeout. Therefore the receiver before the retransmission timeout. Therefore, the timeout
timeout cannot be declared spurious in this case. cannot be declared spurious in this case.
If the first acknowledgment after the RTO retransmission does not If the first acknowledgment after the RTO retransmission does not
acknowledge all of the data that was retransmitted in step 1, the TCP acknowledge all of the data that was retransmitted in step 1, the TCP
sender reverts to the conventional RTO recovery. Otherwise, a sender reverts to the conventional RTO recovery. Otherwise, a
malicious receiver acknowledging partial segments could cause the malicious receiver acknowledging partial segments could cause the
sender to declare the timeout spurious in a case where data was lost. 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 TCP sender is allowed to send two new segments in algorithm
branch (2b), because the conventional TCP sender would transmit two branch (2b) because the conventional TCP sender would transmit two
segments when the first new ACK arrives after the RTO retransmission. segments when the first new ACK arrives after the RTO retransmission.
If sending new data is not possible in algorithm branch (2b), or the If sending new data is not possible in algorithm branch (2b), or if
receiver window limits the transmission, the TCP sender has to send the receiver window limits the transmission, the TCP sender has to
something in order to prevent the TCP transfer from stalling. If no send something in order to prevent the TCP transfer from stalling.
segments were sent, the pipe between sender and receiver might run If no segments were sent, the pipe between sender and receiver might
out of segments, and no further acknowledgments would arrive. run out of segments, and no further acknowledgments would arrive.
Therefore, in the window limited case the recommendation is to revert Therefore, in the window-limited case, the recommendation is to
to the conventional RTO recovery with slow start retransmissions. revert to the conventional RTO recovery with slow start
Appendix C discusses some alternative solutions for window limited retransmissions. Appendix C discusses some alternative solutions for
situations. window-limited situations.
If the retransmission timeout is declared spurious, the TCP sender If the retransmission timeout is declared spurious, the TCP sender
sets the value of the "recover" variable to SND.UNA in order to allow sets the value of the "recover" variable to SND.UNA in order to allow
fast retransmit [FHG04]. The "recover" variable was proposed for fast retransmit [FHG04]. The "recover" variable was proposed for
avoiding unnecessary multiple fast retransmits when RTO expires avoiding unnecessary, multiple fast retransmits when RTO expires
during fast recovery with NewReno TCP. As the sender does not during fast recovery with NewReno TCP. Because the sender
retransmit other segments but the one that triggered the timeout, the retransmits only the segment that triggered the timeout, the problem
problem of unnecessary multiple fast retransmits [FHG04] cannot of unnecessary multiple fast retransmits [FHG04] cannot occur.
occur. Therefore, if there are three duplicate ACKs arriving at the Therefore, if three duplicate ACKs arrive at the sender after the
sender after the timeout, they are likely to indicate a packet loss, timeout, they probably indicate a packet loss, and thus fast
hence fast retransmit should be used to allow efficient recovery. If retransmit should be used to allow efficient recovery. If there are
there are not enough duplicate ACKs arriving at the sender after a not enough duplicate ACKs arriving at the sender after a packet loss,
packet loss, the retransmission timer expires another time and the the retransmission timer expires again and the sender enters step 1
sender enters step 1 of this algorithm. of this algorithm.
When the timeout is declared spurious, the TCP sender cannot detect When the timeout is declared spurious, the TCP sender cannot detect
whether the unnecessary RTO retransmission was lost. In principle the whether the unnecessary RTO retransmission was lost. In principle,
loss of the RTO retransmission should be taken as a congestion the loss of the RTO retransmission should be taken as a congestion
signal, and thus there is a small possibility that the F-RTO sender signal. Thus, there is a small possibility that the F-RTO sender
violates the congestion control rules, if it chooses to fully revert will violate the congestion control rules, if it chooses to fully
congestion control parameters after detecting a spurious timeout. The revert congestion control parameters after detecting a spurious
Eifel detection algorithm has a similar property, while the DSACK timeout. The Eifel detection algorithm has a similar property, while
option can be used to detect whether the retransmitted segment was the DSACK option can be used to detect whether the retransmitted
successfully delivered to the receiver. segment was successfully delivered to the receiver.
The F-RTO algorithm has a side-effect on the TCP round-trip time 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 measurement. Because the TCP sender can avoid most of the
retransmissions after detecting a spurious timeout, the sender is unnecessary retransmissions after detecting a spurious timeout, the
able to take round-trip time samples on the delayed segments. If the sender is able to take round-trip time samples on the delayed
regular RTO recovery was used without TCP timestamps, this would not segments. If the regular RTO recovery was used without TCP
be possible due to the retransmission ambiguity. As a result, the RTO timestamps, this would not be possible due to the retransmission
is likely to have more accurate and larger values with F-RTO than ambiguity. As a result, the RTO is likely to have more accurate and
with the regular TCP after a spurious timeout that was triggered due larger values with F-RTO than with the regular TCP after a spurious
to delayed segments. We believe this is an advantage in the networks timeout that was triggered due to delayed segments. We believe this
that are prone to delay spikes. is an advantage in the networks that are prone to delay spikes.
It is possible that the F-RTO algorithm does not always avoid There are some situations where the F-RTO algorithm may not avoid
unnecessary retransmissions after a spurious timeout. If packet unnecessary retransmissions after a spurious timeout. If packet
reordering or packet duplication occurs on the segment that triggered reordering or packet duplication occurs on the segment that triggered
the spurious timeout, the F-RTO algorithm may not detect the spurious the spurious timeout, the F-RTO algorithm may not detect the spurious
timeout due to incoming duplicate ACKs. Additionally, if a spurious timeout due to incoming duplicate ACKs. Additionally, if a spurious
timeout occurs during fast recovery, the F-RTO algorithm often cannot timeout occurs during fast recovery, the F-RTO algorithm often cannot
detect the spurious timeout, because the segments transmitted before detect the spurious timeout because the segments that were
the fast recovery trigger duplicate ACKs. However, we consider these transmitted before the fast recovery trigger duplicate ACKs.
cases relatively rare, and note that in cases where F-RTO fails to However, we consider these cases rare, and note that in cases where
detect the spurious timeout, it retransmits the unacknowledged F-RTO fails to detect the spurious timeout, it retransmits the
segments in slow start and thus performs similarly to the regular RTO unacknowledged segments in slow start, and thus performs similarly to
recovery. 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 makes use of the TCP Selective Acknowledgment Option [MMFR96]. that uses the TCP Selective Acknowledgment Option [MMFR96]. By using
By using the SACK option the TCP sender can detect spurious timeouts the SACK option, the TCP sender detects spurious timeouts in most of
in most of the cases when packet reordering or packet duplication is the cases when packet reordering or packet duplication is present.
present. The difference to the basic F-RTO algorithm is that the If the SACK blocks acknowledge new data that was not transmitted
sender may declare timeout spurious even when duplicate ACKs follow after the RTO retransmission, the sender may declare the timeout
the RTO, if the SACK blocks acknowledge new data that was not spurious, even when duplicate ACKs follow the RTO.
transmitted after the RTO retransmission.
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 implement the enabled for a TCP connection, a TCP sender MAY implement the
SACK-enhanced F-RTO algorithm. If the sender applies the SACK-enhanced F-RTO algorithm. If the sender applies the
SACK-enhanced F-RTO algorithm, it MUST follow the steps below. This SACK-enhanced F-RTO algorithm, it MUST follow the steps below. This
algorithm SHOULD NOT be applied, if the TCP sender is already in SACK algorithm SHOULD NOT be applied if the TCP sender is already in SACK
loss recovery when retransmission timeout occurs. However, it should loss recovery when retransmission timeout occurs. However, when
be possible to apply the principle of F-RTO within certain retransmission timeout occurs during existing loss recovery, it
limitations also when retransmission timeout occurs during existing should be possible to apply the principle of F-RTO within certain
loss recovery. While this is a topic of further research, Appendix B limitations. This is a topic for further research. Appendix B
briefly discusses the related issues. briefly discusses the related issues.
The steps of the SACK-enhanced version of the F-RTO algorithm are as
follows.
1) When the RTO expires, retransmit the first unacknowledged segment 1) When the RTO expires, retransmit the first unacknowledged segment
and set SpuriousRecovery to FALSE. Set variable "recover" to and set SpuriousRecovery to FALSE. Set variable "recover" to
indicate the highest segment transmitted so far. Following the indicate the highest segment transmitted so far. Following the
recommendation in SACK specification [MMFR96], reset the SACK recommendation in SACK specification [MMFR96], reset the SACK
scoreboard. scoreboard.
2) Wait until the acknowledgment for the data retransmitted due to 2) Wait until the acknowledgment of the data retransmitted due to the
the timeout arrives at the sender. If duplicate ACKs arrive before timeout arrives at the sender. If duplicate ACKs arrive before
the cumulative acknowledgment for retransmitted data, adjust the the cumulative acknowledgment for retransmitted data, adjust the
scoreboard according to the incoming SACK information but stay in scoreboard according to the incoming SACK information. Stay in
step 2 waiting for the next new acknowledgment. If RTO expires step 2 and wait for the next new acknowledgment. If RTO expires
again, go to step 1 of the algorithm. again, go to step 1 of the algorithm.
a) if a cumulative ACK acknowledges a sequence number equal to a) if a cumulative ACK acknowledges a sequence number equal to
"recover", revert to the conventional RTO recovery and set "recover", revert to the conventional RTO recovery and set the
congestion window to no more than 2 * MSS, like a regular TCP congestion window to no more than 2 * MSS, like a regular TCP
would do. Do not enter step 3 of this algorithm. would do. Do not enter step 3 of this algorithm.
b) else, if a cumulative ACK acknowledges a sequence number b) else, if a cumulative ACK acknowledges a sequence number
smaller than "recover" but larger than SND.UNA, transmit up to (smaller than "recover", but larger than SND.UNA) transmit up
two new (previously unsent) segments and proceed to step 3. If to two new (previously unsent) segments and proceed to step 3.
the TCP sender is not able to transmit any previously unsent If the TCP sender is not able to transmit any previously unsent
data due to receiver window limitation or because it does not data -- either due to receiver window limitation, or because it
have any new data to send, the recommended action is to not does not have any new data to send -- the recommended action is
enter step 3 of this algorithm but continue with slow start to refrain from entering step 3 of this algorithm. Rather,
retransmissions following the conventional RTO recovery continue with slow start retransmissions following the
algorithm. conventional RTO recovery algorithm.
It is also possible to apply some of the alternatives for It is also possible to apply some of the alternatives for
handling window limited cases discussed in Appendix C. In this handling window-limited cases discussed in Appendix C. In this
case, the TCP sender should also follow the recommendations case, the TCP sender should follow the recommendations
concerning acknowledgments of retransmitted segments given in concerning acknowledgments of retransmitted segments given in
Appendix B. Appendix B.
3) The next acknowledgment arrives at the sender. Either duplicate 3) The next acknowledgment arrives at the sender. Either a duplicate
ACK or a new cumulative ACK advancing the window applies in this ACK or a new cumulative ACK (advancing the window) applies in this
step. step.
a) if the ACK acknowledges sequence number above "recover", either a) if the ACK acknowledges a sequence number above "recover",
in SACK blocks or as a cumulative ACK, set congestion window to either in SACK blocks or as a cumulative ACK, set the
no more than 3 * MSS and proceed with the conventional RTO congestion window to no more than 3 * MSS and proceed with the
recovery, retransmitting unacknowledged segments. Take this conventional RTO recovery, retransmitting unacknowledged
branch also when the acknowledgment is a duplicate ACK and it segments. Take this branch also when the acknowledgment is a
does not acknowledge any new, previously unacknowledged data duplicate ACK and it does not acknowledge any new, previously
below "recover" in the SACK blocks. Leave SpuriousRecovery set unacknowledged data below "recover" in the SACK blocks. Leave
to FALSE. SpuriousRecovery set to FALSE.
b) if the ACK does not acknowledge sequence numbers above b) if the ACK does not acknowledge sequence numbers above
"recover" AND it acknowledges data that was not acknowledged "recover" AND it acknowledges data that was not acknowledged
earlier either with cumulative acknowledgment or using SACK earlier (either with cumulative acknowledgment or using SACK
blocks, declare the timeout spurious and set SpuriousRecovery blocks), declare the timeout spurious and set SpuriousRecovery
to SPUR_TO. The retransmission timeout can be declared to SPUR_TO. The retransmission timeout can be declared
spurious, because the segment acknowledged with this ACK was spurious, because the segment acknowledged with this ACK was
transmitted before the timeout. transmitted before the timeout.
If there are unacknowledged holes between the received SACK blocks, If there are unacknowledged holes between the received SACK blocks,
those segments are retransmitted similarly to the conventional SACK those segments are retransmitted similarly to the conventional SACK
recovery algorithm [BAFW03]. If the algorithm exits with recovery algorithm [BAFW03]. If the algorithm exits with
SpuriousRecovery set to SPUR_TO, "recover" is set to SND.UNA, thus SpuriousRecovery set to SPUR_TO, "recover" is set to SND.UNA, thus
allowing fast recovery on incoming duplicate acknowledgments. allowing fast recovery on incoming duplicate acknowledgments.
4. Taking Actions after Detecting Spurious RTO 4. Taking Actions after Detecting Spurious RTO
Upon retransmission timeout, a conventional TCP sender assumes that Upon retransmission timeout, a conventional TCP sender assumes that
outstanding segments are lost and starts retransmitting the outstanding segments are lost and starts retransmitting the
unacknowledged segments. When the retransmission timeout is detected unacknowledged segments. When the retransmission timeout is detected
to be spurious, the TCP sender should not continue retransmitting to be spurious, the TCP sender should not continue retransmitting
based on the timeout. For example, if the sender was in congestion based on the timeout. For example, if the sender was in congestion
avoidance phase transmitting new previously unsent segments, it avoidance phase transmitting new, previously unsent segments, it
should continue transmitting previously unsent segments after should continue transmitting previously unsent segments after
detecting a spurious RTO. This document does not describe the detecting a spurious RTO. This document does not describe the
response to spurious timeout, but a response algorithm is described response to spurious timeouts, but a response algorithm is described
in another IETF document [LG04]. in RFC 4015 [LG04].
Additionally, different response variants to spurious retransmission Additionally, different response variants to spurious retransmission
timeout have been discussed in various research papers [SKR03, GL03, timeout have been discussed in various research papers [SKR03, GL03,
Sar03] and Internet-Drafts [SL03]. The different response Sar03] and IETF documents [SL03]. The different response
alternatives vary in whether the spurious retransmission timeout alternatives vary in whether the spurious retransmission timeout
should be taken as a congestion signal, thus causing the congestion should be taken as a congestion signal, thus causing the congestion
window or slow start threshold to be reduced at the sender, or window or slow start threshold to be reduced at the sender, or
whether the congestion control state should be fully reverted to the whether the congestion control state should be fully reverted to the
state valid prior to the retransmission timeout. state valid prior to the retransmission timeout.
5. SCTP Considerations 5. SCTP Considerations
SCTP has similar retransmission algorithms and congestion control to SCTP has similar retransmission algorithms and congestion control to
TCP. The SCTP T3-rtx timer for one destination address is maintained TCP. The SCTP T3-rtx timer for one destination address is maintained
in the same way than the TCP retransmission timer, and after a T3-rtx in the same way as the TCP retransmission timer, and after a T3-rtx
expires, an SCTP sender retransmits unacknowledged data chunks in expires, an SCTP sender retransmits unacknowledged data chunks in
slow start like TCP does. Therefore, SCTP is vulnerable to the slow start like TCP does. Therefore, SCTP is vulnerable to the
negative effects of the spurious retransmission timeouts similarly to negative effects of the spurious retransmission timeouts similarly to
TCP. Due to similar RTO recovery algorithms, F-RTO algorithm logic TCP. Due to similar RTO recovery algorithms, F-RTO algorithm logic
can be applied also to SCTP. Since SCTP uses selective can be applied also to SCTP. Since SCTP uses selective
acknowledgments, the SACK-based variant of the algorithm is acknowledgments, the SACK-based variant of the algorithm is
recommended, although the basic version can also be applied to SCTP. recommended, although the basic version can also be applied to SCTP.
However, SCTP contains features that are not present with TCP that However, SCTP contains features that are not present with TCP that
need to be discussed when applying the F-RTO algorithm. need to be discussed when applying the F-RTO algorithm.
skipping to change at page 11, line 25 skipping to change at page 11, line 7
retransmission arrives back at the sender before the acknowledgments retransmission arrives back at the sender before the acknowledgments
of the original transmissions arrive. If this happens, a possible of the original transmissions arrive. If this happens, a possible
loss of the original transmission of the data chunk that was loss of the original transmission of the data chunk that was
retransmitted due to the spurious timeout may remain undetected when retransmitted due to the spurious timeout may remain undetected when
applying the F-RTO algorithm. Because the timeout was caused by a applying the F-RTO algorithm. Because the timeout was caused by a
delay spike, and it was spurious in that respect, a suitable response delay spike, and it was spurious in that respect, a suitable response
is to continue by sending new data. However, if the original is to continue by sending new data. However, if the original
transmission was lost, fully reverting the congestion control transmission was lost, fully reverting the congestion control
parameters is too aggressive. Therefore, taking conservative actions parameters is too aggressive. Therefore, taking conservative actions
on congestion control is recommended, if the SCTP association is on congestion control is recommended, if the SCTP association is
multi-homed and retransmissions go to alternative address. The multi-homed and retransmissions go to alternative addresses. The
information in duplicate TSNs can be then used for reverting information in duplicate TSNs can be then used for reverting
congestion control, if desired [BA04]. congestion control, if desired [BA04].
Note that the forward transmissions made in F-RTO algorithm step (2b) Note that the forward transmissions made in F-RTO algorithm step (2b)
should be destined to the primary address, since they are not should be destined to the primary address, since they are not
retransmissions. retransmissions.
When making a retransmission, a SCTP sender can bundle a number of When making a retransmission, an SCTP sender can bundle a number of
unacknowledged data chunks and include them in the same packet. This unacknowledged data chunks and include them in the same packet. This
needs to be considered when implementing F-RTO for SCTP. The basic needs to be considered when implementing F-RTO for SCTP. The basic
principle of F-RTO still holds: in order to declare the timeout principle of F-RTO still holds: in order to declare the timeout
spurious, the sender must get an acknowledgment for a data chunk that spurious, the sender must get an acknowledgment for a data chunk that
was not retransmitted after the retransmission timeout. In other was not retransmitted after the retransmission timeout. In other
words, acknowledgments of data chunks that were bundled in RTO words, acknowledgments of data chunks that were bundled in RTO
retransmission must not be used for declaring the timeout spurious. retransmission must not be used for declaring the timeout spurious.
6. Security Considerations 6. Security Considerations
The main security threat regarding F-RTO is the possibility of a The main security threat regarding F-RTO is the possibility that a
receiver misleading the sender to set too large a congestion window receiver could mislead the sender into setting too large a congestion
after an RTO. There are two possible ways a malicious receiver could window after an RTO. There are two possible ways a malicious
trigger a wrong output from the F-RTO algorithm. First, the receiver receiver could trigger a wrong output from the F-RTO algorithm.
can acknowledge data that it has not received. Second, it can delay First, the receiver can acknowledge data that it has not received.
acknowledgment of a segment it has received earlier, and acknowledge Second, it can delay acknowledgment of a segment it has received
the segment after the TCP sender has been deluded to enter algorithm earlier, and acknowledge the segment after the TCP sender has been
step 3. deluded to enter algorithm step 3.
If the receiver acknowledges a segment it has not really received, If the receiver acknowledges a segment it has not really received,
the sender can be led to declare spurious timeout in F-RTO algorithm the sender can be led to declare spurious timeout in the F-RTO
step 3. However, since this causes the sender to have incorrect algorithm, step 3. However, because the sender will have an
state, it cannot retransmit the segment that has never reached the incorrect state, it cannot retransmit the segment that has never
receiver. Therefore, this attack is unlikely to be useful for the reached the receiver. Therefore, this attack is unlikely to be
receiver to maliciously gain a larger congestion window. useful for the receiver to maliciously gain a larger congestion
window.
A common case for a retransmission timeout is that a fast A common case for a retransmission timeout is that a fast
retransmission of a segment is lost. If all other segments have been retransmission of a segment is lost. If all other segments have been
received, the RTO retransmission causes the whole window to be received, the RTO retransmission causes the whole window to be
acknowledged at once. This case is recognized in F-RTO algorithm acknowledged at once. This case is recognized in F-RTO algorithm
branch (2a). However, if the receiver only acknowledges one segment branch (2a). However, if the receiver only acknowledges one segment
after receiving the RTO retransmission, and then the rest of the after receiving the RTO retransmission, and then the rest of the
segments, it could cause the timeout to be declared spurious when it segments, it could cause the timeout to be declared spurious when it
is not. Therefore, it is suggested that when an RTO expires during is not. Therefore, it is suggested that, when an RTO expires during
fast recovery phase, the sender would not fully revert the congestion fast recovery phase, the sender would not fully revert the congestion
window even if the timeout was declared spurious, but reduce the window even if the timeout was declared spurious. Instead, the
congestion window to 1. sender would reduce the congestion window to 1.
If there are more than one segments missing at the time when a
retransmission timeout occurs, the receiver does not benefit from
misleading the sender to declare a spurious timeout, because the
sender would then have to go through another recovery period to
retransmit the missing segments, usually after an RTO has elapsed.
7. IANA Considerations
This document has no actions for IANA. 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.
8. Acknowledgments 7. Acknowledgements
We are grateful to Reiner Ludwig, Andrei Gurtov, Josh Blanton, Mark We are grateful to Reiner Ludwig, Andrei Gurtov, Josh Blanton, Mark
Allman, Sally Floyd, Yogesh Swami, Mika Liljeberg, Ivan Arias Allman, Sally Floyd, Yogesh Swami, Mika Liljeberg, Ivan Arias
Rodriguez, Sourabh Ladha, Martin Duke, Motoharu Miyake, Ted Faber, Rodriguez, Sourabh Ladha, Martin Duke, Motoharu Miyake, Ted Faber,
Samu Kontinen, and Kostas Pentikousis for the discussion and feedback Samu Kontinen, and Kostas Pentikousis for the discussion and feedback
contributed to this text. contributed to this text.
9. References 8. References
Normative References 8.1. Normative References
[APS99] M. Allman, V. Paxson, and W. Stevens. TCP Congestion [APS99] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control. RFC 2581, April 1999. Control", RFC 2581, April 1999.
[BAFW03] E. Blanton, M. Allman, K. Fall, and L. Wang. A Conservative [BAFW03] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
Selective Acknowledgment (SACK)-based Loss Recovery Conservative Selective Acknowledgment (SACK)-based Loss
Algorithm for TCP. RFC 3517, April 2003. Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC2119] S. Bradner. Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels. RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[FHG04] S. Floyd, T. Henderson, and A. Gurtov. The NewReno [FHG04] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
Modification to TCP's Fast Recovery Algorithm. RFC 3782, Modification to TCP's Fast Recovery Algorithm", RFC 3782,
April 2004. April 2004.
[MMFR96] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP [MMFR96] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options. RFC 2018, October 1996. Selective Acknowledgement Options", RFC 2018, October 1996.
[PA00] V. Paxson and M. Allman. Computing TCP's Retransmission [PA00] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer. RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[Pos81] J. Postel. Transmission Control Protocol. RFC 793, [Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC
September 1981. 793, September 1981.
[Ste00] R. Stewart, et. al. Stream Control Transmission Protocol. [Ste00] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang,
L., and V. Paxson, "Stream Control Transmission Protocol",
RFC 2960, October 2000. RFC 2960, October 2000.
Informative References 8.2. Informative References
[ABF01] M. Allman, H. Balakrishnan, and S. Floyd. Enhancing TCP's [ABF01] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
Loss Recovery Using Limited Transmit. RFC 3042, January TCP's Loss Recovery Using Limited Transmit", RFC 3042,
2001. January 2001.
[BA04] E. Blanton and M. Allman. Using TCP Duplicate Selective [BA04] Blanton, E. and M. Allman, "Using TCP Duplicate Selective
Acknowledgment (DSACKs) and Stream Control Transmission Acknowledgement (DSACKs) and Stream Control Transmission
Protocol (SCTP) Duplicate Transmission Sequence Numbers Protocol (SCTP) Duplicate Transmission Sequence Numbers
(TSNs) to Detect Spurious Retransmissions. RFC 3708, (TSNs) to Detect Spurious Retransmissions", RFC 3708,
February 2004. February 2004.
[BBJ92] D. Borman, R. Braden, and V. Jacobson. TCP Extensions for [BBJ92] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
High Performance. RFC 1323, May 1992. for High Performance", RFC 1323, May 1992.
[FMMP00] S. Floyd, J. Mahdavi, M. Mathis, and M. Podolsky. An [FMMP00] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgment (SACK) Option to Extension to the Selective Acknowledgement (SACK) Option
TCP. RFC 2883, July 2000. for TCP", RFC 2883, July 2000.
[GL02] A. Gurtov and R. Ludwig. Evaluating the Eifel Algorithm for [GL02] A. Gurtov and R. Ludwig. Evaluating the Eifel Algorithm
TCP in a GPRS Network. In Proc. of European Wireless, for TCP in a GPRS Network. In Proc. of European Wireless,
Florence, Italy, February 2002. Florence, Italy, February 2002.
[GL03] A. Gurtov and R. Ludwig, Responding to Spurious Timeouts in [GL03] A. Gurtov and R. Ludwig, Responding to Spurious Timeouts in
TCP. In Proceedings of IEEE INFOCOM 03, San Francisco, CA, TCP. In Proceedings of IEEE INFOCOM 03, San Francisco, CA,
USA, March 2003. USA, March 2003.
[Jac88] V. Jacobson. Congestion Avoidance and Control. In [Jac88] V. Jacobson. Congestion Avoidance and Control. In
Proceedings of ACM SIGCOMM 88. Proceedings of ACM SIGCOMM 88.
[LG04] R. Ludwig and A. Gurtov. The Eifel Response Algorithm for [LG04] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for
TCP. Internet draft TCP", RFC 4015, February 2005.
"draft-ietf-tsvwg-tcp-eifel-response-05.txt". March 2004.
Work in progress.
[LK00] R. Ludwig and R.H. Katz. The Eifel Algorithm: Making TCP [LK00] R. Ludwig and R.H. Katz. The Eifel Algorithm: Making TCP
Robust Against Spurious Retransmissions. ACM SIGCOMM Robust Against Spurious Retransmissions. ACM SIGCOMM
Computer Communication Review, 30(1), January 2000. Computer Communication Review, 30(1), January 2000.
[LM03] R. Ludwig and M. Meyer. The Eifel Detection Algorithm for [LM03] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for
TCP. RFC 3522, April 2003. TCP", RFC 3522, April 2003.
[Nag84] J. Nagle. Congestion Control in IP/TCP Internetworks. RFC [Nag84] Nagle, J., "Congestion Control in IP/TCP Internetworks",
896, January 1984. RFC 896, January 1984.
[SKR03] P. Sarolahti, M. Kojo, and K. Raatikainen. F-RTO: An [SKR03] P. Sarolahti, M. Kojo, and K. Raatikainen. F-RTO: An
Enhanced Recovery Algorithm for TCP Retransmission Enhanced Recovery Algorithm for TCP Retransmission
Timeouts. ACM SIGCOMM Computer Communication Review, 33(2), Timeouts. ACM SIGCOMM Computer Communication Review,
April 2003. 33(2), April 2003.
[Sar03] P. Sarolahti. Congestion Control on Spurious TCP [Sar03] P. Sarolahti. Congestion Control on Spurious TCP
Retransmission Timeouts. In Proceedings of IEEE Globecom Retransmission Timeouts. In Proceedings of IEEE Globecom
2003, San Francisco, CA, USA. December 2003. 2003, San Francisco, CA, USA. December 2003.
[SL03] Y. Swami and K. Le. DCLOR: De-correlated Loss Recovery [SL03] Y. Swami and K. Le, "DCLOR: De-correlated Loss Recovery
using SACK option for spurious timeouts. Internet draft using SACK Option for Spurious Timeouts", work in progress,
"draft-swami-tsvwg-tcp-dclor-02.txt". September 2003. Work September 2003.
in progress.
Appendix A: Scenarios Appendix A: Scenarios
This section discusses different scenarios where RTOs occur and how This section discusses different scenarios where RTOs occur and how
the basic F-RTO algorithm performs in those scenarios. The the basic F-RTO algorithm performs in those scenarios. The
interesting scenarios are a sudden delay triggering retransmission interesting scenarios are: a sudden delay triggering retransmission
timeout, loss of a retransmitted packet during fast recovery, link timeout, loss of a retransmitted packet during fast recovery, link
outage causing the loss of several packets, and packet reordering. A outage causing the loss of several packets, and packet reordering. A
performance evaluation with a more thorough analysis on a real performance evaluation with a more thorough analysis on a real
implementation of F-RTO is given in [SKR03]. implementation of F-RTO is given in [SKR03].
A.1. Sudden delay A.1. Sudden Delay
The main motivation behind the F-RTO algorithm is to improve TCP The main motivation behind the F-RTO algorithm is to improve TCP
performance when a delay spike triggers a spurious retransmission performance when a delay spike triggers a spurious retransmission
timeout. The example below illustrates the segments and timeout. The example below illustrates the segments and
acknowledgments transmitted by the TCP end hosts when a spurious acknowledgments transmitted by the TCP end hosts when a spurious
timeout occurs, but no packets are lost. For simplicity, delayed timeout occurs, but no packets are lost. For simplicity, delayed
acknowledgments are not used in the example. The example below acknowledgments are not used in the example. The example below
applies the Eifel Response Algorithm [LG04] after detecting a applies the Eifel Response Algorithm [LG04] after detecting a
spurious timeout. spurious timeout.
skipping to change at page 16, line 6 skipping to change at page 16, line 14
11. SEND 14 ----------------------------> 11. SEND 14 ---------------------------->
(cwnd = 7, ssthresh = 6, FlightSize = 7) (cwnd = 7, ssthresh = 6, FlightSize = 7)
12. <---------------------------- ACK 9 12. <---------------------------- ACK 9
13. SEND 15 ----------------------------> 13. SEND 15 ---------------------------->
(cwnd = 7, ssthresh = 6, FlightSize = 7) (cwnd = 7, ssthresh = 6, FlightSize = 7)
14. <---------------------------- ACK 10 14. <---------------------------- ACK 10
15. SEND 16 ----------------------------> 15. SEND 16 ---------------------------->
(cwnd = 7, ssthresh = 6, FlightSize = 7) (cwnd = 7, ssthresh = 6, FlightSize = 7)
... ...
When a sudden delay long enough to trigger timeout occurs at step 5, When a sudden delay (long enough to trigger timeout) occurs at step
the TCP sender retransmits the first unacknowledged segment (step 6). 5, the TCP sender retransmits the first unacknowledged segment (step
The next ACK covers the RTO retransmission because the originally 6). The next ACK covers the RTO retransmission because the
transmitted segment 6 arrived at the receiver, and the TCP sender originally transmitted segment 6 arrived at the receiver, and the TCP
continues by sending two new data segments (steps 8, 9). Note that on sender continues by sending two new data segments (steps 8, 9). Note
F-RTO steps (1) and (2b) congestion window and FlightSize are not yet that on F-RTO steps (1) and (2b), congestion window and FlightSize
reset, because in case of possible spurious timeout the segments sent are not yet reset because in the case of spurious timeout, the
before the timeout are still in the network. However, the sender segments sent before the timeout are still in the network. However,
should still be equally aggressive to conventional TCP. Because the the sender should still be equally aggressive toward conventional
second acknowledgment arriving after the RTO retransmission TCP. Because the second acknowledgment arriving after the RTO
acknowledges data that was not retransmitted due to timeout (step retransmission acknowledges data that was not retransmitted due to
10), the TCP sender declares the timeout as spurious and continues by timeout (step 10), the TCP sender declares the timeout to be spurious
sending new data on next acknowledgments. Also the congestion control and continues by sending new data on the next acknowledgments. Also,
state is reversed, as required by the Eifel Response Algorithm. the congestion control state is reversed, as required by the Eifel
Response Algorithm.
A.2. Loss of a retransmission A.2. Loss of a Retransmission
If a retransmitted segment is lost, the only way to retransmit it If a retransmitted segment is lost, the only way to retransmit it is
again is to wait for the timeout to trigger the retransmission. Once to wait for the timeout to trigger the retransmission. Once the
the segment is successfully received, the receiver usually segment is successfully received, the receiver usually acknowledges
acknowledges several segments at once, because other segments in the several segments at once, because other segments in the same window
same window have been successfully delivered before the have been successfully delivered before the retransmission arrives at
retransmission arrives at the receiver. The example below shows a the receiver. The example below shows a scenario where
scenario where retransmission (of segment 6) is lost, as well as a retransmission (of segment 6) is lost, as well as a later segment
later segment (segment 9) in the same window. The limited transmit (segment 9) in the same window. The limited transmit [ABF01] or SACK
[ABF01] or SACK TCP [MMFR96] enhancements are not in use in this TCP [MMFR96] enhancements are not in use in this example.
example.
... ...
(cwnd = 6, ssthresh < 6, FlightSize = 6) (cwnd = 6, ssthresh < 6, FlightSize = 6)
<segment 6 lost> <segment 6 lost>
<segment 9 lost> <segment 9 lost>
1. <---------------------------- ACK 5 1. <---------------------------- ACK 5
2. SEND 10 ----------------------------> 2. SEND 10 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6) (cwnd = 6, ssthresh < 6, FlightSize = 6)
3. <---------------------------- ACK 6 3. <---------------------------- ACK 6
4. SEND 11 ----------------------------> 4. SEND 11 ---------------------------->
skipping to change at page 17, line 30 skipping to change at page 17, line 38
18. SEND 9 ----------------------------> 18. SEND 9 ---------------------------->
19. SEND 10 ----------------------------> 19. SEND 10 ---------------------------->
20. SEND 11 ----------------------------> 20. SEND 11 ---------------------------->
... ...
In the example above, segment 6 is lost and the sender retransmits it In the example above, segment 6 is lost and the sender retransmits it
after three duplicate ACKs in step 8. However, the retransmission is after three duplicate ACKs in step 8. However, the retransmission is
also lost, and the sender has to wait for the RTO to expire before also lost, and the sender has to wait for the RTO to expire before
retransmitting it again. Because the first ACK following the RTO retransmitting it again. Because the first ACK following the RTO
retransmission acknowledges the RTO retransmission (step 14), the retransmission acknowledges the RTO retransmission (step 14), the
sender transmits two new segments. The second ACK in step 17 does not sender transmits two new segments. The second ACK in step 17 does
acknowledge any previously unacknowledged data. Therefore the F-RTO not acknowledge any previously unacknowledged data. Therefore, the
sender enters the slow start and sets cwnd to 3 * MSS. Congestion F-RTO sender enters the slow start and sets cwnd to 3 * MSS. The
window can be set to three segments, because two round-trips have congestion window can be set to three segments, because two round-
elapsed after the retransmission timeout. After this the receiver trips have elapsed after the retransmission timeout. Finally, the
acknowledges all segments transmitted prior to entering recovery and receiver acknowledges all segments transmitted prior to entering
the sender can continue transmitting new data in congestion recovery and the sender can continue transmitting new data in
avoidance. congestion avoidance.
A.3. Link outage A.3. Link Outage
The example below illustrates the F-RTO behavior when 4 consecutive The example below illustrates the F-RTO behavior when 4 consecutive
packets are lost in the network causing the TCP sender to fall back packets are lost in the network causing the TCP sender to fall back
to RTO recovery. Limited transmit and SACK are not used in this to RTO recovery. Limited transmit and SACK are not used in this
example. example.
... ...
(cwnd = 6, ssthresh < 6, FlightSize = 6) (cwnd = 6, ssthresh < 6, FlightSize = 6)
<segments 6-9 lost> <segments 6-9 lost>
1. <---------------------------- ACK 5 1. <---------------------------- ACK 5
skipping to change at page 18, line 28 skipping to change at page 18, line 41
(cwnd = 7, ssthresh = 3, FlightSize = 7) (cwnd = 7, ssthresh = 3, FlightSize = 7)
10. <---------------------------- ACK 7 10. <---------------------------- ACK 7
[F-RTO step (3a)] [F-RTO step (3a)]
[SpuriousRecovery <- FALSE] [SpuriousRecovery <- FALSE]
(cwnd = 3, ssthresh = 3, FlightSize = 7) (cwnd = 3, ssthresh = 3, FlightSize = 7)
11. SEND 7 ----------------------------> 11. SEND 7 ---------------------------->
12. SEND 8 ----------------------------> 12. SEND 8 ---------------------------->
13. SEND 9 ----------------------------> 13. SEND 9 ---------------------------->
Again, F-RTO sender transmits two new segments (steps 8 and 9) after Again, F-RTO sender transmits two new segments (steps 8 and 9) after
the RTO retransmission is acknowledged. Because the next ACK does not the RTO retransmission is acknowledged. Because the next ACK does
acknowledge any data that was not retransmitted after the not acknowledge any data that was not retransmitted after the
retransmission timeout (step 10), the F-RTO sender proceeds with retransmission timeout (step 10), the F-RTO sender proceeds with
conventional recovery and slow start retransmissions. conventional recovery and slow start retransmissions.
A.4. Packet reordering A.4. Packet Reordering
Since F-RTO modifies the TCP sender behavior only after a Because F-RTO modifies the TCP sender behavior only after a
retransmission timeout and it is intended to avoid unnecessary retransmission timeout and it is intended to avoid unnecessary
retransmissions only after spurious timeout, we limit the discussion retransmissions only after spurious timeout, we limit the discussion
on the effects of packet reordering in F-RTO behavior to the cases on the effects of packet reordering on F-RTO behavior to the cases
where packet reordering occurs immediately after the retransmission where it occurs immediately after the retransmission timeout. When
timeout. When the TCP receiver gets an out-of-order segment, it the TCP receiver gets an out-of-order segment, it generates a
generates a duplicate ACK. If the TCP sender implements the basic duplicate ACK. If the TCP sender implements the basic F-RTO
F-RTO algorithm, this may prevent the sender from detecting a algorithm, this may prevent the sender from detecting a spurious
spurious timeout. timeout.
However, if the TCP sender applies the SACK-enhanced F-RTO, it is However, if the TCP sender applies the SACK-enhanced F-RTO, it is
possible to detect a spurious timeout also when packet reordering possible to detect a spurious timeout when packet reordering occurs.
occurs. We illustrate the behavior of SACK-enhanced F-RTO below when Below, we illustrate the behavior of SACK-enhanced F-RTO when segment
segment 8 arrives before segments 6 and 7, and segments starting from 8 arrives before segments 6 and 7, and segments starting from segment
segment 6 are delayed in the network. In this example the TCP sender 6 are delayed in the network. In this example the TCP sender reduces
reduces the congestion window and slow start threshold in response to the congestion window and slow start threshold in response to
spurious timeout. spurious timeout.
... ...
(cwnd = 6, ssthresh < 6, FlightSize = 6) (cwnd = 6, ssthresh < 6, FlightSize = 6)
1. <---------------------------- ACK 5 1. <---------------------------- ACK 5
2. SEND 10 ----------------------------> 2. SEND 10 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6) (cwnd = 6, ssthresh < 6, FlightSize = 6)
3. <---------------------------- ACK 6 3. <---------------------------- ACK 6
4. SEND 11 ----------------------------> 4. SEND 11 ---------------------------->
5. | 5. |
skipping to change at page 19, line 42 skipping to change at page 20, line 7
[SpuriousRecovery <- SPUR_TO] [SpuriousRecovery <- SPUR_TO]
(cwnd = 7, ssthresh = 6, FlightSize = 6) (cwnd = 7, ssthresh = 6, FlightSize = 6)
14. SEND 14 ----------------------------> 14. SEND 14 ---------------------------->
(cwnd = 7, ssthresh = 6, FlightSize = 7) (cwnd = 7, ssthresh = 6, FlightSize = 7)
15. <---------------------------- ACK 10 15. <---------------------------- ACK 10
16. SEND 15 ----------------------------> 16. SEND 15 ---------------------------->
... ...
After RTO expires and the sender retransmits segment 6 (step 6), the After RTO expires and the sender retransmits segment 6 (step 6), the
receiver gets segment 8 and generates duplicate ACK with SACK for receiver gets segment 8 and generates duplicate ACK with SACK for
segment 8. In response to the acknowledgment the TCP sender does not segment 8. In response to the acknowledgment, the TCP sender does
send anything but stays in F-RTO step 2. Because the next not send anything but stays in F-RTO step 2. Because the next
acknowledgment advances the cumulative ACK point (step 9), the sender acknowledgment advances the cumulative ACK point (step 9), the sender
can transmit two new segments according to SACK-enhanced F-RTO. The can transmit two new segments according to SACK-enhanced F-RTO. The
next segment acknowledges new data between 7 and 11 that was not next segment acknowledges new data between 7 and 11 that was not
acknowledged earlier (segment 7), so the F-RTO sender declares the acknowledged earlier (segment 7), so the F-RTO sender declares the
timeout spurious. timeout spurious.
Appendix B: SACK-enhanced F-RTO and Fast Recovery Appendix B: SACK-enhanced F-RTO and Fast Recovery
We believe that slightly modified SACK-enhanced F-RTO algorithm can
be used to detect spurious timeouts also when RTO expires while an We believe that a slightly modified, SACK-enhanced F-RTO algorithm
earlier loss recovery is underway. However, there are issues that can be used to detect spurious timeouts also when RTO expires while
an earlier loss recovery is underway. However, there are issues that
need to be considered if F-RTO is applied in this case. need to be considered if F-RTO is applied in this case.
The original SACK-based F-RTO requires in algorithm step 3 that an In step 3, the original SACK-based F-RTO algorithm requires that an
ACK acknowledges previously unacknowledged non-retransmitted data ACK acknowledges previously unacknowledged non-retransmitted data
between SND.UNA and send_high. If RTO expires during earlier between SND.UNA and send_high. If RTO expires during earlier
(SACK-based) loss recovery, the F-RTO sender must only use (SACK-based) loss recovery, the F-RTO sender must use only
acknowledgments for non-retransmitted segments transmitted before the acknowledgments for non-retransmitted segments transmitted before the
SACK-based loss recovery started. This means that in order to declare SACK-based loss recovery started. This means that in order to
timeout spurious the TCP sender must receive an acknowledgment for declare timeout spurious, the TCP sender must receive an
non-retransmitted segment between SND.UNA and RecoveryPoint in acknowledgment for non-retransmitted segment between SND.UNA and
algorithm step 3. RecoveryPoint is defined in conservative RecoveryPoint in algorithm step 3. RecoveryPoint is defined in
SACK-recovery algorithm [BAFW03], and it is set to indicate the conservative SACK-recovery algorithm [BAFW03], and it is set to
highest segment transmitted so far when SACK-based loss recovery indicate the highest segment transmitted so far when SACK-based loss
begins. In other words, if the TCP sender receives acknowledgment for recovery begins. In other words, if the TCP sender receives
segment that was transmitted more than one RTO ago, it can declare acknowledgment for a segment that was transmitted more than one RTO
the timeout spurious. Defining an efficient algorithm for checking ago, it can declare the timeout spurious. Defining an efficient
these conditions remains as a future work item. algorithm for checking these conditions remains a future work item.
When spurious timeout is detected according to the rules given above, When spurious timeout is detected according to the rules given above,
it may be possible that the response algorithm needs to consider this it may be possible that the response algorithm needs to consider this
case separately, for example in terms of what segments to retransmit case separately, for example, in terms of which segments to
after RTO expires, and whether it is safe to revert the congestion retransmit after RTO expires, and whether it is safe to revert the
control parameters in this case. This is considered as a topic of congestion control parameters. This is considered a topic for future
future research. research.
Appendix C: Discussion on Window Limited Cases Appendix C: Discussion of Window-Limited Cases
When the advertised window limits the transmission of two new When the advertised window limits the transmission of two new
previously unsent segments, or there are no new data to send, it was previously unsent segments, or there are no new data to send, it is
recommended in F-RTO algorithm step (2b) that the TCP sender would recommended in F-RTO algorithm step (2b) that the TCP sender continue
continue with conventional RTO recovery algorithm. The disadvantage with the conventional RTO recovery algorithm. The disadvantage is
of doing this is that the sender may continue unnecessary that the sender may continue unnecessary retransmissions due to
retransmissions due to possible spurious timeout. This section possible spurious timeout. This section briefly discusses the
briefly discusses the options that can potentially result in better options that can potentially improve performance when transmitting
performance when transmitting previously unsent data is not possible. previously unsent data is not possible.
- The TCP sender could reserve an unused space of a size of one or - The TCP sender could reserve an unused space of a size of one or
two segments in the advertised window to ensure the use of two segments in the advertised window to ensure the use of
algorithms such as F-RTO or Limited Transmit [ABF01] in window algorithms such as F-RTO or Limited Transmit [ABF01] in window-
limited situations. On the other hand, while doing this, the TCP limited situations. On the other hand, while doing this, the TCP
sender should ensure that the window of outstanding segments is sender should ensure that the window of outstanding segments is
large enough to have a proper utilization of the available pipe. large enough for proper utilization of the available pipe.
- Use additional information if available, e.g. TCP timestamps with - Use additional information if available, e.g., TCP timestamps with
the Eifel Detection algorithm, for detecting a spurious timeout. the Eifel Detection algorithm, for detecting a spurious timeout.
However, Eifel detection may yield different results from F-RTO However, Eifel detection may yield different results from F-RTO
when ACK losses and a RTO occur within the same round-trip time when ACK losses and an RTO occur within the same round-trip time
[SKR03]. [SKR03].
- Retransmit data from the tail of the retransmission queue and - Retransmit data from the tail of the retransmission queue and
continue with step 3 of the F-RTO algorithm. It is possible that continue with step 3 of the F-RTO algorithm. It is possible that
the retransmission is unnecessarily made, hence this option is not the retransmission will be made unnecessarily. Thus, this option
encouraged, except for hosts that are known to operate in an is not encouraged, except for hosts that are known to operate in an
environment that is highly likely to have spurious timeouts. On the environment that is prone to spurious timeouts. On the other hand,
other hand, with this method it is possible to avoid several with this method it is possible to limit unnecessary
unnecessary retransmissions due to spurious timeout by doing only retransmissions due to spurious timeout to one retransmission.
one retransmission that may be unnecessary.
- Send a zero-sized segment below SND.UNA similar to TCP Keep-Alive - Send a zero-sized segment below SND.UNA, similar to TCP Keep-Alive
probe and continue with step 3 of the F-RTO algorithm. Since the probe, and continue with step 3 of the F-RTO algorithm. Because
receiver replies with a duplicate ACK, the sender is able to detect the receiver replies with a duplicate ACK, the sender is able to
from the incoming acknowledgment whether the timeout was spurious. detect whether the timeout was spurious from the incoming
While this method does not send data unnecessarily, it delays the acknowledgment. This method does not send data unnecessarily, but
recovery by one round-trip time in cases where the timeout was not it delays the recovery by one round-trip time in cases where the
spurious, and therefore is not encouraged. timeout was not spurious. Therefore, this method is not
encouraged.
- In receiver-limited cases, send one octet of new data regardless of - In receiver-limited cases, send one octet of new data, regardless
the advertised window limit, and continue with step 3 of the F-RTO of the advertised window limit, and continue with step 3 of the
algorithm. It is possible that the receiver has free buffer space F-RTO algorithm. It is possible that the receiver will have free
to receive the data by the time the segment has propagated through buffer space to receive the data by the time the segment has
the network, in which case no harm is done. If the receiver is not propagated through the network, in which case no harm is done. If
capable of receiving the segment, it rejects the segment and sends the receiver is not capable of receiving the segment, it rejects
a duplicate ACK. the segment and sends a duplicate ACK.
Authors' Addresses Authors' Addresses
Pasi Sarolahti Pasi Sarolahti
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FIN-00045 NOKIA GROUP FIN-00045 NOKIA GROUP
Finland Finland
Phone: +358 50 4876607 Phone: +358 50 4876607
EMail: pasi.sarolahti@nokia.com EMail: pasi.sarolahti@nokia.com
http://www.cs.helsinki.fi/u/sarolaht/ http://www.cs.helsinki.fi/u/sarolaht/
Markku Kojo Markku Kojo
University of Helsinki University of Helsinki
Department of Computer Science Department of Computer Science
P.O. Box 26 P.O. Box 68
FIN-00014 UNIVERSITY OF HELSINKI FIN-00014 UNIVERSITY OF HELSINKI
Finland Finland
Phone: +358 9 1914 4179
EMail: markku.kojo@cs.helsinki.fi Phone: +358 9 191 51305
EMail: kojo@cs.helsinki.fi
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. This document is subject to the rights, licenses and restrictions
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 an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
skipping to change at page 22, line 42 skipping to change at page 23, line 42
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/