Internet Engineering Task Force (IETF) E. Blanton
Request for Comments: 6675 Purdue University
Obsoletes: 3517 M. Allman
Category: Standards Track ICSI
ISSN: 2070-1721 L. Wang
Juniper Networks
I. Jarvinen
M. Kojo
University of Helsinki
Y. Nishida
WIDE Project
August 2012
Internet Engineering Task Force (IETF) E. Blanton
Request for Comments: 6675 Purdue University
Obsoletes: 3517 M. Allman
Category: Standards Track ICSI
ISSN: 2070-1721 L. Wang
Juniper Networks
I. Jarvinen
M. Kojo
University of Helsinki
Y. Nishida
WIDE Project
August 2012
A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP
一种基于选择性确认（SACK）的TCP保守丢失恢复算法
Abstract
摘要
This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. This document obsoletes RFC 3517 and describes changes from it.
本文档介绍了一种基于选择性确认（SACK）TCP选项的TCP保守丢失恢复算法。本文介绍的算法符合当前拥塞控制规范（RFC 5681）的精神，但允许TCP发送方在单次数据传输中丢失多个数据段时更有效地进行恢复。本文件淘汰了RFC 3517，并描述了其变化。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6675.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6675.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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许可证中所述的无担保。
This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. While the TCP SACK option [RFC2018] is being steadily deployed in the Internet [All00], there is evidence that hosts are not using the SACK information when making retransmission and congestion control decisions [PF01]. The goal of this document is to outline one straightforward method for TCP implementations to use SACK information to increase performance.
本文档介绍了一种基于选择性确认（SACK）TCP选项的TCP保守丢失恢复算法。虽然TCP SACK选项[RFC2018]正在互联网[All00]中稳步部署，但有证据表明主机在做出重传和拥塞控制决策时没有使用SACK信息[PF01]。本文档的目标是概述TCP实现使用SACK信息提高性能的一种简单方法。
[RFC5681] allows advanced loss recovery algorithms to be used by TCP
[RFC793] provided that they follow the spirit of TCP's congestion
control algorithms [RFC5681] [RFC2914]. [RFC6582] outlines one such
advanced recovery algorithm called NewReno. This document outlines a
loss recovery algorithm that uses the SACK TCP option [RFC2018] to
enhance TCP's loss recovery. The algorithm outlined in this
document, heavily based on the algorithm detailed in [FF96], is a
conservative replacement of the fast recovery algorithm [Jac90]
[RFC5681]. The algorithm specified in this document is a
straightforward SACK-based loss recovery strategy that follows the
guidelines set in [RFC5681] and can safely be used in TCP
implementations. Alternate SACK-based loss recovery methods can be
used in TCP as implementers see fit (as long as the alternate
algorithms follow the guidelines provided in [RFC5681]). Please
note, however, that the SACK-based decisions in this document (such
as what segments are to be sent at what time) are largely decoupled
from the congestion control algorithms, and as such can be treated as
separate issues if so desired.
[RFC5681] allows advanced loss recovery algorithms to be used by TCP
[RFC793] provided that they follow the spirit of TCP's congestion
control algorithms [RFC5681] [RFC2914]. [RFC6582] outlines one such
advanced recovery algorithm called NewReno. This document outlines a
loss recovery algorithm that uses the SACK TCP option [RFC2018] to
enhance TCP's loss recovery. The algorithm outlined in this
document, heavily based on the algorithm detailed in [FF96], is a
conservative replacement of the fast recovery algorithm [Jac90]
[RFC5681]. The algorithm specified in this document is a
straightforward SACK-based loss recovery strategy that follows the
guidelines set in [RFC5681] and can safely be used in TCP
implementations. Alternate SACK-based loss recovery methods can be
used in TCP as implementers see fit (as long as the alternate
algorithms follow the guidelines provided in [RFC5681]). Please
note, however, that the SACK-based decisions in this document (such
as what segments are to be sent at what time) are largely decoupled
from the congestion control algorithms, and as such can be treated as
separate issues if so desired.
This document represents a revision of [RFC3517] to address several situations that are not handled explicitly in that document. A
本文件对[RFC3517]进行了修订，以解决该文件中未明确处理的几种情况。A.
summary of the changes between this document and [RFC3517] can be found in Section 9.
本文件与[RFC3517]之间的变更汇总见第9节。
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
The reader is expected to be familiar with the definitions given in [RFC5681].
读者应熟悉[RFC5681]中给出的定义。
The reader is assumed to be familiar with selective acknowledgments as specified in [RFC2018].
假定读者熟悉[RFC2018]中规定的选择性确认。
For the purposes of explaining the SACK-based loss recovery algorithm, we define six variables that a TCP sender stores:
为了解释基于SACK的丢失恢复算法，我们定义了TCP发送方存储的六个变量：
"HighACK" is the sequence number of the highest byte of data that has been cumulatively ACKed at a given point.
“HighACK”是在给定点累计确认的数据最高字节的序列号。
"HighData" is the highest sequence number transmitted at a given point.
“HighData”是在给定点传输的最高序列号。
"HighRxt" is the highest sequence number which has been retransmitted during the current loss recovery phase.
“HighRxt”是在当前丢失恢复阶段重新传输的最高序列号。
"RescueRxt" is the highest sequence number which has been optimistically retransmitted to prevent stalling of the ACK clock when there is loss at the end of the window and no new data is available for transmission.
“RescueRxt”是经过优化重新传输的最高序列号，以防止在窗口结束丢失且无新数据可供传输时ACK时钟停止。
"Pipe" is a sender's estimate of the number of bytes outstanding in the network. This is used during recovery for limiting the sender's sending rate. The pipe variable allows TCP to use fundamentally different congestion control than the algorithm specified in [RFC5681]. The congestion control algorithm using the pipe estimate is often referred to as the "pipe algorithm".
“管道”是发送方对网络中未完成字节数的估计。这在恢复期间用于限制发件人的发送速率。pipe变量允许TCP使用与[RFC5681]中指定的算法完全不同的拥塞控制。使用管道估计的拥塞控制算法通常被称为“管道算法”。
"DupAcks" is the number of duplicate acknowledgments received since the last cumulative acknowledgment.
“DupAcks”是自上次累积确认以来收到的重复确认数。
For the purposes of this specification, we define a "duplicate acknowledgment" as a segment that arrives carrying a SACK block that identifies previously unacknowledged and un-SACKed octets between HighACK and HighData. Note that an ACK which carries new SACK data is counted as a duplicate acknowledgment under this definition even
在本规范中，我们将“重复确认”定义为携带SACK块到达的段，该块标识HighACK和HighData之间先前未确认和未确认的八位字节。注意，根据该定义，携带新SACK数据的ACK被视为重复确认
if it carries new data, changes the advertised window, or moves the cumulative acknowledgment point, which is different from the definition of duplicate acknowledgment in [RFC5681].
如果它携带新数据、更改播发窗口或移动累积确认点，这与[RFC5681]中重复确认的定义不同。
We define a variable "DupThresh" that holds the number of duplicate acknowledgments required to trigger a retransmission. Per [RFC5681], this threshold is defined to be 3 duplicate acknowledgments. However, implementers should consult any updates to [RFC5681] to determine the current value for DupThresh (or method for determining its value).
我们定义了一个变量“DupThresh”，它保存触发重传所需的重复确认数。根据[RFC5681]，该阈值定义为3个重复确认。但是，实施者应参考[RFC5681]的任何更新，以确定DupThresh的当前值（或确定其值的方法）。
Finally, a range of sequence numbers [A,B] is said to "cover" sequence number S if A <= S <= B.
最后，如果a<=S<=B，则序列号[a，B]的范围称为“覆盖”序列号S。
For a TCP sender to implement the algorithm defined in the next section, it must keep a data structure to store incoming selective acknowledgment information on a per connection basis. Such a data structure is commonly called the "scoreboard". The specifics of the scoreboard data structure are out of scope for this document (as long as the implementation can perform all functions required by this specification).
对于要实现下一节中定义的算法的TCP发送方，它必须保留一个数据结构，以便在每个连接的基础上存储传入的选择性确认信息。这种数据结构通常被称为“记分牌”。记分板数据结构的细节不在本文档的范围内（只要实现可以执行本规范要求的所有功能）。
Note that this document refers to keeping account of (marking) individual octets of data transferred across a TCP connection. A real-world implementation of the scoreboard would likely prefer to manage this data as sequence number ranges. The algorithms presented here allow this, but require the ability to mark arbitrary sequence number ranges as having been selectively acknowledged.
请注意，本文档涉及记录（标记）通过TCP连接传输的单个八位字节数据。记分板的实际实现可能更愿意将此数据作为序列号范围进行管理。这里介绍的算法允许这种情况，但需要能够将任意序列号范围标记为已被选择性确认。
Finally, note that the algorithm in this document assumes a sender that is not keeping track of segment boundaries after transmitting a segment. It is possible that there is a more refined and precise algorithm available to a sender that keeps this extra state than the algorithm presented herein; however, we leave this as future work.
最后，请注意，本文档中的算法假设发送方在传输段后不跟踪段边界。可能有一种更精确的算法可供发送方使用，该算法比本文提出的算法保持这种额外状态；然而，我们将此作为未来的工作。
This section describes a specific structure and control flow for implementing the TCP behavior described by this standard. The behavior is what is standardized, and this particular collection of functions is the strongly recommended means of implementing that behavior, though other approaches to achieving that behavior are feasible.
本节描述了用于实现本标准所述TCP行为的特定结构和控制流。行为是标准化的，这个特定的函数集合是强烈推荐的实现该行为的方法，尽管实现该行为的其他方法是可行的。
The definition of Sender Maximum Segment Size (SMSS) used in this section is provided in [RFC5681].
[RFC5681]中提供了本节中使用的发送方最大段大小（SMSS）的定义。
For the purposes of the algorithm defined in this document, the scoreboard SHOULD implement the following functions:
为了实现本文件中定义的算法，计分板应实现以下功能：
Update ():
更新（）：
Given the information provided in an ACK, each octet that is cumulatively ACKed or SACKed should be marked accordingly in the scoreboard data structure, and the total number of octets SACKed should be recorded.
根据ACK中提供的信息，应在记分板数据结构中相应地标记累积确认或撤销的每个八位字节，并应记录撤销的八位字节总数。
Note: SACK information is advisory and therefore SACKed data MUST NOT be removed from the TCP's retransmission buffer until the data is cumulatively acknowledged [RFC2018].
注意：SACK信息是建议性的，因此，在累积确认数据之前，不得从TCP的重传缓冲区删除SACK数据[RFC2018]。
IsLost (SeqNum):
IsLost（SeqNum）：
This routine returns whether the given sequence number is considered to be lost. The routine returns true when either DupThresh discontiguous SACKed sequences have arrived above 'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequence numbers greater than 'SeqNum' have been SACKed. Otherwise, the routine returns false.
此例程返回给定序列号是否被视为丢失。当序列号大于“SeqNum”的DupThresh不连续SACKed序列到达“SeqNum”以上或超过（DupThresh-1）*SMSS字节时，例程返回true。否则，例程返回false。
SetPipe ():
SetPipe（）：
This routine traverses the sequence space from HighACK to HighData and MUST set the "pipe" variable to an estimate of the number of octets that are currently in transit between the TCP sender and the TCP receiver. After initializing pipe to zero, the following steps are taken for each octet 'S1' in the sequence space between HighACK and HighData that has not been SACKed:
此例程遍历从HighACK到HighData的序列空间，并且必须将“pipe”变量设置为TCP发送方和TCP接收方之间当前传输的八位字节数的估计值。将管道初始化为零后，对HighACK和HighData之间的序列空间中未被清除的每个八位组“S1”执行以下步骤：
(a) If IsLost (S1) returns false:
(a) 如果IsLost（S1）返回false：
Pipe is incremented by 1 octet.
管道增加1个八位字节。
The effect of this condition is that pipe is incremented for packets that have not been SACKed and have not been determined to have been lost (i.e., those segments that are still assumed to be in the network).
此条件的影响是，对于尚未被丢弃且尚未确定已丢失的数据包（即，仍假定在网络中的数据段），管道将增加。
(b) If S1 <= HighRxt:
(b) 如果S1<=高Rxt：
Pipe is incremented by 1 octet.
管道增加1个八位字节。
The effect of this condition is that pipe is incremented for the retransmission of the octet.
这种情况的影响是，八位字节的重传增加了管道。
Note that octets retransmitted without being considered lost are counted twice by the above mechanism.
注意，在不被认为丢失的情况下重新传输的八位字节按上述机制计数两次。
NextSeg ():
NextSeg（）：
This routine uses the scoreboard data structure maintained by the Update() function to determine what to transmit based on the SACK information that has arrived from the data receiver (and hence been marked in the scoreboard). NextSeg () MUST return the sequence number range of the next segment that is to be transmitted, per the following rules:
此例程使用Update（）函数维护的记分板数据结构，根据从数据接收器收到的SACK信息（因此在记分板中标记）确定要传输的内容。NextSeg（）必须根据以下规则返回要传输的下一段的序列号范围：
(1) If there exists a smallest unSACKed sequence number 'S2' that meets the following three criteria for determining loss, the sequence range of one segment of up to SMSS octets starting with S2 MUST be returned.
(1) 如果存在满足以下三个确定丢失标准的最小未标记序列号“S2”，则必须返回从S2开始的最多SMSS八位字节的一段序列范围。
(1.a) S2 is greater than HighRxt.
（1.a）S2大于HighRxt。
(1.b) S2 is less than the highest octet covered by any received SACK.
（1.b）S2小于任何接收SACK覆盖的最高八位字节。
(1.c) IsLost (S2) returns true.
（1.c）IsLost（S2）返回true。
(2) If no sequence number 'S2' per rule (1) exists but there exists available unsent data and the receiver's advertised window allows, the sequence range of one segment of up to SMSS octets of previously unsent data starting with sequence number HighData+1 MUST be returned.
(2) 如果不存在每个规则（1）的序列号“S2”，但存在可用的未发送数据，且接收器的播发窗口允许，则必须返回从序列号HighData+1开始的先前未发送数据的SMSS八位字节的一段序列范围。
(3) If the conditions for rules (1) and (2) fail, but there exists an unSACKed sequence number 'S3' that meets the criteria for detecting loss given in steps (1.a) and (1.b) above (specifically excluding step (1.c)), then one segment of up to SMSS octets starting with S3 SHOULD be returned.
(3) 如果规则（1）和（2）的条件失败，但存在满足上述步骤（1.a）和（1.b）中给出的检测丢失标准的未标记序列号“S3”（特别是不包括步骤（1.c）），则应返回以S3开头的最多SMSS八位字节的一段。
(4) If the conditions for (1), (2), and (3) fail, but there exists outstanding unSACKed data, we provide the opportunity for a single "rescue" retransmission per entry into loss recovery. If HighACK is greater than RescueRxt (or RescueRxt is undefined), then one segment of up to SMSS octets that MUST include the highest outstanding unSACKed sequence number SHOULD be returned, and RescueRxt set to RecoveryPoint. HighRxt MUST NOT be updated.
(4) 如果（1）、（2）和（3）的条件失败，但存在未完成的未打包数据，我们将为每次进入丢失恢复的条目提供一次“救援”重传的机会。如果HighACK大于RescueRxt（或RescueRxt未定义），则应返回最多SMSS八位字节的一段，该八位字节必须包含最高未标记的序列号，并将RescueRxt设置为RecoveryPoint。HighRxt不能被更新。
Note that rules (3) and (4) are a sort of retransmission "last resort". They allow for retransmission of sequence numbers even when the sender has less certainty a segment has been
注意，规则（3）和（4）是一种重传“最后手段”。它们允许序列号的重新传输，即使发送方不太确定某个段已被传输
lost than as with rule (1). Retransmitting segments via rule (3) and (4) will help sustain the TCP's ACK clock and therefore can potentially help avoid retransmission timeouts. However, in sending these segments, the sender has two copies of the same data considered to be in the network (and also in the pipe estimate, in the case of (3)). When an ACK or SACK arrives covering this retransmitted segment, the sender cannot be sure exactly how much data left the network (one of the two transmissions of the packet or both transmissions of the packet). Therefore, the sender may underestimate pipe by considering both segments to have left the network when it is possible that only one of the two has.
与规则（1）相比，损失更大。通过规则（3）和（4）重新传输段将有助于维持TCP的ACK时钟，因此可能有助于避免重新传输超时。然而，在发送这些数据段时，发送方拥有两份被认为在网络中的相同数据的副本（在（3）的情况下，同样在管道估计中）。当覆盖该重传段的ACK或SACK到达时，发送方无法确切确定离开网络的数据量（数据包的两次传输之一或数据包的两次传输）。因此，当两段中可能只有一段已离开网络时，发送方可能会认为这两段已离开网络，从而低估管道。
(5) If the conditions for each of (1), (2), (3), and (4) are not met, then NextSeg () MUST indicate failure, and no segment is returned.
(5) 如果不满足（1）、（2）、（3）和（4）中每一项的条件，则NextSeg（）必须指示失败，并且不返回任何段。
Note: The SACK-based loss recovery algorithm outlined in this document requires more computational resources than previous TCP loss recovery strategies. However, we believe the scoreboard data structure can be implemented in a reasonably efficient manner (both in terms of computation complexity and memory usage) in most TCP implementations.
注意：本文中概述的基于SACK的丢失恢复算法比以前的TCP丢失恢复策略需要更多的计算资源。然而，我们相信在大多数TCP实现中，记分板数据结构可以以合理有效的方式实现（计算复杂性和内存使用）。
Upon the receipt of any ACK containing SACK information, the scoreboard MUST be updated via the Update () routine.
收到包含SACK信息的任何ACK后，必须通过Update（）例程更新记分板。
If the incoming ACK is a cumulative acknowledgment, the TCP MUST reset DupAcks to zero.
如果传入的ACK是累积确认，TCP必须将DupAcks重置为零。
If the incoming ACK is a duplicate acknowledgment per the definition in Section 2 (regardless of its status as a cumulative acknowledgment), and the TCP is not currently in loss recovery, the TCP MUST increase DupAcks by one and take the following steps:
如果根据第2节中的定义，传入确认为重复确认（无论其状态为累积确认），且TCP当前未处于丢失恢复中，则TCP必须将重复确认增加1，并采取以下步骤：
(1) If DupAcks >= DupThresh, go to step (4).
(1) 如果DupAcks>=DupThresh，则转至步骤（4）。
Note: This check covers the case when a TCP receives SACK information for multiple segments smaller than SMSS, which can potentially prevent IsLost() (next step) from declaring a segment as lost.
注意：此检查涵盖TCP接收多个小于SMS的段的SACK信息的情况，这可能会阻止IsLost（）（下一步）将段声明为丢失。
(2) If DupAcks < DupThresh but IsLost (HighACK + 1) returns true -- indicating at least three segments have arrived above the current cumulative acknowledgment point, which is taken to indicate loss -- go to step (4).
(2) 如果DupAcks<DupThresh，但IsLost（HighACK+1）返回true（表示至少有三个段已到达当前累积确认点以上，这表示丢失），则转至步骤（4）。
(3) The TCP MAY transmit previously unsent data segments as per Limited Transmit [RFC5681], except that the number of octets which may be sent is governed by pipe and cwnd as follows:
(3) TCP可根据受限传输[RFC5681]传输先前未发送的数据段，但可发送的八位字节数由管道和cwnd控制，如下所示：
(3.1) Set HighRxt to HighACK.
（3.1）将HighRxt设置为HighACK。
(3.2) Run SetPipe ().
（3.2）运行设置管（）。
(3.3) If (cwnd - pipe) >= 1 SMSS, there exists previously unsent data, and the receiver's advertised window allows, transmit up to 1 SMSS of data starting with the octet HighData+1 and update HighData to reflect this transmission, then return to (3.2).
（3.3）如果（cwnd-pipe）>=1个SMS，则存在以前未发送的数据，且接收器的播发窗口允许从八位组HighData+1开始发送最多1个SMS的数据，并更新HighData以反映此传输，然后返回（3.2）。
(3.4) Terminate processing of this ACK.
（3.4）终止此确认的处理。
(4) Invoke fast retransmit and enter loss recovery as follows:
(4) 调用快速重传并输入丢失恢复，如下所示：
(4.1) RecoveryPoint = HighData
（4.1）恢复点=高数据
When the TCP sender receives a cumulative ACK for this data octet, the loss recovery phase is terminated.
当TCP发送方收到此数据八位字节的累积ACK时，丢失恢复阶段终止。
(4.2) ssthresh = cwnd = (FlightSize / 2)
(4.2) ssthresh = cwnd = (FlightSize / 2)
The congestion window (cwnd) and slow start threshold (ssthresh) are reduced to half of FlightSize per [RFC5681]. Additionally, note that [RFC5681] requires that any segments sent as part of the Limited Transmit mechanism not be counted in FlightSize for the purpose of the above equation.
根据[RFC5681]，拥塞窗口（cwnd）和慢启动阈值（ssthresh）减少到FlightSize的一半。此外，请注意，[RFC5681]要求，出于上述等式的目的，作为有限传输机制的一部分发送的任何段不计入FlightSize。
(4.3) Retransmit the first data segment presumed dropped -- the segment starting with sequence number HighACK + 1. To prevent repeated retransmission of the same data or a premature rescue retransmission, set both HighRxt and RescueRxt to the highest sequence number in the retransmitted segment.
（4.3）重新传输假定丢弃的第一个数据段——以序列号HighACK+1开始的数据段。为了防止重复传输相同的数据或过早的rescue重新传输，请将HighRxt和RescueRxt都设置为重新传输段中的最高序列号。
(4.4) Run SetPipe ()
（4.4）运行设定管（）
Set a "pipe" variable to the number of outstanding octets currently "in the pipe"; this is the data which has been sent by the TCP sender but for which no cumulative or selective acknowledgment has been received and the data has not been determined to have been dropped in the network. It is assumed that the data is still traversing the network path.
将“管道”变量设置为当前“管道中”未完成的八位字节数；这是TCP发送方已发送的数据，但未收到任何累积或选择性确认，且未确定数据已在网络中丢弃。假设数据仍在通过网络路径。
(4.5) In order to take advantage of potential additional available cwnd, proceed to step (C) below.
（4.5）为了利用潜在的额外可用cwnd，进行以下步骤（C）。
Once a TCP is in the loss recovery phase, the following procedure MUST be used for each arriving ACK:
一旦TCP处于丢失恢复阶段，必须对每个到达的ACK使用以下过程：
(A) An incoming cumulative ACK for a sequence number greater than RecoveryPoint signals the end of loss recovery, and the loss recovery phase MUST be terminated. Any information contained in the scoreboard for sequence numbers greater than the new value of HighACK SHOULD NOT be cleared when leaving the loss recovery phase.
（A） 序列号大于RecoveryPoint的传入累积ACK表示丢失恢复结束，并且必须终止丢失恢复阶段。在离开损失恢复阶段时，不应清除记分板中包含的序列号大于HighACK新值的任何信息。
(B) Upon receipt of an ACK that does not cover RecoveryPoint, the following actions MUST be taken:
（B） 收到不包括RecoveryPoint的ACK后，必须采取以下措施：
(B.1) Use Update () to record the new SACK information conveyed by the incoming ACK.
（B.1）使用Update（）记录传入ACK传递的新SACK信息。
(B.2) Use SetPipe () to re-calculate the number of octets still in the network.
（B.2）使用SetPipe（）重新计算仍在网络中的八位字节数。
(C) If cwnd - pipe >= 1 SMSS, the sender SHOULD transmit one or more segments as follows:
（C） 如果cwnd-pipe>=1个SMS，发送方应传输一个或多个段，如下所示：
(C.1) The scoreboard MUST be queried via NextSeg () for the sequence number range of the next segment to transmit (if any), and the given segment sent. If NextSeg () returns failure (no data to send), return without sending anything (i.e., terminate steps C.1 -- C.5).
（C.1）记分牌必须通过NextSeg（）查询下一个要传输的段（如果有）的序列号范围，以及发送的给定段。如果NextSeg（）返回失败（没有要发送的数据），则返回而不发送任何内容（即，终止步骤C.1--C.5）。
(C.2) If any of the data octets sent in (C.1) are below HighData, HighRxt MUST be set to the highest sequence number of the retransmitted segment unless NextSeg () rule (4) was invoked for this retransmission.
（C.2）如果（C.1）中发送的任何数据八位字节低于HighData，则必须将HighRxt设置为重传段的最高序列号，除非为该重传调用了NextSeg（）规则（4）。
(C.3) If any of the data octets sent in (C.1) are above HighData, HighData must be updated to reflect the transmission of previously unsent data.
（C.3）如果（C.1）中发送的任何数据八位字节高于HighData，则必须更新HighData以反映以前未发送数据的传输。
(C.4) The estimate of the amount of data outstanding in the network must be updated by incrementing pipe by the number of octets transmitted in (C.1).
（C.4）网络中未完成数据量的估计值必须通过将管道增加（C.1）中传输的八位字节数来更新。
(C.5) If cwnd - pipe >= 1 SMSS, return to (C.1)
(C.5) If cwnd - pipe >= 1 SMSS, return to (C.1)
Note that steps (A) and (C) can potentially send a burst of back-to-back segments into the network if the incoming cumulative acknowledgment is for more than SMSS octets of data, or if incoming SACK blocks indicate that more than SMSS octets of data have been lost in the second half of the window.
注意，如果传入的累积确认用于超过SMSS八位字节的数据，或者如果传入的SACK块指示在窗口的后半部分丢失了超过SMSS八位字节的数据，则步骤（A）和（C）可能会向网络发送背对背段的突发。
In order to avoid memory deadlocks, the TCP receiver is allowed to discard data that has already been selectively acknowledged. As a result, [RFC2018] suggests that a TCP sender SHOULD expunge the SACK information gathered from a receiver upon a retransmission timeout (RTO) "since the timeout might indicate that the data receiver has reneged." Additionally, a TCP sender MUST "ignore prior SACK information in determining which data to retransmit." However, since the publication of [RFC2018], this has come to be viewed by some as too strong. It has been suggested that, as long as robust tests for reneging are present, an implementation can retain and use SACK information across a timeout event [Errata1610]. While this document does not change the specification in [RFC2018], we note that implementers should consult any updates to [RFC2018] on this subject. Further, a SACK TCP sender SHOULD utilize all SACK information made available during the loss recovery following an RTO.
为了避免内存死锁，允许TCP接收器丢弃已被选择性确认的数据。因此，[RFC2018]建议TCP发送方应在重新传输超时（RTO）时删除从接收方收集的SACK信息，“因为超时可能表明数据接收方已叛逆。”此外，TCP发送方必须“在确定要重新传输的数据时忽略先前的SACK信息。”，自[RFC2018]出版以来，一些人认为这一点过于强烈。有人建议，只要存在针对拒绝的健壮测试，实现就可以在超时事件中保留和使用SACK信息[Errata1610]。虽然本文档没有更改[RFC2018]中的规范，但我们注意到，实现者应该就这个问题咨询[RFC2018]的任何更新。此外，SACK TCP发送方应利用RTO后丢失恢复期间可用的所有SACK信息。
If an RTO occurs during loss recovery as specified in this document, RecoveryPoint MUST be set to HighData. Further, the new value of RecoveryPoint MUST be preserved and the loss recovery algorithm outlined in this document MUST be terminated. In addition, a new recovery phase (as described in Section 5) MUST NOT be initiated until HighACK is greater than or equal to the new value of RecoveryPoint.
如果在本文档中指定的损失恢复期间发生RTO，则必须将RecoveryPoint设置为HighData。此外，必须保留RecoveryPoint的新值，并且必须终止本文档中概述的损失恢复算法。此外，在HighACK大于或等于RecoveryPoint的新值之前，不得启动新的恢复阶段（如第5节所述）。
As described in Sections 4 and 5, Update () SHOULD continue to be used appropriately upon receipt of ACKs. This will allow the recovery period after an RTO to benefit from all available information provided by the receiver, even if SACK information was expunged due to the RTO.
如第4节和第5节所述，在收到ACK后，应继续适当使用Update（）。这将允许RTO后的恢复期受益于接收方提供的所有可用信息，即使由于RTO而删除了SACK信息。
If there are segments missing from the receiver's buffer following processing of the retransmitted segment, the corresponding ACK will contain SACK information. In this case, a TCP sender SHOULD use this SACK information when determining what data should be sent in each segment following an RTO. The exact algorithm for this selection is not specified in this document (specifically NextSeg () is inappropriate during loss recovery after an RTO). A relatively straightforward approach to "filling in" the sequence space reported as missing should be a reasonable approach.
如果在处理重传的段之后，接收器的缓冲区中缺少段，则相应的ACK将包含SACK信息。在这种情况下，TCP发送方在确定RTO之后的每个段中应发送哪些数据时，应使用此SACK信息。本文档中未指定此选择的确切算法（尤其是在RTO后的损失恢复期间，NextSeg（）是不合适的）。一种相对简单的方法来“填充”报告为缺失的序列空间应该是一种合理的方法。
The standard TCP RTO estimator is defined in [RFC6298]. Due to the fact that the SACK algorithm in this document can have an impact on the behavior of the estimator, implementers may wish to consider how the timer is managed. [RFC6298] calls for the RTO timer to be re-armed each time an ACK arrives that advances the cumulative ACK point. Because the algorithm presented in this document can keep the ACK clock going through a fairly significant loss event (comparatively longer than the algorithm described in [RFC5681]), on some networks the loss event could last longer than the RTO. In this case the RTO timer would expire prematurely and a segment that need not be retransmitted would be resent.
[RFC6298]中定义了标准TCP RTO估计器。由于该文档中的SAK算法可以对估计器的行为产生影响，所以实现者可能希望考虑如何管理计时器。[RFC6298]在每次ACK到达时调用RTO计时器，使累积ACK点提前。由于本文中介绍的算法可以使ACK时钟通过相当重要的丢失事件（比[RFC5681]中描述的算法更长），因此在某些网络上，丢失事件的持续时间可能比RTO更长。在这种情况下，RTO计时器将提前到期，并且不需要重新传输的段将重新发送。
Therefore, we give implementers the latitude to use the standard [RFC6298]-style RTO management or, optionally, a more careful variant that re-arms the RTO timer on each retransmission that is sent during recovery MAY be used. This provides a more conservative timer than specified in [RFC6298], and so may not always be an attractive alternative. However, in some cases it may prevent needless retransmissions, go-back-N transmission, and further reduction of the congestion window.
因此，我们为实现者提供了使用标准[RFC6298]式RTO管理的自由度，或者可以选择使用一种更谨慎的变体，在恢复期间发送的每次重传中重新配置RTO计时器。这提供了一个比[RFC6298]中规定的更保守的计时器，因此可能并不总是一个有吸引力的替代方案。然而，在某些情况下，它可以防止不必要的重传、回退N传输和进一步减少拥塞窗口。
The algorithm specified in this document is analyzed in [FF96], which shows that the above algorithm is effective in reducing transfer time over standard TCP Reno [RFC5681] when multiple segments are dropped from a window of data (especially as the number of drops increases). [AHKO97] shows that the algorithm defined in this document can greatly improve throughput in connections traversing satellite channels.
[FF96]中分析了本文件中指定的算法，这表明当从数据窗口中删除多个数据段时（尤其是当删除次数增加时），上述算法在减少标准TCP Reno[RFC5681]的传输时间方面是有效的。[AHKO97]表明，本文中定义的算法可以极大地提高通过卫星信道的连接的吞吐量。
The algorithm presented in this paper shares security considerations with [RFC5681]. A key difference is that an algorithm based on SACKs is more robust against attackers forging duplicate ACKs to force the TCP sender to reduce cwnd. With SACKs, TCP senders have an additional check on whether or not a particular ACK is legitimate. While not fool-proof, SACK does provide some amount of protection in this area.
本文提出的算法与[RFC5681]具有相同的安全性考虑。一个关键的区别是，基于SACK的算法对伪造重复ACK以迫使TCP发送方减少cwnd的攻击者更具鲁棒性。对于SACK，TCP发送方可以额外检查特定ACK是否合法。虽然不是傻瓜式的，但SACK确实在这方面提供了一定程度的保护。
Similarly, [CPNI309] sketches a variant of a blind attack [RFC5961] whereby an attacker can spoof out-of-window data to a TCP endpoint, causing it to respond to the legitimate peer with a duplicate cumulative ACK, per [RFC793]. Adding a SACK-based requirement to trigger loss recovery effectively mitigates this attack, as the
类似地，[CPNI309]描绘了盲攻击[RFC5961]的一种变体，攻击者可以根据[RFC793]将窗口外数据欺骗到TCP端点，使其以重复的累积ACK响应合法对等方。添加基于SACK的要求以触发损失恢复，可以有效地缓解此攻击，因为
duplicate ACKs caused by out-of-window segments will not contain SACK information indicating reception of previously un-SACKED in-window data.
由窗口外段引起的重复ACK将不包含SACK信息，该信息指示接收到以前未解除的窗口内数据。
The state variable "DupAcks" has been added to the list of variables maintained by this algorithm, and its usage specified.
状态变量“DupAcks”已添加到此算法维护的变量列表中，并指定了其用法。
The function IsLost () has been modified to require that more than (DupThresh - 1) * SMSS octets have been SACKed above a given sequence number as indication that it is lost, which is changed from the minimum requirement of (DupThresh * SMSS) described in [RFC3517]. This retains the requirement that at least three segments following the sequence number in question have been SACKed, while improving detection in the event that the sender has outstanding segments which are smaller than SMSS.
函数IsLost（）已修改为要求在给定序列号上方填充超过（DupThresh-1）*SMSS八位字节，以表示丢失，这与[RFC3517]中所述的（DupThresh*SMSS）的最低要求不同。这保留了以下要求，即在所讨论的序列号之后至少有三个段已被丢弃，同时改进了在发送方具有小于SMS的未完成段的情况下的检测。
The definition of a "duplicate acknowledgment" has been modified to utilize the SACK information in detecting loss. Duplicate cumulative acknowledgments can be caused by either loss or reordering in the network. To disambiguate loss and reordering, TCP's fast retransmit algorithm [RFC5681] waits until three duplicate ACKs arrive to trigger loss recovery. This notion was then the basis for the algorithm specified in [RFC3517]. However, with SACK information there is no need to rely blindly on the cumulative acknowledgment field. We can leverage the additional information present in the SACK blocks to understand that three segments lying above a gap in the sequence space have arrived at the receiver, and can use this understanding to trigger loss recovery. This notion was used in [RFC3517] during loss recovery, and the change in this document is that the notion is also used to enter a loss recovery phase.
修改了“重复确认”的定义，以利用SACK信息检测丢失。网络中的丢失或重新排序可能会导致重复的累积确认。为了消除丢失和重新排序的歧义，TCP的快速重传算法[RFC5681]等待三个重复的ACK到达，以触发丢失恢复。这个概念是[RFC3517]中规定的算法的基础。但是，对于SACK信息，不需要盲目依赖累积确认字段。我们可以利用SACK块中存在的附加信息来理解序列空间中间隙上方的三个段已经到达接收器，并且可以使用这种理解来触发丢失恢复。[RFC3517]在损失恢复期间使用了该概念，本文件中的变化是该概念也用于进入损失恢复阶段。
The state variable "RescueRxt" has been added to the list of variables maintained by the algorithm, and its usage specified. This variable is used to allow for one extra retransmission per entry into loss recovery, in order to keep the ACK clock going under certain circumstances involving loss at the end of the window. This mechanism allows for no more than one segment of no larger than 1 SMSS to be optimistically retransmitted per loss recovery.
状态变量“RescueRxt”已添加到算法维护的变量列表中，并指定了其用法。此变量用于允许每次进入丢失恢复时进行一次额外的重新传输，以便在某些情况下（包括窗口结束时的丢失）保持ACK时钟运行。该机制允许在每次丢失恢复时，对不大于1个SMS的不超过一个段进行优化重传。
Rule (3) of NextSeg() has been changed from MAY to SHOULD, to appropriately reflect the opinion of the authors and working group that it should be left in, rather than out, if an implementor does not have a compelling reason to do otherwise.
NextSeg（）的规则（3）已从5月改为“应该”，以适当反映作者和工作组的意见，即如果实施者没有令人信服的理由不这样做，则应将其保留在内部，而不是外部。
The authors wish to thank Sally Floyd for encouraging [RFC3517] and commenting on early drafts. The algorithm described in this document is loosely based on an algorithm outlined by Kevin Fall and Sally Floyd in [FF96], although the authors of this document assume responsibility for any mistakes in the above text.
作者希望感谢Sally Floyd鼓励[RFC3517]并对早期草稿发表评论。本文档中描述的算法大致基于Kevin Fall和Sally Floyd在[FF96]中概述的算法，尽管本文档的作者对上述文本中的任何错误承担责任。
[RFC3517] was co-authored by Kevin Fall, who provided crucial input to that document and hence this follow-on work.
[RFC3517]由凯文·法尔（Kevin Fall）合著，他为该文件以及后续工作提供了重要的投入。
Murali Bashyam, Ken Calvert, Tom Henderson, Reiner Ludwig, Jamshid Mahdavi, Matt Mathis, Shawn Ostermann, Vern Paxson, and Venkat Venkatsubra provided valuable feedback on earlier versions of this document.
Murali Bashyam、Ken Calvert、Tom Henderson、Reiner Ludwig、Jamshid Mahdavi、Matt Mathis、Shawn Ostermann、Vern Paxson和Venkat Venkatsubra提供了关于本文件早期版本的宝贵反馈。
We thank Matt Mathis and Jamshid Mahdavi for implementing the scoreboard in ns and hence guiding our thinking in keeping track of SACK state.
我们感谢Matt Mathis和Jamshid Mahdavi在ns中实施记分牌，从而指导我们跟踪SACK状态。
The first author would like to thank Ohio University and the Ohio University Internetworking Research Group for supporting the bulk of his work on RFC 3517, from which this document is derived.
第一作者要感谢俄亥俄大学和俄亥俄大学互联网研究小组支持他在RFC3517上的大部分工作，本文档就是从RFC3517中衍生出来的。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]Mathis，M.，Mahdavi，J.，Floyd，S.，和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 56812009年9月。
[AHKO97] Mark Allman, Chris Hayes, Hans Kruse, Shawn Ostermann, "TCP Performance Over Satellite Links", Proceedings of the Fifth International Conference on Telecommunications Systems, Nashville, TN, March, 1997.
[AHKO97]Mark Allman，Chris Hayes，Hans Kruse，Shawn Ostermann，“卫星链路上的TCP性能”，第五届国际电信系统会议记录，田纳西州纳什维尔，1997年3月。
[All00] Mark Allman, "A Web Server's View of the Transport Layer", ACM Computer Communication Review, 30(5), October 2000.
[All00]Mark Allman，“网络服务器的传输层视图”，ACM计算机通信评论，30（5），2000年10月。
[CPNI309] Fernando Gont, "Security Assessment of the Transmission Control Protocol (TCP)", CPNI Technical Note 3/2009, <http://www.gont.com.ar/papers/ tn-03-09-security-assessment-TCP.pdf>, February 2009.
[CPNI309]Fernando Gont，“传输控制协议（TCP）的安全评估”，CPNI技术说明3/2009<http://www.gont.com.ar/papers/ tn-03-09-security-assessment-TCP.pdf>，2009年2月。
[Errata1610] RFC Errata, Errata ID 1610, RFC 2018, <http://www.rfc-editor.org>.
[勘误表1610]RFC勘误表，勘误表ID 1610，RFC 2018<http://www.rfc-editor.org>.
[FF96] Kevin Fall and Sally Floyd, "Simulation-based Comparisons of Tahoe, Reno and SACK TCP", Computer Communication Review, July 1996.
[FF96]Kevin Fall和Sally Floyd，“基于模拟的塔霍、雷诺和萨克TCP的比较”，《计算机通信评论》，1996年7月。
[Jac90] Van Jacobson, "Modified TCP Congestion Avoidance Algorithm", Technical Report, LBL, April 1990.
[Jac90]Van Jacobson，“改进的TCP拥塞避免算法”，技术报告，LBL，1990年4月。
[PF01] Jitendra Padhye, Sally Floyd "Identifying the TCP Behavior of Web Servers", ACM SIGCOMM, August 2001.
[PF01]Jitendra Padhye，Sally Floyd，“识别Web服务器的TCP行为”，ACM SIGCOMM，2001年8月。
[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, April 2012.
[RFC6582]Henderson，T.，Floyd，S.，Gurtov，A.，和Y.Nishida，“TCP快速恢复算法的NewReno修改”，RFC 6582，2012年4月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
[RFC6298]Paxson，V.，Allman，M.，Chu，J.，和M.Sargent，“计算TCP的重传计时器”，RFC 62982011年6月。
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3517]Blanton，E.，Allman，M.，Fall，K.，和L.Wang，“基于保守选择确认（SACK）的TCP丢失恢复算法”，RFC 3517，2003年4月。
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
[RFC5961]Ramaiah，A.，Stewart，R.，和M.Dalal，“提高TCP对窗口盲攻击的鲁棒性”，RFC 59612010年8月。
Authors' Addresses
作者地址
Ethan Blanton Purdue University Computer Sciences 305 N. University St. West Lafayette, IN 47907 United States EMail: elb@psg.com
Ethan Blanton Purdue大学计算机科学305 N.University St.West Lafayette，美国47907电子邮件：elb@psg.com
Mark Allman International Computer Science Institute 1947 Center St. Suite 600 Berkeley, CA 94704 United States EMail: mallman@icir.org http://www.icir.org/mallman
Mark Allman国际计算机科学研究所1947 Center St.Suite 600加利福尼亚州伯克利94704美国电子邮件：mallman@icir.org http://www.icir.org/mallman
Lili Wang Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States EMail: liliw@juniper.net
Lili Wang Juniper Networks 10 Technology Park Drive Westford，马萨诸塞州01886美国电子邮件：liliw@juniper.net
Ilpo Jarvinen University of Helsinki P.O. Box 68 FI-00014 UNIVERSITY OF HELSINKI Finland EMail: ilpo.jarvinen@helsinki.fi
ILPJARVENEN赫尔辛基大学邮政信箱68 FI-000 014赫尔辛基大学芬兰电子邮件：ILPO。jarvinen@helsinki.fi
Markku Kojo University of Helsinki P.O. Box 68 FI-00014 UNIVERSITY OF HELSINKI Finland EMail: kojo@cs.helsinki.fi
马尔库科乔赫尔辛基大学芬兰邮政信箱68 FI000 014赫尔辛基大学电子邮件：kojo@cs.helsinki.fi
Yoshifumi Nishida WIDE Project Endo 5322 Fujisawa, Kanagawa 252-8520 Japan EMail: nishida@wide.ad.jp
日本神奈川藤泽5322藤泽县西田义文广域项目252-8520电子邮件：nishida@wide.ad.jp