Internet Engineering Task Force (IETF) P. Hurtig
Request for Comments: 7765 A. Brunstrom
Category: Experimental Karlstad University
ISSN: 2070-1721 A. Petlund
Simula Research Laboratory AS
M. Welzl
University of Oslo
February 2016
Internet Engineering Task Force (IETF) P. Hurtig
Request for Comments: 7765 A. Brunstrom
Category: Experimental Karlstad University
ISSN: 2070-1721 A. Petlund
Simula Research Laboratory AS
M. Welzl
University of Oslo
February 2016
TCP and Stream Control Transmission Protocol (SCTP) RTO Restart
TCP和流控制传输协议（SCTP）RTO重启
Abstract
摘要
This document describes a modified sender-side algorithm for managing the TCP and Stream Control Transmission Protocol (SCTP) retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its 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 loss detection and recovery for connections that are short lived or application limited.
本文档描述了一种改进的发送方算法，用于管理TCP和流控制传输协议（SCTP）重传计时器，该算法在连接有少量未完成数据时提供更快的丢失恢复。修改后的RTO重启（RTO Restart，RTO）允许传输使用较小的超时持续时间重新启动其重传计时器，以便在无法使用快速重传的情况下，有效重传超时（RTO）变得更具攻击性。这使短寿命或应用程序受限的连接能够更快地进行丢失检测和恢复。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF 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.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7765.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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
TCP and SCTP use two almost identical mechanisms to detect and recover from data loss, specified in [RFC6298] and [RFC5681] for TCP and [RFC4960] for SCTP. First, if transmitted data is not acknowledged within a certain amount of time, a retransmission timeout (RTO) occurs and the data is retransmitted. While the RTO is based on measured round-trip times (RTTs) between the sender and receiver, it also has a conservative lower bound of 1 second to ensure that delayed data are not mistaken as lost. Second, when a sender receives duplicate acknowledgments or similar information via selective acknowledgments, the fast retransmit algorithm suspects data loss and can trigger a retransmission. Duplicate (and selective) acknowledgments are generated by a receiver when data arrives out of order. As both data loss and data reordering cause out-of-order arrival, fast retransmit waits for three out-of-order notifications before considering the corresponding data as lost. In some situations, however, the amount of outstanding data is not enough to trigger three such acknowledgments, and the sender must rely on lengthy RTOs for loss recovery.
TCP和SCTP使用两种几乎相同的机制来检测和恢复数据丢失，分别在[RFC6298]和[RFC5681]中指定用于TCP和[RFC4960]中指定用于SCTP。首先，如果在一定时间内未确认传输的数据，则发生重传超时（RTO）并重传数据。虽然RTO基于发送方和接收方之间测量的往返时间（RTT），但它也有一个1秒的保守下限，以确保延迟数据不会被误认为丢失。其次，当发送方通过选择性确认接收到重复确认或类似信息时，快速重传算法怀疑数据丢失，并可能触发重传。当数据无序到达时，接收器生成重复（和选择性）确认。由于数据丢失和数据重新排序都会导致无序到达，因此快速重新传输会等待三个无序通知，然后再将相应的数据视为丢失。但是，在某些情况下，未完成的数据量不足以触发三次此类确认，发送方必须依靠冗长的RTO进行损失恢复。
The amount of outstanding data can be small for several reasons:
由于以下几个原因，未完成的数据量可能很小：
(1) The connection is limited by congestion control when the path has a low total capacity (bandwidth-delay product) or the connection's share of the capacity is small. It is also limited by congestion control in the first few RTTs of a connection or after an RTO when the available capacity is probed using slow-start.
(1) 当路径的总容量（带宽延迟积）较低或连接的容量份额较小时，连接会受到拥塞控制的限制。它还受到连接的前几个RTT中的拥塞控制的限制，或者在使用慢启动探测可用容量时RTO之后的拥塞控制的限制。
(2) The connection is limited by the receiver's available buffer space.
(2) 连接受到接收器可用缓冲区空间的限制。
(3) The connection is limited by the application if the available capacity of the path is not fully utilized (e.g., interactive applications) or is at the end of a transfer.
(3) 如果路径的可用容量未充分利用（例如，交互式应用程序）或处于传输结束时，则连接受到应用程序的限制。
While the reasons listed above are valid for any flow, the third reason is most common for applications that transmit short flows or use a bursty transmission pattern. A typical example of applications that produce short flows are web-based applications. [RJ10] shows 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 all retransmissions sent by a major web service are sent after RTO expiry. Applications with bursty transmission patterns often send data in response to actions or as a reaction to real life events. Typical examples of such applications are stock-trading systems, remote computer operations, online games, and web-based applications
虽然上面列出的原因对任何流都有效，但第三个原因对于传输短流或使用突发传输模式的应用程序最为常见。产生短流的典型应用程序示例是基于web的应用程序。[RJ10]显示，排名前500位的所有web对象中有70%太小，无法进行快速重新传输。[FDT13]显示，主要web服务发送的所有重传中，约77%是在RTO到期后发送的。具有突发传输模式的应用程序通常发送数据以响应操作或作为对实际事件的反应。此类应用程序的典型示例是股票交易系统、远程计算机操作、在线游戏和基于web的应用程序
using persistent connections. What is special about this class of applications is that they are often time dependent, and extra latency can reduce the application service level [P09].
使用持久连接。这类应用程序的特殊之处在于它们通常依赖于时间，额外的延迟可以降低应用程序服务级别[P09]。
The RTO Restart (RTOR) mechanism described in this document makes the effective RTO slightly more aggressive when the amount of outstanding data is too small for fast retransmit to work, in an attempt to enable faster loss recovery while being robust to reordering. While RTOR still conforms to the requirement for when a segment can be retransmitted, specified in [RFC6298] for TCP and [RFC4960] for SCTP, it could increase the risk of spurious timeouts. To determine whether this modification is safe to deploy and enable by default, further experimentation is required. Section 5 discusses experiments still needed, including evaluations in environments where the risk of spurious retransmissions are increased, e.g., mobile networks with highly varying RTTs.
本文档中描述的RTO重启（RTO）机制使有效的RTO在未完成数据量太小而无法进行快速重新传输时更具攻击性，以实现更快的丢失恢复，同时对重新排序更具鲁棒性。虽然RTOR仍然符合[RFC6298]中针对TCP和[RFC4960]中针对SCTP规定的段何时可以重新传输的要求，但它可能会增加虚假超时的风险。要确定默认情况下部署和启用此修改是否安全，需要进行进一步的实验。第5节讨论了仍然需要的实验，包括在伪重传风险增加的环境中进行的评估，例如，具有高度变化RTT的移动网络。
The remainder of this document describes RTOR and its implementation for TCP only, to make the document easier to read. However, the RTOR algorithm described in Section 4 is applicable also for SCTP. Furthermore, Section 7 details the SCTP socket API needed to control RTOR.
本文档的其余部分仅描述RTOR及其TCP实现，以使文档更易于阅读。然而，第4节中描述的RTOR算法也适用于SCTP。此外，第7节详细介绍了控制RTOR所需的SCTP套接字API。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document introduces the following variables:
本文件介绍了以下变量：
o The number of previously unsent segments (prevunsnt): The number of segments that a sender has queued for transmission, but has not yet sent.
o 先前未发送的段数（prevunsnt）：发送方已排队等待传输但尚未发送的段数。
o RTO Restart threshold (rrthresh): RTOR is enabled whenever the sum of the number of outstanding and previously unsent segments (prevunsnt) is below this threshold.
o RTO重新启动阈值（rrthresh）：只要未完成和以前未发送的段（prevunsnt）的总数低于此阈值，RTO就会启用。
The RTO management algorithm described in [RFC6298] recommends that the retransmission timer be restarted when an acknowledgment (ACK) that acknowledges new data is received and there is still outstanding data. The restart is conducted to guarantee that unacknowledged segments will be retransmitted after approximately RTO seconds. The standardized RTO timer management is illustrated in Figure 1, where a TCP sender transmits three segments to a receiver. The arrival of
[RFC6298]中描述的RTO管理算法建议在接收到确认新数据的确认（ACK）且仍有未完成数据时重新启动重传计时器。重新启动是为了确保未确认的数据段将在大约RTO秒后重新传输。标准化的RTO定时器管理如图1所示，其中TCP发送方向接收方发送三个段。的到来
the first and second segment triggers a delayed ACK (delACK) [RFC1122], which restarts the RTO timer at the sender. The RTO is restarted approximately one RTT after the transmission of the third segment. Thus, if the third segment is lost, as indicated in Figure 1, the effective loss detection time becomes "RTO + RTT" seconds. In some situations, the effective loss detection time becomes even longer. Consider a scenario where only two segments are outstanding. If the second segment is lost, the time to expire the delACK timer will also be included in the effective loss detection time.
第一和第二段触发延迟ACK（delACK）[RFC1122]，该延迟ACK重新启动发送方的RTO定时器。RTO在传输第三段后大约一个RTT重新启动。因此，如果第三段丢失，如图1所示，有效丢失检测时间变为“RTO+RTT”秒。在某些情况下，有效损失检测时间甚至更长。考虑一个只有两个片段突出的场景。如果第二段丢失，delACK计时器过期的时间也将包含在有效丢失检测时间中。
Sender Receiver
...
DATA [SEG 1] ----------------------> (ack delayed)
DATA [SEG 2] ----------------------> (send ack)
DATA [SEG 3] ----X /-------- ACK
(restart RTO) <----------/
...
(RTO expiry)
DATA [SEG 3] ---------------------->
Sender Receiver
...
DATA [SEG 1] ----------------------> (ack delayed)
DATA [SEG 2] ----------------------> (send ack)
DATA [SEG 3] ----X /-------- ACK
(restart RTO) <----------/
...
(RTO expiry)
DATA [SEG 3] ---------------------->
Figure 1: RTO Restart Example
图1:RTO重启示例
For bulk traffic, the current approach is beneficial -- it is described in [EL04] to act as a "safety margin" that compensates for some of the problems that the authors have identified with the standard RTO calculation. Notably, the authors of [EL04] also state that "this safety margin does not exist for highly interactive applications where often only a single packet is in flight." In general, however, as long as enough segments arrive at a receiver to enable fast retransmit, RTO-based loss recovery should be avoided. RTOs should only be used as a last resort, as they drastically lower the congestion window as compared to fast retransmit.
对于批量流量，当前的方法是有益的——在[EL04]中描述了作为“安全裕度”，补偿作者通过标准RTO计算确定的一些问题。值得注意的是，[EL04]的作者还指出，“对于通常只有一个数据包在传输中的高度交互应用程序，不存在此安全裕度。”然而，一般来说，只要有足够的数据段到达接收器以实现快速重传，就应避免基于RTO的丢失恢复。RTO只能作为最后手段使用，因为与快速重传相比，RTO大大降低了拥塞窗口。
Although fast retransmit is preferable, there are situations where timeouts are appropriate or are the only choice. For example, if the network is severely congested and no segments arrive, RTO-based recovery should be used. In this situation, the time to recover from the loss(es) will not be the performance bottleneck. However, for connections that do not utilize enough capacity to enable fast retransmit, RTO-based loss detection is the only choice, and the time required for this can become a performance bottleneck.
尽管快速重传更可取，但在某些情况下，超时是适当的或是唯一的选择。例如，如果网络严重拥塞且没有网段到达，则应使用基于RTO的恢复。在这种情况下，从损失中恢复的时间不会成为性能瓶颈。但是，对于没有利用足够容量来实现快速重传的连接，基于RTO的丢失检测是唯一的选择，而这所需的时间可能会成为性能瓶颈。
To enable faster loss recovery for connections that are unable to use fast retransmit, RTOR can be used. This section specifies the modifications required to use RTOR. By resetting the timer to "RTO - T_earliest", where T_earliest is the time elapsed since the earliest outstanding segment was transmitted, retransmissions will always occur after exactly RTO seconds.
为了使无法使用快速重传的连接能够更快地恢复丢失，可以使用RTOR。本节规定了使用RTOR所需的修改。通过将计时器重置为“RTO-T_earliest”，其中T_earliest是自传输最早未完成段以来经过的时间，重传将始终在RTO秒之后发生。
This document specifies an OPTIONAL sender-only modification to TCP 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 that implements this method MUST follow the algorithm below:
本文件规定了对TCP和SCTP的可选仅发送方修改，该修改更新了[RFC6298]第5节中的步骤5.3]（以及[RFC4960]第6.3.2节中针对SCTP的类似更新）。实现此方法的发件人必须遵循以下算法：
When an ACK is received that acknowledges new data:
当接收到确认新数据的ACK时：
(1) Set T_earliest = 0.
(1) 设置T_=0。
(2) If the sum of the number of outstanding and previously unsent segments (prevunsnt) is less than an RTOR threshold (rrthresh), set T_earliest to the time elapsed since the earliest outstanding segment was sent.
(2) 如果未发送段和以前未发送段的总数（prevunsnt）小于RTOR阈值（rrthresh），则将T_Earlime设置为自发送最早未发送段以来经过的时间。
(3) Restart the retransmission timer so that it will expire after (for the current value of RTO):
(3) 重新启动重传计时器，使其在以下时间后过期（对于RTO的当前值）：
(a) RTO - T_earliest, if RTO - T_earliest > 0.
(a) RTO-T_最早，如果RTO-T_最早>0。
(b) RTO, otherwise.
(b) RTO，否则。
The RECOMMENDED value of rrthresh is four, as this value will ensure that RTOR is only used when fast retransmit cannot be triggered. With this update, TCP implementations MUST track the time elapsed since the transmission of the earliest outstanding segment (T_earliest). As RTOR is only used when the amount of outstanding and previously unsent data is less than rrthresh segments, TCP implementations also need to track whether the amount of outstanding and previously unsent data is more, equal, or less than rrthresh segments. Although some packet-based TCP implementations (e.g., Linux TCP) already track both the transmission times of all segments and also the number of outstanding segments, not all implementations do. Section 5.3 describes how to implement segment tracking for a general TCP implementation. To use RTOR, the calculated expiration time MUST be positive (step 3(a) in the list above); this is required to ensure that RTOR does not trigger retransmissions prematurely when previously retransmitted segments are acknowledged.
建议的rrthresh值为4，因为该值将确保RTOR仅在无法触发快速重传时使用。通过此更新，TCP实现必须跟踪自传输最早未完成段（T_Earlime）以来经过的时间。由于RTOR仅在未发送和以前未发送的数据量小于rrthresh段时使用，TCP实现还需要跟踪未发送和以前未发送的数据量是大于、等于还是小于rrthresh段。尽管一些基于数据包的TCP实现（例如Linux TCP）已经跟踪了所有段的传输时间和未完成段的数量，但并非所有实现都跟踪。第5.3节描述了如何为通用TCP实现实现段跟踪。要使用RTOR，计算的到期时间必须为正（上面列表中的步骤3（a））；这是为了确保RTOR不会在确认先前重新传输的段时过早触发重新传输。
Although RTOR conforms to the requirement in [RFC6298] that segments must not be retransmitted earlier than RTO seconds after their original transmission, RTOR makes the effective RTO more aggressive. In this section, we discuss the applicability and the issues related to RTOR.
尽管RTOR符合[RFC6298]中的要求，即段在原始传输后的RTO秒之前不得重新传输，但RTOR使有效RTO更具攻击性。在本节中，我们将讨论RTOR的适用性和相关问题。
The currently standardized algorithm has been shown to add at least one RTT to the loss recovery process in TCP [LS00] and SCTP [HB11] [PBP09]. For applications that have strict timing requirements (e.g., interactive web) rather than throughput requirements, using RTOR could be beneficial because the RTT and the delACK timer of receivers are often large components of the effective loss recovery time. Measurements in [HB11] have shown that the total transfer time of a lost segment (including the original transmission time and the loss recovery time) can be reduced by 35% using RTOR. These results match those presented in [PGH06] and [PBP09], where RTOR is shown to significantly reduce retransmission latency.
目前标准化的算法已被证明在TCP[LS00]和SCTP[HB11][PBP09]中的丢失恢复过程中添加了至少一个RTT。对于具有严格定时要求（例如，交互式web）而非吞吐量要求的应用程序，使用RTOR可能是有益的，因为接收机的RTT和delACK定时器通常是有效损失恢复时间的重要组成部分。[HB11]中的测量表明，使用RTOR可以将丢失段的总传输时间（包括原始传输时间和丢失恢复时间）减少35%。这些结果与[PGH06]和[PBP09]中给出的结果一致，其中RTOR被证明能显著降低重传延迟。
There are also traffic types that do not benefit from RTOR. One example of such traffic is bulk transmission. The reason why bulk traffic does not benefit from RTOR is that such traffic flows mostly have four or more segments outstanding, allowing loss recovery by fast retransmit. However, there is no harm in using RTOR for such traffic as the algorithm is only active when the amount of outstanding and unsent segments are less than rrthresh (default 4).
还有一些流量类型不能从RTOR中获益。这种业务的一个例子是批量传输。批量流量不能从RTOR中受益的原因是，此类流量流大多有四个或更多未完成的段，允许通过快速重传恢复丢失。但是，对此类流量使用RTOR没有任何危害，因为该算法仅在未发送和未发送段的数量小于rrthresh（默认值4）时才处于活动状态。
Given that RTOR is a mostly conservative algorithm, it is suitable for experimentation as a system-wide default for TCP traffic.
鉴于RTOR是一种保守的算法，它适合作为TCP流量的系统范围默认算法进行实验。
RTOR can in some situations reduce the loss detection time and thereby increase the risk of spurious timeouts. In theory, the retransmission timer has a lower bound of 1 second [RFC6298], which limits the risk of having spurious timeouts. However, in practice, most implementations use a significantly lower value. Initial measurements show slight increases in the number of spurious timeouts when such lower values are used [RHB15]. However, further experiments, in different environments and with different types of traffic, are encouraged to quantify such increases more reliably.
在某些情况下，RTOR可以减少丢失检测时间，从而增加虚假超时的风险。理论上，重传计时器的下限为1秒[RFC6298]，这限制了出现虚假超时的风险。然而，在实践中，大多数实现使用的值要低得多。初始测量表明，当使用较低的值时，假超时的数量略有增加[RHB15]。然而，鼓励在不同环境和不同类型的交通中进行进一步试验，以更可靠地量化此类增长。
Does a slightly increased risk matter? Generally, spurious timeouts have a negative effect on the network as segments are transmitted needlessly. However, recent experiments do not show a significant
稍微增加的风险重要吗？通常，由于段被不必要地传输，虚假超时对网络有负面影响。然而，最近的实验并没有显示出显著的效果
increase in network load for a number of realistic scenarios [RHB15]. Another problem with spurious retransmissions is related to the performance of TCP/SCTP, as the congestion window is reduced to one segment when timeouts occur [RFC5681]. This could be a potential problem for applications transmitting multiple bursts of data within a single flow, e.g., web-based HTTP/1.1 and HTTP/2.0 applications. However, results from recent experiments involving persistent web traffic [RHB15] revealed a net gain using RTOR. Other types 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.
许多现实场景下的网络负载增加[RHB15]。伪重传的另一个问题与TCP/SCTP的性能有关，因为当超时发生时，拥塞窗口减少为一个段[RFC5681]。对于在单个流中传输多个突发数据的应用程序（例如，基于web的HTTP/1.1和HTTP/2.0应用程序），这可能是一个潜在问题。然而，最近涉及持久web流量[RHB15]的实验结果显示，使用RTOR可以获得净收益。其他类型的流（例如，长寿命批量流）不受影响，因为该算法仅在未完成和未发送段的数量小于rrthresh时应用。此外，短命和应用程序受限的流量通常不会受到影响，因为它们太短，无法体验拥塞控制的效果，或者传输速率很快就能达到。
While a slight increase in spurious timeouts has been observed using RTOR, it is not clear whether or not the effects of this increase mandate any future algorithmic changes -- especially since most modern operating systems already include mechanisms to detect [RFC3522] [RFC3708] [RFC5682] and resolve [RFC4015] possible problems with spurious retransmissions. Further experimentation is needed to determine this and thereby move this specification from Experimental to the Standards Track. 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.
虽然使用RTOR观察到虚假超时的轻微增加，但不清楚这种增加的影响是否要求未来进行任何算法更改——特别是因为大多数现代操作系统已经包括检测[RFC3522][RFC3708][RFC5682]和解析[RFC4015]的机制可能存在错误的重新传输问题。需要进一步的实验来确定这一点，从而将本规范从实验性转移到标准轨道。例如，尚未在移动网络环境中评估RTOR。由于例如切换，移动网络通常会产生高度可变的RTT（延迟峰值），因此对于进一步的实验来说是一个有用的场景。
The method of tracking outstanding and previously unsent segments will probably differ depending on the actual TCP implementation. For packet-based TCP implementations, tracking outstanding segments is 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 [RFC5827] outlines a general method of tracking the number of outstanding segments. The same method can be used for RTOR. The implementation will have to track segment boundaries to form an understanding as to how many actual segments have been transmitted but not acknowledged. This can be done by the sender tracking the boundaries of the rrthresh segments on the right side of the current 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
跟踪未发送段和以前未发送段的方法可能会因实际TCP实现的不同而有所不同。对于基于数据包的TCP实现，跟踪未完成的段通常很简单，可以使用简单的计数器来实现。对于基于字节的TCP堆栈，这是一项更复杂的任务。[RFC5827]第3.2节概述了跟踪未完成分段数量的一般方法。RTOR也可以使用相同的方法。实施必须跟踪段边界，以了解有多少实际段已传输但未确认。这可以通过发送方跟踪当前窗口右侧的rrthresh段的边界来完成（这涉及跟踪TCP中的rrthresh+1序列号）。例如，这可以通过保持一个线段边界的循环列表来实现。不在此区域内的累积ACK表明至少rrthresh段未完成，因此未启用RTOR。当未完成窗口变得足够小以至于可以调用RTOR时，可以从保留的rrthresh+1序列号获得对未完成段数量的全面了解。（注：隐式序列
number consumed by the TCP FIN bit can also be included in the tracking of segment boundaries.)
TCP FIN位消耗的数量也可以包含在段边界的跟踪中。）
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 where 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 resegmented) as long as it is still unsent, a straightforward strategy could be to divide the amount of unsent data (in bytes) with the Sender Maximum Segment Size (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. The tracking of prevunsnt is only made to optimize a corner case in which RTOR was unnecessarily disabled. Implementations can use a simplified method by setting prevunsnt to rrthresh whenever previously unsent data is available, and set prevunsnt to zero when no new data is available. This will disable RTOR in the presence of unsent data and only use the number of outstanding segments to enable/disable RTOR.
跟踪以前未发送的段数取决于TCP实现使用的分段策略，而不是基于数据包还是基于字节。在直接在套接字写入上形成段的情况下，确定以前未发送的段的数量的过程应该很简单。在未发送的数据可以被分割（或重新分割）的情况下，只要它仍然是未发送的，一个简单的策略就是将未发送的数据量（以字节为单位）除以发送方的最大段大小（SMS）以获得估计值。在某些情况下，这种估计可能过于简单，具体取决于TCP实现的分段策略。然而，这种估计对RTOR并不重要。对prevunsnt的跟踪仅用于优化RTOR被不必要地禁用的拐角情况。实现可以使用一种简化的方法，只要以前未发送的数据可用，就将prevunsnt设置为rrthresh，如果没有新数据可用，就将prevunsnt设置为零。这将在存在未发送数据的情况下禁用RTOR，并且仅使用未发送段的数量来启用/禁用RTOR。
There are several proposals that address the problem of not having enough ACKs for loss recovery. In what follows, we explain why the mechanism described here is complementary to these approaches:
有几个建议可以解决没有足够的ACK进行损失恢复的问题。在下文中，我们将解释为什么这里描述的机制是对这些方法的补充：
The limited transmit mechanism [RFC3042] allows a TCP sender to transmit a previously unsent segment for each of the first two duplicate acknowledgements (dupACKs). By transmitting new segments, the sender attempts to generate additional dupACKs to enable fast retransmit. However, limited transmit does not help if no previously unsent data is ready for transmission. [RFC5827] specifies an early retransmit algorithm to enable fast loss recovery in such situations. By dynamically lowering the number of dupACKs needed for fast retransmit (dupthresh), based on the number of outstanding segments, a smaller number of dupACKs is needed to trigger a retransmission. In some situations, however, the algorithm is of no use or might not work properly. First, if a single segment is outstanding and lost, it is impossible to use early retransmit. Second, if ACKs are lost, early retransmit cannot help. Third, if the network path reorders segments, the algorithm might cause more spurious retransmissions than fast retransmit. The recommended value of RTOR's rrthresh variable is based on the dupthresh, but it is possible to adapt to allow tighter integration with other experimental algorithms such as early retransmit.
受限传输机制[RFC3042]允许TCP发送方为前两个重复确认（dupACKs）中的每一个发送先前未发送的段。通过传输新段，发送方尝试生成额外的dupack以实现快速重传。但是，如果以前未发送的数据未准备好传输，则限制传输没有帮助。[RFC5827]指定一种早期重传算法，以在这种情况下实现快速丢失恢复。通过基于未完成段的数量动态降低快速重传（dupthresh）所需的dupack数量，触发重传所需的dupack数量更少。但是，在某些情况下，该算法没有用处，或者可能无法正常工作。首先，如果单个段未完成且丢失，则不可能使用早期重传。第二，如果ACK丢失，那么早期重新传输也无济于事。第三，如果网络路径对段进行重新排序，该算法可能会导致比快速重传更多的伪重传。RTOR的rrthresh变量的建议值基于DUPThrresh，但可以进行调整，以便与其他实验算法（如早期重传）进行更紧密的集成。
Tail Loss Probe [TLP] is a proposal to send up to two "probe 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, else it is a retransmission. The intention is to compensate for sluggish RTO behavior in situations where the RTO greatly exceeds the RTT, which, according to measurements reported in [TLP], is not uncommon. Furthermore, TLP also tries to circumvent the congestion window reset to one segment by instead enabling fast recovery. The probe timeout (PTO) is normally two RTTs, and a spurious PTO is less risky than a spurious RTO because it would not have the same negative effects (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 further reduce loss recovery times. However, it also noticeably increases the amount of spurious retransmissions, as compared to RTOR [RHB15].
Tail Loss Probe[TLP]是一个建议，当定时器触发时，发送最多两个“探测段”，该定时器的值设置为小于RTO。如果有新数据可用，“探测段”是新段，否则是重传。其目的是在RTO大大超过RTT的情况下补偿缓慢的RTO行为，根据[TLP]中报告的测量，这种情况并不少见。此外，TLP还试图通过启用快速恢复来避免拥塞窗口重置为一个段。探测超时（PTO）通常为两个RTT，伪PTO的风险低于伪RTO，因为它不会产生相同的负面影响（清除记分牌并以慢速启动重新启动）。TLP是一种比RTOR更先进的机制，例如需要SACK才能工作，并且通常能够进一步减少损失恢复时间。然而，与RTOR[RHB15]相比，它还显著增加了伪重传的数量。
TLP is applicable in situations where RTOR does not apply, and it could overrule (yielding a similar general behavior, but with a lower timeout) RTOR in cases where the number of outstanding segments is smaller than four and no new segments are available for transmission. 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 to offer more consistent timeouts.
TLP适用于RTOR不适用的情况，如果未完成的段数小于4个且没有新的段可供传输，TLP可以否决RTOR（产生类似的一般行为，但超时时间较短）。PTO具有相同的固有问题，即在传入ACK时重新启动计时器，并且可以与类似于RTOR的策略相结合，以提供更一致的超时。
This section describes how the socket API for SCTP defined in [RFC6458] is extended to control the usage of RTO restart for SCTP.
本节介绍如何扩展[RFC6458]中定义的SCTP套接字API，以控制SCTP的RTO重启的使用。
Please note that this section is informational only.
请注意，本节仅供参考。
This section uses data types from [IEEE.9945]: uintN_t means an unsigned integer of exactly N bits (e.g., uint16_t). This is the same as in [RFC6458].
本节使用[IEEE.9945]中的数据类型：uintN_t表示正好N位的无符号整数（例如uint16_t）。这与[RFC6458]中的相同。
7.2. Socket Option for Controlling the RTO Restart Support (SCTP_RTO_RESTART)
7.2. 用于控制RTO重启支持的套接字选项（SCTP\U RTO\U重启）
This socket option allows the enabling or disabling of RTO Restart for SCTP associations.
此套接字选项允许启用或禁用SCTP关联的RTO重启。
Whether or not RTO restart is enabled per default is implementation specific.
是否根据默认值启用RTO重启取决于具体的实现。
This socket option uses IPPROTO_SCTP as its level and SCTP_RTO_RESTART as its name. It can be used with getsockopt() and setsockopt(). The socket option value uses the following structure defined in [RFC6458]:
此套接字选项使用IPPROTO_SCTP作为其级别，SCTP_RTO_RESTART作为其名称。它可以与getsockopt（）和setsockopt（）一起使用。套接字选项值使用[RFC6458]中定义的以下结构：
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, this parameter indicates upon which association the user is performing an action. The special sctp_assoc_t SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used in assoc_id for setsockopt(). For getsockopt(), the special value SCTP_FUTURE_ASSOC can be used in assoc_id, but it is an error to use SCTP_{CURRENT|ALL}_ASSOC in assoc_id.
assoc_id：对于一对一样式的套接字，此参数被忽略。对于一对多样式套接字，此参数指示用户执行操作的关联。特殊的sctp_assoc_t sctp_{FUTURE | CURRENT | ALL}_assoc也可以在setsockopt（）的assoc_id中使用。对于getsockopt（），特殊值SCTP_FUTURE_ASSOC可以在ASSOC_id中使用，但在ASSOC_id中使用SCTP_{CURRENT | ALL}_ASSOC是错误的。
assoc_value: A non-zero value encodes the enabling of RTO restart whereas a value of 0 encodes the disabling of RTO restart.
assoc_值：非零值编码RTO重启的启用，而0值编码RTO重启的禁用。
sctp_opt_info() needs to be extended to support SCTP_RTO_RESTART.
需要扩展sctp_opt_info（），以支持sctp_RTO_重启。
This document specifies an experimental sender-only modification to TCP and SCTP. The modification introduces a change in how to set the retransmission timer's value when restarted. Therefore, the security considerations found in [RFC6298] apply to this document. No additional security problems have been identified with RTO Restart at this time.
本文档指定了对TCP和SCTP的实验性仅发送方修改。修改引入了重新启动时如何设置重传计时器值的更改。因此，[RFC6298]中的安全注意事项适用于本文件。目前还没有发现RTO重启的其他安全问题。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，DOI 10.17487/RFC1122，1989年10月<http://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, DOI 10.17487/RFC3042, January 2001, <http://www.rfc-editor.org/info/rfc3042>.
[RFC3042]Allman，M.，Balakrishnan，H.，和S.Floyd，“使用有限传输增强TCP的丢失恢复”，RFC 3042，DOI 10.17487/RFC3042，2001年1月<http://www.rfc-editor.org/info/rfc3042>.
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, DOI 10.17487/RFC3522, April 2003, <http://www.rfc-editor.org/info/rfc3522>.
[RFC3522]Ludwig，R.和M.Meyer，“TCP的Eifel检测算法”，RFC 3522，DOI 10.17487/RFC3522，2003年4月<http://www.rfc-editor.org/info/rfc3522>.
[RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions", RFC 3708, DOI 10.17487/RFC3708, February 2004, <http://www.rfc-editor.org/info/rfc3708>.
[RFC3708]Blanton，E.和M.Allman，“使用TCP重复选择确认（DSACKs）和流控制传输协议（SCTP）重复传输序列号（TSN）来检测虚假重传”，RFC 3708，DOI 10.17487/RFC3708，2004年2月<http://www.rfc-editor.org/info/rfc3708>.
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", RFC 4015, DOI 10.17487/RFC4015, February 2005, <http://www.rfc-editor.org/info/rfc4015>.
[RFC4015]Ludwig，R.和A.Gurtov，“TCP的Eifel响应算法”，RFC 4015，DOI 10.17487/RFC4015，2005年2月<http://www.rfc-editor.org/info/rfc4015>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 4960，DOI 10.17487/RFC4960，2007年9月<http://www.rfc-editor.org/info/rfc4960>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 5681，DOI 10.17487/RFC56812009年9月<http://www.rfc-editor.org/info/rfc5681>.
[RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP", RFC 5682, DOI 10.17487/RFC5682, September 2009, <http://www.rfc-editor.org/info/rfc5682>.
[RFC5682]Sarolahti，P.，Kojo，M.，Yamamoto，K.，和M.Hata，“前向RTO恢复（F-RTO）：使用TCP检测虚假重传超时的算法”，RFC 5682，DOI 10.17487/RFC5682，2009年9月<http://www.rfc-editor.org/info/rfc5682>.
[RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and P. Hurtig, "Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)", RFC 5827, DOI 10.17487/RFC5827, May 2010, <http://www.rfc-editor.org/info/rfc5827>.
[RFC5827]Allman，M.，Avrachenkov，K.，Ayesta，U.，Blanton，J.，和P.Hurtig，“TCP和流控制传输协议（SCTP）的早期重传”，RFC 5827，DOI 10.17487/RFC5827，2010年5月<http://www.rfc-editor.org/info/rfc5827>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <http://www.rfc-editor.org/info/rfc6298>.
[RFC6298]Paxson，V.，Allman，M.，Chu，J.，和M.Sargent，“计算TCP的重传计时器”，RFC 6298，DOI 10.17487/RFC62982011年6月<http://www.rfc-editor.org/info/rfc6298>.
[EL04] Ekstroem, H. and R. Ludwig, "The Peak-Hopper: A New End-to-End Retransmission Timer for Reliable Unicast Transport", IEEE INFOCOM 2004, DOI 10.1109/INFCOM.2004.1354671, March 2004.
[EL04]Ekstroem，H.和R.Ludwig，“峰值漏斗：用于可靠单播传输的新端到端重传计时器”，IEEE INFOCOM 2004，DOI 10.1109/INFCOM.2004.13546712004年3月。
[FDT13] Flach, T., Dukkipati, N., Terzis, A., Raghavan, B., Cardwell, N., Cheng, Y., Jain, A., Hao, S., Katz-Bassett, E., and R. Govindan, "Reducing Web Latency: the Virtue of Gentle Aggression", Proc. ACM SIGCOMM Conf., DOI 10.1145/2486001.2486014, August 2013.
[FDT13]Flach，T.，Dukkipati，N.，Terzis，A.，Raghavan，B.，Cardwell，N.，Cheng，Y.，Jain，A.，Hao，S.，Katz Bassett，E.，和R.Govindan，“减少网络延迟：温和攻击的美德”，Proc。ACM SIGCOMM Conf.，DOI 10.1145/248601.2486014，2013年8月。
[HB11] Hurtig, P. and A. Brunstrom, "SCTP: designed for timely message delivery?", Springer Telecommunication Systems 47 (3-4), DOI 10.1007/s11235-010-9321-3, August 2011.
[HB11]Hurtig，P.和A.Brunstrom，“SCTP：为及时传递信息而设计？”，Springer Telecommunication Systems 47（3-4），DOI 10.1007/s11235-010-9321-3，2011年8月。
[IEEE.9945] IEEE/ISO/IEC, "International Standard - Information technology Portable Operating System Interface (POSIX) Base Specifications, Issue 7", IEEE 9945-2009, <http://standards.ieee.org/findstds/ standard/9945-2009.html>.
[IEEE.9945]IEEE/ISO/IEC，“国际标准-信息技术便携式操作系统接口（POSIX）基本规范，第7期”，IEEE 9945-2009<http://standards.ieee.org/findstds/ 标准/9945-2009.html>。
[LS00] Ludwig, R. and K. Sklower, "The Eifel retransmission timer", ACM SIGCOMM Comput. Commun. Rev., 30(3), DOI 10.1145/382179.383014, July 2000.
[LS00]Ludwig，R.和K.Sklower，“Eifel重传计时器”，ACM SIGCOMM计算机。公社。第30（3）号修订本，内政部10.1145/382179.383014，2000年7月。
[P09] Petlund, A., "Improving latency for interactive, thin-stream applications over reliable transport", Unipub PhD Thesis, Oct 2009.
[P09]Petlund，A.“通过可靠传输改善交互式瘦流应用程序的延迟”，Unipub博士论文，2009年10月。
[PBP09] Petlund, A., Beskow, P., Pedersen, J., Paaby, E., Griwodz, C., and P. Halvorsen, "Improving SCTP retransmission delays for time-dependent thin streams", Springer Multimedia Tools and Applications, 45(1-3), DOI 10.1007/s11042-009-0286-8, October 2009.
[PBP09]Petlund，A.，Beskow，P.，Pedersen，J.，Paaby，E.，Griwodz，C.，和P.Halvorsen，“改善依赖时间的细流的SCTP重传延迟”，Springer多媒体工具和应用，45（1-3），DOI 10.1007/s11042-009-0286-8，2009年10月。
[PGH06] Pedersen, J., Griwodz, C., and P. Halvorsen, "Considerations of SCTP Retransmission Delays for Thin Streams", IEEE LCN 2006, DOI 10.1109/LCN.2006.322082, November 2006.
[PGH06]Pedersen，J.，Griwodz，C.，和P.Halvorsen，“细流SCTP重传延迟的考虑”，IEEE LCN 2006，DOI 10.1109/LCN.2006.322082，2006年11月。
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/RFC6458, December 2011, <http://www.rfc-editor.org/info/rfc6458>.
[RFC6458]Stewart，R.，Tuexen，M.，Poon，K.，Lei，P.，和V.Yasevich，“流控制传输协议（SCTP）的套接字API扩展”，RFC 6458，DOI 10.17487/RFC6458，2011年12月<http://www.rfc-editor.org/info/rfc6458>.
[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), DOI 10.1145/2717646.2717648, January 2015.
[RHB15]Rajiullah，M.，Hurtig，P.，Brunstrom，A.，Petlund，A.，和M.Welzl，“TCP尾部损失恢复机制的评估”，ACM SIGCOMM CCR 45（1），DOI 10.1145/2717646.2717648，2015年1月。
[RJ10] Ramachandran, S., "Web metrics: Size and number of resources", May 2010, <https://goo.gl/0a6Q9A>.
[RJ10]Ramachandran，S.，“网络指标：资源的大小和数量”，2010年5月<https://goo.gl/0a6Q9A>.
[TLP] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses", Work in Progress, draft-dukkipati-tcpm-tcp-loss-probe-01, February 2013.
[TLP]Dukkipati，N.，Cardwell，N.，Cheng，Y.，和M.Mathis，“尾部损失探测（TLP）：快速恢复尾部损失的算法”，正在进行的工作，草稿-Dukkipati-tcpm-tcp-Loss-Probe-012013年2月。
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.
作者希望感谢Michael Tuexen对SCTP Socket API考虑做出的贡献，以及Godred Fairhurst、Yuchong Cheng、Mark Allman、Anantha Ramaih、Richard Scheffenegger、Nicolas Kuhn、Alexander Zimmermann和Michael Scharf对文档及其背后思想的评论。
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.
所有作者都得到了RITE的支持(http://riteproject.eu/)，这是一个研究项目（ICT-317700），由欧洲共同体根据其第七个框架计划资助。此处表达的观点仅为作者的观点。欧盟委员会对可能使用本文件中的信息不承担任何责任。
Authors' Addresses
作者地址
Per Hurtig Karlstad University Universitetsgatan 2 Karlstad 651 88 Sweden
Per Hurtig Karlstad大学加坦2 Karlstad 651 88瑞典
Phone: +46 54 700 23 35
Email: per.hurtig@kau.se
Phone: +46 54 700 23 35
Email: per.hurtig@kau.se
Anna Brunstrom Karlstad University Universitetsgatan 2 Karlstad 651 88 Sweden
安娜·布伦斯特罗姆·卡尔斯塔德大学加坦2卡尔斯塔德65188瑞典
Phone: +46 54 700 17 95
Email: anna.brunstrom@kau.se
Phone: +46 54 700 17 95
Email: anna.brunstrom@kau.se
Andreas Petlund Simula Research Laboratory AS P.O. Box 134 Lysaker 1325 Norway
Andreas Petlund Simula研究实验室，邮政信箱134，挪威Lysaker 1325
Phone: +47 67 82 82 00
Email: apetlund@simula.no
Phone: +47 67 82 82 00
Email: apetlund@simula.no
Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway
米迦勒WelZl奥斯陆大学邮政信箱1080盲人奥斯陆N-0316挪威
Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no
Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no