Network Working Group S. Floyd
Request for Comments: 5622 ICIR
Category: Experimental E. Kohler
UCLA
August 2009
Network Working Group S. Floyd
Request for Comments: 5622 ICIR
Category: Experimental E. Kohler
UCLA
August 2009
Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)
数据报拥塞控制协议（DCCP）拥塞ID 4的配置文件：TCP友好的小包速率控制（TFRC-SP）
Abstract
摘要
This document specifies a profile for Congestion Control Identifier 4, the small-packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 4 is for experimental use, and uses TFRC-SP (RFC 4828), a variant of TFRC designed for applications that send small packets. CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time. The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion. CCID 4 is for use for senders that send small packets and would like a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes.
本文档为数据报拥塞控制协议（DCCP）中的拥塞控制标识符4（TCP友好速率控制（TFRC）的小数据包变体）指定了配置文件。CCID4是用于实验的，它使用TFRC-SP（RFC4828），TFRC的一种变体，专为发送小数据包的应用程序而设计。CCID 4被认为是实验性的，因为TFRC-SP本身就是实验性的，目前还不建议在全球互联网上广泛部署。TFRC-SP的目标是使用高达1500字节的数据包实现与TCP流大致相同的带宽（以比特/秒（bps）为单位），但拥塞程度相同。CCID4用于发送小数据包的发送方，并且希望TCP友好的发送速率，可能带有显式拥塞通知（ECN），同时最大限度地减少突然的速率变化。
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人可能没有授予IETF信托允许的权利
modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
在IETF标准过程之外修改此类材料。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Usage ...........................................................4
3.1. Relationship with TFRC and TFRC-SP .........................5
3.2. Example Half-Connection ....................................5
4. Connection Establishment ........................................6
5. Congestion Control on Data Packets ..............................6
5.1. Response to Idle and Application-Limited Periods ...........7
5.2. Response to Data Dropped and Slow Receiver .................7
5.3. Packet Sizes ...............................................7
6. Acknowledgements ................................................8
6.1. Loss Interval Definition ...................................8
6.2. Congestion Control on Acknowledgements .....................8
6.3. Acknowledgements of Acknowledgements .......................8
6.4. Quiescence .................................................8
7. Explicit Congestion Notification ................................8
8. Options and Features ............................................9
8.1. Window Counter Value ......................................10
8.2. Elapsed Time Options ......................................10
8.3. Receive Rate Option .......................................10
8.4. Send Loss Event Rate Feature ..............................10
8.5. Loss Event Rate Option ....................................11
8.6. Loss Intervals Option .....................................11
8.7. Dropped Packets Option ....................................11
8.7.1. Example ............................................13
9. Verifying Congestion Control Compliance with ECN ...............14
9.1. Verifying the ECN Nonce Echo ..............................14
9.2. Verifying the Reported Loss Intervals and Loss
Event Rate ................................................14
10. Implementation Issues .........................................14
10.1. Timestamp Usage ..........................................14
10.2. Determining Loss Events at the Receiver ..................15
10.3. Sending Feedback Packets .................................15
11. Design Considerations .........................................15
11.1. The Field Size in the Loss Intervals Option ..............15
11.2. The Field Size in the Dropped Packets Option .............16
12. Experimental Status of This Document ..........................17
13. Security Considerations .......................................17
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Usage ...........................................................4
3.1. Relationship with TFRC and TFRC-SP .........................5
3.2. Example Half-Connection ....................................5
4. Connection Establishment ........................................6
5. Congestion Control on Data Packets ..............................6
5.1. Response to Idle and Application-Limited Periods ...........7
5.2. Response to Data Dropped and Slow Receiver .................7
5.3. Packet Sizes ...............................................7
6. Acknowledgements ................................................8
6.1. Loss Interval Definition ...................................8
6.2. Congestion Control on Acknowledgements .....................8
6.3. Acknowledgements of Acknowledgements .......................8
6.4. Quiescence .................................................8
7. Explicit Congestion Notification ................................8
8. Options and Features ............................................9
8.1. Window Counter Value ......................................10
8.2. Elapsed Time Options ......................................10
8.3. Receive Rate Option .......................................10
8.4. Send Loss Event Rate Feature ..............................10
8.5. Loss Event Rate Option ....................................11
8.6. Loss Intervals Option .....................................11
8.7. Dropped Packets Option ....................................11
8.7.1. Example ............................................13
9. Verifying Congestion Control Compliance with ECN ...............14
9.1. Verifying the ECN Nonce Echo ..............................14
9.2. Verifying the Reported Loss Intervals and Loss
Event Rate ................................................14
10. Implementation Issues .........................................14
10.1. Timestamp Usage ..........................................14
10.2. Determining Loss Events at the Receiver ..................15
10.3. Sending Feedback Packets .................................15
11. Design Considerations .........................................15
11.1. The Field Size in the Loss Intervals Option ..............15
11.2. The Field Size in the Dropped Packets Option .............16
12. Experimental Status of This Document ..........................17
13. Security Considerations .......................................17
14. IANA Considerations ...........................................17
14.1. Reset Codes ..............................................17
14.2. Option Types .............................................17
14.3. Feature Numbers ..........................................18
15. Thanks ........................................................18
16. References ....................................................18
16.1. Normative References .....................................18
16.2. Informative References ...................................19
14. IANA Considerations ...........................................17
14.1. Reset Codes ..............................................17
14.2. Option Types .............................................17
14.3. Feature Numbers ..........................................18
15. Thanks ........................................................18
16. References ....................................................18
16.1. Normative References .....................................18
16.2. Informative References ...................................19
List of Tables
表格一览表
Table 1: DCCP CCID 4 Options .......................................9
Table 2: DCCP CCID 4 Feature Numbers ...............................9
Table 1: DCCP CCID 4 Options .......................................9
Table 2: DCCP CCID 4 Feature Numbers ...............................9
This document specifies an experimental profile for Congestion Control Identifier 4, TCP-Friendly Rate Control for Small Packets (TFRC-SP), in the Datagram Congestion Control Protocol (DCCP) [RFC4340]. CCID 4 is a modified version of Congestion Control Identifier 3, CCID 3, which has been specified in [RFC4342]. This document assumes that the reader is familiar with CCID 3, instead of repeating from that document unnecessarily.
本文件规定了数据报拥塞控制协议（DCCP）[RFC4340]中拥塞控制标识符4，小数据包TCP友好速率控制（TFRC-SP）的实验配置文件。CCID 4是[RFC4342]中指定的拥塞控制标识符3 CCID 3的修改版本。本文档假定读者熟悉CCID 3，而不是不必要地重复该文档。
CCID 3 uses TCP-Friendly Rate Control (TFRC), which is now specified in RFC 5348 [RFC5348]. CCID 4 differs from CCID 3 in that CCID 4 uses TFRC-SP [RFC4828], an experimental, small-packet variant of TFRC. The original specification of TFRC, RFC 3448 [RFC3448], has been obsoleted by RFC 5348. The CCID 3 and TFRC-SP documents both predate RFC 5348 and refer instead to RFC 3448 for the specification of TFRC. However, this document assumes that RFC 5348 will be used instead of RFC 3448 for the specification of TFRC.
CCID3使用TCP友好的速率控制（TFRC），现在在RFC5348[RFC5348]中指定。CCID4与CCID3的不同之处在于，CCID4使用TFRC-SP[RFC4828]，TFRC的一种实验性小数据包变体。TFRC的原始规范RFC 3448[RFC3448]已被RFC 5348淘汰。CCID 3和TFRC-SP文件均早于RFC 5348，有关TFRC规范，请参考RFC 3448。然而，本文件假设TFRC规范将使用RFC 5348而不是RFC 3448。
CCID 4 differs from CCID 3 only in the following respects:
CCID 4与CCID 3仅在以下方面不同：
o Header size: For TFRC-SP, the allowed transmit rate in bytes per second is reduced by a factor that accounts for packet header size. This is specified for TFRC-SP in Section 4.2 of [RFC4828], and described for CCID 4 in Section 5 below.
o 报头大小：对于TFRC-SP，允许的传输速率（以字节/秒为单位）会减少一个因子，该因子可以解释数据包报头的大小。[RFC4828]第4.2节对TFRC-SP进行了规定，并在下文第5节对CCID 4进行了说明。
o Maximum sending rate: TFRC-SP enforces a minimum interval of 10 milliseconds between data packets. This is specified for TFRC-SP in Section 4.3 of [RFC4828], and described for CCID 4 in Section 5 below.
o 最大发送速率：TFRC-SP强制数据包之间的最小间隔为10毫秒。[RFC4828]第4.3节对TFRC-SP进行了规定，并在下文第5节对CCID 4进行了说明。
o Loss rates for short loss intervals: For short loss intervals of at most two round-trip times (RTTs), the loss rate is computed by counting the actual number of packets lost or marked. For such a
o 短丢失间隔的丢失率：对于最多两个往返时间（RTT）的短丢失间隔，通过计算丢失或标记的数据包的实际数量来计算丢失率。为了这样一个
short loss interval with N data packets, including K lost or marked data packets, the loss interval length is calculated as N/K, instead of as N. This is specified for TFRC-SP in Section 4.4 of [RFC4828]. If the sender is computing the loss event rate, the Dropped Packets option specified in Section 8.7 is required, in addition to the default CCID 3's Loss Intervals option. Section 8.7 describes the use of the Dropped Packets option in calculating the loss event rate. The computation of the loss rate by the receiver for the Loss Event Rate option is described for CCID 4 in Section 8.4 below.
短丢失间隔对于N个数据包，包括K个丢失或标记的数据包，丢失间隔长度计算为N/K，而不是N。这在[RFC4828]第4.4节中为TFRC-SP规定。如果发送方正在计算丢失事件率，则除了默认CCID 3的丢失间隔选项外，还需要第8.7节中指定的丢弃数据包选项。第8.7节描述了在计算丢失事件率时使用丢弃的数据包选项。下文第8.4节描述了CCID 4中接收机对损失事件率选项的损失率计算。
o The nominal segment size: In TFRC-SP, the nominal segment size used by the TCP throughput equation is set to 1460 bytes. This is specified for TFRC-SP in Section 4.5 of [RFC4828], and described for CCID 4 in Section 5 below.
o 标称段大小：在TFRC-SP中，TCP吞吐量方程使用的标称段大小设置为1460字节。[RFC4828]第4.5节对TFRC-SP进行了规定，并在下文第5节对CCID 4进行了说明。
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]中所述进行解释。
Additional terminology is described in Section 2 of [RFC4342].
[RFC4342]第2节描述了其他术语。
Like CCID 3, CCID 4's 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.
与CCID 3类似，CCID 4的拥塞控制适用于希望最小化发送速率的突然变化的流，包括在播放之前具有小或中等接收器缓冲的流媒体应用。
CCID 4 is designed to be used either by applications that use a small fixed segment size, or by applications that change their sending rate by varying the segment size. If CCID 4 is used by an application that varies its segment size in response to changes in the allowed sending rate in bps, we note that CCID 4 doesn't dictate the segment size to be used by the application; this is done by the application itself. The CCID 4 sender determines the allowed sending rate in bps, in response to on-going feedback from the CCID 4 receiver, and the application can use information about the current allowed sending rate to decide whether to change the current segment size.
CCID4设计用于使用较小固定段大小的应用程序，或通过改变段大小来改变发送速率的应用程序。如果CCID 4由一个应用程序使用，该应用程序根据允许的发送速率（以bps为单位）的变化而改变其段大小，我们注意到CCID 4并不规定应用程序要使用的段大小；这是由应用程序本身完成的。CCID 4发送方根据CCID 4接收方的持续反馈确定允许的发送速率（以bps为单位），应用程序可以使用有关当前允许发送速率的信息来决定是否更改当前段大小。
We note that in some environments, there will be a feedback loop, with changes in the packet size or in the sending rate in bps affecting congestion along the path, therefore affecting the allowed sending rate in the future.
我们注意到，在某些环境中，会有一个反馈循环，包大小或发送速率（bps）的变化会影响路径上的拥塞，从而影响未来允许的发送速率。
The congestion control mechanisms described here follow the TFRC-SP mechanism specified in [RFC4828]. As with CCID 3, conformant CCID 4 implementations MAY track updates to the TCP throughput equation directly, as updates are standardized in the IETF, rather than waiting for revisions of this document. This document is based on CCID 3 [RFC4342], TFRC, and TFRC-SP. For TFRC, RFC 3448 [RFC3448] has been obsoleted by RFC 5348 [RFC5348].
这里描述的拥塞控制机制遵循[RFC4828]中指定的TFRC-SP机制。与CCID 3一样，符合CCID 4的实现可以直接跟踪TCP吞吐量方程的更新，因为更新在IETF中是标准化的，而不是等待本文档的修订。本文件基于CCID 3[RFC4342]、TFRC和TFRC-SP。对于TFRC，RFC 3448[RFC3448]已被RFC 5348[RFC5348]淘汰。
This example shows the typical progress of a half-connection using CCID 4's TFRC Congestion Control, not including connection initiation and termination. The example is informative, not normative. This example differs from that for CCID 3 in [RFC4342] only in one respect; with CCID 4, the allowed transmit rate is determined by [RFC4828] as well as by [RFC5348].
此示例显示了使用CCID 4的TFRC拥塞控制的半连接的典型过程，不包括连接启动和终止。这个例子是信息性的，而不是规范性的。该示例与[RFC4342]中CCID 3的示例仅在一个方面不同；对于CCID 4，允许的传输速率由[RFC4828]以及[RFC5348]确定。
1. The sender transmits DCCP-Data packets, where the sending rate is governed by the allowed transmit rate as specified in [RFC4828]. Each DCCP-Data packet has a sequence number, and the DCCP header's CCVal field contains the window counter value, used by the receiver in determining when multiple losses belong in a single loss event.
1. 发送方传输DCCP数据包，其中发送速率由[RFC4828]中规定的允许传输速率控制。每个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 [RFC5348] (Section 6). Each DCCP-Ack packet uses a sequence number, identifying the most recent packet received from the sender and includes feedback about the recent loss intervals experienced by the receiver.
2. 接收机发送DCCP Ack数据包，每个往返时间至少确认一次数据包，除非发送方以小于每个往返时间一个数据包的速率发送[RFC5348]（第6节）。每个DCCP Ack分组使用序列号，识别从发送方接收的最近分组，并包括关于接收方经历的最近丢失间隔的反馈。
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 [RFC5348] (Section 4.3) and [RFC4828]. This update is based upon a loss event rate calculated by the sender, based on the receiver's loss-interval feedback. If it prefers, the sender can also use a loss event rate calculated and reported by the receiver.
3. 发送方继续发送由允许的传输速率控制的DCCP数据包。接收到DCCP Ack数据包后，发送方按照[RFC5348]（第4.3节）和[RFC4828]中的规定更新其允许的传输速率。此更新基于发送方根据接收方的丢失间隔反馈计算的丢失事件率。如果愿意，发送方也可以使用接收方计算和报告的损失事件率。
4. The sender estimates round-trip times and calculates a nofeedback time, as specified in [RFC5348] (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. 发送方根据[RFC5348]（第4.4节）中的规定，估计往返时间并计算无反馈时间。如果在这段时间内（至少四次往返时间）没有收到来自接收方的反馈，则发送方将其发送速率减半。
The connection establishment is as specified in Section 4 of [RFC4342].
连接建立如[RFC4342]第4节所述。
CCID 4 uses the congestion control mechanisms of TFRC [RFC5348] and TFRC-SP [RFC4828]. [RFC4828] MUST be considered normative except where specifically indicated.
CCID4使用TFRC[RFC5348]和TFRC-SP[RFC4828]的拥塞控制机制。[RFC4828]必须被视为规范性的，除非另有明确说明。
Loss Event Rate
损失事件率
As with CCID 3, the basic operation of CCID 4 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. For CCID 4, this loss event rate, a round-trip time estimate, and a nominal packet size of 1460 bytes are plugged into the TCP throughput equation, as specified in RFC 5348 (Section 3.1) and [RFC4828].
与CCID 3一样，CCID 4的基本操作以丢失事件率的计算为中心：丢失事件的数量是传输数据包数量的一部分，在过去的几个丢失间隔内加权。对于CCID 4，按照RFC 5348（第3.1节）和[RFC4828]中的规定，将该丢失事件率、往返时间估计和1460字节的标称数据包大小插入TCP吞吐量方程。
Because CCID 4 is intended for applications that send small packets, the allowed transmit rate derived from the TCP throughput equation is reduced by a factor that accounts for packet header size, as specified in Section 4.2 of [RFC4828]. The header size on data packets is estimated as 36 bytes (20 bytes for the IPv4 header and 16 bytes for the DCCP-Data header with 48-bit sequence numbers). If the DCCP sender is sending N-byte data packets, the allowed transmit rate is reduced by N/(N+36). CCID 4 senders are limited to this fair rate. The header size would be 32 bytes instead of 36 bytes when 24-bit sequence numbers were used in the DCCP-Data header.
由于CCID 4适用于发送小数据包的应用程序，因此根据[RFC4828]第4.2节中的规定，从TCP吞吐量方程推导出的允许传输速率减少了一个系数，该系数考虑了数据包头的大小。数据包上的报头大小估计为36字节（IPv4报头为20字节，DCCP数据报头为16字节，序列号为48位）。如果DCCP发送方正在发送N字节数据包，则允许的传输速率将降低N/（N+36）。CCID 4发送方仅限于此公平费率。当DCCP数据报头中使用24位序列号时，报头大小将为32字节，而不是36字节。
As explained in Section 4.2 of [RFC4828], the actual header could be larger or smaller than the assumed value due to IP or DCCP options, IPv6, IP tunnels, header compression, and the like. Because we are only aiming at rough fairness, and at a rough incentive for applications, the default use of a 32-byte or 36-byte header in the calculations of the header bandwidth is sufficient for both IPv4 and IPv6.
如[RFC4828]第4.2节所述，由于IP或DCCP选项、IPv6、IP隧道、报头压缩等原因，实际报头可能大于或小于假设值。由于我们的目标只是粗略的公平性，以及对应用程序的粗略激励，因此在计算报头带宽时默认使用32字节或36字节报头对于IPv4和IPv6都是足够的。
If the sender is calculating the loss event rate itself, the loss event rate can be calculated using recent loss interval lengths reported by the receiver. Loss intervals are precisely defined in
如果发送方自行计算损失事件率，则可以使用接收方报告的最近损失间隔长度来计算损失事件率。损失间隔在
Section 6.1 of [RFC4342], with the modification in [RFC4828] (Section 3) for loss intervals of at most two round-trip times. 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. The CCID 3 Loss Intervals option is used to report loss interval lengths; see Section 8.6.
[RFC4342]的第6.1节，以及[RFC4828]（第3节）中针对最多两个往返时间的损失间隔所做的修改。总之，丢失间隔最多为1 RTT的可能丢失或带有ECN标记的数据包，然后是任意数量的未丢弃、未标记的数据包。CCID 3损耗间隔选项用于报告损耗间隔长度；见第8.6节。
For loss intervals of at most two round-trip times, CCID 4 calculates the loss event rate for that interval by counting the number of packets lost or marked, as described in Section 4.4 of [RFC4828]. Thus, for such a short loss interval with N data packets, including K lost or marked data packets, the loss interval length is calculated as N/K, instead as N. The Dropped Packets option is used to report K, the count of lost or marked data packets.
对于最多两个往返时间的丢失间隔，CCID 4通过计算丢失或标记的数据包数量来计算该间隔的丢失事件率，如[RFC4828]第4.4节所述。因此，对于具有N个数据分组（包括K个丢失或标记的数据分组）的这种短丢失间隔，丢失间隔长度被计算为N/K，而不是N。丢弃的分组选项用于报告K，丢失或标记的数据分组的计数。
Unlike CCID 3, the CCID 4 sender enforces a minimum interval of 10 ms between data packets, regardless of the allowed transmit rate. If operating system scheduling granularity makes this impractical, up to one additional packet MAY be sent per timeslice, providing that no more than three packets are sent in any 30 ms interval.
与CCID 3不同，CCID 4发送方在数据包之间强制执行10 ms的最小间隔，而与允许的传输速率无关。如果操作系统调度粒度使得这不切实际，则每个时间片最多可以发送一个额外的数据包，前提是在任何30ms间隔内发送的数据包不超过三个。
Other Congestion Control Mechanisms
其他拥塞控制机制
The other congestion control mechanisms such as slow-start and feedback packets are exactly as in CCID 3, and are described in the subsection on "Other Congestion Control Mechanisms" of Section 5 in [RFC4342].
其他拥塞控制机制，如慢启动和反馈数据包，与CCID 3完全相同，并在[RFC4342]第5节“其他拥塞控制机制”小节中描述。
This is described in Section 5.1 of [RFC4342]. If Faster Restart is standardized in the IETF for TFRC [KFS07], then Faster Restart MAY be implemented in CCID4 without having to wait for an explicit update to this document.
[RFC4342]第5.1节对此进行了描述。如果TFRC[KFS07]的IETF标准化了更快的重启，那么CCID4中可以实现更快的重启，而无需等待本文档的明确更新。
This is described in Section 5.2 of [RFC4342].
[RFC4342]第5.2节对此进行了描述。
CCID 4 is intended for applications that use a fixed small segment size, or that vary their segment size in response to congestion.
CCID4适用于使用固定小段大小的应用程序，或根据拥塞情况改变其段大小的应用程序。
The CCID 4 sender uses a segment size of 1460 bytes in the TCP throughput equation. This gives the CCID 4 sender roughly the same sending rate in bytes per second as a TFRC flow using 1460-byte segments but experiencing the same packet drop rate.
CCID 4发送方在TCP吞吐量等式中使用1460字节的段大小。这使得CCID 4发送器的发送速率（字节/秒）与使用1460字节段的TFRC流大致相同，但具有相同的丢包速率。
The acknowledgements are as specified in Section 6 of [RFC4342] with the exception of the Loss Interval lengths specified below.
确认如[RFC4342]第6节规定，但下文规定的损失间隔长度除外。
The loss interval definition is as defined in Section 6.1 of [RFC4342], except as specified below. Section 6.1.1 of RFC 4342 specifies that for all loss intervals except the first one, the data length equals the sequence length minus the number of non-data packets the sender transmitted during the loss interval, with a minimum data length of one packet. For short loss intervals of at most two round-trip times, TFRC-SP computes the loss interval length as the data length divided by the number of dropped or marked data packets (rather than as the data length of the loss interval).
损失间隔定义如[RFC4342]第6.1节所述，以下规定除外。RFC 4342第6.1.1节规定，对于除第一个丢失间隔外的所有丢失间隔，数据长度等于序列长度减去发送方在丢失间隔期间传输的非数据包数量，最小数据长度为一个包。对于最多两个往返时间的短丢失间隔，TFRC-SP将丢失间隔长度计算为数据长度除以丢弃或标记的数据包数（而不是丢失间隔的数据长度）。
Section 5.4 of RFC 4342 describes when to use the most recent loss interval in the calculation of the average loss interval. [RFC4828] adds to this procedure the restriction that the most recent loss interval is only used in the calculation of the average loss interval if the most recent loss interval is greater than two round-trip times. The pseudocode is given in Section 3 of [RFC4828].
RFC 4342第5.4节描述了在计算平均损失间隔时何时使用最新损失间隔。[RFC4828]在此程序中增加了一个限制，即如果最近的损耗间隔大于两个往返时间，则最近的损耗间隔仅用于计算平均损耗间隔。[RFC4828]第3节给出了伪代码。
The congestion control on acknowledgements is as specified in Section 6.2 of [RFC4342].
确认时的拥塞控制如[RFC4342]第6.2节所述。
Procedures for the acknowledgement of acknowledgements are as specified in Section 6.3 of [RFC4342].
确认程序如[RFC4342]第6.3节所述。
The procedure for detecting that the sender has gone quiescent is as specified in Section 6.4 of [RFC4342].
[RFC4342]第6.4节规定了检测发送器已静止的程序。
Procedures for the use of Explicit Congestion Notification (ECN) are as specified in Section 7 of [RFC4342].
[RFC4342]第7节规定了使用显式拥塞通知（ECN）的程序。
CCID 4 can make use of DCCP's Ack Vector, Timestamp, Timestamp Echo, and Elapsed Time options, and its Send Ack Vector and ECN Incapable features. CCID 4 also imports the currently defined CCID-3-specific options and features [RFC4342], augmented by the Dropped Packets option specified in this document. Each CCID4-specific option and feature contains the same data as the corresponding CCID 3 option or feature, and is interpreted in the same way, except as specified elsewhere in this document (or in a subsequent IETF standards-track RFC that updates or obsoletes this specification).
CCID4可以利用DCCP的Ack向量、时间戳、时间戳回音和经过时间选项，以及其发送Ack向量和ECN功能。CCID 4还导入当前定义的CCID-3特定选项和功能[RFC4342]，并通过本文档中指定的丢弃数据包选项进行补充。每个CCID4特定选项和功能包含与相应CCID3选项或功能相同的数据，并以相同的方式解释，除非本文件其他地方另有规定（或更新或废除本规范的后续IETF标准跟踪RFC）。
Option DCCP- Section
Type Length Meaning Data? Reference
----- ------ ------- ----- ---------
128-183 Unassigned
184-190 Reserved for
experimental
and testing use
191 Unassigned
192 6 Loss Event Rate N 8.5
193 variable Loss Intervals N 8.6
194 6 Receive Rate N 8.3
195 variable Dropped Packets N 8.7
196-247 Unassigned
248-254 Reserved for
experimental
and testing use
255 Unassigned
Option DCCP- Section
Type Length Meaning Data? Reference
----- ------ ------- ----- ---------
128-183 Unassigned
184-190 Reserved for
experimental
and testing use
191 Unassigned
192 6 Loss Event Rate N 8.5
193 variable Loss Intervals N 8.6
194 6 Receive Rate N 8.3
195 variable Dropped Packets N 8.7
196-247 Unassigned
248-254 Reserved for
experimental
and testing use
255 Unassigned
Table 1: DCCP CCID 4 Options
表1:DCCP CCID 4选项
The "DCCP-Data?" column indicates that all currently defined CCID4- specific options MUST be ignored when they occur on DCCP-Data packets.
“DCCP数据”列表明，当当前定义的所有CCID4特定选项出现在DCCP数据包上时，必须忽略它们。
As with CCID 3, the following CCID-specific features are also defined.
与CCID 3一样，还定义了以下CCID特定功能。
Number Meaning Rule Value Req'd Reference
------ ------- ----- ----- ----- ---------
128-183 Unassigned
184-190 Reserved for experimental
and testing use
191 Unassigned
192 Send Loss Event Rate SP 0 N 8.4
193-247 Unassigned
248-254 Reserved for experimental
and testing use
255 Unassigned
Number Meaning Rule Value Req'd Reference
------ ------- ----- ----- ----- ---------
128-183 Unassigned
184-190 Reserved for experimental
and testing use
191 Unassigned
192 Send Loss Event Rate SP 0 N 8.4
193-247 Unassigned
248-254 Reserved for experimental
and testing use
255 Unassigned
Table 2: DCCP CCID 4 Feature Numbers
表2:DCCP CCID 4功能编号
More information is available in Section 8 of [RFC4342].
更多信息见[RFC4342]第8节。
The use of the Window Counter Value in the DCCP generic header's CCVal field is as specified in Section 8.1 of [RFC4342]. In addition to their use described in CCID 3, the CCVal counters are used by the receiver in CCID 4 to determine when the length of a loss interval is at most two round-trip times. None of these procedures require the receiver to maintain an explicit estimate of the round-trip time. However, Section 8.1 of [RFC4342] gives a procedure that implementors may use if they wish to keep such an RTT estimate using CCVal.
DCCP通用报头的CCVal字段中窗口计数器值的使用如[RFC4342]第8.1节所述。除了CCID 3中描述的使用外，CCVal计数器还由CCID 4中的接收器用于确定丢失间隔的长度何时最多为两个往返时间。这些程序都不要求接收者保持对往返时间的明确估计。然而，[RFC4342]第8.1节给出了一个程序，如果实施者希望使用CCVal保持RTT估算值，则可以使用该程序。
The use of the Elapsed Time option is defined in Section 8.2 of [RFC4342].
[RFC4342]的第8.2节中定义了运行时间选项的使用。
The Receive Rate option is as specified in Section 8.3 of [RFC4342].
接收速率选项如[RFC4342]第8.3节所述。
The Send Loss Event Rate feature is as defined in Section 8.4 of [RFC4342].
发送丢失事件速率特性如[RFC4342]第8.4节所述。
See [RFC5348], Section 5, and [RFC4828], Section 4.4, for a normative calculation of the loss event rate. Section 4.4 of [RFC4828] modifies the calculation of the loss interval size for loss intervals of at most two round-trip times.
有关损失事件率的标准计算，请参见[RFC5348]第5节和[RFC4828]第4.4节。[RFC4828]第4.4节修改了最多两个往返时间的损耗间隔的损耗间隔大小计算。
If the CCID 4 receiver is using the Loss Event Rate option, the receiver needs to be able to determine if a loss interval is short, of at most two round-trip times. The receiver can heuristically detect a short loss interval by using the Window Counter in arriving data packets. The sender increases the Window Counter by 1 every quarter of a round-trip time, with the caveat that the Window Counter is never increased by more than five, modulo 16, from one data packet to the next. Using the Window Counter to detect loss intervals of at most two round-trip times could result in some false positives, with some longer loss intervals incorrectly identified as short ones. For example, if the loss interval contained data packets with only two Window Counter values, say, k and k+5, then the receiver could not tell if the loss interval was at most two round-trip times long or not. Similarly, if the sender sent data packets with Window Counter values of 4, 8, 12, 0, 5, but the packets with Window Counter values of 8, 12, and 0 were lost in the network, then the receiver would only receive data packets with Window Counter values of 4 and 5, and would incorrectly infer that the loss interval was at most two round-trip times.
如果CCID 4接收器使用丢失事件率选项，接收器需要能够确定丢失间隔是否短，最多两个往返时间。接收机可以通过在到达的数据包中使用窗口计数器来试探性地检测短的丢失间隔。发送方每四分之一往返时间将窗口计数器增加1，但要注意，从一个数据包到下一个数据包，窗口计数器的增加量不得超过5（模16）。使用窗口计数器检测最多两个往返时间的丢失间隔可能会导致一些误报，一些较长的丢失间隔被错误地识别为较短的丢失间隔。例如，如果丢失间隔包含仅具有两个窗口计数器值（例如，k和k+5）的数据分组，则接收器无法判断丢失间隔是否最多两个往返时间长。类似地，如果发送方发送了窗口计数器值为4、8、12、0、5的数据包，但窗口计数器值为8、12和0的数据包在网络中丢失，则接收方将只接收窗口计数器值为4和5的数据包，并将错误地推断丢失间隔最多为两个往返时间。
The Loss Event Rate option is as specified in Section 8.5 of [RFC4342].
损失事件率选项如[RFC4342]第8.5节所述。
See [RFC5348] (Section 5) and [RFC4828] for a normative calculation of the loss event rate.
有关损失事件率的标准计算，请参见[RFC5348]（第5节）和[RFC4828]。
The Loss Intervals option is as specified in Section 8.6 of [RFC4342].
损失间隔选项如[RFC4342]第8.6节所述。
This section describes the Dropped Packets option, a mechanism for reporting the number of lost and marked packets per loss interval. By reporting both the Loss Intervals and Dropped Packets options on the feedback packets, the receiver gives the sender sufficient information to calculate the loss event rate, or to verify the calculation of the reported loss event rate, if the sender so desires.
本节介绍丢弃的数据包选项，这是一种报告每个丢失间隔丢失和标记的数据包数量的机制。通过报告反馈数据包上的丢失间隔和丢弃数据包选项，接收方向发送方提供足够的信息，以计算丢失事件率，或验证所报告的丢失事件率的计算（如果发送方愿意）。
The core information reported by CCID 4 receivers is a list of recent loss intervals, where 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
CCID 4接收器报告的核心信息是最近丢失间隔的列表，其中丢失间隔以丢失或ECN标记的数据包开始；继续使用最多一个往返时间的数据包，这些数据包可能会丢失或标记，也可能不会丢失或标记；并以任意长的一系列未删除、未标记的数据完成
packets. Loss intervals model the congestion behavior of TCP NewReno senders, which reduce their sending rate at most once per window of data packets. Consequently, the number of packets lost in a loss interval is not important for either TCP's or TFRC's congestion response. CCID 3's Loss Intervals option reports the length of each loss interval's lossy part, not the number of packets that were actually lost or marked in that lossy part.
小包。丢失间隔对TCP NewReno发送方的拥塞行为进行了建模，每个数据包窗口最多减少一次发送速率。因此，在丢失间隔内丢失的数据包数量对于TCP或TFRC的拥塞响应都不重要。CCID3的丢失间隔选项报告每个丢失间隔有损部分的长度，而不是该有损部分中实际丢失或标记的数据包数。
However, for computing the loss event rate for periods that include short loss intervals the TFRC-SP sender needs to know the number of packets lost or marked in a loss interval, over and above the length of the loss interval in packets. The Dropped Packets option, a CCID4-specific option, reports this information. Together with the existing Loss Intervals option, the Dropped Packets option allows the CCID 4 sender to discover exactly how many packets were dropped from each loss interval. The receiver reports the number of lost or marked packets in its recently observed loss intervals using the Dropped Packets option.
然而，为了计算包含短丢失间隔的时段的丢失事件率，TFRC-SP发送方需要知道丢失间隔中丢失或标记的数据包数量，超过数据包中丢失间隔的长度。丢弃的数据包选项（CCID4特定的选项）报告此信息。与现有的丢失间隔选项一起，丢弃的数据包选项允许CCID 4发送方准确地发现每个丢失间隔丢弃了多少数据包。接收器使用丢弃的数据包选项报告其最近观察到的丢失间隔中丢失或标记的数据包的数量。
The Dropped Packets Option is specified as follows:
丢弃的数据包选项指定如下：
+--------+--------+-------...-------+--------+-------
|11000011| Length | Drop Count | More Drop Counts...
+--------+--------+-------...-------+--------+-------
Type=195 3 bytes
+--------+--------+-------...-------+--------+-------
|11000011| Length | Drop Count | More Drop Counts...
+--------+--------+-------...-------+--------+-------
Type=195 3 bytes
Figure 1: Dropped Packets Option
图1：丢弃的数据包选项
The Dropped Packets option contains information about one to 84 consecutive loss intervals, always including the most recent loss interval. As with the Loss Intervals option, intervals are listed in reverse chronological order. Should more than 84 loss intervals need to be reported, multiple Dropped Packets options can be sent; the second option begins where the first left off, and so forth.
丢弃的数据包选项包含关于一到84个连续丢失间隔的信息，始终包括最近的丢失间隔。与“损失间隔”选项一样，间隔按相反的时间顺序列出。如果需要报告84个以上的丢失间隔，可以发送多个丢弃的数据包选项；第二个选项从第一个选项停止的地方开始，依此类推。
One Drop Count is specified per loss interval. Drop Count is a 24- bit number that equals the number of packets, lost or received, ECN-marked during the corresponding loss interval. By definition, this number MUST NOT exceed the corresponding loss interval's Loss Length.
每个丢失间隔指定一次丢弃计数。Drop Count是一个24位数字，等于在相应的丢失间隔内标记的丢失或接收的数据包数。根据定义，该数字不得超过相应损耗间隔的损耗长度。
CCID 4 receivers MUST report Dropped Packets options with every feedback packet. Any packet containing a Loss Intervals option MUST also contain a Dropped Packets option covering the same loss intervals. If a feedback packet does not include a relevant Dropped Packets option, and the CCID 4 sender is computing the loss event rate itself, the sender MUST treat the relevant loss intervals' Drop Counts as equal to the corresponding Loss Lengths, as specified below.
CCID 4接收器必须在每个反馈数据包中报告丢弃的数据包选项。包含丢失间隔选项的任何数据包还必须包含覆盖相同丢失间隔的丢弃数据包选项。如果反馈数据包不包括相关丢弃数据包选项，且CCID 4发送方正在计算丢失事件率本身，则发送方必须将相关丢失间隔的丢弃计数视为等于相应的丢失长度，如下所述。
Consider a CCID 4 receiver. As specified in Section 8.6.1 of RFC 4342, the receiver sends the Loss Intervals option for all intervals that have not been acknowledged by the sender. When this receiver sends a feedback packet containing information about the N most recent loss intervals (packaged in one or more Loss Intervals options), then the receiver includes on the same feedback packet one or more Dropped Packets options covering exactly those N loss intervals. CCID 4 senders MUST ignore Drop Counts information for loss intervals not covered by a Loss Intervals option on the same feedback packet. Conversely, a CCID 4 sender might want to interpolate Drop Counts information for a loss interval not covered by any Dropped Packets options; such a sender MUST use the corresponding loss interval's Loss Length as its Drop Count.
考虑一个CIDD 4接收器。按照RFC 4342第8.6.1节的规定，对于发送方未确认的所有间隔，接收方发送丢失间隔选项。当该接收机发送包含关于N个最近的丢失间隔（打包在一个或多个丢失间隔选项中）的信息的反馈分组时，接收机在同一反馈分组上包括正好覆盖那些N个丢失间隔的一个或多个丢弃的分组选项。CCID 4发送方必须忽略同一反馈数据包上丢失间隔选项未涵盖的丢失间隔的丢弃计数信息。相反，CCID 4发送方可能希望为任何丢弃的分组选项都不包括的丢失间隔插入丢弃计数信息；这样的发送方必须使用相应的丢失间隔的丢失长度作为其丢弃计数。
Each loss interval's Drop Count MUST, by definition, be less than or equal to its Loss Length. A Drop Count that exceeds the corresponding Loss Length MUST be treated as equal to the Loss Length.
根据定义，每个丢失间隔的丢弃计数必须小于或等于其丢失长度。超过相应损耗长度的跌落计数必须视为等于损耗长度。
Consider the following sequence of packets, where "-" represents a safely delivered packet and "*" represents a lost or marked packet. This sequence is repeated from [RFC4342].
考虑下面的数据包序列，其中“-”表示一个安全传递的数据包，而“*”表示丢失或标记的数据包。此序列从[RFC4342]重复。
Sequence
Numbers: 0 10 20 30 40 44
| | | | | |
----------*--------***-*--------*----------*-
Sequence
Numbers: 0 10 20 30 40 44
| | | | | |
----------*--------***-*--------*----------*-
Figure 2: Sequence of Delivered (-) and Lost (*) Packets
图2：传递（-）和丢失（*）数据包的顺序
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
Figure 3: Loss Intervals for the Packet Sequence
图3：数据包序列的丢失间隔
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; for interpretation of this
在确认号为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、0、1、0、8、0、0、0、10、128、0、0、0、0、0、0、0、0、15；为了解释这一点
option, see [RFC4342]. A Dropped Packets option sent in tandem on this packet would contain the bytes 195,14, 0,0,1, 0,0,4, 0,0,1, 0,0,0. This is interpreted as follows.
选项，请参阅[RFC4342]。在此数据包上串联发送的丢弃数据包选项将包含字节195,14,0,0,1,0,0,4,0,0,1,0,0,0。这解释如下。
195 The Dropped Packets option number.
195丢弃的数据包选项号。
14 The length of the option, including option type and length bytes. This option contains information about (14 - 2)/3 = 4 loss intervals. Note that the two most recent sequence numbers are not yet part of any loss interval -- the Loss Intervals option includes them in its Skip Length -- and are thus not included in the Dropped Packets option.
14选项的长度，包括选项类型和长度字节。此选项包含关于（14-2）/3=4损失间隔的信息。请注意，最近的两个序列号还不是任何丢失间隔的一部分（丢失间隔选项将它们包含在其跳过长度中），因此不包括在丢弃的数据包选项中。
0,0,1 These bytes define the Drop Count for L3, which is 1. As required, the Drop Count is less than or equal to L3's Loss Length, which is also 1.
0,0,1这些字节定义L3的丢弃计数，即1。根据需要，丢弃计数小于或等于L3的丢失长度，也就是1。
0,0,4 The Drop Count for L2 is 4.
0,0,4 L2的丢弃计数为4。
0,0,1 The Drop Count for L1 is 1.
0,0,1 L1的丢弃计数为1。
0,0,0 Finally, the Drop Count for L0 is 0.
0,0,0最后，L0的丢弃计数为0。
Verifying congestion control compliance with ECN is as discussed in Section 9 of [RFC4342].
[RFC4342]第9节讨论了验证拥塞控制是否符合ECN。
Procedures for verifying the ECN Nonce Echo are as specified in Section 9.1 of [RFC4342].
[RFC4342]第9.1节规定了验证ECN当前回波的程序。
Section 9.2 of [RFC4342] discusses the sender's possible verification of loss intervals and loss event rate information reported by the receiver.
[RFC4342]第9.2节讨论了发送方对接收方报告的损失间隔和损失事件率信息的可能验证。
The use of the Timestamp option is as discussed in Section 10.1 of [RFC4342].
时间戳选项的使用如[RFC4342]第10.1节所述。
The use of the window counter by the receiver to determine if multiple lost packets belong to the same loss event is as described in Section 10.2 of [RFC4342].
接收机使用窗口计数器确定多个丢失数据包是否属于同一丢失事件，如[RFC4342]第10.2节所述。
The procedure for sending feedback packets is as described in Section 10.3 of [RFC4342].
发送反馈数据包的程序如[RFC4342]第10.3节所述。
This section discusses design considerations for the field sizes in the Loss Intervals and Dropped Packets options.
本节讨论丢失间隔和丢弃数据包选项中字段大小的设计注意事项。
Section 8.6 of RFC 4342 specifies a Loss Intervals option with three fields for each loss interval, for reporting the Lossless Length, Loss Length, and Data Length. Each field is specified to be three bytes. Section 8.6 of this document specifies that CCID 4 use the same Loss Intervals option as CCID 3, with the same field sizes. This has the significant advantage of minimizing the implementation differences between CCID 3 and CCID 4. However, it has been suggested that CCID 4 *could* use a Loss Intervals option with smaller field sizes, since a CCID 4 sender enforces a minimum interval of 10 ms between data packets. This section explains the reason for CCID 4 to use the same Loss Intervals option as specified for CCID 3.
RFC 4342第8.6节规定了一个损耗间隔选项，每个损耗间隔有三个字段，用于报告无损长度、损耗长度和数据长度。每个字段指定为三个字节。本文件第8.6节规定，CCID 4使用与CCID 3相同的损耗间隔选项，字段大小相同。这具有最大限度地减少CCID3和CCID4之间的实现差异的显著优势。然而，有人建议CCID 4*可以*使用具有较小字段大小的丢失间隔选项，因为CCID 4发送方在数据分组之间强制执行最小10 ms的间隔。本节解释CCID 4使用与CCID 3相同的损耗间隔选项的原因。
The Lossless Length field reports the number of packets in the loss intervals' lossless part, and the Loss Length field reports the number of packets in the loss interval's lossy part. The Data Length field reports the number of packets in the loss interval's data length (excluding non-data packets). A two-byte Data Length field can report a data length of 65,536 packets, corresponding to a loss event rate of 0.00002; this is enough to give the CCID 4 sender an allowed sending rate of roughly 250 packets per RTT, which is enough for a connection with a round-trip time of at most 2.5 seconds. For a CCID 4 connection with a larger round-trip time, the three-byte Lossless Length and Data Length fields would be needed.
无损长度字段报告丢失间隔的无损部分中的数据包数量，而丢失长度字段报告丢失间隔的有损部分中的数据包数量。数据长度字段报告丢失间隔数据长度中的数据包数（不包括非数据包）。两字节数据长度字段可报告65536个数据包的数据长度，对应于0.00002的丢失事件率；这足以使CCID 4发送方获得每RTT大约250个数据包的允许发送速率，这对于往返时间最多为2.5秒的连接来说就足够了。对于具有较大往返时间的CCID 4连接，需要三字节无损长度和数据长度字段。
For the Loss Length field in the Loss Intervals option, reporting the number of packets in the one-RTT lossy part of the loss interval, a one-byte field would not be sufficient for a CCID 4 connection with a long RTT (three seconds or longer). For the Loss Length field, a two-byte field should be sufficient for CCID 4. However, our
对于Loss interval（丢失间隔）选项中的Loss Length（丢失长度）字段，报告丢失间隔的一个RTT有损部分中的数据包数，一个字节字段对于具有长RTT（三秒或更长）的CCID 4连接是不够的。对于丢失长度字段，对于CCID 4，两字节字段应该足够了。然而，我们的
judgement is that the advantages of using the same Loss Intervals option as in CCID 3 outweigh any advantages of using a CCID 4 Loss Intervals option that uses eight bytes instead of nine bytes for reporting the fields for each loss interval.
判断是，使用与CCID 3中相同的丢失间隔选项的优势大于使用CCID 4丢失间隔选项的任何优势，该选项使用八个字节而不是九个字节来报告每个丢失间隔的字段。
Section 8.7 specifies the Dropped Packets option for reporting the number of lost or marked packets per loss interval, allocating three bytes for the drop count field for each loss interval reported. The three-byte field is partly for simplicity, to give the same field size as the fields in the Loss Intervals option specified in RFC 4342. It has been suggested that CCID 4 *could* use a smaller field size for the Dropped Packets option. This section discusses the issue of the size of the drop count field in the Dropped Packets option.
第8.7节规定了丢弃数据包选项，用于报告每个丢失间隔丢失或标记数据包的数量，为每个报告的丢失间隔的丢弃计数字段分配三个字节。三字节字段部分是为了简单起见，以提供与RFC 4342中指定的丢失间隔选项中的字段相同的字段大小。有人建议CCID 4*可以*为丢弃的数据包选项使用较小的字段大小。本节讨论丢弃数据包选项中丢弃计数字段的大小问题。
It is not necessary to specify a three-byte field for the Dropped Packets option. A one-byte field would allow a reported drop count of 255, and a two-byte field would allow a reported drop count of 65,535. A two-byte field would clearly be sufficient for the drop count field for CCID 4.
不必为丢弃的数据包选项指定三字节字段。单字节字段允许报告的丢弃计数为255，双字节字段允许报告的丢弃计数为65535。对于CCID 4的drop count字段，两字节字段显然就足够了。
In fact, a one-byte field would *probably* be adequate for reporting the drop count for a loss interval in a CCID 4 connection. Because a CCID 4 sender enforces a minimum interval of 10 ms between data packets, a sender would need a round-trip time of over 2.55 seconds to have more than 255 packets lost or marked in a single loss interval; round-trip times of greater than three seconds are not unusual for some flows traversing satellite links. The drop count field is used in CCID 4 to compute the actual loss rate for short loss intervals, rather than using the loss event rate that is used for longer loss intervals. If a loss interval of at most two round-trip times included N packets sent, with more than 255 of those packets lost or marked, a drop count field of one byte would allow a drop count of at most 255 to be reported, resulting in a computed loss rate for that interval of 255/N. This loss rate might be less than the actual loss rate, but it is significantly higher than the loss event rate of 1/N, and should be sufficient to prevent a steady-state condition of a CCID 4 connection with multiple packets dropped each round-trip time. Thus, a one-byte field would probably be adequate for reporting the drop count for a loss interval in a CCID 4 connection. However, at the moment this document specifies a three-byte field, for consistency with the field size in the Loss Intervals option.
事实上，一个单字节字段*可能*足以报告CCID 4连接中丢失间隔的丢弃计数。由于CCID 4发送方要求数据包之间的最小间隔为10 ms，因此发送方需要超过2.55秒的往返时间才能在单个丢失间隔内丢失或标记255个以上的数据包；对于一些穿越卫星链路的流来说，大于3秒的往返时间并不罕见。在CCID 4中，drop count字段用于计算短损失间隔的实际损失率，而不是使用更长损失间隔的损失事件率。如果最多两个往返时间的丢失间隔包括发送的N个数据包，其中超过255个数据包丢失或标记，则一个字节的丢弃计数字段将允许报告最多255个丢弃计数，从而导致该间隔的计算丢失率为255/N。此丢失率可能小于实际丢失率，但是，它明显高于1/N的丢失事件率，并且应该足以防止CCID 4连接的稳态条件，即每次往返时间都有多个数据包丢失。因此，一个单字节字段可能足以报告CCID 4连接中丢失间隔的丢弃计数。但是，为了与丢失间隔选项中的字段大小保持一致，本文档目前指定了一个三字节字段。
TFRC-SP is a congestion control mechanism defined in RFC 4828. Section 10 of [RFC4828] describes why TFRC-SP is currently specified as experimental and why it is not intended for widespread deployment at this time in the global Internet. Since TFRC-SP is Experimental, CCID 4 is therefore also considered experimental. If the IETF publishes a Standards-Track RFC that changes the status of TFRC-SP, then CCID 4 should then be updated to reflect the change of status.
TFRC-SP是RFC 4828中定义的拥塞控制机制。[RFC4828]的第10节描述了为什么TFRC-SP目前被指定为实验性的，以及为什么目前不打算在全球互联网上广泛部署。由于TFRC-SP是实验性的，因此CCID 4也被认为是实验性的。如果IETF发布了改变TFRC-SP状态的标准跟踪RFC，则应更新CCID 4以反映状态的变化。
Security considerations include those discussed in Section 11 of [RFC4342]. There are no new security considerations introduced by CCID 4.
安全注意事项包括[RFC4342]第11节中讨论的事项。CCID4没有引入新的安全注意事项。
This specification defines the value 4 in the DCCP CCID namespace managed by IANA. This is a permanent codepoint, as is needed for experimentation across the Internet using different codebases.
本规范定义了IANA管理的DCCP CCID命名空间中的值4。这是一个永久性的代码点，在互联网上使用不同的代码库进行实验时需要这样做。
CCID 4 also uses three sets of numbers whose values have been allocated by IANA, namely CCID4-specific Reset Codes, option types, and feature numbers. 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 [RFC5226].
CCID4还使用IANA分配的三组数值，即CCID4特定重置代码、选项类型和功能编号。除试验和测试使用[RFC3692]外，本文件未对重置代码范围进行特殊分配。我们参考[RFC5226]中概述的标准行动政策。
Each entry in the DCCP CCID 4 Reset Code registry contains a CCID4- 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 4重置代码注册表中的每个条目都包含一个特定于CCID4的重置代码，该代码的范围为128-255；复位代码的简短说明；以及对定义重置代码的RFC的引用。重置代码184-190和248-254永久保留供实验和测试使用。其余的重置代码（128-183、191-247和255）目前保留，并应与标准行动政策一起分配，该政策要求IESG审查和批准以及标准跟踪IETF RFC发布。
Each entry in the DCCP CCID 4 option type registry contains a CCID4- 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 includes the value 195 allocated for the Dropped Packets option. This document
DCCP CCID 4选项类型注册表中的每个条目都包含一个特定于CCID4的选项类型，它是一个范围为128-255的数字；期权的名称，如“损失间隔”；以及对定义选项类型的RFC的引用。注册表最初使用第8节表1中的值填充。这包括为丢弃的分组选项分配的值195。本文件
allocates option types 192-195, and option types 184-190 and 248-254 are permanently reserved for experimental and testing use. The remaining option types -- 128-183, 191, 196-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.
分配选项类型192-195，选项类型184-190和248-254永久保留供实验和测试使用。其余的选项类型（128-183、191、196-247和255）目前保留，应与标准行动政策一起分配，该政策要求IESG审查和批准以及标准跟踪IETF RFC发布。
Each entry in the DCCP CCID 4 feature number registry contains a CCID4-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 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.
DCCP CCID 4功能部件编号注册表中的每个条目都包含CCID4特定的功能部件编号，该编号的范围为128-255；功能的名称，如“发送丢失事件率”；以及对定义特征编号的RFC的引用。注册表最初使用第8节表2中的值填充。本文件分配了特征编号192，特征编号184-190和248-254永久保留供实验和测试使用。其余的功能部件编号（128-183、191、193-247和255）目前保留，应与标准行动政策一起分配，该政策要求IESG审查和批准以及标准跟踪IETF RFC出版物。
We thank Gorry Fairhurst, Alfred Hoenes, Ian McDonald, Gerrit Renker, and Leandro Sales for feedback on this document.
我们感谢Gorry Fairhurst、Alfred Hoenes、Ian McDonald、Gerrit Renker和Leandro Sales对本文件的反馈。
[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月。
[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月。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006.
[RFC4342]Floyd，S.，Kohler，E.，和J.Padhye，“数据报拥塞控制协议（DCCP）拥塞控制ID 3的配置文件：TCP友好速率控制（TFRC）”，RFC 43422006年3月。
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007.
[RFC4828]Floyd，S.和E.Kohler，“TCP友好速率控制（TFRC）：小数据包（SP）变体”，RFC 48282007年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[RFC5348]Floyd，S.，Handley，M.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 5348，2008年9月。
[KFS07] Kohler, E., Floyd, S., and A. Sathiaseelan, "Faster Restart for TCP Friendly Rate Control (TFRC)", Work in Progress, July 2008.
[KFS07]Kohler，E.，Floyd，S.，和A.Sathiaseelan，“TCP友好速率控制（TFRC）的更快重启”，正在进行的工作，2008年7月。
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