draft-ietf-tcpm-rtorestart-04.txt   draft-ietf-tcpm-rtorestart-05.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: April 30, 2015 A. Petlund Expires: September 10, 2015 A. Petlund
Simula Research Laboratory AS Simula Research Laboratory AS
M. Welzl M. Welzl
University of Oslo University of Oslo
October 27, 2014 March 9, 2015
TCP and SCTP RTO Restart TCP and SCTP RTO Restart
draft-ietf-tcpm-rtorestart-04 draft-ietf-tcpm-rtorestart-05
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 April 30, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 3, line 34 skipping to change at page 3, line 34
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 variables:
RTO Restart threshold (rrthresh): RTOR is enabled whenever the total The number of previously unsent segments (prevunsnt): The number of
number of outstanding and previously unsent segments is below this segments that a sender has queued for transmission, but has not yet
threshold. sent.
RTO Restart threshold (rrthresh): RTOR is enabled whenever the sum of
the number of outstanding and previously unsent segments (prevunsnt)
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 standardized RTO timer management is illustrated in Figure 1 The standardized RTO timer management is illustrated in Figure 1
where a TCP sender transmits three segments to a receiver. The where a TCP sender transmits three segments to a receiver. The
arrival of the first and second segment triggers a delayed ACK arrival of the first and second segment triggers a delayed ACK
(delACK) [RFC1122], which restarts the RTO timer at the sender. RTO (delACK) [RFC1122], which restarts the RTO timer at the sender. The
restart is performed approximately one RTT after the transmission of RTO is restarted approximately one RTT after the transmission of the
the third segment. Thus, if the third segment is lost, as indicated third segment. Thus, if the third segment is lost, as indicated in
in Figure 1, the effective loss detection time is "RTO + RTT" Figure 1, the effective loss detection time is "RTO + RTT" seconds.
seconds. In some situations, the effective loss detection time In some situations, the effective loss detection time becomes even
becomes even longer. Consider a scenario where only two segments are longer. Consider a scenario where only two segments are outstanding.
outstanding. If the second segment is lost, the time to expire the If the second segment is lost, the time to expire the delACK timer
delACK timer will also be included in the effective loss detection will also be included in the effective loss detection time.
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 28 skipping to change at page 5, line 31
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.
(2) If the total number of outstanding and previously unsent (2) If the sum of the number of outstanding and previously unsent
segments is less than an RTOR threshold (rrthresh), set segments (prevunsnt) is less than an RTOR threshold
T_earliest to the time elapsed since the earliest outstanding (rrthresh), set T_earliest to the time elapsed since the
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 is > 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 it will prevent RTOR
from being more aggressive and potentially causing RTOs instead of from being more aggressive and potentially causing RTOs instead of
fast retransmits. This update needs TCP implementations to track the fast retransmits. This update needs TCP implementations to track the
time elapsed since the transmission of the earliest outstanding time elapsed since the transmission of the earliest outstanding
segment (T_earliest). As RTOR is only used when the amount of segment (T_earliest). As RTOR is only used when the amount of
outstanding and unsent data is less than rrthresh segments, TCP outstanding and previously unsent data is less than rrthresh
implementations also need to track whether the amount of outstanding segments, TCP implementations also need to track whether the amount
and unsent data is more, equal, or less than rrthresh segments. of outstanding and previously unsent data is more, equal, or less
Although some packet-based TCP implementations (e.g. Linux TCP) than rrthresh segments. Although some packet-based TCP
already track both the transmission times of all segments and also implementations (e.g. Linux TCP) already track both the transmission
the number of outstanding segments, not all implementations do. times of all segments and also the number of outstanding segments,
Section 5.3 describes how to implement segment tracking for a general not all implementations do. Section 5.3 describes how to implement
TCP implementation. RTOR is applied only if the calculated segment tracking for a general TCP implementation. To use RTOR, the
expiration time is positive (step 3(a) in the list above). This is calculated expiration time MUST be positive (step 3(a) in the list
done to ensure that RTOR does not trigger retransmissions prematurely above); this is required to ensure that RTOR does not trigger
when previously retransmitted segments are acknowledged. 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 36 skipping to change at page 6, line 40
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 from RTOR is that such traffic flows mostly traffic does not benefit from RTOR is that such traffic flows mostly
have four or more segments outstanding, allowing loss recovery by have four or more segments outstanding, allowing loss recovery by
fast retransmit. However, there is no harm in using RTOR for such fast retransmit. However, there is no harm in using RTOR for such
traffic as the algorithm only is active when the amount of traffic as the algorithm only is active when the amount of
outstanding and unsent segments are less than rrthresh (default 4). outstanding and unsent segments are less than rrthresh (default 4).
Given RTOR's ability to only work when it is beneficial for the loss Given that RTOR is a mostly conservative algorithm, it is suitable
recovery process, it is suitable as a system-wide default mechanism for experimentation as a system-wide default 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
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, conducted by the authors, show slight increases in the measurements, show slight increases in the number of spurious
number of spurious timeouts when such lower values are used. timeouts when such lower values are used [RHB15]. However, further
However, further experiments, in different environments and with experiments, in different environments and with different types of
different types of traffic, are encouraged to quantify such increases traffic, are encouraged to quantify such increases 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 the network as segments are transmitted
window is reduced to one segment [RFC5681], limiting an application's needlessly. However, recent experiments do not show a significant
ability to transmit large amounts of data instantaneously. However, increase in network load for a number of realistic scenarios [RHB15].
with respect to RTOR spurious timeouts are only a problem for Another problem with spurious retransmissions is related to the
applications transmitting multiple bursts of data within a single performance of TCP/SCTP, as the congestion window is reduced to one
flow. Other types of flows, e.g. long-lived bulk flows, are not segment when timeouts occur [RFC5681]. This could be a potential
affected as the algorithm is only applied when the amount of problem for applications transmitting multiple bursts of data within
outstanding and unsent segments is less than rrthresh. Furthermore, a single flow, e.g. web-based HTTP/1.1 and HTTP/2.0 applications.
short-lived and application-limited flows are typically not affected However, results from recent experiments involving persistent web
as they are too short to experience the effect of congestion control traffic [RHB15] only revealed a net gain of using RTOR. Other types
or have a transmission rate that is quickly attainable. of flows, e.g. long-lived bulk flows, are not affected as the
algorithm is only applied when the amount of outstanding and unsent
segments is less than rrthresh. Furthermore, short-lived and
application-limited flows are typically not affected as they are too
short to experience the effect of congestion control or have a
transmission rate that is 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. For instance, RTOR has not been evaluated in
the context of mobile networks. Mobile networks often incur highly
variable RTTs (delay spikes), due to e.g. handovers, and would
therefore be a useful scenario for further experimentation.
5.3. Tracking Outstanding and Previously Unsent Segments 5.3. Tracking Outstanding and Previously Unsent Segments
Section 3.2 of [RFC5827] outlines a general method of tracking the The method of tracking outstanding and previously unsent segments
number of outstanding segments. This method can be used by TCP will probably differ depending on the actual TCP implementation. For
implementations that do not natively perform such tracking. The packet-based TCP implementations, tracking outstanding segments is
basic idea is to track the segment boundaries of the last transmitted often straightforward and can be implemented using a simple counter.
segments. In practice this could be achieved by keeping a circular For byte-based TCP stacks it is a more complex task. Section 3.2 of
list of the last rrthresh segment boundaries. Then, cumulative ACKs [RFC5827] outlines a general method of tracking the number of
that do not fall within this region indicate that at least rrthresh outstanding segments. The same method can be used for RTOR. The
segments are outstanding. Similarly, when cumulative ACKs fall implementation will have to track segment boundaries to form an
within this region, it is possible to exactly determine the number of understanding as to how many actual segments have been transmitted,
outstanding segments. To determine the number of previously unsent but not acknowledged. This can be done by the sender tracking the
segments, a sender can simply divide the number of bytes in its send boundaries of the rrthresh segments on the right side of the current
queue with the SMSS. window (which involves tracking rrthresh + 1 sequence numbers in
TCP). This could be done by keeping a circular list of the segment
boundaries, for instance. Cumulative ACKs that do not fall within
this region indicate that at least rrthresh segments are outstanding,
and therefore RTOR is not enabled. When the outstanding window
becomes small enough that RTOR can be invoked, a full understanding
of the number of outstanding segments will be available from the
rrthresh + 1 sequence numbers retained. (Note: the implicit sequence
number consumed by the TCP FIN bit can also be included in the
tracking of segment boundaries.)
Tracking the number of previously unsent segments depends on the
segmentation strategy used by the TCP implementation, not whether it
is packet-based or byte-based. In the case segments are formed
directly on socket writes, the process of determining the number of
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, a straightforward strategy could be to divide the amount of
unsent data (in bytes) with the SMSS to obtain an estimate. In some
cases, such an estimation could be too simplistic, depending on the
segmentation strategy of the TCP implementation. However, this
estimation is not critical to RTOR. For instance, 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. 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
disabled.
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 8, line 25 skipping to change at page 9, line 17
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,
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 Furthermore, TLP also tries to circumvent the congestion window reset
less risky than a spurious RTO because it would not have the same to one segment by instead enabling fast recovery. The Probe timeout
negative effects (clearing the scoreboard and restarting with slow- (PTO) is normally two RTTs, and a spurious PTO is less risky than a
start). In contrast, RTOR is trying to make the RTO more appropriate spurious RTO because it would not have the same negative effects
in cases where there is no need to be overly cautious. (clearing the scoreboard and restarting with slow-start). TLP is a
more advanced mechanism than RTOR, requiring e.g. SACK to work, and
is often able to reduce loss recovery times more. However, it also
increases the amount of spurious retransmissions noticeably, as
compared to RTOR [RHB15].
TLP is applicable in situations where RTOR does not apply, and it TLP is applicable in situations where RTOR does not apply, and it
could overrule (yielding a similar general behavior, but with a lower could overrule (yielding a similar general behavior, but with a lower
timeout) RTOR in cases where the number of outstanding segments is timeout) RTOR in cases where the number of outstanding segments is
smaller than four and no new segments are available for transmission. smaller than four and no new segments are available for transmission.
The PTO has the same inherent problem of restarting the timer on an The PTO has the same inherent problem of restarting the timer on an
incoming ACK, and could be combined with a strategy similar to RTOR's incoming ACK, and could be combined with a strategy similar to RTOR's
to offer more consistent timeouts. to offer more consistent timeouts.
7. Acknowledgements 7. Acknowledgements
The authors wish to thank Godred Fairhurst, Yuchung Cheng, Mark The authors wish to thank Godred Fairhurst, Yuchung Cheng, Mark
Allman, Anantha Ramaiah, Richard Scheffenegger, Nicolas Kuhn, and Allman, Anantha Ramaiah, Richard Scheffenegger, Nicolas Kuhn,
Alexander Zimmermann for commenting the draft and the ideas behind Alexander Zimmermann, and Michael Scharf for commenting on the draft
it. and the ideas behind it.
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.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
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. Therefore, the security considerations
security issues with TCP or SCTP. found in [RFC6298] apply to this document. No additional security
problems have been identified with RTO Restart at this time.
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-...-03 to -04 10.1. Changes from draft-ietf-...-04 to -05
o Introduced variable to track the number of previously unsent
segments.
o Clarified many concepts, e.g. extended the description on how to
track outstanding and previously unsent segments.
o Added a reference to initial measurements on the effects of using
RTOR.
o Improved wording throughout the document.
10.2. 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 "RTO - T_earliest" <= 0, o Changed the algorithm to not trigger if RTOR <= 0.
to avoid that ACKs to previous retransmissions trigger premature
timeouts.
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.
10.2. Changes from draft-ietf-...-02 to -03 10.3. 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.3. Changes from draft-ietf-...-01 to -02 10.4. 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.4. Changes from draft-ietf-...-00 to -01 10.5. 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.
skipping to change at page 12, line 22 skipping to change at page 13, line 37
[PBP09] Petlund, A., Beskow, P., Pedersen, J., Paaby, E., Griwodz, [PBP09] Petlund, A., Beskow, P., Pedersen, J., Paaby, E., Griwodz,
C., and P. Halvorsen, "Improving SCTP Retransmission C., and P. Halvorsen, "Improving SCTP Retransmission
Delays for Time-Dependent Thin Streams", Springer Delays for Time-Dependent Thin Streams", Springer
Multimedia Tools and Applications, 45(1-3), 2009. Multimedia Tools and Applications, 45(1-3), 2009.
[PGH06] Pedersen, J., Griwodz, C., and P. Halvorsen, [PGH06] Pedersen, J., Griwodz, C., and P. Halvorsen,
"Considerations of SCTP Retransmission Delays for Thin "Considerations of SCTP Retransmission Delays for Thin
Streams", IEEE LCN 2006, November 2006. Streams", IEEE LCN 2006, November 2006.
[RHB15] Rajiullah, M., Hurtig, P., Brunstrom, A., Petlund, A., and
M. Welzl, "An Evaluation of Tail Loss Recovery Mechanisms
for TCP", ACM SIGCOMM CCR 45 (1), January 2015.
[RJ10] Ramachandran, S., "Web metrics: Size and number of [RJ10] Ramachandran, S., "Web metrics: Size and number of
resources", Google resources", Google
http://code.google.com/speed/articles/web-metrics.html, http://code.google.com/speed/articles/web-metrics.html,
May 2010. May 2010.
[TLP] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, [TLP] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis,
"TCP Loss Probe (TLP): An Algorithm for Fast Recovery of "TCP Loss Probe (TLP): An Algorithm for Fast Recovery of
Tail Losses", Internet-draft draft-dukkipati-tcpm-tcp- Tail Losses", Internet-draft draft-dukkipati-tcpm-tcp-
loss-probe-01.txt, February 2013. loss-probe-01.txt, February 2013.
 End of changes. 25 change blocks. 
83 lines changed or deleted 142 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/