draft-ietf-tcpm-rtorestart-10.txt   rfc7765.txt 
TCP Maintenance and Minor Extensions (tcpm) P. Hurtig Internet Engineering Task Force (IETF) P. Hurtig
Internet-Draft A. Brunstrom Request for Comments: 7765 A. Brunstrom
Intended status: Experimental Karlstad University Category: Experimental Karlstad University
Expires: May 8, 2016 A. Petlund ISSN: 2070-1721 A. Petlund
Simula Research Laboratory AS Simula Research Laboratory AS
M. Welzl M. Welzl
University of Oslo University of Oslo
November 5, 2015 February 2016
TCP and SCTP RTO Restart TCP and Stream Control Transmission Protocol (SCTP) RTO Restart
draft-ietf-tcpm-rtorestart-10
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 Stream Control Transmission Protocol (SCTP)
recovery when there is a small amount of outstanding data for a retransmission timers that provides faster loss recovery when there
connection. The modification, RTO Restart (RTOR), allows the is a small amount of outstanding data for a connection. The
transport to restart its retransmission timer using a smaller timeout modification, RTO Restart (RTOR), allows the transport to restart its
duration, so that the effective RTO becomes more aggressive in retransmission timer using a smaller timeout duration, so that the
effective retransmission timeout (RTO) becomes more aggressive in
situations where fast retransmit cannot be used. This enables faster situations where fast retransmit cannot be used. This enables faster
loss detection and recovery for connections that are short-lived or loss detection and recovery for connections that are short lived or
application-limited. application limited.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on May 8, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7765.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. RTO Overview and Rationale for RTOR . . . . . . . . . . . . . 4
4. RTOR Algorithm . . . . . . . . . . . . . . . . . . . . . . . 6
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Spurious Timeouts . . . . . . . . . . . . . . . . . . . . 7
5.3. Tracking Outstanding and Previously Unsent Segments . . . 8
6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 9
7. SCTP Socket API Considerations . . . . . . . . . . . . . . . 10
7.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Socket Option for Controlling the RTO Restart Support
(SCTP_RTO_RESTART) . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
TCP and SCTP use two almost identical mechanisms to detect and TCP and SCTP use two almost identical mechanisms to detect and
recover from data loss, specified in [RFC6298][RFC5681] (for TCP) and recover from data loss, specified in [RFC6298] and [RFC5681] for TCP
[RFC4960] (for SCTP). First, if transmitted data is not acknowledged and [RFC4960] for SCTP. First, if transmitted data is not
within a certain amount of time, a retransmission timeout (RTO) acknowledged within a certain amount of time, a retransmission
occurs, and the data is retransmitted. While the RTO is based on timeout (RTO) occurs and the data is retransmitted. While the RTO is
measured round-trip times (RTTs) between the sender and receiver, it based on measured round-trip times (RTTs) between the sender and
also has a conservative lower bound of 1 second to ensure that receiver, it also has a conservative lower bound of 1 second to
delayed data are not mistaken as lost. Second, when a sender ensure that delayed data are not mistaken as lost. Second, when a
receives duplicate acknowledgments, or similar information via sender receives duplicate acknowledgments or similar information via
selective acknowledgments, the fast retransmit algorithm suspects selective acknowledgments, the fast retransmit algorithm suspects
data loss and can trigger a retransmission. Duplicate (and data loss and can trigger a retransmission. Duplicate (and
selective) acknowledgments are generated by a receiver when data selective) acknowledgments are generated by a receiver when data
arrives out-of-order. As both data loss and data reordering cause arrives out of order. As both data loss and data reordering cause
out-of-order arrival, fast retransmit waits for three out-of-order out-of-order arrival, fast retransmit waits for three out-of-order
notifications before considering the corresponding data as lost. In notifications before considering the corresponding data as lost. In
some situations, however, the amount of outstanding data is not some situations, however, the amount of outstanding data is not
enough to trigger three such acknowledgments, and the sender must enough to trigger three such acknowledgments, and the sender must
rely on lengthy RTOs for loss recovery. rely on lengthy RTOs for loss recovery.
The amount of outstanding data 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 congestion control when the path
path has a low total capacity (bandwidth-delay product) or the 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 congestion control in the first few RTTs of a connection or
or after an RTO when the available capacity is probed using 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.
(3) The connection is limited by the application if the available (3) The connection is limited by the application if the available
capacity of the path is not fully utilized (e.g. interactive capacity of the path is not fully utilized (e.g., interactive
applications), or at the end of a transfer. applications) or is at the end of a transfer.
While the reasons listed above are valid for any flow, the third While the reasons listed above are valid for any flow, the third
reason is most common for applications that transmit short flows, or reason is most common for applications that transmit short flows or
use a bursty transmission pattern. A typical example of applications use a bursty transmission pattern. A typical example of applications
that produce short flows are web-based applications. [RJ10] shows that produce short flows are web-based applications. [RJ10] shows
that 70% of all web objects, found at the top 500 sites, are too that 70% of all web objects, found at the top 500 sites, are too
small for fast retransmit to work. [FDT13] shows that about 77% of small for fast retransmit to work. [FDT13] shows that about 77% of
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 are often time dependent, 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
effective RTO slightly more aggressive when the amount of outstanding effective RTO slightly more aggressive when the amount of outstanding
data is too small for fast retransmit to work, in an attempt to data is too small for fast retransmit to work, in an attempt to
enable faster loss recovery while being robust to reordering. While enable faster loss recovery while being robust to reordering. While
RTOR still conforms to the requirement for when a segment can be RTOR still conforms to the requirement for when a segment can be
retransmitted, specified in [RFC6298] (for TCP) and [RFC4960] (for retransmitted, specified in [RFC6298] for TCP and [RFC4960] for SCTP,
SCTP) it could increase the risk of spurious timeouts. To determine it could increase the risk of spurious timeouts. To determine
whether this modification is safe to deploy and enable by default, whether this modification is safe to deploy and enable by default,
further experimentation is required. Section 5 discusses experiments further experimentation is required. Section 5 discusses experiments
still needed, including evaluations in environments where the risk of still needed, including evaluations in environments where the risk of
spurious retransmissions are increased e.g. mobile networks with spurious retransmissions are increased, e.g., mobile networks with
highly varying RTTs. highly varying RTTs.
The remainder of this document describes RTOR and its implementation The remainder of this document describes RTOR and its implementation
for TCP only, to make the document easier to read. However, the RTOR for TCP only, to make the document easier to read. However, the RTOR
algorithm described in Section 4 is applicable also for SCTP. algorithm described in Section 4 is applicable also for SCTP.
Furthermore, Section 7 details the SCTP socket API needed to control Furthermore, Section 7 details the SCTP socket API needed to control
RTOR. 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 o The number of previously unsent segments (prevunsnt): The number
segments that a sender has queued for transmission, but has not yet of segments that a sender has queued for transmission, but has not
sent. yet sent.
RTO Restart threshold (rrthresh): RTOR is enabled whenever the sum of o RTO Restart threshold (rrthresh): RTOR is enabled whenever the sum
the number of outstanding and previously unsent segments (prevunsnt) of the number of outstanding and previously unsent segments
is below this threshold. (prevunsnt) is below this threshold.
3. RTO Overview and Rationale for RTOR 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 be 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. The segments will be retransmitted after approximately RTO seconds. The
standardized RTO timer management is illustrated in Figure 1 where a standardized RTO timer management is illustrated in Figure 1, where a
TCP sender transmits three segments to a receiver. The arrival of TCP sender transmits three segments to a receiver. The arrival of
the first and second segment triggers a delayed ACK (delACK) the first and second segment triggers a delayed ACK (delACK)
[RFC1122], which restarts the RTO timer at the sender. The RTO is [RFC1122], which restarts the RTO timer at the sender. The RTO is
restarted approximately one RTT after the transmission of the third restarted approximately one RTT after the transmission of the third
segment. Thus, if the third segment is lost, as indicated in segment. Thus, if the third segment is lost, as indicated in
Figure 1, the effective loss detection time become "RTO + RTT" Figure 1, the effective loss detection time becomes "RTO + RTT"
seconds. In some situations, the effective loss detection time seconds. In some situations, the effective loss detection time
becomes even longer. Consider a scenario where only two segments are becomes even longer. Consider a scenario where only two segments are
outstanding. If the second segment is lost, the time to expire the outstanding. If the second segment is lost, the time to expire the
delACK timer will also be included in the effective loss detection delACK timer 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] ---------------------->
Figure 1: RTO restart example Figure 1: RTO Restart Example
For bulk traffic the current approach is beneficial -- it is For bulk traffic, the current approach is beneficial -- it is
described in [EL04] to act as a "safety margin" that compensates for described in [EL04] to act as a "safety margin" that compensates for
some of the problems that the authors have identified with the some of the problems that the authors have identified with the
standard RTO calculation. Notably, the authors of [EL04] also state standard RTO calculation. Notably, the authors of [EL04] also state
that "this safety margin does not exist for highly interactive that "this safety margin does not exist for highly interactive
applications where often only a single packet is in flight". In applications where often only a single packet is in flight." In
general, however, as long as enough segments arrive at a receiver to general, however, as long as enough segments arrive at a receiver to
enable fast retransmit, RTO-based loss recovery should be avoided. enable fast retransmit, RTO-based loss recovery should be avoided.
RTOs should only be used as a last resort, as they drastically lower RTOs should only be used as a last resort, as they drastically lower
the congestion window compared to fast retransmit. the congestion window as compared to fast retransmit.
Although fast retransmit is preferrable there are situations where Although fast retransmit is preferable, there are situations where
timeouts are appropriate, or the only choice. For example, if the timeouts are appropriate or are 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. occur after exactly RTO seconds.
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 sum of the number of outstanding and previously unsent (2) If the sum of the number of outstanding and previously unsent
segments (prevunsnt) is less than an RTOR threshold segments (prevunsnt) is less than an RTOR threshold
(rrthresh), set T_earliest to the time elapsed since the (rrthresh), set T_earliest to the time elapsed since the
skipping to change at page 5, line 52 skipping to change at page 6, line 43
(b) RTO, otherwise. (b) RTO, otherwise.
The RECOMMENDED value of rrthresh is four, as this value will ensure The RECOMMENDED value of rrthresh is four, as this value will ensure
that RTOR is only used when fast retransmit cannot be triggered. that RTOR is only used when fast retransmit cannot be triggered.
With this update, TCP implementations MUST track the time elapsed With this update, TCP implementations MUST track the time elapsed
since the transmission of the earliest outstanding segment since the transmission of the earliest outstanding segment
(T_earliest). As RTOR is only used when the amount of outstanding (T_earliest). As RTOR is only used when the amount of outstanding
and previously unsent data is less than rrthresh segments, TCP and previously unsent data is less than rrthresh segments, TCP
implementations also need to track whether the amount of outstanding implementations also need to track whether the amount of outstanding
and previously unsent data is more, equal, or less than rrthresh and previously unsent data is more, equal, or less than rrthresh
segments. Although some packet-based TCP implementations (e.g. segments. Although some packet-based TCP implementations (e.g.,
Linux TCP) already track both the transmission times of all segments Linux TCP) already track both the transmission times of all segments
and also the number of outstanding segments, not all implementations and also the number of outstanding segments, not all implementations
do. Section 5.3 describes how to implement segment tracking for a do. Section 5.3 describes how to implement segment tracking for a
general TCP implementation. To use RTOR, the calculated expiration general TCP implementation. To use RTOR, the calculated expiration
time MUST be positive (step 3(a) in the list above); this is required time MUST be positive (step 3(a) in the list above); this is required
to ensure that RTOR does not trigger retransmissions prematurely when to ensure that RTOR does not trigger retransmissions prematurely when
previously retransmitted segments are acknowledged. previously retransmitted segments are acknowledged.
5. Discussion 5. Discussion
Although RTOR conforms to the requirement in [RFC6298] that segments Although RTOR conforms to the requirement in [RFC6298] that segments
must not be retransmitted earlier than RTO seconds after their must not be retransmitted earlier than RTO seconds after their
original transmission, RTOR makes the effective RTO more aggressive. original transmission, RTOR makes the effective RTO more aggressive.
In this section, we discuss the applicability and the issues related In this section, we discuss the applicability and the issues related
to RTOR. 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]
[HB11][PBP09]. For applications that have strict timing requirements [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 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] and [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 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 is only 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 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 timeouts measurements show slight increases in the number of spurious 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] revealed a net gain of using RTOR. Other types of traffic [RHB15] revealed a net gain using RTOR. Other types of
flows, e.g. long-lived bulk flows, are not affected as the algorithm 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 is only applied when the amount of outstanding and unsent segments is
less than rrthresh. Furthermore, short-lived and application-limited less than rrthresh. Furthermore, short-lived and application-limited
flows are typically not affected as they are too short to experience flows are typically not affected as they are too short to experience
the effect of congestion control or have a transmission rate that is the effect of congestion control 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 or not the effects of this increase
any future algorithmic changes or not -- especially since most modern mandate any future algorithmic changes -- especially since most
operating systems already include mechanisms to detect modern 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 the standards track. For instance, RTOR has not been evaluated in to the Standards Track. 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
variable RTTs (delay spikes), due to e.g. handovers, and would variable RTTs (delay spikes), due to e.g., handovers, and would
therefore be a useful scenario for further experimentation. therefore be a useful scenario for further experimentation.
5.3. Tracking Outstanding and Previously Unsent Segments 5.3. Tracking Outstanding and Previously Unsent Segments
The method of tracking outstanding and previously unsent segments The method of tracking outstanding and previously unsent segments
will probably differ depending on the actual TCP implementation. For will probably differ depending on the actual TCP implementation. For
packet-based TCP implementations, tracking outstanding segments is packet-based TCP implementations, tracking outstanding segments is
often straightforward and can be implemented using a simple counter. often straightforward and can be implemented using a simple counter.
For byte-based TCP stacks it is a more complex task. Section 3.2 of For byte-based TCP stacks, it is a more complex task. Section 3.2 of
[RFC5827] outlines a general method of tracking the number of [RFC5827] outlines a general method of tracking the number of
outstanding segments. The same method can be used for RTOR. The outstanding segments. The same method can be used for RTOR. The
implementation will have to track segment boundaries to form an implementation will have to track segment boundaries to form an
understanding as to how many actual segments have been transmitted, understanding as to how many actual segments have been transmitted
but not acknowledged. This can be done by the sender tracking the but not acknowledged. This can be done by the sender tracking the
boundaries of the rrthresh segments on the right side of the current boundaries of the rrthresh segments on the right side of the current
window (which involves tracking rrthresh + 1 sequence numbers in window (which involves tracking rrthresh + 1 sequence numbers in
TCP). This could be done by keeping a circular list of the segment TCP). This could be done by keeping a circular list of the segment
boundaries, for instance. Cumulative ACKs that do not fall within boundaries, for instance. Cumulative ACKs that do not fall within
this region indicate that at least rrthresh segments are outstanding, this region indicate that at least rrthresh segments are outstanding,
and therefore RTOR is not enabled. When the outstanding window and therefore RTOR is not enabled. When the outstanding window
becomes small enough that RTOR can be invoked, a full understanding becomes small enough that RTOR can be invoked, a full understanding
of the number of outstanding segments will be available from the of the number of outstanding segments will be available from the
rrthresh + 1 sequence numbers retained. (Note: the implicit sequence rrthresh + 1 sequence numbers retained. (Note: the implicit sequence
number consumed by the TCP FIN bit can also be included in the number consumed by the TCP FIN bit can also be included in the
tracking of segment boundaries.) tracking of segment boundaries.)
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 where 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 resegmented) as long as it is still
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 Sender Maximum Segment Size (SMSS) to
cases, such an estimation could be too simplistic, depending on the obtain an estimate. In some cases, such an estimation could be too
segmentation strategy of the TCP implementation. However, this simplistic, depending on the segmentation strategy of the TCP
estimation is not critical to RTOR. The tracking of prevunsnt is implementation. However, this estimation is not critical to RTOR.
only made to optimize a corner case in which RTOR was unnecessarily The tracking of prevunsnt is only made to optimize a corner case in
disabled. Implementations can use a simplified method by setting which RTOR was unnecessarily disabled. Implementations can use a
prevunsnt to rrthresh whenever previously unsent data is available, simplified method by setting prevunsnt to rrthresh whenever
and set prevunsnt to zero when no new data is available. This will previously unsent data is available, and set prevunsnt to zero when
disable RTOR in the presence of unsent data and only use the number no new data is available. This will disable RTOR in the presence of
of outstanding segments to enable/disable RTOR. 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 duplicate acknowledgements (dupACKs). By transmitting new segments,
generate additional dupACKs to enable fast retransmit. However, the sender attempts to generate additional dupACKs to enable fast
limited transmit does not help if no previously unsent data is ready retransmit. However, limited transmit does not help if no previously
for transmission. [RFC5827] specifies an early retransmit algorithm unsent data is ready for transmission. [RFC5827] specifies an early
to enable fast loss recovery in such situations. By dynamically retransmit algorithm to enable fast loss recovery in such situations.
lowering the number of dupACKs needed for fast retransmit By dynamically lowering the number of dupACKs needed for fast
(dupthresh), based on the number of outstanding segments, a smaller retransmit (dupthresh), based on the number of outstanding segments,
number of dupACKs is needed to trigger a retransmission. In some a smaller number of dupACKs is needed to trigger a retransmission.
situations, however, the algorithm is of no use or might not work In some situations, however, the algorithm is of no use or might not
properly. First, if a single segment is outstanding, and lost, it is work properly. First, if a single segment is outstanding and lost,
impossible to use early retransmit. Second, if ACKs are lost, early it is impossible to use early retransmit. Second, if ACKs are lost,
retransmit cannot help. Third, if the network path reorders early retransmit cannot help. Third, if the network path reorders
segments, the algorithm might cause more spurious 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 it is possible to adapt to
tighter integration with other experimental algorithms such as early allow tighter integration with other experimental algorithms such as
retransmit. early 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 that 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 it is a retransmission. The intention is to compensate for
RTO behavior in situations where the RTO greatly exceeds the RTT, sluggish RTO behavior in situations where the RTO greatly exceeds the
which, according to measurements reported in [TLP], is not uncommon. RTT, which, according to measurements reported in [TLP], is not
Furthermore, TLP also tries to circumvent the congestion window reset uncommon. Furthermore, TLP also tries to circumvent the congestion
to one segment by instead enabling fast recovery. The Probe timeout window reset to one segment by instead enabling fast recovery. The
(PTO) is normally two RTTs, and a spurious PTO is less risky than a probe timeout (PTO) is normally two RTTs, and a spurious PTO is less
spurious RTO because it would not have the same negative effects risky than a spurious RTO because it would not have the same negative
(clearing the scoreboard and restarting with slow-start). TLP is a effects (clearing the scoreboard and restarting with slow-start).
more advanced mechanism than RTOR, requiring e.g. SACK to work, and TLP is a more advanced mechanism than RTOR, requiring e.g., SACK to
is often able to reduce loss recovery times more. However, it also work, and is often able to further reduce loss recovery times.
increases the amount of spurious retransmissions noticeably, as However, it also noticeably increases the amount of spurious
compared to RTOR [RHB15]. retransmissions, 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. SCTP Socket API Considerations 7. SCTP Socket API Considerations
This section describes how the socket API for SCTP defined in This section describes how the socket API for SCTP defined in
[RFC6458] is extended to control the usage of RTO restart for SCTP. [RFC6458] is extended to control the usage of RTO restart for SCTP.
Please note that this section is informational only. Please note that this section is informational only.
7.1. Data Types 7.1. Data Types
This section uses data types from [IEEE.1003-1G.1997]: uintN_t means This section uses data types from [IEEE.9945]: uintN_t means an
an unsigned integer of exactly N bits (e.g., uint16_t). This is the unsigned integer of exactly N bits (e.g., uint16_t). This is the
same as in [RFC6458]. same as in [RFC6458].
7.2. Socket Option for Controlling the RTO Restart Support 7.2. Socket Option for Controlling the RTO Restart Support
(SCTP_RTO_RESTART) (SCTP_RTO_RESTART)
This socket option allows the enabling or disabling of RTO Restart This socket option allows the enabling or disabling of RTO Restart
for SCTP associations. for SCTP associations.
Whether RTO Restart is enabled or not per default is implementation Whether or not RTO restart is enabled per default is implementation
specific. specific.
This socket option uses IPPROTO_SCTP as its level and This socket option uses IPPROTO_SCTP as its level and
SCTP_RTO_RESTART as its name. It can be used with getsockopt() and SCTP_RTO_RESTART as its name. It can be used with getsockopt() and
setsockopt(). The socket option value uses the following structure setsockopt(). The socket option value uses the following structure
defined in [RFC6458]: defined in [RFC6458]:
struct sctp_assoc_value { struct sctp_assoc_value {
sctp_assoc_t assoc_id; sctp_assoc_t assoc_id;
uint32_t assoc_value; uint32_t assoc_value;
skipping to change at page 10, line 37 skipping to change at page 11, line 28
sctp_assoc_t SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used in sctp_assoc_t SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used in
assoc_id for setsockopt(). For getsockopt(), the special value assoc_id for setsockopt(). For getsockopt(), the special value
SCTP_FUTURE_ASSOC can be used in assoc_id, but it is an error to SCTP_FUTURE_ASSOC can be used in assoc_id, but it is an error to
use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. use SCTP_{CURRENT|ALL}_ASSOC in assoc_id.
assoc_value: A non-zero value encodes the enabling of RTO restart assoc_value: A non-zero value encodes the enabling of RTO restart
whereas a value of 0 encodes the disabling of RTO restart. whereas a value of 0 encodes the disabling of RTO restart.
sctp_opt_info() needs to be extended to support SCTP_RTO_RESTART. sctp_opt_info() needs to be extended to support SCTP_RTO_RESTART.
8. IANA Considerations 8. Security Considerations
This memo includes no request to IANA.
9. Security Considerations
This document specifies an experimental sender-only modification to This document specifies an experimental sender-only modification to
TCP and SCTP. The modification introduces a change in how to set the TCP and SCTP. The modification introduces a change in how to set the
retransmission timer's value when restarted. Therefore, the security retransmission timer's value when restarted. Therefore, the security
considerations found in [RFC6298] apply to this document. No considerations found in [RFC6298] apply to this document. No
additional security problems have been identified with RTO Restart at additional security problems have been identified with RTO Restart at
this time. this time.
10. Acknowledgements 9. References
The authors wish to thank Michael Tuexen for contributing the SCTP
Socket API considerations and Godred Fairhurst, Yuchung Cheng, Mark
Allman, Anantha Ramaiah, Richard Scheffenegger, Nicolas Kuhn,
Alexander Zimmermann, and Michael Scharf for commenting on the draft
and the ideas behind it.
All the authors are supported by RITE (http://riteproject.eu/ ), a
research project (ICT-317700) funded by the European Community under
its Seventh Framework Program. The views expressed here are those of
the author(s) only. The European Commission is not liable for any
use that may be made of the information in this document.
11. Changes from Previous Versions
RFC-Editor note: please remove this section prior to publication.
11.1. Changed from draft-ietf-...-09 to -10
o Changed wording in abstract, from "delay" to "timeout duration".
11.2. Changed from draft-ietf-...-08 to -09
o Clarified, in the abstract, that the modified restart causes a
smaller retransmission delay in total.
o Clarified, in the introduction, that the fast retransmit algorithm
may cause retransmissions upon receiving duplicate
acknowledgments, not that it unconditionally does so.
o Changed wording from "to proposed standard" to "to the standards
track".
o Changed algorithm description so that a TCP sender MUST track the
time elapsed since the transmission of the earliest outstanding
segment. This was not explicitly stated in previous versions of
the draft.
11.3. 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.4. Changes from draft-ietf-...-06 to -07
o Clarified, at multiple places in the document, that the
modification is sender-only.
o Added an explanation (in the introduction) to why the mechanism is
experimental and what experiments are missing.
o Added a sentence in Section 4 to clarify that the section is the
one describing the actual modification.
11.5. Changes from draft-ietf-...-05 to -06
o Added socket API considerations, after discussing the draft in
tsvwg.
11.6. 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.
11.7. 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 RTOR <= 0.
o Made minor adjustments throughout the document to adjust for the
algorithmic change.
o Improved the wording throughout the document.
11.8. Changes from draft-ietf-...-02 to -03
o Updated the document to use "RTOR" instead of "RTO Restart" when
refering to the modified algorithm.
o Moved document terminology to a section of its own.
o Introduced the rrthresh variable in the terminology section.
o Added a section to generalize the tracking of outstanding
segments.
o Updated the algorithm to work when the number of outstanding
segments is less than four and one segment is ready for
transmission, by restarting the timer when new data has been sent.
o Clarified the relationship between fast retransmit and RTOR.
o Improved the wording throughout the document.
11.9. Changes from draft-ietf-...-01 to -02
o Changed the algorithm description in Section 3 to use formal RFC
2119 language.
o Changed last paragraph of Section 3 to clarify why the RTO restart
algorithm is active when less than four segments are outstanding.
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
effects on traffic patterns that do not benefit from a modified
timer restart.
o Improved the wording throughout the document.
o Replaced and updated some references.
11.10. Changes from draft-ietf-...-00 to -01
o Improved the wording throughout the document.
o Removed the possibility for a connection limited by the receiver's
advertised window to use RTO restart, decreasing the risk of
spurious retransmission timeouts.
o Added a section that discusses the applicability of and problems
related to the RTO restart mechanism.
o Updated the text describing the relationship to TLP to reflect
updates made in this draft.
o Added acknowledgments.
12. References
12.1. Normative References 9.1. Normative References
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <http://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 15, line 34 skipping to change at page 13, line 5
P. Hurtig, "Early Retransmit for TCP and Stream Control P. Hurtig, "Early Retransmit for TCP and Stream Control
Transmission Protocol (SCTP)", RFC 5827, Transmission Protocol (SCTP)", RFC 5827,
DOI 10.17487/RFC5827, May 2010, DOI 10.17487/RFC5827, May 2010,
<http://www.rfc-editor.org/info/rfc5827>. <http://www.rfc-editor.org/info/rfc5827>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011, DOI 10.17487/RFC6298, June 2011,
<http://www.rfc-editor.org/info/rfc6298>. <http://www.rfc-editor.org/info/rfc6298>.
12.2. Informative References 9.2. Informative References
[EL04] Ekstroem, H. and R. Ludwig, "The Peak-Hopper: A New End- [EL04] Ekstroem, H. and R. Ludwig, "The Peak-Hopper: A New End-
to-End Retransmission Timer for Reliable Unicast to-End Retransmission Timer for Reliable Unicast
Transport", IEEE INFOCOM 2004, March 2004. Transport", IEEE INFOCOM 2004,
DOI 10.1109/INFCOM.2004.1354671, March 2004.
[FDT13] Flach, T., Dukkipati, N., Terzis, A., Raghavan, B., [FDT13] Flach, T., Dukkipati, N., Terzis, A., Raghavan, B.,
Cardwell, N., Cheng, Y., Jain, A., Hao, S., Katz-Bassett, Cardwell, N., Cheng, Y., Jain, A., Hao, S., Katz-Bassett,
E., and R. Govindan, "Reducing Web Latency: the Virtue of E., and R. Govindan, "Reducing Web Latency: the Virtue of
Gentle Aggression", Proc. ACM SIGCOMM Conf., August 2013. Gentle Aggression", Proc. ACM SIGCOMM Conf.,
DOI 10.1145/2486001.2486014, August 2013.
[HB11] Hurtig, P. and A. Brunstrom, "SCTP: designed for timely [HB11] Hurtig, P. and A. Brunstrom, "SCTP: designed for timely
message delivery?", Springer Telecommunication Systems 47 message delivery?", Springer Telecommunication Systems 47
(3-4), August 2011. (3-4), DOI 10.1007/s11235-010-9321-3, August 2011.
[IEEE.1003-1G.1997] [IEEE.9945]
Institute of Electrical and Electronics Engineers, IEEE/ISO/IEC, "International Standard - Information
"Protocol Independent Interfaces", IEEE Standard 1003.1G, technology Portable Operating System Interface (POSIX)
March 1997. Base Specifications, Issue 7", IEEE 9945-2009,
<http://standards.ieee.org/findstds/
standard/9945-2009.html>.
[LS00] Ludwig, R. and K. Sklower, "The Eifel retransmission [LS00] Ludwig, R. and K. Sklower, "The Eifel retransmission
timer", ACM SIGCOMM Comput. Commun. Rev., 30(3), July timer", ACM SIGCOMM Comput. Commun. Rev., 30(3),
2000. DOI 10.1145/382179.383014, July 2000.
[P09] Petlund, A., "Improving latency for interactive, thin- [P09] Petlund, A., "Improving latency for interactive, thin-
stream applications over reliable transport", Unipub PhD stream applications over reliable transport", Unipub PhD
Thesis, Oct 2009. Thesis, Oct 2009.
[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", delays for time-dependent thin streams", Springer
Springer Multimedia Tools and Applications, 45(1-3), 2009. Multimedia Tools and Applications, 45(1-3),
DOI 10.1007/s11042-009-0286-8, October 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, DOI 10.1109/LCN.2006.322082,
November 2006.
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
Yasevich, "Sockets API Extensions for the Stream Control Yasevich, "Sockets API Extensions for the Stream Control
Transmission Protocol (SCTP)", RFC 6458, Transmission Protocol (SCTP)", RFC 6458,
DOI 10.17487/RFC6458, December 2011, DOI 10.17487/RFC6458, December 2011,
<http://www.rfc-editor.org/info/rfc6458>. <http://www.rfc-editor.org/info/rfc6458>.
[RHB15] Rajiullah, M., Hurtig, P., Brunstrom, A., Petlund, A., and [RHB15] Rajiullah, M., Hurtig, P., Brunstrom, A., Petlund, A., and
M. Welzl, "An Evaluation of Tail Loss Recovery Mechanisms M. Welzl, "An Evaluation of Tail Loss Recovery Mechanisms
for TCP", ACM SIGCOMM CCR 45 (1), January 2015. for TCP", ACM SIGCOMM CCR 45 (1),
DOI 10.1145/2717646.2717648, January 2015.
[RJ10] Ramachandran, S., "Web metrics: Size and number of [RJ10] Ramachandran, S., "Web metrics: Size and number of
resources", Google http://code.google.com/speed/articles/ resources", May 2010, <https://goo.gl/0a6Q9A>.
web-metrics.html, 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 "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of
Tail Losses", Internet-draft draft-dukkipati-tcpm-tcp- Tail Losses", Work in Progress, draft-dukkipati-tcpm-tcp-
loss-probe-01.txt, February 2013. loss-probe-01, February 2013.
Acknowledgements
The authors wish to thank Michael Tuexen for contributing the SCTP
Socket API considerations and Godred Fairhurst, Yuchung Cheng, Mark
Allman, Anantha Ramaiah, Richard Scheffenegger, Nicolas Kuhn,
Alexander Zimmermann, and Michael Scharf for commenting on the
document and the ideas behind it.
All the authors are supported by RITE (http://riteproject.eu/), a
research project (ICT-317700) funded by the European Community under
its Seventh Framework Program. The views expressed here are those of
the author(s) only. The European Commission is not liable for any
use that may be made of the information in this document.
Authors' Addresses Authors' Addresses
Per Hurtig Per Hurtig
Karlstad University Karlstad University
Universitetsgatan 2 Universitetsgatan 2
Karlstad 651 88 Karlstad 651 88
Sweden Sweden
Phone: +46 54 700 23 35 Phone: +46 54 700 23 35
 End of changes. 68 change blocks. 
317 lines changed or deleted 198 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/