Network Working Group S. Bhandarkar
Request for Comments: 4653 A. L. N. Reddy
Category: Experimental Texas A&M University
M. Allman
ICIR/ICSI
E. Blanton
Purdue University
August 2006
Network Working Group S. Bhandarkar
Request for Comments: 4653 A. L. N. Reddy
Category: Experimental Texas A&M University
M. Allman
ICIR/ICSI
E. Blanton
Purdue University
August 2006
Improving the Robustness of TCP to Non-Congestion Events
提高TCP对非拥塞事件的鲁棒性
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network, TCP uses loss as an indication of congestion. One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments. However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications.
本文件规定了TCP的非拥塞鲁棒性（NCR）。在没有来自网络的明确拥塞通知的情况下，TCP使用丢失作为拥塞指示。TCP检测丢失的方法之一是使用三个重复确认的到达。然而，这种启发式方法并不总是正确的，尤其是在网络路径重新排序段（无论出于何种原因）导致性能下降的情况下。TCP-NCR旨在根据连接的当前状态，通过增加触发丢失恢复所需的重复确认数，以更好地从段重新排序中消除真实段丢失的歧义，从而缓解这种性能下降。本文件规定了TCP的变更，以及这些变更的成本和收益。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................4
2. NCR Description .................................................5
3. Algorithm .......................................................6
3.1. Initialization .............................................8
3.2. Terminating Extended Limited Transmit and
Preventing Bursts ..........................................9
3.3. Extended Limited Transmit .................................10
3.4. Entering Loss Recovery ....................................11
4. Advantages .....................................................12
5. Disadvantages ..................................................12
6. Related Work ...................................................13
7. Security Considerations ........................................14
8. Acknowledgments ................................................14
9. IANA Considerations ............................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................15
1. Introduction ....................................................2
1.1. Terminology ................................................4
2. NCR Description .................................................5
3. Algorithm .......................................................6
3.1. Initialization .............................................8
3.2. Terminating Extended Limited Transmit and
Preventing Bursts ..........................................9
3.3. Extended Limited Transmit .................................10
3.4. Entering Loss Recovery ....................................11
4. Advantages .....................................................12
5. Disadvantages ..................................................12
6. Related Work ...................................................13
7. Security Considerations ........................................14
8. Acknowledgments ................................................14
9. IANA Considerations ............................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................15
One strength of TCP [RFC793] lies in its ability to adjust its sending rate according to the perceived congestion in the network [Jac88, RFC2581]. In the absence of explicit notification of congestion from the network, TCP uses segment loss as an indication of congestion (i.e., assuming queue overflow). TCP receivers send cumulative acknowledgments (ACKs) indicating the next sequence number expected from the sender for arriving segments [RFC793]. When segments arrive out of order, duplicate ACKs are generated. As specified in [RFC2581], a TCP sender uses the arrival of three duplicate ACKs as an indication of segment loss. The TCP sender retransmits the lost segment and reduces the load imposed on the network, assuming the segment loss was caused by resource contention within the network path. The TCP sender does not assume loss on the first or second duplicate ACK, but waits for three duplicate ACKs to account for minor packet reordering. However, the use of this constant threshold of duplicate ACKs has several problems that can be mitigated with a dynamic threshold.
TCP[RFC793]的一个优势在于它能够根据网络中感知到的拥塞调整发送速率[Jac88，RFC2581]。在没有来自网络的明确拥塞通知的情况下，TCP使用段丢失作为拥塞指示（即，假设队列溢出）。TCP接收器发送累积确认（ACKs），指示到达段的发送者期望的下一个序列号[RFC793]。当段无序到达时，将生成重复的ACK。如[RFC2581]所述，TCP发送方使用三个重复ACK的到达作为段丢失的指示。TCP发送方重新传输丢失的网段，并减少对网络施加的负载，假设网段丢失是由网络路径内的资源争用引起的。TCP发送方不承担第一个或第二个重复ACK的丢失，而是等待三个重复ACK来解释较小的数据包重新排序。但是，使用此重复ack的恒定阈值存在几个问题，可以通过动态阈值来缓解这些问题。
The following is an example of TCP's behavior:
以下是TCP行为的一个示例：
+ TCP A is the data sender, and TCP B is the data receiver.
+ TCP A是数据发送方，TCP B是数据接收方。
+ TCP A sends 10 segments, each consisting of a single data byte (i.e., transmits bytes 1-10 in segments 1-10).
+ TCP A发送10个段，每个段由一个数据字节组成（即，在段1-10中传输字节1-10）。
+ Assume segment 3 is dropped in the network.
+ 假设段3在网络中被丢弃。
+ TCP B cumulatively acknowledges segments 1 and 2, making the cumulative ACK transmitted to the sender 3 (the next expected sequence number). (Note: TCP B may generate one or two ACKs, depending on whether delayed ACKs [RFC1122, RFC2581] are employed.)
+ TCP B累积地确认段1和2，使得累积ACK被发送到发送方3（下一个预期序列号）。（注意：TCP B可能会生成一个或两个ACK，这取决于是否使用延迟ACK[RFC1122，RFC2581]）
+ The arrival of segments 4-10 at TCP B will each trigger the transmission of a cumulative ACK for sequence number 3. (Note: [RFC2581] recommends that delayed ACKs not be used when the ACK is triggered by an out-of-order segment.)
+ 段4-10到达TCP B将分别触发序列号3的累积ACK传输。（注意：[RFC2581]建议当ACK由无序段触发时，不要使用延迟ACK。）
+ When TCP A receives the third duplicate ACK (or fourth ACK overall) for sequence number 3, TCP A will retransmit segment 3 and reduce the sending rate by roughly half (see [RFC2581] for specifics on the congestion control state adjustments).
+ 当TCP A收到序列号3的第三个重复ACK（或全部第四个ACK）时，TCP A将重新传输段3并将发送速率降低大约一半（有关拥塞控制状态调整的详细信息，请参阅[RFC2581]）。
Alternatively, suppose segment 3 was not dropped by the network, but rather delayed such that segment 3 arrives at TCP B after segment 10. The above scenario will play out in precisely the same manner insomuch as a retransmission of segment 3 will be triggered. In other words, TCP is not capable of disambiguating this reordering event from a segment loss, resulting in an unnecessary retransmission and rate reduction.
或者，假设网段3没有被网络丢弃，而是被延迟，使得网段3在网段10之后到达TCP B。上述场景将以完全相同的方式进行，因为将触发段3的重新传输。换言之，TCP无法将此重新排序事件与段丢失区分开来，从而导致不必要的重传和速率降低。
The following is the specific motivation behind making TCP robust to reordered segments:
以下是使TCP对重新排序的数据段具有健壮性的具体动机：
* A number of Internet measurement studies have shown that packet reordering is not a rare phenomenon [Pax97, BPS99, JIDKT03, GPL04]. Further, the reordering can be well beyond that required for fast retransmit to be falsely triggered.
* 大量互联网测量研究表明，数据包重新排序并非罕见现象[Pax97、BPS99、JIDKT03、GPL04]。此外，重新排序可以远远超过错误触发快速重传所需的顺序。
* [BA02, ZKFP03] show the negative performance implications that packet reordering has on current TCP.
* [BA02，ZKFP03]显示数据包重新排序对当前TCP的负面性能影响。
* The requirement imposed by TCP for almost in-order packet delivery places a constraint on the design of future technology. Novel routing algorithms, network components, link-layer retransmission mechanisms, and applications could all be looked at with a fresh perspective if TCP were to be more robust to segment reordering. For instance, high-speed packet switches could cause resequencing of packets if TCP were more robust. There has been work proposed in the literature explicitly to ensure that packet ordering is maintained in such switches (e.g., [KM02]). Also, link-layer mechanisms that attempt to recover
* TCP对几乎按顺序发送数据包的要求对未来技术的设计提出了限制。新的路由算法、网络组件、链路层重传机制和应用程序都可以从全新的角度来看待，如果TCP要对段重新排序更具鲁棒性的话。例如，如果TCP更健壮，高速数据包交换可能会导致数据包重新排序。文献中明确提出了一些工作，以确保在此类交换机（例如[KM02]）中保持分组顺序。此外，还有尝试恢复的链接层机制
from packet corruption by retransmitting could be allowed to reorder packets, and thus increase the chances of local loss repair rather than rely on TCP to repair the loss (and, needlessly reduce its sending rate). Additional examples include multi-path routing, high-delay satellite links, and some of the schemes proposed for a differentiated services architecture. By making TCP more robust to non-congestion events, TCP-NCR may open the design space of the future Internet components.
通过重传防止数据包损坏可以允许对数据包重新排序，从而增加本地丢失修复的机会，而不是依赖TCP来修复丢失（并且不必要地降低其发送速率）。其他示例包括多径路由、高延迟卫星链路以及为区分服务体系结构提出的一些方案。通过使TCP对非拥塞事件更具鲁棒性，TCP-NCR可能为未来互联网组件的设计开辟空间。
In this document, we specify a set of TCP sender modifications to provide Non-Congestion Robustness (NCR) to TCP. In particular, these changes are built on top of TCP with selective acknowledgments (SACKs) [RFC2018] and the SACK-based loss recovery scheme given in [RFC3517], since SACK is widely deployed at this point ([MAF05] indicates that 68% of web servers and 88% of web clients utilize SACK as of spring 2004).
在本文中，我们指定了一组TCP发送方修改，以向TCP提供非拥塞鲁棒性（NCR）。特别是，这些更改是建立在TCP和选择性确认（SACK）[RFC2018]以及[RFC3517]中给出的基于SACK的丢失恢复方案之上的，因为SACK在这一点上得到了广泛部署（[MAF05]表明，截至2004年春季，68%的web服务器和88%的web客户端使用SACK）。
Note that the TCP-NCR algorithm provided in this document could be easily adapted to SCTP [RFC2960] since SCTP uses congestion control algorithms similar to TCP's (and thus has the same reordering robustness issues).
请注意，本文中提供的TCP-NCR算法可以很容易地适用于SCTP[RFC2960]，因为SCTP使用与TCP类似的拥塞控制算法（因此具有相同的重排序鲁棒性问题）。
As noted in several places in the remainder of this document, we consider TCP-NCR experimental in that more experience with the techniques is required before TCP-NCR should be used on a large scale on the Internet. We encourage implementation and experimentation with TCP-NCR in the hopes of gaining an understanding of its suitability for wide-scale deployment.
正如在本文件的其余部分中所提到的，我们认为TCP-NCR实验是在TCP NCR在互联网上大规模使用之前需要更多的技术经验。我们鼓励使用TCP-NCR进行实施和实验，希望了解其是否适合大规模部署。
The remainder of this document is organized as follows. Section 2 provides a high-level description of the TCP-NCR mechanisms. In Section 3, we specify the TCP-NCR algorithm. Section 4 provides a brief overview of the benefits of TCP-NCR, while Section 5 discusses the drawbacks. Section 6 discusses related work. Section 7 discusses security concerns.
本文件的其余部分组织如下。第2节提供了TCP-NCR机制的高级描述。在第3节中，我们指定了TCP-NCR算法。第4节简要概述了TCP-NCR的优点，而第5节讨论了其缺点。第6节讨论了相关工作。第7节讨论了安全问题。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Readers should be familiar with the TCP terminology (e.g., FlightSize, Pipe) given in [RFC2581] and [RFC3517].
读者应熟悉[RFC2581]和[RFC3517]中给出的TCP术语（如FlightSize、管道）。
As discussed above, in the face of packet reordering, three duplicate ACKs may not be enough to disambiguate loss from reordering. In this section we provide a non-normative sketch of TCP-NCR. The detailed algorithms for implementing Non-Congestion Robustness for TCP are presented in the next section.
如上所述，面对数据包重新排序，三个重复的ack可能不足以消除重新排序造成的丢失。在本节中，我们提供了TCP-NCR的非规范性草图。下一节将介绍实现TCP无拥塞鲁棒性的详细算法。
The general idea behind TCP-NCR is to increase the threshold used to trigger a fast retransmission from the current fixed value of three duplicate ACKs [RFC2581] to approximately a congestion window of data having left the network (but not less than the currently standardized value of three duplicate ACKs). Since cwnd represents the amount of data a TCP flow can transmit in one round-trip time (RTT), waiting to receive notice that cwnd bytes have left the network before deciding whether the root cause is loss or reordering imposes a delay of roughly one RTT on both the retransmission and the congestion control response. The appropriate choice for a new value of the threshold is essentially a trade-off between making the best decision regarding the cause of the duplicate ACKs and responsiveness. The choice to trigger a retransmission only after a cwnd's worth of data is known to have left the network represents roughly the largest amount of time a TCP can wait before the (often costly) retransmission timeout may be triggered. Therefore, the algorithm described in this document attempts to make the best decision possible at the expense of timeliness.
TCP-NCR背后的总体思路是将用于触发快速重传的阈值从三个重复ACK的当前固定值[RFC2581]增加到离开网络的数据的大致拥塞窗口（但不小于三个重复ACK的当前标准值）。由于cwnd表示TCP流在一个往返时间（RTT）内可以传输的数据量，因此在决定根本原因是丢失还是重新排序之前，等待接收cwnd字节已离开网络的通知会对重传和拥塞控制响应施加大约一个RTT的延迟。对于阈值的新值的适当选择本质上是在做出关于重复ack的原因的最佳决策和响应性之间进行权衡。只有在已知cwnd的数据量已离开网络后才触发重传的选择大致代表TCP在触发（通常代价高昂）重传超时之前可以等待的最大时间量。因此，本文中描述的算法试图以牺牲时效性为代价做出最佳决策。
Simply increasing the threshold before retransmitting a segment can make TCP brittle to packet loss or ACK loss since such loss reduces the number of duplicate ACKs that will arrive at the sender from the receiver. For instance, if the cwnd is 10 segments and one segment is lost, a duplicate ACK threshold of 10 will never be met because duplicate ACKs corresponding to at most 9 segments will arrive at the sender. To offset the issue of loss, we extend TCP's Limited Transmit [RFC3042] scheme to allow for the sending of new data during the period when the TCP sender is disambiguating loss and reordering. This new data serves to increase the likelihood that enough duplicate ACKs arrive at the sender to trigger loss recovery if it is appropriate.
在重新传输段之前简单地增加阈值可能会使TCP易受数据包丢失或ACK丢失的影响，因为这种丢失会减少将从接收器到达发送方的重复ACK的数量。例如，如果cwnd为10个段，并且一个段丢失，则将永远不会满足重复ACK阈值10，因为最多9个段对应的重复ACK将到达发送方。为了抵消丢失的问题，我们扩展了TCP的有限传输[RFC3042]方案，以允许在TCP发送方消除丢失和重新排序歧义期间发送新数据。此新数据有助于增加足够多的重复ACK到达发送方以触发丢失恢复（如果合适）的可能性。
Note that TCP tightly couples reliability and congestion control: when a segment is declared lost, a retransmission is triggered, and a change to the sending rate is also made on the assumption that the drop is due to resource contention [RFC2581]. Therefore, simply by changing the retransmission trigger, the congestion control response is also changed. However, we lack experience on the Internet as to whether delaying the point that a rate reduction takes place is
请注意，TCP将可靠性和拥塞控制紧密地结合在一起：当宣布某个段丢失时，会触发重新传输，并且发送速率也会发生变化，前提是丢弃是由于资源争用[RFC2581]。因此，简单地通过改变重传触发器，拥塞控制响应也会改变。然而，我们在互联网上缺乏经验，无法确定推迟降息是否是明智之举
appropriate for wide-scale deployment. Therefore, the Extended Limited Transmit mechanism proposed in this document offers two variants for experimentation.
适合大规模部署。因此，本文中提出的扩展有限传输机制提供了两种用于实验的变体。
The first Extended Limited Transmit variant, Careful Limited Transmit, calls for the transmission of one previously unsent segment, in response to duplicate acknowledgments, for every two segments that are known to have left the network. This effectively halves the sending rate, since normal TCP operation calls for the sending of one segment for every segment that has left the network. Further, the halving starts immediately and is not delayed until a retransmission is triggered. In the case of packet reordering (i.e., not segment loss), the congestion control state is restored to its previous state when reordering is determined.
第一个扩展的有限传输变体，小心有限传输，要求每两个已知已离开网络的段传输一个先前未发送的段，以响应重复确认。这实际上使发送速率减半，因为正常的TCP操作要求为离开网络的每个段发送一个段。此外，减半立即开始，并且直到触发重传才延迟。在分组重新排序（即，不是段丢失）的情况下，当确定重新排序时，拥塞控制状态恢复到其先前的状态。
The second variant, Aggressive Limited Transmit, calls for transmitting one previously unsent data segment, in response to duplicate acknowledgments, for every segment known to have left the network. With this variant, while waiting to disambiguate the loss from a reordering event, ACK-clocked transmission continues at roughly the same rate as before the event started. Retransmission and the sending rate reduction happen per [RFC2581, RFC3517], albeit with the delayed threshold described above. Although this approach delays legitimate rate reductions (possibly slightly and temporarily aggravating overall congestion on the network), the scheme has the advantage of not reducing the transmission rate in the face of segment reordering.
第二种变体，主动有限传输，要求为已知已离开网络的每个数据段发送一个先前未发送的数据段，以响应重复确认。对于这种变体，在等待消除重新排序事件造成的丢失的歧义时，ACK时钟传输以与事件开始前大致相同的速率继续。重传和发送速率降低按照[RFC2581，RFC3517]发生，尽管具有上述延迟阈值。尽管这种方法延迟了合法的速率降低（可能会略微和暂时地加剧网络上的总体拥塞），但该方案的优点是在面临段重新排序时不会降低传输速率。
Which of the two Extended Limited Transmit variants is best for use on the Internet is an open question.
两种扩展有限传输变体中哪一种最适合在互联网上使用是一个悬而未决的问题。
The TCP-NCR modifications make two fundamental changes to the way [RFC3517] currently operates, as follows.
TCP-NCR修改对[RFC3517]当前的运行方式进行了两项基本更改，如下所示。
First, the trigger for retransmitting a segment is changed from three duplicate ACKs [RFC2581, RFC3517] to indications that a congestion window's worth of data has left the network. Second, TCP-NCR decouples initial congestion control decisions from retransmission decisions, in some cases delaying congestion control changes relative to TCP's current behavior as defined in [RFC2581]. The algorithm provides two alternatives for extending Limited Transmit. The two variants of extended Limited Transmit are:
首先，用于重新传输段的触发器从三个重复ack[RFC2581，RFC3517]更改为拥塞窗口值的数据已离开网络的指示。其次，TCP-NCR将初始拥塞控制决策与重传决策分离，在某些情况下，延迟了与[RFC2581]中定义的TCP当前行为相关的拥塞控制更改。该算法为扩展有限传输提供了两种选择。扩展有限传输的两种变体是：
Careful Limited Transmit
谨慎限制传输
This variant calls for reducing the sending rate at approximately the same time [RFC2581] implementations reduce the congestion window, while at the same time withholding a retransmission (and the final congestion determination) for approximately one RTT.
此变体要求在大约相同的时间降低发送速率[RFC2581]实现减少拥塞窗口，同时为大约一个RTT保留重传（和最终拥塞确定）。
Aggressive Limited Transmit
攻击性有限传输
This variant calls for maintaining the sending rate in the face of duplicate ACKs until TCP concludes that a segment is lost and needs to be retransmitted (which TCP-NCR delays by one RTT when compared with current loss recovery schemes).
此变体要求在出现重复ACK时保持发送速率，直到TCP断定某个段丢失并需要重新传输（与当前的丢失恢复方案相比，TCP-NCR延迟了一个RTT）。
A TCP-NCR implementation MUST use either Careful Limited Transmit or Aggressive Limited Transmit.
TCP-NCR实现必须使用谨慎的有限传输或积极的有限传输。
A constant MUST be set, depending on which variant of extended Limited Transmit is used, as follows:
必须设置一个常数，具体取决于使用的扩展有限传输的变体，如下所示：
Careful Limited Transmit
谨慎限制传输
LT_F = 2/3
LT_F = 2/3
Aggressive Limited Transmit
攻击性有限传输
LT_F = 1/2
LT_F = 1/2
This constant reflects the fraction of outstanding data (including data sent during Extended Limited Transmit) that must be SACKed before a retransmission is triggered. Since Aggressive Limited Transmit sends a new segment for every segment known to have left the network, a total of roughly cwnd segments will be sent during Aggressive Limited Transmit, and therefore ideally a total of roughly 2*cwnd segments will be outstanding when a retransmission is triggered. The duplicate ACK threshold is then set to LT_F = 1/2 of 2*cwnd (or about 1 RTT worth of data). The factor is different for Careful Limited Transmit because the sender only transmits one new segment for every two segments that are SACKed and therefore will ideally have a total of 1.5*cwnd segments outstanding when the retransmission is to be triggered. Hence, the required threshold is LT_F=2/3 of 1.5*cwnd to delay the retransmission by roughly 1 RTT.
该常数反映在触发重新传输之前必须清除的未完成数据（包括在扩展有限传输期间发送的数据）的分数。由于主动有限传输为已知已离开网络的每个段发送一个新段，因此在主动有限传输期间总共将发送大约2*cwnd段，因此理想情况下，当触发重新传输时，总共大约2*cwnd段将是未完成的。然后将重复ACK阈值设置为LT_F=2*cwnd的1/2（或大约1个RTT值的数据）。谨慎限制传输的系数不同，因为发送方仅为每两个被解除的段发送一个新段，因此理想情况下，在触发重传时，总共有1.5*cwnd段未完成。因此，所需阈值为LT_F=1.5*cwnd的2/3，以将重传延迟约1 RTT。
There are situations whereby the sender cannot transmit new data during Extended Limited Transmit (e.g., lack of data from the application, receiver's advertised window limit). These situations can lead to the problems discussed in the last section when a TCP
在扩展有限传输期间，存在发送方无法传输新数据的情况（例如，缺少来自应用程序的数据、接收方的公告窗口限制）。这些情况可能会导致上一节讨论的问题，当TCP
does not employ Extended Limited Transmit and is starved for ACKs. Therefore, TCP-NCR adapts the duplicate ACK threshold on each SACK arrival to be as robust as possible given the actual amount of data that has been transmitted, or roughly LT_F times the number of outstanding segments.
不采用扩展有限传输，并且缺少ACK。因此，TCP-NCR在每个SACK到达时调整重复ACK阈值，使其在给定已传输的实际数据量或大约为未完成段数的LT_F倍的情况下尽可能可靠。
The TCP-NCR modifications specified in this document lend themselves to incremental deployment. Only the TCP implementation on the sender side requires modification (assuming both hosts support SACK). The changes themselves are modest. However, as will be discussed below, availability of additional buffer space at the receiver will help maximize the benefits of using TCP-NCR but is not strictly necessary.
本文档中指定的TCP-NCR修改适用于增量部署。只有发送方端的TCP实现需要修改（假设两台主机都支持SACK）。这些变化本身是温和的。然而，正如下文所讨论的，在接收器处提供额外的缓冲区空间将有助于最大限度地发挥使用TCP-NCR的优势，但这并不是绝对必要的。
The following algorithms depend on the notions provided by [RFC3517], and we assume the reader is familiar with the terminology given in [RFC3517]. The TCP-NCR algorithm can be adapted to alternate SACK-based loss recovery schemes. [BR04, BSRV04] outline non-SACK-based algorithms; however, we do not specify those algorithms in this document and do not recommend them due to both the complexity and security implications of having only a gross understanding of the number of outstanding segments in the network.
以下算法取决于[RFC3517]提供的概念，我们假设读者熟悉[RFC3517]中给出的术语。TCP-NCR算法可适用于备用的基于SACK的丢失恢复方案。[BR04，BSRV04]概述非基于SACK的算法；但是，由于仅大致了解网络中未完成段的数量会带来复杂性和安全影响，因此我们在本文件中未指定这些算法，也不推荐使用这些算法。
A TCP connection using the Nagle algorithm [RFC896, RFC1122] MAY employ the TCP-NCR algorithm. If a TCP implementation does implement TCP-NCR, the implementation MUST follow the various specifications provided in Sections 3.1 - 3.4. If the Nagle algorithm is not being used, there is no way to accurately calculate the number of outstanding segments in the network (and, therefore, no good way to derive an appropriate duplicate ACK threshold) without adding state to the TCP sender. A TCP connection that does not employ the Nagle algorithm SHOULD NOT use TCP-NCR. We envision that NCR could be adapted to an implementation that carefully tracks the sequence numbers transmitted in each segment. However, we leave this as future work.
使用Nagle算法[RFC896，RFC1122]的TCP连接可采用TCP-NCR算法。如果TCP实现确实实现了TCP-NCR，则实现必须遵循第3.1-3.4节中提供的各种规范。如果未使用Nagle算法，则在不向TCP发送方添加状态的情况下，无法准确计算网络中未完成段的数量（因此，也无法获得适当的重复ACK阈值）。不采用Nagle算法的TCP连接不应使用TCP-NCR。我们设想NCR可以适应一种实现，这种实现可以仔细跟踪每个段中传输的序列号。然而，我们将此作为未来的工作。
When entering a period of loss/reordering detection and Extended Limited Transmit, a TCP-NCR MUST initialize several state variables. A TCP MUST enter Extended Limited Transmit upon receiving the first ACK with a SACK block after the reception of an ACK that (a) did not contain SACK information and (b) did increase the connection's cumulative ACK point. The initializations are:
当进入丢失/重新排序检测和扩展有限传输期间时，TCP-NCR必须初始化多个状态变量。在接收到（A）不包含SACK信息且（b）增加了连接的累积ACK点的ACK后，TCP必须在接收到带有SACK块的第一个ACK时进入扩展有限传输。初始化包括：
(I.1) The TCP MUST save the current FlightSize.
（I.1）TCP必须保存当前的FlightSize。
FlightSizePrev = FlightSize
FlightSizePrev = FlightSize
(I.2) The TCP MUST set a variable for tracking the number of segments for which an ACK does not trigger a transmission during Careful Limited Transmit.
（I.2）TCP必须设置一个变量，用于跟踪在谨慎限制传输期间ACK不会触发传输的段数。
Skipped = 0
Skipped = 0
(Note: Skipped is not used during Aggressive Limited Transmit.)
（注意：在主动限制传输期间不使用跳过。）
(I.3) The TCP MUST set DupThresh (from [RFC3517]) based on the current FlightSize.
（I.3）TCP必须根据当前FlightSize设置DupThresh（来自[RFC3517]）。
DupThresh = max (LT_F * (FlightSize / SMSS),3)
DupThresh = max (LT_F * (FlightSize / SMSS),3)
Note: We keep the lower bound of DupThresh = 3 from [RFC2581, RFC3517].
注：我们保留[RFC2581，RFC3517]中DupThresh=3的下限。
In addition to the above steps, the incoming ACK MUST be processed with the E series of steps in Section 3.3.
除上述步骤外，必须使用第3.3节中的E系列步骤处理传入ACK。
Extended Limited Transmit MUST be terminated at the start of loss recovery as outlined in Section 3.4.
如第3.4节所述，扩展有限传输必须在损失恢复开始时终止。
The arrival of an ACK that advances the cumulative ACK point while in Extended Limited Transmit, but before loss recovery is triggered, signals that a series of duplicate ACKs was caused by reordering and not congestion. Therefore, the receipt of an ACK that extends the cumulative ACK point MUST terminate Extended Limited Transmit. As described below (in (T.4)), an ACK that extends the cumulative ACK point and *also* contains SACK information will also trigger the beginning of a new Extended Limited Transmit phase.
在扩展有限传输中，但在触发丢失恢复之前，提前累积ACK点的ACK的到达表明一系列重复ACK是由重新排序而非拥塞引起的。因此，扩展累积ACK点的ACK接收必须终止扩展有限传输。如下所述（在（T.4）中），扩展累积ACK点并且*还*包含SACK信息的ACK也将触发新的扩展有限发射阶段的开始。
Upon the termination of Extended Limited Transmit, and especially when using the Careful variant, TCP-NCR may be in a situation where the entire cwnd is not being utilized, and therefore TCP-NCR will be prone to transmitting a burst of segments into the network. Therefore, to mitigate this bursting when a TCP-NCR in the Extended Limited Transmit phase receives an ACK that updates the cumulative ACK point (regardless of whether the ACK contains SACK information), the following steps MUST be taken:
在扩展有限传输终止时，尤其是在使用谨慎变体时，TCP-NCR可能处于整个cwnd未被利用的情况，因此TCP-NCR将容易向网络传输突发段。因此，当处于扩展有限传输阶段的TCP-NCR接收到更新累积ACK点的ACK时（无论该ACK是否包含SACK信息），为了缓解这种突发，必须采取以下步骤：
(T.1) A TCP MUST reset cwnd to:
（T.1）TCP必须将cwnd重置为：
cwnd = min (FlightSize + SMSS,FlightSizePrev)
cwnd=最小值（FlightSize+SMSS，FlightSizePrev）
This step ensures that cwnd is not grossly larger than the amount of data outstanding, a situation that would cause a line rate burst.
此步骤确保cwnd不会明显大于未完成的数据量，这种情况会导致线速率突发。
(T.2) A TCP MUST set ssthresh to:
（T.2）TCP必须将ssthresh设置为：
ssthresh = FlightSizePrev
ssthresh = FlightSizePrev
This step provides TCP-NCR with a sense of "history". If step (T.1) reduces cwnd below FlightSizePrev, this step ensures that TCP-NCR will slow start back to the operating point in effect before Extended Limited Transmit.
此步骤为TCP-NCR提供了一种“历史”感。如果步骤（T.1）将cwnd降低到FlightSizePrev以下，该步骤将确保TCP-NCR将使启动速度减慢至扩展有限传输之前的有效工作点。
(T.3) A TCP is now permitted to transmit previously unsent data as allowed by cwnd, FlightSize, application data availability, and the receiver's advertised window.
（T.3）TCP现在可以根据cwnd、FlightSize、应用程序数据可用性和接收器的公布窗口的允许，传输以前未发送的数据。
(T.4) When an incoming ACK extends the cumulative ACK point and also contains SACK information, the initializations in steps (I.2) and (I.3) from Section 3.1 MUST be taken (but step (I.1) MUST NOT be executed) to re-start Extended Limited Transmit. In addition, the series of steps in Section 3.3 (the "E" steps) MUST be taken.
（T.4）当传入ACK扩展累积ACK点并且还包含SACK信息时，必须采取第3.1节中步骤（I.2）和（I.3）中的初始化（但不得执行步骤（I.1）以重新启动扩展有限传输。此外，必须采取第3.3节中的一系列步骤（“E”步骤）。
On each ACK containing SACK information that arrives after TCP-NCR has entered the Extended Limited Transmit phase (as outlined in Section 3.1) and before Extended Limited Transmit terminates, the sender MUST use the following procedure.
在TCP-NCR进入扩展有限传输阶段（如第3.1节所述）之后和扩展有限传输终止之前，对于包含SACK信息的每个ACK，发送方必须使用以下程序。
(E.1) The SetPipe () procedure from [RFC3517] MUST be used to set the "pipe" variable (which represents the number of bytes still considered "in the network"). Note: the current value of DupThresh MUST be used by SetPipe () to produce an accurate assessment of the amount of data still considered in the network.
（E.1）必须使用[RFC3517]中的SetPipe（）过程来设置“pipe”变量（表示“网络中”仍然考虑的字节数）。注：SetPipe（）必须使用DupThresh的当前值来准确评估网络中仍考虑的数据量。
(E.2) If the comparison in equation (1), below, holds and there are SMSS bytes of previously unsent data available for transmission, then the sender MUST transmit one segment of SMSS bytes.
（E.2）如果下面等式（1）中的比较成立，且存在可用于传输的先前未发送数据的SMSS字节，则发送方必须传输一段SMSS字节。
(pipe + Skipped) <= (FlightSizePrev - SMSS) (1)
(pipe + Skipped) <= (FlightSizePrev - SMSS) (1)
If the comparison in equation (1) does not hold or no new data can be transmitted (due to lack of data from the application or the advertised window limit), skip to step (E.6).
如果等式（1）中的比较不成立或无法传输新数据（由于缺少来自应用程序的数据或公布的窗口限制），则跳至步骤（E.6）。
(E.3) Pipe MUST be incremented by SMSS bytes.
（E.3）管道必须按SMSS字节递增。
(E.4) If using Careful Limited Transmit, Skipped MUST be incremented by SMSS bytes to ensure that the next SMSS bytes of SACKed data processed does not trigger a Limited Transmit transmission (since the goal of Careful Limited Transmit is to send upon receipt of every second duplicate ACK).
（E.4）如果使用仔细限制传输，则跳过的数据必须增加SMSS字节，以确保处理的下一个SMSS数据字节不会触发限制传输（因为仔细限制传输的目标是在接收到每秒钟的重复ACK后发送）。
(E.5) A TCP MUST return to step (E.2) to ensure that as many bytes as are appropriate are transmitted. This provides robustness to ACK loss that can be (largely) compensated for using SACK information.
（E.5）TCP必须返回步骤（E.2），以确保传输尽可能多的字节。这提供了对ACK丢失的鲁棒性，可以（很大程度上）通过使用SACK信息进行补偿。
(E.6) DupThresh MUST be reset via:
（E.6）DupThresh必须通过以下方式复位：
DupThresh = max (LT_F * (FlightSize / SMSS),3)
DupThresh = max (LT_F * (FlightSize / SMSS),3)
where FlightSize is the total number of bytes that have not been cumulatively acknowledged (which is different from "pipe").
其中FlightSize是尚未累计确认的字节总数（与“管道”不同）。
When a segment is deemed lost via the algorithms in [RFC3517], Extended Limited Transmit MUST be terminated, leaving the algorithms in [RFC3517] to govern TCP's behavior. One slight change to [RFC3517] MUST be made, however. In Section 5, step (2) of [RFC3517] MUST be changed to:
当通过[RFC3517]中的算法认为某段丢失时，必须终止扩展有限传输，让[RFC3517]中的算法来控制TCP的行为。但是，必须对[RFC3517]进行一个细微的更改。在第5节中，[RFC3517]的步骤（2）必须更改为：
(2) ssthresh = cwnd = (FlightSizePrev / 2)
(2) ssthresh = cwnd = (FlightSizePrev / 2)
This ensures that the congestion control modifications are made with respect to the amount of data in the network before FlightSize was increased by Extended Limited Transmit.
这确保在FlightSize通过扩展有限传输增加之前，针对网络中的数据量进行拥塞控制修改。
Note: Once the algorithm in [RFC3517] takes over from Extended Limited Transmit, the DupThresh value MUST be held constant until the loss recovery phase is terminated.
注：一旦[RFC3517]中的算法从扩展有限传输中接管，则DUPTRESH值必须保持恒定，直到丢失恢复阶段终止。
The major advantages of TCP-NCR are twofold. As discussed in Section 1, TCP-NCR will open up the design space for network applications and components that are currently constrained by TCP's lack of robustness to packet reordering. The second advantage is in terms of an increase in TCP performance.
TCP-NCR的主要优点有两个。如第1节所述，TCP-NCR将为网络应用程序和组件打开设计空间，这些应用程序和组件目前受到TCP对数据包重新排序缺乏鲁棒性的限制。第二个优势是TCP性能的提高。
[BR04] presents ns-2 [NS-2] simulations of a pre-cursor to the TCP-NCR algorithm specified in this document, called TCP-DCR (Delayed Congestion Response). The paper shows that TCP-DCR aids performance in comparison to unmodified TCP in the presence of packet reordering. In addition, the extended version of [BR04] presents results based on emulations involving Linux (kernel 2.4.24). These results show that the performance of TCP-DCR is similar to Linux's native implementation that seeks to "undo" wrong decisions according to duplicate-SACK (DSACK) [RFC2883] feedback (similar to the schemes outlined in [ZKFP03]), when packets are reordered by less than one RTT. The advantage of using TCP-DCR over the DSACK-based scheme is that the DSACK-based scheme tries to estimate the exact amount of reordering in the network using fairly complex algorithms, whereas TCP-DCR achieves similar results with less complicated modifications.
[BR04]对本文件中指定的TCP-NCR算法（称为TCP-DCR（延迟拥塞响应））的预游标进行了ns-2[ns-2]模拟。本文表明，与未经修改的TCP相比，TCP-DCR在存在数据包重排序的情况下有助于提高性能。此外，[BR04]的扩展版本还提供了基于Linux（内核2.4.24）仿真的结果。这些结果表明，TCP-DCR的性能类似于Linux的本机实现，当数据包按少于一个RTT的顺序重新排序时，该实现根据重复SACK（DSACK）[RFC2883]反馈（类似于[ZKFP03]中概述的方案）寻求“撤销”错误决策。与基于DSACK的方案相比，使用TCP-DCR的优势在于，基于DSACK的方案尝试使用相当复杂的算法来估计网络中重新排序的确切数量，而TCP-DCR通过不太复杂的修改获得类似的结果。
In addition, [BR04,BSRV04] illustrate the ability of TCP-DCR to allow for the improvement of other parts of the system. For example, these papers show that increasing TCP's robustness to packet reordering allows a novel wireless ARQ mechanism to be added at the link-layer. The added robustness of the link-layer to channel errors, in turn, increases TCP performance by not requiring TCP to retransmit packets that were dropped due to corruption (and thus also prevents TCP from needlessly reducing the sending rate when retransmitting these segments).
此外，[BR04，BSRV04]说明了TCP-DCR允许改进系统其他部分的能力。例如，这些论文表明，增加TCP对数据包重新排序的鲁棒性允许在链路层添加一种新的无线ARQ机制。链路层对信道错误的鲁棒性增加，从而通过不要求TCP重新传输由于损坏而丢弃的数据包来提高TCP性能（从而也防止TCP在重新传输这些数据段时不必要地降低发送速率）。
Although all the changes outlined above are implemented in the sender, the receiver also potentially has a part to play. In particular, TCP-NCR increases the receiver's buffering requirement by up to an extra cwnd -- in the case of the TCP sender using Aggressive Limited Transmit and actual loss occurring in the network. Therefore, to maximize the benefits from TCP-NCR, receivers should advertise a large window to absorb the extra out-of-order traffic. In the case that the additional buffer requirements are not met, the use of the above algorithm takes into account the reduced advertised window -- with a corresponding loss in robustness to packet reordering.
尽管上面列出的所有更改都是在发送方中实现的，但接收方也有可能发挥作用。特别是，TCP-NCR增加了接收方的缓冲要求，最多增加一个额外的cwnd——在TCP发送方使用攻击性有限传输和网络中发生的实际损失的情况下。因此，为了最大限度地从TCP-NCR中获益，接收者应该宣传一个大窗口来吸收额外的无序流量。在不满足额外缓冲区要求的情况下，上述算法的使用考虑了减少的播发窗口，并相应地降低了对数据包重新排序的鲁棒性。
In addition, using TCP-NCR could delay the delivery of data to the application by up to one RTT because the fast retransmission point is delayed by roughly one RTT in TCP-NCR. Applications that are sensitive to such delays should turn off the TCP-NCR option. For instance, a socket option could be introduced to allow applications to control whether NCR would be used for a particular connection.
此外，使用TCP-NCR可能会将数据传输到应用程序的时间延迟一个RTT，因为在TCP-NCR中，快速重传点大约延迟一个RTT。对此类延迟敏感的应用程序应关闭TCP-NCR选项。例如，可以引入套接字选项，以允许应用程序控制NCR是否将用于特定连接。
Finally, the use of TCP-NCR makes the recovery from congestion events sluggish in comparison to the standard reaction in [RFC2581]. [BR04, BSRV04] show (via simulation) that the delay in congestion response has minimal impact on the connection itself and the traffic sharing a bottleneck. [BBFS01] also indicates (again, via simulation) that "slowly responsive" congestion control may be safe for deployment in the Internet. These studies suggest that schemes that slightly delay congestion control decisions may be reasonable; however, further experimentation on the Internet is required to verify these results.
最后，与[RFC2581]中的标准反应相比，TCP-NCR的使用使得拥塞事件的恢复缓慢。[BR04，BSRV04]显示（通过模拟）拥塞响应延迟对连接本身和共享瓶颈的流量的影响最小。[BBFS01]还指出（同样，通过模拟）在互联网上部署“缓慢响应”拥塞控制可能是安全的。这些研究表明，稍微延迟拥塞控制决策的方案可能是合理的；然而，需要在互联网上进行进一步的实验来验证这些结果。
Over the past few years, several solutions have been proposed to improve the performance of TCP in the face of segment reordering. These schemes generally fall into one of two categories (with some overlap): mechanisms that try to prevent spurious retransmits from happening and mechanisms that try to detect spurious retransmits and "undo" the needless congestion control state changes that have been taken.
在过去的几年中，人们提出了几种解决方案来提高TCP在面对段重新排序时的性能。这些方案通常分为两类（有一些重叠）：一类是尝试防止虚假重传发生的机制，另一类是尝试检测虚假重传并“撤销”已采取的不必要的拥塞控制状态更改的机制。
[BA02,ZKFP03] attempt to prevent segment reordering from triggering spurious retransmits by using various algorithms to approximate the duplicate ACK threshold required to disambiguate loss and reordering over a given network path at a given time. TCP-NCR similarly tries to prevent spurious retransmits. However, TCP-NCR takes a simplified approach compared to those in [BA02, ZKFP03], in that TCP-NCR simply delays retransmission by an amount based on the current cwnd (in comparison to standard TCP), while the other schemes use relatively complex algorithms in an attempt to derive a more precise value for DupThresh that depends on the current patterns of packet reordering. While TCP-NCR offers simplicity, the other schemes may offer more precision such that applications would not be forced to wait as long for their retransmissions. Future work could be undertaken to achieve robustness without needless delay.
[BA02，ZKFP03]尝试通过使用各种算法来近似消除在给定时间在给定网络路径上丢失和重新排序的歧义所需的重复ACK阈值，防止段重新排序触发虚假重新传输。TCP-NCR同样试图防止虚假的重新传输。然而，与[BA02，ZKFP03]中的方法相比，TCP-NCR采用了一种简化的方法，因为TCP-NCR只是根据当前cwnd（与标准TCP相比）延迟一定量的重传，而其他方案则使用相对复杂的算法，试图根据数据包重新排序的当前模式得出更精确的DupThresh值。虽然TCP-NCR提供了简单性，但其他方案可能提供更高的精度，这样应用程序就不会被迫等待其重新传输的时间。可以开展今后的工作，以实现稳健性，而不会造成不必要的拖延。
On the other hand, several schemes have been developed to detect and mitigate needless retransmissions after the fact. [RFC3522, RFC3708, BA02, RFC4015, RFC4138] present algorithms to detect spurious retransmits and mitigate the changes these events made to the congestion control state. TCP-NCR could be used in conjunction with these algorithms, with TCP-NCR attempting to prevent spurious
另一方面，已经开发了几种方案来检测和减轻事后不必要的重传。[RFC3522、RFC3708、BA02、RFC4015、RFC4138]提出了检测虚假重传的算法，并减轻了这些事件对拥塞控制状态的改变。TCP-NCR可以与这些算法结合使用，TCP-NCR试图防止虚假的
retransmits and some other scheme kicking in if the prevention failed. In addition, note that TCP-NCR is concentrated on preventing spurious fast retransmits; some of the above algorithms also attempt to detect and mitigate spurious timeout-based retransmits.
如果预防失败，重新传输和其他一些方案将起作用。此外，请注意，TCP-NCR专注于防止虚假的快速重传；上述一些算法还试图检测和减轻基于超时的伪重传。
General attacks against the congestion control of TCP are described in [RFC2581]. SACK-based loss recovery for TCP [RFC3517] mitigates some of the duplicate ACK attacks against TCP's congestion control. This document builds upon that work, and the Extended Limited Transmit algorithms specified in this document have been designed to thwart the ACK division problems that are described in [RFC3465].
[RFC2581]中描述了针对TCP拥塞控制的一般攻击。基于SACK的TCP丢失恢复[RFC3517]缓解了针对TCP拥塞控制的一些重复ACK攻击。本文件以该工作为基础，本文件中规定的扩展有限传输算法旨在阻止[RFC3465]中描述的ACK分割问题。
Feedback from Lars Eggert, Ted Faber, Wesley Eddy, Gorry Fairhurst, Sally Floyd, Sara Landstrom, Nauzad Sadry, Pasi Sarolahti, Joe Touch, Nitin Vaidya, and the TCPM working group have contributed significantly to this document. Our thanks to all!
Lars Eggert、Ted Faber、Wesley Eddy、Gorry Fairhurst、Sally Floyd、Sara Landstrom、Nauzad Sadry、Pasi Sarolahti、Joe Touch、Nitin Vaidya和TCPM工作组的反馈对本文件做出了重大贡献。我们感谢大家！
[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 Acknowledgement 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月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[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月。
[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月。
[BA02] E. Blanton and M. Allman, "On Making TCP More Robust to Packet Reordering," ACM Computer Communication Review, January 2002.
[BA02]E.Blanton和M.Allman，“关于使TCP对数据包重新排序更具鲁棒性”，ACM计算机通信评论，2002年1月。
[BBFS01] D. Bansal, H. Balakrishnan, S. Floyd and S. Shenker, "Dynamic Behavior of Slowly Responsive Congestion Control Algorithms", Proceedings of ACM SIGCOMM, Sep. 2001.
[BBFS01]D.Bansal，H.Balakrishnan，S.Floyd和S.Shenker，“慢响应拥塞控制算法的动态行为”，ACM SIGCOMM会议记录，2001年9月。
[BPS99] J. Bennett, C. Partridge, and N. Shectman, "Packet reordering is not pathological network behavior," IEEE/ACM Transactions on Networking, December 1999.
[BPS99]J.Bennett，C.Partridge和N.Shectman，“数据包重新排序不是病态的网络行为”，IEEE/ACM网络交易，1999年12月。
[BR04] Sumitha Bhandarkar and A. L. Narasimha Reddy, "TCP-DCR: Making TCP Robust to Non-Congestion Events", In the Proceedings of Networking 2004 conference, May 2004. Extended version available as tech report TAMU-ECE-2003-04.
[BR04]Sumitha Bhandarkar和A.L.Narasimha Reddy，“TCP-DCR：使TCP对非拥塞事件具有鲁棒性”，发表于《2004年网络会议记录》，2004年5月。扩展版作为技术报告TAMU-ECE-2003-04提供。
[BSRV04] Sumitha Bhandarkar, Nauzad Sadry, A. L. Narasimha Reddy and Nitin Vaidya, "TCP-DCR: A Novel Protocol for Tolerating Wireless Channel Errors", to appear in IEEE Transactions on Mobile Computing.
[BSRV04]Sumitha Bhandarkar、Nauzad Sadry、A.L.Narasimha Reddy和Nitin Vaidya，“TCP-DCR：容忍无线信道错误的新协议”，将出现在移动计算的IEEE交易中。
[GPL04] Ladan Gharai, Colin Perkins and Tom Lehman, "Packet Reordering, High Speed Networks and Transport Protocol Performance", ICCCN 2004, October 2004.
[GPL04]Ladan Gharai，Colin Perkins和Tom Lehman，“数据包重新排序，高速网络和传输协议性能”，ICCCN 2004，2004年10月。
[Jac88] V. Jacobson, "Congestion Avoidance and Control", Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
[Jac88]V.Jacobson，“拥塞避免和控制”，《计算机通信评论》，第18卷，第4期，第314-329页，1988年8月。ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
[JIDKT03] S. Jaiswal, G. Iannaccone, C. Diot, J. Kurose, and D. Towsley, "Measurement and Classification of Out-of-Sequence Packets in a Tier-1 IP Backbone," Proceedings of IEEE INFOCOM, 2003.
[JIDKT03]S.Jaiswal，G.Iannacone，C.Diot，J.Kurose和D.Towsley，“一级IP主干中无序数据包的测量和分类”，IEEE信息通信会议录，2003年。
[KM02] I. Keslassy and N. McKeown, "Maintaining packet order in twostage switches," Proceedings of the IEEE Infocom, June 2002
[KM02]I.Keslassy和N.McKeown，“维护两级交换机中的数据包顺序”，IEEE信息通信会议录，2002年6月
[MAF05] A. Medina, M. Allman, S. Floyd. Measuring the Evolution of Transport Protocols in the Internet. ACM Computer Communication Review, 35(2), April 2005.
[MAF05]A.麦地那，M.奥尔曼，S.弗洛伊德。测量互联网中传输协议的演变。ACM计算机通信评论，35（2），2005年4月。
[NS-2] ns-2 Network Simulator. http://www.isi.edu/nsnam/
[NS-2] ns-2 Network Simulator. http://www.isi.edu/nsnam/
[Pax97] V. Paxson, "End-to-End Internet Packet Dynamics," Proceedings of ACM SIGCOMM, September 1997.
[Pax97]V.Paxson，“端到端互联网数据包动态”，ACM SIGCOMM会议录，1997年9月。
[RFC896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[RFC896]Nagle，J.，“IP/TCP网络中的拥塞控制”，RFC896，1984年1月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[RFC2883]Floyd，S.，Mahdavi，J.，Mathis，M.，和M.Podolsky，“TCP选择性确认（SACK）选项的扩展”，RFC 28832000年7月。
[RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson. Stream Control Transmission Protocol. October 2000.
[RFC2960]R.Stewart，Q.Xie，K.Morneault，C.Sharp，H.Schwarzbauer，T.Taylor，I.Rytina，M.Kalla，L.Zhang，V.Paxson。流控制传输协议。2000年10月。
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3465]Allman，M.，“具有适当字节计数的TCP拥塞控制（ABC）”，RFC 3465，2003年2月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[RFC3522]Ludwig，R.和M.Meyer，“TCP的Eifel检测算法”，RFC 3522，2003年4月。
[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, February 2004.
[RFC3708]Blanton，E.和M.Allman，“使用TCP重复选择确认（DSACKs）和流控制传输协议（SCTP）重复传输序列号（TSN）来检测虚假重传”，RFC 3708，2004年2月。
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", RFC 4015, February 2005.
[RFC4015]Ludwig，R.和A.Gurtov，“TCP的Eifel响应算法”，RFC 4015，2005年2月。
[RFC4138] Sarolahti, P. and M. Kojo, "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)", RFC 4138, August 2005.
[RFC4138]Sarolahti，P.和M.Kojo，“前向RTO恢复（F-RTO）：使用TCP和流控制传输协议（SCTP）检测虚假重传超时的算法”，RFC 4138，2005年8月。
[ZKFP03] M. Zhang, B. Karp, S. Floyd, L. Peterson, "RR-TCP: A Reordering-Robust TCP with DSACK", in Proceedings of the Eleventh IEEE International Conference on Networking Protocols (ICNP 2003), Atlanta, GA, November, 2003.
[ZKFP03]M.Zhang，B.Karp，S.Floyd，L.Peterson，“RR-TCP：一种使用DSACK重新排序的健壮TCP”，发表于第十一届IEEE网络协议国际会议记录（ICNP 2003），佐治亚州亚特兰大，2003年11月。
Authors' Addresses
作者地址
Sumitha Bhandarkar Dept. of Elec. Engg. 214 ZACH College Station, TX 77843-3128
Sumitha Bhandarkar电气工程部。德克萨斯州扎克学院站214号，邮编77843-3128
Phone: (512) 468-8078
EMail: sumitha@tamu.edu
URL: http://students.cs.tamu.edu/sumitha/
Phone: (512) 468-8078
EMail: sumitha@tamu.edu
URL: http://students.cs.tamu.edu/sumitha/
A. L. Narasimha Reddy Professor Dept. of Elec. Engg. 315C WERC College Station, TX 77843-3128
A.L.Narasimha Reddy，电气工程系教授。德克萨斯州WERC学院站315C 77843-3128
Phone: (979) 845-7598
EMail: reddy@ee.tamu.edu
URL: http://ee.tamu.edu/~reddy/
Phone: (979) 845-7598
EMail: reddy@ee.tamu.edu
URL: http://ee.tamu.edu/~reddy/
Mark Allman ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704-1198
马克·奥尔曼ICSI互联网研究中心1947中心街600室加利福尼亚州伯克利94704-1198
Phone: (440) 235-1792
EMail: mallman@icir.org
URL: http://www.icir.org/mallman/
Phone: (440) 235-1792
EMail: mallman@icir.org
URL: http://www.icir.org/mallman/
Ethan Blanton Purdue University Computer Science 305 North University Street West Lafayette, IN 47907
伊桑·布兰顿·普渡大学计算机科学北大学街305号西拉斐特，邮编：47907
EMail: eblanton@cs.purdue.edu
EMail: eblanton@cs.purdue.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。