draft-ietf-tcpm-rtorestart-03.txt   draft-ietf-tcpm-rtorestart-04.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: January 5, 2015 A. Petlund Expires: April 30, 2015 A. Petlund
Simula Research Laboratory AS Simula Research Laboratory AS
M. Welzl M. Welzl
University of Oslo University of Oslo
July 4, 2014 October 27, 2014
TCP and SCTP RTO Restart TCP and SCTP RTO Restart
draft-ietf-tcpm-rtorestart-03 draft-ietf-tcpm-rtorestart-04
Abstract Abstract
This document describes a modified algorithm for managing the TCP and This document describes a modified algorithm for managing the TCP and
SCTP retransmission timers that provides faster loss recovery when SCTP retransmission timers that provides faster loss recovery when
there is a small amount of outstanding data for a connection. The there is a small amount of outstanding data for a connection. The
modification, RTO Restart (RTOR), allows the transport to restart its modification, RTO Restart (RTOR), allows the transport to restart its
retransmission timer more aggressively in situations where fast retransmission timer more aggressively in situations where fast
retransmit cannot be used. This enables faster loss detection and retransmit cannot be used. This enables faster loss detection and
recovery for connections that are short-lived or application-limited. recovery for connections that are short-lived or application-limited.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 January 5, 2015. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 3, line 18 skipping to change at page 3, line 18
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 RTO slightly more aggressive when the number of outstanding segments
is too small for fast retransmit to work, in an attempt to enable is too small for fast retransmit to work, in an attempt to enable
faster loss recovery for all segments while being robust to faster loss recovery for all segments while being robust to
reordering. While RTOR still conforms to the requirement in reordering. While RTOR still conforms to the requirement in
[RFC6298] that segments must not be retransmitted earlier than RTO [RFC6298] that segments must not be retransmitted earlier than RTO
seconds after their original transmission, it could increase the risk seconds after their original transmission, it could increase the risk
of spurious timeout. Spurious timeouts typically degrade the of spurious timeout. Spurious timeouts can degrade the performance
performance of flows with multiple bursts of data, as a burst of flows with multiple bursts of data, as a burst following a
following a spurious timeout might not fit within the reduced spurious timeout might not fit within the reduced congestion window
congestion window (cwnd). (cwnd). There are, however, several techniques to mitigate the
effects of such unnecessary retransmissions (cf. [RFC4015]).
While this document focuses on TCP, the described changes are also While this document focuses on TCP, the described changes are also
valid for the Stream Control Transmission Protocol (SCTP) [RFC4960] valid for the Stream Control Transmission Protocol (SCTP) [RFC4960]
which has similar loss recovery and congestion control algorithms. which has similar loss recovery and congestion control algorithms.
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 variable: This document introduces the following variable:
RTO Restart threshold (rrthresh): RTOR is enabled whenever the number RTO Restart threshold (rrthresh): RTOR is enabled whenever the total
of outstaning segments is below this threshold. number of outstanding and previously unsent segments is below this
threshold.
3. RTO Restart Overview 3. RTO Restart Overview
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.
However, by restarting the timer on each incoming ACK, However, by restarting the timer on each incoming ACK,
retransmissions are not typically triggered RTO seconds after their retransmissions are not typically triggered RTO seconds after their
previous transmission but rather RTO seconds after the last ACK previous transmission but rather RTO seconds after the last ACK
arrived. The duration of this extra delay depends on several factors arrived. The duration of this extra delay depends on several factors
but is in most cases approximately one RTT. Hence, in most but is in most cases approximately one RTT. Hence, in most
situations, the time before a retransmission is triggered is equal to situations, the time before a retransmission is triggered is equal to
"RTO + RTT". "RTO + RTT".
The extra delay can be significant, especially for applications that The standardized RTO timer management is illustrated in Figure 1
use a lower RTOmin than the standard of 1 second and/or in where a TCP sender transmits three segments to a receiver. The
environments with high RTTs, e.g. mobile networks. The restart arrival of the first and second segment triggers a delayed ACK
approach is illustrated in Figure 1 where a TCP sender transmits (delACK) [RFC1122], which restarts the RTO timer at the sender. RTO
three segments to a receiver. The arrival of the first and second restart is performed approximately one RTT after the transmission of
segment triggers a delayed ACK (delACK) [RFC1122], which restarts the the third segment. Thus, if the third segment is lost, as indicated
RTO timer at the sender. RTO restart is performed approximately one in Figure 1, the effective loss detection time is "RTO + RTT"
RTT after the transmission of the third segment. Thus, if the third seconds. In some situations, the effective loss detection time
segment is lost, as indicated in Figure 1, the effective loss becomes even longer. Consider a scenario where only two segments are
detection time is "RTO + RTT" seconds. In some situations, the outstanding. If the second segment is lost, the time to expire the
effective loss detection time becomes even longer. Consider a delACK timer will also be included in the effective loss detection
scenario where only two segments are outstanding. If the second time.
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] ---------------------->
skipping to change at page 5, line 5 skipping to change at page 5, line 5
safety margin does not exist for highly interactive applications safety margin does not exist for highly interactive applications
where often only a single packet is in flight." 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 serious 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. By resetting the timer to "RTO - fast retransmit, RTOR can be used. 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. This approach makes the RTO more
aggressive than the standardized approach in [RFC6298] but still aggressive than the standardized approach in [RFC6298] but still
conforms to the requirement in [RFC6298] that segments must not be conforms to the requirement in [RFC6298] that segments must not be
retransmitted earlier than RTO seconds after their original retransmitted earlier than RTO seconds after their original
transmission. 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, or when a new When an ACK is received that acknowledges new data:
data segment has been sent:
(1) Set T_earliest = 0. (1) Set T_earliest = 0.
(2) If the following two conditions hold: (2) If the total number of outstanding and previously unsent
segments is less than an RTOR threshold (rrthresh), set
(a) The number of outstanding segments is less than a RTOR T_earliest to the time elapsed since the earliest outstanding
threshold (rrthresh). The rrthresh SHOULD be set to segment was sent.
four.
(b) There is no unsent data ready for transmission. (3) Restart the retransmission timer so that it will expire after
(for the current value of RTO):
set T_earliest to the time elapsed since the earliest (a) RTO - T_earliest, if RTO - T_earliest is > 0.
outstanding segment was sent.
(3) Restart the retransmission timer so that it will expire after (b) RTO, otherwise.
"RTO - T_earliest" seconds (for the current value of RTO).
This update needs TCP implementations to track the time elapsed since The RECOMMENDED value of rrthresh is four, as it will prevent RTOR
the transmission of the earliest outstanding segment (T_earliest). from being more aggressive and potentially causing RTOs instead of
As RTOR is only used when the amount of outstanding data is less than fast retransmits. This update needs TCP implementations to track the
rrthresh segments, TCP implementations also need to track whether the time elapsed since the transmission of the earliest outstanding
amount of outstanding data is more, equal, or less than rrthresh segment (T_earliest). As RTOR is only used when the amount of
segments. Although some packet-based TCP implementations (e.g. outstanding and unsent data is less than rrthresh segments, TCP
Linux TCP) already track both the transmission times of all segments implementations also need to track whether the amount of outstanding
and also the number of outstanding segments, not all implementations and unsent data is more, equal, or less than rrthresh segments.
do. Section 5.3 describes how to implement segment tracking for a Although some packet-based TCP implementations (e.g. Linux TCP)
general TCP implementation. already track both the transmission times of all segments and also
the number of outstanding segments, not all implementations do.
Section 5.3 describes how to implement segment tracking for a general
TCP implementation. RTOR is applied only if the calculated
expiration time is positive (step 3(a) in the list above). This is
done to ensure that RTOR does not trigger retransmissions prematurely
when previously retransmitted segments are acknowledged.
5. Discussion 5. Discussion
In this section, we discuss the applicability and a number of issues In this section, we discuss the applicability and a number of issues
surrounding RTOR. surrounding 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
skipping to change at page 6, line 28 skipping to change at page 6, line 30
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
of a lost segment (including the original transmission time and the of a lost segment (including the original transmission time and the
loss recovery time) can be reduced by 35% using RTOR. These results loss recovery time) can be reduced by 35% using RTOR. These results
match those presented in [PGH06][PBP09], where RTOR is shown to match those presented in [PGH06][PBP09], where RTOR is shown to
significantly reduce retransmission latency. significantly reduce retransmission latency.
There are also traffic types that do not benefit from RTOR. One There are also traffic types that do not benefit from RTOR. One
example of such traffic is bulk transmission. The reason why bulk example of such traffic is bulk transmission. The reason why bulk
traffic does not benefit RTOR is related to the number of outstanding traffic does not benefit from RTOR is that such traffic flows mostly
segments that such flows usually have. Fast retransmit [RFC5681], have four or more segments outstanding, allowing loss recovery by
the preferred loss recovery mechanism, is triggered whenever three fast retransmit. However, there is no harm in using RTOR for such
dupACKs arrive at a TCP sender. Duplicate acknowledgments are traffic as the algorithm only is active when the amount of
generated by a receiver when out-of-order segments arrive. As both outstanding and unsent segments are less than rrthresh (default 4).
segment loss and segment reordering cause out-of-order arrival, fast
retransmit waits for three dupACKs before regarding the segment as
lost. Considering this, bulk flows will mostly use fast retransmit
as they often have three or more outstanding segments. Moreover, as
RTOR is not activated as long as there are rrthresh, or more,
segments outstanding the risk of recovering loss using timeouts
instead of fast retransmits can be controlled.
Given RTOR's ability to only work when it is beneficial for the loss Given RTOR's ability to only work when it is beneficial for the loss
recovery process, it is suitable as a system-wide default mechanism recovery process, it is suitable as a system-wide default mechanism
for TCP traffic. 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
skipping to change at page 7, line 18 skipping to change at page 7, line 13
more reliably. 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 TCP/SCTP performance as the congestion have a negative effect on TCP/SCTP performance as the congestion
window is reduced to one segment [RFC5681], limiting an application's window is reduced to one segment [RFC5681], limiting an application's
ability to transmit large amounts of data instantaneously. However, ability to transmit large amounts of data instantaneously. However,
with respect to RTOR spurious timeouts are only a problem for with respect to RTOR spurious timeouts are only a problem for
applications transmitting multiple bursts of data within a single applications transmitting multiple bursts of data within a single
flow. Other types of flows, e.g. long-lived bulk flows, are not flow. Other types of flows, e.g. long-lived bulk flows, are not
affected as the algorithm is only applied when the amount of affected as the algorithm is only applied when the amount of
outstanding segments is less than rrthresh and no previously unsent outstanding and unsent segments is less than rrthresh. Furthermore,
data is available. Furthermore, short-lived and application-limited short-lived and application-limited flows are typically not affected
flows are typically not affected as they are too short to experience as they are too short to experience the effect of congestion control
the effect of congestion control or have a transmission rate that is or have a 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. to proposed standard.
5.3. Tracking Outstanding Segments 5.3. Tracking Outstanding and Previously Unsent Segments
Section 3.2 of [RFC5827] outlines a general method of tracking the Section 3.2 of [RFC5827] outlines a general method of tracking the
number of outstanding segments. This method can be used by TCP number of outstanding segments. This method can be used by TCP
implementations that do not natively track this number. The basic implementations that do not natively perform such tracking. The
idea is to track the segment boundaries of the last transmitted basic idea is to track the segment boundaries of the last transmitted
segments (rrthresh segments for RTOR). In practice this could be segments. In practice this could be achieved by keeping a circular
achieved by keeping a circular list of the last rrthresh segment list of the last rrthresh segment boundaries. Then, cumulative ACKs
boundaries. Then, cumulative ACKs that do not fall within this that do not fall within this region indicate that at least rrthresh
region indicate that at least rrthresh segments are outstanding. segments are outstanding. Similarly, when cumulative ACKs fall
Similarly, when cumulative ACKs fall within this region, the number within this region, it is possible to exactly determine the number of
of outstanding segments is smaller. outstanding segments. To determine the number of previously unsent
segments, a sender can simply divide the number of bytes in its send
queue with the SMSS.
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
generate additional dupACKs to enable fast retransmit. However, generate additional dupACKs to enable fast retransmit. However,
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 or if the receiver has no buffer space. [RFC5827] for transmission. [RFC5827] specifies an early retransmit algorithm
specifies an early retransmit algorithm to enable fast loss recovery to enable fast loss recovery in such situations. By dynamically
in such situations. By dynamically lowering the number of dupACKs lowering the number of dupACKs needed for fast retransmit
needed for fast retransmit (dupthresh), based on the number of (dupthresh), based on the number of outstanding segments, a smaller
outstanding segments, a smaller number of dupACKs is needed to number of dupACKs is needed to trigger a retransmission. In some
trigger a retransmission. In some situations, however, the algorithm situations, however, the algorithm is of no use or might not work
is of no use or might not work properly. First, if a single segment properly. First, if a single segment is outstanding, and lost, it is
is outstanding, and lost, it is impossible to use early retransmit. impossible to use early retransmit. Second, if ACKs are lost, early
Second, if ACKs are lost, the early retransmit cannot help. Third, retransmit cannot help. Third, if the network path reorders
if the network path reorders segments, the algorithm might cause more segments, the algorithm might cause more unnecessary retransmissions
unnecessary retransmissions than fast retransmit. than fast retransmit. The recommended value of RTOR's rrthresh
variable is based on the dupthresh, but is possible to adapt to allow
Following the fast retransmit mechanism standardized in [RFC5681] tighter integration with other experimental algorithms such as early
this draft assumes a value of 3 for dupthresh, which is used as a retransmit.
basis for rrthresh. However, by considering a dynamic value for
dupthresh a tighter integration with early retransmit (or other
experimental algorithms) could also be possible.
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,
which, according to measurements reported in [TLP], is not uncommon. which, according to measurements reported in [TLP], is not uncommon.
The Probe timeout (PTO) is normally two RTTs, and a spurious PTO is The Probe timeout (PTO) is normally two RTTs, and a spurious PTO is
less risky than a spurious RTO because it would not have the same less risky than a spurious RTO because it would not have the same
negative effects (clearing the scoreboard and restarting with slow- negative effects (clearing the scoreboard and restarting with slow-
skipping to change at page 9, line 27 skipping to change at page 9, line 19
9. Security Considerations 9. Security Considerations
This document discusses a change in how to set the retransmission This document discusses a change in how to set the retransmission
timer's value when restarted. This change does not raise any new timer's value when restarted. This change does not raise any new
security issues with TCP or SCTP. security issues with TCP or SCTP.
10. Changes from Previous Versions 10. Changes from Previous Versions
RFC-Editor note: please remove this section prior to publication. RFC-Editor note: please remove this section prior to publication.
10.1. Changes from draft-ietf-...-02 to -03 10.1. Changes from draft-ietf-...-03 to -04
o Changed the algorithm to allow RTOR when there is unsent data
available, but the cwnd does not allow transmission.
o Changed the algorithm to not trigger if "RTO - T_earliest" <= 0,
to avoid that ACKs to previous retransmissions trigger premature
timeouts.
o Made minor adjustments throughout the document to adjust for the
algorithmic change.
o Improved the wording throughout the document.
10.2. 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.
10.2. Changes from draft-ietf-...-01 to -02 10.3. 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.
10.3. Changes from draft-ietf-...-00 to -01 10.4. 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. 22 change blocks. 
93 lines changed or deleted 101 lines changed or added

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