Network Working Group E. Blanton
Request for Comments: 3517 Purdue University
Category: Standards Track M. Allman
BBN/NASA GRC
K. Fall
Intel Research
L. Wang
University of Kentucky
April 2003
Network Working Group E. Blanton
Request for Comments: 3517 Purdue University
Category: Standards Track M. Allman
BBN/NASA GRC
K. Fall
Intel Research
L. Wang
University of Kentucky
April 2003
A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP
一种基于SACK的TCP丢包恢复算法
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data.
本文档介绍了一种基于选择性确认（SACK）TCP选项的TCP保守丢失恢复算法。本文介绍的算法符合当前拥塞控制规范（RFC 2581）的精神，但允许TCP发送方在单次数据传输中丢失多个数据段时更有效地进行恢复。
Terminology
术语
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]中的说明进行解释。
1 Introduction
1导言
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 [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]中稳定部署，但有证据表明主机在做出重传和拥塞控制决策[PF01]时没有使用SACK信息。本文档的目标是概述TCP实现使用SACK信息提高性能的一种简单方法。
[RFC2581] allows advanced loss recovery algorithms to be used by TCP [RFC793] provided that they follow the spirit of TCP's congestion control algorithms [RFC2581, RFC2914]. [RFC2582] outlines one such advanced recovery algorithm called NewReno. This document outlines a loss recovery algorithm that uses the SACK [RFC2018] TCP option 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, RFC2581]. The algorithm specified in this document is a straightforward SACK-based loss recovery strategy that follows the guidelines set in [RFC2581] 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 [RFC2581]). 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.
[RFC2581]允许TCP[RFC793]使用高级丢失恢复算法，前提是它们遵循TCP拥塞控制算法[RFC2581，RFC2914]的精神。[RFC2582]概述了一种称为NewReno的高级恢复算法。本文档概述了一种丢失恢复算法，该算法使用SACK[RFC2018]TCP选项来增强TCP的丢失恢复。本文概述的算法主要基于[FF96]中详述的算法，是快速恢复算法[Jac90，RFC2581]的保守替代。本文档中指定的算法是一种简单的基于SACK的丢失恢复策略，遵循[RFC2581]中的指导原则，可以安全地用于TCP实现。基于SACK的备用丢失恢复方法可以在TCP中使用，因为实施者认为合适（只要备用算法遵循[RFC2581]中提供的指南）。但是，请注意，本文档中基于SACK的决策（例如在什么时间发送什么段）在很大程度上与拥塞控制算法分离，因此，如果需要，可以将其视为单独的问题。
2 Definitions
2定义
The reader is expected to be familiar with the definitions given in [RFC2581].
读者应熟悉[RFC2581]中给出的定义。
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 four 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”是在当前丢失恢复阶段重新传输的最高序列号。
"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 a fundamentally different congestion control than specified in [RFC2581]. The algorithm is often referred to as the "pipe algorithm".
“管道”是发送方对网络中未完成字节数的估计。这在恢复期间用于限制发件人的发送速率。pipe变量允许TCP使用与[RFC2581]中规定的完全不同的拥塞控制。该算法通常被称为“管道算法”。
For the purposes of this specification we define a "duplicate acknowledgment" as a segment that arrives with no data and an acknowledgment (ACK) number that is equal to the current value of HighACK, as described in [RFC2581].
在本规范中，我们将“重复确认”定义为无数据到达的段和等于当前HighACK值的确认（ACK）号，如[RFC2581]中所述。
We define a variable "DupThresh" that holds the number of duplicate acknowledgments required to trigger a retransmission. Per [RFC2581] this threshold is defined to be 3 duplicate acknowledgments. However, implementers should consult any updates to [RFC2581] to determine the current value for DupThresh (or method for determining its value).
我们定义了一个变量“DupThresh”，它保存触发重传所需的重复确认数。根据[RFC2581]，该阈值定义为3个重复确认。但是，实施者应参考[RFC2581]的任何更新，以确定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。
3 Keeping Track of SACK Information
3跟踪SACK信息
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 arbitrary sequence number ranges to be marked as having been selectively acknowledged.
请注意，本文档涉及记录（标记）通过TCP连接传输的单个八位字节数据。记分板的实际实现可能更愿意将此数据作为序列号范围进行管理。这里介绍的算法允许这样做，但需要将任意序列号范围标记为已被选择性确认。
4 Processing and Acting Upon SACK Information
4处理和处理SACK信息
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 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 (DupThresh * SMSS) bytes with sequence numbers greater than 'SeqNum' have been SACKed. Otherwise, the routine returns false.
此例程返回给定序列号是否被视为丢失。当序列号大于“SeqNum”的DupThresh不连续SACKed序列或序列号大于“SeqNum”的（DupThresh*SMSS）字节已被SACKed时，例程返回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 MAY be returned.
(3) 如果规则（1）和（2）的条件失败，但存在满足上述步骤（1.a）和（1.b）中给出的检测丢失标准的未标记序列号“S3”（特别是不包括步骤（1.c）），则可以返回最多一段以S3开头的SMSS八位字节。
Note that rule (3) is a sort of retransmission "last resort". It allows for retransmission of sequence numbers even when the sender has less certainty a segment has been lost than as with rule (1). Retransmitting segments via rule (3) will help sustain 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). When an ACK or SACK arrives covering this retransmitted segment, the
注意，规则（3）是一种重传“最后手段”。它允许重新传输序列号，即使发送方比规则（1）更不确定某个段是否丢失。通过规则（3）重新传输段将有助于维持TCP的ACK时钟，因此可能有助于避免重新传输超时。但是，在发送这些段时，发送方有两个相同数据的副本，这些数据被视为存在于网络中（也存在于管道估计中）。当覆盖该重传段的ACK或SACK到达时
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.
发送方无法确切确定离开网络的数据量（两次数据包传输中的一次或两次数据包传输中的一次）。因此，当两段中可能只有一段离开网络时，发送方可能会认为两段都离开了网络，从而低估管道。
We believe that the triggering of rule (3) will be rare and that the implications are likely limited to corner cases relative to the entire recovery algorithm. Therefore we leave the decision of whether or not to use rule (3) to implementors.
我们认为，触发规则（3）的情况将非常罕见，并且其影响可能仅限于与整个恢复算法相关的角落案例。因此，我们将是否使用规则（3）的决定权留给实现者。
(4) If the conditions for each of (1), (2), and (3) are not met, then NextSeg () MUST indicate failure, and no segment is returned.
(4) 如果不满足（1）、（2）和（3）中每一项的条件，则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实现中，记分板数据结构可以以合理有效的方式实现（计算复杂性和内存使用）。
5 Algorithm Details
5算法细节
Upon the receipt of any ACK containing SACK information, the scoreboard MUST be updated via the Update () routine.
收到包含SACK信息的任何ACK后，必须通过Update（）例程更新记分板。
Upon the receipt of the first (DupThresh - 1) duplicate ACKs, the scoreboard is to be updated as normal. Note: The first and second duplicate ACKs can also be used to trigger the transmission of previously unsent segments using the Limited Transmit algorithm [RFC3042].
在收到第一个（DupThresh-1）重复ACK后，记分牌将正常更新。注：第一个和第二个重复ACK还可用于使用有限传输算法[RFC3042]触发先前未发送段的传输。
When a TCP sender receives the duplicate ACK corresponding to DupThresh ACKs, the scoreboard MUST be updated with the new SACK information (via Update ()). If no previous loss event has occurred on the connection or the cumulative acknowledgment point is beyond the last value of RecoveryPoint, a loss recovery phase SHOULD be initiated, per the fast retransmit algorithm outlined in [RFC2581]. The following steps MUST be taken:
当TCP发送方收到对应于DupThresh ACK的重复ACK时，记分板必须用新SACK信息更新（通过更新（））。如果连接上未发生以前的丢失事件，或者累计确认点超过RecoveryPoint的最后一个值，则应按照[RFC2581]中概述的快速重传算法启动丢失恢复阶段。必须采取以下步骤：
(1) RecoveryPoint = HighData
(1) RecoveryPoint=HighData
When the TCP sender receives a cumulative ACK for this data octet the loss recovery phase is terminated.
当TCP发送方收到此数据八位字节的累积ACK时，丢失恢复阶段终止。
(2) ssthresh = cwnd = (FlightSize / 2)
(2) ssthresh = cwnd = (FlightSize / 2)
The congestion window (cwnd) and slow start threshold (ssthresh) are reduced to half of FlightSize per [RFC2581].
根据[RFC2581]，拥塞窗口（cwnd）和慢启动阈值（ssthresh）减少到FlightSize的一半。
(3) Retransmit the first data segment presumed dropped -- the segment starting with sequence number HighACK + 1. To prevent repeated retransmission of the same data, set HighRxt to the highest sequence number in the retransmitted segment.
(3) 重新传输假定丢弃的第一个数据段——以序列号HighACK+1开头的数据段。为防止重复重新传输相同的数据，请将HighRxt设置为重新传输段中的最高序列号。
(4) Run SetPipe ()
(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发送方已发送的数据，但未收到任何累积或选择性确认，且未确定数据已在网络中丢弃。假设数据仍在通过网络路径。
(5) In order to take advantage of potential additional available cwnd, proceed to step (C) below.
(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),
（C.1）记分牌必须通过NextSeg（）查询下一段要传输的序列号范围（如有），
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).
并发送给定的段。如果NextSeg（）返回failure（没有要发送的数据），则返回时不发送任何内容（即，终止步骤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.
（C.2）如果（C.1）中发送的任何数据八位字节低于HighData，则HighRxt必须设置为重传段的最高序列号。
(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)
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 "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, a SACK TCP sender SHOULD still use all SACK information made available during the slow start phase of loss recovery following an RTO.
为了避免内存死锁，允许TCP接收器丢弃已被选择性确认的数据。因此，[RFC2018]建议TCP发送方应在重新传输超时时删除从接收方收集的SACK信息，“因为超时可能表明数据接收方已叛逆”。此外，TCP发送方必须“在确定要重新传输的数据时忽略先前的SACK信息。”，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 slow start recovery period to benefit from all available information provided by the receiver, despite the fact that SACK information was expunged due to the RTO.
如第4节和第5节所述，在收到ACK后，应继续适当使用Update（）。这将允许慢启动恢复期受益于接收方提供的所有可用信息，尽管由于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
如果在处理重传的段之后，接收器的缓冲区中缺少段，则相应的ACK将包含SACK信息。在这种情况下，TCP发送方在确定每个会话中应发送哪些数据时，应使用此SACK信息
segment of the slow start. The exact algorithm for this selection is not specified in this document (specifically NextSeg () is inappropriate during slow start after an RTO). A relatively straightforward approach to "filling in" the sequence space reported as missing should be a reasonable approach.
慢启动部分。本文档中未指定此选择的确切算法（尤其是在RTO后的慢速启动期间，NextSeg（）不合适）。一种相对简单的方法来“填充”报告为缺失的序列空间应该是一种合理的方法。
6 Managing the RTO Timer
6管理RTO计时器
The standard TCP RTO estimator is defined in [RFC2988]. 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. [RFC2988] 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 [RFC2581]), 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.
[RFC2988]中定义了标准TCP RTO估计器。由于该文档中的SAK算法可以对估计器的行为产生影响，所以实现者可能希望考虑如何管理计时器。[RFC2988]在每次ACK到达时调用RTO计时器，使累积ACK点提前。由于本文中介绍的算法可以使ACK时钟通过相当重要的丢失事件（相对长于[RFC2581]中描述的算法），因此在某些网络上，丢失事件的持续时间可能长于RTO。在这种情况下，RTO计时器将提前到期，并且不需要重新传输的段将重新发送。
Therefore we give implementers the latitude to use the standard [RFC2988] 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 [RFC2988], 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.
因此，我们为实施者提供了使用标准[RFC2988]式RTO管理的自由，或者，可以选择使用更谨慎的变体，在恢复期间发送的每次重传中重新启用RTO计时器。这提供了一个比[RFC2988]中规定的更保守的计时器，因此可能并不总是一个有吸引力的替代方案。然而，在某些情况下，它可以防止不必要的重传、回退N传输和进一步减少拥塞窗口。
7 Research
7研究
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 [RFC2581] 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[RFC2581]的传输时间方面是有效的。[AHKO97]表明，本文中定义的算法可以极大地提高通过卫星信道的连接的吞吐量。
8 Security Considerations
8安全考虑
The algorithm presented in this paper shares security considerations with [RFC2581]. 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.
本文提出的算法与[RFC2581]具有相同的安全性考虑。一个关键的区别是，基于SACK的算法对伪造重复ACK以迫使TCP发送方减少cwnd的攻击者更具鲁棒性。对于SACK，TCP发送方可以额外检查特定ACK是否合法。虽然不是傻瓜式的，但SACK确实在这方面提供了一定程度的保护。
Acknowledgments
致谢
The authors wish to thank Sally Floyd for encouraging this document 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. 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. We thank Matt Mathis and Jamshid Mahdavi for implementing the scoreboard in ns and hence guiding our thinking in keeping track of SACK state.
作者希望感谢Sally Floyd对本文件的鼓励和对早期草案的评论。本文档中描述的算法大致基于Kevin Fall和Sally Floyd在[FF96]中概述的算法，尽管本文档的作者对上述文本中的任何错误承担责任。Murali Bashyam、Ken Calvert、Tom Henderson、Reiner Ludwig、Jamshid Mahdavi、Matt Mathis、Shawn Ostermann、Vern Paxson和Venkat Venkatsubra就本文件的早期版本提供了宝贵的反馈。我们感谢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 this project.
第一作者要感谢俄亥俄大学和俄亥俄大学互联网研究小组对他在这个项目上的大部分工作的支持。
Normative References
规范性引用文件
[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月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，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月。
[RFC2581] Allman, M., Paxson, V. and R. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和R.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
Informative References
资料性引用
[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]马克·奥尔曼、克里斯·海斯、汉斯·克鲁斯、肖恩·奥斯特曼。卫星链路上的TCP性能。第五届国际电信系统会议记录，田纳西州纳什维尔，1997年3月。
[All00] Mark Allman. A Web Server's View of the Transport Layer. ACM Computer Communication Review, 30(5), October 2000.
马克·奥尔曼。Web服务器的传输层视图。ACM计算机通信评论，30（5），2000年10月。
[FF96] Kevin Fall and Sally Floyd. Simulation-based Comparisons of Tahoe, Reno and SACK TCP. Computer Communication Review, July 1996.
[FF96]凯文·法尔和萨莉·弗洛伊德。基于模拟的Tahoe、Reno和SACK TCP比较。《计算机通信评论》，1996年7月。
[Jac90] Van Jacobson. Modified TCP Congestion Avoidance Algorithm. Technical Report, LBL, April 1990.
范雅各布森。改进的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月。
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[RFC2582]Floyd，S.和T.Henderson，“TCP快速恢复算法的NewReno修改”，RFC 25821999年4月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[RFC3042] Allman, M., Balakrishnan, H, and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042]Allman，M.，Balakrishnan，H和S.Floyd，“使用有限传输增强TCP的丢失恢复”，RFC 3042，2001年1月。
Intellectual Property Rights Notice
知识产权公告
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Authors' Addresses
作者地址
Ethan Blanton Purdue University Computer Sciences 1398 Computer Science Building West Lafayette, IN 47907
伊桑·布兰顿·普渡大学计算机科学1398计算机科学大楼西拉斐特，47907年
EMail: eblanton@cs.purdue.edu
EMail: eblanton@cs.purdue.edu
Mark Allman BBN Technologies/NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 54-5 Cleveland, OH 44135
马克·奥尔曼BBN技术公司/美国宇航局格伦研究中心刘易斯菲尔德21000布鲁克公园路，俄亥俄州克利夫兰市54-5号，邮编：44135
Phone: 216-433-6586
Fax: 216-433-8705
EMail: mallman@bbn.com
http://roland.grc.nasa.gov/~mallman
Phone: 216-433-6586
Fax: 216-433-8705
EMail: mallman@bbn.com
http://roland.grc.nasa.gov/~mallman
Kevin Fall Intel Research 2150 Shattuck Ave., PH Suite Berkeley, CA 94704
Kevin Fall英特尔研究院加利福尼亚州伯克利市沙塔克大道2150号，邮编94704
EMail: kfall@intel-research.net
EMail: kfall@intel-research.net
Lili Wang Laboratory for Advanced Networking 210 Hardymon Building University of Kentucky Lexington, KY 40506-0495
李丽望高级网络实验室210 HealyMon大楼肯塔基大学莱克辛顿，KY 40506 0495
EMail: lwang0@uky.edu
EMail: lwang0@uky.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。