Network Working Group S. Floyd
Request for Comments: 4341 ICIR
Category: Standards Track E. Kohler
UCLA
March 2006
Network Working Group S. Floyd
Request for Comments: 4341 ICIR
Category: Standards Track E. Kohler
UCLA
March 2006
Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control
数据报拥塞控制协议（DCCP）拥塞控制ID 2的配置文件：类似TCP的拥塞控制
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document contains the profile for Congestion Control Identifier 2 (CCID 2), TCP-like Congestion Control, in the Datagram Congestion Control Protocol (DCCP). CCID 2 should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control.
本文档包含数据报拥塞控制协议（DCCP）中类似TCP的拥塞控制标识符2（CCID 2）的配置文件。如果发送方希望在条件快速变化的环境中利用可用带宽，并且能够适应TCP加增乘减（AIMD）拥塞控制典型拥塞窗口的突然变化，则应使用CCID 2。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions and Notation ........................................2
3. Usage ...........................................................3
3.1. Relationship with TCP ......................................3
3.2. Half-Connection Example ....................................4
4. Connection Establishment ........................................5
5. Congestion Control on Data Packets ..............................5
5.1. Response to Idle and Application-Limited Periods ...........8
5.2. Response to Data Dropped and Slow Receiver .................8
5.3. Packet Size ................................................8
6. Acknowledgements ................................................9
6.1. Congestion Control on Acknowledgements .....................9
6.1.1. Detecting Lost and Marked Acknowledgements .........10
1. Introduction ....................................................2
2. Conventions and Notation ........................................2
3. Usage ...........................................................3
3.1. Relationship with TCP ......................................3
3.2. Half-Connection Example ....................................4
4. Connection Establishment ........................................5
5. Congestion Control on Data Packets ..............................5
5.1. Response to Idle and Application-Limited Periods ...........8
5.2. Response to Data Dropped and Slow Receiver .................8
5.3. Packet Size ................................................8
6. Acknowledgements ................................................9
6.1. Congestion Control on Acknowledgements .....................9
6.1.1. Detecting Lost and Marked Acknowledgements .........10
6.1.2. Changing Ack Ratio .................................10
6.2. Acknowledgements of Acknowledgements ......................11
6.2.1. Determining Quiescence .............................12
7. Explicit Congestion Notification ...............................12
8. Options and Features ...........................................12
9. Security Considerations ........................................13
10. IANA Considerations ...........................................13
10.1. Reset Codes ..............................................13
10.2. Option Types .............................................13
10.3. Feature Numbers ..........................................14
11. Thanks ........................................................14
A. Appendix: Derivation of Ack Ratio Decrease ....................15
B. Appendix: Cost of Loss Inference Mistakes to Ack Ratio ........15
Normative References ..............................................17
Informative References ............................................18
6.1.2. Changing Ack Ratio .................................10
6.2. Acknowledgements of Acknowledgements ......................11
6.2.1. Determining Quiescence .............................12
7. Explicit Congestion Notification ...............................12
8. Options and Features ...........................................12
9. Security Considerations ........................................13
10. IANA Considerations ...........................................13
10.1. Reset Codes ..............................................13
10.2. Option Types .............................................13
10.3. Feature Numbers ..........................................14
11. Thanks ........................................................14
A. Appendix: Derivation of Ack Ratio Decrease ....................15
B. Appendix: Cost of Loss Inference Mistakes to Ack Ratio ........15
Normative References ..............................................17
Informative References ............................................18
This document contains the profile for Congestion Control Identifier 2 (CCID 2), TCP-like Congestion Control, in the Datagram Congestion Control Protocol (DCCP) [RFC4340]. DCCP uses Congestion Control Identifiers, or CCIDs, to specify the congestion control mechanism in use on a half-connection.
本文档包含数据报拥塞控制协议（DCCP）[RFC4340]中拥塞控制标识符2（CCID 2）的配置文件，类似于TCP的拥塞控制。DCCP使用拥塞控制标识符（CCID）来指定在半连接上使用的拥塞控制机制。
The TCP-like Congestion Control CCID sends data using a close variant of TCP's congestion control mechanisms, incorporating a variant of selective acknowledgements (SACK) [RFC2018, RFC3517]. CCID 2 is suitable for senders who can adapt to the abrupt changes in congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control, and particularly useful for senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions. See Section 3 for more on application requirements.
类似于TCP的拥塞控制CCID使用TCP拥塞控制机制的近似变体发送数据，包括选择性确认（SACK）的变体[RFC2018，RFC3517]。CCID 2适用于能够适应TCP加性增加乘性减少（AIMD）拥塞控制典型的拥塞窗口突变的发送方，尤其适用于希望在条件快速变化的环境中利用可用带宽的发送方。有关应用程序要求的更多信息，请参见第3节。
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]中所述进行解释。
A DCCP half-connection consists of the application data sent by one endpoint and the corresponding acknowledgements sent by the other endpoint. The terms "HC-Sender" and "HC-Receiver" denote the endpoints sending application data and acknowledgements, respectively. Since CCIDs apply at the level of half-connections, we abbreviate HC-Sender to "sender" and HC-Receiver to "receiver" in this document. See [RFC4340] for more discussion.
DCCP半连接由一个端点发送的应用程序数据和另一个端点发送的相应确认组成。术语“HC发送方”和“HC接收方”分别表示发送应用程序数据和确认的端点。由于CCID适用于半连接级别，因此在本文档中，我们将HC Sender缩写为“Sender”，将HC Receiver缩写为“Receiver”。有关更多讨论，请参阅[RFC4340]。
For simplicity, we say that senders send DCCP-Data packets and receivers send DCCP-Ack packets. Both of these categories are meant to include DCCP-DataAck packets.
为简单起见，我们说发送方发送DCCP数据包，接收方发送DCCP Ack包。这两个类别都包括DCCP数据包。
The phrases "ECN-marked" and "marked" refer to packets marked ECN Congestion Experienced unless otherwise noted.
除非另有说明，否则短语“ECN标记”和“标记”指标记为ECN拥塞的数据包。
CCID 2, TCP-like Congestion Control, is appropriate for DCCP flows that would like to receive as much bandwidth as possible over the long term, consistent with the use of end-to-end congestion control. CCID 2 flows must also tolerate the large sending rate variations characteristic of AIMD congestion control, including halving of the congestion window in response to a congestion event.
CCID 2，类似TCP的拥塞控制，适用于希望在长期内接收尽可能多带宽的DCCP流，与端到端拥塞控制的使用一致。CCID 2流还必须能够承受AIMD拥塞控制的大发送速率变化特性，包括响应拥塞事件将拥塞窗口减半。
Applications that simply need to transfer as much data as possible in as short a time as possible should use CCID 2. This contrasts with CCID 3, TCP-Friendly Rate Control (TFRC) [RFC4342], which is appropriate for flows that would prefer to minimize abrupt changes in the sending rate. For example, CCID 2 is recommended over CCID 3 for streaming media applications that buffer a considerable amount of data at the application receiver before playback time, insulating the application somewhat from abrupt changes in the sending rate. Such applications could easily choose DCCP's CCID 2 over TCP itself, possibly adding some form of selective reliability at the application layer. CCID 2 is also recommended over CCID 3 for applications where halving the sending rate in response to congestion is not likely to interfere with application-level performance.
那些只需要在尽可能短的时间内传输尽可能多的数据的应用程序应该使用CCID2。这与CCID 3、TCP友好速率控制（TFRC）[RFC4342]形成对比，后者适用于希望最小化发送速率突变的流。例如，对于在回放时间之前在应用接收器处缓冲相当数量的数据的流媒体应用，建议使用CCID 2而不是CCID 3，从而在一定程度上避免应用程序受到发送速率的突然变化的影响。这样的应用程序可以很容易地选择DCCP的CCID2而不是TCP本身，可能会在应用层增加某种形式的选择性可靠性。对于响应拥塞而将发送速率减半不太可能干扰应用程序级性能的应用程序，建议使用CCID 2而不是CCID 3。
An additional advantage of CCID 2 is that its TCP-like congestion control mechanisms are reasonably well understood, with traffic dynamics quite similar to those of TCP. While the network research community is still learning about the dynamics of TCP after 15 years of its being the dominant transport protocol in the Internet, some applications might prefer the more well-known dynamics of TCP-like congestion control over those of newer congestion control mechanisms, which haven't yet met the test of widespread Internet deployment.
CCID2的另一个优点是，它类似于TCP的拥塞控制机制得到了合理的理解，其流量动态与TCP非常相似。虽然网络研究界在TCP作为互联网上的主要传输协议已有15年之久之后仍在学习TCP的动态特性，但与较新的拥塞控制机制相比，一些应用程序可能更喜欢TCP之类的更著名的动态特性，还没有通过互联网广泛部署的考验。
The congestion control mechanisms described here closely follow mechanisms standardized by the IETF for use in SACK-based TCP, and we rely partially on existing TCP documentation, such as [RFC793], [RFC2581], [RFC3465], and [RFC3517]. TCP congestion control continues to evolve, but CCID 2 implementations SHOULD wait for explicit updates to CCID 2 rather than track TCP's evolution directly.
这里描述的拥塞控制机制严格遵循IETF标准化的用于基于SACK的TCP的机制，我们部分依赖现有的TCP文档，如[RFC793]、[RFC2581]、[RFC3465]和[RFC3517]。TCP拥塞控制继续发展，但CCID2实现应该等待CCID2的显式更新，而不是直接跟踪TCP的发展。
Differences between CCID 2 and straight TCP congestion control include the following:
CCID 2和直接TCP拥塞控制之间的区别包括：
o CCID 2 applies congestion control to acknowledgements, a mechanism not currently standardized for use in TCP.
o CCID2将拥塞控制应用于确认，这是一种目前尚未在TCP中使用的标准化机制。
o DCCP is a datagram protocol, so several parameters whose units are specified in bytes in TCP, such as the congestion window cwnd, have units of packets in DCCP.
o DCCP是一种数据报协议，因此TCP中以字节为单位指定的几个参数（如拥塞窗口cwnd）在DCCP中具有数据包单位。
o As an unreliable protocol, DCCP never retransmits a packet, so congestion control mechanisms that distinguish retransmissions from new packets have been redesigned for the DCCP context.
o 作为一种不可靠的协议，DCCP从不重发数据包，因此针对DCCP上下文重新设计了区分重发和新数据包的拥塞控制机制。
This example shows the typical progress of a half-connection using CCID 2's TCP-like Congestion Control, not including connection initiation and termination. The example is informative, not normative.
此示例显示了使用CCID2的TCP类拥塞控制的半连接的典型过程，不包括连接启动和终止。这个例子是信息性的，而不是规范性的。
1. The sender sends DCCP-Data packets, where the number of packets sent is governed by a congestion window, cwnd, as in TCP. Each DCCP-Data packet uses a sequence number. The sender also sends an Ack Ratio feature option specifying the number of data packets to be covered by an Ack packet from the receiver; Ack Ratio defaults to two. The DCCP header's CCVal field is set to zero.
1. 发送方发送DCCP数据包，其中发送的数据包数量由拥塞窗口cwnd控制，如TCP中所述。每个DCCP数据包使用一个序列号。发送方还发送Ack Ratio特征选项，该选项指定来自接收方的Ack分组要覆盖的数据分组的数目；确认比率默认为2。DCCP标头的CCVal字段设置为零。
Assuming that the half-connection is Explicit Congestion Notification (ECN) capable (the ECN Incapable feature is zero, the default), each DCCP-Data packet is sent as ECN Capable with either the ECT(0) or the ECT(1) codepoint set, as described in [RFC3540].
假设半连接具有显式拥塞通知（ECN）功能（默认情况下，ECN无法功能为零），则每个DCCP数据包将作为具有ECT（0）或ECT（1）码点集的ECN功能发送，如[RFC3540]中所述。
2. The receiver sends a DCCP-Ack packet acknowledging the data packets for every Ack Ratio data packets transmitted by the sender. Each DCCP-Ack packet uses a sequence number and contains an Ack Vector. The sequence number acknowledged in a DCCP-Ack packet is that of the received packet with the highest sequence number; it is not a TCP-like cumulative acknowledgement.
2. 接收机发送DCCP Ack分组，确认发送方发送的每个Ack比率数据分组的数据分组。每个DCCP Ack数据包使用一个序列号并包含一个Ack向量。在DCCP Ack分组中确认的序列号是具有最高序列号的接收分组的序列号；它不是类似于TCP的累积确认。
The receiver returns the sum of received ECN Nonces via Ack Vector options, allowing the sender to probabilistically verify that the receiver is not misbehaving. DCCP-Ack packets from the receiver are also sent as ECN Capable, since the sender will control the acknowledgement rate in a roughly TCP-friendly way using the Ack Ratio feature. There is little need for the receiver to verify the nonces of its DCCP-Ack packets, since the sender cannot get significant benefit from misreporting the ack mark rate.
接收机通过Ack Vector选项返回接收到的ECN nonce之和，从而允许发送方以概率方式验证接收机是否行为异常。来自接收方的DCCP Ack数据包也作为ECN功能发送，因为发送方将使用Ack比率功能以大致TCP友好的方式控制确认率。接收方几乎不需要验证其DCCP Ack数据包的时值，因为发送方无法从误报Ack标记率中获得显著的好处。
3. The sender continues sending DCCP-Data packets as controlled by the congestion window. Upon receiving DCCP-Ack packets, the sender examines their Ack Vectors to learn about marked or dropped data packets and adjusts its congestion window accordingly. Because this is unreliable transfer, the sender does not retransmit dropped packets.
3. The sender continues sending DCCP-Data packets as controlled by the congestion window. Upon receiving DCCP-Ack packets, the sender examines their Ack Vectors to learn about marked or dropped data packets and adjusts its congestion window accordingly. Because this is unreliable transfer, the sender does not retransmit dropped packets.translate error, please retry
4. Because DCCP-Ack packets use sequence numbers, the sender has some information about lost or marked DCCP-Ack packets. The sender responds to lost or marked DCCP-Ack packets by modifying the Ack Ratio sent to the receiver.
4. 因为DCCP Ack数据包使用序列号，所以发送方有一些关于丢失或标记的DCCP Ack数据包的信息。发送方通过修改发送给接收方的Ack比率来响应丢失或标记的DCCP Ack数据包。
5. The sender acknowledges the receiver's acknowledgements at least once per congestion window. If both half-connections are active, the sender's acknowledgement of the receiver's acknowledgements is included in the sender's acknowledgement of the receiver's data packets. If the reverse-path half-connection is quiescent, the sender sends at least one DCCP-DataAck packet per congestion window.
5. 发送方至少在每个拥塞窗口确认接收方的确认一次。如果两个半连接都处于活动状态，发送方对接收方确认的确认将包含在发送方对接收方数据包的确认中。如果反向路径半连接处于静止状态，则发送方在每个拥塞窗口至少发送一个DCCP数据包。
6. The sender estimates round-trip times, either through keeping track of acknowledgement round-trip times as TCP does or through explicit Timestamp options, and calculates a TimeOut (TO) value much as the RTO (Retransmit Timeout) is calculated in TCP. The TO determines when a new DCCP-Data packet can be transmitted when the sender has been limited by the congestion window and no feedback has been received from the receiver.
6. 发送方通过像TCP一样跟踪确认往返时间或通过显式时间戳选项来估计往返时间，并计算超时（TO）值，就像TCP中计算RTO（重传超时）一样。当发送方受到拥塞窗口的限制并且没有从接收方接收到反馈时，TO确定何时可以发送新的DCCP数据包。
Use of the Ack Vector is MANDATORY on CCID 2 half-connections, so the sender MUST send a "Change R(Send Ack Vector, 1)" option to the receiver as part of connection establishment. The sender SHOULD NOT send data until it has received the corresponding "Confirm L(Send Ack Vector, 1)" from the receiver, except that it MAY send data on DCCP-Request packets.
CCID 2半连接上必须使用Ack向量，因此发送方必须向接收方发送“更改R（发送Ack向量，1）”选项，作为连接建立的一部分。发送方在从接收方收到相应的“确认L（发送确认向量，1）”之前不应发送数据，除非它可以发送DCCP请求数据包上的数据。
CCID 2's congestion control mechanisms are based on those for SACK-based TCP [RFC3517], since the Ack Vector provides all the information that might be transmitted in SACK options.
CCID 2的拥塞控制机制基于基于SACK的TCP[RFC3517]的拥塞控制机制，因为Ack向量提供了SACK选项中可能传输的所有信息。
A CCID 2 data sender maintains three integer parameters measured in packets.
CCID2数据发送器维护以数据包为单位测量的三个整数参数。
1. The congestion window "cwnd", which equals the maximum number of data packets allowed in the network at any time. ("Data packet" means any DCCP packet that contains user data: DCCP-Data, DCCP-DataAck, and occasionally DCCP-Request and DCCP-Response.)
1. 拥塞窗口“cwnd”，它等于网络中任何时候允许的最大数据包数。（“数据包”指任何包含用户数据的DCCP包：DCCP数据、DCCP数据包，偶尔还包括DCCP请求和DCCP响应。）
2. The slow-start threshold "ssthresh", which controls adjustments to cwnd.
2. 慢启动阈值“ssthresh”，用于控制cwnd的调整。
3. The pipe value "pipe", which is the sender's estimate of the number of data packets outstanding in the network.
3. 管道值“pipe”，它是发送方对网络中未完成的数据包数量的估计。
These parameters are manipulated, and their initial values determined, according to SACK-based TCP's behavior, except that they are measured in packets, not bytes. The rest of this section provides more specific guidance.
这些参数是根据基于SACK的TCP的行为进行操作的，它们的初始值是确定的，但它们是以数据包而不是字节来度量的。本节其余部分提供了更具体的指导。
The sender MAY send a data packet when pipe < cwnd but MUST NOT send a data packet when pipe >= cwnd. Every data packet sent increases pipe by 1.
发送方可以在管道<cwnd时发送数据包，但在管道>=cwnd时不得发送数据包。每发送一个数据包，管道就增加1。
The sender reduces pipe as it infers that data packets have left the network, either by being received or by being dropped. In particular:
发送方通过接收或丢弃数据包来推断数据包已离开网络，从而减少了管道。特别地：
1. Acked data packets. The sender reduces pipe by 1 for each data packet newly acknowledged as received (Ack Vector State 0 or State 1) by some DCCP-Ack.
1. 已确认的数据包。对于通过某个DCCP Ack新确认为接收到的每个数据包（Ack向量状态0或状态1），发送方将管道减少1。
2. Dropped data packets. The sender reduces pipe by 1 for each data packet it can infer as lost due to the DCCP equivalent of TCP's "duplicate acknowledgements". This depends on the NUMDUPACK parameter, the number of duplicate acknowledgements needed to infer a loss. The NUMDUPACK parameter is set to three, as is currently the case in TCP. A packet P is inferred to be lost, rather than delayed, when at least NUMDUPACK packets transmitted after P have been acknowledged as received (Ack Vector State 0 or 1) by the receiver. Note that the acknowledged packets following the hole may be DCCP-Acks or other non-data packets.
2. 丢弃的数据包。发送方将每个数据包的管道减少1，因为它可以推断由于TCP的“重复确认”的DCCP等价物而丢失。这取决于NUMDUPACK参数，即推断丢失所需的重复确认数。NUMDUPACK参数设置为3，与TCP中当前的情况相同。当在P之后发送的至少NUMDUPACK分组已被接收机确认为已接收（Ack向量状态0或1）时，分组P被推断为丢失而不是延迟。注意，孔后的已确认分组可以是DCCP ack或其他非数据分组。
3. Transmit timeouts. Finally, the sender needs transmit timeouts, handled like TCP's retransmission timeouts, in case an entire window of packets is lost. The sender estimates the round-trip time at most once per window of data and uses the TCP algorithms for maintaining the average round-trip time, mean deviation, and timeout value [RFC2988]. (If more than one measurement per round-trip time was used for these calculations, then the weights of the averagers would have to be adjusted to ensure that the average round-trip time is effectively derived from measurements
3. 传输超时。最后，发送方需要传输超时，就像TCP的重传超时一样处理，以防整个数据包窗口丢失。发送方在每个数据窗口最多估计一次往返时间，并使用TCP算法来维护平均往返时间、平均偏差和超时值[RFC2988]。（如果在这些计算中使用了每个往返时间的多个测量值，则必须调整平均值的权重，以确保有效地从测量值中得出平均往返时间。）
over multiple round-trip times.) Because DCCP does not retransmit data, DCCP does not require TCP's recommended minimum timeout of one second. The exponential backoff of the timer is exactly as in TCP. When a transmit timeout occurs, the sender sets pipe to zero. The adjustments to cwnd and ssthresh are described below.
由于DCCP不重新传输数据，因此DCCP不需要TCP建议的最小超时1秒。计时器的指数后退与TCP中的完全相同。发生传输超时时，发送方将管道设置为零。cwnd和ssthresh的调整如下所述。
The sender MUST NOT decrement pipe more than once per data packet. True duplicate acknowledgements, for example, MUST NOT affect pipe. The sender also MUST NOT decrement pipe again upon receiving acknowledgement of a packet previously inferred as lost. Furthermore, the sender MUST NOT decrement pipe for non-data packets, such as DCCP-Acks, even though the Ack Vector will contain information about them.
发送方对每个数据包的递减管道不得超过一次。例如，真正的重复确认不能影响管道。发送方也不得在收到先前推断为丢失的数据包的确认后再次减少管道。此外，发送方不得减少非数据包（如DCCP Ack）的管道，即使Ack向量将包含关于它们的信息。
Congestion events cause CCID 2 to reduce its congestion window. A congestion event contains at least one lost or marked packet. As in TCP, two losses or marks are considered part of a single congestion event when the second packet was sent before the loss or mark of the first packet was detected. As an approximation, a sender can consider two losses or marks to be part of a single congestion event when the packets were sent within one RTT estimate of one another, using an RTT estimate current at the time the packets were sent. For each congestion event, either indicated explicitly as an Ack Vector State 1 (ECN-marked) acknowledgement or inferred via "duplicate acknowledgements", cwnd is halved, then ssthresh is set to the new cwnd. Cwnd is never reduced below one packet. After a timeout, the slow-start threshold is set to cwnd/2, then cwnd is set to one packet. When halved, cwnd and ssthresh have their values rounded down, except that cwnd is never less than one and ssthresh is never less than two.
拥塞事件导致CCID 2减少其拥塞窗口。拥塞事件至少包含一个丢失或标记的数据包。在TCP中，当检测到第一个数据包的丢失或标记之前发送第二个数据包时，两个丢失或标记被视为单个拥塞事件的一部分。作为近似，发送者可以考虑两个丢失或标记作为单个拥塞事件的一部分，当数据包在一个RTT估计内被发送时，使用在发送数据包时的RTT估计电流。对于每个拥塞事件（明确表示为Ack矢量状态1（ECN标记）确认或通过“重复确认”推断），cwnd减半，然后ssthresh设置为新cwnd。Cwnd永远不会减少到一个数据包以下。超时后，慢启动阈值设置为cwnd/2，然后cwnd设置为一个数据包。减半后，cwnd和ssthresh的值向下舍入，但cwnd永远不小于1，ssthresh永远不小于2。
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. The cwnd parameter is initialized to at most four packets for new connections, following the rules from [RFC3390]; the ssthresh parameter is initialized to an arbitrarily high value.
当cwnd<ssthresh时，意味着发送方处于慢启动状态，对于Ack向量状态为0（未标记ECN）的每两个新确认的数据包，拥塞窗口增加一个包，最大Ack比率为每个确认2个包。这是适当字节计数[RFC3465]的一种修改形式，与TCP的当前标准（不包括字节计数）一致，但当CCID 2的Ack比率大于默认值2时，允许CCID 2像TCP一样大幅增加。当cwnd>=ssthresh时，对于在没有丢失或标记数据包的情况下确认的每个数据窗口，拥塞窗口增加一个数据包。根据[RFC3390]中的规则，对于新连接，cwnd参数初始化为最多四个数据包；ssthresh参数初始化为任意高的值。
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.
当发送由单个ack分组释放的多个数据分组时，发送方可以使用基于速率的调整形式，而不是在单个突发中发送所有释放的数据分组。
CCID 2 is designed to follow TCP's congestion control mechanisms to the extent possible, but TCP does not have complete standardization for its congestion control response to idle periods (when no data packets are sent) or to application-limited periods (when the sending rate is less than that allowed by cwnd). This section is a brief guide to the standards for TCP in this area.
CCID 2旨在尽可能遵循TCP的拥塞控制机制，但TCP对空闲时间段（无数据包发送时）或应用程序限制时间段（发送速率小于cwnd允许时）的拥塞控制响应没有完全标准化。本节简要介绍了该领域的TCP标准。
For idle periods, [RFC2581] recommends that the TCP sender SHOULD slow-start after an idle period, where an idle period is defined as a period exceeding the timeout interval. [RFC2861], currently Experimental, suggests a slightly more moderate mechanism where the congestion window is halved for every round-trip time that the sender has remained idle.
对于空闲时间段，[RFC2581]建议TCP发送方在空闲时间段后缓慢启动，其中空闲时间段定义为超过超时间隔的时间段。[RFC2861]目前处于实验阶段，它提出了一种稍微温和的机制，即发送方空闲的每一个往返时间的拥塞窗口都会减半。
There are currently no standards governing TCP's use of the congestion window during an application-limited period. In particular, it is possible for TCP's congestion window to grow quite large during a long uncongested period when the sender is application limited, sending at a low rate. [RFC2861] essentially suggests that TCP's congestion window not be increased during application-limited periods when the congestion window is not being fully utilized.
目前还没有标准来管理TCP在应用程序有限期内对拥塞窗口的使用。特别是，当发送方受到应用程序限制，以较低的速率发送时，TCP的拥塞窗口可能在长时间的未拥塞期间变得相当大。[RFC2861]本质上建议，在拥塞窗口未被充分利用的应用程序限制期间，TCP的拥塞窗口不得增加。
DCCP's Data Dropped option lets a receiver declare that a packet was dropped at the end host before delivery to the application -- for instance, because of corruption or receive buffer overflow. DCCP's Slow Receiver option lets a receiver declare that it is having trouble keeping up with the sender's packets, although nothing has yet been dropped. CCID 2 senders respond to these options as described in [RFC4340], with the following further clarifications.
DCCP的数据丢弃选项允许接收方声明数据包在交付到应用程序之前已在终端主机上丢弃——例如，由于损坏或接收缓冲区溢出。DCCP的Slow Receiver（慢速接收）选项允许接收端声明其无法跟上发送方的数据包，尽管尚未丢弃任何数据包。CCID 2发送方对[RFC4340]中所述的这些选项作出响应，并做出以下进一步澄清。
o Drop Code 2 ("receive buffer drop"). The congestion window "cwnd" is reduced by one for each packet newly acknowledged as Drop Code 2, except that it is never reduced below one.
o 删除代码2（“接收缓冲区删除”）。对于新确认为丢弃码2的每个数据包，拥塞窗口“cwnd”减少一个，除非它从未减少到一个以下。
o Exiting slow start. The sender MUST exit slow start whenever it receives a relevant Data Dropped or Slow Receiver option.
o 退出慢速启动。无论何时收到相关数据丢弃或慢速接收器选项，发送方都必须退出慢速启动。
CCID 2 is optimized for applications that generally use a fixed packet size and vary their sending rate in packets per second in response to congestion. CCID 2 is not appropriate for applications that require a fixed interval of time between packets and vary their packet size instead of their packet rate in response to congestion.
CCID 2针对通常使用固定数据包大小并根据拥塞情况以每秒数据包的形式改变发送速率的应用程序进行了优化。CCID 2不适用于需要在数据包之间有固定时间间隔并根据拥塞情况改变数据包大小而不是数据包速率的应用程序。
CCID 2 maintains a congestion window in packets and does not increase the congestion window in response to a decrease in the packet size. However, some attention might be required for applications using CCID 2 that vary their packet size not in response to congestion, but in response to other application-level requirements.
CCID 2在分组中保持拥塞窗口，并且不响应于分组大小的减小而增加拥塞窗口。然而，对于使用CCID 2的应用程序，可能需要注意改变其数据包大小不是为了响应拥塞，而是为了响应其他应用程序级别的要求。
CCID 2 implementations MAY check for applications that appear to be manipulating the packet size inappropriately. For example, an application might send small packets for a while, building up a fast rate, then switch to large packets to take advantage of the fast rate. (Preliminary simulations indicate that applications may not be able to increase their overall transfer rates this way, so it is not clear that this manipulation will occur in practice [V03].)
CCID2实现可能会检查似乎不适当地操纵数据包大小的应用程序。例如，一个应用程序可能会发送一段时间的小数据包，建立一个快速率，然后切换到大数据包以利用快速率。（初步模拟表明，应用程序可能无法以这种方式增加其总传输速率，因此不清楚这种操纵是否会在实践中发生[V03]。）
CCID 2 acknowledgements are generally paced by the sender's data packets. Each required acknowledgement MUST contain Ack Vector options that declare exactly which packets arrived and whether those packets were ECN-marked. Acknowledgement data in the Ack Vector options SHOULD generally cover the receiver's entire Acknowledgement Window; see [RFC4340], Section 11.4.2. Any Data Dropped options SHOULD likewise cover the receiver's entire Acknowledgement Window.
CCID 2确认通常由发送方的数据包进行调整。每个必需的确认必须包含Ack向量选项，这些选项准确地声明哪些数据包到达，以及这些数据包是否有ECN标记。Ack向量选项中的确认数据通常应覆盖接收机的整个确认窗口；见[RFC4340]，第11.4.2节。任何丢弃的数据选项同样应覆盖接收器的整个确认窗口。
CCID 2 senders use DCCP's Ack Ratio feature to influence the rate at which receivers generate DCCP-Ack packets, thus controlling reverse-path congestion. This differs from TCP, which presently has no congestion control for pure acknowledgement traffic. CCID 2's reverse-path congestion control does not try to be TCP friendly; it just tries to avoid congestion collapse, and to be somewhat better than TCP is in the presence of a high packet loss or mark rate on the reverse path. The default Ack Ratio is two, and CCID 2 with this Ack Ratio behaves like TCP with delayed acks. [RFC4340], Section 11.3, describes the Ack Ratio in more detail, including its relationship to acknowledgement pacing and DCCP-DataAck packets. This document's Section 6.1.1 describes how a CCID 2 sender detects lost or marked acknowledgements, and Section 6.1.2 describes how it changes the Ack Ratio.
CCID 2发送方使用DCCP的Ack比率特性来影响接收方生成DCCP Ack数据包的速率，从而控制反向路径拥塞。这与TCP不同，TCP目前没有针对纯确认流量的拥塞控制。CCID2的反向路径拥塞控制并不试图对TCP友好；它只是试图避免拥塞崩溃，在反向路径上存在高丢包率或标记率的情况下，它比TCP要好一些。默认Ack比率为2，具有此Ack比率的CCID 2的行为类似于具有延迟Ack的TCP。[RFC4340]第11.3节更详细地描述了Ack比率，包括其与确认起搏和DCCP数据包的关系。本文件第6.1.1节描述了CCID 2发送方如何检测丢失或标记的确认，第6.1.2节描述了其如何更改确认比率。
When Ack Ratio is R, the receiver sends one DCCP-Ack packet per R data packets, more or less. Since the sender sends cwnd data packets per round-trip time, the acknowledgement rate equals cwnd/R DCCP-Acks per round-trip time. The sender keeps the acknowledgement rate roughly TCP friendly by monitoring the acknowledgement stream for lost and marked DCCP-Ack packets and modifying R accordingly. For every RTT containing a DCCP-Ack congestion event (that is, a lost or
当Ack比率为R时，接收器或多或少地每R个数据分组发送一个DCCP Ack分组。由于发送方在每个往返时间发送cwnd数据包，因此确认率等于每个往返时间的cwnd/R DCCP ACK。发送方通过监视确认流中丢失和标记的DCCP Ack数据包并相应地修改R来保持大致TCP友好的确认率。对于包含DCCP Ack拥塞事件（即丢失或丢失）的每个RTT
marked DCCP-Ack), the sender halves the acknowledgement rate by doubling Ack Ratio; for every RTT containing no DCCP-Ack congestion event, it additively increases the acknowledgement rate through gradual decreases in Ack Ratio.
标记为DCCP Ack），发送方通过加倍Ack比率将确认率减半；对于每个不包含DCCP Ack拥塞事件的RTT，它通过逐渐降低Ack比率来增加确认率。
All packets from the receiver contain sequence numbers, so the sender can detect both losses and marks on the receiver's packets. The sender infers receiver packet loss in the same way that it infers losses of its data packets: a packet from the receiver is considered lost after at least NUMDUPACK packets with greater sequence numbers have been received.
来自接收方的所有数据包都包含序列号，因此发送方可以检测接收方数据包上的丢失和标记。发送方推断接收方数据包丢失的方式与推断其数据包丢失的方式相同：来自接收方的数据包在至少收到具有较大序列号的NUMDUPACK数据包后被视为丢失。
DCCP-Ack packets are generally small, so they might impose less load on congested network links than DCCP-Data and DCCP-DataAck packets. For this reason, Ack Ratio depends on losses and marks on the receiver's non-data packets, not on aggregate losses and marks on all of the receiver's packets. The non-data packet category consists of those packet types that cannot carry application data: DCCP-Ack, DCCP-Close, DCCP-CloseReq, DCCP-Reset, DCCP-Sync, and DCCP-SyncAck. The sender can easily distinguish non-data marks from other marks. This is harder for losses, though, since the sender can't always know whether a lost packet carried data. Unless it has better information, the sender SHOULD assume, for the purpose of Ack Ratio calculation, that every lost packet was a non-data packet. Better information is available via DCCP's NDP Count option, if necessary. (Appendix B discusses the costs of mistaking data packet loss for non-data packet loss.)
DCCP Ack数据包通常很小，因此它们可能比DCCP数据包和DCCP数据包对拥塞的网络链路施加的负载更小。因此，Ack比率取决于接收机的非数据分组上的丢失和标记，而不是取决于所有接收机分组上的总丢失和标记。非数据包类别由不能承载应用程序数据的包类型组成：DCCP Ack、DCCP Close、DCCP CLOSERQ、DCCP Reset、DCCP Sync和DCCP SyncAck。发送方可以很容易地将非数据标记与其他标记区分开来。然而，这对于丢失来说更难，因为发送方不能总是知道丢失的数据包是否携带数据。除非发送方具有更好的信息，否则为了计算Ack比率，发送方应假定每个丢失的分组都是非数据分组。如有必要，可通过DCCP的NDP计数选项获得更好的信息。（附录B讨论了将数据包丢失误认为非数据包丢失的成本。）
A receiver that implements its own acknowledgement congestion control independent of Ack Ratio SHOULD NOT reduce its DCCP-Ack acknowledgement rate due to losses or marks on its data packets.
独立于Ack比率实现自身确认拥塞控制的接收器不应由于其数据包上的丢失或标记而降低其DCCP Ack确认率。
Ack Ratio always meets three constraints: (1) Ack Ratio is an integer. (2) Ack Ratio does not exceed cwnd/2, rounded up, except that Ack Ratio 2 is always acceptable. (3) Ack Ratio is two or more for a congestion window of four or more packets.
确认比率始终满足三个约束条件：（1）确认比率是一个整数。（2） 确认率不超过cwnd/2，四舍五入，但确认率2始终是可接受的。（3） 对于包含四个或更多数据包的拥塞窗口，Ack比率为两个或更多。
The sender changes Ack Ratio within those constraints as follows. For each congestion window of data with lost or marked DCCP-Ack packets, Ack Ratio is doubled; and for each cwnd/(R^2 - R) consecutive congestion windows of data with no lost or marked DCCP-Ack packets, Ack Ratio is decreased by 1. (See Appendix A for the derivation.) Changes in Ack Ratio are signalled through feature negotiation; see [RFC4340], Section 11.3.
发送方在这些约束内更改Ack比率，如下所示。对于丢失或标记DCCP Ack数据包的数据的每个拥塞窗口，Ack比率加倍；对于没有丢失或标记DCCP Ack数据包的数据的每个cwnd/（R^2-R）连续拥塞窗口，Ack比率减少1。（推导见附录A。）Ack比率的变化通过特征协商发出信号；见[RFC4340]，第11.3节。
For a constant congestion window, this gives 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 use the most recent value of cwnd when determining whether to decrease Ack Ratio by 1.
对于恒定的拥塞窗口，这提供了一个Ack发送速率，该速率大体上是TCP友好的。当然，cwnd通常随时间而变化；动态将相当复杂，但大致上对TCP友好。我们建议发送方在确定是否将Ack比率降低1时使用cwnd的最新值。
The sender need not keep 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 renegotiate the Ack Ratio more than once per round-trip time. Additionally, it MAY enforce a minimum Ack Ratio of two, or it MAY set Ack Ratio to one for half-connections with persistent congestion windows of 1 or 2 packets.
发送方不需要保持Ack比率完全为最新。例如，它可以将Ack比率重新协商的速率限制为每四或五次往返一次，或每秒或两次一次。发送方不应在每次往返时间内多次尝试重新协商Ack比率。此外，它可以强制最小Ack比率为2，或者对于具有1或2个包的持久拥塞窗口的一半连接，它可以将Ack比率设置为1。
Putting it all together, the receiver always sends at least one acknowledgement per window of data when cwnd = 1, and at least two acknowledgements per window of data otherwise. Thus, the receiver could be sending two ack packets per 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, as in TCP. Thus, if congestion is sufficiently heavy on the reverse path, then the sender reduces its sending rate on the forward path, which reduces the rate on the reverse path as well.
综上所述，当cwnd=1时，接收器总是在每个数据窗口发送至少一个确认，否则在每个数据窗口发送至少两个确认。因此，即使在反向路径上面临非常严重的拥塞时，接收机也可以在每个数据窗口发送两个ack分组。然而，我们会注意到，如果拥塞足够严重，那么所有ack数据包都会被丢弃，然后发送方会返回到指数级后退超时，就像TCP中那样。因此，如果反向路径上的拥塞足够严重，则发送方降低其在正向路径上的发送速率，这也降低了反向路径上的速率。
An active sender DCCP A MUST occasionally acknowledge its peer DCCP B's acknowledgements so that DCCP B can free up Ack Vector state. When both half-connections are active, A's acknowledgements of B's acknowledgements are automatically contained in A's acknowledgements of B's data. If the B-to-A half-connection is quiescent, however, DCCP A must occasionally send acknowledgements proactively, such as by sending a DCCP-DataAck packet that includes an Acknowledgement Number in the header.
活动发送方DCCP A必须偶尔确认其对等方DCCP B的确认，以便DCCP B可以释放确认向量状态。当两个半连接都处于活动状态时，A对B的确认将自动包含在A对B数据的确认中。但是，如果B-to-A连接处于静止状态，DCCP A必须偶尔主动发送确认，例如通过发送在报头中包含确认号的DCCP数据包。
An active sender SHOULD acknowledge the receiver's acknowledgements at least once per congestion window. Of course, the sender's application might fall silent. This is no problem; when neither side is sending data, a sender can wait arbitrarily long before sending an ack.
主动发送方应在每个拥塞窗口至少确认接收方的确认一次。当然，发送方的应用程序可能会保持沉默。这是没有问题的；当双方都不发送数据时，发送方可以在发送ack之前任意等待很长时间。
This section describes how a CCID 2 receiver determines that the corresponding sender is not sending any data and therefore has gone quiescent. See [RFC4340], Section 11.1, for general information on quiescence.
本节描述CCID 2接收器如何确定相应的发送方未发送任何数据，因此处于静止状态。有关静止的一般信息，请参见[RFC4340]，第11.1节。
Let T equal the greater of 0.2 seconds and two round-trip times. (The receiver may know the round-trip time in its role as the sender for the other half-connection. If it does not, it should use a default RTT of 0.2 seconds, as described in [RFC4340], Section 3.4.) Once the sender acknowledges the receiver's Ack Vectors and the sender has not sent additional data for at least T seconds, the receiver can infer that the sender is quiescent. More precisely, the receiver infers that the sender has gone quiescent when at least T seconds have passed without receiving any data from the sender, and when the sender has acknowledged receiver Ack Vectors covering all data packets received at the receiver.
T等于0.2秒和两个往返时间中的较大者。（作为另一半连接的发送方，接收方可能知道往返时间。如果不知道，则应使用默认RTT 0.2秒，如[RFC4340]第3.4节所述。）一旦发送方确认接收方的Ack向量，且发送方至少有T秒未发送额外数据，接收者可以推断发送者是静止的。更准确地说，当至少T秒过去而没有从发送方接收任何数据时，并且当发送方已经确认覆盖在接收方接收的所有数据分组的接收机Ack向量时，接收机推断发送方已经静止。
CCID 2 supports Explicit Congestion Notification (ECN) [RFC3168]. The sender will use the ECN Nonce for data packets, and the receiver will echo those nonces in its Ack Vectors, as specified in [RFC4340], Section 12.2. Information about marked packets is also returned in the Ack Vector. Because the information in the Ack Vector is reliably transferred, DCCP does not need the TCP flags of ECN-Echo and Congestion Window Reduced.
CCID2支持显式拥塞通知（ECN）[RFC3168]。发送方将对数据包使用ECN Nonce，接收方将在其Ack向量中回送这些Nonce，如[RFC4340]第12.2节所述。有关标记的数据包的信息也会在Ack向量中返回。由于Ack向量中的信息被可靠地传输，DCCP不需要ECN回波和拥塞窗口的TCP标志。
For unmarked data packets, the receiver computes the ECN Nonce Echo as in [RFC3540] and returns it as part of its Ack Vector options. The sender SHOULD check these ECN Nonce Echoes against the expected values, thus protecting against the accidental or malicious concealment of marked packets.
对于未标记的数据包，接收机计算[RFC3540]中的ECN Nonce Echo，并将其作为其Ack Vector选项的一部分返回。发送方应根据预期值检查这些ECN Nonce回波，从而防止意外或恶意隐藏标记的数据包。
Because CCID 2 acknowledgements are congestion controlled, ECN may also be used for its acknowledgements. In this case we do not make use of the ECN Nonce, because it would not be easy to provide protection against the concealment of marked ack packets by the sender, and because the sender does not have much motivation for lying about the mark rate on acknowledgements.
因为CCID 2确认是拥塞控制的，所以ECN也可以用于其确认。在这种情况下，我们不使用ECN Nonce，因为它不容易提供防止发送方隐藏标记的ack数据包的保护，并且因为发送方没有太多动机在确认时谎报标记率。
DCCP's Ack Vector option, and its ECN Capable, Ack Ratio, and Send Ack Vector features, are relevant for CCID 2.
DCCP的Ack矢量选项及其ECN功能、Ack比率和发送Ack矢量功能与CCID 2相关。
Security considerations for DCCP have been discussed in [RFC4340], and security considerations for TCP have been discussed in [RFC2581].
[RFC4340]中讨论了DCCP的安全注意事项，而[RFC2581]中讨论了TCP的安全注意事项。
[RFC2581] discusses ways in which an attacker could impair the performance of a TCP connection by dropping packets, or by forging extra duplicate acknowledgements or acknowledgements for new data. We are not aware of any new security considerations created by this document in its use of TCP-like congestion control.
[RFC2581]讨论了攻击者通过丢弃数据包或伪造额外的重复确认或新数据确认来损害TCP连接性能的方式。我们不知道本文档在使用类似TCP的拥塞控制时产生了任何新的安全考虑。
This specification defines the value 2 in the DCCP CCID namespace managed by IANA. This assignment is also mentioned in [RFC4340]. CCID 2 also introduces three sets of numbers whose values should be allocated by IANA; namely, CCID 2-specific Reset Codes, option types, and feature numbers. These ranges will prevent any future CCID 2-specific allocations from polluting DCCP's corresponding global namespaces; see [RFC4340], Section 10.3. However, this document makes no particular allocations from any range, except for experimental and testing use [RFC3692]. We refer to the Standards Action policy outlined in [RFC2434].
本规范定义了IANA管理的DCCP CCID命名空间中的值2。[RFC4340]中也提到了此任务。CCID2还引入了三组数字，其值应由IANA分配；即CCID 2特定的重置代码、选项类型和功能编号。这些范围将防止任何未来特定于CCID 2的分配污染DCCP相应的全局名称空间；见[RFC4340]，第10.3节。但是，本文件未对任何范围进行特殊分配，实验和测试使用除外[RFC3692]。我们参考[RFC2434]中概述的标准行动政策。
Each entry in the DCCP CCID 2 Reset Code registry contains a CCID 2-specific Reset Code, which is a number in the range 128-255; a short description of the Reset Code; and a reference to the RFC defining the Reset Code. Reset Codes 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining Reset Codes -- 128-183, 191-247, and 255 -- are currently reserved and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication.
DCCP CCID 2重置代码注册表中的每个条目都包含一个特定于CCID 2的重置代码，该代码的范围为128-255；复位代码的简短说明；以及对定义重置代码的RFC的引用。重置代码184-190和248-254永久保留供实验和测试使用。其余的重置代码（128-183、191-247和255）目前为保留代码，应与标准行动政策一起分配，该政策要求IESG审查和批准以及标准跟踪IETF RFC发布。
Each entry in the DCCP CCID 2 option type registry contains a CCID 2-specific option type, which is a number in the range 128-255; the name of the option; and a reference to the RFC defining the option type. Option types 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining option types -- 128-183, 191-247, and 255 -- are currently reserved and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication.
DCCP CCID 2选项类型注册表中的每个条目都包含一个特定于CCID 2的选项类型，该选项类型是一个范围为128-255的数字；期权的名称；定义对RFC的类型和引用。选项类型184-190和248-254永久保留供实验和测试使用。其余的选项类型（128-183、191-247和255）目前保留，应与标准行动政策一起分配，该政策要求IESG审查和批准以及标准跟踪IETF RFC发布。
Each entry in the DCCP CCID 2 feature number registry contains a CCID 2-specific feature number, which is a number in the range 128-255; the name of the feature; and a reference to the RFC defining the feature number. Feature numbers 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining feature numbers -- 128-183, 191-247, and 255 -- are currently reserved and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication.
DCCP CCID 2功能编号注册表中的每个条目都包含一个CCID 2特定功能编号，该编号的范围为128-255；特征的名称；以及对定义特征编号的RFC的引用。特征编号184-190和248-254永久保留供实验和测试使用。其余的功能部件编号（128-183、191-247和255）目前保留，应与标准行动政策一起分配，该政策要求IESG审查和批准以及标准跟踪IETF RFC发布。
We thank Mark Handley and Jitendra Padhye for their help in defining CCID 2. We also thank Mark Allman, Aaron Falk, Nils-Erik Mattsson, Greg Minshall, Arun Venkataramani, Magnus Westerlund, and members of the DCCP Working Group for feedback on this document.
我们感谢Mark Handley和Jitendra Padhye在定义CCID 2方面的帮助。我们还感谢Mark Allman、Aaron Falk、Nils Erik Mattsson、Greg Minshall、Arun Venkataramani、Magnus Westerlund和DCCP工作组成员对本文件的反馈。
A. Appendix: Derivation of Ack Ratio Decrease
A.附录：确认率下降的推导
This section justifies the algorithm for increasing and decreasing the Ack Ratio given in Section 6.1.2.
本节证明了第6.1.2节中给出的增加和减少Ack比率的算法的合理性。
The congestion avoidance phase of TCP halves the cwnd for every window with congestion. Similarly, CCID 2 doubles Ack Ratio for every window with congestion on the return path, roughly halving the DCCP-Ack sending rate.
TCP的拥塞避免阶段将每个拥塞窗口的cwnd减半。类似地，CCID 2将返回路径上拥塞的每个窗口的Ack比率加倍，大约将DCCP Ack发送速率减半。
The congestion avoidance phase of TCP increases cwnd by one MSS for every congestion-free window. When this congestion avoidance behavior is applied to acknowledgement traffic, this would correspond to increasing the number of DCCP-Ack packets per window by one after every congestion-free window of DCCP-Ack packets. We cannot achieve this exactly using Ack Ratio, since it is an integer. Instead, we must decrease Ack Ratio by one after K windows have been sent without a congestion event on the reverse path, where K is chosen so that the long-term number of DCCP-Ack packets per congestion window is roughly TCP friendly, following AIMD congestion control.
TCP的拥塞避免阶段为每个无拥塞窗口增加一个MSS的cwnd。当此拥塞避免行为应用于确认流量时，这将对应于在DCCP Ack数据包的每个无拥塞窗口之后，将每个窗口的DCCP Ack数据包的数量增加一个。由于Ack比率是一个整数，因此我们无法使用Ack比率精确地实现这一点。相反，在反向路径上没有拥塞事件的情况下发送K个窗口后，我们必须将Ack比率降低1，其中选择K，以便在AIMD拥塞控制之后，每个拥塞窗口的DCCP Ack数据包的长期数量大体上是TCP友好的。
In CCID 2, rough TCP-friendliness for the ack traffic can be accomplished by setting K to cwnd/(R^2 - R), where R is the current Ack Ratio.
在CCID2中，可以通过将K设置为cwnd/（R^2-R）来实现ack流量的粗略TCP友好性，其中R是当前ack比率。
This result was calculated as follows:
该结果计算如下：
R = Ack Ratio = # data packets / ack packets, and
W = Congestion Window = # data packets / window, so
W/R = # ack packets / window.
R = Ack Ratio = # data packets / ack packets, and
W = Congestion Window = # data packets / window, so
W/R = # ack packets / window.
Requirement: Increase W/R by 1 per congestion-free window. Since we can only reduce R by increments of one, we find K so that, after K congestion-free windows, W/R + K would equal W/(R-1).
要求：每个无拥堵窗口的W/R增加1。因为我们只能以1的增量减少R，所以我们找到K，在K个无拥塞窗口之后，W/R+K等于W/（R-1）。
(W/R) + K = W/(R-1), so K = W/(R-1) - W/R = W/(R^2 - R).
（W/R）+K=W/（R-1），所以K=W/（R-1）-W/R=W/（R^2-R）。
B. Appendix: Cost of Loss Inference Mistakes to Ack Ratio
附录：损失推断错误成本与确认比率
As discussed in Section 6.1.1, the sender often cannot determine whether lost packets carried data. This hinders its ability to separate non-data loss events from other loss events. In the absence of better information, the sender assumes, for the purpose of Ack Ratio calculation, that all lost packets were non-data packets. This may overestimate the non-data loss event rate, which can lead to a too-high Ack Ratio, and thus to a too-slow acknowledgement rate. All acknowledgement information will still get through -- DCCP
如第6.1.1节所述，发送方通常无法确定丢失的数据包是否携带数据。这妨碍了其将非数据丢失事件与其他丢失事件分开的能力。在没有更好的信息的情况下，为了计算Ack比率，发送方假设所有丢失的分组都是非数据分组。这可能会高估非数据丢失事件率，这可能导致过高的Ack比率，从而导致过慢的确认率。所有确认信息仍将通过DCCP
acknowledgements are reliable -- but acknowledgement information will arrive in a burstier fashion. Absent some form of rate-based pacing, this could lead to increased burstiness for the sender's data traffic.
确认是可靠的，但确认信息将以一种更加激动人心的方式到达。如果没有某种形式的基于速率的起搏，这可能会导致发送方数据流量的突发性增加。
There are several cases when the problem of an overly-high Ack Ratio, and the resulting increased burstiness of the data traffic, will not arise. In particular, call the receiver DCCP B and the sender DCCP A:
在一些情况下，不会出现过高的Ack比率问题以及由此导致的数据流量突发性增加。具体而言，调用接收方DCCP B和发送方DCCP A：
o The problem won't arise unless DCCP B is sending a significant amount of data itself. When the B-to-A half-connection is quiescent or low rate, most packets sent by DCCP B will, in fact, be pure acknowledgements, and DCCP A's estimate of the DCCP-Ack loss rate will be reasonably accurate.
o 除非DCCP B本身发送大量数据，否则问题不会出现。当B-to-A连接处于静态或低速时，DCCP B发送的大多数数据包实际上都是纯粹的确认，DCCP A对DCCP Ack丢失率的估计将相当准确。
o The problem won't arise if DCCP B habitually piggybacks acknowledgement information on its data packets. The piggybacked acknowledgements are not limited by Ack Ratio, so they can arrive frequently enough to prevent burstiness.
o 如果DCCP B习惯性地在其数据包上携带确认信息，那么问题就不会出现。背驮式应答不受应答率的限制，因此它们可以足够频繁地到达以防止突发。
o The problem won't arise if DCCP A's sending rate is low, since burstiness isn't a problem at low rates.
o 如果DCCP A的发送速率很低，问题就不会出现，因为在低速率下突发性不是问题。
o The problem won't arise if DCCP B's sending rate is high relative to DCCP A's sending rate, since the B-to-A loss rate must be low to support DCCP B's sending rate. This bounds the Ack Ratio to reasonable values even when DCCP A labels every loss as a DCCP-Ack loss.
o 如果DCCP B的发送速率相对于DCCP A的发送速率较高，则不会出现问题，因为B-to-A丢失率必须较低才能支持DCCP B的发送速率。即使DCCP A将每个损失标记为DCCP Ack损失，也会将Ack比率限制为合理值。
o The problem won't arise if DCCP B sends NDP Count options when appropriate (the Send NDP Count/B feature is true). Then the sender can use the receiver's NDP Count options to detect, in most cases, whether lost packets were data packets or DCCP-Acks.
o 如果DCCP B在适当时发送NDP计数选项（发送NDP计数/B功能为true），则不会出现问题。然后，在大多数情况下，发送方可以使用接收方的NDP计数选项来检测丢失的数据包是数据包还是DCCP确认。
o Finally, the problem won't arise if DCCP A rate-paces its data packets.
o 最后，如果DCCP A的速率调整其数据包的速度，则不会出现问题。
This leaves the case when DCCP B is sending roughly the same amount of data packets and non-data packets, without NDP Count options, and with all acknowledgement information in DCCP-Ack packets. We now quantify the potential cost, in terms of a too-large Ack Ratio, due to the sender's misclassifying data packet losses as DCCP-Ack losses. For simplicity, we assume an environment of large-scale statistical multiplexing where the packet drop rate is independent of the sending rate of any individual connection.
这使得DCCP B发送的数据包和非数据包的数量大致相同，没有NDP计数选项，并且所有确认信息都在DCCP Ack包中的情况成为可能。现在，我们用过大的Ack比率来量化潜在成本，这是由于发送方将数据包丢失误分类为DCCP Ack丢失造成的。为简单起见，我们假设一个大规模统计多路复用环境，其中丢包率独立于任何单个连接的发送速率。
Assume that when DCCP A correctly counts non-data losses, Ack Ratio is set so that B-to-A data and acknowledgement traffic both have a sending rate of D packets per second. Then when DCCP A incorrectly counts data losses as non-data losses, the sending rate for the B-to-A data traffic is still D pps, but the reduced sending rate for the B-to-A acknowledgement traffic is f*D pps, with f < 1. Let the packet loss rate be p. The sender incorrectly estimates the non-data loss rate as (pD+pfD)/fD, or, equivalently, as p(1 + 1/f). Because the congestion control mechanism for acknowledgement traffic is roughly TCP friendly, and therefore the non-data sending rate and the data sending rate both grow as 1/sqrt(x) for x the packet drop rate, we have
假设当DCCP A正确统计非数据丢失时，设置Ack比率，以便B-to-A数据和确认流量的发送速率均为每秒D个数据包。然后，当DCCP A错误地将数据丢失计算为非数据丢失时，B-to-A数据通信的发送速率仍然是D pps，但B-to-A确认通信的降低发送速率是f*D pps，f<1。设丢包率为p。发送方错误地将非数据丢失率估计为（pD+pfD）/fD，或等效地估计为p（1+1/f）。由于确认流量的拥塞控制机制基本上是TCP友好的，因此非数据发送速率和数据发送速率都增长为1/sqrt（x），对于x丢包率，我们有
fD/D = sqrt(p)/sqrt(p(1 + 1/f)),
fD/D=sqrt（p）/sqrt（p（1+1/f）），
so
所以
f^2 = 1/(1 + 1/f).
f^2=1/（1+1/f）。
Solving, we get f = 0.62. If the sender incorrectly counts lost data packets as non-data in this scenario, the acknowledgement rate is decreased by a factor of 0.62. This would result in a moderate increase in burstiness for the A-to-B data traffic, which could be mitigated by sending NDP Count options or piggybacked acknowledgements, or by rate-pacing out the data.
求解，我们得到f=0.62。在这种情况下，如果发送方错误地将丢失的数据包计算为非数据，则确认率将降低0.62倍。这将导致a-to-B数据流量的突发性适度增加，这可以通过发送NDP计数选项或搭载应答，或通过数据速率调整来缓解。
Normative References
规范性引用文件
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC2018]Mathis，M.，Mahdavi，J.，Floyd，S.，和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[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月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]奥尔曼，M.，弗洛伊德，S.，和C.帕特里奇，“增加TCP的初始窗口”，RFC3390，2002年10月。
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3517]Blanton，E.，Allman，M.，Fall，K.，和L.Wang，“基于保守选择确认（SACK）的TCP丢失恢复算法”，RFC 3517，2003年4月。
[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月。
Informative References
资料性引用
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861]Handley，M.，Padhye，J.，和S.Floyd，“TCP拥塞窗口验证”，RFC 28612000年6月。
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3465]Allman，M.，“具有适当字节计数的TCP拥塞控制（ABC）”，RFC 3465，2003年2月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]Spring，N.，Weterral，D.，和D.Ely，“带有nonce的鲁棒显式拥塞通知（ECN）信令”，RFC 35402003年6月。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006.
[RFC4342]Floyd，S.，Kohler，E.，和J.Padhye，“数据报拥塞控制协议（DCCP）拥塞控制ID 3的配置文件：TCP友好速率控制（TFRC）”，RFC 43422006年3月。
[V03] Arun Venkataramani, August 2003. Citation for acknowledgement purposes only.
[V03]Arun Venkataramani，2003年8月。引文仅供确认之用。
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
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
Eddie Kohler 4531C Boelter Hall加州大学洛杉矶分校计算机科学系美国加利福尼亚州洛杉矶90095
EMail: kohler@cs.ucla.edu
EMail: kohler@cs.ucla.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。