Internet Engineering Task Force (IETF) G. Renker
Request for Comments: 6323 G. Fairhurst
Updates: 4342, 5622 University of Aberdeen
Category: Standards Track July 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) G. Renker
Request for Comments: 6323 G. Fairhurst
Updates: 4342, 5622 University of Aberdeen
Category: Standards Track July 2011
ISSN: 2070-1721
Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP)
数据报拥塞控制协议（DCCP）的发送方RTT估计选项
Abstract
摘要
This document specifies an update to the round-trip time (RTT) estimation algorithm used for TFRC (TCP-Friendly Rate Control) congestion control by the Datagram Congestion Control Protocol (DCCP). It updates specifications for the CCID-3 and CCID-4 Congestion Control IDs of DCCP.
本文件规定了数据报拥塞控制协议（DCCP）用于TFRC（TCP友好速率控制）拥塞控制的往返时间（RTT）估计算法的更新。它更新了DCCP的CCID-3和CCID-4拥塞控制ID的规范。
The update addresses parameter-estimation problems occurring with TFRC-based DCCP congestion control. It uses a recommendation made in the original TFRC specification to avoid the inherent problems of receiver-based RTT sampling, by utilising higher-accuracy RTT samples already available at the sender.
更新解决了基于TFRC的DCCP拥塞控制中出现的参数估计问题。它使用原始TFRC规范中提出的建议，通过使用发送方已有的更高精度RTT样本，避免基于接收器的RTT采样的固有问题。
It is integrated into the feature set of DCCP as an end-to-end negotiable extension.
它作为端到端可协商的扩展集成到DCCP的功能集中。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6323.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6323.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problems Caused by Sampling the RTT at the Receiver . . . . . 4
2.1. List of Problems Encountered with a Real Implementation . 4
2.2. Other Areas Affected by the RTT Sampling Problems . . . . 5
2.2.1. Measured Receive Rate X_recv . . . . . . . . . . . . . 6
2.2.2. Disambiguation and Accuracy of Loss Intervals . . . . 6
2.2.3. Determining Quiescence . . . . . . . . . . . . . . . . 6
2.2.4. Practical Considerations . . . . . . . . . . . . . . . 7
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Options and Features . . . . . . . . . . . . . . . . . . . 7
3.2.1. RTT Estimate Option . . . . . . . . . . . . . . . . . 7
3.2.2. Send RTT Estimate Feature . . . . . . . . . . . . . . 9
3.3. Basic Usage . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Receiver Robustness Measures . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Option Types . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Feature Numbers . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problems Caused by Sampling the RTT at the Receiver . . . . . 4
2.1. List of Problems Encountered with a Real Implementation . 4
2.2. Other Areas Affected by the RTT Sampling Problems . . . . 5
2.2.1. Measured Receive Rate X_recv . . . . . . . . . . . . . 6
2.2.2. Disambiguation and Accuracy of Loss Intervals . . . . 6
2.2.3. Determining Quiescence . . . . . . . . . . . . . . . . 6
2.2.4. Practical Considerations . . . . . . . . . . . . . . . 7
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Options and Features . . . . . . . . . . . . . . . . . . . 7
3.2.1. RTT Estimate Option . . . . . . . . . . . . . . . . . 7
3.2.2. Send RTT Estimate Feature . . . . . . . . . . . . . . 9
3.3. Basic Usage . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Receiver Robustness Measures . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Option Types . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Feature Numbers . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a transport protocol for connection-oriented, unreliable, and congestion-controlled datagram delivery. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID; [RFC4340], Section 10).
数据报拥塞控制协议（DCCP）[RFC4340]是一种面向连接、不可靠和拥塞控制的数据报传输协议。在DCCP中，应用程序可以选择拥塞控制机制，每个机制由拥塞控制标识符（CCID；[RFC4340]，第10节）指定。
This document defines a Standards-Track update to the sender and receiver sides of two rate-based DCCP congestion control IDs: CCID-3 [RFC4342] and the Experimental CCID-4 variant [RFC5622].
本文档定义了两个基于速率的DCCP拥塞控制ID的发送方和接收方的标准跟踪更新：CCID-3[RFC4342]和实验CCID-4变体[RFC5622]。
Both CCIDs are based on the principles of TCP-Friendly Rate Control (TFRC) [RFC5348], which performs rate-based congestion control. Its feedback mechanism differs from that used by window-based congestion control such as in TCP. As a consequence, in TFRC the feedback may be sent less frequently (e.g., once per round-trip time). Furthermore, a measured RTT estimate is directly used as the basis for computing the (TCP-friendly) transmission rate.
这两种CCID都基于TCP友好速率控制（TFRC）[RFC5348]的原理，后者执行基于速率的拥塞控制。它的反馈机制不同于TCP中基于窗口的拥塞控制所使用的机制。因此，在TFRC中，反馈发送的频率可能会降低（例如，每往返一次）。此外，测量的RTT估计直接用作计算（TCP友好）传输速率的基础。
In TFRC-based protocols, packets are rate-paced over an RTT, instead of allowing them to be sent back-to-back as they could be in TCP; thus, accurate RTT estimation is important to ensure appropriate pacing at the sender.
在基于TFRC的协议中，数据包通过RTT进行速率控制，而不是像在TCP中那样允许它们背靠背发送；因此，准确的RTT估计对于确保发送方的适当起搏非常重要。
The original specifications for CCID-3 and CCID-4, in [RFC4342] and [RFC5622], both estimate the RTT at the receiver, using an algorithm based on the cyclic 4-bit window counter of the DCCP CCVal header. The method has implications that have been observed when using applications over DCCP implementations, resulting in infrequent and inaccurate RTT measurement.
[RFC4342]和[RFC5622]中CCID-3和CCID-4的原始规范均使用基于DCCP CCVal报头的循环4位窗口计数器的算法估计接收机处的RTT。该方法具有在DCCP实现上使用应用程序时观察到的含义，导致RTT测量不频繁且不准确。
This update addresses these RTT estimation problems by providing a solution based on a concept first recommended in [RFC5348], Section 3.2.1; i.e., to measure the RTT at the sender. That approach results in a higher reliability and frequency of samples and avoids the inherent problems of receiver-based RTT sampling discussed below.
本更新通过提供基于[RFC5348]第3.2.1节中首次推荐的概念的解决方案，解决了这些RTT估算问题；i、 例如，在发送器处测量RTT。该方法可提高采样的可靠性和频率，并避免下文讨论的基于接收机的RTT采样的固有问题。
The document begins by analysing the encountered problems in the next section. The update is presented in Section 3. We then discuss security considerations in Section 4 and list the resulting IANA considerations in Section 5.
本文件在下一节中首先分析遇到的问题。更新内容见第3节。然后，我们将在第4节中讨论安全注意事项，并在第5节中列出由此产生的IANA注意事项。
There are at least six areas that make a TFRC receiver vulnerable to inaccuracies or absence of (receiver-based) RTT samples:
TFRC接收器至少有六个方面容易受到不准确或缺少（基于接收器的）RTT样本的影响：
o the measured sending rate, X_recv ([RFC5348], Section 6.2);
o 测量的发送速率X_recv（[RFC5348]，第6.2节）；
o synthesis of the first loss interval ([RFC5348], Section 6.3.1);
o 第一损失间隔的合成（[RFC5348]，第6.3.1节）；
o disambiguation of loss events ([RFC4342], Section 10.2);
o 消除损失事件的歧义（[RFC4342]，第10.2节）；
o validation of loss intervals ([RFC4342], Section 6.1);
o 损失间隔的验证（[RFC4342]，第6.1节）；
o ensuring that at least one feedback packet is sent per RTT ([RFC4342], Section 10.3);
o 确保每个RTT至少发送一个反馈数据包（[RFC4342]，第10.3节）；
o determining quiescence periods ([RFC4342], Section 6.4).
o 确定静止期（[RFC4342]，第6.4节）。
This section summarizes several years of experience using the Linux implementation of CCID-3 and CCID-4. It lists the problems encountered with receiver-based RTT sampling over real networks, in a variety of wired and wireless environments and under different link-layer conditions.
本节总结了使用CCID-3和CCID-4的Linux实现的几年经验。它列出了在各种有线和无线环境以及不同链路层条件下，通过真实网络进行基于接收器的RTT采样时遇到的问题。
The Linux DCCP/TFRC implementation is based on the RTT-sampling algorithm specified in [RFC4342], Section 8.1. This algorithm relies on a coarse-grained window counter (units of RTT/4), and uses packet inter-arrival times to estimate the current RTT of the network.
Linux DCCP/TFRC实现基于[RFC4342]第8.1节中指定的RTT采样算法。该算法依赖于粗粒度窗口计数器（RTT/4单位），并使用数据包到达时间来估计网络的当前RTT。
The algorithm is effective only for packets with modulo-16 CCVal differences less than 5, due to limitations noted in Sections 8.1 and 10.3 of [RFC4342]. A CCVal difference less than 4 means sampling at sub-RTT scale; [RFC4342], Section 8.1 thus suggests differences between 2 and 4, the latter being preferable (equivalent to a full RTT). The same section limits the maximum CCVal difference between data-carrying packets to 5, in order to avoid wrap-around. As a consequence, it is not possible to determine the timing interval for adjacent packets with a CCVal difference greater than 4: such samples have to be discarded.
由于[RFC4342]第8.1节和第10.3节中指出的限制，该算法仅对模16 CCVal差异小于5的数据包有效。CCVal差值小于4表示在亚RTT标度下采样；[RFC4342]，第8.1节因此建议2和4之间存在差异，后者更可取（相当于完整RTT）。同一部分将数据传输包之间的最大CCVal差异限制为5，以避免环绕。因此，不可能确定CCVal差异大于4的相邻分组的定时间隔：必须丢弃此类样本。
A second problem arises when there are holes in the sequence space. Because the 4-bit CCVal counter may cycle around multiple times, it is not possible to determine window-counter wrap-around whenever sequence numbers of subsequent packets are not immediately adjacent. This problem occurs when packets are delayed, reordered, or lost in the network.
第二个问题出现在序列空间中有孔时。由于4位CCVal计数器可能循环多次，因此当后续数据包的序列号不直接相邻时，不可能确定窗口计数器循环。当数据包在网络中延迟、重新排序或丢失时，就会出现此问题。
As a result, RTT sampling has to be paused during times of loss. However, this aggravates the problem, since the sender now requires new feedback from the receiver, but the receiver is unable to provide accurate and up-to-date information: the receiver is unable to sample the RTT, and accordingly is also unable to estimate X_recv correctly, which then in turn affects X_Bps at the sender.
因此，RTT采样必须在丢失期间暂停。然而，这加剧了问题，因为发送方现在需要接收方的新反馈，但接收方无法提供准确和最新的信息：接收方无法对RTT进行采样，因此也无法正确估计X_recv，这反过来会影响发送方的X_Bps。
The third limitation arises from using inter-arrival times as representatives of network inter-packet gaps. It is well known that the inter-packet gap of packets is not constant along a network path. Furthermore, modern network interface cards do not necessarily deliver each packet at the time it is received, but rather in a bunch, to avoid overly frequent interrupts [MR97]. As a result, inter-packet arrival times may converge to zero, when subsequent packets are being delivered at virtually the same time.
第三个限制源于使用到达间隔时间作为网络数据包间隔的代表。众所周知，在网络路径上，分组的分组间隙不是恒定的。此外，现代网络接口卡不一定在接收到每个数据包时发送数据包，而是成束发送，以避免过度频繁的中断[MR97]。结果，当随后的分组几乎同时被传送时，分组间到达时间可能收敛到零。
The fourth problem is that of under-sampling and thus related to the first limitation. If loss occurs while the receiver has not yet had a chance to sample the RTT, it needs to fall back to some fixed RTT constant to plug into the equation of [RFC5348], Section 6.3.1. (The sender, for example, uses a fixed value of 1 second when it is unable to obtain an initial RTT sample; see [RFC5348], Section 4.2).
第四个问题是抽样不足，因此与第一个限制有关。如果在接收器还没有机会对RTT进行采样时发生损耗，则需要返回到某个固定的RTT常数，以插入第6.3.1节[RFC5348]中的方程式。（例如，当无法获得初始RTT样本时，发送方使用1秒的固定值；参见[RFC5348]，第4.2节）。
In particular, if the loss is caused by a transient condition, this fourth problem causes a subsequent deterioration of the connection (rate reduction), further aggravated by the fact that TFRC takes longer than common window-based protocols to recover from a reduction of its allowed sending rate.
特别是，如果丢失是由瞬态条件引起的，则第四个问题会导致连接的后续恶化（速率降低），TFRC从其允许发送速率的降低中恢复所需的时间比基于普通窗口的协议更长，这进一步加剧了这一事实。
Trying to smooth over these effects by imposing heavy filtering on the RTT samples did not substantially improve the situation, nor does it solve the problem of under-sampling.
试图通过对RTT样本施加大量过滤来消除这些影响并没有实质性地改善这种情况，也没有解决采样不足的问题。
The TFRC sender, on the other hand, is much better equipped to estimate the RTT and can do this more accurately. This is in particular due to the use of timestamps and elapsed time information ([RFC5348], Section 3.2.2), which are mandatory in CCID-3 (Sections 6 and 8.2 of [RFC4342]).
另一方面，TFRC发送器能够更好地估计RTT，并且能够更准确地估计RTT。这尤其是由于使用了时间戳和经过时间信息（[RFC5348]，第3.2.2节），这在CCID-3（第6节和第8.2节[RFC4342]）中是强制性的。
Here we analyse the impact that unreliability of receiver-based RTT sampling has on the areas listed at the beginning of Section 2.
在此，我们分析了基于接收器的RTT采样的不可靠性对第2节开头列出的区域的影响。
In addition, benefits of sender-based RTT sampling have already been pointed out in [RFC5348] and in the specification of CCID-3 at the end of Section 10.2 of [RFC4342].
此外，[RFC5348]和[RFC4342]第10.2节末尾的CCID-3规范中已经指出了基于发送方的RTT采样的好处。
A key problem is that the reliability of X_recv [RFC4342] depends directly upon the reliability and accuracy of RTT samples. This means that failures propagate from one parameter to another.
一个关键问题是X_recv[RFC4342]的可靠性直接取决于RTT样本的可靠性和准确性。这意味着故障会从一个参数传播到另一个参数。
Errata IDs 610 [Err610] and 611 [Err611] update [RFC4342] to use the definition of the receive rate as specified in [RFC5348].
勘误表IDs 610[Err610]和611[Err611]更新[RFC4342]以使用[RFC5348]中指定的接收速率定义。
Having an explicit (rather than a coarse-grained) RTT estimate allows measurement of X_recv with greater accuracy and isolates failure.
有一个明确的（而不是粗粒度的）RTT估计，可以更精确地测量X_recv，并隔离故障。
An explicit RTT estimate also enables the receiver to more accurately perform the test in step (2) of [RFC4342], Section 6.2, i.e., to check whether less or more than one RTT has passed since the last feedback.
明确的RTT估计还使接收机能够更准确地执行[RFC4342]第6.2节步骤（2）中的测试，即检查自上次反馈以来是否通过了少于或多于一个RTT。
Since a loss event is defined as one or more data packets in one RTT that are lost or marked with Explicit Congestion Notification (ECN; [RFC5348], Section 5.2), the receiver needs accurate RTT estimates to validate and accurately separate loss events. Moreover, Section 5.2 of [RFC5348] expressly indicates the sender RTT estimate is RECOMMENDED for this purpose.
由于丢失事件定义为一个RTT中丢失或标记有显式拥塞通知（ECN；[RFC5348]，第5.2节）的一个或多个数据包，因此接收器需要准确的RTT估计来验证和准确分离丢失事件。此外，[RFC5348]第5.2节明确指出，为此目的，建议使用发送方RTT估算值。
Having the sender RTT Estimate available further increases the accuracy of the information reported by the receiver. The definition of Loss Intervals in [RFC4342], Section 6.1 needs the RTT to separate the lossy parts; in particular, lossy parts spanning a period of more than one RTT are invalid.
发送方RTT估计可用进一步提高接收方报告的信息的准确性。[RFC4342]第6.1节中损耗间隔的定义需要RTT分离损耗部分；特别是，跨越一个以上RTT周期的有损零件无效。
A similar benefit arises in the computation of the loss event rate: as discussed in Section 9.2 of [RFC4342], it may happen that the sender and receiver compute different loss event rates, due to differences in the available timing information. An explicit RTT estimate increases the accuracy of information available at the receiver; thus, the sender may not need to recompute the (less reliable) loss event rate reported by the receiver.
损失事件率的计算也有类似的好处：如[RFC4342]第9.2节所述，由于可用时间信息的差异，发送方和接收方可能计算不同的损失事件率。显式RTT估计提高了接收机可用信息的准确性；因此，发送方可能不需要重新计算接收方报告的（不太可靠的）损失事件率。
The quiescence period is defined as max(2 * RTT, 0.2 sec) in Section 6.4 of [RFC4342]. An explicit RTT estimate avoids under- and over-estimating quiescence periods.
[RFC4342]第6.4节将静止期定义为最大值（2*RTT，0.2秒）。显式RTT估计可避免低估和高估静止期。
Using explicit RTT estimates contributes to greater robustness and can also result in simpler implementation.
使用显式RTT估计有助于提高鲁棒性，还可以简化实现。
First, it becomes easier to separate adjacent loss events. The 4-bit counter value wraps relatively frequently, which requires additional procedures to avoid aliasing effects.
首先，分离相邻损失事件变得更容易。4位计数器值相对频繁地换行，这需要额外的过程来避免锯齿效应。
Second, the receiver is better able to determine when to send feedback packets. It can perform the test described in step (2) of [RFC5348], Section 6.2 more accurately. Moreover, unnecessary expiration of the nofeedback timer (as described in [RFC4342], Section 10.3) can be avoided.
其次，接收器能够更好地确定何时发送反馈数据包。它可以更准确地执行[RFC5348]第6.2节步骤（2）中所述的测试。此外，可以避免无反馈定时器不必要的过期（如[RFC4342]第10.3节所述）。
Lastly, a sender-based RTT estimate option can be used by middleboxes to verify that a flow uses conforming end-to-end congestion control ([RFC4342], Section 10.2).
最后，中间盒可以使用基于发送方的RTT估计选项来验证流是否使用一致的端到端拥塞控制（[RFC4342]，第10.2节）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses the conventions of [RFC5348], [RFC4340], [RFC4342], and [RFC5622].
本文档使用[RFC5348]、[RFC4340]、[RFC4342]和[RFC5622]的约定。
All multi-byte field descriptions presented in this document are in network byte order (most significant byte first).
本文档中提供的所有多字节字段描述均按网络字节顺序排列（最高有效字节优先）。
This document defines a single TFRC-specific option, RTT Estimate, described in the next subsection.
本文件定义了单个TFRC特定选项RTT Estimate，将在下一小节中介绍。
Following the guidelines in [RFC4340], Section 15, the use of the RTT Estimate Option is governed by an associated feature, Send RTT Estimate Feature. This feature is described in Section 3.2.2.
按照[RFC4340]第15节中的指导原则，RTT估算选项的使用受相关功能“发送RTT估算功能”的约束。第3.2.2节描述了该特性。
The sender communicates its current RTT estimate to the receiver using an RTT Estimate Option.
发送方使用RTT估计选项将其当前RTT估计值传送给接收方。
+------+---------------+--------------+------------+
| Type | Option Length | Meaning | DCCP Data? |
+------+---------------+--------------+------------+
| 128 | 3/4/5 | RTT Estimate | Y |
+------+---------------+--------------+------------+
+------+---------------+--------------+------------+
| Type | Option Length | Meaning | DCCP Data? |
+------+---------------+--------------+------------+
| 128 | 3/4/5 | RTT Estimate | Y |
+------+---------------+--------------+------------+
Table 1: The RTT Estimate Option Defined by This Document
表1：本文件定义的RTT估算选项
Column meanings are as per [RFC4340], Section 5.8 (Table 3). This option MAY be placed in any DCCP packet, has option number 128 and a length of 3..5 bytes.
列含义符合[RFC4340]第5.8节（表3）。此选项可以放置在任何DCCP数据包中，选项号为128，长度为3..5字节。
A Sender RTT Estimate Option is valid if it satisfies one of the three following formats:
如果发送方RTT估算选项满足以下三种格式之一，则该选项有效：
+--------+--------+--------+
|10000000|00000011| RTT |
+--------+--------+--------+
Type=128 Length=3 Estimate
+--------+--------+--------+
|10000000|00000011| RTT |
+--------+--------+--------+
Type=128 Length=3 Estimate
+--------+--------+--------+--------+
|10000000|00000100| RTT |
+--------+--------+--------+--------+
Type=128 Length=4 Estimate
+--------+--------+--------+--------+
|10000000|00000100| RTT |
+--------+--------+--------+--------+
Type=128 Length=4 Estimate
+--------+--------+--------+--------+--------+
|10000000|00000101| RTT |
+--------+--------+--------+--------+--------+
Type=128 Length=5 Estimate
+--------+--------+--------+--------+--------+
|10000000|00000101| RTT |
+--------+--------+--------+--------+--------+
Type=128 Length=5 Estimate
The 1..3 value bytes of the option data carry the current RTT estimate of the sender, using a granularity of 1 microsecond. This allows values up to 16.7 seconds (corresponding to 0xFFFFFE) to be communicated.
选项数据的1..3值字节携带发送方的当前RTT估计值，使用1微秒的粒度。这允许传输最长16.7秒的值（对应于0xFFFFFE）。
A sender capable of sampling at sub-microsecond granularity SHOULD round up RTT samples to the next microsecond, to avoid under-estimating the RTT.
能够以亚微秒级粒度进行采样的发送器应将RTT样本四舍五入到下一微秒，以避免低估RTT。
The value 0xFFFFFF is reserved to indicate significant delay spikes, larger than 16.7 seconds. This is qualitative rather than quantitative information, to alert the receiver that there is a network problem (for instance, jamming on a wireless channel).
保留值0xFFFFFF以指示大于16.7秒的显著延迟峰值。这是定性而非定量信息，用于提醒接收器存在网络问题（例如，无线信道上的干扰）。
The use of the RTT Estimate Option on networks with RTTs larger than 16.7 seconds is not specified by this document (as per Section 3.3, the sender would then always report 0xFFFFFF).
本文件未规定在RTT大于16.7秒的网络上使用RTT估算选项（根据第3.3节，发送方将始终报告0xFFFFFF）。
A value of 0 indicates the absence of a valid RTT sample. The sender MUST set the value to 0 if it does not yet have an RTT estimate. RTT estimates of less than 1 microsecond MUST be reported as 1 microsecond.
值为0表示缺少有效的RTT样本。如果发送方还没有RTT估计值，则必须将该值设置为0。小于1微秒的RTT估计值必须报告为1微秒。
The sender SHOULD select the smallest format suitable to carry the RTT estimate (i.e., less than 1 byte of leading zeroes).
发送方应选择适合承载RTT估计值的最小格式（即小于1字节的前导零）。
The Send RTT Estimate feature lets endpoints negotiate whether the sender MUST provide RTT Estimate options on its data packets.
发送RTT估计功能允许端点协商发送方是否必须在其数据包上提供RTT估计选项。
Send RTT Estimate has feature number 128 and is server-priority. It takes 1-byte Boolean values; values greater than 1 are reserved.
Send RTT Estimate具有功能编号128，并且是服务器优先级。它采用1字节的布尔值；保留大于1的值。
+--------+-------------------+------------+---------------+-------+
| Number | Meaning | Rec'n Rule | Initial Value | Req'd |
+--------+-------------------+------------+---------------+-------+
| 128 | Send RTT Estimate | SP | 0 | N |
+--------+-------------------+------------+---------------+-------+
+--------+-------------------+------------+---------------+-------+
| Number | Meaning | Rec'n Rule | Initial Value | Req'd |
+--------+-------------------+------------+---------------+-------+
| 128 | Send RTT Estimate | SP | 0 | N |
+--------+-------------------+------------+---------------+-------+
Table 2: The Send RTT Estimate Feature Defined by This Document
表2：本文档定义的发送RTT估算功能
The column meanings are described in [RFC4340], Section 6.4.
[RFC4340]第6.4节描述了列的含义。
The Send RTT Estimate feature is OPTIONAL. An extension may implement it, but this specification does not require the feature to be understood by every DCCP implementation (see [RFC4340], Section 15). The feature is off by default (initial value of 0).
发送RTT估算功能是可选的。扩展可以实现该功能，但本规范不要求每个DCCP实现都理解该功能（参见[RFC4340]，第15节）。默认情况下，该功能处于禁用状态（初始值为0）。
DCCP B sends a "Mandatory Change R(Send RTT Estimate, 1)" to require DCCP A to send RTT Estimate options as part of its data traffic (DCCP A will reset the connection if it does not understand this feature).
DCCP B发送“强制更改R（发送RTT估算，1）”以要求DCCP a发送RTT估算选项作为其数据通信量的一部分（如果DCCP a不了解此功能，将重置连接）。
When the Send RTT Estimate Feature is enabled, the sender MUST provide an RTT Estimate Option on all of its Data, DataAck, Sync, and SyncAck packets. It MAY in addition provide the RTT Estimate Option on other packet types, such as DCCP-Ack. If the RTT is larger than the maximum representable value (0xFFFFFE), the sender MUST set the value of the RTT Estimate Option to 0xFFFFFF.
当启用发送RTT估计功能时，发送方必须对其所有数据、DataAck、Sync和SyncAck数据包提供RTT估计选项。此外，它还可以对其他分组类型（例如DCCP Ack）提供RTT估计选项。如果RTT大于最大可表示值（0xFFFFFE），发送方必须将RTT估算选项的值设置为0xFFFFFF。
The sender MUST implement and continue to update the CCVal window counter as specified in [RFC4342], Section 8.1, even when the Send RTT Estimate Feature is on.
发送方必须按照[RFC4342]第8.1节的规定实施并继续更新CCVal窗口计数器，即使在发送RTT估算功能开启时也是如此。
When the Send RTT Estimate Feature is enabled, the receiver MUST use the value reported by the RTT Estimate Option in all places that require an RTT (listed at the begin of Section 2). If the receiver encounters an invalid RTT Estimate Option (Section 3.2.1), it MUST reset the connection with Reset Code 5, "Option Error", where the Data 1..3 fields are set to the first 3 bytes of the offending RTT Estimate Option.
当启用发送RTT估算功能时，接收方必须在所有需要RTT的地方（在第2节开头列出）使用RTT估算选项报告的值。如果接收器遇到无效的RTT估算选项（第3.2.1节），则必须使用重置代码5“选项错误”重置连接，其中数据1..3字段设置为违规RTT估算选项的前3个字节。
The receiver SHOULD track the long-term RTT estimate using a moving average, such as the one specified in [RFC5348], Section 4.3. This long-term estimate is referred to as "receiver_RTT" below.
接收机应使用移动平均值跟踪长期RTT估计值，如[RFC5348]第4.3节中规定的移动平均值。该长期估计在下文中称为“接收方”。
When the Send RTT Estimate Feature is disabled, the receiver MUST estimate the RTT as previously specified in [RFC4340], [RFC4342], and [RFC5622].
当禁用发送RTT估计功能时，接收机必须按照[RFC4340]、[RFC4342]和[RFC5622]中先前的规定估计RTT。
This subsection specifies robustness measures for the receiver when the Send RTT Estimate Feature is on.
本小节规定了启用发送RTT估计功能时接收机的稳健性度量。
The 0-valued and 0xFFFFFF-valued RTT Estimate Options are both referred to as "no-number RTT options". RTT Estimate Options with values in the range of 1..0xFFFFFE are analogously called "numeric RTT options".
0值和0xFFFFFF值RTT估算选项均被称为“无编号RTT选项”。值在1..0xFFFFFE范围内的RTT估算选项类似地称为“数字RTT选项”。
Until the first numeric RTT option arrives, the receiver MUST use a value of 0.5 seconds for receiver_RTT (to match the initial 2-second timeout of the TFRC nofeedback timer; see [RFC5348], Section 4.2).
在第一个数字RTT选项到达之前，接收器必须为接收器RTT使用0.5秒的值（以匹配TFRC nofeedback计时器的初始2秒超时；请参阅[RFC5348]，第4.2节）。
If the path RTT is known, e.g., from a previous connection [RFC2140], the receiver MAY reuse the previously known path RTT value to seed its long-term RTT estimate.
如果路径RTT是已知的，例如，从先前的连接[RFC2140]，则接收机可以重用先前已知的路径RTT值来播种其长期RTT估计。
The sender MAY occasionally send no-number RTT options, covering for transient changes and spurious disruptions. During these times, the receiver SHOULD continue to use its long-term receiver_RTT value.
发送方有时可能不发送任何数量的RTT选项，以覆盖瞬时更改和虚假中断。在此期间，接收器应继续使用其长期接收器RTT值。
To avoid under-estimating the RTT in the absence of numeric options, the receiver MUST back off receiver_RTT in the following manner: if the sender supplies no-number RTT options for longer than receiver_RTT units of time, the receiver sets
为了避免在没有数字选项的情况下低估RTT，接收方必须以以下方式回退接收方RTT：如果发送方提供的RTT选项数量超过接收方RTT时间单位，则接收方设置
receiver_RTT = MIN(2 * receiver_RTT, t_mbi)
receiver_RTT = MIN(2 * receiver_RTT, t_mbi)
where t_mbi = 64 seconds is the maximum back-off interval ([RFC5348], Appendix A). For the next round of no-number RTT options, the updated value of receiver_RTT applies.
其中t_mbi=64秒是最大退避间隔（[RFC5348]，附录A）。对于下一轮无编号RTT选项，将应用receiver_RTT的更新值。
This back-off mechanism ensures that short-term disruptions do not have a lasting impact, whereas long-term problems will result in asymptotically high receiver_RTT values.
这种退避机制确保短期中断不会产生持久影响，而长期问题将导致渐进的高接收RTT值。
To bail out from a hanging session, the receiver MAY close the connection when receiver_RTT has reached the value MAX_RTT.
为了从挂起会话中退出，当接收器\u RTT达到值MAX\u RTT时，接收器可以关闭连接。
Security considerations for CCID-3 have been discussed in Section 11 of [RFC4342]; for CCID-4, these have been discussed in Section 13 of [RFC5622], referring back to the same section of [RFC4342].
[RFC4342]第11节讨论了CCID-3的安全注意事项；对于CCID-4，这些已在[RFC5622]的第13节中讨论过，参考[RFC4342]的同一节。
This document introduces an extension to communicate the current RTT estimate of the sender to the receiver of a TFRC communication.
本文档介绍了一个扩展，用于将发送方的当前RTT估计值传递给TFRC通信的接收方。
By altering the value of the RTT Estimate Option, it is possible to interfere with the behaviour of a flow using TFRC. In particular, since accuracy of the RTT estimate directly influences the accuracy of the measured sending rate X_recv, it would be possible to obtain either higher or lower sending rates than are warranted by the current network conditions.
通过改变RTT估算选项的值，可以使用TFRC干扰流的行为。特别是，由于RTT估计的准确性直接影响测量的发送速率X_recv的准确性，因此有可能获得比当前网络条件所保证的更高或更低的发送速率。
This is only possible if an attacker is on the same path as the DCCP sender and receiver, and is able to guess valid sequence numbers. Therefore, the considerations in Section 18 of [RFC4340] apply.
只有当攻击者与DCCP发送方和接收方位于同一路径上，并且能够猜出有效的序列号时，才可能发生这种情况。因此，[RFC4340]第18节中的考虑因素适用。
This document requests identical allocation in the dccp-ccid3- parameters and the dccp-ccid4-parameters registries.
本文件要求在dccp-ccid3-参数和dccp-ccid4-参数注册表中进行相同的分配。
This document defines a single CCID-specific option (128) for communicating RTT estimates from the HC-sender to the HC-receiver. Following [RFC4340], Section 10.3, this requires an option number for the RTT Estimate Option in the range 128..191.
本文件定义了一个CCID特定选项（128），用于将RTT估计值从HC发送方传送到HC接收方。根据[RFC4340]第10.3节，这要求RTT估算选项的选项编号在128..191范围内。
This document defines a single CCID-specific feature number (128) for the Send RTT Estimate feature, which is located at the HC-sender. Following [RFC4340], Section 10.3, a feature number in the range 128..191 is required.
本文档为发送RTT估计功能定义了一个CCID特定功能编号（128），该功能位于HC发送方。根据[RFC4340]第10.3节，需要128..191范围内的特征编号。
[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月。
[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月。
[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月。
[RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, August 2009.
[RFC5622]Floyd，S.和E.Kohler，“数据报拥塞控制协议（DCCP）拥塞ID 4的配置文件：小数据包的TCP友好速率控制（TFRC-SP）”，RFC 5622，2009年8月。
[Err610] RFC Errata, Errata ID 610, RFC 4342, <http://www.rfc-editor.org>.
[Err610]RFC勘误表，勘误表ID 610，RFC 4342<http://www.rfc-editor.org>.
[Err611] RFC Errata, Errata ID 611, RFC 4342, <http://www.rfc-editor.org>.
[Err611]RFC勘误表，勘误表ID 611，RFC 4342<http://www.rfc-editor.org>.
[MR97] Mogul, J. and K. Ramakrishnan, "Eliminating Receive Livelock in an Interrupt-Driven Kernel", ACM Transactions on Computer Systems (TOCS), 15(3):217-252, August 1997.
[MR97]Mogul，J.和K.Ramakrishnan，“在中断驱动内核中消除接收活锁”，计算机系统上的ACM事务（TOCS），15（3）：217-252，1997年8月。
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[RFC2140]Touch，J.，“TCP控制块相互依赖”，RFC 2140，1997年4月。
Authors' Addresses
作者地址
Gerrit Renker University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland
苏格兰阿伯丁大学工程学院弗雷泽贵族大厦阿伯丁
EMail: gerrit@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk
EMail: gerrit@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk
Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland
GoRead FelHurt阿伯丁大学工程学院弗雷泽贵族大厦阿伯丁Ab24 3UE苏格兰
EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk
EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk