draft-ietf-tcpm-rtorestart-07.txt   draft-ietf-tcpm-rtorestart-08.txt 
TCP Maintenance and Minor Extensions (tcpm) P. Hurtig TCP Maintenance and Minor Extensions (tcpm) P. Hurtig
Internet-Draft A. Brunstrom Internet-Draft A. Brunstrom
Intended status: Experimental Karlstad University Intended status: Experimental Karlstad University
Expires: October 22, 2015 A. Petlund Expires: December 20, 2015 A. Petlund
Simula Research Laboratory AS Simula Research Laboratory AS
M. Welzl M. Welzl
University of Oslo University of Oslo
April 20, 2015 June 18, 2015
TCP and SCTP RTO Restart TCP and SCTP RTO Restart
draft-ietf-tcpm-rtorestart-07 draft-ietf-tcpm-rtorestart-08
Abstract Abstract
This document describes a modified sender-side algorithm for managing This document describes a modified sender-side algorithm for managing
the TCP and SCTP retransmission timers that provides faster loss the TCP and SCTP retransmission timers that provides faster loss
recovery when there is a small amount of outstanding data for a recovery when there is a small amount of outstanding data for a
connection. The modification, RTO Restart (RTOR), allows the connection. The modification, RTO Restart (RTOR), allows the
transport to restart its retransmission timer more aggressively in transport to restart its retransmission timer so that the effective
situations where fast retransmit cannot be used. This enables faster RTO becomes more aggressive in situations where fast retransmit
loss detection and recovery for connections that are short-lived or cannot be used. This enables faster loss detection and recovery for
application-limited. connections that are short-lived or application-limited.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 22, 2015. This Internet-Draft will expire on December 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
1. Introduction 1. Introduction
TCP uses two mechanisms to detect segment loss. First, if a segment TCP and SCTP use two almost identical mechanisms to detect and
is not acknowledged within a certain amount of time, a retransmission recover from data loss, specified in [RFC6298][RFC5681] (for TCP) and
timeout (RTO) occurs, and the segment is retransmitted [RFC6298]. [RFC4960] (for SCTP). First, if transmitted data is not acknowledged
While the RTO is based on measured round-trip times (RTTs) between within a certain amount of time, a retransmission timeout (RTO)
the sender and receiver, it also has a conservative lower bound of 1 occurs, and the data is retransmitted. While the RTO is based on
second to ensure that delayed segments are not mistaken as lost. measured round-trip times (RTTs) between the sender and receiver, it
Second, when a sender receives dupACKs, the fast retransmit algorithm also has a conservative lower bound of 1 second to ensure that
infers segment loss and triggers a retransmission [RFC5681]. delayed data are not mistaken as lost. Second, when a sender
Duplicate acknowledgments are generated by a receiver when out-of- receives duplicate acknowledgments, or similar information via
order segments arrive. As both segment loss and segment reordering selective acknowledgments, the fast retransmit algorithm infers data
cause out-of-order arrival, fast retransmit waits for three dupACKs loss and triggers a retransmission. Duplicate (and selective)
before considering the segment as lost. In some situations, however, acknowledgments are generated by a receiver when data arrives out-of-
the number of outstanding segments is not enough to trigger three order. As both data loss and data reordering cause out-of-order
dupACKs, and the sender must rely on lengthy RTOs for loss recovery. arrival, fast retransmit waits for three out-of-order notifications
before considering the corresponding data as lost. In some
situations, however, the amount of outstanding data is not enough to
trigger three such acknowledgments, and the sender must rely on
lengthy RTOs for loss recovery.
The number of outstanding segments can be small for several reasons: The amount of outstanding data can be small for several reasons:
(1) The connection is limited by the congestion control when the (1) The connection is limited by the congestion control when the
path has a low total capacity (bandwidth-delay product) or the path has a low total capacity (bandwidth-delay product) or the
connection's share of the capacity is small. It is also limited connection's share of the capacity is small. It is also limited
by the congestion control in the first few RTTs of a connection by the congestion control in the first few RTTs of a connection
or after an RTO when the available capacity is probed using or after an RTO when the available capacity is probed using
slow-start. slow-start.
(2) The connection is limited by the receiver's available buffer (2) The connection is limited by the receiver's available buffer
space. space.
skipping to change at page 3, line 13 skipping to change at page 3, line 17
all retransmissions sent by a major web service are sent after RTO all retransmissions sent by a major web service are sent after RTO
expiry. Applications with bursty transmission patterns often send expiry. Applications with bursty transmission patterns often send
data in response to actions, or as a reaction to real life events. data in response to actions, or as a reaction to real life events.
Typical examples of such applications are stock trading systems, Typical examples of such applications are stock trading systems,
remote computer operations, online games, and web-based applications remote computer operations, online games, and web-based applications
using persistent connections. What is special about this class of using persistent connections. What is special about this class of
applications is that they often are time-dependant, and extra latency applications is that they often are time-dependant, and extra latency
can reduce the application service level [P09]. can reduce the application service level [P09].
The RTO Restart (RTOR) mechanism described in this document makes the The RTO Restart (RTOR) mechanism described in this document makes the
RTO slightly more aggressive when the number of outstanding segments effective RTO slightly more aggressive when the amount of outstanding
is too small for fast retransmit to work, in an attempt to enable data is too small for fast retransmit to work, in an attempt to
faster loss recovery for all segments while being robust to enable faster loss recovery while being robust to reordering. While
reordering. While RTOR still conforms to the requirement in RTOR still conforms to the requirement for when a segment can be
[RFC6298] that segments must not be retransmitted earlier than RTO retransmitted, specified in [RFC6298] (for TCP) and [RFC4960] (for
seconds after their original transmission, it could increase the risk SCTP) it could increase the risk of spurious timeouts. To determine
of spurious timeout. Spurious timeouts can degrade the performance whether this modification is safe to deploy and enable by default,
of flows with multiple bursts of data, as a burst following a further experimentation is required. Section 5 discusses experiments
spurious timeout might not fit within the reduced congestion window still needed, including evaluations in environments where the risk of
(cwnd). There are, however, several techniques to mitigate the spurious retransmissions are increased e.g. mobile networks with
effects of such unnecessary retransmissions (cf. [RFC4015]). To highly varying RTTs.
determine whether this modification is safe to deploy and enable by
default further experimentation is required. The experiments needed
to determine this are discussed in Section 5 and include evaluating
the modification in environments with highly varying RTTs, e.g.
mobile networks.
While this document focuses on TCP, the described changes are also The remainder of this document describes RTOR and its implementation
valid for the Stream Control Transmission Protocol (SCTP) [RFC4960] for TCP only, to make the document easier to read. However, the RTOR
which has similar loss recovery and congestion control algorithms. algorithm described in Section 4 is applicable also for SCTP.
Furthermore, Section 7 details the SCTP socket API needed to control
RTOR.
2. Terminology 2. 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document introduces the following variables: This document introduces the following variables:
The number of previously unsent segments (prevunsnt): The number of The number of previously unsent segments (prevunsnt): The number of
segments that a sender has queued for transmission, but has not yet segments that a sender has queued for transmission, but has not yet
sent. sent.
RTO Restart threshold (rrthresh): RTOR is enabled whenever the sum of RTO Restart threshold (rrthresh): RTOR is enabled whenever the sum of
the number of outstanding and previously unsent segments (prevunsnt) the number of outstanding and previously unsent segments (prevunsnt)
is below this threshold. is below this threshold.
3. RTO Restart Overview 3. RTO Overview and Rationale for RTOR
The RTO management algorithm described in [RFC6298] recommends that The RTO management algorithm described in [RFC6298] recommends that
the retransmission timer is restarted when an acknowledgment (ACK) the retransmission timer is restarted when an acknowledgment (ACK)
that acknowledges new data is received and there is still outstanding that acknowledges new data is received and there is still outstanding
data. The restart is conducted to guarantee that unacknowledged data. The restart is conducted to guarantee that unacknowledged
segments will be retransmitted after approximately RTO seconds. segments will be retransmitted after approximately RTO seconds. The
However, by restarting the timer on each incoming ACK, standardized RTO timer management is illustrated in Figure 1 where a
retransmissions are not typically triggered RTO seconds after their TCP sender transmits three segments to a receiver. The arrival of
previous transmission but rather RTO seconds after the last ACK the first and second segment triggers a delayed ACK (delACK)
arrived. The duration of this extra delay depends on several factors [RFC1122], which restarts the RTO timer at the sender. The RTO is
but is in most cases approximately one RTT. Hence, in most restarted approximately one RTT after the transmission of the third
situations, the time before a retransmission is triggered is equal to segment. Thus, if the third segment is lost, as indicated in
"RTO + RTT". Figure 1, the effective loss detection time become "RTO + RTT"
seconds. In some situations, the effective loss detection time
The standardized RTO timer management is illustrated in Figure 1 becomes even longer. Consider a scenario where only two segments are
where a TCP sender transmits three segments to a receiver. The outstanding. If the second segment is lost, the time to expire the
arrival of the first and second segment triggers a delayed ACK delACK timer will also be included in the effective loss detection
(delACK) [RFC1122], which restarts the RTO timer at the sender. The time.
RTO is restarted approximately one RTT after the transmission of the
third segment. Thus, if the third segment is lost, as indicated in
Figure 1, the effective loss detection time is "RTO + RTT" seconds.
In some situations, the effective loss detection time becomes even
longer. Consider a scenario where only two segments are outstanding.
If the second segment is lost, the time to expire the delACK timer
will also be included in the effective loss detection time.
Sender Receiver Sender Receiver
... ...
DATA [SEG 1] ----------------------> (ack delayed) DATA [SEG 1] ----------------------> (ack delayed)
DATA [SEG 2] ----------------------> (send ack) DATA [SEG 2] ----------------------> (send ack)
DATA [SEG 3] ----X /-------- ACK DATA [SEG 3] ----X /-------- ACK
(restart RTO) <----------/ (restart RTO) <----------/
... ...
(RTO expiry) (RTO expiry)
DATA [SEG 3] ----------------------> DATA [SEG 3] ---------------------->
Figure 1: RTO restart example Figure 1: RTO restart example
During normal TCP bulk transfer the current RTO restart approach is For bulk traffic the current approach is beneficial -- it is
not a problem. Actually, as long as enough segments arrive at a described in [EL04] to act as a "safety margin" that compensates for
receiver to enable fast retransmit, RTO-based loss recovery should be some of the problems that the authors have identified with the
avoided. RTOs should only be used as a last resort, as they standard RTO calculation. Notably, the authors of [EL04] also state
drastically lower the congestion window compared to fast retransmit. that "this safety margin does not exist for highly interactive
The current approach can therefore be beneficial -- it is described applications where often only a single packet is in flight". In
in [EL04] to act as a "safety margin" that compensates for some of general, however, as long as enough segments arrive at a receiver to
the problems that the authors have identified with the standard RTO enable fast retransmit, RTO-based loss recovery should be avoided.
calculation. Notably, the authors of [EL04] also state that "this RTOs should only be used as a last resort, as they drastically lower
safety margin does not exist for highly interactive applications the congestion window compared to fast retransmit.
where often only a single packet is in flight."
Although fast retransmit is preferrable there are situations where Although fast retransmit is preferrable there are situations where
timeouts are appropriate, or the only choice. For example, if the timeouts are appropriate, or the only choice. For example, if the
network is severely congested and no segments arrive RTO-based network is severely congested and no segments arrive RTO-based
recovery should be used. In this situation, the time to recover from recovery should be used. In this situation, the time to recover from
the loss(es) will not be the performance bottleneck. However, for the loss(es) will not be the performance bottleneck. However, for
connections that do not utilize enough capacity to enable fast connections that do not utilize enough capacity to enable fast
retransmit, RTO-based loss detection is the only choice and the time retransmit, RTO-based loss detection is the only choice and the time
required for this can become a performance bottleneck. required for this can become a performance bottleneck.
4. RTOR Algorithm 4. RTOR Algorithm
To enable faster loss recovery for connections that are unable to use To enable faster loss recovery for connections that are unable to use
fast retransmit, RTOR can be used. This section specifies the fast retransmit, RTOR can be used. This section specifies the
modifications required to use RTOR. By resetting the timer to "RTO - modifications required to use RTOR. By resetting the timer to "RTO -
T_earliest", where T_earliest is the time elapsed since the earliest T_earliest", where T_earliest is the time elapsed since the earliest
outstanding segment was transmitted, retransmissions will always outstanding segment was transmitted, retransmissions will always
occur after exactly RTO seconds. This approach makes the RTO more occur after exactly RTO seconds.
aggressive than the standardized approach in [RFC6298] but still
conforms to the requirement in [RFC6298] that segments must not be
retransmitted earlier than RTO seconds after their original
transmission.
This document specifies an OPTIONAL sender-only modification to TCP This document specifies an OPTIONAL sender-only modification to TCP
and SCTP which updates step 5.3 in Section 5 of [RFC6298] (and a and SCTP which updates step 5.3 in Section 5 of [RFC6298] (and a
similar update in Section 6.3.2 of [RFC4960] for SCTP). A sender similar update in Section 6.3.2 of [RFC4960] for SCTP). A sender
that implements this method MUST follow the algorithm below: that implements this method MUST follow the algorithm below:
When an ACK is received that acknowledges new data: When an ACK is received that acknowledges new data:
(1) Set T_earliest = 0. (1) Set T_earliest = 0.
skipping to change at page 6, line 5 skipping to change at page 5, line 40
(rrthresh), set T_earliest to the time elapsed since the (rrthresh), set T_earliest to the time elapsed since the
earliest outstanding segment was sent. earliest outstanding segment was sent.
(3) Restart the retransmission timer so that it will expire after (3) Restart the retransmission timer so that it will expire after
(for the current value of RTO): (for the current value of RTO):
(a) RTO - T_earliest, if RTO - T_earliest > 0. (a) RTO - T_earliest, if RTO - T_earliest > 0.
(b) RTO, otherwise. (b) RTO, otherwise.
The RECOMMENDED value of rrthresh is four, as it will prevent RTOR The RECOMMENDED value of rrthresh is four, as this value will ensure
from being more aggressive and potentially causing RTOs instead of that RTOR is only used when fast retransmit cannot be triggered.
fast retransmits. This update needs TCP implementations to track the This update needs TCP implementations to track the time elapsed since
time elapsed since the transmission of the earliest outstanding the transmission of the earliest outstanding segment (T_earliest).
segment (T_earliest). As RTOR is only used when the amount of As RTOR is only used when the amount of outstanding and previously
outstanding and previously unsent data is less than rrthresh unsent data is less than rrthresh segments, TCP implementations also
segments, TCP implementations also need to track whether the amount need to track whether the amount of outstanding and previously unsent
of outstanding and previously unsent data is more, equal, or less data is more, equal, or less than rrthresh segments. Although some
than rrthresh segments. Although some packet-based TCP packet-based TCP implementations (e.g. Linux TCP) already track both
implementations (e.g. Linux TCP) already track both the transmission the transmission times of all segments and also the number of
times of all segments and also the number of outstanding segments, outstanding segments, not all implementations do. Section 5.3
not all implementations do. Section 5.3 describes how to implement describes how to implement segment tracking for a general TCP
segment tracking for a general TCP implementation. To use RTOR, the implementation. To use RTOR, the calculated expiration time MUST be
calculated expiration time MUST be positive (step 3(a) in the list positive (step 3(a) in the list above); this is required to ensure
above); this is required to ensure that RTOR does not trigger that RTOR does not trigger retransmissions prematurely when
retransmissions prematurely when previously retransmitted segments previously retransmitted segments are acknowledged.
are acknowledged.
5. Discussion 5. Discussion
In this section, we discuss the applicability and a number of issues Although RTOR conforms to the requirement in [RFC6298] that segments
surrounding RTOR. must not be retransmitted earlier than RTO seconds after their
original transmission, RTOR makes the effective RTO more aggressive.
In this section, we discuss the applicability and the issues related
to RTOR.
5.1. Applicability 5.1. Applicability
The currently standardized algorithm has been shown to add at least The currently standardized algorithm has been shown to add at least
one RTT to the loss recovery process in TCP [LS00] and SCTP one RTT to the loss recovery process in TCP [LS00] and SCTP
[HB11][PBP09]. For applications that have strict timing requirements [HB11][PBP09]. For applications that have strict timing requirements
(e.g. interactive web) rather than throughput requirements, using (e.g. interactive web) rather than throughput requirements, using
RTOR could be beneficial because the RTT and also the delACK timer of RTOR could be beneficial because the RTT and also the delACK timer of
receivers are often large components of the effective loss recovery receivers are often large components of the effective loss recovery
time. Measurements in [HB11] have shown that the total transfer time time. Measurements in [HB11] have shown that the total transfer time
skipping to change at page 7, line 12 skipping to change at page 6, line 49
Given that RTOR is a mostly conservative algorithm, it is suitable Given that RTOR is a mostly conservative algorithm, it is suitable
for experimentation as a system-wide default for TCP traffic. for experimentation as a system-wide default for TCP traffic.
5.2. Spurious Timeouts 5.2. Spurious Timeouts
RTOR can in some situations reduce the loss detection time and RTOR can in some situations reduce the loss detection time and
thereby increase the risk of spurious timeouts. In theory, the thereby increase the risk of spurious timeouts. In theory, the
retransmission timer has a lower bound of 1 second [RFC6298], which retransmission timer has a lower bound of 1 second [RFC6298], which
limits the risk of having spurious timeouts. However, in practice limits the risk of having spurious timeouts. However, in practice
most implementations use a significantly lower value. Initial most implementations use a significantly lower value. Initial
measurements, show slight increases in the number of spurious measurements show slight increases in the number of spurious timeouts
timeouts when such lower values are used [RHB15]. However, further when such lower values are used [RHB15]. However, further
experiments, in different environments and with different types of experiments, in different environments and with different types of
traffic, are encouraged to quantify such increases more reliably. traffic, are encouraged to quantify such increases more reliably.
Does a slightly increased risk matter? Generally, spurious timeouts Does a slightly increased risk matter? Generally, spurious timeouts
have a negative effect on the network as segments are transmitted have a negative effect on the network as segments are transmitted
needlessly. However, recent experiments do not show a significant needlessly. However, recent experiments do not show a significant
increase in network load for a number of realistic scenarios [RHB15]. increase in network load for a number of realistic scenarios [RHB15].
Another problem with spurious retransmissions is related to the Another problem with spurious retransmissions is related to the
performance of TCP/SCTP, as the congestion window is reduced to one performance of TCP/SCTP, as the congestion window is reduced to one
segment when timeouts occur [RFC5681]. This could be a potential segment when timeouts occur [RFC5681]. This could be a potential
problem for applications transmitting multiple bursts of data within problem for applications transmitting multiple bursts of data within
a single flow, e.g. web-based HTTP/1.1 and HTTP/2.0 applications. a single flow, e.g. web-based HTTP/1.1 and HTTP/2.0 applications.
However, results from recent experiments involving persistent web However, results from recent experiments involving persistent web
traffic [RHB15] only revealed a net gain of using RTOR. Other types traffic [RHB15] revealed a net gain of using RTOR. Other types of
of flows, e.g. long-lived bulk flows, are not affected as the flows, e.g. long-lived bulk flows, are not affected as the algorithm
algorithm is only applied when the amount of outstanding and unsent is only applied when the amount of outstanding and unsent segments is
segments is less than rrthresh. Furthermore, short-lived and less than rrthresh. Furthermore, short-lived and application-limited
application-limited flows are typically not affected as they are too flows are typically not affected as they are too short to experience
short to experience the effect of congestion control or have a the effect of congestion control or have a transmission rate that is
transmission rate that is quickly attainable. quickly attainable.
While a slight increase in spurious timeouts has been observed using While a slight increase in spurious timeouts has been observed using
RTOR, it is not clear whether the effects of this increase mandate RTOR, it is not clear whether the effects of this increase mandate
any future algorithmic changes or not -- especially since most modern any future algorithmic changes or not -- especially since most modern
operating systems already include mechanisms to detect operating systems already include mechanisms to detect
[RFC3522][RFC3708][RFC5682] and resolve [RFC4015] possible problems [RFC3522][RFC3708][RFC5682] and resolve [RFC4015] possible problems
with spurious retransmissions. Further experimentation is needed to with spurious retransmissions. Further experimentation is needed to
determine this and thereby move this specification from experimental determine this and thereby move this specification from experimental
to proposed standard. For instance, RTOR has not been evaluated in to proposed standard. For instance, RTOR has not been evaluated in
the context of mobile networks. Mobile networks often incur highly the context of mobile networks. Mobile networks often incur highly
skipping to change at page 8, line 33 skipping to change at page 8, line 23
Tracking the number of previously unsent segments depends on the Tracking the number of previously unsent segments depends on the
segmentation strategy used by the TCP implementation, not whether it segmentation strategy used by the TCP implementation, not whether it
is packet-based or byte-based. In the case segments are formed is packet-based or byte-based. In the case segments are formed
directly on socket writes, the process of determining the number of directly on socket writes, the process of determining the number of
previously unsent segments should be trivial. In the case that previously unsent segments should be trivial. In the case that
unsent data can be segmented (or re-segmented) as long as it still is unsent data can be segmented (or re-segmented) as long as it still is
unsent, a straightforward strategy could be to divide the amount of unsent, a straightforward strategy could be to divide the amount of
unsent data (in bytes) with the SMSS to obtain an estimate. In some unsent data (in bytes) with the SMSS to obtain an estimate. In some
cases, such an estimation could be too simplistic, depending on the cases, such an estimation could be too simplistic, depending on the
segmentation strategy of the TCP implementation. However, this segmentation strategy of the TCP implementation. However, this
estimation is not critical to RTOR. For instance, implementations estimation is not critical to RTOR. The tracking of prevunsnt is
can use a simplified method by setting prevunsnt to rrthresh whenever
previously unsent data is available, and set prevunsnt to zero when
no new data is available. This will disable RTOR in the presence of
unsent data and only use the number of outstanding segments to
enable/disable RTOR. This strategy was used in an earlier version of
the algorithm and works well. The addition of tracking prevunsnt was
only made to optimize a corner case in which RTOR was unnecessarily only made to optimize a corner case in which RTOR was unnecessarily
disabled. disabled. Implementations can use a simplified method by setting
prevunsnt to rrthresh whenever previously unsent data is available,
and set prevunsnt to zero when no new data is available. This will
disable RTOR in the presence of unsent data and only use the number
of outstanding segments to enable/disable RTOR.
6. Related Work 6. Related Work
There are several proposals that address the problem of not having There are several proposals that address the problem of not having
enough ACKs for loss recovery. In what follows, we explain why the enough ACKs for loss recovery. In what follows, we explain why the
mechanism described here is complementary to these approaches: mechanism described here is complementary to these approaches:
The limited transmit mechanism [RFC3042] allows a TCP sender to The limited transmit mechanism [RFC3042] allows a TCP sender to
transmit a previously unsent segment for each of the first two transmit a previously unsent segment for each of the first two
dupACKs. By transmitting new segments, the sender attempts to dupACKs. By transmitting new segments, the sender attempts to
skipping to change at page 9, line 14 skipping to change at page 8, line 51
limited transmit does not help if no previously unsent data is ready limited transmit does not help if no previously unsent data is ready
for transmission. [RFC5827] specifies an early retransmit algorithm for transmission. [RFC5827] specifies an early retransmit algorithm
to enable fast loss recovery in such situations. By dynamically to enable fast loss recovery in such situations. By dynamically
lowering the number of dupACKs needed for fast retransmit lowering the number of dupACKs needed for fast retransmit
(dupthresh), based on the number of outstanding segments, a smaller (dupthresh), based on the number of outstanding segments, a smaller
number of dupACKs is needed to trigger a retransmission. In some number of dupACKs is needed to trigger a retransmission. In some
situations, however, the algorithm is of no use or might not work situations, however, the algorithm is of no use or might not work
properly. First, if a single segment is outstanding, and lost, it is properly. First, if a single segment is outstanding, and lost, it is
impossible to use early retransmit. Second, if ACKs are lost, early impossible to use early retransmit. Second, if ACKs are lost, early
retransmit cannot help. Third, if the network path reorders retransmit cannot help. Third, if the network path reorders
segments, the algorithm might cause more unnecessary retransmissions segments, the algorithm might cause more spurious retransmissions
than fast retransmit. The recommended value of RTOR's rrthresh than fast retransmit. The recommended value of RTOR's rrthresh
variable is based on the dupthresh, but is possible to adapt to allow variable is based on the dupthresh, but is possible to adapt to allow
tighter integration with other experimental algorithms such as early tighter integration with other experimental algorithms such as early
retransmit. retransmit.
Tail Loss Probe [TLP] is a proposal to send up to two "probe Tail Loss Probe [TLP] is a proposal to send up to two "probe
segments" when a timer fires which is set to a value smaller than the segments" when a timer fires which is set to a value smaller than the
RTO. A "probe segment" is a new segment if new data is available, RTO. A "probe segment" is a new segment if new data is available,
else a retransmission. The intention is to compensate for sluggish else a retransmission. The intention is to compensate for sluggish
RTO behavior in situations where the RTO greatly exceeds the RTT, RTO behavior in situations where the RTO greatly exceeds the RTT,
skipping to change at page 11, line 25 skipping to change at page 11, line 15
All the authors are supported by RITE (http://riteproject.eu/ ), a All the authors are supported by RITE (http://riteproject.eu/ ), a
research project (ICT-317700) funded by the European Community under research project (ICT-317700) funded by the European Community under
its Seventh Framework Program. The views expressed here are those of its Seventh Framework Program. The views expressed here are those of
the author(s) only. The European Commission is not liable for any the author(s) only. The European Commission is not liable for any
use that may be made of the information in this document. use that may be made of the information in this document.
11. Changes from Previous Versions 11. Changes from Previous Versions
RFC-Editor note: please remove this section prior to publication. RFC-Editor note: please remove this section prior to publication.
11.1. Changes from draft-ietf-...-06 to -07 11.1. Changes from draft-ietf-...-07 to -08
o Clarified, at multiple places in the document, that the
modification only causes the effective RTO to be more aggressive,
not the actual RTO.
o Removed information in the introduction that was too detailed,
i.e., material that is hard to understand without knowing details
of the algorithm.
o Changed the name of Section 3 to more correctly capture the actual
contents of the section.
o Re-arranged the text in Section 3 to have a more logical
structure.
o Moved text from the algorithm description (Section 4) to the
introduction of the discussion section (Section 5). The text was
discussing the possible effects of the algorithm more than
describing the actual algorithm.
o Clarified why the RECOMMENDED value of rrthresh is four.
o Reworked the introduction to be suitable for both TCP and SCTP.
11.2. Changes from draft-ietf-...-06 to -07
o Clarified, at multiple places in the document, that the o Clarified, at multiple places in the document, that the
modification is sender-only. modification is sender-only.
o Added an explanation (in the introduction) to why the mechanism is o Added an explanation (in the introduction) to why the mechanism is
experimental and what experiments are missing. experimental and what experiments are missing.
o Added a sentence in Section 4 to clarify that the section is the o Added a sentence in Section 4 to clarify that the section is the
one describing the actual modification. one describing the actual modification.
11.2. Changes from draft-ietf-...-05 to -06 11.3. Changes from draft-ietf-...-05 to -06
o Added socket API considerations, after discussing the draft in o Added socket API considerations, after discussing the draft in
tsvwg. tsvwg.
11.3. Changes from draft-ietf-...-04 to -05 11.4. Changes from draft-ietf-...-04 to -05
o Introduced variable to track the number of previously unsent o Introduced variable to track the number of previously unsent
segments. segments.
o Clarified many concepts, e.g. extended the description on how to o Clarified many concepts, e.g. extended the description on how to
track outstanding and previously unsent segments. track outstanding and previously unsent segments.
o Added a reference to initial measurements on the effects of using o Added a reference to initial measurements on the effects of using
RTOR. RTOR.
o Improved wording throughout the document. o Improved wording throughout the document.
11.4. Changes from draft-ietf-...-03 to -04 11.5. Changes from draft-ietf-...-03 to -04
o Changed the algorithm to allow RTOR when there is unsent data o Changed the algorithm to allow RTOR when there is unsent data
available, but the cwnd does not allow transmission. available, but the cwnd does not allow transmission.
o Changed the algorithm to not trigger if RTOR <= 0. o Changed the algorithm to not trigger if RTOR <= 0.
o Made minor adjustments throughout the document to adjust for the o Made minor adjustments throughout the document to adjust for the
algorithmic change. algorithmic change.
o Improved the wording throughout the document. o Improved the wording throughout the document.
11.5. Changes from draft-ietf-...-02 to -03 11.6. Changes from draft-ietf-...-02 to -03
o Updated the document to use "RTOR" instead of "RTO Restart" when o Updated the document to use "RTOR" instead of "RTO Restart" when
refering to the modified algorithm. refering to the modified algorithm.
o Moved document terminology to a section of its own. o Moved document terminology to a section of its own.
o Introduced the rrthresh variable in the terminology section. o Introduced the rrthresh variable in the terminology section.
o Added a section to generalize the tracking of outstanding o Added a section to generalize the tracking of outstanding
segments. segments.
o Updated the algorithm to work when the number of outstanding o Updated the algorithm to work when the number of outstanding
segments is less than four and one segment is ready for segments is less than four and one segment is ready for
transmission, by restarting the timer when new data has been sent. transmission, by restarting the timer when new data has been sent.
o Clarified the relationship between fast retransmit and RTOR. o Clarified the relationship between fast retransmit and RTOR.
o Improved the wording throughout the document. o Improved the wording throughout the document.
11.6. Changes from draft-ietf-...-01 to -02 11.7. Changes from draft-ietf-...-01 to -02
o Changed the algorithm description in Section 3 to use formal RFC o Changed the algorithm description in Section 3 to use formal RFC
2119 language. 2119 language.
o Changed last paragraph of Section 3 to clarify why the RTO restart o Changed last paragraph of Section 3 to clarify why the RTO restart
algorithm is active when less than four segments are outstanding. algorithm is active when less than four segments are outstanding.
o Added two paragraphs in Section 4.1 to clarify why the algorithm o Added two paragraphs in Section 4.1 to clarify why the algorithm
can be turned on for all TCP traffic without having any negative can be turned on for all TCP traffic without having any negative
effects on traffic patterns that do not benefit from a modified effects on traffic patterns that do not benefit from a modified
timer restart. timer restart.
o Improved the wording throughout the document. o Improved the wording throughout the document.
o Replaced and updated some references. o Replaced and updated some references.
11.7. Changes from draft-ietf-...-00 to -01 11.8. Changes from draft-ietf-...-00 to -01
o Improved the wording throughout the document. o Improved the wording throughout the document.
o Removed the possibility for a connection limited by the receiver's o Removed the possibility for a connection limited by the receiver's
advertised window to use RTO restart, decreasing the risk of advertised window to use RTO restart, decreasing the risk of
spurious retransmission timeouts. spurious retransmission timeouts.
o Added a section that discusses the applicability of and problems o Added a section that discusses the applicability of and problems
related to the RTO restart mechanism. related to the RTO restart mechanism.
 End of changes. 27 change blocks. 
123 lines changed or deleted 137 lines changed or added

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