Network Working Group M. Allman
Request for Comments: 3465 BBN/NASA GRC
Category: Experimental February 2003
Network Working Group M. Allman
Request for Comments: 3465 BBN/NASA GRC
Category: Experimental February 2003
TCP Congestion Control with Appropriate Byte Counting (ABC)
具有适当字节计数的TCP拥塞控制（ABC）
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers. This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly.
本文档对TCP增加拥塞窗口的方式提出了一个小的修改。与传统方法不同的是，对于每个到达的确认，将拥塞窗口增加一个常量，该文档建议根据每个确认覆盖的以前未确认的字节数来增加拥塞窗口。这一变化提高了TCP的性能，同时也填补了TCP接收者用来诱使发送者过快增加发送速率的安全漏洞。
Terminology
术语
Much of the language in this document is taken from [RFC2581].
本文档中的大部分语言取自[RFC2581]。
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]中所述进行解释。
1 Introduction
1导言
This document proposes a modification to the algorithm for increasing TCP's congestion window (cwnd) that improves both performance and security. Rather than increasing a TCP's congestion window based on the number of acknowledgments (ACKs) that arrive at the data sender (per the current specification [RFC2581]), the congestion window is increased based on the number of bytes acknowledged by the arriving ACKs. The algorithm improves performance by mitigating the impact of delayed ACKs on the growth of cwnd. At the same time, the algorithm provides cwnd growth in direct relation to the probed capacity of a
本文提出了一种改进算法，以增加TCP的拥塞窗口（cwnd），从而提高性能和安全性。拥塞窗口不是基于到达数据发送方的确认（确认）数量（根据当前规范[RFC2581]）增加TCP的拥塞窗口，而是基于到达的确认确认的字节数增加。该算法通过减少延迟ack对cwnd增长的影响来提高性能。同时，该算法提供的cwnd增长与网络的探测容量直接相关
network path, therefore providing a more measured response to ACKs that cover only small amounts of data (less than a full segment size) than ACK counting. This more appropriate cwnd growth can improve both performance and can prevent inappropriate cwnd growth in response to a misbehaving receiver. On the other hand, in some cases the modified cwnd growth algorithm causes larger bursts of segments to be sent into the network. In some cases this can lead to a non-negligible increase in the drop rate and reduced performance (see section 4 for a larger discussion of the issues).
网络路径，因此对仅覆盖少量数据（小于完整段大小）的ACK提供比ACK计数更可测量的响应。这种更合适的cwnd增长既可以提高性能，也可以防止因接收器行为不当而导致不适当的cwnd增长。另一方面，在某些情况下，改进的cwnd增长算法会导致向网络发送较大的分段突发。在某些情况下，这可能导致下降率不可忽略的增加和性能降低（有关问题的详细讨论，请参阅第4节）。
This document is organized as follows. Section 2 outlines the modified algorithm for increasing TCP's congestion window. Section 3 discusses the advantages of using the modified algorithm. Section 4 discusses the disadvantages of the approach outlined in this document. Section 5 outlines some of the fairness issues that must be considered for the modified algorithm. Section 6 discusses security considerations.
本文件的组织结构如下。第2节概述了增加TCP拥塞窗口的改进算法。第3节讨论了使用改进算法的优点。第4节讨论了本文件中概述的方法的缺点。第5节概述了修改后的算法必须考虑的一些公平性问题。第6节讨论了安全注意事项。
Statement of Intent
意向书
This specification contains an algorithm improving the performance of TCP which is understood to be effective and safe, but which has not been widely deployed. One goal of publication as an Experimental RFC is to be prudent, and encourage use and deployment prior to publication in the standards track. It is the intent of the Transport Area to re-submit this specification as an IETF Proposed Standard in the future, after more experience has been gained.
本规范包含一种改进TCP性能的算法，该算法被认为是有效和安全的，但尚未广泛部署。作为实验性RFC出版的一个目标是谨慎，鼓励在标准轨道出版之前使用和部署。在获得更多经验后，运输部门打算在未来将本规范作为IETF提议的标准重新提交。
2 A Modified Algorithm for Increasing the Congestion Window
2增加拥塞窗口的改进算法
As originally outlined in [Jac88] and specified in [RFC2581], TCP uses two algorithms for increasing the congestion window. During steady-state, TCP uses the Congestion Avoidance algorithm to linearly increase the value of cwnd. At the beginning of a transfer, after a retransmission timeout or after a long idle period (in some implementations), TCP uses the Slow Start algorithm to increase cwnd exponentially. According to RFC 2581, slow start bases the cwnd increase on the number of incoming acknowledgments. During congestion avoidance RFC 2581 allows more latitude in increasing cwnd, but traditionally implementations have based the increase on the number of arriving ACKs. In the following two subsections, we detail modifications to these algorithms to increase cwnd based on the number of bytes being acknowledged by each arriving ACK, rather than by the number of ACKs that arrive. We call these changes "Appropriate Byte Counting" (ABC) [All99].
正如[Jac88]中最初概述并在[RFC2581]中指定的那样，TCP使用两种算法来增加拥塞窗口。在稳态时，TCP使用拥塞避免算法线性增加cwnd的值。在传输开始时、重传超时后或长时间空闲后（在某些实现中），TCP使用慢启动算法以指数方式增加cwnd。根据RFC 2581，慢启动根据传入确认的数量增加cwnd。在避免拥塞期间，RFC 2581允许在增加cwnd方面有更多的自由度，但传统的实现是基于到达的ACK数量的增加。在下面的两小节中，我们详细介绍了对这些算法的修改，以根据每个到达的ACK确认的字节数而不是根据到达的ACK数来增加cwnd。我们称这些变化为“适当的字节计数”（ABC）[All99]。
RFC 2581 specifies that cwnd should be increased by 1 segment per round-trip time (RTT) during the congestion avoidance phase of a transfer. Traditionally, TCPs have approximated this increase by increasing cwnd by 1/cwnd for each arriving ACK. This algorithm opens cwnd by roughly 1 segment per RTT if the receiver ACKs each incoming segment and no ACK loss occurs. However, if the receiver implements delayed ACKs [Bra89], the receiver returns roughly half as many ACKs, which causes the sender to open cwnd more conservatively (by approximately 1 segment every second RTT). The approach that this document suggests is to store the number of bytes that have been ACKed in a "bytes_acked" variable in the TCP control block. When bytes_acked becomes greater than or equal to the value of the congestion window, bytes_acked is reduced by the value of cwnd. Next, cwnd is incremented by a full-sized segment (SMSS). The algorithm suggested above is specifically allowed by RFC 2581 during congestion avoidance because it opens the window by at most 1 segment per RTT.
RFC 2581规定，在换乘的拥塞避免阶段，cwnd应每往返时间（RTT）增加1段。传统上，TCP通过将每个到达ACK的cwnd增加1/cwnd来近似此增加。如果接收器确认每个传入段并且没有发生确认丢失，则该算法大约每RTT打开cwnd 1段。然而，如果接收器实现延迟ACK[Bra89]，接收器返回的ACK数量大约是原来的一半，这会导致发送方更保守地打开cwnd（大约每秒RTT一段）。本文档建议的方法是将已确认的字节数存储在TCP控制块中的“bytes_ACKed”变量中。当bytes_acked大于或等于拥塞窗口的值时，bytes_acked将减少cwnd的值。接下来，将cwnd增加一个全尺寸段（SMS）。在避免拥塞期间，RFC 2581特别允许使用上述算法，因为它在每个RTT中最多打开1段窗口。
RFC 2581 states that the sender increments the congestion window by at most, 1*SMSS bytes for each arriving acknowledgment during slow start. This document proposes that a TCP sender SHOULD increase cwnd by the number of previously unacknowledged bytes ACKed by each incoming acknowledgment, provided the increase is not more than L bytes. Choosing the limit on the increase, L, is discussed in the next subsection. When the number of previously unacknowledged bytes ACKed is less than or equal to 1*SMSS bytes, or L is less than or equal to 1*SMSS bytes, this proposal is no more aggressive (and possibly less aggressive) than allowed by RFC 2581. However, increasing cwnd by more than 1*SMSS bytes in response to a single ACK is more aggressive than allowed by RFC 2581. The more aggressive version of the slow start algorithm still falls within the spirit of the principles outlined in [Jac88] (i.e., of no more than doubling the cwnd per RTT), and this document proposes ABC for experimentation in shared networks, provided an appropriate limit is applied (see next section).
RFC 2581指出，对于慢启动期间的每个到达确认，发送方最多将拥塞窗口增加1*SMSS字节。本文档建议，TCP发送方应将cwnd增加每个传入确认之前未确认的字节数，前提是增加的字节数不超过1个字节。下一小节将讨论如何选择增加限制L。当先前未确认的字节数小于或等于1*SMSS字节，或L小于或等于1*SMSS字节时，此方案不比RFC 2581所允许的更具攻击性（可能更具攻击性）。但是，响应单个ACK将cwnd增加1*SMSS字节以上比RFC 2581允许的更具攻击性。更激进的慢启动算法仍然符合[Jac88]中概述的原则（即每RTT的cwnd不超过两倍），本文件建议在共享网络中进行ABC试验，前提是应用了适当的限制（见下一节）。
The limit, L, chosen for the cwnd increase during slow start, controls the aggressiveness of the algorithm. Choosing L=1*SMSS bytes provides behavior that is no more aggressive than allowed by RFC 2581. However, ABC with L=1*SMSS bytes is more conservative in a
为慢启动期间cwnd增加选择的限制L控制算法的攻击性。选择L=1*SMSS字节提供的行为不比RFC 2581所允许的更具攻击性。但是，L=1*SMSS字节的ABC在a中更为保守
number of key ways (as discussed in the next section) and therefore, this document suggests that even though with L=1*SMSS bytes TCP stacks will see little performance change, ABC SHOULD be used.
许多关键方法（如下一节所述），因此，本文档建议，即使L=1*SMSS字节，TCP堆栈的性能变化不大，也应使用ABC。
A very large L could potentially lead to large line-rate bursts of traffic in the face of a large amount of ACK loss or in the case when the receiver sends "stretch ACKs" (ACKs for more than the two full-sized segments allowed by the delayed ACK algorithm) [Pax97].
在面临大量ACK丢失的情况下，或在接收器发送“拉伸ACK”（延迟ACK算法允许的两个以上全尺寸段的ACK）的情况下，非常大的L可能会导致大的线路速率突发通信量）[Pax97]。
This document specifies that TCP implementations MAY use L=2*SMSS bytes and MUST NOT use L > 2*SMSS bytes. This choice balances between being conservative (L=1*SMSS bytes) and being potentially very aggressive. In addition, L=2*SMSS bytes exactly balances the negative impact of the delayed ACK algorithm (as discussed in more detail in section 3.2). Note that when L=2*SMSS bytes cwnd growth is roughly the same as the case when the standard algorithms are used in conjunction with a receiver that transmits an ACK for each incoming segment [All98] (assuming no or small amounts of ACK loss in both cases).
本文档规定TCP实现可以使用L=2*SMSS字节，而不能使用L>2*SMSS字节。这种选择在保守（L=1*SMSS字节）和潜在的非常激进之间取得平衡。此外，L=2*SMSS字节正好平衡了延迟ACK算法的负面影响（如第3.2节中更详细的讨论）。请注意，当L=2*SMSS字节时，cwnd增长与标准算法与为每个传入段发送ACK的接收器结合使用的情况大致相同[All98]（假设在这两种情况下都没有或少量ACK丢失）。
The exception to the above suggestion is during a slow start phase that follows a retransmission timeout (RTO). In this situation, a TCP MUST use L=1*SMSS as specified in RFC 2581 since ACKs for large amounts of previously unacknowledged data are common during this phase of a transfer. These ACKs do not necessarily indicate how much data has left the network in the last RTT, and therefore ABC cannot accurately determine how much to increase cwnd. As an example, say segment N is dropped by the network, and segments N+1 and N+2 arrive successfully at the receiver. The sender will receive only two duplicate ACKs and therefore must rely on the retransmission timer (RTO) to detect the loss. When the RTO expires, segment N is retransmitted. The ACK sent in response to the retransmission will be for segment N+2. However, this ACK does not indicate that three segments have left the network in the last RTT, but rather only a single segment left the network. Therefore, the appropriate cwnd increment is at most 1*SMSS bytes.
上述建议的例外情况是在重传超时（RTO）之后的缓慢启动阶段。在这种情况下，TCP必须使用RFC 2581中规定的L=1*SMS，因为在传输的这个阶段，大量以前未确认的数据的确认是常见的。这些ACK不一定表示在最后一次RTT中有多少数据离开了网络，因此ABC无法准确确定增加cwnd的量。例如，假设网段N被网络丢弃，网段N+1和N+2成功到达接收机。发送方将只收到两个重复的ACK，因此必须依靠重传计时器（RTO）来检测丢失。当RTO到期时，重新传输段N。为响应重传而发送的ACK将用于段N+2。但是，此确认并不表示在最后一次RTT中有三个网段离开了网络，而是只有一个网段离开了网络。因此，适当的cwnd增量最多为1*SMSS字节。
[Jac88] shows that increases in cwnd of more than a factor of two in succeeding RTTs can cause spurious retransmissions on slow links where the bandwidth dominates the RTT, assuming the RTO estimator given in [Jac88] and [RFC2988]. ABC stays within this limit of no more than doubling cwnd in successive RTTs by capping the increase (no matter what L is employed) by the number of previously unacknowledged bytes covered by each incoming ACK.
[Jac88]表明，假设[Jac88]和[RFC2988]中给出的RTO估计器，后续RTT中cwnd的增加超过两倍，可能会在带宽占RTT主导地位的慢链路上导致伪重传。ABC在连续RTT中保持在不超过两倍cwnd的限制范围内，方法是将增加的字节数（无论使用什么L）限制为每个传入ACK覆盖的先前未确认字节数。
3 Advantages
三大优势
This section outlines several advantages of using the ABC algorithm to increase cwnd, rather than the standard ACK counting algorithm given in [RFC2581].
本节概述了使用ABC算法增加cwnd的几个优点，而不是[RFC2581]中给出的标准ACK计数算法。
The ABC algorithm outlined in section 2 increases TCP's cwnd in proportion to the amount of data actually sent into the network. ACK counting, on the other hand, increments cwnd by a constant upon the arrival of each ACK. For instance, consider an interactive telnet connection (e.g., ssh or telnet) in which ACKs generally cover only a few bytes of data, but cwnd is increased by 1*SMSS bytes for each ACK received. When a large amount of data needs to be transmitted (e.g., displaying a large file) the data is sent in one large burst because the cwnd grows by 1*SMSS bytes per ACK rather than based on the actual amount of capacity used. Such a line-rate burst of data can potentially cause a large amount of segment loss.
第2节中概述的ABC算法根据实际发送到网络的数据量按比例增加TCP的cwnd。另一方面，ACK计数在每个ACK到达时将cwnd增加一个常数。例如，考虑一个交互式的telnet连接（例如，SSH或telnet），其中ACK通常只覆盖几个字节的数据，但是CWND为接收的每个ACK增加了1×MSSS字节。当需要传输大量数据（例如，显示大文件）时，数据以一个大突发发送，因为cwnd每ACK增加1*SMSS字节，而不是基于实际使用的容量。这样的数据线速率突发可能会导致大量的段丢失。
Congestion Window Validation (CWV) [RFC2861] addresses the above problem as well. CWV limits the amount of unused cwnd a TCP connection can accumulate. ABC can be used in conjunction with CWV to obtain an accurate measure of the network path.
拥塞窗口验证（CWV）[RFC2861]也解决了上述问题。CWV限制TCP连接可以累积的未使用cwnd的数量。ABC可与CWV结合使用，以获得网络路径的准确测量值。
Delayed ACKs [RFC1122,RFC2581] allow a TCP receiver to refrain from sending an ACK for each incoming segment. However, a receiver SHOULD send an ACK for every second full-sized segment that arrives. Furthermore, a receiver MUST NOT withhold an ACK for more than 500 ms. By reducing the number of ACKs sent to the data originator the receiver is slowing the growth of the congestion window under an ACK counting system. Using ABC with L=2*SMSS bytes can roughly negate the negative impact imposed by delayed ACKs by allowing cwnd to be increased for ACKs that are withheld by the receiver. This allows the congestion window to grow in a manner similar to the case when the receiver ACKs each incoming segment, but without adding extra traffic to the network. Simulation studies have shown increased throughput when a TCP sender uses ABC when compared to the standard ACK counting algorithm [All99], especially for short transfers that never leave the initial slow start period.
延迟确认[RFC1122，RFC2581]允许TCP接收器避免为每个传入段发送确认。然而，接收器应该为每一秒到达的全尺寸段发送一个ACK。此外，接收器不得保留ACK超过500 ms。通过减少发送给数据发起人的ACK数量，接收器正在减缓ACK计数系统下拥塞窗口的增长。使用L=2*SMSS字节的ABC可以通过允许对接收器保留的ACK增加cwnd，大致抵消延迟ACK造成的负面影响。这允许拥塞窗口以类似于接收器确认每个传入段的方式增长，但不会向网络添加额外流量。模拟研究表明，与标准的ACK计数算法[All99]相比，TCP发送方使用ABC时吞吐量增加，特别是对于从不离开初始慢启动期的短传输。
Note that delayed ACKs should not be an issue during slow start-based loss recovery, as RFC 2581 recommends that receivers should not delay ACKs that cover out-of-order segments. Therefore, as discussed above, ABC with L > 1*SMSS bytes is inappropriate for such slow start based loss recovery and MUST NOT be used.
请注意，在基于慢启动的丢失恢复过程中，延迟确认不应成为问题，因为RFC 2581建议接收机不应延迟覆盖无序段的确认。因此，如上所述，L>1*SMSS字节的ABC不适合这种基于缓慢启动的丢失恢复，因此不得使用。
Note: In the case when an entire window of data is lost, a TCP receiver will likely generate delayed ACKs and an L > 1*SMSS bytes would be safe. However, detecting this scenario is difficult. Therefore to keep ABC conservative, this document mandates that L MUST NOT be > 1*SMSS bytes in any slow start-based loss recovery.
注意：在整个数据窗口丢失的情况下，TCP接收器可能会生成延迟ACK，并且L>1*SMSS字节是安全的。然而，检测这种情况是困难的。因此，为了保持ABC的保守性，本文件规定，在任何基于慢速启动的丢失恢复中，L不得大于1*SMSS字节。
ACK loss can also retard the growth of a congestion window that increases based on the number of ACKs that arrive. When counting ACKs, dropped ACKs represent forever-missed opportunities to increase cwnd. Using ABC with L > 1*SMSS bytes allows the sender to mitigate the effect of lost ACKs.
ACK丢失还可以延迟拥塞窗口的增长，该窗口根据到达的ACK数量而增加。在计算ACK时，丢失的ACK表示永远错过了增加cwnd的机会。使用L>1*SMSS字节的ABC允许发送方减轻丢失ACK的影响。
[SCWA99] outlines several methods for a receiver to induce a TCP sender into violating congestion control and transmitting data at a potentially inappropriate rate. One of the outlined attacks is "ACK Division". This scheme involves the receiver sending multiple ACKs for each incoming data segment, each ACKing only a small portion of the original TCP data segment. Since TCP senders have traditionally used ACK counting to increase cwnd, ACK division causes inappropriately rapid cwnd growth and, in turn, a potentially inappropriate sending rate. A TCP sender that uses ABC can prevent this attack from being used to undermine standard congestion control because the cwnd increase is based on the number of bytes ACKed, rather than the number of ACKs received.
[SCWA99]概述了接收方诱导TCP发送方违反拥塞控制并以可能不适当的速率传输数据的几种方法。概述的攻击之一是“阿克师”。此方案涉及接收器为每个传入数据段发送多个ack，每个ack只发送原始TCP数据段的一小部分。由于TCP发送方传统上使用ACK计数来增加cwnd，ACK分割会导致不适当的cwnd快速增长，进而导致潜在的不适当发送速率。使用ABC的TCP发送方可以防止此攻击被用于破坏标准拥塞控制，因为cwnd的增加基于已确认的字节数，而不是已接收的确认数。
To prevent misbehaving receivers from inducing inappropriate sender behavior, this document suggests TCP implementations use ABC, even if L=1*SMSS bytes (i.e., not allowing ABC to provide more aggressive cwnd growth than allowed by RFC 2581).
为了防止行为不端的接收方诱发不适当的发送方行为，本文档建议TCP实现使用ABC，即使L=1*SMSS字节（即，不允许ABC提供比RFC 2581允许的更积极的cwnd增长）。
4 Disadvantages
4缺点
The main disadvantages of using ABC with L=2*SMSS bytes are an increase in the burstiness of TCP and a small increase in the overall loss rate. [All98] discusses the two ways that ABC increases the burstiness of the TCP sender. First, the "micro burstiness" of the connection is increased. In other words, the number of segments sent in response to each incoming ACK is increased by at most 1 segment when using ABC with L=2*SMSS bytes in conjunction with a receiver that is sending delayed ACKs. During slow start this translates into an increase from sending 2 back-to-back segments to sending 3 back-to-back packets in response to an ACK for a single packet. Or, an increase from 3 packets to 4 packets when receiving a delayed ACK for two outstanding packets. Note that ACK loss can cause larger bursts. However, ABC only increases the burst size by at most 1*SMSS bytes per ACK received when compared to the standard behavior. This slight
使用L=2*SMSS字节的ABC的主要缺点是TCP的突发性增加，总体丢失率略有增加。[All98]讨论了ABC增加TCP发送方突发性的两种方式。首先，连接的“微突发性”增加。换句话说，当与发送延迟ACK的接收机一起使用L＝2×SMSS字节的ABC时，响应于每个传入ACK而发送的段数最多增加1段。在慢启动期间，这转化为响应单个数据包的ACK，从发送2个背靠背数据段增加到发送3个背靠背数据包。或者，当接收到两个未完成分组的延迟ACK时，从3个分组增加到4个分组。请注意，ACK丢失可能会导致更大的突发。但是，与标准行为相比，ABC只会将每个接收到的ACK的突发大小最多增加1*SMSS字节。这轻微的
increase in the burstiness should only cause problems for devices that have very small buffers. In addition, ABC increases the "macro burstiness" of the TCP sender in response to delayed ACKs in slow start. Rather than increasing cwnd by roughly 1.5 times per RTT, ABC roughly doubles the congestion window every RTT. However, doubling cwnd every RTT fits within the spirit of slow start, as originally outlined [Jac88].
突发性的增加只会导致缓冲区非常小的设备出现问题。此外，ABC增加了TCP发送方的“宏突发性”，以响应慢启动中的延迟ACK。ABC不是将cwnd每RTT大约增加1.5倍，而是将拥塞窗口每RTT大约增加一倍。然而，如最初所述，每个RTT将cwnd加倍符合慢启动的精神[Jac88]。
With the increased burstiness comes a modest increase in the loss rate for a TCP connection employing ABC (see the next section for a short discussion on the fairness of ABC to non-ABC flows). The additional loss can be directly attributable to the increased aggressiveness of ABC. During slow start cwnd is increased more rapidly. Therefore when loss occurs cwnd is larger and more drops are likely. Similarly, a congestion avoidance cycle takes roughly half, as long when using ABC and delayed ACKs when compared to an ACK counting implementation. In other words, a TCP sender reaches the capacity of the network path, drops a packet and reduces the congestion window by half roughly twice as often when using ABC. However, as discussed above, in spite of the additional loss an ABC TCP sender generally obtains better overall performance than a non-ABC TCP [All99].
随着突发性的增加，采用ABC的TCP连接的丢失率也会略有增加（关于ABC对非ABC流的公平性的简短讨论，请参见下一节）。额外的损失可直接归因于ABC的攻击性增强。在缓慢启动期间，cwnd增加得更快。因此，当损失发生时，cwnd更大，可能出现更多的液滴。类似地，与ACK计数实现相比，使用ABC和延迟ACK时，拥塞避免周期大约需要一半的时间。换句话说，当使用ABC时，TCP发送方达到网络路径的容量，丢弃数据包，并将拥塞窗口减少一半，大约两倍。然而，如上所述，尽管有额外的损失，ABC TCP发送方通常比非ABC TCP发送方获得更好的总体性能[All99]。
Due to the increase in the packet drop rate we suggest ABC be implemented in conjunction with selective acknowledgments [RFC2018].
由于丢包率的增加，我们建议将ABC与选择性确认结合使用[RFC2018]。
5 Fairness Considerations
5公平考虑
[All99] presents several simple simulations conducted to measure the impact of ABC on competing traffic (both ABC and non-ABC). The experiments show that while ABC increases the drop rate for the connection using ABC, competing traffic is not greatly effected. The experiments show that standard TCP and ABC both obtain roughly the same throughput, regardless of the variant of the competing traffic. The simulations also reaffirm that ABC outperforms non-ABC TCP in an environment with varying types of TCP connections. On the other hand, the simulations presented in [All99] are not necessarily realistic. Therefore we are encouraging more experimentation in the Internet.
[All99]介绍了为测量ABC对竞争流量（ABC和非ABC）的影响而进行的几个简单模拟。实验表明，虽然ABC增加了使用ABC的连接的丢弃率，但竞争流量不会受到很大影响。实验表明，无论竞争流量如何变化，标准TCP和ABC都获得大致相同的吞吐量。模拟还重申，在具有不同类型TCP连接的环境中，ABC优于非ABC TCP。另一方面，[All99]中给出的模拟不一定真实。因此，我们鼓励在互联网上进行更多的实验。
6 Security Considerations
6安全考虑
As discussed in section 3.3, ABC protects a TCP sender from a misbehaving receiver that induces the sender into transmitting at an inappropriate rate with an "ACK division" attack. This, in turn, protects the network from an overly aggressive sender.
如第3.3节所述，ABC保护TCP发送方免受行为不当的接收方的攻击，该接收方通过“ACK分割”攻击诱导发送方以不适当的速率进行传输。这反过来又可以保护网络免受过度攻击的发送方的攻击。
7 Conclusions
7结论
This document RECOMMENDS that all TCP stacks be modified to use ABC with L=1*SMSS bytes. This change does not increase the aggressiveness of TCP. Furthermore, simulations of ABC with L=2*SMSS bytes show a promising performance improvement that we encourage researchers to experiment with in the Internet.
本文档建议修改所有TCP堆栈以使用L=1*SMSS字节的ABC。此更改不会增加TCP的攻击性。此外，模拟L=2*SMSS字节的ABC显示了一种有希望的性能改进，我们鼓励研究人员在互联网上进行试验。
Acknowledgments
致谢
This document has benefited from discussions with and encouragement from Sally Floyd. Van Jacobson and Reiner Ludwig provided valuable input on the implications of byte counting on the RTO. Reiner Ludwig and Kostas Pentikousis provided valuable feedback on a draft of this document.
本文件得益于与Sally Floyd的讨论和鼓励。Van Jacobson和Reiner Ludwig就字节计数对RTO的影响提供了宝贵的意见。Reiner Ludwig和Kostas Pentikousis就本文件草案提供了宝贵的反馈意见。
Normative References
规范性引用文件
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，Ed.“互联网主机的要求——通信层”，STD 3，RFC 1122，1989年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月。
Informative References
资料性引用
[All98] Mark Allman. On the Generation and Use of TCP Acknowledgments. ACM Computer Communication Review, 29(3), July 1998.
马克·奥尔曼。关于TCP确认的生成和使用。ACM计算机通信评论，29（3），1998年7月。
[All99] Mark Allman. TCP Byte Counting Refinements. ACM Computer Communication Review, 29(3), July 1999.
[全部99]马克·奥尔曼。TCP字节计数改进。ACM计算机通信评论，29（3），1999年7月。
[Jac88] Van Jacobson. Congestion Avoidance and Control. ACM SIGCOMM 1988.
范雅各布森。拥塞避免和控制。ACM SIGCOMM 1988。
[Pax97] Vern Paxson. Automated Packet Trace Analysis of TCP Implementations. ACM SIGCOMM, September 1997.
[Pax97]弗恩·帕克森。TCP实现的自动数据包跟踪分析。ACM SIGCOMM，1997年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月。
[RFC2861] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861]Handley，M.，Padhye，J.和S.Floyd，“TCP拥塞窗口验证”，RFC 28612000年6月。
[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, Tom Anderson. TCP Congestion Control with a Misbehaving Receiver. ACM Computer Communication Review, 29(5), October 1999.
Stefan Savage Neal Cardwell David Wetheral Tom Anderson。使用行为不正常的接收器进行TCP拥塞控制。ACM计算机通信评论，29（5），1999年10月。
Author's Address
作者地址
Mark Allman BBN Technologies/NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 54-5 Cleveland, OH 44135
马克·奥尔曼BBN技术公司/美国宇航局格伦研究中心刘易斯菲尔德21000布鲁克公园路，俄亥俄州克利夫兰市54-5号，邮编：44135
Fax: 216-433-8705
Phone: 216-433-6586
EMail: mallman@bbn.com
http://roland.grc.nasa.gov/~mallman
Fax: 216-433-8705
Phone: 216-433-6586
EMail: mallman@bbn.com
http://roland.grc.nasa.gov/~mallman
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编辑功能的资金目前由互联网协会提供。