Independent Submission S. Floyd
Request for Comments: 5690 ICIR
Category: Informational A. Arcia
ISSN: 2070-1721 D. Ros
TELECOM Bretagne
J. Iyengar
Franklin & Marshall College
February 2010
Independent Submission S. Floyd
Request for Comments: 5690 ICIR
Category: Informational A. Arcia
ISSN: 2070-1721 D. Ros
TELECOM Bretagne
J. Iyengar
Franklin & Marshall College
February 2010
Adding Acknowledgement Congestion Control to TCP
向TCP添加确认拥塞控制
Abstract
摘要
This document describes a possible congestion control mechanism for acknowledgement (ACKs) traffic in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts: the TCP data sender and the TCP data receiver. The TCP data sender detects lost or Explicit Congestion Notification (ECN)-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in the Datagram Congestion Control Protocol's (DCCP's) Congestion Control Identifier (CCID) 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community.
本文档描述了TCP中确认（ACKs）流量的可能拥塞控制机制。该文档为TCP指定了一种端到端确认拥塞控制机制，该机制使用TCP主机（TCP数据发送方和TCP数据接收方）的参与。TCP数据发送方检测丢失或显式拥塞通知（ECN）标记的ACK数据包，并告知TCP数据接收方ACK比率R，用于响应从数据接收方到数据发送方的反向路径上的拥塞。TCP数据接收器对于接收到的每R个数据包发送大约一个ACK数据包。该机制基于数据报拥塞控制协议（DCCP）的拥塞控制标识符（CCID）2中的确认拥塞控制。该确认拥塞控制机制正被指定用于网络社区的进一步评估。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5690.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5690.
IESG Note
IESG注释
The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work.
IETF曾考虑过本RFC的内容，因此它可能类似于当前正在进行的IETF工作或已发布的IETF工作。
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions and Terminology .....................................4
3. Overview ........................................................4
4. Acknowledgement Congestion Control ..............................6
4.1. The ACK Congestion Control Permitted Option ................6
4.2. The TCP ACK Ratio Option ...................................7
4.3. The Receiver: Implementing the ACK Ratio ...................7
4.4. The Sender: Determining Lost or Marked ACK Packets .........8
4.4.1. The Sender: Detecting Lost ACK Packets
after a Congestion Event ...........................10
4.5. The Sender: Adjusting the ACK Ratio .......................10
4.5.1. Possible Addition: Decreasing the ACK Ratio
after a Congestion Window Decrease .................12
4.6. The Receiver: Sending ACKs for Out-of-Order Data
Segments ..................................................12
4.7. The Sender: Response to ACK Packets .......................13
4.8. Possible Addition: Receiver Bounds on the ACK Ratio .......15
5. Possible Complications .........................................15
5.1. Possible Complication: Delayed Acknowledgements ...........15
5.2. Possible Complication: Duplicate Acknowledgements .........15
5.3. Possible Complication: Two-Way Traffic ....................16
5.4. Possible Complication: Reordering of ACK Packets ..........16
5.5. Possible Complication: Abrupt Changes in the ACK Path .....17
5.6. Possible Complication: Corruption .........................17
5.7. Possible Complication: ACKs That Don't Contribute
to Congestion .............................................17
5.8. Possible Complication: TCP Implementations that
Skip ACK Packets ..........................................20
1. Introduction ....................................................3
2. Conventions and Terminology .....................................4
3. Overview ........................................................4
4. Acknowledgement Congestion Control ..............................6
4.1. The ACK Congestion Control Permitted Option ................6
4.2. The TCP ACK Ratio Option ...................................7
4.3. The Receiver: Implementing the ACK Ratio ...................7
4.4. The Sender: Determining Lost or Marked ACK Packets .........8
4.4.1. The Sender: Detecting Lost ACK Packets
after a Congestion Event ...........................10
4.5. The Sender: Adjusting the ACK Ratio .......................10
4.5.1. Possible Addition: Decreasing the ACK Ratio
after a Congestion Window Decrease .................12
4.6. The Receiver: Sending ACKs for Out-of-Order Data
Segments ..................................................12
4.7. The Sender: Response to ACK Packets .......................13
4.8. Possible Addition: Receiver Bounds on the ACK Ratio .......15
5. Possible Complications .........................................15
5.1. Possible Complication: Delayed Acknowledgements ...........15
5.2. Possible Complication: Duplicate Acknowledgements .........15
5.3. Possible Complication: Two-Way Traffic ....................16
5.4. Possible Complication: Reordering of ACK Packets ..........16
5.5. Possible Complication: Abrupt Changes in the ACK Path .....17
5.6. Possible Complication: Corruption .........................17
5.7. Possible Complication: ACKs That Don't Contribute
to Congestion .............................................17
5.8. Possible Complication: TCP Implementations that
Skip ACK Packets ..........................................20
5.9. Possible Complication: Router or Middlebox-Based
ACK Mechanisms ............................................21
5.10. Possible Complication: Data-Limited Senders ..............21
5.11. Other Issues .............................................22
6. Evaluating ACK Congestion Control ..............................22
6.1. Contention in Wireless Links or in Non-Switched Ethernet ..22
6.2. Keep-Alive and Other Special ACK Packets ..................22
7. Measurements of ACK Traffic and Congestion .....................23
8. Acknowledgement Congestion Control in DCCP's CCID 2 ............23
9. Security Considerations ........................................24
10. IANA Considerations ...........................................25
11. Conclusions ...................................................26
12. Acknowledgements ..............................................26
Appendix A. Related Work ..........................................27
A.1. ECN-Only Mechanisms .......................................28
A.2. Receiver-Only Mechanisms ..................................28
A.3. Middlebox-Based Mechanisms ................................29
Appendix B. Design Considerations .................................29
B.1. The TCP ACK Ratio Option, or an AckNow Bit in
Data Packets? .............................................29
Normative References ..............................................30
Informative References ............................................30
5.9. Possible Complication: Router or Middlebox-Based
ACK Mechanisms ............................................21
5.10. Possible Complication: Data-Limited Senders ..............21
5.11. Other Issues .............................................22
6. Evaluating ACK Congestion Control ..............................22
6.1. Contention in Wireless Links or in Non-Switched Ethernet ..22
6.2. Keep-Alive and Other Special ACK Packets ..................22
7. Measurements of ACK Traffic and Congestion .....................23
8. Acknowledgement Congestion Control in DCCP's CCID 2 ............23
9. Security Considerations ........................................24
10. IANA Considerations ...........................................25
11. Conclusions ...................................................26
12. Acknowledgements ..............................................26
Appendix A. Related Work ..........................................27
A.1. ECN-Only Mechanisms .......................................28
A.2. Receiver-Only Mechanisms ..................................28
A.3. Middlebox-Based Mechanisms ................................29
Appendix B. Design Considerations .................................29
B.1. The TCP ACK Ratio Option, or an AckNow Bit in
Data Packets? .............................................29
Normative References ..............................................30
Informative References ............................................30
This document describes a congestion control mechanism for acknowledgements (ACKs) to TCP. This mechanism is based on the acknowledgement congestion control in DCCP's CCID 2 ([RFC4340], [RFC4341]), which is a successor to the TCP acknowledgement congestion control mechanism proposed by Balakrishnan, et al. in [BPK97].
本文档描述了TCP确认（ACKs）的拥塞控制机制。该机制基于DCCP的CCID 2中的确认拥塞控制（[RFC4340]，[RFC4341]），它是Balakrishnan等人在[BPK97]中提出的TCP确认拥塞控制机制的继承者。
In this document we use the terminology of senders and receivers, with the sender sending data traffic and the receiver sending acknowledgement traffic in response. In CCID 2's acknowledgement congestion control, specified in Section 6.1 of [RFC4341], the receiver uses an ACK Ratio R reported to it by the sender, sending roughly one ACK packet for every R data packets received. The CCID 2 sender keeps the acknowledgement rate roughly TCP-friendly by monitoring the acknowledgement stream for lost and marked ACK packets and modifying the ACK Ratio accordingly. For every round-trip time (RTT) containing an ACK congestion event (that is, a lost or marked ACK packet), the sender halves the acknowledgement rate by doubling the ACK Ratio; for every RTT containing no ACK congestion event, the sender additively increases the acknowledgement rate through gradual decreases in the ACK Ratio.
在本文档中，我们使用发送方和接收方的术语，发送方发送数据流量，接收方发送确认流量作为响应。在[RFC4341]第6.1节中规定的CCID 2的确认拥塞控制中，接收方使用发送方报告给它的ACK比率R，每接收到R个数据包，发送大约一个ACK包。CCID 2发送方通过监控确认流中丢失和标记的ACK数据包并相应地修改ACK比率，使确认率大致保持TCP友好。对于包含ACK拥塞事件（即，丢失或标记的ACK数据包）的每个往返时间（RTT），发送方通过加倍ACK比率将确认率减半；对于每个不包含ACK拥塞事件的RTT，发送方通过逐渐降低ACK比率来增加确认率。
The goal of this document is to explore a similar congestion control mechanism for acknowledgement traffic for TCP. The assumption is that in some environments with congestion on the reverse path, reducing the sending rate for ACK traffic traversing the congested path can help to reduce the congestion itself. For those environments where the reverse path is congested but where TCP ACK traffic does not appreciably contribute to that aggregate congestion, the goal is for TCP's ACK congestion control to have a minimal negative effect on the performance of the TCP connection.
本文档的目标是探索一种类似的TCP确认流量拥塞控制机制。假设在反向路径上存在拥塞的某些环境中，降低通过拥塞路径的ACK流量的发送速率有助于减少拥塞本身。对于反向路径拥塞但TCP ACK通信量对聚合拥塞影响不大的环境，目标是使TCP的ACK拥塞控制对TCP连接的性能产生最小的负面影响。
Adding acknowledgement congestion control as an option in TCP would require the following:
在TCP中添加确认拥塞控制作为一个选项需要以下几点：
* An agreement from the TCP hosts on the use of ACK congestion control. For the mechanism specified in this document, the TCP hosts would use a new TCP option, the ACK Congestion Control Permitted option.
* TCP主机关于使用ACK拥塞控制的协议。对于本文档中指定的机制，TCP主机将使用一个新的TCP选项，ACK拥塞控制允许选项。
* A mechanism for the TCP sender to detect lost and ECN-marked pure acknowledgement packets.
* TCP发送方检测丢失和ECN标记的纯确认数据包的机制。
* A mechanism for adjusting the ACK Ratio. The TCP sender would adjust the ACK Ratio as specified in Section 6.1.2 of [RFC4341].
* 用于调整确认比率的机制。TCP发送方将按照[RFC4341]第6.1.2节的规定调整ACK比率。
* A method for the TCP sender to inform the TCP receiver of a new value for the ACK Ratio. For the mechanism specified in this document, the TCP sender would use a new TCP option, the ACK Ratio option.
* TCP发送方通知TCP接收方ACK比率的新值的一种方法。对于本文档中指定的机制，TCP发送方将使用一个新的TCP选项，即ACK Ratio选项。
MSS refers to the Maximum Segment Size.
MSS是指最大段大小。
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]中所述进行解释。
This section gives an overview of acknowledgement congestion control for TCP.
本节概述TCP的确认拥塞控制。
---------------------------------------------------------------
TCP Host A Router TCP Host B
(data sender) (data receiver)
---------- ------ ----------
<--- SYN with AckCC Permitted.
SYN/ACK with AckCC Permitted --->
. . .
Data packets --->
<--- one ACK packet
for every two data packets
. . .
Sender detects a lost ACK packet.
Data packet with an ACK Ratio option of 4 --->
<--- one ACK packet
for at most every four data packets
. . .
Sender detects a period with no lost ACK packets.
Data packet with an ACK Ratio option of 3 --->
<--- one ACK packet
for at most every three data packets
---------------------------------------------------------------
---------------------------------------------------------------
TCP Host A Router TCP Host B
(data sender) (data receiver)
---------- ------ ----------
<--- SYN with AckCC Permitted.
SYN/ACK with AckCC Permitted --->
. . .
Data packets --->
<--- one ACK packet
for every two data packets
. . .
Sender detects a lost ACK packet.
Data packet with an ACK Ratio option of 4 --->
<--- one ACK packet
for at most every four data packets
. . .
Sender detects a period with no lost ACK packets.
Data packet with an ACK Ratio option of 3 --->
<--- one ACK packet
for at most every three data packets
---------------------------------------------------------------
Figure 1: Acknowledgement Congestion Control, Host B as the Connection Initiator, for a Connection without ECN
图1：无ECN连接的确认拥塞控制，主机B作为连接启动器
Figure 1 gives an example of acknowledgement congestion control (AckCC) with TCP Host B as the connection initiator.
图1给出了TCP主机B作为连接启动器的确认拥塞控制（AckCC）示例。
During connection initiation, TCP host B sends an ACK Congestion Control Permitted option on its SYN or SYN/ACK packet. This allows TCP host A (now called the sender) to send instructions to TCP host B (now called the receiver) about the ACK Ratio to use in responding to data packets.
在连接启动期间，TCP主机B在其SYN或SYN/ACK数据包上发送ACK拥塞控制允许选项。这允许TCP主机A（现在称为发送方）向TCP主机B（现在称为接收方）发送关于用于响应数据包的ACK比率的指令。
Also during connection initiation, TCP host A sends an ACK Congestion Control Permitted option on its SYN or SYN/ACK packet. In combination with TCP host B's sending of an ACK Congestion Control Permitted option, and with the negotiation of ECN-Capability as specified in [RFC3168], this would allow TCP host B to send its ACK packets as ECN-Capable.
同样在连接启动期间，TCP主机A在其SYN或SYN/ACK数据包上发送ACK拥塞控制允许选项。结合TCP主机B发送ACK拥塞控制允许选项，以及[RFC3168]中规定的ECN能力协商，这将允许TCP主机B以ECN能力发送其ACK数据包。
The TCP receiver starts with an ACK Ratio of two, generally sending one ACK packet for every two data packets received.
TCP接收器以2的ACK比率开始，通常每接收两个数据包发送一个ACK包。
The TCP sender detects a lost or ECN-marked ACK packet from the TCP receiver and sends an ACK Ratio option of four to the receiver. The TCP receiver changes to an ACK Ratio of four, sending one ACK packet for at most four data packets. The TCP sender uses Appropriate Byte Counting and rate-based pacing in responding to these ACK packets.
TCP发送方检测到来自TCP接收方的丢失或带有ECN标记的ACK数据包，并向接收方发送ACK比率选项4。TCP接收器更改为4的ACK比率，最多为4个数据包发送一个ACK数据包。TCP发送方使用适当的字节计数和基于速率的调整来响应这些ACK数据包。
The TCP sender detects a period with no lost ACK packets and sends an ACK Ratio option of three to the TCP receiver. The TCP receiver changes back to an ACK Ratio of three, sending one ACK packet for at most three data packets.
TCP发送方检测没有丢失ACK数据包的时段，并向TCP接收方发送ACK比率选项3。TCP接收器更改回三个ACK比率，最多为三个数据包发送一个ACK数据包。
The goal of the mechanism proposed in this document is to control pure ACK traffic on the path from the TCP data receiver to the TCP data sender. Note that the approach outlined here is an end-to-end one (as is the approach followed by DCCP's CCID 2 [RFC4341]), but it may also take advantage of explicit congestion information from the network, conveyed by ECN [RFC3168], if available. The ECN specification ([RFC3168], see Section 6.1.4) prohibits a TCP receiver from setting the ECT(0) or ECT(1) codepoints in IP packets carrying pure ACKs, but *only* as long as the receiver does *not* implement any form of ACK congestion control. Unlike some of the related work cited in the appendix, in this document we are proposing an end-to-end ACK congestion control mechanism that controls congestion on the reverse path (the path followed by the ACK traffic) by detecting and responding to either marked or dropped ACK packets.
本文提出的机制的目标是控制从TCP数据接收方到TCP数据发送方的路径上的纯ACK流量。请注意，此处概述的方法是端到端的方法（与DCCP的CCID 2[RFC4341]所采用的方法一样），但也可以利用ECN[RFC3168]传输的来自网络的明确拥塞信息（如果可用）。ECN规范（[RFC3168]，见第6.1.4节）禁止TCP接收器在承载纯ACK的IP数据包中设置ECT（0）或ECT（1）码点，但*仅限于*只要接收器*不*实施任何形式的ACK拥塞控制。与附录中引用的一些相关工作不同，在本文档中，我们提出了一种端到端ACK拥塞控制机制，通过检测和响应标记或丢弃的ACK数据包来控制反向路径（ACK流量后面的路径）上的拥塞。
The TCP end-points would negotiate the use of ACK congestion control (AckCC) with a TCP option: the ACK Congestion Control Permitted option. The option number would be allocated by IANA.
TCP端点将通过TCP选项协商ACK拥塞控制（ACKC）的使用：ACK拥塞控制允许选项。选项编号将由IANA分配。
The ACK Congestion Control Permitted option can only be sent on packets that have the SYN bit set. If TCP end-point A receives an ACK Congestion Control Permitted option from TCP end-point B, then the TCP end-points may use ACK congestion control on the pure acknowledgements sent from B to A. This means that TCP end-point A may send ACK Ratio values to TCP end-point B, for TCP end-point B to use on pure acknowledgement packets. Equivalently, if TCP end-point A *does not* receive an ACK Congestion Control Permitted option from TCP end-point B, then TCP end-point A knows not to waste its time detecting lost ACK packets and adjusting and sending the ACK Ratio values.
ACK拥塞控制允许选项只能在设置了SYN位的数据包上发送。如果TCP端点A从TCP端点B接收到ACK拥塞控制允许选项，则TCP端点可以对从B发送到A的纯确认使用ACK拥塞控制。这意味着TCP端点A可以向TCP端点B发送ACK比率值，以便TCP端点B在纯确认数据包上使用。等效地，如果TCP端点A*没有*从TCP端点B接收到ACK拥塞控制允许选项，则TCP端点A知道不要浪费时间检测丢失的ACK数据包以及调整和发送ACK比率值。
If TCP end-point B receives an ACK Congestion Control Permitted option from TCP end-point A, then the TCP end-points may use ACK congestion control on the pure acknowledgements sent from A to B.
如果TCP端点B从TCP端点A接收到ACK拥塞控制允许选项，则TCP端点可以对从A发送到B的纯确认使用ACK拥塞控制。
If TCP end-point B receives an ACK Congestion Control Permitted option from TCP end-point A and also sent an ACK Congestion Control Permitted option to TCP end-point A, and if ECN-Capability has been negotiated, then TCP end-point B can send its pure ACK packets as ECN-Capable.
如果TCP端点B从TCP端点A接收到ACK拥塞控制允许选项，并且还向TCP端点A发送了ACK拥塞控制允许选项，并且如果已协商ECN能力，则TCP端点B可以将其纯ACK数据包作为ECN能力发送。
TCP ACK Congestion Control Permitted Option:
TCP ACK拥塞控制允许选项：
Kind: TBD1
种类：TBD1
+-----------+-----------+
| Kind=TBD1 | Length=2 |
+-----------+-----------+
+-----------+-----------+
| Kind=TBD1 | Length=2 |
+-----------+-----------+
When ACK congestion control is used, the default initial ACK Ratio is two, with the receiver acknowledging at least every other data packet.
当使用ACK拥塞控制时，默认的初始ACK比率为2，接收机至少每隔一个数据包确认一次。
The sender uses an ACK Ratio TCP option to communicate the ACK Ratio value from the sender to the receiver.
发送方使用ACK Ratio TCP选项将ACK Ratio值从发送方传递给接收方。
TCP ACK Ratio Option:
TCP确认比率选项：
Kind: TBD2
种类：TBD2
+-----------+-----------+-----------+
| Kind=TBD2 | Length=3 | ACK Ratio |
+-----------+-----------+-----------+
+-----------+-----------+-----------+
| Kind=TBD2 | Length=3 | ACK Ratio |
+-----------+-----------+-----------+
The ACK Ratio option is only sent on data packets. Because TCP uses reliable delivery for data packets, the TCP sender can tell if the TCP receiver has received an ACK Ratio option.
ACK Ratio选项仅在数据包上发送。因为TCP使用可靠的数据包传递，所以TCP发送方可以判断TCP接收方是否收到了ACK Ratio选项。
With an ACK Ratio of R, the receiver should send one pure ACK for every R newly received data packets unless the delayed ACK timer expires first. A receiver could simply maintain a counter that increments by one for each new data packet received, and send an ACK packet when the counter reaches R. The receiver would reset the counter to zero whenever a pure or piggybacked ACK is sent.
在ACK比率为R的情况下，除非延迟的ACK定时器首先到期，否则接收机应为每R个新接收的数据分组发送一个纯ACK。接收器可以简单地为接收到的每个新数据包维护一个递增1的计数器，并在计数器到达R时发送一个ACK数据包。每当发送纯数据包或背载数据包时，接收器将计数器重置为零。
If the receiver has buffer limitations, the receiver might have to acknowledge K packets, for some K less than the current ACK Ratio R. In this case, the sender could observe from the acknowledgements that the receiver is acknowledging less than R packets.
如果接收器有缓冲区限制，接收器可能必须确认K个数据包，其中一些K小于当前确认比率R。在这种情况下，发送方可以从确认中观察到接收器确认的数据包少于R个。
It is possible for there to be lost or marked ACK packets when there haven't yet been any lost or marked data packets. Thus, the sender could increase the ACK Ratio R even during the initial slow-start.
当还没有任何丢失或标记的数据包时，可能存在丢失或标记的ACK数据包。因此，即使在初始慢启动期间，发送方也可以增加ACK比率R。
[RFC5681] recommends that the receiver SHOULD acknowledge out-of-order data packets immediately, sending an immediate duplicate ACK when it receives a data segment above a gap in the sequence space, and sending an immediate ACK when it receives a data segment that fills in all or part of a gap in the sequence space.
[RFC5681]建议接收器应立即确认无序数据包，当其接收到序列空间中间隙上方的数据段时，立即发送重复ACK，当其接收到填充序列空间中间隙全部或部分的数据段时，立即发送ACK。
When ACK congestion control is being used and the ACK Ratio is at most two, the TCP receiver acknowledges each out-of-order data packet immediately. For an ACK Ratio greater than two, Section 4.6 specifies in detail the receiver's behavior for sending ACKs for out-of-order data packets.
当使用ACK拥塞控制且ACK比率最多为2时，TCP接收器立即确认每个无序数据包。对于大于2的ACK比率，第4.6节详细规定了接收器发送无序数据包ACK的行为。
The TCP data sender uses its knowledge of the ACK Ratio in use by the receiver to infer when an ACK packet has been lost.
TCP数据发送方使用其对接收方使用的ACK比率的了解来推断ACK数据包何时丢失。
Because the TCP sender knows the ACK Ratio R in use by the receiver, the TCP sender knows that in the absence of dropped or reordered acknowledgement packets, each new acknowledgement received will acknowledge at most R additional data packets. Thus, if the sender receives an acknowledgement acknowledging more than R data packets, and does not receive a subsequent acknowledgement acknowledging a strict subset (with a smaller cumulative acknowledgement, or with the same cumulative acknowledgement but a strict subset of data acknowledged in selective acknowledgement (SACK) blocks), then the sender can infer that an ACK packet has been dropped. The use of SACK options in ACK packets would help the sender in detecting lost ACK packets.
因为TCP发送方知道接收方使用的ACK比率R，所以TCP发送方知道，在没有丢弃或重新排序的确认数据包的情况下，接收到的每个新确认将最多确认R个附加数据包。因此，如果发送方接收到确认多于R个数据分组的确认，并且没有接收到确认严格子集的后续确认（具有较小的累积确认，或者具有相同的累积确认，但是在选择性确认（SACK）块中确认的数据的严格子集），然后发送方可以推断ACK数据包已被丢弃。在ACK数据包中使用SACK选项将有助于发送方检测丢失的ACK数据包。
Similarly, the TCP sender knows that in the absence of dropped or delayed data packets from the sender, and in the absence of delayed acknowledgements due to a timer expiring at the receiver, each new pure acknowledgement received will acknowledge at least R additional data packets. In terms of ACK congestion control, the TCP sender does not have to take any actions when it receives an acknowledgement acknowledging less than R additional packets.
类似地，TCP发送方知道，在没有来自发送方的丢弃或延迟的数据分组的情况下，并且在没有由于定时器在接收机处过期而导致的延迟确认的情况下，接收到的每个新的纯确认将确认至少R个额外的数据分组。在ACK拥塞控制方面，TCP发送方在收到确认少于R个额外数据包的确认时不必采取任何行动。
Out-of-order data packets:
无序数据包：
If the ACK Ratio is at most two, then the TCP receiver sends a duplicate acknowledgement (DupACK) for every out-of-order data packet. In this case, the TCP sender should be able to detect lost DupACK packets by counting the number of DupACKs that arrive between the beginning of the loss event and the arrival of the first full or partial ACK, and comparing this number with the number of DupACKs that should have arrived (based on the number of packets being ACKed by the full or partial ACK). Simulations and/or experiments will be needed to determine whether, in practice, it works for the TCP sender to assess lost ACK packets during loss events, for an ACK Ratio of at most two.
如果ACK比率最多为2，则TCP接收器为每个无序数据包发送重复确认（DupACK）。在这种情况下，TCP发送方应该能够通过计算在丢失事件开始和第一个完整或部分ACK到达之间到达的DupACK数量，并将该数量与应该到达的DupACK数量进行比较，来检测丢失的DupACK数据包（基于全部或部分ACK确认的数据包数量）。需要进行模拟和/或实验，以确定TCP发送方在丢失事件期间评估丢失的ACK数据包（ACK比率最多为2）在实践中是否有效。
If the ACK Ratio is greater than two, the TCP receiver does not send a DupACK for every out-of-order data packet, as specified in Section 4.6. For simplicity, the TCP sender does not attempt to detect lost ACK packets during loss events involving forward-path data traffic. That is, as soon as the sender infers a packet loss for a forward-path data packet, it stops detection of ACK loss on the reverse path. The sender waits until a new cumulative acknowledgement is received that covers the retransmitted data, and then restarts detection of ACK loss for reverse-path traffic.
如果ACK比率大于2，TCP接收器不会按照第4.6节的规定，为每个无序数据包发送一个DupACK。为简单起见，TCP发送方在涉及前向路径数据流量的丢失事件期间不尝试检测丢失的ACK数据包。也就是说，一旦发送方推断出前向路径数据分组的分组丢失，它就停止检测反向路径上的ACK丢失。发送方等待直到接收到覆盖重传数据的新累积确认，然后重新启动反向路径通信的ACK丢失检测。
Detecting lost ACK packets after changes in the ACK Ratio:
在ACK比率发生变化后检测丢失的ACK数据包：
In detecting lost ACK packets, the sender relies on its knowledge of the ACK Ratio used by the receiver. But when the sender makes a change in the ACK Ratio and then receives ACK packets, how does the sender know whether the receiver was using the new or the old ACK Ratio when it sent those ACK packets? As specified in the next section, the sender can make only one of two possible changes to the ACK Ratio within one round-trip time. The sender can decrease the ACK Ratio by one, from R to R-1, or the sender can double the ACK Ratio, increasing it from R to 2R. But, in detecting lost ACK packets after an increase in the ACK Ratio, the sender needs to know whether the receiver was using the old ACK Ratio R or the new ACK Ratio 2R.
在检测丢失的ACK数据包时，发送方依赖于其对接收方使用的ACK比率的了解。但是，当发送方改变ACK比率，然后接收ACK数据包时，发送方如何知道接收方在发送这些ACK数据包时使用的是新的还是旧的ACK比率？如下一节所述，发送方只能在一个往返时间内对ACK比率进行两种可能的更改中的一种。发送方可以将ACK比率减少1，从R减少到R-1，或者发送方可以将ACK比率增加一倍，从R增加到2R。但是，在ACK比率增加之后检测丢失的ACK分组时，发送方需要知道接收机是使用旧的ACK比率R还是新的ACK比率2R。
The sender sends ACK Ratio options only on data packets, and these data packets are acknowledged by the receiver. One possibility would be for the sender to save the sequence number of the last data packet that contained an ACK Ratio option and to remember whether that ACK Ratio option was for an increase or a decrease in the ACK Ratio. Then, if the sender receives an ACK packet acknowledging the saved sequence number, the sender knows that the receiver has begun using the new ACK Ratio.
发送方仅在数据包上发送ACK比率选项，这些数据包由接收方确认。一种可能性是发送方保存包含ACK比率选项的最后一个数据分组的序列号，并记住该ACK比率选项是用于增加还是减少ACK比率。然后，如果发送方接收到确认保存的序列号的ACK分组，则发送方知道接收方已经开始使用新的ACK比率。
It *might* be sufficient for the sender just to save the information of whether the last change in the ACK Ratio was an increase or a decrease, without saving the sequence number associated with the last ACK Ratio option. In this way, if the sender recently increased the ACK Ratio from R to 2R, the sender could be more cautious in detecting lost ACK packets. Another possibility would be that, after sending an ACK Ratio option, the sender waits until that data has been ACKed, with the new ACK Ratio in use by the receiver, before resuming the detection of lost ACK packets. However, we do not explore either of these approaches in more detail in this document.
发送方只保存确认比率的最后更改是增加还是减少的信息*可能*就足够了，而不保存与最后确认比率选项相关联的序列号。这样，如果发送方最近将ACK比率从R增加到2R，则发送方在检测丢失的ACK分组时可以更加谨慎。另一种可能性是，在发送ACK Ratio选项之后，发送方等待直到该数据已被确认，并且接收方正在使用新的ACK Ratio，然后才恢复对丢失的ACK分组的检测。但是，在本文档中，我们不会更详细地探讨这两种方法。
After a sender's retransmit timeout or fast retransmit, the sender might retransmit a number of data packets dropped from a single window of data. In particular, during a loss recovery period (from the sender's detection of the congestion event up until the sender receives an acknowledgement of all data packets transmitted before the loss recovery period began), retransmitted data packets can fill holes in the receiver's sequence space, resulting in irregular jumps in the cumulative acknowledgement field in ACK packets from the receiver. These jumps in the cumulative acknowledgement field make it difficult for the sender to reliably detect lost ACK packets during a loss recovery period.
在发送方的重传超时或快速重传之后，发送方可能重传从单个数据窗口丢弃的多个数据包。特别地，在丢失恢复期间（从发送方检测到拥塞事件直到发送方接收到在丢失恢复期间开始之前发送的所有数据分组的确认），重传的数据分组可以填充接收机序列空间中的孔，导致来自接收器的ACK分组中的累积确认字段出现不规则跳跃。累积确认字段中的这些跳跃使得发送方难以在丢失恢复期间可靠地检测丢失的ACK分组。
Because of this uneven progress of the cumulative acknowledgement field during a loss recovery period, the sender should not attempt to detect lost ACK packets during a loss recovery period. As a consequence, the sender will not increase the ACK Ratio in response to ACK packets that are lost during a loss recovery period.
由于在丢失恢复期间累积确认字段的这种不均匀进展，发送方不应在丢失恢复期间尝试检测丢失的ACK分组。因此，发送方不会响应于在丢失恢复期间丢失的ACK分组而增加ACK比率。
The TCP sender will adjust the ACK Ratio as specified in Section 6.1.2 of [RFC4341], as follows.
TCP发送方将按照[RFC4341]第6.1.2节的规定调整ACK比率，如下所示。
The ACK Ratio always meets the following three constraints.
确认比率始终满足以下三个约束条件。
(1) The ACK Ratio is an integer.
(1) 确认比率是一个整数。
(2) The minimum ACK sending rate: The ACK Ratio does not exceed max(2, cwnd/(K*MSS)), rounded up, for K=2. As a result, the TCP receiver generally sends at least two ACKs in response to a window of at least four full-sized segments.
(2) 最小ACK发送速率：当K=2时，ACK比率不超过最大值（2，cwnd/（K*MSS）），向上舍入。结果，TCP接收器通常发送至少两个ack以响应至少四个全尺寸段的窗口。
(3) If the congestion window is at least as large as four full-sized segments, then the ACK Ratio is at least two. In other words, an ACK Ratio of one is only allowed when the congestion window is at most three full-sized segments.
(3) 如果拥塞窗口至少与四个全尺寸段一样大，则ACK比率至少为两个。换句话说，只有当拥塞窗口最多为三个全尺寸段时，才允许ACK比率为1。
The sender changes the ACK Ratio within those constraints as follows.
发送方在这些约束内更改ACK比率，如下所示。
For each congestion window of data with lost or marked ACK packets, the ACK Ratio R is doubled; for each cwnd/(MSS*(R^2 - R)) consecutive congestion windows of data with no lost or marked ACK packets, the ACK Ratio is decreased by 1. (See Appendix A of RFC 4341 for the derivation. Note that Appendix A of RFC 4341 assumes a congestion window W in packets, while we use cwnd in bytes.) As stated in the previous section, when the ACK Ratio is greater than two, the sender does not attempt to detect lost ACK packets during loss events for forward-path traffic.
对于具有丢失或标记的ACK分组的数据的每个拥塞窗口，ACK比率R加倍；对于没有丢失或标记的ACK数据包的数据的每个cwnd/（MSS*（R^2-R））连续拥塞窗口，ACK比率减少1。（有关推导过程，请参见RFC 4341的附录A。请注意，RFC 4341的附录A假设拥塞窗口为W（以数据包为单位），而我们使用cwnd（以字节为单位）。如前一节所述，当ACK比率大于2时，发送方不会在前向路径流量的丢失事件期间尝试检测丢失的ACK数据包。
For a constant congestion window, these modifications to the ACK Ratio give an ACK sending rate that is roughly TCP-friendly. Of course, cwnd usually varies over time; the dynamics will be rather complex, but roughly TCP friendly. We recommend that the sender determines when to decrease the ACK Ratio by one (i.e., by calculating the number of in-order data packets to count) right after an ACK loss event.
对于恒定的拥塞窗口，这些对ACK比率的修改给出的ACK发送速率大致上是TCP友好的。当然，cwnd通常随时间而变化；动态将相当复杂，但大致上对TCP友好。我们建议发送方在ACK丢失事件之后立即确定何时将ACK比率降低1（即，通过计算要计数的顺序数据包的数量）。
The frequency of ACK Ratio negotiations:
ACK比率协商的频率：
The sender need not keep the ACK Ratio completely up to date. For instance, it may rate-limit ACK Ratio renegotiations to once every four or five round-trip times, or to once every second or two. The sender should not attempt to change the ACK Ratio more than once per round-trip time. In particular, before sending a packet with a new value for the ACK Ratio, the sender should verify that the receiver has acknowledged a data packet containing an ACK Ratio option for the old value of the ACK Ratio. Additionally, the sender may enforce a minimum ACK Ratio of two, or it may set the ACK Ratio to one for half-connections with persistent congestion windows of 1 or 2 packets.
发送方不需要使确认比率完全保持最新。例如，它可以将ACK比率重新协商的速率限制为每四或五次往返一次，或每秒或两次一次。发送方每次往返时间不应尝试更改ACK比率超过一次。具体地，在发送具有ACK比率的新值的分组之前，发送方应当验证接收方已经确认了包含ACK比率的旧值的ACK比率选项的数据分组。此外，发送方可以强制实施最小ACK比率2，或者对于具有1或2个分组的持续拥塞窗口的一半连接，发送方可以将ACK比率设置为1。
The minimum ACK sending rate:
最小ACK发送速率：
From rule (2) above, the TCP receiver always sends at least K=2 ACKs for a window of data, even in the face of very heavy congestion on the reverse path. We would note, however, that if congestion is sufficiently heavy, all the ACK packets are dropped, and then the sender falls back on an exponentially backed-off timeout. Thus, if congestion is sufficiently heavy on the reverse path, then the sender reduces its sending rate on the forward
根据上面的规则（2），TCP接收器总是为一个数据窗口发送至少K=2个ACK，即使在反向路径上遇到非常严重的拥塞时也是如此。然而，我们会注意到，如果拥塞足够严重，那么所有的ACK数据包都会被丢弃，然后发送方会返回到指数级后退超时。因此，如果反向路径上的拥塞足够严重，那么发送方将降低正向路径上的发送速率
path, which reduces the rate on the reverse path as well. One possibility would be to use a higher minimum ACK-sending rate, adding a constant upper bound on the ACK Ratio. That is, if the ACK Ratio also had an upper bound of J, independent of cwnd, then the receiver would always send at least one ACK for every J data packets, regardless of the level of congestion on the reverse path.
路径，这也会降低反向路径上的速率。一种可能是使用更高的最小ACK发送速率，在ACK比率上增加一个恒定的上限。也就是说，如果ACK比率也具有独立于cwnd的J的上界，则接收器将始终为每J个数据分组发送至少一个ACK，而不管反向路径上的拥塞程度如何。
4.5.1. Possible Addition: Decreasing the ACK Ratio after a Congestion Window Decrease
4.5.1. 可能的添加：在拥塞窗口减少后降低ACK比率
After a lost or ECN-marked data packet, the data sender halves the congestion window, thus halving the sending rate for data packets, while making no change to the ACK Ratio R. As a result, after a congestion event involving a data packet, the sending rate for ACK packets on the return path is also halved. If the congestion event was a lost or ECN-marked data packet, this was due to congestion on the forward path, which may have been unrelated to conditions on the reverse path. Thus, it has been suggested that the sender could decrease the ACK Ratio R when it halves the congestion window; in this case, the halving of the sending rate for data packets would not be accompanied by a halving of the sending rate for ACK packets also.
在丢失或带有ECN标记的数据包之后，数据发送方将拥塞窗口减半，从而使数据包的发送速率减半，同时不改变ACK比率R。因此，在涉及数据包的拥塞事件之后，返回路径上ACK包的发送速率也减半。如果拥塞事件是丢失的或带有ECN标记的数据包，这是由于前向路径上的拥塞造成的，这可能与反向路径上的条件无关。因此，有人建议，当发送方将拥塞窗口减半时，发送方可以降低ACK比率R；在这种情况下，数据分组的发送速率减半不会伴随ACK分组的发送速率减半。
However, there are a few cases where a congestion event involving data packets could in fact have been caused by congestion on the reverse path. As one example, the path could include a congested multiaccess link where forward-path and reverse-path traffic can interfere with each other. Thus, in this case it might be desirable if a congestion event resulted in a reduction in the sending rate of ACK packets as well as of data packets.
然而，在少数情况下，涉及数据包的拥塞事件实际上可能是由反向路径上的拥塞引起的。例如，该路径可以包括拥塞的多址链路，其中前向路径和反向路径业务可以相互干扰。因此，在这种情况下，如果拥塞事件导致ACK分组以及数据分组的发送速率降低，则可能是期望的。
As a second example of a congestion event involving congestion of the reverse path, a congestion event could be caused not by a dropped or ECN-marked data packet, but by a window of dropped ACK packets, resulting in a retransmit timeout at the data sender. After a retransmit timeout, the TCP sender will slow-start, reducing the congestion window to the initial window and setting the ACK Ratio to at most two.
作为涉及反向路径的拥塞的拥塞事件的第二示例，拥塞事件可能不是由丢弃的或带有ECN标记的数据分组引起的，而是由丢弃的ACK分组的窗口引起的，从而导致数据发送方处的重传超时。在重新传输超时后，TCP发送方将减慢启动速度，将拥塞窗口减少到初始窗口，并将ACK比率设置为最多两个。
Until further investigation, the sender will not decrease the ACK Ratio as a result of a congestion event involving a data packet.
在进一步调查之前，发送方不会由于涉及数据分组的拥塞事件而降低ACK比率。
RFC 5681 says that "a TCP receiver SHOULD send an immediate duplicate ACK when an out-of-order segment arrives". After three duplicate ACKs are received, the TCP sender infers a packet loss and implements
RFC5681说“当出现故障的段到达时，TCP接收器应立即发送一个重复的ACK”。在收到三个重复的ACK后，TCP发送方推断出一个数据包丢失并执行
fast retransmit and fast recovery, retransmitting the missing packet. When the ACK Ratio is at most two, the TCP receiver should still send an immediate duplicate ACK when an out-of-order segment arrives.
快速重传和快速恢复，重传丢失的数据包。当ACK比率最多为2时，当出现故障的段到达时，TCP接收器仍应立即发送重复ACK。
In general, when the ACK Ratio is greater than two, the TCP receiver still should send an immediate duplicate ACK for each of the first three out-of-order segments that arrive in a reordering event. (We define a reordering event at the receiver as beginning when an out-of-order segment arrives, and ending when the receiver holds no more out-of-order segments.) However, when the ACK Ratio is greater than two, after the first three duplicate ACKs have been sent, the TCP receiver should perform ACK congestion control on the remaining ACKs to be sent during the current reordering event. That is, after the first three duplicate ACKs have been sent, the TCP receiver should return to sending an ACK for every R segments, instead of sending an ACK for every out-of-order segment in that reordering event. (We note that the fast recovery procedure of the TCP sender might have to be modified to take this change into account.) In addition, a receiver must not withhold an ACK for more than 500 ms.
通常，当ACK比率大于2时，TCP接收器仍应立即为在重新排序事件中到达的前三个无序段中的每一个发送重复ACK。（我们将接收器处的重新排序事件定义为当无序段到达时开始，当接收器不再持有无序段时结束。）但是，当ACK比率大于2时，在发送前三个重复ACK之后，TCP接收器应在当前重新排序事件期间对要发送的剩余ACK执行ACK拥塞控制。也就是说，在发送前三个重复的ACK之后，TCP接收器应该返回到为每个R段发送ACK，而不是为该重新排序事件中的每个无序段发送ACK。（我们注意到，可能必须修改TCP发送方的快速恢复过程，以将此更改考虑在内。）此外，接收方保留ACK的时间不得超过500 ms。
We note that in an environment with systematic reordering in the data path (e.g., every set of K data packets arrives in inverted order, for some value of K), the guideline above could result in the receiver sending an ACK for every data packet, regardless of the ACK Ratio. In such an environment with persistent reordering, the receiver may decide not to send an immediate duplicate ACK for each of the first three out-of-order segments that arrive in a reordering event. We leave the investigation of mechanisms for effective ACK congestion control in environments with systematic reordering for future work.
我们注意到，在数据路径中具有系统重新排序的环境中（例如，对于K的某个值，每组K个数据分组以相反的顺序到达），上述准则可导致接收器为每个数据分组发送ACK，而不管ACK比率如何。在这种具有持续重新排序的环境中，接收机可以决定不对在重新排序事件中到达的前三个无序段中的每一个发送立即重复ACK。我们将系统重新排序环境中有效ACK拥塞控制机制的研究留给未来的工作。
The use of a large ACK Ratio can generate line-rate data bursts at a TCP sender. When the ACK Ratio is greater than two, the TCP sender should use some form of burst mitigation or rate-based pacing for sending data packets in response to a single acknowledgement. The use of rate-based pacing will be limited by the timer granularity at the TCP sender.
使用较大的ACK比率可以在TCP发送方生成线速率数据突发。当ACK比率大于2时，TCP发送方应使用某种形式的突发缓解或基于速率的调整来发送数据包以响应单个确认。基于速率的起搏的使用将受到TCP发送方的计时器粒度的限制。
We note that the interaction of ACK congestion control and burst mitigation schemes needs further study.
我们注意到，ACK拥塞控制和突发缓解方案的相互作用需要进一步研究。
Byte counting at the sender:
发送方的字节计数：
In addition to the impact of a large ACK Ratio on the burstiness of the TCP sender's sending rate, a large ACK Ratio can also affect the data-sending rate by slowing down the increase of the
除了较大的ACK比率对TCP发送方发送速率的突发性的影响外，较大的ACK比率还可以通过减缓发送速率的增加来影响数据发送速率
congestion window cwnd. As specified in RFC 5681, in slow-start the TCP sender increases cwnd by one full-sized segment for each new ACK received (in this context, a "new ACK" is an ACK that acknowledges new data). RFC 5681 also specifies that in congestion avoidance, the TCP sender increases cwnd by roughly 1/cwnd full-sized segments for each ACK received, resulting in an increase in cwnd of roughly one full-sized segment per round-trip time. In this case, the use of a large ACK Ratio would slow down the increase of the sender's congestion window.
拥塞窗口cwnd。如RFC 5681中所述，在慢启动中，TCP发送方将接收到的每个新ACK的cwnd增加一个完整大小的段（在此上下文中，“新ACK”是确认新数据的ACK）。RFC 5681还规定，在拥塞避免中，TCP发送方为每个接收到的ACK将cwnd增加约1/cwnd全尺寸段，从而导致cwnd增加约一个全尺寸段/往返时间。在这种情况下，使用较大的ACK比率将减缓发送方拥塞窗口的增加。
RFC 5681 notes that during congestion avoidance, it is also acceptable to count the number of bytes acknowledged by new ACKs and to increase cwnd based on the number of bytes acknowledged, rather than on the number of new ACKs received. Thus, the sender should use this form of byte counting with acknowledgement congestion control, so that the acknowledgement congestion control doesn't slow down the window increases for the data traffic sent by the sender. Because rate-based pacing should be used with acknowledgement congestion control, as recommended earlier in this section, the TCP sender may increase the congestion window by more than two MSS for each ACK.
RFC 5681指出，在避免拥塞期间，也可以计算新ACK确认的字节数，并根据确认的字节数而不是接收到的新ACK数增加cwnd。因此，发送方应使用这种形式的字节计数和确认拥塞控制，以便确认拥塞控制不会减慢发送方发送的数据流量的窗口增加。由于基于速率的起搏应与确认拥塞控制一起使用，如本节前面所建议的，TCP发送方可能会为每个ACK将拥塞窗口增加两个以上的MSS。
We note that for Appropriate Byte Counting (ABC) as specified in [RFC3465], during slow-start the sender is allowed to increase the congestion window by at most two MSS for each ACK. It has not yet been determined whether, with acknowledgement congestion control, the TCP sender could use ABC during slow-start. If ABC is used with acknowledgement congestion control, then when the TCP sender is in slow-start and the ACK Ratio is greater than two, the TCP sender may increase the congestion window by more that two MSS in response to a single ACK. Section 4.2 of [LL07] explores some of the issues with the use of ABC for TCP connections with a fixed ACK Ratio greater than two.
我们注意到，对于[RFC3465]中规定的适当字节计数（ABC），在慢启动期间，允许发送方为每个ACK最多增加两个MSS的拥塞窗口。在确认拥塞控制的情况下，TCP发送方是否可以在慢启动期间使用ABC尚未确定。如果ABC与确认拥塞控制一起使用，则当TCP发送方处于慢启动状态且ACK比率大于2时，TCP发送方可能会响应单个ACK将拥塞窗口增加两个以上的MSS。[LL07]第4.2节探讨了在固定ACK比率大于2的TCP连接中使用ABC的一些问题。
Inferring lost data packets:
推断丢失的数据包：
As cited earlier, RFC 5681 infers that a packet has been lost after it receives three duplicate acknowledgements. Because ACK congestion control is only used when there is congestion on the reverse path, after a packet loss, one or more of the three duplicate ACKs sent by the receiver could be lost on the reverse path, and the receiver might wait until it has received R more out-of-order segments before sending the next duplicate ACK. All this could slow down fast recovery and fast retransmit quite a bit. The use of SACK can help reduce the potential delay in detecting a lost packet. With SACK, a TCP sender can use the information in the SACK option to detect when the receiver has
如前所述，RFC 5681推断一个数据包在收到三个重复确认后丢失。由于ACK拥塞控制仅在反向路径上出现拥塞时使用，因此在数据包丢失后，接收机发送的三个重复ACK中的一个或多个可能会在反向路径上丢失，并且接收机可能会等待，直到接收到更多的无序段，然后再发送下一个重复ACK。所有这些都会大大降低快速恢复和快速重传的速度。SACK的使用有助于减少检测丢失数据包的潜在延迟。有了SACK，TCP发送方可以使用SACK选项中的信息来检测接收方何时收到了SACK
received at least three out-of-order data packets and to initiate fast retransmit and fast recovery in this case, even if the TCP sender has not yet received three duplicate ACKs.
接收到至少三个无序数据包，并在这种情况下启动快速重传和快速恢复，即使TCP发送方尚未收到三个重复的ACK。
It has been suggested that in some environments, the TCP receiver might want to set lower bounds on the ACK Ratio. For example, the TCP receiver might know from configuration or from past experience that the bandwidth on the return path is limited, and might want to set a lower bound (greater than two) on the ACK Ratio R. If this is included, this would require a TCP option from the TCP receiver to the TCP sender, reporting the lower bound on the ACK Ratio. Care would also be needed so that the lower bound on the ACK Ratio was only in effect when the TCP sender's congestion window was sufficiently high.
有人建议，在某些环境中，TCP接收器可能希望设置ACK比率的下限。例如，TCP接收器可能从配置或过去的经验中知道返回路径上的带宽是有限的，并且可能希望在ACK比率R上设置一个下限（大于2）。如果包括这一点，则需要从TCP接收器到TCP发送器的TCP选项，报告ACK比率的下限。还需要注意的是，只有当TCP发送方的拥塞窗口足够大时，ACK比率的下限才有效。
The receiver could send a delayed acknowledgement acknowledging a single packet, even when the ACK Ratio is two or more.
即使在ACK比率为两个或更多的情况下，接收器也可以发送确认单个数据包的延迟确认。
This should not cause false positives (when the TCP sender infers a loss when no loss happened). The TCP sender only infers that a pure ACK packet has been lost when no data packet has been lost and an ACK packet arrives acknowledging more than R new packets.
这不应导致误报（当TCP发送方在未发生丢失的情况下推断出丢失时）。TCP发送方仅在没有数据包丢失且ACK包到达时确认有R个以上的新包时，才推断纯ACK包丢失。
Delayed acknowledgements could, however, cause false negatives, with the TCP sender unable to detect the loss of an ACK packet sent as a delayed acknowledgement. False negatives seem acceptable; this would result in approximate ACK congestion control, which would be better than no ACK congestion control at all. In particular, when this form of false negative occurs, it is because the receiver is sending acknowledgements at such a low rate that it is sending delayed acknowledgements, rather than acknowledging at least R data packets with each acknowledgement.
但是，延迟确认可能会导致误报，TCP发送方无法检测作为延迟确认发送的ACK数据包的丢失。假阴性似乎可以接受；这将导致近似的ACK拥塞控制，这比根本没有ACK拥塞控制要好。特别地，当出现这种形式的假阴性时，这是因为接收机以如此低的速率发送确认，所以它发送延迟确认，而不是用每个确认确认至少确认R个数据分组。
As discussed in Section 4.3, RFC 5681 states that "a TCP receiver SHOULD send an immediate duplicate ACK when an out-of-order segment arrives", and that "a TCP receiver SHOULD send an immediate ACK when the incoming segment fills in all or part of a gap in the sequence space" [RFC5681]. When ACK congestion control is used, the TCP receiver instead uses the guidelines from Section 4.6 to govern the sending of duplicate ACKs. More work would be useful to evaluate the
如第4.3节所述，RFC 5681规定“当无序段到达时，TCP接收器应立即发送重复的ACK”，并且“当传入段填充序列空间中的全部或部分间隙时，TCP接收器应立即发送ACK”[RFC5681]。当使用ACK拥塞控制时，TCP接收器使用第4.6节中的指南来控制重复ACK的发送。更多的工作将有助于评估
advantages and disadvantages of this approach in terms of the potential delay in triggering fast retransmit, and to explore alternate possibilities.
就触发快速重传的潜在延迟而言，这种方法的优点和缺点，并探索替代可能性。
In a TCP connection with two-way traffic, the receiver could send some pure ACK packets and some acknowledgements piggybacked on data packets. The receiver would still follow the rule of only sending a pure ACK packet when there is a need for a delayed ACK or when there are R new data packets to acknowledge.
在具有双向通信的TCP连接中，接收器可以发送一些纯ACK数据包和一些基于数据包的确认。当需要延迟的ACK时或当有R个新的数据分组要确认时，接收机仍将遵循仅发送纯ACK分组的规则。
In a connection with two-way traffic, the TCP sender would not always be able to infer when a pure ACK packet had been lost. For example, the receiver could send a pure ACK packet acknowledging packet K and, soon afterwards, the receiver could send a newly generated data packet for the reverse-path flow also acknowledging packet K. The pure ACK packet could be dropped in the network, and the sender would not be able to detect this drop.
在双向通信的连接中，TCP发送方并不总是能够推断出纯ACK数据包何时丢失。例如，接收机可以发送确认分组K的纯ACK分组，并且不久之后，接收机可以发送也确认分组K的反向路径流的新生成的数据分组。纯ACK分组可以在网络中丢弃，并且发送方将无法检测到该丢弃。
Fortunately, there are limitations to the potential problems caused by undetected ACK losses in two-way traffic. The sender will only fail to detect the loss of a pure ACK packet if the ACK packet was followed by a data packet with the same acknowledgement number. If the reverse-path traffic for the connection is dominated by data traffic, then the congestion control for the data traffic is more important than the congestion control for the pure ACK traffic. If the reverse-path traffic is dominated by pure ACK traffic, then the sender would detect any losses of pure ACK packets followed by other pure ACK packets, and this would include most of the pure ACK packets for that connection. Thus, the sender's failure to detect the loss of a pure ACK packet followed by a data packet with the same acknowledgement number would not disable acknowledgement congestion control for a TCP connection with two-way traffic.
幸运的是，由于双向通信中未检测到的ACK丢失而导致的潜在问题存在局限性。如果ACK数据包后面有一个具有相同确认号的数据包，则发送方仅无法检测到纯ACK数据包的丢失。如果连接的反向路径流量由数据流量控制，那么数据流量的拥塞控制比纯ACK流量的拥塞控制更重要。如果反向路径通信量由纯ACK通信量控制，则发送方将检测到纯ACK分组的任何丢失，随后是其他纯ACK分组，这将包括该连接的大部分纯ACK分组。因此，发送方未能检测到纯ACK数据包随后是具有相同确认号的数据包的丢失，不会禁用具有双向通信量的TCP连接的确认拥塞控制。
It is possible for ACK packets to be reordered on the reverse path. The TCP sender could either use a parallel mechanism to the DupACK threshold to infer when an ACK packet has been lost, as with TCP, or, more robustly, the TCP sender could wait an entire round-trip time before inferring that an ACK packet has been lost [RFC4653].
ACK数据包可以在反向路径上重新排序。TCP发送方可以使用DupACK阈值的并行机制来推断ACK数据包何时丢失，就像TCP一样，或者更可靠地说，TCP发送方可以在推断ACK数据包丢失之前等待整个往返时间[RFC4653]。
What happens when there are abrupt changes in the reverse path, such as from vertical handovers? Can there be any problems that would be worse than those experienced by a TCP connection that is not using ACK congestion control?
当反向路径发生突然变化时会发生什么情况，例如垂直切换？是否存在比不使用ACK拥塞控制的TCP连接遇到的问题更严重的问题？
As with data packets, it is possible for ACK packets to be dropped in the network due to corruption rather than congestion. The current assumption of ACK congestion control is that all losses should be taken as indications of congestion. If there is ever some better mechanism for identifying and responding to corrupted TCP data packets, the same solution hopefully would apply to corrupted ACK packets as well.
与数据包一样，ACK包可能由于损坏而不是拥塞而在网络中丢弃。ACK拥塞控制的当前假设是，所有损失都应视为拥塞的迹象。如果有更好的机制来识别和响应损坏的TCP数据包，同样的解决方案有望也适用于损坏的ACK数据包。
One problem with the interaction of packet corruption and congestion control, for both data and ACK packets, is that it is not always obvious when the packet corruption is related to congestion and when the packet corruption is independent of the level of congestion on the corrupting link. In environments where packet corruption exists and is independent of the level of congestion on the corrupting link, applying ACK congestion control would only make the connection more sensitive to ACK packet corruption by reducing the number of ACKs that are sent.
对于数据和ACK数据包，数据包损坏和拥塞控制的交互作用的一个问题是，当数据包损坏与拥塞相关，并且数据包损坏与损坏链路上的拥塞水平无关时，这并不总是明显的。在存在数据包损坏且与损坏链路上的拥塞级别无关的环境中，应用ACK拥塞控制只能通过减少发送的ACK数量使连接对ACK数据包损坏更加敏感。
It is possible for the ACK packets in a TCP connection to traverse a congested path where ACK packets are dropped but where the ACK packets themselves don't significantly contribute to the congestion on the path. In scenarios where ACK packets are dropped but where ACK traffic doesn't make a significant contribution of the congestion on the path, the use of ACK congestion control would not contribute to reducing the aggregate congestion on the path. In this case, one goal is to minimize the negative impact of ACK congestion control on the overall performance of the TCP connection.
TCP连接中的ACK数据包有可能穿越拥塞路径，在该路径中，ACK数据包被丢弃，但ACK数据包本身对路径上的拥塞没有显著影响。在ACK数据包被丢弃但ACK流量对路径上的拥塞没有显著影响的情况下，使用ACK拥塞控制将不会有助于减少路径上的总拥塞。在这种情况下，一个目标是最小化ACK拥塞控制对TCP连接整体性能的负面影响。
J TCP conns. link L -> J TCP conns.
data -> |---| |---| <- ACKs
<-------------> | | | | <------------->
| | <-------------> | |
<-------------> | | | | <------------->
K TCP conns. |---| |---| K TCP conns.
ACKs -> <- link L1 <- data
J TCP conns. link L -> J TCP conns.
data -> |---| |---| <- ACKs
<-------------> | | | | <------------->
| | <-------------> | |
<-------------> | | | | <------------->
K TCP conns. |---| |---| K TCP conns.
ACKs -> <- link L1 <- data
Figure 2. A Scenario with J Forward and K Reverse TCP Connections
图2。具有J个正向和K个反向TCP连接的场景
To explore the relative contribution of ACK traffic on congestion, it is useful to consider a simple scenario with a congested unidirectional link L carrying data traffic from J TCP connections (the forward TCP connections) and ACK traffic from K TCP connections (the reverse TCP connections). We assume that all TCP connections have the same round-trip time R and the same data packet size S of 1500 bytes. We further assume that all of the forward TCP connections have the same data packet drop rate p and the same congestion window W, and that all of the reverse TCP connections have the same congestion window W1 and the same ACK packet drop rate p1. (The packet drop rate for data packets is defined as the fraction of arriving data packets that are dropped; similarly, the packet drop rate for ACK packets is the fraction of arriving ACK packets that are dropped.) The J TCP connections each use a bandwidth on link L of 1500*W/R bytes per second, and the K TCP connections, without ACK congestion control, each use a bandwidth on link L of 40*(W1/2)/R bytes per second. This gives a ratio of 75*(J/K)*(W/W1) for TCP data bandwidth to TCP ACK bandwidth on link L. The ratio J/K is the ratio between the number of forward and reverse TCP connections on link L, and could have a wide range of values (e.g., large for an access link from a web server, and small for an access link to a web server). For this scenario, the ratio W/W1 is largely a function of the different levels of congestion on the forward and reverse paths.
为了探讨ACK业务对拥塞的相对贡献，考虑一个简单的场景，拥塞的单向链路L承载来自J TCP连接（转发TCP连接）和来自K TCP连接（反向TCP连接）的ACK业务的数据流量。我们假设所有TCP连接具有相同的往返时间R和相同的数据包大小S（1500字节）。我们进一步假设所有前向TCP连接具有相同的数据分组丢弃率p和相同的拥塞窗口W，并且所有反向TCP连接具有相同的拥塞窗口W1和相同的ACK分组丢弃率p1。（数据包的丢包率定义为丢包的到达数据包的分数；类似地，ACK包的丢包率是丢包的到达ACK包的分数。）J TCP连接在链路L上使用每秒1500*W/R字节的带宽，K TCP连接，在没有ACK拥塞控制的情况下，每个链路在链路L上使用每秒40*（W1/2）/R字节的带宽。这使得链路L上的TCP数据带宽与TCP ACK带宽的比率为75*（J/K）*（W/W1）。比率J/K是链路L上的正向和反向TCP连接数之间的比率，并且可能具有广泛的值范围（例如，对于来自web服务器的访问链路来说大，对于到web服务器的访问链路来说小）。在这种情况下，W/W1比率在很大程度上取决于正向和反向路径上不同程度的拥塞。
To explore the possibilities, we will consider some of the range of congestion control mechanisms for the congested link. First, we consider scenarios where the limitation on the congested path is in the link bandwidth in bytes per second.
为了探索可能性，我们将考虑拥塞链路的拥塞控制机制的一些范围。首先，我们考虑的情况下，拥塞路径的限制是在每秒字节的链路带宽。
Cases (1), (2), (3), (5), and (7) below represent the best scenarios for ACK congestion control, where the fraction of packet drops for TCP ACK packets roughly matches the TCP ACK packets' contribution to congestion. (In several of these cases this is, at best, a rough match because the data packets are a factor in the bandwidth and in the queue limitations, while the TCP ACK packets are only a factor in the queue limitations.) Cases (4) and (8) below represent problematic scenarios where the fraction of packet drops for TCP ACK packets is much higher than the TCP ACK packets' contribution to congestion (in terms of taking space in a congested queue, using scarce CPU cycles at the congested router, or using scarce bandwidth). Case (6) below represents scenarios where ACK congestion control would not be effective because it would not be invoked. In the scenarios in case (6), the fraction of packet drops for TCP ACK packets would be much smaller than the TCP ACK packets' contribution to congestion.
下面的情况（1）、（2）、（3）、（5）和（7）代表了ACK拥塞控制的最佳方案，其中TCP ACK数据包的丢包率大致与TCP ACK数据包对拥塞的贡献相匹配。（在其中一些情况下，这充其量只是粗略匹配，因为数据包是带宽和队列限制的一个因素，而TCP ACK数据包只是队列限制的一个因素。）情况（4）和（8）下面是一些有问题的场景，其中TCP ACK数据包的丢包率远远高于TCP ACK数据包对拥塞的贡献（在拥塞队列中占用空间、在拥塞路由器上使用稀少的CPU周期或使用稀少的带宽）。下面的案例（6）表示由于ACK拥塞控制不会被调用而无效的场景。在情况（6）中的场景中，TCP ACK数据包的丢包率将远小于TCP ACK数据包对拥塞的贡献。
(1) The Drop-Tail queue for link L is measured in packets. In this case, the congested queue can accommodate N packets (regardless of packet size), there is a limitation of both bandwidth in bytes per second and also in queue space in packets, and large data packets and small TCP ACK packets should see similar packet drop rates. Although TCP ACK packets most likely aren't a major factor in the bandwidth limitation, they can be a significant contribution to the limitation of queue space. So, while the packet drop rate for ACK packets could be high in times of congestion, the ACK packets are contributing to that congestion somewhat by using scarce buffer space.
(1) 链路L的丢弃尾队列是以数据包为单位测量的。在这种情况下，拥塞队列可以容纳N个数据包（不管数据包大小），带宽（以字节/秒为单位）和队列空间（以数据包为单位）都有限制，并且大数据包和小TCP ACK数据包应该具有类似的数据包丢弃率。虽然TCP ACK数据包很可能不是带宽限制的主要因素，但它们可能是队列空间限制的重要因素。因此，虽然ACK分组的分组丢弃率在拥塞时可能很高，但是ACK分组通过使用稀缺的缓冲空间在一定程度上导致了拥塞。
(2) The Drop-Tail queue is measured in bytes. In this case, the congested queue can accommodate M bytes of packets, and TCP ACK packets don't make a significant contribution to either the bandwidth limitation or to the limitation in queue space. It is also the case that, in this scenario, even if there is heavy congestion, the packet drop rate for TCP ACK packets should be small (because small ACK packets can often find space on the congested queue when large data packets can't find space). In this case, ACK congestion control should not present any problems; the TCP ACK packets aren't contributing significantly to congestion and aren't experiencing significant packet drop rates.
(2) 丢弃尾队列以字节为单位。在这种情况下，拥塞队列可以容纳M字节的数据包，而TCP ACK数据包对带宽限制或队列空间限制都没有显著影响。在这种情况下，即使存在严重拥塞，TCP ACK数据包的丢包率也应该很小（因为当大数据包找不到空间时，小ACK数据包通常可以在拥塞队列上找到空间）。在这种情况下，ACK拥塞控制不应该出现任何问题；TCP ACK数据包对拥塞没有显著影响，也没有显著的数据包丢失率。
(3) The RED queue is in packet mode and is measured in packets. This is similar to case (1) above. Because the queue is measured in packets, small TCP ACK packets contribute to the limitation in queue space but not to the limitation in link bandwidth. Because the queue is in packet mode, large data packets and small TCP ACK packets should see similar packet drop rates.
(3) 红色队列处于数据包模式，以数据包为单位进行测量。这与上述情况（1）类似。因为队列是以数据包为单位度量的，所以较小的TCP ACK数据包会导致队列空间的限制，但不会导致链路带宽的限制。因为队列处于数据包模式，所以大数据包和小TCP ACK包应该看到类似的数据包丢弃率。
(4) The RED queue is in packet mode but is measured in bytes. Because the queue is measured in bytes, small TCP ACK packets don't contribute significantly to either the limitation in queue space or to the limitation in link bandwidth. Because the queue is in packet mode, large data packets and small TCP ACK packets should see similar packet drop rates. If it existed, this case would be problematic, because the TCP ACK packets would not be contributing significantly to the congestion but they would see a similar packet drop rate as the large data packets that are contributing to congestion.
(4) 红色队列处于数据包模式，但以字节为单位。因为队列是以字节为单位测量的，所以较小的TCP ACK数据包对队列空间的限制或链路带宽的限制都没有显著影响。因为队列处于数据包模式，所以大数据包和小TCP ACK包应该看到类似的数据包丢弃率。如果存在，这种情况将是有问题的，因为TCP ACK数据包不会对拥塞产生显著影响，但它们会看到与导致拥塞的大数据包类似的丢包率。
(5) The RED queue is in byte mode and is measured in bytes. This is similar to case (2) above. Because the queue is measured in bytes, small TCP ACK packets don't contribute significantly to either the limitation in queue space or to the limitation in link
(5) 红色队列处于字节模式，以字节为单位度量。这与上述情况（2）类似。因为队列是以字节为单位测量的，所以较小的TCP ACK数据包对队列空间的限制或链路的限制都没有显著影响
bandwidth. At the same time, because the queue is in byte mode, small TCP ACK packets see much smaller packet drop rates than those of large data packets.
带宽。同时，由于队列处于字节模式，小TCP ACK数据包的丢包率比大数据包的丢包率小得多。
(6) The RED queue is in byte mode but is measured in packets. Because the queue is measured in packets, small TCP ACK packets contribute to the limitation in queue space but not to the limitation in link bandwidth. Because the queue is in byte mode, small TCP ACK packets see much smaller packet drop rates than those of large data packets. If this case existed, TCP ACK packets would contribute somewhat to congestion but would see a much smaller packet drop rate than that of large data packets.
(6) 红色队列处于字节模式，但以数据包为单位。因为队列是以数据包为单位度量的，所以较小的TCP ACK数据包会导致队列空间的限制，但不会导致链路带宽的限制。由于队列处于字节模式，小TCP ACK数据包的丢包率比大数据包的丢包率小得多。如果存在这种情况，TCP ACK数据包将在一定程度上造成拥塞，但丢包率将比大数据包小得多。
Next, we consider scenarios where the limitation on the congested link is in CPU cycles at the router in packets per second, not in bandwidth in bytes per second.
接下来，我们考虑的情况下，拥塞链路的限制是在路由器的CPU周期中每秒分组，而不是以每秒字节的带宽。
(7) The CPU load imposed by TCP ACK packets is similar to the load imposed by other packets (e.g., TCP data packets). ACK congestion control would be useful in this scenario, particularly if TCP ACK packets saw the same packet drop rates as TCP data packets.
(7) TCP ACK数据包施加的CPU负载与其他数据包（例如TCP数据包）施加的负载相似。ACK拥塞控制在这种情况下非常有用，特别是当TCP ACK数据包的丢包率与TCP数据包相同时。
(8) The CPU load imposed by TCP ACK packets is much less than the load imposed by other packets (e.g., TCP data packets). If TCP ACK packets saw a smaller packet drop rate than TCP data packets, then the TCP ACK packet drop rate would roughly match the TCP ACK packets' contribution to congestion, and this would be good. If TCP ACK packets saw the same packet drop rate as TCP data packets, this case would be problematic, because the TCP ACK packets would not be contributing significantly to the congestion, but they would see a similar packet drop rate as the large data packets that are contributing to congestion.
(8) TCP ACK数据包施加的CPU负载远小于其他数据包（例如TCP数据包）施加的负载。如果TCP ACK数据包的丢包率小于TCP数据包，那么TCP ACK数据包的丢包率将大致与TCP ACK数据包对拥塞的贡献相匹配，这将是很好的。如果TCP ACK数据包的丢包率与TCP数据包的丢包率相同，则这种情况将是有问题的，因为TCP ACK数据包不会对拥塞产生显著影响，但它们会看到与导致拥塞的大数据包相似的丢包率。
It has been reported in IETF meetings that current TCP implementations do not always acknowledge at least every other data packet, as required by the TCP specifications. In particular, it has been reported that if a TCP receiver receives many data packets in a burst, before it is able to send an acknowledgement, then it might send a single acknowledgement for the burst of packets. We note that such a behavior would cause complications for a TCP connection that used ACK congestion control, as the sender would not be able to determine when an ACK packet had been dropped in the network or when the packet had been skipped by the receiver because it was processing a burst of data packet arrivals.
据IETF会议报告，按照TCP规范的要求，当前的TCP实现并不总是至少确认每个其他数据包。特别地，据报道，如果TCP接收器在能够发送确认之前在突发中接收到许多数据分组，那么它可能会针对分组突发发送单个确认。我们注意到，这种行为将导致使用ACK拥塞控制的TCP连接的复杂性，因为发送方无法确定ACK数据包何时在网络中丢失，或者接收方何时跳过该数据包，因为它正在处理突发数据包到达。
One possibility for addressing this problem would be for TCP receivers using ACK congestion control to be required to send an acknowledgement for each R packets, for ACK Ratio R. In this case, if the receiver received a large burst of data packets back-to-back, the receiver would be required to send a responding burst of ACK packets, one for each set of R data packets.
解决此问题的一种可能性是，使用ACK拥塞控制的TCP接收器需要为每个R数据包发送确认，对于ACK比率R。在这种情况下，如果接收器背对背接收到大量数据包突发，则接收器需要发送应答的ACK数据包突发，每组R数据包一个。
A second possibility for addressing this problem would be to define a TCP option or flag that the TCP receiver could use when sending an ACK packet to inform the sender that the TCP receiver `skipped' some ACK packets, so that the sender should not infer ACK loss if some previous ACK packets seem to be missing.
解决此问题的第二种可能性是定义TCP选项或标志，TCP接收器在发送ACK数据包时可使用该选项或标志通知发送方TCP接收器“跳过”了一些ACK数据包，以便发送方在以前的一些ACK数据包似乎丢失时不应推断ACK丢失。
Future work will explore the costs and benefits of these two approaches.
未来的工作将探讨这两种方法的成本和收益。
One possible complication would be the interaction of ACK congestion control with router-based or middlebox-based ACK mechanisms, such as ACK filtering along the reverse path ([BPK97], [WWCM99], [BA03], [KLS07]). We are not aware of the deployment of ACK filtering in the Internet, but any testing of ACK congestion control would have to look for interactions with any middlebox-based mechanisms regarding ACK packets. In particular, we would consider interactions of ACK congestion control with the possible deployment of ACK filtering on satellite links, cable modems, or the like.
一个可能的复杂性是ACK拥塞控制与基于路由器或基于中间盒的ACK机制的交互，例如沿着反向路径的ACK过滤（[BPK97]、[WWCM99]、[BA03]、[KLS07]）。我们不知道在互联网上部署了ACK过滤，但任何ACK拥塞控制测试都必须寻找与任何基于中间包的机制有关的ACK数据包的交互。特别地，我们将考虑ACK拥塞控制与卫星链路、电缆调制解调器等的ACK滤波的可能部署的相互作用。
The mechanism for adjusting the ACK Ratio is designed with the goal of having the TCP receiver send at least two ACKs in response to each window of at least four full-sized data packets. However, with ACK congestion control in combination with a data-limited sender, it is possible for the sender to send at least four full-sized data packets in a round-trip time, with the receiver sending less than two ACKs in response.
用于调整ACK比率的机制的设计目标是使TCP接收器发送至少两个ACK以响应至少四个全尺寸数据分组的每个窗口。然而，在ACK拥塞控制与数据受限发送方相结合的情况下，发送方可以在往返时间内发送至少四个全尺寸数据分组，而接收方发送少于两个ACK作为响应。
As an example, consider a connection where the sender's congestion window W is greater than four and the ACK Ratio R is at its maximum value of W/2. If the sender becomes data-limited and sends less than W data packets in a round-trip time, then the receiver can send less than two ACK packets in response. This behavior makes the connection more sensitive to the loss of an occasional ACK packet.
作为一个例子，考虑发送方的拥塞窗口W大于四，ACK比率R在其最大值W / 2的连接。如果发送方变得数据受限并且在往返时间内发送少于W个数据分组，则接收方可以发送少于两个ACK分组作为响应。此行为使连接对偶尔的ACK数据包丢失更敏感。
Of course, there is still the safety mechanism of the receiver sending an ACK packet when the delayed ACK timer expires. However, more work would be useful to explore the conflicting goals of a
当然，当延迟的ACK定时器到期时，仍然存在接收机发送ACK分组的安全机制。然而，更多的工作将有助于探索冲突的目标
congestion-controlled ACK flow and a timely ACK response to the sender for the specific case of a connection with a data-limited sender and a congested ACK path.
拥塞控制的ACK流和针对与数据受限的发送方和拥塞的ACK路径的连接的特定情况对发送方的及时ACK响应。
Are there any problems caused by the combination of two-way traffic and reordering? Or other issues that have not yet been addressed?
双向交通和重新订购是否会造成任何问题？还是其他尚未解决的问题？
Evaluating ACK congestion control will have two components: (1) evaluating the effects of ACK congestion control on an individual TCP connection, and (2) evaluating the effects of ACK congestion control on aggregate traffic (including the effects of ACK congestion control on the aggregate congestion of the path).
评估ACK拥塞控制将包括两个部分：（1）评估ACK拥塞控制对单个TCP连接的影响，（2）评估ACK拥塞控制对聚合流量的影响（包括ACK拥塞控制对路径聚合拥塞的影响）。
The first part, evaluating ACK congestion control on the performance of an individual TCP connection, will have to examine those scenarios where ACK congestion control might help the performance of a TCP connection and those scenarios where the use of ACK congestion control might cause problems.
第一部分，根据单个TCP连接的性能评估ACK拥塞控制，必须检查ACK拥塞控制可能有助于TCP连接性能的场景以及使用ACK拥塞控制可能导致问题的场景。
The second part, evaluating the effects of ACK congestion control on aggregate traffic, should consider scenarios where the use of ACK congestion control helps all of the connections sharing a path by reducing the aggregate congestion on the path. This part should also see if there are scenarios where ACK congestion control causes problems by increasing the burstiness of aggregate traffic or by otherwise changing traffic dynamics.
第二部分，评估ACK拥塞控制对总流量的影响，应该考虑使用ACK拥塞控制来帮助减少路径上的总拥塞的所有连接共享路径的情况。本部分还应了解是否存在ACK拥塞控制通过增加总流量的突发性或通过改变流量动态而导致问题的场景。
One possible benefit of ACK congestion control is that it could reduce contention in wireless links, shared Ethernet, or other environments with contention between forward-path and reverse-path traffic ([AJ03], [KIA07]). At the same time, contention on the shared medium won't necessarily result in dropped ACK packets, and therefore wouldn't necessarily be detected by ACK congestion control.
ACK拥塞控制的一个可能好处是，它可以减少无线链路、共享以太网或具有正向路径和反向路径流量之间争用的其他环境中的争用（[AJ03]、[KIA07]）。同时，共享介质上的争用不一定会导致ACK数据包丢失，因此ACK拥塞控制不一定会检测到。
Some TCP hosts send keep-alive packets when no data or ACK packets have been received over a long period of time [KEEP-ALIVE]. This keep-alive mechanism is not addressed in TCP specifications. However, such keep-alive packets, if used, should not interact with ACK congestion control one way or another. For ACK congestion control, the ACK Ratio is set small enough to allow the receiver to
某些TCP主机在长时间未收到数据或ACK数据包时发送保持活动数据包[保持活动]。TCP规范中没有提到这种保持活动的机制。然而，如果使用这种保持活动的数据包，则不应以这种或那种方式与ACK拥塞控制交互。对于ACK拥塞控制，ACK比率设置得足够小，以允许接收机
generally send at least two ACKs for a window of data. In addition, the receiver uses a delayed ACK timer with the ACK Ratio, always sending an acknowledgement if the delayed ACK timer expires. Thus, ACK congestion control will never cause the receiver to delay indefinitely in sending an acknowledgement for a received data packet.
通常为一个数据窗口发送至少两个ACK。此外，接收机使用具有ACK比率的延迟ACK定时器，如果延迟ACK定时器过期，则始终发送确认。因此，ACK拥塞控制将永远不会导致接收器在发送接收到的数据分组的确认时无限期地延迟。
Some TCP implementations send pure ACK packets as window probes, to solicit an ACK packet from the other end with current window information. Such ACK packets will generally be orthogonal to the ACK congestion control specified in this document.
一些TCP实现将纯ACK数据包作为窗口探测发送，以从另一端请求具有当前窗口信息的ACK数据包。此类ACK分组通常与本文档中指定的ACK拥塞控制正交。
TCP receivers also can send pure ACK packets as window update packets announcing a new value for the receive window, even when the acknowledgement number and SACK options in the ACK packet are not new. The receiver may send window update packets even if the ACK congestion control mechanism would say that it is not time yet to send a pure ACK. The sender will not necessarily be able to detect the loss of a window update ACK packet.
TCP接收器还可以发送纯ACK数据包作为窗口更新数据包，宣布接收窗口的新值，即使ACK数据包中的确认号和SACK选项不是新的。即使ACK拥塞控制机制会说现在还不是发送纯ACK的时候，接收机也可以发送窗口更新分组。发送方不一定能够检测到窗口更新ACK数据包的丢失。
There are a number of studies about the traffic composition on various links in the Internet, reporting the fraction of bandwidth used by TCP data and by TCP ACK traffic [Studies].
关于互联网中各种链路上的流量组成，有许多研究报告了TCP数据和TCP ACK流量所使用的带宽分数[studies]。
Are there any studies that show the relative packet drop rates for TCP data and ACK traffic, for particular links or for particular TCP connections?
是否有任何研究显示TCP数据和ACK流量、特定链路或特定TCP连接的相对丢包率？
Are there any studies of congested links that show the fraction of traffic on the congested link, or in the congested queue, that consist of TCP ACK packets?
是否有任何关于拥塞链路的研究表明拥塞链路上或拥塞队列中由TCP ACK数据包组成的流量比例？
In the transport protocol DCCP [RFC4340], the congestion control mechanism for the CCID 2 profile is based on that of TCP. This section briefly discusses some of the issues that have been addressed in the acknowledgement congestion control already standardized in CCID 2 [RFC4341].
在传输协议DCCP[RFC4340]中，CCID 2配置文件的拥塞控制机制基于TCP。本节简要讨论了CCID 2中已经标准化的确认拥塞控制[RFC4341]中已经解决的一些问题。
Rate-based pacing:
基于速率的起搏：
For CCID 2, RFC 4341 says that "senders MAY use a form of rate-based pacing when sending multiple data packets liberated by a single ACK packet, rather than sending all liberated data packets in a single burst." However, rate-based pacing is not required in CCID 2.
对于CCID 2，RFC 4341指出，“当发送由单个ACK数据包释放的多个数据包时，发送方可以使用基于速率的调整，而不是在单个突发中发送所有释放的数据包。”然而，CCID 2中不需要基于速率的调整。
Increasing the congestion window:
增加拥塞窗口：
For CCID 2, RFC 4341 says that "when cwnd < ssthresh, meaning that the sender is in slow-start, the congestion window is increased by one packet for every two newly acknowledged data packets with ACK Vector State 0 (not ECN-marked), up to a maximum of ACK Ratio/2 packets per acknowledgement. This is a modified form of Appropriate Byte Counting [RFC3465] that is consistent with TCP's current standard (which does not include byte counting), but allows CCID 2 to increase as aggressively as TCP when CCID 2's ACK Ratio is greater than the default value of two. When cwnd >= ssthresh, the congestion window is increased by one packet for every window of data acknowledged without lost or marked packets."
对于CCID 2，RFC 4341指出，“当cwnd<ssthresh时，意味着发送方处于慢启动状态，对于ACK向量状态为0（未标记ECN）的每两个新确认的数据包，拥塞窗口增加一个包，最大ACK比率为每个确认2个包。这是一种适当字节计数的修改形式[RFC3465]符合TCP的当前标准（不包括字节计数），但当CCID 2的ACK比率大于默认值2时，允许CCID 2像TCP一样急剧增加。当cwnd>=ssthresh时，对于没有丢失或标记数据包的已确认数据窗口，拥塞窗口将增加一个数据包。”
What are the sender's incentives to cheat on ACK congestion control? What are the receiver's incentives to cheat? What are the avenues open for cheating?
发送方在ACK拥塞控制上作弊的动机是什么？接收者作弊的动机是什么？作弊的途径有哪些？
As long as ACK congestion control is optional, neither host can be forced to use ACK congestion control if it doesn't want to. So ACK congestion control will only be used if the sender or receiver have some chance of receiving some benefit.
只要ACK拥塞控制是可选的，如果主机不想使用ACK拥塞控制，就不能强制主机使用ACK拥塞控制。因此，只有当发送方或接收方有机会获得某些好处时，才会使用ACK拥塞控制。
As long as ACK congestion control is optional for TCP, there is little incentive for the TCP end nodes to cheat on non-ECN-based ACK congestion control. There is nothing now that requires TCP hosts to use congestion control in response to dropped ACK packets.
只要TCP的ACK拥塞控制是可选的，TCP端节点就不会在基于非ECN的ACK拥塞控制上作弊。现在没有任何东西要求TCP主机使用拥塞控制来响应丢弃的ACK数据包。
What avenues for cheating are opened by the use of ECN-Capable ACK packets? If the end nodes can use ECN to have ACK packets marked rather than dropped, and if the end nodes can then avoid the use of ACK congestion control that goes along with the use of ECN on ACK packets, then the end nodes could have an incentive to cheat. Senders could cheat by not instructing the receiver to use a higher ACK Ratio; the receiver would have a hard time detecting this cheating. Receivers could cheat by not using the ACK Ratio they were instructed to use, but senders could easily detect this cheating. However, receivers could also cheat by not using ACK congestion
通过使用支持ECN的ACK数据包，可以打开哪些欺骗渠道？如果终端节点可以使用ECN来标记而不是丢弃ACK分组，并且如果终端节点随后可以避免使用与在ACK分组上使用ECN一起使用的ACK拥塞控制，则终端节点可能有欺骗的动机。发送方可以通过不指示接收方使用更高的ACK比率进行欺骗；接收者很难发现这种欺骗行为。接收者可以通过不使用指示他们使用的ACK比率进行欺骗，但是发送者可以很容易地检测到这种欺骗。然而，接收机也可以通过不使用ACK拥塞来欺骗
control and still sending ACK packets as ECN-Capable, so ACK congestion control is not a necessary component for receivers to cheat about sending ECN-Capable ACK packets. One question would be whether there is any way for receivers to cheat about sending ECN-Capable ACK packets and not using appropriate ACK congestion control without this cheating being easily detected by the sender.
控制并仍然以支持ECN的方式发送ACK数据包，因此ACK拥塞控制不是接收器欺骗发送支持ECN的ACK数据包的必要组件。一个问题是，接收方是否有办法在发送支持ECN的ACK数据包时进行欺骗，而不使用适当的ACK拥塞控制，而不让发送方轻易检测到这种欺骗。
What about the ability of routers or middleboxes to detect TCP receivers that cheat by inappropriately sending ACK packets as ECN-Capable? The router will only know if the receiver is authorized to send ACK packets as ECN-Capable if the router can see traffic on both the forward and reverse paths and monitored both the SYN and SYN/ACK packets (and was able to read the TCP options in the packet headers). If ACK congestion control has been negotiated, the router will only know if ACK congestion control is being used correctly by the receiver if it can monitor the ACK Ratio options sent from the sender to the receiver. If ACK congestion control is being used, the router will not necessarily be able to tell if ACK congestion control is being used correctly by the sender, because drops of ACK packets might be occurring after the ACK packets have left the router. However, if the router sees the ACK Ratio options sent from the sender, the router will be able to tell if the sender is correctly accounting for those ACK packets that are dropped or ECN-marked on the path from the receiver to the router.
路由器或中间盒通过不适当地发送ACK数据包作为ECN功能来检测欺骗的TCP接收器的能力如何？如果路由器可以看到正向和反向路径上的通信量，并监视SYN和SYN/ACK数据包（并且能够读取数据包头中的TCP选项），则路由器将仅知道接收器是否被授权以ECN能力发送ACK数据包。如果已经协商了ACK拥塞控制，那么路由器只有在能够监控从发送方发送到接收方的ACK比率选项的情况下，才会知道接收方是否正确使用了ACK拥塞控制。如果正在使用ACK拥塞控制，则路由器不一定能够判断发送方是否正确使用了ACK拥塞控制，因为ACK数据包离开路由器后可能会发生丢包。但是，如果路由器看到从发送方发送的ACK比率选项，路由器将能够判断发送方是否正确地说明从接收方到路由器的路径上丢弃或标记的ACK数据包。
No IANA action is needed at this time. If this document was advanced as Experimental or Proposed Standard, then IANA would allocate the option numbers for the two TCP options, the ACK Congestion Control Permitted option, and the ACK Ratio option. In such a case, the following two lines would be added to the TCP Option Numbers registry (maintained by IANA -- http://www.iana.org):
目前无需IANA行动。如果本文件是作为实验性或拟议标准提出的，则IANA将为两个TCP选项分配选项编号，即ACK拥塞控制允许选项和ACK比率选项。在这种情况下，以下两行将添加到TCP选项号注册表（由IANA维护--http://www.iana.org):
Kind Length Meaning Reference
---- ------ --------------------------------- -----------
TBD1 2 ACK Congestion Control Permitted [RFCXXXX]
TBD2 3 ACK Ratio [RFCXXXX]
Kind Length Meaning Reference
---- ------ --------------------------------- -----------
TBD1 2 ACK Congestion Control Permitted [RFCXXXX]
TBD2 3 ACK Ratio [RFCXXXX]
In the absence of TCP option numbers allocated by IANA, experimenters may use the TCP Option Numbers set aside for Experimentation in RFC 4727 [RFC4727]. As stressed in Section 1 of RFC 3692 [RFC3692], the TCP Option Numbers in the experimental range are intended for experimentation and testing and not for wide or general deployments; these option numbers could be in use by other experimentors for other purposes.
在IANA未分配TCP选项号的情况下，实验者可使用RFC 4727[RFC4727]中为实验预留的TCP选项号。正如RFC 3692[RFC3692]第1节所强调的，试验范围内的TCP选项编号用于试验和测试，而不是用于广泛或一般部署；这些选项编号可能被其他实验者用于其他目的。
This document specifies a congestion control mechanism for acknowledgement (ACKs) traffic for TCP and discusses the possible complications. We are deferring a recommendation on the use of this mechanism for TCP until it has been evaluated more fully.
本文档指定了TCP确认（ACKs）流量的拥塞控制机制，并讨论了可能的复杂性。我们将推迟对TCP使用该机制的建议，直到对其进行更全面的评估。
Many thanks for feedback from Mark Allman, Armando Caro, Alfred Hoenes, Ilpoo Jarvinen, Sara Landstrom, Anantha Ramaiah, and Michael Welzl, and for contributed text from Michael Welzl.
非常感谢Mark Allman、Armando Caro、Alfred Hoenes、Ilpoo Jarvinen、Sara Landstrom、Anantha Ramaiah和Michael Welzl的反馈，以及Michael Welzl提供的文字。
There exist several papers dealing with controlling congestion in the reverse path of a TCP connection, especially in the context of networks with bandwidth asymmetry. Some of these proposals require explicit support from routers or middleboxes, whereas others are "pure" end-to-end schemes.
有几篇论文涉及TCP连接反向路径中的拥塞控制，特别是在带宽不对称的网络环境中。其中一些方案需要路由器或中间盒的明确支持，而另一些方案则是“纯”端到端方案。
RFC 3449 [RFC3449] discusses TCP performance problems that arise in TCP connections over asymmetric paths. Section 3 of RFC 3449 describes in detail how congestion on the ACK path can affect overall TCP performance. RFC 3449 also outlines a number of proposed mitigations, including ACK congestion control. The experimental ACK congestion control mechanism discussed in that RFC relies on ECN, with the TCP sender detecting congestion on the ACK path from ECN-marked packets. RFC 3449 also discusses two receiver-based mechanisms, the Window Prediction Mechanism (WPM) [CLP98] and Acknowledgement based on Cwnd Estimation (ACE) [MJW00], for using a dynamic ACK Ratio. RFC 3449 also considers link- and network-layer techniques that address congestion on the upstream path. These include header compression as well as bandwidth management techniques for the upstream link, including ACK filtering and ACK reconstruction.
RFC 3449[RFC3449]讨论了在非对称路径上的TCP连接中出现的TCP性能问题。RFC 3449的第3节详细描述了ACK路径上的拥塞如何影响总体TCP性能。RFC 3449还概述了一些建议的缓解措施，包括ACK拥塞控制。实验性的ACK拥塞控制机制在RFC依赖于ECN的情况下讨论，TCP发送方通过ECN标记的数据包检测ACK路径上的拥塞。RFC 3449还讨论了两种基于接收机的机制，用于使用动态ACK比率的窗口预测机制（WPM）[CLP98]和基于Cwnd估计的确认机制（ACE）[MJW00]。RFC 3449还考虑了解决上行路径拥塞的链路层和网络层技术。这些包括报头压缩以及用于上游链路的带宽管理技术，包括ACK滤波和ACK重构。
RFC 3135 [RFC3135], "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", surveys a range of Performance Enhancing Proxies used to improve TCP behavior, including proxies for ACK filtering and reconstruction. RFC 2760 [RFC2760], "Ongoing TCP Research Related to Satellites", discusses both ACK congestion control and ACK filtering and reconstruction, with detailed descriptions of the mechanisms proposed by Balakrishnan, et al. in [BPK97].
RFC 3135[RFC3135]，“旨在缓解链路相关降级的性能增强代理”，调查了一系列用于改善TCP行为的性能增强代理，包括用于ACK过滤和重建的代理。RFC 2760[RFC2760]，“正在进行的与卫星相关的TCP研究”，讨论了ACK拥塞控制和ACK过滤与重建，详细描述了Balakrishnan等人在[BPK97]中提出的机制。
Landstrom, et al. in [LL07] explore a mechanism where the receiver sends only four acknowledgements per window of data, along with the sender using a form of Appropriate Byte Counting. In addition, the receiver reverts to a lower acknowledgement frequency after a timeout, to avoid unnecessary retransmit timeouts. One conclusion of the paper is that pacing at the sender introduces an additional delay and might not be necessary. A key result of the paper is that, with the use of some form of byte counting at the sender, it is possible for TCP to use a lower acknowledgement frequency than that of delayed acknowledgements.
Landstrom等人在[LL07]中探索了一种机制，其中接收器在每个数据窗口中仅发送四个确认，发送者使用适当的字节计数形式。此外，接收机在超时后恢复到较低的确认频率，以避免不必要的重传超时。论文的一个结论是，在发送者处进行起搏会带来额外的延迟，可能没有必要。本文的一个关键结果是，通过在发送方使用某种形式的字节计数，TCP可以使用比延迟确认更低的确认频率。
Balakrishnan, et al. in [BPK97] describe the use of ECN to detect congestion in the return path, in order to reduce the sending rate of ACKs. The use of a RED queue in the reverse path allows for marking of ACK packets. The sender echoes back ECN congestion marks to the receiver. The receiver keeps an ACK Ratio d (called the "delayed-ACK factor"), specifying the number of data segments that have to be received before the receiver sends a new ACK. The ACK Ratio d is managed using multiplicative-increase, additive-decrease; upon reception of a congestion mark, the receiver doubles the value of d (hence dividing the ACK sending rate by two). The ACK Ratio decreases linearly for each RTT in which no ECN-marked ACKs are received. Multiple congestion marks received in an RTT are treated as a single congestion event, i.e., d can be doubled at most once per RTT. The TCP timestamp option is used to keep track of the RTT values.
Balakrishnan等人在[BPK97]中描述了使用ECN检测返回路径中的拥塞，以降低ACK的发送速率。在反向路径中使用红色队列允许标记ACK数据包。发送方向接收方回显ECN拥塞标记。接收机保持ACK比率d（称为“延迟ACK因子”），指定在接收机发送新ACK之前必须接收的数据段的数量。使用乘法增加、加法减少来管理ACK比率d；在接收到拥塞标记时，接收器将d的值加倍（因此将ACK发送速率除以2）。对于没有接收到ECN标记的ACK的每个RTT，ACK比率线性降低。在RTT中接收到的多个拥塞标记被视为单个拥塞事件，即，每个RTT最多可将d加倍一次。TCP时间戳选项用于跟踪RTT值。
In [MJW00], Tam Ming-Chit, et al. propose a receiver-based method for calculating an "appropriate" number of ACKs per congestion window (cwnd) of data, in order to alleviate congestion on the reverse path. The sender's cwnd is estimated at the receiver by counting the number of received packets per RTT (which also has to be estimated by the receiver). From this estimate, a simple algorithm is used to compute the number of ACKs to be sent per cwnd. The algorithm enforces a lower bound on the number of ACKs per cwnd, aiming at minimizing the probability of timeout at the sender due to ACK loss. Similarly, the ACK Ratio is upper-bounded so as to avoid excessive ACK delay.
在[MJW00]中，Tam Ming Chit等人提出了一种基于接收器的方法，用于计算每个数据拥塞窗口（cwnd）的“适当”ACK数，以缓解反向路径上的拥塞。发送方的cwnd在接收方通过计算每个RTT接收的数据包的数量来估计（接收方也必须估计）。根据该估计，使用一个简单的算法来计算每个cwnd要发送的ACK数。该算法对每个cwnd的ACK数施加一个下限，目的是最小化由于ACK丢失而导致发送方超时的概率。类似地，ACK比率是上界的，以避免过多的ACK延迟。
Blandford, et al. [BGG+07] propose an end-to-end, receiver-oriented scheme called "smartacking". The algorithm is based upon the receiver's monitoring the inter-segment arrival time for data packets and adapting the ACK sending rate in response. When the bottleneck link is underutilized, ACKs are sent frequently (up to one ACK per received segment) to promote fast growth of the congestion window. On the other hand, when the bottleneck is close to full utilization, the algorithm tries to reduce control traffic overhead and slow congestion window growth by generating ACKs at the minimum rate needed to keep the data pipe full.
Blandford等人[BGG+07]提出了一种端到端、面向接收器的方案，称为“smartacking”。该算法基于接收机对数据包的段间到达时间进行监控，并根据响应调整ACK发送速率。当瓶颈链路未充分利用时，会频繁发送ACK（每个接收段最多发送一个ACK），以促进拥塞窗口的快速增长。另一方面，当瓶颈接近完全利用时，该算法试图通过以保持数据管道满所需的最小速率生成ack来减少控制流量开销并减缓拥塞窗口的增长。
Reducing the number of ACKs (or, equivalently, increasing the amount of bytes acknowledged by each ACK) can increase the burstiness of the TCP sender. Hence, any mechanism as those cited above should be coupled with a burst mitigation technique, such as rate-based pacing, that paces the sending of data segments ([AB05], [ASA00], [BPK97]).
减少ACK的数量（或者，等效地，增加每个ACK确认的字节数）可以增加TCP发送方的突发性。因此，如上所述的任何机制都应与突发缓解技术相结合，例如基于速率的起搏，该技术可对数据段的发送进行起搏（[AB05]、[ASA00]、[BPK97]）。
ACK filtering (AF) [BPK97] from Balakrishnan, et al. is a router-based technique that tries to reduce the number of ACKs sent over the congested return link. With AF, an arriving ACK may replace preceding, older ACKs at the bottleneck queue. An aggressive replacement policy might guarantee that at most one ACK per connection is waiting in the queue, alleviating congestion. However, as in other proposals, care must be taken to avoid sender timeouts in case the (too few) ACKs resulting from the filtering get lost. The idea of filtering ACKs has been extended in [YMH03] to deal with SACK information.
Balakrishnan等人提出的ACK过滤（AF）[BPK97]是一种基于路由器的技术，它试图减少通过拥塞的返回链路发送的ACK数量。使用AF，到达的ACK可以替换瓶颈队列中先前的旧ACK。积极的替换策略可以保证每个连接最多有一个ACK在队列中等待，从而缓解拥塞。但是，与其他方案一样，必须注意避免由于过滤导致的（太少的）ack丢失而导致发送方超时。[YMH03]扩展了过滤ack的思想，以处理SACK信息。
Aweya, et al. [AOM02] present a middlebox-based approach for mitigating data packet bursts and for controlling the uplink ACK congestion. The main idea is to perform pacing on ACK segments on an edge device close to the sender, so as to control the ACK arrival rate at the sender.
Aweya等人[AOM02]提出了一种基于中间盒的方法，用于缓解数据包突发和控制上行链路ACK拥塞。其主要思想是在靠近发送方的边缘设备上对ACK段执行起搏，以控制发送方的ACK到达率。
In the ACK congestion control mechanism specified in this document, the sender uses the TCP ACK Ratio option to tell the receiver the ACK Ratio to use. An alternate approach to the TCP ACK Ratio option could be for the sender to use an AckNow bit in the TCP header of data packets, telling the receiver to acknowledge this data packet. In the discussion below, we call these two approaches the TCP ACK Ratio option approach and the AckNow approach.
在本文档中指定的ACK拥塞控制机制中，发送方使用TCP ACK Ratio选项告知接收方要使用的ACK Ratio。TCP ACK Ratio选项的另一种方法是发送方在数据包的TCP报头中使用AckNow位，告知接收方确认该数据包。在下面的讨论中，我们将这两种方法称为TCP确认比率选项方法和AckNow方法。
An advantage of an AckNow approach is that it would require less state from the receiver; the receiver would not need to maintain a variable for the current ACK Ratio and would not need to keep track of the number of data packets un-ACKed to date.
AckNow方法的一个优点是它需要较少的来自接收器的状态；接收机不需要为当前ACK比率维护变量，也不需要跟踪到目前为止未确认的数据包的数量。
However, a disadvantage of the AckNow approach is that the sender does not know when packets will be reordered, delayed, or dropped on the path to the receiver. In particular, the sender does not have control over whether a data packet with the AckNow bit set is reordered, delayed, or dropped in the network. For this reason, we have chosen the approach of the sender determining the ACK Ratio that should be used and sending the ACK Ratio to the receiver, rather than the sender telling the receiver exactly which data packets to acknowledge.
然而，AckNow方法的一个缺点是，发送方不知道数据包在到达接收方的路径上何时被重新排序、延迟或丢弃。具体地说，发送方不能控制具有AckNow位集的数据包在网络中是否被重新排序、延迟或丢弃。因此，我们选择了发送方确定应使用的ACK比率并将ACK比率发送给接收方的方法，而不是发送方确切地告诉接收方要确认哪些数据包。
An additional disadvantage of the AckNow approach is that it would add complications and difficulties for the default cases of the receiver using an ACK Ratio of one or two, as is done in the absence of ACK congestion control.
AckNow方法的另一个缺点是，对于使用一个或两个ACK比率的接收机的默认情况，它将增加复杂性和困难，就像在没有ACK拥塞控制的情况下所做的那样。
For these reasons, we have specified that the sender determines the ACK Ratio to use and tells the receiver, rather than the sender setting an AckNow bit in the TCP Header of selected data packets.
出于这些原因，我们指定发送方确定要使用的ACK比率并告知接收方，而不是发送方在所选数据包的TCP报头中设置AckNow位。
Normative References
规范性引用文件
[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月。
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3465]Allman，M.，“具有适当字节计数的TCP拥塞控制（ABC）”，RFC 3465，2003年2月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006.
[RFC4341]Floyd，S.和E.Kohler，“数据报拥塞控制协议（DCCP）拥塞控制ID 2的配置文件：类似TCP的拥塞控制”，RFC 43412006年3月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727]Fenner，B.，“IPv4、IPv6、ICMPv4、ICMPv6、UDP和TCP报头中的实验值”，RFC 4727，2006年11月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 56812009年9月。
Informative References
资料性引用
[RFC2760] Allman, M., Ed., Dawkins, S., Glover, D., Griner, J., Tran, D., Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann, S., Scott, K., and J. Semke, "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000.
[RFC2760]Allman，M.，Ed.，Dawkins，S.，Glover，D.，Griner，J.，Tran，D.，Henderson，T.，Heidemann，J.，Touch，J.，Kruse，H.，Ostermann，S.，Scott，K.，和J.Semke，“正在进行的与卫星相关的TCP研究”，RFC 27602000年2月。
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
[RFC3135]Border，J.，Kojo，M.，Griner，J.，黑山，G.，和Z.Shelby，“旨在缓解链路相关降级的性能增强代理”，RFC 31352001年6月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, December 2002.
[RFC3449]Balakrishnan，H.，Padmanabhan，V.，Fairhurst，G.，和M.Sooriyabandara，“网络路径不对称的TCP性能影响”，BCP 69，RFC 3449，2002年12月。
[RFC4653] Bhandarkar, S., Reddy, A., Allman, M., and E. Blanton, "Improving the Robustness of TCP to Non-Congestion Events", RFC 4653, August 2006.
[RFC4653]Bhandarkar，S.，Reddy，A.，Allman，M.，和E.Blanton，“提高TCP对非拥塞事件的鲁棒性”，RFC 46532006年8月。
[ASA00] Aggarwal, A., Savage, S., and T. Anderson, "Understanding the Performance of TCP Pacing", INFOCOM (3), pp. 1157-1165, 2000.
[ASA00]Aggarwal，A.，Savage，S.，和T.Anderson，“理解TCP起搏的性能”，INFOCOM（3），第1157-1165页，2000年。
[AB05] Allman, M., and E. Blanton, "Notes on Burst Mitigation for Transport Protocols", SIGCOMM, Computer Communications Review, 35(2):5360, 2005.
[AB05]Allman，M.和E.Blanton，“传输协议的突发缓解注释”，SIGCOM，《计算机通信评论》，35（2）：53602005年。
[AJ03] Altman, E., and T. Jimenez, "Novel Delayed ACK Techniques for Improving TCP Performance in Multihop Wireless Networks", Proc. of the Personal Wireless Communications, 2003.
[AJ03]Altman，E.和T.Jimenez，“改进多跳无线网络中TCP性能的新型延迟ACK技术”，Proc。个人无线通信，2003年。
[AOM02] Aweya, J., Ouellette, M., and D. Y. Montuno, "A Self-regulating TCP Acknowledgement (ack) Pacing Scheme", International Journal of Network Management, 12(3):145163, 2002.
[AOM02]Aweya，J.，Ouellette，M.，和D.Y.Montuno，“自我调节TCP确认（ack）起搏方案”，国际网络管理杂志，12（3）：145163，2002年。
[BA03] Barakat, C., and E. Altman, "On ACK Filtering on a Slow Reverse Channel", International Journal of Satellite Communications and Networking, V.21 N.3, 2003.
[BA03]Barakat，C.和E.Altman，“关于慢反向信道上的ACK过滤”，国际卫星通信和网络杂志，第21卷第3期，2003年。
[BPK97] Balakrishnan, H., Padmanabhan, V., and Katz, R., "The Effects of Asymmetry on TCP Performance", Third ACM/IEEE Mobicom Conference, September 1997.
[BPK97]Balakrishnan，H.，Padmanabhan，V.，和Katz，R.，“不对称对TCP性能的影响”，第三届ACM/IEEE Mobicom会议，1997年9月。
[BGG+07] Blandford, D.K., Goldman, S.A., Gorinsky, S., Zhou, Y., and D.R. Dooly, "Smartacking: Improving TCP Performance from the Receiving End", Journal of Internet Engineering, 1(1), 2007.
[BGG+07]Blandford，D.K.，Goldman，S.A.，Gorinsky，S.，Zhou，Y.，和D.R.Dooly，“Smartacking:从接收端改进TCP性能”，《互联网工程杂志》，2007年第1（1）期。
[CLP98] Calveras, A., Linares, J., and J. Paradells, "Window Prediction Mechanism for Improving TCP in Wireless Asymmetric Links". Proc. IEEE Global Communications Conference (GLOBECOM), Sydney Australia, pp. 533-538, November 1998.
[CLP98]Calveras，A.，Linares，J.，和J.Paradells，“改进无线非对称链路中TCP的窗口预测机制”。过程。IEEE全球通信会议（GLOBECOM），澳大利亚悉尼，第533-538页，1998年11月。
[KIA07] Keceli, F., Inan, I., and E. Ayanoglu, "TCP ACK Congestion Control and Filtering for Fairness Provision in the Uplink of IEEE 802.11 Infrastructure Basic Service Set", Proc. IEEE ICC 2007, June 2007.
[KIA07]Keceli，F.，Inan，I.，和E.Ayanoglu，“IEEE 802.11基础设施基本服务集上行链路中公平性提供的TCP ACK拥塞控制和过滤”，Proc。IEEE ICC 2007，2007年6月。
[KEEP-ALIVE] Busatto, F., "TCP Keepalive HOWTO", May 2007, http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/index.html.
[KEEP-ALIVE]Busatto，F.，“TCP Keepalive HOWTO”，2007年5月，http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/index.html.
[KLS07] Kim, H., Lee, H., and S. Shin, "On the Cross-Layer Impact of TCP ACK Thinning on IEEE 802.11 Wireless MAC Dynamics", IEICE Transactions on Communications, 2007.
[KLS07]Kim，H.，Lee，H.，和S.Shin，“关于TCP ACK细化对IEEE 802.11无线MAC动态的跨层影响”，IEICE通信事务，2007年。
[LL07] Landstrom, S., and Larzon, L.A., "Reducing the TCP Acknowledgement Frequency", SIGCOMM, Computer Communications Review, July 2007.
[LL07]Landstrom，S.和Larzon，L.A.，“降低TCP确认频率”，SIGCOMM，《计算机通信评论》，2007年7月。
[MJW00] Ming-Chit, I.T., Jinsong, D., and W. Wang, "Improving TCP Performance Over Asymmetric Networks", SIGCOMM, Computer Communications Review (CCR), Vol.30, No.3, 2000.
[MJW00]Ming Chit，I.T.，Jinsong，D.，和W.Wang，“在非对称网络上改进TCP性能”，SIGCOMM，计算机通信评论（CCR），第30卷，第3期，2000年。
[Studies] Floyd, S., "Measurement Studies of End-to-End Congestion Control in the Internet", http://www.icir.org/floyd/ccmeasure.html.
[研究]Floyd，S.，“互联网端到端拥塞控制的测量研究”，http://www.icir.org/floyd/ccmeasure.html.
[WWCM99] Wu, H., Wu, J., Cheng, S., and J. Ma, "ACK Filtering on Bandwidth Asymmetry Networks", IEEE Communications, 1999.
[WWCM99]Wu，H.，Wu，J.，Cheng，S.，和J.Ma，“带宽不对称网络上的ACK过滤”，IEEE通信，1999年。
[YMH03] Yu, L., Minhua, Y., and Z. Huimin, "The Improvement of TCP Performance in Bandwidth Asymmetric Network", IEEE PIMRC, 1:482-486, September 2003.
[YMH03]Yu，L.，Minhua，Y.，和Z.Huimin，“带宽不对称网络中TCP性能的改进”，IEEE PIMRC，1:482-486，2003年9月。
Authors' Addresses
作者地址
Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
Sally Floyd ICSI互联网研究中心美国加利福尼亚州伯克利中心街1947号600室，邮编94704
EMail: floyd@icir.org
EMail: floyd@icir.org
Andres Arcia Networking, Security & Multimedia (RSM) Universidad de Los Andes TELECOM Bretagne Facultad de Ingenieria Rue de la Chataigneraie, CS 17607 Nucleo La Hechicera 35576 Cesson Sevigne Cedex Merida, Merida 5101 France Venezuela
安德烈斯·阿尔西亚网络、安全与多媒体（RSM）洛斯安第斯通信大学布列塔尼通信学院，CS 17607 Nucleu la Hechicera 35576 Cesson Sevigne Cedex Merida，梅里达5101法国委内瑞拉
EMail: ae.arcia@telecom-bretagne.eu EMail: amoret@ula.ve
URI: http://www.ula.ve
EMail: ae.arcia@telecom-bretagne.eu EMail: amoret@ula.ve
URI: http://www.ula.ve
David Ros Networking, Security & Multimedia (RSM) Dpt. TELECOM Bretagne Rue de la Chataigneraie, CS 17607 35576 Cesson Sevigne Cedex France
David Ros网络、安全和多媒体（RSM）Dpt。CS 17607 35576法国塞森塞维涅塞德克斯市布列塔尼大道电信公司
EMail: David.Ros@telecom-bretagne.eu
EMail: David.Ros@telecom-bretagne.eu
Janardhan R. Iyengar Math and Computer Science Franklin & Marshall College P. O. Box 3003 Lancaster, PA 17604-3003 USA
Janardhan R.Iyengar数学和计算机科学美国宾夕法尼亚州兰开斯特市富兰克林和马歇尔学院3003信箱17604-3003
EMail: jiyengar@fandm.edu
EMail: jiyengar@fandm.edu