Network Working Group S. Floyd
Request for Comments: 4342 ICIR
Category: Standards Track E. Kohler
UCLA
J. Padhye
Microsoft Research
March 2006
Network Working Group S. Floyd
Request for Comments: 4342 ICIR
Category: Standards Track E. Kohler
UCLA
J. Padhye
Microsoft Research
March 2006
Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)
数据报拥塞控制协议（DCCP）拥塞控制ID 3的配置文件：TCP友好速率控制（TFRC）
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 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 3 should be used by senders that want a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes.
本文档包含数据报拥塞控制协议（DCCP）中拥塞控制标识符3 TCP友好速率控制（TFRC）的配置文件。CCID 3应该由希望TCP友好发送速率的发送方使用，可能带有显式拥塞通知（ECN），同时最小化速率的突然变化。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions .....................................................3
3. Usage ...........................................................3
3.1. Relationship with TFRC .....................................4
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 ...........7
5.2. Response to Data Dropped and Slow Receiver .................8
5.3. Packet Sizes ...............................................9
6. Acknowledgements ................................................9
6.1. Loss Interval Definition ..................................10
6.1.1. Loss Interval Lengths ..............................12
6.2. Congestion Control on Acknowledgements ....................13
1. Introduction ....................................................2
2. Conventions .....................................................3
3. Usage ...........................................................3
3.1. Relationship with TFRC .....................................4
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 ...........7
5.2. Response to Data Dropped and Slow Receiver .................8
5.3. Packet Sizes ...............................................9
6. Acknowledgements ................................................9
6.1. Loss Interval Definition ..................................10
6.1.1. Loss Interval Lengths ..............................12
6.2. Congestion Control on Acknowledgements ....................13
6.3. Acknowledgements of Acknowledgements ......................13
6.4. Determining Quiescence ....................................14
7. Explicit Congestion Notification ...............................14
8. Options and Features ...........................................14
8.1. Window Counter Value ......................................15
8.2. Elapsed Time Options ......................................17
8.3. Receive Rate Option .......................................17
8.4. Send Loss Event Rate Feature ..............................18
8.5. Loss Event Rate Option ....................................18
8.6. Loss Intervals Option .....................................18
8.6.1. Option Details .....................................19
8.6.2. Example ............................................20
9. Verifying Congestion Control Compliance with ECN ...............22
9.1. Verifying the ECN Nonce Echo ..............................22
9.2. Verifying the Reported Loss Intervals and Loss
Event Rate ................................................23
10. Implementation Issues .........................................23
10.1. Timestamp Usage ..........................................23
10.2. Determining Loss Events at the Receiver ..................24
10.3. Sending Feedback Packets .................................25
11. Security Considerations .......................................27
12. IANA Considerations ...........................................28
12.1. Reset Codes ..............................................28
12.2. Option Types .............................................28
12.3. Feature Numbers ..........................................28
13. Thanks ........................................................29
A. Appendix: Possible Future Changes to CCID 3 ....................30
Normative References ..............................................31
Informative References ............................................31
6.3. Acknowledgements of Acknowledgements ......................13
6.4. Determining Quiescence ....................................14
7. Explicit Congestion Notification ...............................14
8. Options and Features ...........................................14
8.1. Window Counter Value ......................................15
8.2. Elapsed Time Options ......................................17
8.3. Receive Rate Option .......................................17
8.4. Send Loss Event Rate Feature ..............................18
8.5. Loss Event Rate Option ....................................18
8.6. Loss Intervals Option .....................................18
8.6.1. Option Details .....................................19
8.6.2. Example ............................................20
9. Verifying Congestion Control Compliance with ECN ...............22
9.1. Verifying the ECN Nonce Echo ..............................22
9.2. Verifying the Reported Loss Intervals and Loss
Event Rate ................................................23
10. Implementation Issues .........................................23
10.1. Timestamp Usage ..........................................23
10.2. Determining Loss Events at the Receiver ..................24
10.3. Sending Feedback Packets .................................25
11. Security Considerations .......................................27
12. IANA Considerations ...........................................28
12.1. Reset Codes ..............................................28
12.2. Option Types .............................................28
12.3. Feature Numbers ..........................................28
13. Thanks ........................................................29
A. Appendix: Possible Future Changes to CCID 3 ....................30
Normative References ..............................................31
Informative References ............................................31
List of Tables
表格一览表
Table 1: DCCP CCID 3 Options ......................................14
Table 2: DCCP CCID 3 Feature Numbers ..............................15
Table 1: DCCP CCID 3 Options ......................................14
Table 2: DCCP CCID 3 Feature Numbers ..............................15
This document contains the profile for Congestion Control Identifier 3, TCP-Friendly Rate Control (TFRC), 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]中的拥塞控制标识符3，TCP友好速率控制（TFRC）的配置文件。DCCP使用拥塞控制标识符（CCID）来指定在半连接上使用的拥塞控制机制。
TFRC is a receiver-based congestion control mechanism that provides a TCP-friendly sending rate while minimizing the abrupt rate changes characteristic of TCP or of TCP-like congestion control [RFC3448]. The sender's allowed sending rate is set in response to the loss
TFRC是一种基于接收器的拥塞控制机制，提供TCP友好的发送速率，同时最小化TCP或类似TCP的拥塞控制特性的突然速率变化[RFC3448]。发送方允许的发送速率是为响应丢失而设置的
event rate, which is typically reported by the receiver to the sender. See Section 3 for more on application requirements.
事件速率，通常由接收方报告给发送方。有关应用程序要求的更多信息，请参见第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]中所述进行解释。
All multi-byte numerical quantities in CCID 3, such as arguments to options, are transmitted in network byte order (most significant byte first).
CCID 3中的所有多字节数字量，例如选项的参数，都以网络字节顺序传输（最高有效字节优先）。
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拥塞的数据包。
This document uses a number of variables from [RFC3448], including the following:
本文件使用了[RFC3448]中的许多变量，包括：
o X_recv: The receive rate in bytes per second. See [RFC3448], Section 3.2.2.
o X_recv：以字节/秒为单位的接收速率。参见[RFC3448]，第3.2.2节。
o s: The packet size in bytes. See [RFC3448], Section 3.1.
o s：以字节为单位的数据包大小。参见[RFC3448]，第3.1节。
o p: The loss event rate. See [RFC3448], Section 3.1.
o p：损失事件率。参见[RFC3448]，第3.1节。
CCID 3's TFRC congestion control is appropriate for flows that would prefer to minimize abrupt changes in the sending rate, including streaming media applications with small or moderate receiver buffering before playback. TCP-like congestion control, such as that of DCCP's CCID 2 [RFC4341], halves the sending rate in response to each congestion event and thus cannot provide a relatively smooth sending rate.
CCID 3的TFRC拥塞控制适用于希望将发送速率的突然变化降至最低的流，包括播放前具有小型或中型接收器缓冲的流媒体应用。类似TCP的拥塞控制，如DCCP的CCID 2[RFC4341]的拥塞控制，在响应每个拥塞事件时将发送速率减半，因此无法提供相对平滑的发送速率。
As explained in [RFC3448], Section 1, the penalty of having smoother throughput than TCP while competing fairly for bandwidth with TCP is that the TFRC mechanism in CCID 3 responds slower to changes in available bandwidth than do TCP or TCP-like mechanisms. Thus, CCID 3 should only be used for applications with a requirement for smooth throughput. For applications that simply need to transfer as much data as possible in as short a time as possible, we recommend using TCP-like congestion control, such as CCID 2.
如[RFC3448]第1节所述，在与TCP公平竞争带宽的同时拥有比TCP更平滑的吞吐量的代价是CCID 3中的TFRC机制对可用带宽变化的响应比TCP或类似TCP的机制慢。因此，CCID 3应仅用于要求平滑吞吐量的应用程序。对于只需要在尽可能短的时间内传输尽可能多的数据的应用程序，我们建议使用类似TCP的拥塞控制，如CCID 2。
CCID 3 should also not be used by applications that change their sending rate by varying the packet size, rather than by varying the rate at which packets are sent. A new CCID will be required for these applications.
通过改变数据包大小而不是改变数据包发送速率来改变发送速率的应用程序也不应使用CCID 3。这些应用将需要新的CCID。
The congestion control mechanisms described here follow the TFRC mechanism standardized by the IETF [RFC3448]. Conforming CCID 3 implementations MAY track updates to the TCP throughput equation directly, as updates are standardized in the IETF, rather than wait for revisions of this document. However, conforming implementations SHOULD wait for explicit updates to CCID 3 before implementing other changes to TFRC congestion control.
这里描述的拥塞控制机制遵循IETF标准化的TFRC机制[RFC3448]。符合CCID 3的实施可直接跟踪TCP吞吐量方程的更新，因为更新在IETF中是标准化的，而不是等待本文件的修订。然而，在对TFRC拥塞控制进行其他更改之前，一致性实现应该等待CCID 3的显式更新。
This example shows the typical progress of a half-connection using CCID 3's TFRC Congestion Control, not including connection initiation and termination. The example is informative, not normative.
此示例显示了使用CCID 3的TFRC拥塞控制的半连接的典型过程，不包括连接启动和终止。这个例子是信息性的，而不是规范性的。
1. The sender transmits DCCP-Data packets. Its sending rate is governed by the allowed transmit rate as specified in [RFC3448], Section 3.2. Each DCCP-Data packet has a sequence number and the DCCP header's CCVal field contains the window counter value, which is used by the receiver in determining when multiple losses belong in a single loss event.
1. 发送方发送DCCP数据包。其发送速率由[RFC3448]第3.2节规定的允许传输速率控制。每个DCCP数据包都有一个序列号，DCCP报头的CCVal字段包含窗口计数器值，接收器使用该值确定多个丢失何时属于单个丢失事件。
In the typical case of an ECN-capable half-connection, each DCCP-Data and DCCP-DataAck packet is sent as ECN Capable, with either the ECT(0) or the ECT(1) codepoint set. The use of the ECN Nonce with TFRC is described in Section 9.
在支持ECN的半连接的典型情况下，每个DCCP数据和DCCP DataAck数据包以支持ECN的方式发送，带有ECT（0）或ECT（1）码点集。第9节描述了将ECN Nonce与TFRC一起使用。
2. The receiver sends DCCP-Ack packets acknowledging the data packets at least once per round-trip time, unless the sender is sending at a rate of less than one packet per round-trip time, as indicated by the TFRC specification ([RFC3448], Section 6). Each DCCP-Ack packet uses a sequence number, identifies the most recent packet
2. 接收方发送DCCP Ack数据包，确认数据包在每个往返时间至少发送一次，除非发送方按照TFRC规范（[RFC3448]，第6节）的指示，以小于每个往返时间一个数据包的速率发送数据包。每个DCCP Ack数据包使用一个序列号，标识最近的数据包
received from the sender, and includes feedback about the recent loss intervals experienced by the receiver.
从发送方接收，包括关于接收方最近经历的丢失间隔的反馈。
3. The sender continues sending DCCP-Data packets as controlled by the allowed transmit rate. Upon receiving DCCP-Ack packets, the sender updates its allowed transmit rate as specified in [RFC3448], Section 4.3. This update is based on a loss event rate calculated by the sender using the receiver's loss intervals feedback. If it prefers, the sender can also use a loss event rate calculated and reported by the receiver.
3. 发送方继续发送由允许的传输速率控制的DCCP数据包。收到DCCP Ack数据包后，发送方将按照[RFC3448]第4.3节的规定更新其允许的传输速率。此更新基于发送方使用接收方的丢失间隔反馈计算的丢失事件率。如果愿意，发送方也可以使用接收方计算和报告的损失事件率。
4. The sender estimates round-trip times and calculates a nofeedback time, as specified in [RFC3448], Section 4.4. If no feedback is received from the receiver in that time (at least four round-trip times), the sender halves its sending rate.
4. 发送方根据[RFC3448]第4.4节的规定，估计往返时间并计算无反馈时间。如果在这段时间内（至少四次往返时间）没有收到来自接收方的反馈，则发送方将其发送速率减半。
The client initiates the connection by using mechanisms described in the DCCP specification [RFC4340]. During or after CCID 3 negotiation, the client and/or server may want to negotiate the values of the Send Ack Vector and Send Loss Event Rate features.
客户机使用DCCP规范[RFC4340]中描述的机制启动连接。在CCID 3协商期间或之后，客户端和/或服务器可能希望协商发送确认向量和发送丢失事件率特征的值。
CCID 3 uses the congestion control mechanisms of TFRC [RFC3448]. The following discussion summarizes information from [RFC3448], which should be considered normative except where specifically indicated otherwise.
CCID3使用TFRC[RFC3448]的拥塞控制机制。以下讨论总结了[RFC3448]中的信息，除非另有明确说明，否则这些信息应视为规范性信息。
Loss Event Rate
损失事件率
The basic operation of CCID 3 centers around the calculation of a loss event rate: the number of loss events as a fraction of the number of packets transmitted, weighted over the last several loss intervals. This loss event rate, a round-trip time estimate, and the average packet size are plugged into the TCP throughput equation, as specified in [RFC3448], Section 3.1. The result is a fair transmit rate close to what a modern TCP would achieve in the same conditions. CCID 3 senders are limited to this fair rate.
CCID 3的基本操作围绕着丢失事件率的计算：丢失事件的数量占传输的数据包数量的一小部分，在过去的几个丢失间隔内加权。按照[RFC3448]第3.1节的规定，将该丢失事件率、往返时间估计值和平均数据包大小插入TCP吞吐量方程中。结果是公平的传输速率接近现代TCP在相同条件下的传输速率。CCID 3发送方仅限于此公平费率。
The loss event rate itself is calculated in CCID 3 using recent loss interval lengths reported by the receiver. Loss intervals are precisely defined in Section 6.1. In summary, a loss interval is up to 1 RTT of possibly lost or ECN-marked data packets, followed by an arbitrary number of non-dropped, non-marked data packets. Thus, long loss intervals represent low congestion rates. The CCID 3 Loss
The loss event rate itself is calculated in CCID 3 using recent loss interval lengths reported by the receiver. Loss intervals are precisely defined in Section 6.1. In summary, a loss interval is up to 1 RTT of possibly lost or ECN-marked data packets, followed by an arbitrary number of non-dropped, non-marked data packets. Thus, long loss intervals represent low congestion rates. The CCID 3 Losstranslate error, please retry
Intervals option is used to report loss interval lengths; see Section 8.6.
间隔选项用于报告损失间隔长度；见第8.6节。
Other Congestion Control Mechanisms
其他拥塞控制机制
The sender starts in a slow-start phase, roughly doubling its allowed sending rate each round-trip time. The slow-start phase is ended by the receiver's report of a data packet drop or mark, after which the sender uses the loss event rate to calculate its allowed sending rate.
发送方在缓慢启动阶段启动，每次往返时间大约是其允许发送速率的两倍。缓慢启动阶段由接收方报告数据包丢失或标记而结束，之后发送方使用丢失事件率来计算其允许的发送速率。
[RFC3448], Section 4, specifies an initial sending rate of one packet per round-trip time (RTT) as follows: The sender initializes the allowed sending rate to one packet per second. As soon as a feedback packet is received from the receiver, the sender has a measurement of the round-trip time and then sets the initial allowed sending rate to one packet per RTT. However, while the initial TCP window used to be one segment, [RFC2581] allows an initial TCP window of two segments, and [RFC3390] allows an initial TCP window of three or four segments (up to 4380 bytes). [RFC3390] gives an upper bound on the initial window of min(4*MSS, max(2*MSS, 4380 bytes)).
[RFC3448]第4节规定了每往返时间（RTT）一个数据包的初始发送速率，如下所示：发送方将允许的发送速率初始化为每秒一个数据包。一旦从接收器接收到反馈数据包，发送方就有一个往返时间的测量值，然后将初始允许发送速率设置为每RTT一个数据包。然而，虽然初始TCP窗口过去是一个段，[RFC2581]允许两个段的初始TCP窗口，[RFC3390]允许三个或四个段（最多4380字节）的初始TCP窗口。[RFC3390]给出了最小值（4*MSS，最大值（2*MSS，4380字节））的初始窗口的上限。
Therefore, in contrast to [RFC3448], the initial CCID 3 sending rate is allowed to be at least two packets per RTT, and at most four packets per RTT, depending on the packet size. The initial rate is only allowed to be three or four packets per RTT when, in terms of segment size, that translates to at most 4380 bytes per RTT.
因此，与[RFC3448]相反，初始CCID 3发送速率被允许为每个RTT至少两个分组，并且根据分组大小，每个RTT最多四个分组。初始速率仅允许为每RTT三个或四个数据包，就段大小而言，转换为每RTT最多4380字节。
The sender's measurement of the round-trip time uses the Elapsed Time and/or Timestamp Echo option contained in feedback packets, as described in Section 8.2. The Elapsed Time option is required, while the Timestamp Echo option is not. The sender maintains an average round-trip time heavily weighted on the most recent measurements.
发送方对往返时间的测量使用反馈数据包中包含的经过时间和/或时间戳回音选项，如第8.2节所述。需要经过时间选项，而不需要时间戳回显选项。发送方根据最近的测量值维持平均往返时间。
Each DCCP-Data packet contains a sequence number. Each DCCP-Data packet also contains a window counter value, as described in Section 8.1. The window counter is generally incremented by one every quarter round-trip time. The receiver uses it as a coarse-grained timestamp to determine when a packet loss should be considered part of an existing loss interval and when it must begin a new loss interval.
每个DCCP数据包包含一个序列号。每个DCCP数据包还包含一个窗口计数器值，如第8.1节所述。窗口计数器通常每四分之一往返时间递增一次。接收器将其用作粗粒度时间戳，以确定何时应将数据包丢失视为现有丢失间隔的一部分，以及何时必须开始新的丢失间隔。
Because TFRC is rate-based instead of window-based, and because feedback packets can be dropped in the network, the sender needs some mechanism for reducing its sending rate in the absence of positive feedback from the receiver. As described in Section 6, the receiver sends feedback packets roughly once per round-trip time. As specified in [RFC3448], Section 4.3, the sender sets a nofeedback
由于TFRC是基于速率的，而不是基于窗口的，并且反馈数据包可以在网络中丢弃，因此发送方需要某种机制在没有来自接收方的正反馈的情况下降低其发送速率。如第6节所述，接收器大约每往返时间发送一次反馈数据包。按照[RFC3448]第4.3节的规定，发送方设置NOC反馈
timer to at least four round-trip times, or to twice the interval between data packets, whichever is larger. If the sender hasn't received a feedback packet from the receiver when the nofeedback timer expires, then the sender halves its allowed sending rate. The allowed sending rate is never reduced below one packet per 64 seconds. Note that not all acknowledgements are considered feedback packets, since feedback packets must contain valid Loss Intervals, Elapsed Time, and Receive Rate options.
计时器设置为至少四次往返时间，或数据包之间间隔的两倍，以较大者为准。如果发送方在nofeedback计时器过期时没有收到来自接收方的反馈数据包，则发送方将其允许的发送速率减半。允许的发送速率永远不会低于每64秒一个数据包。请注意，并非所有确认都被视为反馈数据包，因为反馈数据包必须包含有效的丢失间隔、经过的时间和接收速率选项。
If the sender never receives a feedback packet from the receiver, and as a consequence never gets to set the allowed sending rate to one packet per RTT, then the sending rate is left at its initial rate of one packet per second, with the nofeedback timer expiring after two seconds. The allowed sending rate is halved each time the nofeedback timer expires. Thus, if no feedback is received from the receiver, the allowed sending rate is never above one packet per second and is quickly reduced below one packet per second.
如果发送方从未收到来自接收方的反馈数据包，并且因此从未将允许的发送速率设置为每RTT一个数据包，则发送速率保持在其初始速率每秒一个数据包，且无反馈计时器在两秒后过期。每次nofeedback计时器过期时，允许的发送速率将减半。因此，如果没有从接收机接收到反馈，则允许的发送速率从不高于每秒一个分组，并且迅速降低到每秒一个分组以下。
The feedback packets from the receiver contain a Receive Rate option specifying the rate at which data packets arrived at the receiver since the last feedback packet. The allowed sending rate can be at most twice the rate received at the receiver in the last round-trip time. This may be less than the nominal fair rate if, for example, the application is sending less than its fair share.
来自接收器的反馈分组包含一个接收速率选项，该选项指定自上次反馈分组以来数据分组到达接收器的速率。允许的发送速率最多可以是接收器在上一次往返时间内接收速率的两倍。例如，如果应用程序发送的数据少于其公平份额，则这可能低于名义公平费率。
One consequence of the nofeedback timer is that the sender reduces the allowed sending rate when the sender has been idle for a significant period of time. In [RFC3448], Section 4.4, the allowed sending rate is never reduced to fewer than two packets per round-trip time as the result of an idle period. CCID 3 revises this to take into account the larger initial windows allowed by [RFC3390]: the allowed sending rate is never reduced to less than the [RFC3390] initial sending rate as the result of an idle period. If the allowed sending rate is less than the initial sending rate upon entry to the idle period, then it will still be less than the initial sending rate when the idle period is exited. However, if the allowed sending rate is greater than or equal to the initial sending rate upon entry to the idle period, then it should not be reduced below the initial sending rate no matter how long the idle period lasts.
nofeedback定时器的一个结果是，当发送方空闲了很长一段时间时，发送方降低了允许的发送速率。在[RFC3448]第4.4节中，由于空闲时间的原因，允许的发送速率不会降低到每次往返时间少于两个数据包。CCID 3对此进行了修改，以考虑[RFC3390]允许的较大初始窗口：由于空闲时间，允许的发送速率不会降低到小于[RFC3390]初始发送速率。如果进入空闲时间段时允许的发送速率小于初始发送速率，则在空闲时间段退出时仍将小于初始发送速率。但是，如果进入空闲期时允许的发送速率大于或等于初始发送速率，则无论空闲期持续多长，都不应将其降低到初始发送速率以下。
The sender's allowed sending rate is limited to at most twice the receive rate reported by the receiver. Thus, after an application-limited period, the sender can at most double its sending rate from one round-trip time to the next, until it reaches the allowed sending rate determined by the loss event rate.
发送方允许的发送速率最多限制为接收方报告的接收速率的两倍。因此，在应用程序限制期之后，发送方最多可以将其发送速率从一个往返时间增加一倍，直到达到由丢失事件速率确定的允许发送速率。
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. Its 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 3 senders respond to these options as described in [RFC4340], with the following further clarifications.
DCCP的数据丢弃选项允许接收方声明数据包在交付到应用程序之前已在终端主机上丢弃——例如，由于损坏或接收缓冲区溢出。它的Slow Receiver选项允许接收者声明其无法跟上发送者的数据包，尽管尚未丢弃任何数据包。CCID 3发送方对[RFC4340]中所述的这些选项作出响应，并做出以下进一步澄清。
o Drop Code 2 ("receive buffer drop"). The allowed sending rate is reduced by one packet per RTT for each packet newly acknowledged as Drop Code 2, except that it is never reduced below one packet per RTT as a result of Drop Code 2.
o 删除代码2（“接收缓冲区删除”）。对于新确认为丢弃代码2的每个数据包，允许的发送速率每RTT减少一个数据包，但决不会由于丢弃代码2而降低到每RTT一个数据包以下。
o Adjusting the receive rate X_recv. A CCID 3 sender SHOULD also respond to non-network-congestion events, such as those implied by Data Dropped and Slow Receiver options, by adjusting X_recv, the receive rate reported by the receiver in Receive Rate options (see Section 8.3). The CCID 3 sender's allowed sending rate is limited to at most twice the receive rate reported by the receiver via the "min(..., 2*X_recv)" clause in TFRC's throughput calculations ([RFC3448], Section 4.3). When the sender receives one or more Data Dropped and Slow Receiver options, the sender adjusts X_recv as follows:
o 调整接收速率X_recv。CCID 3发送方还应通过调整X_recv，即接收方在接收速率选项中报告的接收速率，来响应非网络拥塞事件，如数据丢失和慢速接收方选项所暗示的事件（见第8.3节）。CCID 3发送方的允许发送速率限制为接收方通过TFRC吞吐量计算中的“min（…，2*X_recv）”条款报告的接收速率的两倍（[RFC3448]，第4.3节）。当发送方接收到一个或多个数据丢弃和慢速接收选项时，发送方将调整X_recv，如下所示：
1. X_inrecv is equal to the Receive Rate in bytes per second reported by the receiver in the most recent acknowledgement.
1. X_inrecv等于接收器在最近一次确认中报告的接收速率（字节/秒）。
2. X_drop is set to the sending rate upper bound implied by Data Dropped and Slow Receiver options. If the sender receives a Slow Receiver option, which requests that the sender not increase its sending rate for roughly a round-trip time [RFC4340], then X_drop should be set to X_inrecv. Similarly, if the sender receives a Data Dropped option indicating, for example, that three packets were dropped with Drop Code 2, then the upper bound on the sending rate will be decreased by at most three packets per RTT, by the sender setting X_drop to
2. X_drop设置为数据丢弃和慢速接收器选项所暗示的发送速率上限。如果发送方收到一个慢速接收选项，该选项要求发送方在大约一个往返时间内不增加其发送速率[RFC4340]，则X_drop应设置为X_inrecv。类似地，如果发送方接收到一个数据丢弃选项，该选项指示，例如，使用丢弃代码2丢弃了三个数据包，则发送方将X_Drop设置为，发送速率的上限每RTT最多减少三个数据包
max(X_inrecv - 3*s/RTT, min(X_inrecv, s/RTT)).
最大值（X_inrecv-3*s/RTT，最小值（X_inrecv，s/RTT））。
Again, s is the packet size in bytes.
同样，s是以字节为单位的数据包大小。
3. X_recv is then set to min(X_inrecv, X_drop/2).
3. 然后将X_recv设置为min（X_inrecv，X_drop/2）。
As a result, the next round-trip time's sending rate will be limited to at most 2*(X_drop/2) = X_drop. The effects of the Slow Receiver and Data Dropped options on X_recv will mostly vanish by
因此，下一次往返时间的发送速率将限制为最多2*（X_-drop/2）=X_-drop。慢接收机和数据丢失选项对X_recv的影响将在2015年基本消失
the round-trip time after that, which is appropriate for this non-network-congestion feedback. This procedure MUST only be used for those Drop Codes not related to corruption (see [RFC4340]). Currently, this is limited to Drop Codes 0, 1, and 2.
之后的往返时间，适用于此非网络拥塞反馈。此程序只能用于与损坏无关的删除代码（请参阅[RFC4340]）。目前，这仅限于删除代码0、1和2。
CCID 3 is intended for applications that use a fixed packet size, and that vary their sending rate in packets per second in response to congestion. CCID 3 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. However, some attention might be required for applications using CCID 3 that vary their packet size not in response to congestion, but in response to other application-level requirements.
CCID 3适用于使用固定数据包大小的应用程序，这些应用程序根据拥塞情况以每秒数据包的形式改变发送速率。CCID 3不适用于需要在数据包之间有固定时间间隔并根据拥塞情况改变数据包大小而不是数据包速率的应用程序。然而，对于使用CCID 3的应用程序，可能需要注意其数据包大小的变化不是为了响应拥塞，而是为了响应其他应用程序级别的要求。
The packet size s is used in the TCP throughput equation. A CCID 3 implementation MAY calculate s as the segment size averaged over multiple round trip times -- for example, over the most recent four loss intervals, for loss intervals as defined in Section 6.1. Alternately, a CCID 3 implementation MAY use the Maximum Packet Size to derive s. In this case, s is set to the Maximum Segment Size (MSS), the maximum size in bytes for the data segment, not including the default DCCP and IP packet headers. Each packet transmitted then counts as one MSS, regardless of the actual segment size, and the TCP throughput equation can be interpreted as specifying the sending rate in packets per second.
数据包大小s用于TCP吞吐量等式。CCID 3实施可将s计算为多个往返时间的平均段大小——例如，对于第6.1节中定义的损耗间隔，最近四个损耗间隔的平均段大小。或者，ccid3实现可以使用最大分组大小来导出s。在这种情况下，s被设置为最大段大小（MSS），即数据段的最大字节大小，不包括默认的DCCP和IP数据包头。然后，无论实际段大小如何，发送的每个数据包都算作一个MSS，TCP吞吐量方程可以解释为指定每秒数据包的发送速率。
CCID 3 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].)
CCID3实现可能会检查似乎不适当地操纵数据包大小的应用程序。例如，一个应用程序可能会发送一段时间的小数据包，建立一个快速率，然后切换到大数据包以利用快速率。（初步模拟表明，应用程序可能无法以这种方式增加其总传输速率，因此不清楚这种操纵是否会在实践中发生[V03]。）
The receiver sends a feedback packet to the sender roughly once per round-trip time, if the sender is sending packets that frequently. This rate is determined by the TFRC protocol as specified in [RFC3448], Section 6.
如果发送方发送数据包的频率如此之高，那么接收方大约每往返一次就向发送方发送一个反馈数据包。该速率由[RFC3448]第6节规定的TFRC协议确定。
Each feedback packet contains an Acknowledgement Number, which equals the greatest valid sequence number received so far on this connection. ("Greatest" is, of course, measured in circular sequence space.) Each feedback packet also includes at least the following options:
每个反馈数据包都包含一个确认号，该确认号等于此连接上迄今为止收到的最大有效序列号。（“最大”当然是在循环序列空间中测量的。）每个反馈包还至少包括以下选项：
1. An Elapsed Time and/or Timestamp Echo option specifying the amount of time elapsed since the arrival at the receiver of the packet whose sequence number appears in the Acknowledgement Number field. These options are described in [RFC4340], Section 13.
1. 已用时间和/或时间戳回显选项，指定序列号出现在确认号字段中的数据包到达接收器后经过的时间量。[RFC4340]第13节介绍了这些选项。
2. A Receive Rate option, defined in Section 8.3, specifying the rate at which data was received since the last DCCP-Ack was sent.
2. 第8.3节中定义的接收速率选项，指定自上次DCCP Ack发送以来接收数据的速率。
3. A Loss Intervals option, defined in Section 8.6, specifying the most recent loss intervals experienced by the receiver. (The definition of a loss interval is provided below.) From Loss Intervals, the sender can easily calculate the loss event rate p using the procedure described in [RFC3448], Section 5.4.
3. 第8.6节中定义的损耗间隔选项，指定接收机最近经历的损耗间隔。（损失间隔的定义如下。）根据损失间隔，发送方可以使用[RFC3448]第5.4节中描述的程序轻松计算损失事件率p。
Acknowledgements not containing at least these three options are not considered feedback packets.
至少不包含这三个选项的确认不被视为反馈数据包。
The receiver MAY also include other options concerning the loss event rate, including Loss Event Rate, which gives the loss event rate calculated by the receiver (Section 8.5), and DCCP's generic Ack Vector option, which reports the specific sequence numbers of any lost or marked packets ([RFC4340], Section 11.4). Ack Vector is not required by CCID 3's congestion control mechanisms: the Loss Intervals option provides all the information needed to manage the transmit rate and probabilistically verify receiver feedback. However, Ack Vector may be useful for applications that need to determine exactly which packets were lost. The receiver MAY also include other acknowledgement-related options, such as DCCP's Data Dropped option ([RFC4340], Section 11.7).
接收机还可以包括关于丢失事件速率的其他选项，包括丢失事件速率，它给出了接收机计算的丢失事件速率（第8.5节），以及DCCP的通用Ack向量选项，它报告任何丢失或标记的分组的特定序列号（[RFC4340]，第11.4节）。CCID 3的拥塞控制机制不需要Ack向量：丢失间隔选项提供管理传输速率和概率验证接收器反馈所需的所有信息。然而，对于需要准确确定哪些数据包丢失的应用程序，Ack向量可能很有用。接收机还可以包括其他与确认相关的选项，例如DCCP的数据丢弃选项（[RFC4340]，第11.7节）。
If the HC-Receiver is also sending data packets to the HC-Sender, then it MAY piggyback acknowledgement information on those data packets more frequently than TFRC's specified acknowledgement rate allows.
如果HC接收器也向HC发送器发送数据包，则其可能比TFRC的指定确认率允许的更频繁地在这些数据包上携带确认信息。
As described in [RFC3448], Section 5.2, a loss interval begins with a lost or ECN-marked data packet; continues with at most one round-trip time's worth of packets that may or may not be lost or marked; and completes with an arbitrarily long series of non-dropped, non-marked data packets. For example, here is a single loss interval, assuming that sequence numbers increase as you move right:
如[RFC3448]第5.2节所述，丢失间隔从丢失或带有ECN标记的数据包开始；继续使用最多一个往返时间的数据包，这些数据包可能会丢失或标记，也可能不会丢失或标记；并以任意长系列的未丢弃、未标记的数据包完成。例如，这里是一个单一的丢失间隔，假设序列号随着您向右移动而增加：
Lossy Part
<= 1 RTT __________ Lossless Part __________
/ \/ \
*----*--*--*-------------------------------------
^ ^ ^ ^
losses or marks
Lossy Part
<= 1 RTT __________ Lossless Part __________
/ \/ \
*----*--*--*-------------------------------------
^ ^ ^ ^
losses or marks
Note that a loss interval's lossless part might be empty, as in the first interval below:
请注意，丢失间隔的无损部分可能为空，如下面的第一个间隔中所示：
Lossy Part Lossy Part
<= 1 RTT <= 1 RTT _____ Lossless Part _____
/ \/ \/ \
*----*--*--***--------*-*---------------------------
^ ^ ^ ^^^ ^ ^
\_ Int. 1 _/\_____________ Interval 2 _____________/
Lossy Part Lossy Part
<= 1 RTT <= 1 RTT _____ Lossless Part _____
/ \/ \/ \
*----*--*--***--------*-*---------------------------
^ ^ ^ ^^^ ^ ^
\_ Int. 1 _/\_____________ Interval 2 _____________/
As in [RFC3448], Section 5.2, the length of the lossy part MUST be less than or equal to 1 RTT. CCID 3 uses window counter values, not receive times, to determine whether multiple packets occurred in the same RTT and thus belong to the same loss event; see Section 10.2. A loss interval whose lossy part lasts for more than 1 RTT, or whose lossless part contains a dropped or marked data packet, is invalid.
如[RFC3448]第5.2节所述，有损零件的长度必须小于或等于1 RTT。CCID3使用窗口计数器值而不是接收时间来确定多个数据包是否发生在同一RTT中，因此属于同一丢失事件；见第10.2节。有损部分持续超过1 RTT的丢失间隔，或其无损部分包含丢弃或标记的数据包的丢失间隔无效。
A missing data packet doesn't begin a new loss interval until NDUPACK packets have been seen after the "hole", where NDUPACK = 3. Thus, up to NDUPACK of the most recent sequence numbers (including the sequence numbers of any holes) might temporarily not be part of any loss interval while the implementation waits to see whether a hole will be filled. See [RFC3448], Section 5.1, and [RFC2581], Section 3.2, for further discussion of NDUPACK.
丢失的数据包不会开始新的丢失间隔，直到在“洞”之后看到NDUPACK数据包，其中NDUPACK=3。因此，在实现等待是否填充孔时，最新的序列号（包括任何孔的序列号）可能暂时不属于任何丢失间隔的一部分。有关NDUPACK的进一步讨论，请参见[RFC3448]第5.1节和[RFC2581]第3.2节。
As specified by [RFC3448], Section 5, all loss intervals except the first begin with a lost or marked data packet, and all loss intervals are as long as possible, subject to the validity constraints above.
根据[RFC3448]第5节的规定，除第一个丢失间隔外，所有丢失间隔都以丢失或标记的数据包开始，并且所有丢失间隔都尽可能长，受上述有效性约束的约束。
Lost and ECN-marked non-data packets may occur freely in the lossless part of a loss interval. (Non-data packets consist of those packet types that cannot carry application data; namely, DCCP-Ack, DCCP-Close, DCCP-CloseReq, DCCP-Reset, DCCP-Sync, and DCCP-SyncAck.) In the absence of better information, a receiver MUST conservatively assume that every lost packet was a data packet and thus must occur in some lossy part. DCCP's NDP Count option can help the receiver determine whether a particular packet contained data; see [RFC4340], Section 7.7.
丢失和ECN标记的非数据分组可以在丢失间隔的无损部分自由发生。（非数据包由不能承载应用程序数据的包类型组成；即DCCP Ack、DCCP Close、DCCP CLOSERQ、DCCP Reset、DCCP Sync和DCCP SyncAck。）在没有更好的信息的情况下，接收器必须保守地假设每个丢失的包都是数据包，因此必须发生在某个有损部分。DCCP的NDP计数选项可帮助接收器确定特定数据包是否包含数据；见[RFC4340]，第7.7节。
[RFC3448] defines the TFRC congestion control mechanism in terms of a one-way transfer of data, with data packets going from the sender to the receiver and feedback packets going from the receiver back to the sender. However, CCID 3 applies in a context of two half-connections, with DCCP-Data and DCCP-DataAck packets from one half-connection sharing sequence number space with DCCP-Ack packets from the other half-connection. For the purposes of CCID 3 congestion control, loss interval lengths should include data packets and should exclude the acknowledgement packets from the reverse half-connection. However, it is also useful to report the total number of packets in each loss interval (for example, to facilitate ECN Nonce verification).
[RFC3448]根据数据的单向传输定义TFRC拥塞控制机制，数据包从发送方传输到接收方，反馈数据包从接收方传输回发送方。然而，CCID 3适用于两个半连接的上下文，其中来自一个半连接的DCCP数据和DCCP DATACK数据包与来自另一个半连接的DCCP Ack数据包共享序列号空间。为了CCID 3拥塞控制的目的，丢失间隔长度应该包括数据包，并且应该从反向半连接中排除确认包。但是，报告每个丢失间隔中的数据包总数也很有用（例如，为了便于ECN Nonce验证）。
CCID 3's Loss Intervals option thus reports three lengths for each loss interval, the lengths of the lossy and lossless parts defined above and a separate data length. First, the lossy and lossless lengths are measured in sequence numbers. Together, they sum to the interval's sequence length, which is the total number of packets the sender transmitted during the interval. This is easily calculated in DCCP as the greatest packet sequence number in the interval minus the greatest packet sequence number in the preceding interval (or, if there is no preceding interval, then the predecessor to the half-connection's initial sequence number). The interval's data length, however, is the number used in TFRC's loss event rate calculation, as defined in [RFC3448], Section 5, and is calculated as follows.
CCID 3的损耗间隔选项因此报告了每个损耗间隔的三个长度、上面定义的损耗和无损部分的长度以及一个单独的数据长度。首先，有损和无损长度以序列号测量。它们加在一起等于间隔的序列长度，即发送方在间隔期间传输的数据包总数。在DCCP中，这很容易计算为间隔中的最大数据包序列号减去前一个间隔中的最大数据包序列号（或者，如果没有前一个间隔，则为半连接初始序列号的前一个）。然而，间隔的数据长度是TFRC损失事件率计算中使用的数字，如[RFC3448]第5节中所定义，计算如下。
For all loss intervals except the first, the data length equals the sequence length minus the number of non-data packets the sender transmitted during the loss interval, except that the minimum data length is one packet. In the absence of better information, an endpoint MUST conservatively assume that the loss interval contained only data packets, in which case the data length equals the sequence length. To achieve greater precision, the sender can calculate the exact number of non-data packets in an interval by remembering which sent packets contained data; the receiver can account for received non-data packets by not including them in the data length, and for packets that were not received, it may be able to discriminate between lost data packets and lost non-data packets using DCCP's NDP Count option.
对于除第一个丢失间隔外的所有丢失间隔，数据长度等于序列长度减去发送方在丢失间隔期间发送的非数据包数，但最小数据长度为一个包除外。在没有更好的信息的情况下，端点必须保守地假设丢失间隔仅包含数据包，在这种情况下，数据长度等于序列长度。为了获得更高的精度，发送方可以通过记住哪些发送的包包含数据来计算间隔内非数据包的确切数量；接收机可以通过不将接收到的非数据分组包括在数据长度中来说明它们，并且对于未接收到的分组，接收机可以使用DCCP的NDP Count选项来区分丢失的数据分组和丢失的非数据分组。
The first loss interval's data length is undefined until the first loss event. [RFC3448], Section 6.3.1 specifies how the first loss interval's data length is calculated once the first loss event has occurred; this calculation uses X_recv, the most recent receive rate, as input. Until this first loss event, the loss event rate is zero,
在发生第一次丢失事件之前，第一次丢失间隔的数据长度是未定义的。[RFC3448]，第6.3.1节规定了第一次损失事件发生后如何计算第一次损失间隔的数据长度；此计算使用X_recv（最近的接收速率）作为输入。在发生第一次损失事件之前，损失事件率为零，
as is the data length reported for the interval in the Loss Intervals option.
“丢失间隔”选项中为间隔报告的数据长度为。
The first loss interval's data length might be less than, equal to, or even greater than its sequence length. Any other loss interval's data length must be less than or equal to its sequence length.
第一个丢失间隔的数据长度可能小于、等于甚至大于其序列长度。任何其他丢失间隔的数据长度必须小于或等于其序列长度。
A sender MAY use the loss event rate or loss interval data lengths as reported by the receiver, or it MAY recalculate loss event rate and/or loss interval data lengths based on receiver feedback and additional information. For example, assume the network drops a DCCP-Ack packet with sequence number 50. The receiver might then report a loss interval beginning at sequence number 50. If the sender determined that this loss interval actually contained no lost or ECN-marked data packets, then it might coalesce the loss interval with the previous loss interval, resulting in a larger allowed transmit rate.
发送方可以使用接收方报告的丢失事件率或丢失间隔数据长度，也可以基于接收方反馈和其他信息重新计算丢失事件率和/或丢失间隔数据长度。例如，假设网络丢弃序列号为50的DCCP Ack数据包。然后，接收机可能报告从序列号50开始的丢失间隔。如果发送方确定此丢失间隔实际上不包含丢失或带有ECN标记的数据包，则它可能会将丢失间隔与前一个丢失间隔合并，从而产生更大的允许传输速率。
The rate and timing for generating acknowledgements is determined by the TFRC algorithm ([RFC3448], Section 6). The sending rate for acknowledgements is relatively low -- roughly once per round-trip time -- so there is no need for explicit congestion control on acknowledgements.
生成确认的速率和定时由TFRC算法确定（[RFC3448]，第6节）。确认的发送速率相对较低——大约每往返一次——因此不需要对确认进行显式拥塞控制。
TFRC acknowledgements don't generally need to be reliable, so the sender generally need not acknowledge the receiver's acknowledgements. When Ack Vector or Data Dropped is used, however, the sender, DCCP A, MUST occasionally acknowledge the receiver's acknowledgements so that the receiver can free up Ack Vector or Data Dropped state. When both half-connections are active, the necessary acknowledgements will be contained in A's acknowledgements to B's data. If the B-to-A half-connection goes quiescent, however, DCCP A must send an acknowledgement proactively.
TFRC确认通常不需要可靠，因此发送方通常不需要确认接收方的确认。然而，当使用Ack向量或数据丢弃时，发送方DCCP A必须偶尔确认接收方的确认，以便接收方可以释放Ack向量或数据丢弃状态。当两个半连接都处于活动状态时，必要的确认将包含在A对B数据的确认中。但是，如果B-to-A连接处于静止状态，DCCP A必须主动发送确认。
Thus, when Ack Vector or Data Dropped is used, an active sender MUST acknowledge the receiver's acknowledgements approximately once per round-trip time, within a factor of two or three, probably by sending a DCCP-DataAck packet. No acknowledgement options are necessary, just the Acknowledgement Number in the DCCP-DataAck header.
因此，当使用Ack向量或丢弃的数据时，活动发送方必须大约每往返时间在两到三倍的范围内确认接收方的确认一次，可能通过发送DCCP DataAck分组。不需要确认选项，只需DCCP数据包头中的确认号。
The sender MAY choose to acknowledge the receiver's acknowledgements even if they do not contain Ack Vectors or Data Dropped options. For instance, regular acknowledgements can shrink the size of the Loss Intervals option. Unlike Ack Vector and Data Dropped, however, the
发送方可以选择确认接收方的确认，即使它们不包含确认向量或数据丢弃选项。例如，定期确认可以缩小丢失间隔选项的大小。但是，与Ack向量和丢弃的数据不同
Loss Intervals option is bounded in size (and receiver state), so acks-of-acks are not required.
丢失间隔选项在大小（和接收器状态）上是有界的，因此不需要ACK的ACK。
This section describes how a CCID 3 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 3接收器如何确定相应的发送方未发送任何数据，因此已处于静止状态。有关静止的一般信息，请参见[RFC4340]，第11.1节。
Let T equal the greater of 0.2 seconds and two round-trip times. (A CCID 3 receiver has a rough measure of the round-trip time so that it can pace its acknowledgements.) The receiver detects that the sender has gone quiescent after T seconds have passed without receiving any additional data from the sender.
T等于0.2秒和两个往返时间中的较大者。（CCID 3接收器对往返时间有一个粗略的测量，以便它能够调整其确认的速度。）接收器检测到，在T秒过去之后，发送方已经停止，而没有从发送方接收任何额外的数据。
CCID 3 supports Explicit Congestion Notification (ECN) [RFC3168]. In the typical case of an ECN-capable half-connection (where the receiver's ECN Incapable feature is set to zero), the sender will use the ECN Nonce for its data packets, as specified in [RFC4340], Section 12.2. Information about the ECN Nonce MUST be returned by the receiver using the Loss Intervals option, and any Ack Vector options MUST include the ECN Nonce Sum. The sender MAY maintain a table with the ECN nonce sum for each packet and use this information to probabilistically verify the ECN nonce sums returned in Loss Intervals or Ack Vector options. Section 9 describes this further.
CCID3支持显式拥塞通知（ECN）[RFC3168]。在支持ECN的半连接的典型情况下（接收机的不支持ECN功能设置为零），发送方将按照[RFC4340]第12.2节的规定，对其数据包使用ECN Nonce。接收机必须使用丢失间隔选项返回有关ECN Nonce的信息，并且任何Ack向量选项必须包括ECN Nonce和。发送方可维护具有每个分组的ECN nonce和的表，并使用该信息来概率地验证在丢失间隔或Ack向量选项中返回的ECN nonce和。第9节对此作了进一步描述。
CCID 3 can make use of DCCP's Ack Vector, Timestamp, Timestamp Echo, and Elapsed Time options, and its Send Ack Vector and ECN Incapable features. In addition, the following CCID-specific options are defined for use with CCID 3.
CCID3可以利用DCCP的Ack向量、时间戳、时间戳回音和经过时间选项，以及其发送Ack向量和ECN功能。此外，还定义了以下CCID特定选项，以便与CCID 3一起使用。
Option DCCP- Section
Type Length Meaning Data? Reference
----- ------ ------- ----- ---------
128-191 Reserved
192 6 Loss Event Rate N 8.5
193 variable Loss Intervals N 8.6
194 6 Receive Rate N 8.3
195-255 Reserved
Option DCCP- Section
Type Length Meaning Data? Reference
----- ------ ------- ----- ---------
128-191 Reserved
192 6 Loss Event Rate N 8.5
193 variable Loss Intervals N 8.6
194 6 Receive Rate N 8.3
195-255 Reserved
Table 1: DCCP CCID 3 Options
表1:DCCP CCID 3选项
The "DCCP-Data?" column indicates that all currently defined CCID 3- specific options MUST be ignored when they occur on DCCP-Data packets.
“DCCP数据”列表示当前定义的所有CCID 3特定选项在DCCP数据包上出现时必须忽略。
The following CCID-specific feature is also defined.
还定义了以下CCID特定功能。
Rec'n Initial Section
Number Meaning Rule Value Req'd Reference
------ ------- ----- ----- ----- ---------
128-191 Reserved
192 Send Loss Event Rate SP 0 N 8.4
193-255 Reserved
Rec'n Initial Section
Number Meaning Rule Value Req'd Reference
------ ------- ----- ----- ----- ---------
128-191 Reserved
192 Send Loss Event Rate SP 0 N 8.4
193-255 Reserved
Table 2: DCCP CCID 3 Feature Numbers
表2:DCCP CCID 3功能编号
The column meanings are described in [RFC4340], Table 4. "Rec'n Rule" defines the feature's reconciliation rule, where "SP" means server-priority. "Req'd" specifies whether every CCID 3 implementation MUST understand a feature; Send Loss Event Rate is optional, in that it behaves like an extension ([RFC4340], Section 15).
[RFC4340]表4中描述了列的含义。“对账规则”定义了功能的对账规则，“SP”表示服务器优先级。“Req'd”指定每个CCID3实现是否必须理解一个特性；发送丢失事件速率是可选的，因为它的行为类似于扩展（[RFC4340]，第15节）。
The data sender stores a 4-bit window counter value in the DCCP generic header's CCVal field on every data packet it sends. This value is set to 0 at the beginning of the transmission and generally increased by 1 every quarter of a round-trip time, as described in [RFC3448], Section 3.2.1. Window counters use circular arithmetic modulo 16 for all operations, including comparisons; see [RFC4340], Section 3.1, for more information on circular arithmetic. For reference, the DCCP generic header is as follows. (The diagram is repeated from [RFC4340], Section 5.1, which also shows the generic header with a 24-bit Sequence Number field.)
数据发送方在其发送的每个数据包的DCCP通用报头的CCVal字段中存储一个4位窗口计数器值。如[RFC3448]第3.2.1节所述，该值在传输开始时设置为0，通常每四分之一往返时间增加1。窗口计数器对所有操作（包括比较）使用循环算术模16；有关循环算术的更多信息，请参见[RFC4340]，第3.1节。作为参考，DCCP通用头如下所示。（该图从[RFC4340]第5.1节重复，该节还显示了带有24位序列号字段的通用报头。）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Type |1| Reserved | Sequence Number (high bits) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Sequence Number (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Type |1| Reserved | Sequence Number (high bits) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Sequence Number (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CCVal field has enough space to express 4 round-trip times at quarter-RTT granularity. The sender MUST avoid wrapping CCVal on adjacent packets, as might happen, for example, if two data-carrying packets were sent 4 round-trip times apart with no packets intervening. Therefore, the sender SHOULD use the following algorithm for setting CCVal. The algorithm uses three variables: "last_WC" holds the last window counter value sent, "last_WC_time" is the time at which the first packet with window counter value "last_WC" was sent, and "RTT" is the current round-trip time estimate. last_WC is initialized to zero, and last_WC_time to the time of the first packet sent. Before sending a new packet, proceed like this:
CCVal字段有足够的空间以四分之一RTT粒度表示4次往返时间。发送方必须避免将CCVal包装到相邻的数据包上，例如，如果两个携带数据的数据包在没有数据包干预的情况下间隔发送4次往返，则可能会发生这种情况。因此，发送方应使用以下算法设置CCVal。该算法使用三个变量：“last_WC”保存发送的最后一个窗口计数器值，“last_WC_time”是发送窗口计数器值为“last_WC”的第一个数据包的时间，“RTT”是当前往返时间估计值。last_WC初始化为零，last_WC_time初始化为发送第一个数据包的时间。在发送新数据包之前，请按照以下步骤进行操作：
Let quarter_RTTs = floor((current_time - last_WC_time) / (RTT/4)).
If quarter_RTTs > 0, then:
Set last_WC := (last_WC + min(quarter_RTTs, 5)) mod 16.
Set last_WC_time := current_time.
Set the packet header's CCVal field to last_WC.
Let quarter_RTTs = floor((current_time - last_WC_time) / (RTT/4)).
If quarter_RTTs > 0, then:
Set last_WC := (last_WC + min(quarter_RTTs, 5)) mod 16.
Set last_WC_time := current_time.
Set the packet header's CCVal field to last_WC.
When this algorithm is used, adjacent data-carrying packets' CCVal counters never differ by more than five, modulo 16.
使用此算法时，相邻数据包的CCVal计数器的差值永远不会超过5，模16。
The window counter value may also change as feedback packets arrive. In particular, after receiving an acknowledgement for a packet sent with window counter WC, the sender SHOULD increase its window counter, if necessary, so that subsequent packets have window counter value at least (WC + 4) mod 16.
窗口计数器值也可能随着反馈数据包的到达而改变。特别是，在接收到使用窗口计数器WC发送的数据包的确认后，发送方应在必要时增加其窗口计数器，以便后续数据包的窗口计数器值至少为（WC+4）mod 16。
The CCVal counters are used by the receiver to determine whether multiple losses belong to a single loss event, to determine the interval to use for calculating the receive rate, and to determine when to send feedback packets. None of these procedures require the receiver to maintain an explicit estimate of the round-trip time. However, implementors who wish to keep such an RTT estimate may do so using CCVal. Let T(I) be the arrival time of the earliest valid received packet with CCVal = I. (Of course, when the window counter value wraps around to the same value mod 16, we must recalculate T(I).) Let D = 2, 3, or 4 and say that T(K) and T(K+D) both exist (packets were received with window counters K and K+D). Then the value (T(K+D) - T(K)) * 4/D MAY serve as an estimate of the round-trip time. Values of D = 4 SHOULD be preferred for RTT estimation. Concretely, say that the following packets arrived:
接收机使用CCVal计数器来确定多个丢失是否属于单个丢失事件，确定用于计算接收速率的间隔，以及确定何时发送反馈数据包。这些程序都不要求接收者保持对往返时间的明确估计。然而，希望保持这种RTT估计的实现者可以使用CCVal来实现。设T（I）为CCVal=I的最早有效接收数据包的到达时间（当然，当窗口计数器值变为相同的mod 16时，我们必须重新计算T（I）。）设D=2、3或4，并假设T（K）和T（K+D）都存在（数据包是用窗口计数器K和K+D接收的）。然后，值（T（K+D）-T（K））*4/D可用作往返时间的估计。RTT估算应首选D=4的值。具体来说，假设以下数据包到达：
Time: T1 T2 T3 T4 T5 T6 T7 T8 T9
------*---*---*-*----*------------*---*----*--*---->
CCVal: K-1 K-1 K K K+1 K+3 K+4 K+3 K+4
Time: T1 T2 T3 T4 T5 T6 T7 T8 T9
------*---*---*-*----*------------*---*----*--*---->
CCVal: K-1 K-1 K K K+1 K+3 K+4 K+3 K+4
Then T7 - T3, the difference between the receive times of the first packet received with window counter K+4 and the first packet received with window counter K, is a reasonable round-trip time estimate. Because of the necessary constraint that measurements only come from packet pairs whose CCVals differ by at most 4, this procedure does not work when the inter-packet sending times are significantly greater than the RTT, resulting in packet pairs whose CCVals differ by 5. Explicit RTT measurement techniques, such as Timestamp and Timestamp Echo, should be used in that case.
然后T7-T3，即使用窗口计数器K+4接收的第一个分组与使用窗口计数器K接收的第一个分组之间的接收时间差，是合理的往返时间估计。由于测量仅来自CCVAL相差最多4的数据包对的必要限制，当数据包间发送时间明显大于RTT时，此过程不起作用，从而导致CCVAL相差5的数据包对。在这种情况下，应使用明确的RTT测量技术，如时间戳和时间戳回波。
The data receiver MUST include an elapsed time value on every required acknowledgement. This helps the sender distinguish between network round-trip time, which it must include in its rate equations, and delay at the receiver due to TFRC's infrequent acknowledgement rate, which it need not include. The receiver MUST at least include an Elapsed Time option on every feedback packet, but if at least one recent data packet (i.e., a packet received after the previous DCCP-Ack was sent) included a Timestamp option, then the receiver SHOULD include the corresponding Timestamp Echo option, with Elapsed Time value, as well. All of these option types are defined in the main DCCP specification [RFC4340].
数据接收器必须在每个需要的确认上包含经过的时间值。这有助于发送方区分网络往返时间（它必须包含在其速率方程中）和由于TFRC的不频繁确认率（它不需要包含）而导致的接收方延迟。接收机必须至少在每个反馈分组上包括经过时间选项，但是如果至少一个最近的数据分组（即，在发送前一个DCCP Ack之后接收的分组）包括时间戳选项，则接收机还应包括具有经过时间值的对应时间戳Echo选项。所有这些选项类型都在主DCCP规范[RFC4340]中定义。
+--------+--------+--------+--------+--------+--------+
|11000010|00000110| Receive Rate |
+--------+--------+--------+--------+--------+--------+
Type=194 Len=6
+--------+--------+--------+--------+--------+--------+
|11000010|00000110| Receive Rate |
+--------+--------+--------+--------+--------+--------+
Type=194 Len=6
This option MUST be sent by the data receiver on all required acknowledgements. Its four data bytes indicate the rate at which the receiver has received data since it last sent an acknowledgement, in bytes per second. To calculate this receive rate, the receiver sets t to the larger of the estimated round-trip time and the time since the last Receive Rate option was sent. (Received data packets' window counters can be used to produce a suitable RTT estimate, as described in Section 8.1.) The receive rate then equals the number of data bytes received in the most recent t seconds, divided by t.
此选项必须由数据接收器在所有必需的确认时发送。它的四个数据字节表示自上次发送确认后接收器接收数据的速率，以字节/秒为单位。为了计算该接收速率，接收器将t设置为估计的往返时间和自上次发送接收速率选项以来的时间中的较大值。（如第8.1节所述，接收数据包的窗口计数器可用于产生适当的RTT估计值。）然后，接收速率等于最近t秒内接收的数据字节数除以t。
Receive Rate options MUST NOT be sent on DCCP-Data packets, and any Receive Rate options on received DCCP-Data packets MUST be ignored.
不得在DCCP数据包上发送接收速率选项，并且必须忽略已接收DCCP数据包上的任何接收速率选项。
The Send Loss Event Rate feature lets CCID 3 endpoints negotiate whether the receiver MUST provide Loss Event Rate options on its acknowledgements. DCCP A sends a "Change R(Send Loss Event Rate, 1)" option to ask DCCP B to send Loss Event Rate options as part of its acknowledgement traffic.
发送丢失事件速率功能允许CCID 3端点协商接收方是否必须在其确认上提供丢失事件速率选项。DCCP A发送“更改R（发送丢失事件速率，1）”选项，要求DCCP B发送丢失事件速率选项，作为其确认流量的一部分。
Send Loss Event Rate has feature number 192 and is server-priority. It takes one-byte Boolean values. DCCP B MUST send Loss Event Rate options on its acknowledgements when Send Loss Event Rate/B is one, although it MAY send Loss Event Rate options even when Send Loss Event Rate/B is zero. Values of two or more are reserved. A CCID 3 half-connection starts with Send Loss Event Rate equal to zero.
发送丢失事件速率具有功能编号192，是服务器优先级。它需要一个字节的布尔值。当“发送丢失事件速率”为1时，DCCP B必须在其确认上发送丢失事件速率选项，尽管即使“发送丢失事件速率”为0，DCCP B也可以发送丢失事件速率选项。保留两个或两个以上的值。CCID 3半连接在发送丢失事件率等于零时启动。
+--------+--------+--------+--------+--------+--------+
|11000000|00000110| Loss Event Rate |
+--------+--------+--------+--------+--------+--------+
Type=192 Len=6
+--------+--------+--------+--------+--------+--------+
|11000000|00000110| Loss Event Rate |
+--------+--------+--------+--------+--------+--------+
Type=192 Len=6
The option value indicates the inverse of the loss event rate, rounded UP, as calculated by the receiver. Its units are data packets per loss interval. Thus, if the Loss Event Rate option value is 100, then the loss event rate is 0.01 loss events per data packet (and the average loss interval contains 100 data packets). When each loss event has exactly one data packet loss, the loss event rate is the same as the data packet drop rate.
选项值表示损失事件率的倒数，向上舍入，由接收方计算。它的单位是每个丢失间隔的数据包。因此，如果丢失事件率选项值为100，则丢失事件率为每个数据包0.01个丢失事件（并且平均丢失间隔包含100个数据包）。当每个丢失事件正好有一个数据包丢失时，丢失事件率与数据包丢失率相同。
See [RFC3448], Section 5, for a normative calculation of loss event rate. Before any losses have occurred, when the loss event rate is zero, the Loss Event Rate option value is set to "11111111111111111111111111111111" in binary (or, equivalently, to 2^32 - 1). The loss event rate calculation uses loss interval data lengths, as defined in Section 6.1.1.
关于损失事件率的标准计算，请参见[RFC3448]第5节。在发生任何损失之前，当损失事件率为零时，损失事件率选项值以二进制形式设置为“11111111111111111111111”（或等效为2^32-1）。损失事件率计算使用第6.1.1节中定义的损失间隔数据长度。
Loss Event Rate options MUST NOT be sent on DCCP-Data packets, and any Loss Event Rate options on received DCCP-Data packets MUST be ignored.
不能在DCCP数据包上发送丢失事件速率选项，并且必须忽略接收到的DCCP数据包上的任何丢失事件速率选项。
+--------+--------+--------+--------...--------+--------+---
|11000001| Length | Skip | Loss Interval | More Loss
| | | Length | | Intervals...
+--------+--------+--------+--------...--------+--------+---
Type=193 9 bytes
+--------+--------+--------+--------...--------+--------+---
|11000001| Length | Skip | Loss Interval | More Loss
| | | Length | | Intervals...
+--------+--------+--------+--------...--------+--------+---
Type=193 9 bytes
Each 9-byte Loss Interval contains three fields, as follows:
每个9字节的丢失间隔包含三个字段，如下所示：
____________________ Loss Interval _____________________
/ \
+--------...-------+--------...--------+--------...--------+
| Lossless Length |E| Loss Length | Data Length |
+--------...-------+--------...--------+--------...--------+
3 bytes 3 bytes 3 bytes
____________________ Loss Interval _____________________
/ \
+--------...-------+--------...--------+--------...--------+
| Lossless Length |E| Loss Length | Data Length |
+--------...-------+--------...--------+--------...--------+
3 bytes 3 bytes 3 bytes
The receiver reports its observed loss intervals using a Loss Intervals option. Section 6.1 defines loss intervals. This option MUST be sent by the data receiver on all required acknowledgements. The option reports up to 28 loss intervals seen by the receiver, although TFRC currently uses at most the latest 9 of these. This lets the sender calculate a loss event rate and probabilistically verify the receiver's ECN Nonce Echo.
接收器使用损耗间隔选项报告其观察到的损耗间隔。第6.1节定义了损失间隔。此选项必须由数据接收器在所有必需的确认时发送。虽然TFRC目前最多使用最新的9个，但该选项报告最多28个接收器看到的丢失间隔。这使发送方可以计算丢失事件率，并有可能验证接收方的ECN立即回波。
The Loss Intervals option serves several purposes.
损失间隔选项有多种用途。
o The sender can use the Loss Intervals option to calculate the loss event rate.
o 发送方可以使用“丢失间隔”选项来计算丢失事件率。
o Loss Intervals information is easily checked for consistency against previous Loss Intervals options, and against any Loss Event Rate calculated by the receiver.
o 损失间隔信息很容易与以前的损失间隔选项以及接收方计算的任何损失事件率进行一致性检查。
o The sender can probabilistically verify the ECN Nonce Echo for each Loss Interval, reducing the likelihood of misbehavior.
o 发送方可以概率地验证每个丢失间隔的ECN Nonce Echo，从而降低不当行为的可能性。
Loss Intervals options MUST NOT be sent on DCCP-Data packets, and any Loss Intervals options on received DCCP-Data packets MUST be ignored.
不能在DCCP数据包上发送丢失间隔选项，并且必须忽略接收到的DCCP数据包上的任何丢失间隔选项。
The Loss Intervals option contains information about one to 28 consecutive loss intervals, always including the most recent loss interval. Intervals are listed in reverse chronological order. Should more than 28 loss intervals need to be reported, then multiple Loss Intervals options can be sent; the second option begins where the first left off, and so forth. The options MUST contain information about at least the most recent NINTERVAL + 1 = 9 loss intervals unless (1) there have not yet been NINTERVAL + 1 loss intervals, or (2) the receiver knows, because of the sender's acknowledgements, that some previously transmitted loss interval information has been received. In this second case, the receiver need not send loss intervals that the sender already knows about, except that it MUST transmit at least one loss interval regardless.
“损失间隔”选项包含关于一到28个连续损失间隔的信息，始终包括最近的损失间隔。时间间隔按相反的时间顺序列出。如果需要报告超过28个损失间隔，则可以发送多个损失间隔选项；第二个选项从第一个选项停止的地方开始，依此类推。选项必须至少包含关于最近的NINTERVAL+1=9丢失间隔的信息，除非（1）还没有NINTERVAL+1丢失间隔，或者（2）由于发送方的确认，接收方知道已经接收到一些先前发送的丢失间隔信息。在第二种情况下，接收方不需要发送发送方已经知道的丢失间隔，除非它必须发送至少一个丢失间隔。
The NINTERVAL parameter is equal to "n" as defined in [RFC3448], Section 5.4.
NINTERVAL参数等于[RFC3448]第5.4节中定义的“n”。
Loss interval sequence numbers are delta encoded starting from the Acknowledgement Number. Therefore, Loss Intervals options MUST NOT be sent on packets without an Acknowledgement Number, and any Loss Intervals options received on such packets MUST be ignored.
丢失间隔序列号从确认号开始进行增量编码。因此，不能在没有确认号的数据包上发送丢失间隔选项，并且必须忽略在此类数据包上接收到的任何丢失间隔选项。
The first byte of option data is Skip Length, which indicates the number of packets up to and including the Acknowledgement Number that are not part of any Loss Interval. As discussed above, Skip Length must be less than or equal to NDUPACK = 3. In a packet containing multiple Loss Intervals options, the Skip Lengths of the second and subsequent options MUST equal zero; such options with nonzero Skip Lengths MUST be ignored.
选项数据的第一个字节是Skip Length，它表示不属于任何丢失间隔的数据包数量，包括确认号。如上所述，跳过长度必须小于或等于NDUPACK=3。在包含多个丢失间隔选项的数据包中，第二个和后续选项的跳过长度必须等于零；此类具有非零跳过长度的选项必须忽略。
Loss Interval structures follow Skip Length. Each Loss Interval consists of a Lossless Length, a Loss Length, an ECN Nonce Echo (E), and a Data Length.
损失间隔结构遵循跳跃长度。每个丢失间隔由无损长度、丢失长度、ECN Nonce Echo（E）和数据长度组成。
Lossless Length, a 24-bit number, specifies the number of packets in the loss interval's lossless part. Note again that this part may contain lost or marked non-data packets.
无损长度（24位数字）指定丢失间隔的无损部分中的数据包数。再次注意，此部分可能包含丢失或标记的非数据包。
Loss Length, a 23-bit number, specifies the number of packets in the loss interval's lossy part. The sum of the Lossless Length and the Loss Length equals the loss interval's sequence length. Receivers SHOULD report the minimum valid Loss Length for each loss interval, making the first and last sequence numbers in each lossy part correspond to lost or marked data packets.
丢失长度是一个23位的数字，指定丢失间隔有损部分中的数据包数。无损长度和损耗长度之和等于损耗间隔的序列长度。接收机应报告每个丢失间隔的最小有效丢失长度，使每个有损部分的第一个和最后一个序列号对应于丢失或标记的数据包。
The ECN Nonce Echo, stored in the high-order bit of the 3-byte field containing Loss Length, equals the one-bit sum (exclusive-or, or parity) of data packet nonces received over the loss interval's lossless part (which is Lossless Length packets long). If Lossless Length is 0, the receiver is ECN Incapable, or the Lossless Length contained no data packets, then the ECN Nonce Echo MUST be reported as 0. Note that any ECN nonces on received non-data packets MUST NOT contribute to the ECN Nonce Echo.
存储在包含丢失长度的3字节字段的高位中的ECN Nonce Echo等于在丢失间隔的无损部分（即无损长度数据包长）上接收的数据包Nonce的一位和（异或或奇偶校验）。如果无损长度为0，则接收器无法接收ECN，或者无损长度不包含任何数据包，则ECN Nonce Echo必须报告为0。请注意，接收到的非数据包上的任何ECN Nonce都不得导致ECN Nonce回波。
Finally, Data Length, a 24-bit number, specifies the loss interval's data length, as defined in Section 6.1.1.
最后，如第6.1.1节所定义，数据长度（24位数字）指定丢失间隔的数据长度。
Consider the following sequence of packets, where "-" represents a safely delivered packet and "*" represents a lost or marked packet.
考虑下面的数据包序列，其中“-”表示一个安全传递的数据包，而“*”表示丢失或标记的数据包。
Sequence
Numbers: 0 10 20 30 40 44
| | | | | |
----------*--------***-*--------*----------*-
Sequence
Numbers: 0 10 20 30 40 44
| | | | | |
----------*--------***-*--------*----------*-
Assuming that packet 43 was lost, not marked, this sequence might be divided into loss intervals as follows:
假设数据包43丢失，未标记，该序列可按如下方式划分为丢失间隔：
0 10 20 30 40 44
| | | | | |
----------*--------***-*--------*----------*-
\________/\_______/\___________/\_________/
L0 L1 L2 L3
0 10 20 30 40 44
| | | | | |
----------*--------***-*--------*----------*-
\________/\_______/\___________/\_________/
L0 L1 L2 L3
A Loss Intervals option sent on a packet with Acknowledgement Number 44 to acknowledge this set of loss intervals might contain the bytes 193,39,2, 0,0,10, 128,0,1, 0,0,10, 0,0,8, 0,0,5, 0,0,10, 0,0,8, 0,0,1, 0,0,8, 0,0,10, 128,0,0, 0,0,15. This option is interpreted as follows.
在确认号为44的分组上发送的确认这组丢失间隔的丢失间隔选项可能包含字节193、39、2、0、0、10、128、0、1、0、0、10、0、0、0、8、0、0、10、0、5、0、0、10、0、8、0、0、1、0、8、0、0、10、128、0、0、0、0、0、0、15。该选项的解释如下。
193 The Loss Intervals option number.
193损失间隔选项编号。
39 The length of the option, including option type and length bytes. This option contains information about (39 - 3)/9 = 4 loss intervals.
39选项的长度，包括选项类型和长度字节。此选项包含关于（39-3）/9=4损失间隔的信息。
2 The Skip Length is 2 packets. Thus, the most recent loss interval, L3, ends immediately before sequence number 44 - 2 + 1 = 43.
2跳过长度为2个数据包。因此，最近的丢失间隔L3在序列号44-2+1=43之前结束。
0,0,10, 128,0,1, 0,0,10 These bytes define L3. L3 consists of a 10-packet lossless part (0,0,10), preceded by a 1-packet lossy part. Continuing to subtract, the lossless part begins with sequence number 43 - 10 = 33, and the lossy part begins with sequence number 33 - 1 = 32. The ECN Nonce Echo for the lossless part (namely, packets 33 through 42, inclusive) equals 1. The interval's data length is 10, so the receiver believes that the interval contained exactly one non-data packet.
0,0,10,128,0,1,0,0,10这些字节定义L3。L3由10包无损部分（0,0,10）组成，前面是1包有损部分。继续减法，无损部分从序号43-10=33开始，有损部分从序号33-1=32开始。无损部分（即，包33到42，包括在内）的ECN Nonce Echo等于1。该间隔的数据长度为10，因此接收器认为该间隔正好包含一个非数据包。
0,0,8, 0,0,5, 0,0,10 This defines L2, whose lossless part begins with sequence number 32 - 8 = 24; whose lossy part begins with sequence number 24 - 5 = 19; whose ECN Nonce Echo (for packets [24,31]) equals 0; and whose data length is 10.
0,0,8,0,0,5,0,0,10这定义了L2，其无损部分以序号32-8=24开始；其有损部分以序号24-5=19开始；其ECN Nonce Echo（对于数据包[24,31]）等于0；其数据长度为10。
0,0,8, 0,0,1, 0,0,8 L1's lossless part begins with sequence number 11, its lossy part begins with sequence number 10, its ECN Nonce Echo (for packets [11,18]) equals 0, and its data length is 8.
0,0,8,0,0,1,0,0,8 L1的无损部分以序号11开始，其有损部分以序号10开始，其ECN Nonce Echo（对于数据包[11,18]）等于0，其数据长度为8。
0,0,10, 128,0,0, 0,0,15 L0's lossless part begins with sequence number 0, it has no lossy part, its ECN Nonce Echo (for packets [0,9]) equals 1, and its data length is 15. (This must be the first loss interval in the connection; otherwise, a data length greater than the sequence length would be invalid.)
0,0,10,128,0,0,0,15 L0的无损部分以序号0开始，它没有有损部分，其ECN Nonce Echo（对于数据包[0,9]）等于1，其数据长度为15。（这必须是连接中的第一个丢失间隔；否则，大于序列长度的数据长度将无效。）
The sender can use Loss Intervals options' ECN Nonce Echoes (and possibly any Ack Vectors' ECN Nonce Echoes) to probabilistically verify that the receiver is correctly reporting all dropped or marked packets. Even if ECN is not used (the receiver's ECN Incapable feature is set to one), the sender could still check on the receiver by occasionally not sending a packet, or sending a packet out-of-order, to catch the receiver in an error in Loss Intervals or Ack Vector information. This is not as robust or non-intrusive as the verification provided by the ECN Nonce, however.
发送方可以使用丢失间隔选项的ECN Nonce回波（以及可能的任何Ack向量的ECN Nonce回波）来概率地验证接收方是否正确地报告了所有丢弃或标记的数据包。即使没有使用ECN（接收机的ECN unable功能设置为1），发送方仍然可以通过偶尔不发送分组或发送顺序错误的分组来检查接收机，以捕获丢失间隔或Ack向量信息中的错误。然而，这不像ECN Nonce提供的验证那样健壮或非侵入性。
To verify the ECN Nonce Echo included with a Loss Intervals option, the sender maintains a table with the ECN nonce sum for each data packet. As defined in [RFC3540], the nonce sum for sequence number S is the one-bit sum (exclusive-or, or parity) of data packet nonces over the sequence number range [I,S], where I is the initial sequence number. Let NonceSum(S) represent this nonce sum for sequence number S, and define NonceSum(I - 1) as 0. Note that NonceSum does not account for the nonces of non-data packets such as DCCP-Ack. Then the Nonce Echo for an interval of packets with sequence numbers X to Y, inclusive, should equal the following one-bit sum:
为了验证丢失间隔选项中包含的ECN Nonce Echo，发送方维护一个表，其中包含每个数据包的ECN Nonce sum。如[RFC3540]中所定义，序列号S的nonce和是序列号范围[I，S]上数据包nonce的一位和（异或或奇偶校验），其中I是初始序列号。让NonceSum（S）表示序列号S的这个nonce和，并将NonceSum（I-1）定义为0。注意，NonceSum不考虑非数据包（如DCCP Ack）的nonce。然后，序列号为X到Y（含X到Y）的数据包间隔的非同步回波应等于以下一位和：
NonceSum(X - 1) + NonceSum(Y)
NonceSum(X - 1) + NonceSum(Y)
Since an ECN Nonce Echo is returned for the lossless part of each Loss Interval, a misbehaving receiver -- meaning a receiver that reports a lost or marked data packet as "received non-marked", to avoid rate reductions -- has only a 50% chance of guessing the correct Nonce Echo for each loss interval.
由于针对每个丢失间隔的无损部分返回ECN Nonce Echo，因此行为不正常的接收器（指将丢失或标记的数据包报告为“未标记接收”的接收器）只有50%的机会猜测每个丢失间隔的正确Nonce Echo。
To verify the ECN Nonce Echo included with an Ack Vector option, the sender maintains a table with the ECN nonce value sent for each packet. The Ack Vector option explicitly says which packets were
为了验证Ack Vector选项中包含的ECN Nonce Echo，发送方维护一个表，其中包含为每个数据包发送的ECN Nonce值。Ack Vector选项明确指出哪些数据包是
received non-marked; the sender just adds up the nonces for those packets using a one-bit sum and compares the result to the Nonce Echo encoded in the Ack Vector's option type. Again, a misbehaving receiver has only a 50% chance of guessing an Ack Vector's correct Nonce Echo. Alternatively, an Ack Vector's ECN Nonce Echo may also be calculated from a table of ECN nonce sums, rather than from ECN nonces. If the Ack Vector contains many long runs of non-marked, non-dropped packets, the nonce sum-based calculation will probably be faster than a straightforward nonce-based calculation.
未标记接收；发送方仅使用一位和将这些数据包的Nonce相加，并将结果与Ack向量的选项类型中编码的Nonce Echo进行比较。同样，行为不正常的接收器只有50%的机会猜测Ack向量的正确非同步回波。或者，Ack向量的ECN Nonce回波也可以从ECN Nonce和表计算，而不是从ECN Nonce计算。如果Ack向量包含许多长时间运行的未标记、未丢弃的数据包，则基于nonce和的计算可能比直接基于nonce的计算更快。
Note that Ack Vector's ECN Nonce Echo is measured over both data packets and non-data packets, while the Loss Intervals option reports ECN Nonce Echoes for data packets only. Thus, different nonce sum tables are required to verify the two options.
请注意，Ack Vector的ECN Nonce回波是在数据包和非数据包上测量的，而丢失间隔选项仅报告数据包的ECN Nonce回波。因此，需要不同的nonce sum表来验证这两个选项。
Besides probabilistically verifying the ECN Nonce Echoes reported by the receiver, the sender may also verify the loss intervals and any loss event rate reported by the receiver, if it so desires. Specifically, the Loss Intervals option explicitly reports the size of each loss interval as seen by the receiver; the sender can verify that the receiver is not falsely combining two loss events into one reported Loss Interval by using saved window counter information. The sender can also compare any Loss Event Rate option to the loss event rate it calculates using the Loss Intervals option.
除了概率地验证由接收机报告的ECN当前回波之外，发送方还可以验证由接收机报告的丢失间隔和任何丢失事件率（如果其希望的话）。具体而言，丢失间隔选项明确报告接收机看到的每个丢失间隔的大小；发送方可以使用保存的窗口计数器信息验证接收方是否将两个丢失事件错误地合并到一个报告的丢失间隔中。发送方还可以将任何损失事件率选项与使用损失间隔选项计算的损失事件率进行比较。
Note that in some cases the loss event rate calculated by the sender could differ from an explicit Loss Event Rate option sent by the receiver. In particular, when a number of successive packets are dropped, the receiver does not know the sending times for these packets and interprets these losses as a single loss event. In contrast, if the sender has saved the sending times or window counter information for these packets, then the sender can determine if these losses constitute a single loss event or several successive loss events. Thus, with its knowledge of the sending times of dropped packets, the sender is able to make a more accurate calculation of the loss event rate. These kinds of differences SHOULD NOT be misinterpreted as attempted receiver misbehavior.
请注意，在某些情况下，发送方计算的损失事件率可能不同于接收方发送的显式损失事件率选项。特别地，当多个连续分组被丢弃时，接收机不知道这些分组的发送时间，并且将这些丢失解释为单个丢失事件。相反，如果发送方保存了这些数据包的发送时间或窗口计数器信息，则发送方可以确定这些丢失是构成单个丢失事件还是几个连续丢失事件。因此，通过其对丢包的发送时间的了解，发送方能够对丢失事件率进行更准确的计算。这些类型的差异不应被误解为试图接收错误行为。
CCID 3 data packets need not carry Timestamp options. The sender can store the times at which recent packets were sent; the Acknowledgement Number and Elapsed Time option contained on each required acknowledgement then provide sufficient information to
CCID3数据包不需要携带时间戳选项。发送方可以存储最近发送数据包的时间；每个所需确认中包含的确认编号和运行时间选项将为
compute the round trip time. Alternatively, the sender MAY include Timestamp options on some of its data packets. The receiver will respond with Timestamp Echo options including Elapsed Times, allowing the sender to calculate round-trip times without storing sent packets' timestamps at all.
计算往返时间。或者，发送方可以在其一些数据分组上包括时间戳选项。接收器将使用时间戳回显选项（包括经过的时间）进行响应，允许发送者计算往返时间，而无需存储发送包的时间戳。
The window counter is used by the receiver to determine whether multiple lost packets belong to the same loss event. The sender increases the window counter by one every quarter round-trip time. This section describes in detail the procedure for using the window counter to determine when two lost packets belong to the same loss event.
接收器使用窗口计数器来确定多个丢失的数据包是否属于同一丢失事件。发送方每四分之一往返时间增加一个窗口计数器。本节详细介绍使用窗口计数器确定两个丢失的数据包何时属于同一丢失事件的过程。
[RFC3448], Section 3.2.1 specifies that each data packet contains a timestamp and gives as an alternative implementation a "timestamp" that is incremented every quarter of an RTT, as is the window counter in CCID 3. However, [RFC3448], Section 5.2 on "Translation from Loss History to Loss Events" is written in terms of timestamps, not in terms of window counters. In this section, we give a procedure for the translation from loss history to loss events that is explicitly in terms of window counters.
[RFC3448]，第3.2.1节规定每个数据包包含一个时间戳，并作为替代实现提供一个“时间戳”，该时间戳在RTT的每四分之一处递增，就像CCID 3中的窗口计数器一样。但是，[RFC3448]，第5.2节“从损失历史到损失事件的转换”是根据时间戳而不是窗口计数器编写的。在本节中，我们将给出一个从丢失历史到丢失事件的转换过程，该过程明确地表示为窗口计数器。
To determine whether two lost packets with sequence numbers X and Y belong to different loss events, the receiver proceeds as follows. Assume Y > X in circular sequence space.
为了确定序列号为X和Y的两个丢失的数据包是否属于不同的丢失事件，接收器进行如下操作。假设在循环序列空间中Y>X。
o Let X_prev be the greatest valid sequence number received with X_prev < X.
o 设X_prev为X_prev<X时收到的最大有效序列号。
o Let Y_prev be the greatest valid sequence number received with Y_prev < Y.
o 设Y_prev为Y_prev<Y时接收到的最大有效序列号。
o Given a sequence number N, let C(N) be the window counter value associated with that packet.
o 给定序列号N，让C（N）为与该数据包相关联的窗口计数器值。
o Packets X and Y belong to different loss events if there exists a packet with sequence number S so that X_prev < S <= Y_prev, and the distance from C(X_prev) to C(S) is greater than 4. (The distance is the number D so that C(X_prev) + D = C(S) (mod WCTRMAX), where WCTRMAX is the maximum value for the window counter -- in our case, 16.)
o 如果存在序列号为S的数据包，使得X_prev<S<=Y_prev，并且从C（X_prev）到C（S）的距离大于4，则数据包X和Y属于不同的丢失事件。（距离是数字D，因此C（X_prev）+D=C（S）（mod WCTRMAX），其中WCTRMAX是窗口计数器的最大值——在本例中为16。）
That is, the receiver only considers losses X and Y as separate loss events if there exists some packet S received between X and Y, with the distance from C(X_prev) to C(S) greater than 4. This complex calculation is necessary in order to handle the case where
也就是说，如果在X和Y之间存在一些接收到的分组S，并且从C（X_prev）到C（S）的距离大于4，则接收机仅将丢失X和Y视为单独的丢失事件。为了处理以下情况，需要进行复杂的计算：
window counter space wrapped completely between X and Y. When that space does not wrap, the receiver can simply check whether the distance from C(X_prev) to C(Y_prev) is greater than 4; if so, then X and Y belong to separate loss events.
窗口计数器空间在X和Y之间完全包裹。当该空间没有包裹时，接收器只需检查从C（X_prev）到C（Y_prev）的距离是否大于4；如果是，则X和Y属于单独的损失事件。
Window counters can help the receiver disambiguate multiple losses after a sudden decrease in the actual round-trip time. When the sender receives an acknowledgement acknowledging a data packet with window counter i, the sender increases its window counter, if necessary, so that subsequent data packets are sent with window counter values of at least i+4. This can help minimize errors where the receiver incorrectly interprets multiple loss events as a single loss event.
窗口计数器可以帮助接收器在实际往返时间突然减少后消除多重损失的歧义。当发送方接收到确认具有窗口计数器i的数据分组的确认时，发送方在必要时增加其窗口计数器，以便发送具有至少i+4的窗口计数器值的后续数据分组。这有助于将接收方错误地将多个损失事件解释为单个损失事件的错误降至最低。
We note that if all of the packets between X and Y are lost in the network, then X_prev and Y_prev are equal, and the series of consecutive losses is treated by the receiver as a single loss event. However, the sender will receive no DCCP-Ack packets during a period of consecutive losses, and the sender will reduce its sending rate accordingly.
我们注意到，如果X和Y之间的所有数据包在网络中丢失，那么X_prev和Y_prev是相等的，并且接收机将连续丢失序列视为单个丢失事件。但是，在连续丢失期间，发送方将不会收到DCCP Ack数据包，发送方将相应地降低其发送速率。
As an alternative to the window counter, the sender could have sent its estimate of the round-trip time to the receiver directly in a round-trip time option; the receiver would use the sender's round-trip time estimate to infer when multiple lost or marked packets belong in the same loss event. In some respects, a round-trip time option would give a more precise encoding of the sender's round-trip time estimate than does the window counter. However, the window counter conveys information about the relative *sending* times for packets, while the receiver could only use the round-trip time option to distinguish between the relative *receive* times (in the absence of timestamps). That is, the window counter will give more robust performance when there is a large variation in delay for packets sent within a window of data. Slightly more speculatively, a round-trip time option might possibly be used more easily by middleboxes attempting to verify that a flow used conforming end-to-end congestion control.
作为窗口计数器的替代方案，发送方可以在往返时间选项中将其对往返时间的估计直接发送给接收方；接收方将使用发送方的往返时间估计来推断多个丢失或标记的数据包何时属于同一丢失事件。在某些方面，与窗口计数器相比，往返时间选项将为发送方的往返时间估计提供更精确的编码。然而，窗口计数器传送关于包的相对*发送*时间的信息，而接收器只能使用往返时间选项来区分相对*接收*时间（在没有时间戳的情况下）。也就是说，当在数据窗口内发送的数据包的延迟存在较大变化时，窗口计数器将提供更稳健的性能。更具推测性的是，中间商可能更容易使用往返时间选项来验证流是否使用了一致的端到端拥塞控制。
[RFC3448], Sections 6.1 and 6.2 specify that the TFRC receiver must send a feedback packet when a newly calculated loss event rate p is greater than its previous value. CCID 3 follows this rule.
[RFC3448]，第6.1和6.2节规定，当新计算的丢失事件率p大于其先前值时，TFRC接收器必须发送反馈数据包。CCID3遵循这个规则。
In addition, [RFC3448], Section 6.2, specifies that the receiver use a feedback timer to decide when to send additional feedback packets. If the feedback timer expires and data packets have been received since the previous feedback was sent, then the receiver sends a
此外，[RFC3448]第6.2节规定接收器使用反馈定时器来决定何时发送额外的反馈数据包。如果反馈计时器过期，且自上次反馈发送后已收到数据包，则接收器发送
feedback packet. When the feedback timer expires, the receiver resets the timer to expire after R_m seconds, where R_m is the most recent estimate of the round-trip time received from the sender. CCID 3 receivers, however, generally use window counter values instead of a feedback timer to determine when to send additional feedback packets. This section describes how.
反馈包。当反馈计时器过期时，接收器将计时器重置为在R_m秒后过期，其中R_m是从发送器接收的往返时间的最新估计值。然而，CCID3接收机通常使用窗口计数器值而不是反馈定时器来确定何时发送额外的反馈数据包。本节介绍了如何使用。
Whenever the receiver sends a feedback message, the receiver sets a local variable last_counter to the greatest received value of the window counter since the last feedback message was sent, if any data packets have been received since the last feedback message was sent. If the receiver receives a data packet with a window counter value greater than or equal to last_counter + 4, then the receiver sends a new feedback packet. ("Greater" and "greatest" are measured in circular window counter space.)
每当接收器发送反馈消息时，如果自上次反馈消息发送以来已收到任何数据包，则接收器将局部变量last_计数器设置为自上次反馈消息发送以来窗口计数器的最大接收值。如果接收器接收到窗口计数器值大于或等于last_计数器+4的数据包，则接收器发送新的反馈包。（“较大”和“最大”在圆形窗口计数器空间中测量。）
This procedure ensures that when the sender is sending at a rate less than one packet per round-trip time, the receiver sends a feedback packet after each data packet. Similarly, this procedure ensures that when the sender is sending several packets per round-trip time, the receiver will send a feedback packet each time that a data packet arrives with a window counter at least four greater than the window counter when the last feedback packet was sent. Thus, the feedback timer is not necessary when the window counter is used.
此过程确保当发送方以低于每个往返时间一个数据包的速率发送时，接收方在每个数据包之后发送反馈数据包。类似地，该过程确保当发送方在每个往返时间发送多个分组时，接收方将在每次数据分组到达时发送反馈分组，并且窗口计数器至少比发送最后一个反馈分组时的窗口计数器大四个。因此，当使用窗口计数器时，不需要反馈定时器。
However, the feedback timer still could be useful in some rare cases to prevent the sender from unnecessarily halving its sending rate. In particular, one could construct scenarios where the use of the feedback timer at the receiver would prevent the unnecessary expiration of the nofeedback timer at the sender. Consider the case below, in which a feedback packet is sent when a data packet arrives with a window counter of K.
然而，反馈计时器在一些罕见的情况下仍然可以用来防止发送者不必要地将其发送速率减半。特别是，可以构建这样的场景，即在接收器处使用反馈计时器将防止发送器处的反馈计时器不必要地过期。考虑下面的情况，其中当数据包到达时，用K.的窗口计数器发送反馈包。
Window
Counters: K K+1 K+2 K+3 K+4 K+5 K+6 ... K+15 K+16 K+17 ...
| | | | | | | | | |
Data | | | | | | | | | |
Packets | | | | | | | | | |
Received: - - --- - ... - - -- - -- -- -
| | | | | |
| | | | | |
Events: 1: 2: 3: 4: 5: 6:
"A" "B" Timer "B"
sent sent received
Window
Counters: K K+1 K+2 K+3 K+4 K+5 K+6 ... K+15 K+16 K+17 ...
| | | | | | | | | |
Data | | | | | | | | | |
Packets | | | | | | | | | |
Received: - - --- - ... - - -- - -- -- -
| | | | | |
| | | | | |
Events: 1: 2: 3: 4: 5: 6:
"A" "B" Timer "B"
sent sent received
1: Feedback message A is sent. 2: A feedback message would have been sent if feedback timers had been used.
1：发送反馈消息A。2：如果使用了反馈计时器，则会发送反馈消息。
3: Feedback message B is sent. 4: Sender's nofeedback timer expires. 5: Feedback message B is received at the sender. 6: Sender's nofeedback timer would have expired if feedback timers had been used, and the feedback message at 2 had been sent.
3：发送反馈消息B。4：发件人的nofeedback计时器过期。5：发送方收到反馈消息B。6:如果使用了反馈计时器，并且2处的反馈消息已发送，则发送者的nofeedback计时器将过期。
The receiver receives data after the feedback packet has been sent but has received no data packets with a window counter between K+4 and K+14. A data packet with a window counter of K+4 or larger would have triggered sending a new feedback packet, but no feedback packet is sent until time 3.
接收器在发送反馈分组之后接收数据，但是没有接收到窗口计数器在K+4和K+14之间的数据分组。窗口计数器为K+4或更大的数据包将触发发送新的反馈包，但直到时间3才发送反馈包。
The TFRC protocol specifies that after a feedback packet is received, the sender sets a nofeedback timer to at least four times the round-trip time estimate. If the sender doesn't receive any feedback packets before the nofeedback timer expires, then the sender halves its sending rate. In the figure, the sender receives feedback message A (time 1) and then sets the nofeedback timer to expire roughly four round-trip times later (time 4). The sender starts sending again just before the nofeedback timer expires but doesn't receive the resulting feedback message until after its expiration, resulting in an unnecessary halving of the sending rate. If the connection had used feedback timers, the receiver would have sent a feedback message when the feedback timer expired at time 2, and the halving of the sending rate would have been avoided.
TFRC协议规定，在收到反馈数据包后，发送方将无反馈定时器设置为往返时间估计值的至少四倍。如果发送方在nofeedback计时器到期之前没有收到任何反馈数据包，则发送方将其发送速率减半。在图中，发送方接收到反馈消息A（时间1），然后将nofeedback计时器设置为大约四个往返时间（时间4）后过期。发送方在nofeedback计时器到期前再次开始发送，但直到其到期后才收到生成的反馈消息，导致发送速率不必要地减半。如果连接使用了反馈定时器，则当反馈定时器在时间2过期时，接收器将发送反馈消息，并且发送速率将避免减半。
For implementors who wish to implement a feedback timer for the data receiver, we suggest estimating the round-trip time from the most recent data packet, as described in Section 8.1. We note that this procedure does not work when the inter-packet sending times are greater than the RTT.
对于希望为数据接收器实现反馈计时器的实施者，我们建议根据第8.1节所述的最新数据包估算往返时间。我们注意到，当包间发送时间大于RTT时，此过程不起作用。
Security considerations for DCCP have been discussed in [RFC4340], and security considerations for TFRC have been discussed in [RFC3448], Section 9. The security considerations for TFRC include the need to protect against spoofed feedback and the need to protect the congestion control mechanisms against incorrect information from the receiver.
DCCP的安全注意事项已在[RFC4340]中讨论，TFRC的安全注意事项已在[RFC3448]第9节中讨论。TFRC的安全考虑包括需要防止欺骗反馈，以及需要保护拥塞控制机制免受来自接收器的错误信息的影响。
In this document, we have extensively discussed the mechanisms the sender can use to verify the information sent by the receiver. When ECN is used, the receiver returns ECN Nonce information to the sender. When ECN is not used, then, as Section 9 shows, the sender could still use various techniques that might catch the receiver in
在本文档中，我们广泛讨论了发送方可以用来验证接收方发送的信息的机制。使用ECN时，接收方将ECN当前信息返回给发送方。当不使用ECN时，如第9节所示，发送方仍然可以使用各种技术来捕获接收方
an error in reporting congestion, but this is not as robust or non-intrusive as the verification provided by the ECN Nonce.
报告拥塞时出现错误，但这不像ECN Nonce提供的验证那样可靠或非侵入性。
This specification defines the value 3 in the DCCP CCID namespace managed by IANA. This assignment is also mentioned in [RFC4340].
本规范定义了IANA管理的DCCP CCID命名空间中的值3。[RFC4340]中也提到了此任务。
CCID 3 also introduces three sets of numbers whose values should be allocated by IANA; namely, CCID 3-specific Reset Codes, option types, and feature numbers. These ranges will prevent any future CCID 3- specific allocations from polluting DCCP's corresponding global namespaces; see [RFC4340], Section 10.3. However, we note that this document makes no particular allocations from the Reset Code range, except for experimental and testing use [RFC3692]. We refer to the Standards Action policy outlined in [RFC2434].
CCID3还引入了三组数字，其值应由IANA分配；即CCID 3特定重置代码、选项类型和功能编号。这些范围将防止任何未来特定于CCID3的分配污染DCCP相应的全局名称空间；见[RFC4340]，第10.3节。但是，我们注意到，除了实验和测试使用[RFC3692]之外，本文档未对重置代码范围进行特殊分配。我们参考[RFC2434]中概述的标准行动政策。
Each entry in the DCCP CCID 3 Reset Code registry contains a CCID 3- 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 3重置代码注册表中的每个条目都包含一个特定于CCID 3的重置代码，该代码的范围为128-255；复位代码的简短说明；以及对定义重置代码的RFC的引用。重置代码184-190和248-254永久保留供实验和测试使用。其余的重置代码（128-183、191-247和255）目前为保留代码，应与标准行动政策一起分配，该政策要求IESG审查和批准以及标准跟踪IETF RFC发布。
Each entry in the DCCP CCID 3 option type registry contains a CCID 3-specific option type, which is a number in the range 128-255; the name of the option, such as "Loss Intervals"; and a reference to the RFC defining the option type. The registry is initially populated using the values in Table 1, in Section 8. This document allocates option types 192-194, and option types 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining option types -- 128-183, 191, 195-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 3选项类型注册表中的每个条目都包含一个特定于CCID 3的选项类型，该选项类型是128-255范围内的数字；期权的名称，如“损失间隔”；定义对RFC的类型和引用。注册表最初使用第8节表1中的值填充。本文件分配选项类型192-194，选项类型184-190和248-254永久保留供实验和测试使用。其余选项类型（128-183、191、195-247和255）目前保留，应与标准行动政策一起分配，该政策要求IESG审查和批准以及标准跟踪IETF RFC发布。
Each entry in the DCCP CCID 3 feature number registry contains a CCID 3-specific feature number, which is a number in the range 128-255; the name of the feature, such as "Send Loss Event Rate"; and a reference to the RFC defining the feature number. The registry is
DCCP CCID 3功能部件编号注册表中的每个条目都包含一个CCID 3特定功能部件编号，该编号的范围为128-255；功能的名称，如“发送丢失事件率”；以及对定义特征编号的RFC的引用。登记处是
initially populated using the values in Table 2, in Section 8. This document allocates feature number 192, and feature numbers 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining feature numbers -- 128-183, 191, 193-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.
最初使用第8节表2中的值填充。本文件分配了特征编号192，特征编号184-190和248-254永久保留供实验和测试使用。其余的功能部件编号（128-183、191、193-247和255）目前保留，应与标准行动政策一起分配，该政策要求IESG审查和批准以及标准跟踪IETF RFC发布。
We thank Mark Handley for his help in defining CCID 3. We also thank Mark Allman, Aaron Falk, Ladan Gharai, Sara Karlberg, Greg Minshall, Arun Venkataramani, David Vos, Yufei Wang, Magnus Westerlund, and members of the DCCP Working Group for feedback on versions of this document.
我们感谢Mark Handley在定义CCID 3方面的帮助。我们还感谢Mark Allman、Aaron Falk、Ladan Gharai、Sara Karlberg、Greg Minshall、Arun Venkataramani、David Vos、Yufei Wang、Magnus Westerlund和DCCP工作组成员对本文件版本的反馈。
A. Appendix: Possible Future Changes to CCID 3
附录：CCID 3未来可能的变化
There are a number of cases where the behavior of TFRC as specified in [RFC3448] does not match the desires of possible users of DCCP. These include the following:
在许多情况下，[RFC3448]中规定的TFRC行为与DCCP可能用户的期望不匹配。这些措施包括：
1. The initial sending rate of at most four packets per RTT, as specified in [RFC3390].
1. [RFC3390]中规定的每个RTT最多四个数据包的初始发送速率。
2. The receiver's sending of an acknowledgement for every data packet received, when the receiver receives at a rate less than one packet per round-trip time.
2. 当接收器以小于每往返时间一个数据包的速率接收时，接收器对接收到的每个数据包发送确认。
3. The sender's limitation of at most doubling the sending rate from one round-trip time to the next (or, more specifically, of limiting the sending rate to at most twice the reported receive rate over the previous round-trip time).
3. 发送方限制从一个往返时间到下一个往返时间的发送速率最多翻倍（或者更具体地说，限制发送速率最多为前一个往返时间报告接收速率的两倍）。
4. The limitation of halving the allowed sending rate after an idle period of four round-trip times (possibly down to the initial sending rate of two to four packets per round-trip time).
4. 在四个往返时间的空闲期后，将允许的发送速率减半的限制（可能降低到每个往返时间两到四个数据包的初始发送速率）。
5. The response function used in [RFC3448], Section 3.1, which does not closely match the behavior of TCP in environments with high packet drop rates [RFC3714].
5. [RFC3448]第3.1节中使用的响应函数与TCP在高丢包率环境中的行为不匹配[RFC3714]。
One suggestion for higher initial sending rates is an initial sending rate of up to eight small packets per RTT, when the total packet size, including headers, is at most 4380 bytes. Because the packets would be rate-paced out over a round-trip time, instead of sent back-to-back as they would be in TCP, an initial sending rate of eight small packets per RTT with TFRC-based congestion control would be considerably milder than the impact of an initial window of eight small packets sent back-to-back in TCP. As Section 5.1 describes, the initial sending rate also serves as a lower bound for reductions of the allowed sending rate during an idle period.
对于较高初始发送速率的一个建议是，当包括报头在内的总数据包大小最多为4380字节时，每个RTT的初始发送速率最多为8个小数据包。由于数据包将在往返时间内进行速率配速，而不是像TCP中那样背靠背发送，因此使用基于TFRC的拥塞控制，每个RTT八个小包的初始发送速率将比TCP中八个小包背靠背发送的初始窗口的影响要小得多。如第5.1节所述，初始发送速率也可作为空闲期间允许发送速率降低的下限。
We note that with CCID 3, the sender is in slow-start in the beginning and responds promptly to the report of a packet loss or mark. However, in the absence of feedback from the receiver, the sender can maintain its old sending rate for up to four round-trip times. One possibility would be that for an initial window of eight small packets, the initial nofeedback timer would be set to two round-trip times instead of four, so that the sending rate would be reduced after two round-trips without feedback.
我们注意到，使用CCID 3，发送方在开始时启动缓慢，并对数据包丢失或标记的报告做出迅速响应。然而，在没有来自接收者的反馈的情况下，发送者可以在多达四次往返时间内保持其原来的发送速率。一种可能性是，对于八个小数据包的初始窗口，初始无反馈定时器将被设置为两个往返时间，而不是四个，以便在两个没有反馈的往返时间之后，发送速率将降低。
Research and engineering will be needed to investigate the pros and cons of modifying these limitations in order to allow larger initial sending rates, to send fewer acknowledgements when the data sending rate is low, to allow more abrupt changes in the sending rate, or to allow a higher sending rate after an idle period.
为了允许更大的初始发送速率、在数据发送速率较低时发送更少的确认、允许发送速率发生更突然的变化，或者在空闲时间后允许更高的发送速率，需要进行研究和工程来调查修改这些限制的优缺点。
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月。
[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月。
[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月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
[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
资料性引用
[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月。
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[RFC3714]Floyd，S.和J.Kempf，“IAB对互联网语音流量拥塞控制的关注”，RFC 3714，2004年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月。
[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
Jitendra Padhye Microsoft Research One Microsoft Way Redmond, WA 98052 USA
Jitendra Padhye Microsoft Research One Microsoft Way Redmond，WA 98052美国
EMail: padhye@microsoft.com
EMail: padhye@microsoft.com
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）提供。