Network Working Group M. Handley
Request for Comments: 3448 S. Floyd
Category: Standards Track ICIR
J. Padhye
Microsoft
J. Widmer
University of Mannheim
January 2003
Network Working Group M. Handley
Request for Comments: 3448 S. Floyd
Category: Standards Track ICIR
J. Padhye
Microsoft
J. Widmer
University of Mannheim
January 2003
TCP Friendly Rate Control (TFRC): Protocol Specification
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance.
本文档规定了TCP友好速率控制（TFRC）。TFRC是一种用于在尽力而为的Internet环境中运行的单播流的拥塞控制机制。当与TCP流竞争带宽时，它是合理的，但与TCP相比，吞吐量随时间的变化要小得多，这使得它更适合于相对平滑的发送速率非常重要的应用程序，如电话或流媒体。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Mechanism. . . . . . . . . . . . . . . . . . . 3
3.1. TCP Throughput Equation. . . . . . . . . . . . . . 4
3.2. Packet Contents. . . . . . . . . . . . . . . . . . 6
3.2.1. Data Packets. . . . . . . . . . . . . . . . 6
3.2.2. Feedback Packets. . . . . . . . . . . . . . 7
4. Data Sender Protocol. . . . . . . . . . . . . . . . . . 7
4.1. Measuring the Packet Size. . . . . . . . . . . . . 8
4.2. Sender Initialization. . . . . . . . . . . . . . . 8
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Mechanism. . . . . . . . . . . . . . . . . . . 3
3.1. TCP Throughput Equation. . . . . . . . . . . . . . 4
3.2. Packet Contents. . . . . . . . . . . . . . . . . . 6
3.2.1. Data Packets. . . . . . . . . . . . . . . . 6
3.2.2. Feedback Packets. . . . . . . . . . . . . . 7
4. Data Sender Protocol. . . . . . . . . . . . . . . . . . 7
4.1. Measuring the Packet Size. . . . . . . . . . . . . 8
4.2. Sender Initialization. . . . . . . . . . . . . . . 8
4.3. Sender behavior when a feedback packet is
received. . . . . . . . . . . . . .. . . . . . . . 8
4.4. Expiration of nofeedback timer . . . . . . . . . . 9
4.5. Preventing Oscillations. . . . . . . . . . . . . . 10
4.6. Scheduling of Packet Transmissions . . . . . . . . 11
5. Calculation of the Loss Event Rate (p). . . . . . . . . 12
5.1. Detection of Lost or Marked Packets. . . . . . . . 12
5.2. Translation from Loss History to Loss Events . . . 13
5.3. Inter-loss Event Interval. . . . . . . . . . . . . 14
5.4. Average Loss Interval. . . . . . . . . . . . . . . 14
5.5. History Discounting. . . . . . . . . . . . . . . . 15
6. Data Receiver Protocol. . . . . . . . . . . . . . . . . 17
6.1. Receiver behavior when a data packet is
received . . . . . . . . . . . . . . . . . . . . . 18
6.2. Expiration of feedback timer . . . . . . . . . . . 18
6.3. Receiver initialization. . . . . . . . . . . . . . 19
6.3.1. Initializing the Loss History after the
First Loss Event . . . . . . . . . . . . . 19
7. Sender-based Variants . . . . . . . . . . . . . . . . . 20
8. Implementation Issues . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . 22
12. Non-Normative References. . . . . . . . . . . . . . . . 22
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . 23
14. Full Copyright Statement. . . . . . . . . . . . . . . . 24
4.3. Sender behavior when a feedback packet is
received. . . . . . . . . . . . . .. . . . . . . . 8
4.4. Expiration of nofeedback timer . . . . . . . . . . 9
4.5. Preventing Oscillations. . . . . . . . . . . . . . 10
4.6. Scheduling of Packet Transmissions . . . . . . . . 11
5. Calculation of the Loss Event Rate (p). . . . . . . . . 12
5.1. Detection of Lost or Marked Packets. . . . . . . . 12
5.2. Translation from Loss History to Loss Events . . . 13
5.3. Inter-loss Event Interval. . . . . . . . . . . . . 14
5.4. Average Loss Interval. . . . . . . . . . . . . . . 14
5.5. History Discounting. . . . . . . . . . . . . . . . 15
6. Data Receiver Protocol. . . . . . . . . . . . . . . . . 17
6.1. Receiver behavior when a data packet is
received . . . . . . . . . . . . . . . . . . . . . 18
6.2. Expiration of feedback timer . . . . . . . . . . . 18
6.3. Receiver initialization. . . . . . . . . . . . . . 19
6.3.1. Initializing the Loss History after the
First Loss Event . . . . . . . . . . . . . 19
7. Sender-based Variants . . . . . . . . . . . . . . . . . 20
8. Implementation Issues . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . 22
12. Non-Normative References. . . . . . . . . . . . . . . . 22
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . 23
14. Full Copyright Statement. . . . . . . . . . . . . . . . 24
This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism designed for unicast flows operating in an Internet environment and competing with TCP traffic [2]. Instead of specifying a complete protocol, this document simply specifies a congestion control mechanism that could be used in a transport protocol such as RTP [7], in an application incorporating end-to-end congestion control at the application level, or in the context of endpoint congestion management [1]. This document does not discuss packet formats or reliability. Implementation-related issues are discussed only briefly, in Section 8.
本文档规定了TCP友好速率控制（TFRC）。TFRC是一种拥塞控制机制，设计用于在Internet环境中运行的单播流，并与TCP流量竞争[2]。本文档没有指定一个完整的协议，而是简单地指定了一种拥塞控制机制，该机制可用于传输协议（如RTP[7]）、应用程序级包含端到端拥塞控制的应用程序或端点拥塞管理上下文中[1]。本文件不讨论数据包格式或可靠性。第8节仅简要讨论了与实施有关的问题。
TFRC is designed to be reasonably fair when competing for bandwidth with TCP flows, where a flow is "reasonably fair" if its sending rate is generally within a factor of two of the sending rate of a TCP flow under the same conditions. However, TFRC has a much lower variation of throughput over time compared with TCP, which makes it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance.
TFRC被设计为在与TCP流竞争带宽时合理公平，如果在相同条件下，一个流的发送速率通常在TCP流发送速率的两倍以内，则该流是“合理公平”的。然而，与TCP相比，TFRC的吞吐量随时间的变化要小得多，这使得它更适合于相对平滑的发送速率非常重要的应用程序，如电话或流媒体。
The penalty of having smoother throughput than TCP while competing fairly for bandwidth is that TFRC responds slower than TCP to changes in available bandwidth. Thus TFRC should only be used when the application has a requirement for smooth throughput, in particular, avoiding TCP's halving of the sending rate in response to a single packet drop. For applications that simply need to transfer as much data as possible in as short a time as possible we recommend using TCP, or if reliability is not required, using an Additive-Increase, Multiplicative-Decrease (AIMD) congestion control scheme with similar parameters to those used by TCP.
在公平竞争带宽的同时拥有比TCP更平滑的吞吐量的代价是TFRC对可用带宽变化的响应比TCP慢。因此，只有当应用程序需要平滑吞吐量时，才应该使用TFRC，特别是避免TCP响应单个数据包丢失而将发送速率减半。对于只需要在尽可能短的时间内传输尽可能多的数据的应用程序，我们建议使用TCP，或者如果不需要可靠性，则使用与TCP使用的参数类似的加性增加、乘性减少（AIMD）拥塞控制方案。
TFRC is designed for applications that use a fixed packet size, and vary their sending rate in packets per second in response to congestion. Some audio applications require a fixed interval of time between packets and vary their packet size instead of their packet rate in response to congestion. The congestion control mechanism in this document cannot be used by those applications; TFRC-PS (for TFRC-PacketSize) is a variant of TFRC for applications that have a fixed sending rate but vary their packet size in response to congestion. TFRC-PS will be specified in a later document.
TFRC设计用于使用固定数据包大小的应用程序，并根据拥塞情况以每秒数据包的形式改变其发送速率。一些音频应用程序要求数据包之间有固定的时间间隔，并根据拥塞情况改变数据包大小而不是数据包速率。这些应用程序不能使用本文档中的拥塞控制机制；TFRC-PS（用于TFRC PacketSize）是TFRC的一个变体，适用于具有固定发送速率但根据拥塞情况改变数据包大小的应用程序。TFRC-PS将在以后的文档中指定。
TFRC is a receiver-based mechanism, with the calculation of the congestion control information (i.e., the loss event rate) in the data receiver rather in the data sender. This is well-suited to an application where the sender is a large server handling many concurrent connections, and the receiver has more memory and CPU cycles available for computation. In addition, a receiver-based mechanism is more suitable as a building block for multicast congestion control.
TFRC是一种基于接收方的机制，用于计算数据接收方而非数据发送方的拥塞控制信息（即丢失事件率）。这非常适合于发送方是处理许多并发连接的大型服务器，而接收方有更多的内存和CPU周期可用于计算的应用程序。此外，基于接收器的机制更适合作为多播拥塞控制的构建块。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and indicate requirement levels for compliant TFRC implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119中的描述进行解释，并表示符合TFRC实施的要求级别。
For its congestion control mechanism, TFRC directly uses a throughput equation for the allowed sending rate as a function of the loss event rate and round-trip time. In order to compete fairly with TCP, TFRC uses the TCP throughput equation, which roughly describes TCP's sending rate as a function of the loss event rate, round-trip time, and packet size. We define a loss event as one or more lost or marked packets from a window of data, where a marked packet refers to a congestion indication from Explicit Congestion Notification (ECN) [6].
对于其拥塞控制机制，TFRC直接使用允许发送速率的吞吐量方程作为丢失事件速率和往返时间的函数。为了与TCP公平竞争，TFRC使用TCP吞吐量方程，该方程将TCP的发送速率粗略地描述为丢失事件率、往返时间和数据包大小的函数。我们将丢失事件定义为来自数据窗口的一个或多个丢失或标记的数据包，其中标记的数据包指来自显式拥塞通知（ECN）的拥塞指示[6]。
Generally speaking, TFRC's congestion control mechanism works as follows:
总的来说，TFRC的拥塞控制机制的工作原理如下：
o The receiver measures the loss event rate and feeds this information back to the sender.
o 接收方测量损失事件率，并将此信息反馈给发送方。
o The sender also uses these feedback messages to measure the round-trip time (RTT).
o 发送方还使用这些反馈消息来测量往返时间（RTT）。
o The loss event rate and RTT are then fed into TFRC's throughput equation, giving the acceptable transmit rate.
o 然后将丢失事件速率和RTT输入TFRC的吞吐量方程，给出可接受的传输速率。
o The sender then adjusts its transmit rate to match the calculated rate.
o 然后，发送方调整其传输速率以匹配计算的速率。
The dynamics of TFRC are sensitive to how the measurements are performed and applied. We recommend specific mechanisms below to perform and apply these measurements. Other mechanisms are possible, but it is important to understand how the interactions between mechanisms affect the dynamics of TFRC.
TFRC的动态特性对如何执行和应用测量非常敏感。我们建议使用以下特定机制来执行和应用这些测量。其他机制是可能的，但了解机制之间的相互作用如何影响TFRC的动力学很重要。
Any realistic equation giving TCP throughput as a function of loss event rate and RTT should be suitable for use in TFRC. However, we note that the TCP throughput equation used must reflect TCP's retransmit timeout behavior, as this dominates TCP throughput at higher loss rates. We also note that the assumptions implicit in the throughput equation about the loss event rate parameter have to be a reasonable match to how the loss rate or loss event rate is actually measured. While this match is not perfect for the throughput equation and loss rate measurement mechanisms given below, in practice the assumptions turn out to be close enough.
任何将TCP吞吐量作为丢失事件率和RTT函数的现实方程都应适用于TFRC。然而，我们注意到，所使用的TCP吞吐量方程必须反映TCP的重传超时行为，因为这在较高的丢失率下控制着TCP吞吐量。我们还注意到，吞吐量方程中关于损失事件率参数的隐含假设必须与实际测量损失率或损失事件率的方式合理匹配。虽然这种匹配对于下面给出的吞吐量方程和损失率测量机制并不完美，但在实践中，这些假设证明足够接近。
The throughput equation we currently recommend for TFRC is a slightly simplified version of the throughput equation for Reno TCP from [4]. Ideally we'd prefer a throughput equation based on SACK TCP, but no one has yet derived the throughput equation for SACK TCP, and from both simulations and experiments, the differences between the two equations are relatively minor.
我们目前推荐的TFRC吞吐量方程是[4]中雷诺TCP吞吐量方程的稍微简化版本。理想情况下，我们更喜欢基于SACK TCP的吞吐量方程，但还没有人推导出SACK TCP的吞吐量方程，从模拟和实验来看，这两个方程之间的差异相对较小。
The throughput equation is:
吞吐量方程为：
s
X = ----------------------------------------------------------
R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2)))
s
X = ----------------------------------------------------------
R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2)))
Where:
哪里：
X is the transmit rate in bytes/second.
X是以字节/秒为单位的传输速率。
s is the packet size in bytes.
s是以字节为单位的数据包大小。
R is the round trip time in seconds.
R是以秒为单位的往返时间。
p is the loss event rate, between 0 and 1.0, of the number of loss events as a fraction of the number of packets transmitted.
p是丢失事件率，介于0和1.0之间，丢失事件数占传输的数据包数的一小部分。
t_RTO is the TCP retransmission timeout value in seconds.
t_RTO是TCP重新传输超时值，以秒为单位。
b is the number of packets acknowledged by a single TCP acknowledgement.
b是单个TCP确认确认的数据包数。
We further simplify this by setting t_RTO = 4*R. A more accurate calculation of t_RTO is possible, but experiments with the current setting have resulted in reasonable fairness with existing TCP implementations [9]. Another possibility would be to set t_RTO = max(4R, one second), to match the recommended minimum of one second on the RTO [5].
我们通过设置t_RTO=4*R进一步简化了这一点。可以更精确地计算t_RTO，但使用当前设置的实验已经在现有TCP实现中实现了合理的公平性[9]。另一种可能是设置t_RTO=max（4R，1秒），以匹配RTO上建议的最小1秒[5]。
Many current TCP connections use delayed acknowledgements, sending an acknowledgement for every two data packets received, and thus have a sending rate modeled by b = 2. However, TCP is also allowed to send an acknowledgement for every data packet, and this would be modeled by b = 1. Because many TCP implementations do not use delayed acknowledgements, we recommend b = 1.
许多当前TCP连接使用延迟确认，每接收到两个数据包就发送一个确认，因此发送速率由b=2建模。然而，TCP也允许为每个数据包发送确认，这将由b=1建模。因为许多TCP实现不使用延迟确认，所以我们建议b=1。
In future, different TCP equations may be substituted for this equation. The requirement is that the throughput equation be a reasonable approximation of the sending rate of TCP for conformant TCP congestion control.
将来，可以用不同的TCP方程代替该方程。要求吞吐量方程是一致TCP拥塞控制的TCP发送速率的合理近似值。
The parameters s (packet size), p (loss event rate) and R (RTT) need to be measured or calculated by a TFRC implementation. The measurement of s is specified in Section 4.1, measurement of R is specified in Section 4.3, and measurement of p is specified in Section 5. In the rest of this document all data rates are measured in bytes/second.
TFRC实现需要测量或计算参数s（数据包大小）、p（丢失事件率）和R（RTT）。第4.1节规定了s的测量，第4.3节规定了R的测量，第5节规定了p的测量。在本文档的其余部分中，所有数据速率均以字节/秒为单位。
Before specifying the sender and receiver functionality, we describe the contents of the data packets sent by the sender and feedback packets sent by the receiver. As TFRC will be used along with a transport protocol, we do not specify packet formats, as these depend on the details of the transport protocol used.
在指定发送方和接收方功能之前，我们先描述发送方发送的数据包和接收方发送的反馈包的内容。由于TFRC将与传输协议一起使用，因此我们不指定数据包格式，因为这些格式取决于所用传输协议的详细信息。
Each data packet sent by the data sender contains the following information:
数据发送方发送的每个数据包包含以下信息：
o A sequence number. This number is incremented by one for each data packet transmitted. The field must be sufficiently large that it does not wrap causing two different packets with the same sequence number to be in the receiver's recent packet history at the same time.
o 序列号。对于传输的每个数据包，该数字增加1。该字段必须足够大，以使其不会包装，从而导致具有相同序列号的两个不同数据包同时出现在接收器的最近数据包历史记录中。
o A timestamp indicating when the packet is sent. We denote by ts_i the timestamp of the packet with sequence number i. The resolution of the timestamp should typically be measured in milliseconds. This timestamp is used by the receiver to determine which losses belong to the same loss event. The timestamp is also echoed by the receiver to enable the sender to estimate the round-trip time, for senders that do not save timestamps of transmitted data packets. We note that as an alternative to a timestamp incremented in milliseconds, a "timestamp" that increments every quarter of a round-trip time would be sufficient for determining when losses belong to the same loss event, in the context of a protocol where this is understood by both sender and receiver, and where the sender saves the timestamps of transmitted data packets.
o 指示数据包何时发送的时间戳。我们用ts_i表示序列号为i的数据包的时间戳。时间戳的分辨率通常应以毫秒为单位。接收器使用该时间戳来确定哪些损失属于同一损失事件。时间戳还由接收机回响，以使发送方能够估计不保存所发送数据分组的时间戳的发送方的往返时间。我们注意到，作为以毫秒为单位递增的时间戳的替代，在发送方和接收方都理解的协议上下文中，每四分之一往返时间递增的“时间戳”足以确定何时丢失属于同一丢失事件，以及发送方保存所发送数据分组的时间戳的位置。
o The sender's current estimate of the round trip time. The estimate reported in packet i is denoted by R_i. The round-trip time estimate is used by the receiver, along with the timestamp, to determine when multiple losses belong to the same loss event. If the sender sends a coarse-grained "timestamp" that increments every quarter of a round-trip time, as discussed above, then the sender does not need to send its current estimate of the round trip time.
o 发送方对往返时间的当前估计。包i中报告的估计用R_i表示。接收器使用往返时间估计以及时间戳来确定多个损失何时属于同一损失事件。如上文所述，如果发送方发送每四分之一往返时间递增的粗粒度“时间戳”，则发送方不需要发送其当前的往返时间估计。
Each feedback packet sent by the data receiver contains the following information:
数据接收器发送的每个反馈数据包包含以下信息：
o The timestamp of the last data packet received. We denote this by t_recvdata. If the last packet received at the receiver has sequence number i, then t_recvdata = ts_i. This timestamp is used by the sender to estimate the round-trip time, and is only needed if the sender does not save timestamps of transmitted data packets.
o 接收到的最后一个数据包的时间戳。我们用t_recvdata表示这一点。如果在接收器接收到的最后一个数据包具有序列号i，则t_recvdata=ts_i。发送方使用该时间戳来估计往返时间，并且仅当发送方不保存传输数据包的时间戳时才需要该时间戳。
o The amount of time elapsed between the receipt of the last data packet at the receiver, and the generation of this feedback report. We denote this by t_delay.
o 从接收器接收最后一个数据包到生成此反馈报告之间经过的时间量。我们用t_延迟来表示这一点。
o The rate at which the receiver estimates that data was received since the last feedback report was sent. We denote this by X_recv.
o 自上次发送反馈报告以来，接收器估计接收到数据的速率。我们用X_recv表示这一点。
o The receiver's current estimate of the loss event rate, p.
o 接收方对损失事件率的当前估计值，p。
The data sender sends a stream of data packets to the data receiver at a controlled rate. When a feedback packet is received from the data receiver, the data sender changes its sending rate, based on the information contained in the feedback report. If the sender does not receive a feedback report for two round trip times, it cuts its sending rate in half. This is achieved by means of a timer called the nofeedback timer.
数据发送方以受控速率向数据接收方发送数据分组流。当从数据接收器接收到反馈分组时，数据发送者基于反馈报告中包含的信息改变其发送速率。如果发送方在两次往返时间内没有收到反馈报告，则会将其发送速率减半。这是通过称为无反馈定时器的定时器实现的。
We specify the sender-side protocol in the following steps:
我们在以下步骤中指定发送方协议：
o Measurement of the mean packet size being sent.
o 正在发送的平均数据包大小的测量。
o The sender behavior when a feedback packet is received.
o 收到反馈数据包时发送方的行为。
o The sender behavior when the nofeedback timer expires.
o nofeedback计时器过期时的发件人行为。
o Oscillation prevention (optional)
o 防振荡（可选）
o Scheduling of transmission on non-realtime operating systems.
o 非实时操作系统上的传输调度。
The parameter s (packet size) is normally known to an application. This may not be so in two cases:
应用程序通常知道参数s（数据包大小）。在两种情况下可能并非如此：
o The packet size naturally varies depending on the data. In this case, although the packet size varies, that variation is not coupled to the transmit rate. It should normally be safe to use an estimate of the mean packet size for s.
o 数据包大小自然随数据而变化。在这种情况下，尽管分组大小变化，但该变化不与传输速率耦合。使用s的平均数据包大小的估计值通常是安全的。
o The application needs to change the packet size rather than the number of packets per second to perform congestion control. This would normally be the case with packet audio applications where a fixed interval of time needs to be represented by each packet. Such applications need to have a completely different way of measuring parameters.
o 应用程序需要更改数据包大小，而不是每秒的数据包数，以执行拥塞控制。这通常是分组音频应用的情况，其中每个分组需要表示固定的时间间隔。这种应用需要有一种完全不同的测量参数的方法。
The second class of applications are discussed separately in a separate document on TFRC-PS. For the remainder of this section we assume the sender can estimate the packet size, and that congestion control is performed by adjusting the number of packets sent per second.
第二类应用程序将在TFRC-PS的单独文档中单独讨论。对于本节的其余部分，我们假设发送方可以估计数据包大小，并且通过调整每秒发送的数据包数量来执行拥塞控制。
To initialize the sender, the value of X is set to 1 packet/second and the nofeedback timer is set to expire after 2 seconds. The initial values for R (RTT) and t_RTO are undefined until they are set as described below. The initial value of tld, for the Time Last Doubled during slow-start, is set to -1.
要初始化发送方，将X的值设置为1个数据包/秒，并将nofeedback计时器设置为2秒后过期。R（RTT）和t_RTO的初始值在如下所述进行设置之前未定义。tld的初始值（慢启动期间最后加倍的时间）设置为-1。
The sender knows its current sending rate, X, and maintains an estimate of the current round trip time, R, and an estimate of the timeout interval, t_RTO.
发送方知道其当前发送速率X，并维护当前往返时间R的估计值和超时间隔t_RTO的估计值。
When a feedback packet is received by the sender at time t_now, the following actions should be performed:
当发送方在此时t_接收到反馈数据包时，应执行以下操作：
1) Calculate a new round trip sample.
R_sample = (t_now - t_recvdata) - t_delay.
1) Calculate a new round trip sample.
R_sample = (t_now - t_recvdata) - t_delay.
2) Update the round trip time estimate:
2) 更新往返时间估算：
If no feedback has been received before
R = R_sample;
Else
R = q*R + (1-q)*R_sample;
If no feedback has been received before
R = R_sample;
Else
R = q*R + (1-q)*R_sample;
TFRC is not sensitive to the precise value for the filter constant q, but we recommend a default value of 0.9.
TFRC对过滤器常数q的精确值不敏感，但我们建议默认值为0.9。
3) Update the timeout interval:
3) 更新超时间隔：
t_RTO = 4*R.
t_RTO=4*R。
4) Update the sending rate as follows:
4) 更新发送速率，如下所示：
If (p > 0)
Calculate X_calc using the TCP throughput equation.
X = max(min(X_calc, 2*X_recv), s/t_mbi);
Else
If (t_now - tld >= R)
X = max(min(2*X, 2*X_recv), s/R);
tld = t_now;
If (p > 0)
Calculate X_calc using the TCP throughput equation.
X = max(min(X_calc, 2*X_recv), s/t_mbi);
Else
If (t_now - tld >= R)
X = max(min(2*X, 2*X_recv), s/R);
tld = t_now;
Note that if p == 0, then the sender is in slow-start phase, where it approximately doubles the sending rate each round-trip time until a loss occurs. The s/R term gives a minimum sending rate during slow-start of one packet per RTT. The parameter t_mbi is 64 seconds, and represents the maximum inter-packet backoff interval in the persistent absence of feedback. Thus, when p > 0 the sender sends at least one packet every 64 seconds.
请注意，如果p==0，则发送方处于慢启动阶段，在该阶段中，每次往返时间的发送速率约为两倍，直到发生丢失。s/R项给出了在每个RTT慢启动一个数据包期间的最小发送速率。参数t_mbi为64秒，表示持续无反馈情况下的最大数据包间退避间隔。因此，当p>0时，发送方每64秒至少发送一个数据包。
5) Reset the nofeedback timer to expire after max(4*R, 2*s/X) seconds.
5) 重置nofeedback计时器，使其在最大（4*R，2*s/X）秒后过期。
If the nofeedback timer expires, the sender should perform the following actions:
如果nofeedback计时器过期，发送方应执行以下操作：
1) Cut the sending rate in half. If the sender has received feedback from the receiver, this is done by modifying the sender's cached copy of X_recv (the receive rate). Because the sending rate is limited to at most twice X_recv, modifying X_recv limits the current sending rate, but allows the sender to slow-start, doubling its sending rate each RTT, if feedback messages resume reporting no losses.
1) 将发送速率减半。如果发送方已收到来自接收方的反馈，则可通过修改发送方的X_recv缓存副本（接收速率）来完成此操作。由于发送速率最多限制为X_recv的两倍，因此修改X_recv会限制当前的发送速率，但如果反馈消息继续报告没有丢失，则允许发送方减慢启动速度，使其发送速率在每个RTT时加倍。
If (X_calc > 2*X_recv)
X_recv = max(X_recv/2, s/(2*t_mbi));
Else
X_recv = X_calc/4;
If (X_calc > 2*X_recv)
X_recv = max(X_recv/2, s/(2*t_mbi));
Else
X_recv = X_calc/4;
The term s/(2*t_mbi) limits the backoff to one packet every 64 seconds in the case of persistent absence of feedback.
在持续缺少反馈的情况下，术语s/（2*t_mbi）将回退限制为每64秒一个数据包。
2) The value of X must then be recalculated as described under point (4) above.
2) 然后必须按照上文第（4）点所述重新计算X值。
If the nofeedback timer expires when the sender does not yet have an RTT sample, and has not yet received any feedback from the receiver, then step (1) can be skipped, and the sending rate cut in half directly:
如果当发送方尚未收到RTT样本且尚未收到来自接收方的任何反馈时，nofeedback定时器过期，则可跳过步骤（1），并直接将发送速率减半：
X = max(X/2, s/t_mbi)
X = max(X/2, s/t_mbi)
3) Restart the nofeedback timer to expire after max(4*R, 2*s/X) seconds.
3) 重新启动nofeedback计时器，使其在最长（4*R，2*s/X）秒后过期。
Note that when the sender stops sending, the receiver will stop sending feedback. This will cause the nofeedback timer to start to expire and decrease X_recv. If the sender subsequently starts to send again, X_recv will limit the transmit rate, and a normal slowstart phase will occur until the transmit rate reaches X_calc.
请注意，当发送方停止发送时，接收方将停止发送反馈。这将导致nofeedback计时器开始过期并降低X_recv。如果发送方随后再次开始发送，X_recv将限制传输速率，并且将出现正常的慢启动阶段，直到传输速率达到X_calc。
If the sender has been idle since this nofeedback timer was set and X_recv is less than four packets per round-trip time, then X_recv should not be halved in response to the timer expiration. This ensures that the allowed sending rate is never reduced to less than two packets per round-trip time as a result of an idle period.
如果自设置此nofeedback计时器后，发送方一直处于空闲状态，且X_recv每往返时间少于四个数据包，则X_recv不应因计时器过期而减半。这确保了允许的发送速率不会因为空闲时间而减少到每个往返时间少于两个数据包。
To prevent oscillatory behavior in environments with a low degree of statistical multiplexing it is useful to modify sender's transmit rate to provide congestion avoidance behavior by reducing the transmit rate as the queuing delay (and hence RTT) increases. To do this the sender maintains an estimate of the long-term RTT and modifies its sending rate depending on how the most recent sample of the RTT differs from this value. The long-term sample is R_sqmean, and is set as follows:
为了防止在统计复用程度较低的环境中出现振荡行为，修改发送方的传输速率以提供拥塞避免行为非常有用，方法是随着排队延迟（因此RTT）的增加而降低传输速率。为此，发送方维护长期RTT的估计值，并根据RTT的最新样本与该值的不同程度修改其发送速率。长期样本为R_sqmean，设置如下：
If no feedback has been received before
R_sqmean = sqrt(R_sample);
Else
R_sqmean = q2*R_sqmean + (1-q2)*sqrt(R_sample);
If no feedback has been received before
R_sqmean = sqrt(R_sample);
Else
R_sqmean = q2*R_sqmean + (1-q2)*sqrt(R_sample);
Thus R_sqmean gives the exponentially weighted moving average of the square root of the RTT samples. The constant q2 should be set similarly to q, and we recommend a value of 0.9 as the default.
因此，R_sqmean给出了RTT样本平方根的指数加权移动平均值。常量q2的设置应与q类似，我们建议默认值为0.9。
The sender obtains the base transmit rate, X, from the throughput function. It then calculates a modified instantaneous transmit rate X_inst, as follows:
发送方从吞吐量函数获得基本传输速率X。然后计算修改后的瞬时传输速率X_inst，如下所示：
X_inst = X * R_sqmean / sqrt(R_sample);
X_inst = X * R_sqmean / sqrt(R_sample);
When sqrt(R_sample) is greater than R_sqmean then the queue is typically increasing and so the transmit rate needs to be decreased for stable operation.
当sqrt（R_sample）大于R_sqmean时，队列通常会增加，因此需要降低传输速率以稳定运行。
Note: This modification is not always strictly required, especially if the degree of statistical multiplexing in the network is high. However, we recommend that it is done because it does make TFRC behave better in environments with a low level of statistical multiplexing. If it is not done, we recommend using a very low value of q, such that q is close to or exactly zero.
注意：这种修改并不总是严格要求的，特别是当网络中的统计复用度很高时。但是，我们建议这样做，因为它确实可以使TFRC在统计复用级别较低的环境中表现得更好。如果不这样做，我们建议使用非常低的q值，使q接近或正好为零。
As TFRC is rate-based, and as operating systems typically cannot schedule events precisely, it is necessary to be opportunistic about sending data packets so that the correct average rate is maintained despite the course-grain or irregular scheduling of the operating system. Thus a typical sending loop will calculate the correct inter-packet interval, t_ipi, as follows:
由于TFRC是基于速率的，并且操作系统通常无法精确地调度事件，因此有必要机会主义地发送数据包，以便在操作系统的进程粒度或不规则调度的情况下保持正确的平均速率。因此，典型的发送循环将计算正确的包间间隔t_ipi，如下所示：
t_ipi = s/X_inst;
t_ipi = s/X_inst;
When a sender first starts sending at time t_0, it calculates t_ipi, and calculates a nominal send time t_1 = t_0 + t_ipi for packet 1. When the application becomes idle, it checks the current time, t_now, and then requests re-scheduling after (t_ipi - (t_now - t_0)) seconds. When the application is re-scheduled, it checks the current time, t_now, again. If (t_now > t_1 - delta) then packet 1 is sent.
当发送方第一次在时间t_0开始发送时，它计算t_ipi，并计算数据包1的标称发送时间t_1=t_0+t_ipi。当应用程序空闲时，它检查当前时间t_now，然后在（t_ipi-（t_now-t_0））秒后请求重新调度。当重新安排应用程序时，它会再次检查当前时间t_now。如果（t_now>t_1-delta），则发送数据包1。
Now a new t_ipi may be calculated, and used to calculate a nominal send time t_2 for packet 2: t2 = t_1 + t_ipi. The process then repeats, with each successive packet's send time being calculated from the nominal send time of the previous packet.
现在可以计算新的t_ipi，并用于计算分组2的标称发送时间t_2：t2＝t_1+t_ipi。然后，该过程重复，每个连续分组的发送时间根据前一分组的标称发送时间计算。
In some cases, when the nominal send time, t_i, of the next packet is calculated, it may already be the case that t_now > t_i - delta. In such a case the packet should be sent immediately. Thus if the operating system has coarse timer granularity and the transmit rate
在某些情况下，当计算下一个分组的标称发送时间t_i时，可能已经是t_now>t_i-delta的情况。在这种情况下，应立即发送数据包。因此，如果操作系统具有较粗的计时器粒度和传输速率
is high, then TFRC may send short bursts of several packets separated by intervals of the OS timer granularity.
高，则TFRC可能会发送由操作系统计时器粒度间隔分隔的几个数据包的短突发。
The parameter delta is to allow a degree of flexibility in the send time of a packet. If the operating system has a scheduling timer granularity of t_gran seconds, then delta would typically be set to:
参数delta允许数据包的发送时间具有一定程度的灵活性。如果操作系统的调度计时器粒度为t_gran seconds，则delta通常会设置为：
delta = min(t_ipi/2, t_gran/2);
delta = min(t_ipi/2, t_gran/2);
t_gran is 10ms on many Unix systems. If t_gran is not known, a value of 10ms can be safely assumed.
在许多Unix系统上，t_gran是10ms。如果t_gran未知，则可以安全地假定值为10ms。
Obtaining an accurate and stable measurement of the loss event rate is of primary importance for TFRC. Loss rate measurement is performed at the receiver, based on the detection of lost or marked packets from the sequence numbers of arriving packets. We describe this process before describing the rest of the receiver protocol.
准确、稳定地测量损失事件率对于TFRC至关重要。丢失率测量在接收机处执行，基于从到达的分组的序列号中检测丢失或标记的分组。在描述接收器协议的其余部分之前，我们先描述这个过程。
TFRC assumes that all packets contain a sequence number that is incremented by one for each packet that is sent. For the purposes of this specification, we require that if a lost packet is retransmitted, the retransmission is given a new sequence number that is the latest in the transmission sequence, and not the same sequence number as the packet that was lost. If a transport protocol has the requirement that it must retransmit with the original sequence number, then the transport protocol designer must figure out how to distinguish delayed from retransmitted packets and how to detect lost retransmissions.
TFRC假设所有数据包都包含一个序列号，该序列号对于发送的每个数据包递增一。出于本规范的目的，我们要求，如果重新传输丢失的数据包，则重新传输将获得传输序列中最新的新序列号，而不是与丢失的数据包相同的序列号。如果传输协议要求必须使用原始序列号重新传输，那么传输协议设计者必须弄清楚如何区分延迟数据包和重新传输的数据包，以及如何检测丢失的重新传输。
The receiver maintains a data structure that keeps track of which packets have arrived and which are missing. For the purposes of specification, we assume that the data structure consists of a list of packets that have arrived along with the receiver timestamp when each packet was received. In practice this data structure will normally be stored in a more compact representation, but this is implementation-specific.
接收器维护一个数据结构，跟踪哪些数据包已经到达，哪些丢失。出于规范的目的，我们假设数据结构由在接收每个数据包时随接收器时间戳一起到达的数据包列表组成。实际上，此数据结构通常以更紧凑的表示形式存储，但这是特定于实现的。
The loss of a packet is detected by the arrival of at least three packets with a higher sequence number than the lost packet. The requirement for three subsequent packets is the same as with TCP, and is to make TFRC more robust in the presence of reordering. In contrast to TCP, if a packet arrives late (after 3 subsequent packets arrived) in TFRC, the late packet can fill the hole in TFRC's reception record, and the receiver can recalculate the loss event
通过至少三个序列号高于丢失分组的分组的到达来检测分组的丢失。对三个后续数据包的要求与TCP相同，是为了使TFRC在存在重新排序的情况下更加健壮。与TCP相反，如果一个数据包在TFRC中迟到（在随后的3个数据包到达之后），那么迟到的数据包可以填充TFRC接收记录中的漏洞，并且接收方可以重新计算丢失事件
rate. Future versions of TFRC might make the requirement for three subsequent packets adaptive based on experienced packet reordering, but we do not specify such a mechanism here.
速度TFRC的未来版本可能会根据经验丰富的数据包重新排序，使对三个后续数据包的要求具有自适应性，但我们在此不指定这种机制。
For an ECN-capable connection, a marked packet is detected as a congestion event as soon as it arrives, without having to wait for the arrival of subsequent packets.
对于支持ECN的连接，标记的数据包一到达即被检测为拥塞事件，而不必等待后续数据包的到达。
TFRC requires that the loss fraction be robust to several consecutive packets lost where those packets are part of the same loss event. This is similar to TCP, which (typically) only performs one halving of the congestion window during any single RTT. Thus the receiver needs to map the packet loss history into a loss event record, where a loss event is one or more packets lost in an RTT. To perform this mapping, the receiver needs to know the RTT to use, and this is supplied periodically by the sender, typically as control information piggy-backed onto a data packet. TFRC is not sensitive to how the RTT measurement sent to the receiver is made, but we recommend using the sender's calculated RTT, R, (see Section 4.3) for this purpose.
TFRC要求丢失分数对多个连续丢失的数据包具有鲁棒性，其中这些数据包是同一丢失事件的一部分。这与TCP类似，TCP（通常）在任何单个RTT期间只执行拥塞窗口的一半。因此，接收机需要将分组丢失历史映射到丢失事件记录中，其中丢失事件是在RTT中丢失的一个或多个分组。为了执行这种映射，接收方需要知道要使用的RTT，并且这是由发送方定期提供的，通常是作为控制信息装载到数据包上。TFRC对发送给接收方的RTT测量方式不敏感，但我们建议使用发送方计算的RTT，R（见第4.3节）进行测量。
To determine whether a lost or marked packet should start a new loss event, or be counted as part of an existing loss event, we need to compare the sequence numbers and timestamps of the packets that arrived at the receiver. For a marked packet S_new, its reception time T_new can be noted directly. For a lost packet, we can interpolate to infer the nominal "arrival time". Assume:
为了确定丢失或标记的数据包是否应该启动新的丢失事件，或者作为现有丢失事件的一部分计算，我们需要比较到达接收器的数据包的序列号和时间戳。对于标记的数据包S_new，其接收时间T_new可以直接记录。对于丢失的数据包，我们可以插值来推断名义上的“到达时间”。假设：
S_loss is the sequence number of a lost packet.
S_loss是丢失数据包的序列号。
S_before is the sequence number of the last packet to arrive with sequence number before S_loss.
S_before是最后一个到达的数据包的序列号，序列号在S_丢失之前。
S_after is the sequence number of the first packet to arrive with sequence number after S_loss.
S_after是S_丢失后第一个到达的数据包的序列号。
T_before is the reception time of S_before.
T_before是S_before的接收时间。
T_after is the reception time of S_after.
T_after是S_after的接收时间。
Note that T_before can either be before or after T_after due to reordering.
请注意，由于重新排序，T_before可以在T_after之前或之后。
For a lost packet S_loss, we can interpolate its nominal "arrival time" at the receiver from the arrival times of S_before and S_after. Thus:
对于丢失的数据包S_丢失，我们可以从S_之前和S_之后的到达时间内插其在接收器的标称“到达时间”。因此：
T_loss = T_before + ( (T_after - T_before)
* (S_loss - S_before)/(S_after - S_before) );
T_loss = T_before + ( (T_after - T_before)
* (S_loss - S_before)/(S_after - S_before) );
Note that if the sequence space wrapped between S_before and S_after,
then the sequence numbers must be modified to take this into account
before performing this calculation. If the largest possible sequence
number is S_max, and S_before > S_after, then modifying each sequence
number S by S' = (S + (S_max + 1)/2) mod (S_max + 1) would normally
be sufficient.
Note that if the sequence space wrapped between S_before and S_after,
then the sequence numbers must be modified to take this into account
before performing this calculation. If the largest possible sequence
number is S_max, and S_before > S_after, then modifying each sequence
number S by S' = (S + (S_max + 1)/2) mod (S_max + 1) would normally
be sufficient.
If the lost packet S_old was determined to have started the previous loss event, and we have just determined that S_new has been lost, then we interpolate the nominal arrival times of S_old and S_new, called T_old and T_new respectively.
如果确定丢失的数据包S_old已经开始了前一个丢失事件，并且我们刚刚确定S_new已经丢失，那么我们插值S_old和S_new的标称到达时间，分别称为T_old和T_new。
If T_old + R >= T_new, then S_new is part of the existing loss event. Otherwise S_new is the first packet in a new loss event.
如果T_old+R>=T_new，则S_new是现有损失事件的一部分。否则，S_new是新丢失事件中的第一个数据包。
If a loss interval, A, is determined to have started with packet sequence number S_A and the next loss interval, B, started with packet sequence number S_B, then the number of packets in loss interval A is given by (S_B - S_A).
如果确定丢失间隔a以分组序列号S_a开始，而下一个丢失间隔B以分组序列号S_B开始，则丢失间隔a中的分组数由（S_B-S_a）给出。
To calculate the loss event rate p, we first calculate the average loss interval. This is done using a filter that weights the n most recent loss event intervals in such a way that the measured loss event rate changes smoothly.
为了计算损失事件率p，我们首先计算平均损失间隔。这是通过使用一个过滤器来完成的，该过滤器对n个最近的损失事件间隔进行加权，从而使测量的损失事件率平稳变化。
Weights w_0 to w_(n-1) are calculated as:
权重w_0至w_（n-1）的计算公式如下：
If (i < n/2)
w_i = 1;
Else
w_i = 1 - (i - (n/2 - 1))/(n/2 + 1);
If (i < n/2)
w_i = 1;
Else
w_i = 1 - (i - (n/2 - 1))/(n/2 + 1);
Thus if n=8, the values of w_0 to w_7 are:
因此，如果n=8，则w_0至w_7的值为：
1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2
1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2
The value n for the number of loss intervals used in calculating the loss event rate determines TFRC's speed in responding to changes in the level of congestion. As currently specified, TFRC should not be used for values of n significantly greater than 8, for traffic that might compete in the global Internet with TCP. At the very least, safe operation with values of n greater than 8 would require a slight change to TFRC's mechanisms to include a more severe response to two or more round-trip times with heavy packet loss.
用于计算丢失事件率的丢失间隔数的值n决定了TFRC响应拥塞级别变化的速度。正如目前所规定的，对于可能在全球互联网上与TCP竞争的流量，TFRC不应用于显著大于8的n值。至少，在n值大于8的情况下，安全运行需要对TFRC的机制进行轻微更改，以包括对两个或更多往返时间的更严重响应，并伴有严重的数据包丢失。
When calculating the average loss interval we need to decide whether to include the interval since the most recent packet loss event. We only do this if it is sufficiently large to increase the average loss interval.
在计算平均丢失间隔时，我们需要决定是否包括自最近的丢包事件以来的间隔。只有当它足够大以增加平均损失间隔时，我们才会这样做。
Thus if the most recent loss intervals are I_0 to I_n, with I_0 being the interval since the most recent loss event, then we calculate the average loss interval I_mean as:
因此，如果最近的损失间隔为I_0至I_n，I_0为自最近损失事件以来的间隔，则我们计算平均损失间隔I_平均值为：
I_tot0 = 0;
I_tot1 = 0;
W_tot = 0;
for (i = 0 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1));
}
I_tot = max(I_tot0, I_tot1);
I_mean = I_tot/W_tot;
I_tot0 = 0;
I_tot1 = 0;
W_tot = 0;
for (i = 0 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1));
}
I_tot = max(I_tot0, I_tot1);
I_mean = I_tot/W_tot;
The loss event rate, p is simply:
损失事件率p简单地表示为：
p = 1 / I_mean;
p = 1 / I_mean;
As described in Section 5.4, the most recent loss interval is only assigned 1/(0.75*n) of the total weight in calculating the average loss interval, regardless of the size of the most recent loss interval. This section describes an optional history discounting mechanism, discussed further in [3] and [9], that allows the TFRC receiver to adjust the weights, concentrating more of the relative weight on the most recent loss interval, when the most recent loss interval is more than twice as large as the computed average loss interval.
如第5.4节所述，在计算平均损耗间隔时，最新损耗间隔仅为总重量的1/（0.75*n），与最新损耗间隔的大小无关。本节描述了[3]和[9]中进一步讨论的可选历史贴现机制，该机制允许TFRC接收器调整权重，当最近的损失间隔大于计算的平均损失间隔的两倍时，将更多的相对权重集中在最近的损失间隔上。
To carry out history discounting, we associate a discount factor DF_i with each loss interval L_i, for i > 0, where each discount factor is a floating point number. The discount array maintains the cumulative history of discounting for each loss interval. At the beginning, the values of DF_i in the discount array are initialized to 1:
为了进行历史贴现，我们将贴现因子DF_i与每个损失间隔L_i相关联，对于i>0，其中每个贴现因子都是一个浮点数。折扣数组维护每个损失间隔的累计折扣历史记录。开始时，折扣数组中DF_i的值初始化为1：
for (i = 1 to n) {
DF_i = 1;
}
for (i = 1 to n) {
DF_i = 1;
}
History discounting also uses a general discount factor DF, also a floating point number, that is also initialized to 1. First we show how the discount factors are used in calculating the average loss interval, and then we describe later in this section how the discount factors are modified over time.
历史折扣也使用一般折扣系数DF，也是一个浮点数，也被初始化为1。首先，我们将展示如何在计算平均损失间隔时使用贴现因子，然后在本节稍后部分中描述贴现因子如何随时间进行修改。
As described in Section 5.4 the average loss interval is calculated using the n previous loss intervals I_1, ..., I_n, and the interval I_0 that represents the number of packets received since the last loss event. The computation of the average loss interval using the discount factors is a simple modification of the procedure in Section 5.4, as follows:
如第5.4节所述，使用n个先前的丢失间隔I_1，…，I_n和间隔I_0计算平均丢失间隔，间隔I_0表示自上次丢失事件以来接收的数据包数量。使用贴现系数计算平均损失间隔是对第5.4节程序的简单修改，如下所示：
I_tot0 = I_0 * w_0
I_tot1 = 0;
W_tot0 = w_0
W_tot1 = 0;
for (i = 1 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i * DF_i * DF);
W_tot0 = W_tot0 + w_i * DF_i * DF;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1) * DF_i);
W_tot1 = W_tot1 + w_(i-1) * DF_i;
}
p = min(W_tot0/I_tot0, W_tot1/I_tot1);
I_tot0 = I_0 * w_0
I_tot1 = 0;
W_tot0 = w_0
W_tot1 = 0;
for (i = 1 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i * DF_i * DF);
W_tot0 = W_tot0 + w_i * DF_i * DF;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1) * DF_i);
W_tot1 = W_tot1 + w_(i-1) * DF_i;
}
p = min(W_tot0/I_tot0, W_tot1/I_tot1);
The general discounting factor, DF is updated on every packet arrival as follows. First, the receiver computes the weighted average I_mean of the loss intervals I_1, ..., I_n:
一般折扣系数DF在每个数据包到达时更新，如下所示。首先，接收机计算损失间隔I_1，…，I_n的加权平均值I_：
I_tot = 0;
W_tot = 0;
for (i = 1 to n) {
W_tot = W_tot + w_(i-1) * DF_i;
I_tot = I_tot + (I_i * w_(i-1) * DF_i);
}
I_mean = I_tot / W_tot;
I_tot = 0;
W_tot = 0;
for (i = 1 to n) {
W_tot = W_tot + w_(i-1) * DF_i;
I_tot = I_tot + (I_i * w_(i-1) * DF_i);
}
I_mean = I_tot / W_tot;
This weighted average I_mean is compared to I_0, the number of packets received since the last loss event. If I_0 is greater than twice I_mean, then the new loss interval is considerably larger than the old ones, and the general discount factor DF is updated to decrease the relative weight on the older intervals, as follows:
此加权平均值I_mean与I_0（自上次丢失事件以来接收的数据包数）进行比较。如果I_0大于I_平均值的两倍，则新损失区间比旧损失区间大得多，并且更新一般贴现系数DF以减少旧损失区间的相对权重，如下所示：
if (I_0 > 2 * I_mean) {
DF = 2 * I_mean/I_0;
if (DF < THRESHOLD)
DF = THRESHOLD;
} else
DF = 1;
if (I_0 > 2 * I_mean) {
DF = 2 * I_mean/I_0;
if (DF < THRESHOLD)
DF = THRESHOLD;
} else
DF = 1;
A nonzero value for THRESHOLD ensures that older loss intervals from an earlier time of high congestion are not discounted entirely. We recommend a THRESHOLD of 0.5. Note that with each new packet arrival, I_0 will increase further, and the discount factor DF will be updated.
阈值的非零值可确保早期高拥塞时间的较旧丢失间隔不会被完全打折。我们建议阈值为0.5。请注意，随着每个新数据包的到达，I_0将进一步增加，折扣系数DF将被更新。
When a new loss event occurs, the current interval shifts from I_0 to I_1, loss interval I_i shifts to interval I_(i+1), and the loss interval I_n is forgotten. The previous discount factor DF has to be incorporated into the discount array. Because DF_i carries the discount factor associated with loss interval I_i, the DF_i array has to be shifted as well. This is done as follows:
当新的丢失事件发生时，当前间隔从I_0移动到I_1，丢失间隔I_I移动到间隔I_（I+1），丢失间隔I_n被遗忘。以前的折扣系数DF必须合并到折扣数组中。由于DF_i携带与损失间隔i_i相关联的贴现因子，因此DF_i数组也必须移位。具体做法如下：
for (i = 1 to n) {
DF_i = DF * DF_i;
}
for (i = n-1 to 0 step -1) {
DF_(i+1) = DF_i;
}
I_0 = 1;
DF_0 = 1;
DF = 1;
for (i = 1 to n) {
DF_i = DF * DF_i;
}
for (i = n-1 to 0 step -1) {
DF_(i+1) = DF_i;
}
I_0 = 1;
DF_0 = 1;
DF = 1;
This completes the description of the optional history discounting mechanism. We emphasize that this is an optional mechanism whose sole purpose is to allow TFRC to response somewhat more quickly to the sudden absence of congestion, as represented by a long current loss interval.
这就完成了可选历史贴现机制的描述。我们强调，这是一种可选机制，其唯一目的是允许TFRC对突然出现的拥塞（如长电流丢失间隔所示）做出更快的响应。
The receiver periodically sends feedback messages to the sender. Feedback packets should normally be sent at least once per RTT, unless the sender is sending at a rate of less than one packet per RTT, in which case a feedback packet should be send for every data
接收方定期向发送方发送反馈消息。通常，每个RTT应至少发送一次反馈数据包，除非发送方以低于每个RTT一个数据包的速率发送，在这种情况下，应为每个数据发送反馈数据包
packet received. A feedback packet should also be sent whenever a new loss event is detected without waiting for the end of an RTT, and whenever an out-of-order data packet is received that removes a loss event from the history.
收到数据包。每当检测到新的丢失事件而不等待RTT结束时，以及每当接收到从历史记录中删除丢失事件的无序数据包时，也应发送反馈数据包。
If the sender is transmitting at a high rate (many packets per RTT) there may be some advantages to sending periodic feedback messages more than once per RTT as this allows faster response to changing RTT measurements, and more resilience to feedback packet loss. However, there is little gain from sending a large number of feedback messages per RTT.
如果发送方以高速率传输（每个RTT发送多个数据包），则每个RTT多次发送周期性反馈消息可能有一些优势，因为这允许对变化的RTT测量做出更快的响应，并且对反馈数据包丢失具有更大的恢复力。然而，每个RTT发送大量反馈消息几乎没有什么好处。
When a data packet is received, the receiver performs the following steps:
当接收到数据分组时，接收器执行以下步骤：
1) Add the packet to the packet history.
1) 将数据包添加到数据包历史记录中。
2) Let the previous value of p be p_prev. Calculate the new value of p as described in Section 5.
2) 让p的前一个值为p_prev。按第5节所述计算新的p值。
3) If p > p_prev, cause the feedback timer to expire, and perform the actions described in Section 6.2
3) 如果p>p_prev，导致反馈计时器过期，并执行第6.2节中描述的操作
If p <= p_prev no action need be performed.
如果p<=p_prev，则无需执行任何操作。
However an optimization might check to see if the arrival of the packet caused a hole in the packet history to be filled and consequently two loss intervals were merged into one. If this is the case, the receiver might also send feedback immediately. The effects of such an optimization are normally expected to be small.
然而，优化可能会检查数据包的到达是否导致数据包历史中的漏洞被填满，从而将两个丢失间隔合并为一个。如果是这种情况，接收者也可能立即发送反馈。这种优化的影响通常很小。
When the feedback timer at the receiver expires, the action to be taken depends on whether data packets have been received since the last feedback was sent.
当接收器处的反馈定时器到期时，要采取的操作取决于自上次反馈发送以来是否已接收到数据包。
Let the maximum sequence number of a packet at the receiver so far be S_m, and the value of the RTT measurement included in packet S_m be R_m. If data packets have been received since the previous feedback was sent, the receiver performs the following steps:
让到目前为止接收器处的数据包的最大序列号为S_m，并且包括在数据包S_m中的RTT测量值为R_m。如果自上次反馈发送后已收到数据包，则接收器执行以下步骤：
1) Calculate the average loss event rate using the algorithm described above.
1) 使用上述算法计算平均损失事件率。
2) Calculate the measured receive rate, X_recv, based on the packets received within the previous R_m seconds.
2) 根据前R_m秒内接收到的数据包，计算测量的接收速率X_recv。
3) Prepare and send a feedback packet containing the information described in Section 3.2.2
3) 准备并发送包含第3.2.2节所述信息的反馈包
4) Restart the feedback timer to expire after R_m seconds.
4) 重新启动反馈计时器，使其在R\m秒后过期。
If no data packets have been received since the last feedback was sent, no feedback packet is sent, and the feedback timer is restarted to expire after R_m seconds.
如果自上次发送反馈后未收到任何数据包，则不会发送任何反馈包，并且反馈计时器将重新启动，在rm秒后过期。
The receiver is initialized by the first packet that arrives at the receiver. Let the sequence number of this packet be i.
接收器由到达接收器的第一个数据包初始化。让这个包的序列号为i。
When the first packet is received:
当接收到第一个数据包时：
o Set p=0
o 设置p=0
o Set X_recv = 0.
o 设置X_recv=0。
o Prepare and send a feedback packet.
o 准备并发送反馈信息包。
o Set the feedback timer to expire after R_i seconds.
o 将反馈计时器设置为在R_i秒后过期。
The number of packets until the first loss can not be used to compute the sending rate directly, as the sending rate changes rapidly during this time. TFRC assumes that the correct data rate after the first loss is half of the sending rate when the loss occurred. TFRC approximates this target rate by X_recv, the receive rate over the most recent round-trip time. After the first loss, instead of initializing the first loss interval to the number of packets sent until the first loss, the TFRC receiver calculates the loss interval that would be required to produce the data rate X_recv, and uses this synthetic loss interval to seed the loss history mechanism.
第一次丢失之前的数据包数量不能直接用于计算发送速率，因为在此期间发送速率变化很快。TFRC假设第一次丢失后的正确数据速率是丢失发生时发送速率的一半。TFRC通过X_recv（最近往返时间内的接收速率）近似该目标速率。在第一次丢失之后，TFRC接收器计算产生数据速率X_recv所需的丢失间隔，并使用该合成丢失间隔来为丢失历史机制种子，而不是将第一次丢失间隔初始化为在第一次丢失之前发送的数据包数。
TFRC does this by finding some value p for which the throughput equation in Section 3.1 gives a sending rate within 5% of X_recv, given the current packet size s and round-trip time R. The first loss interval is then set to 1/p. (The 5% tolerance is introduced simply because the throughput equation is difficult to invert, and we want to reduce the costs of calculating p numerically.)
TFRC通过找到某个值p来实现这一点，对于该值，第3.1节中的吞吐量方程给出的发送速率在X_recv的5%以内，给定当前数据包大小s和往返时间R。然后将第一个丢失间隔设置为1/p。（引入5%公差的原因很简单，因为吞吐量方程很难反转，我们希望减少数值计算p的成本。）
It would be possible to implement a sender-based variant of TFRC, where the receiver uses reliable delivery to send information about packet losses to the sender, and the sender computes the packet loss rate and the acceptable transmit rate. However, we do not specify the details of a sender-based variant in this document.
可以实现基于发送方的TFRC变体，其中接收方使用可靠传递向发送方发送关于分组丢失的信息，发送方计算分组丢失率和可接受的传输率。但是，我们在本文档中未指定基于发件人的变体的详细信息。
The main advantages of a sender-based variant of TFRC would be that the sender would not have to trust the receiver's calculation of the packet loss rate. However, with the requirement of reliable delivery of loss information from the receiver to the sender, a sender-based TFRC would have much tighter constraints on the transport protocol in which it is embedded.
基于发送方的TFRC变体的主要优点是发送方不必信任接收方对丢包率的计算。然而，由于需要将丢失信息从接收方可靠地传递给发送方，基于发送方的TFRC将对其嵌入的传输协议有更严格的限制。
In contrast, the receiver-based variant of TFRC specified in this document is robust to the loss of feedback packets, and therefore does not require the reliable delivery of feedback packets. It is also better suited for applications such as streaming media from web servers, where it is typically desirable to offload work from the server to the client as much as possible.
相比之下，本文中指定的基于接收器的TFRC变体对反馈数据包的丢失具有鲁棒性，因此不需要可靠地传递反馈数据包。它还更适合于web服务器的流媒体等应用程序，在这些应用程序中，通常希望尽可能多地将工作从服务器转移到客户端。
The sender-based and receiver-based variants also have different properties in terms of upgrades. For example, for changes in the procedure for calculating the packet loss rate, the sender would have to be upgraded in the sender-based variant, and the receiver would have to be upgraded in the receiver-based variant.
基于发送方和基于接收方的变体在升级方面也有不同的属性。例如，对于计算分组丢失率的过程中的更改，必须在基于发送方的变量中升级发送方，并且必须在基于接收方的变量中升级接收方。
This document has specified the TFRC congestion control mechanism, for use by applications and transport protocols. This section mentions briefly some of the few implementation issues.
本文档指定了TFRC拥塞控制机制，供应用程序和传输协议使用。本节简要介绍了一些实现问题。
For t_RTO = 4*R and b = 1, the throughput equation in Section 3.1 can be expressed as follows:
对于t_RTO=4*R和b=1，第3.1节中的吞吐量方程可以表示为：
s
X = --------
R * f(p)
s
X = --------
R * f(p)
for
对于
f(p) = sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2)).
f（p）=sqrt（2*p/3）+（12*sqrt（3*p/8）*p*（1+32*p^2））。
A table lookup could be used for the function f(p).
函数f（p）可以使用表查找。
Many of the multiplications (e.g., q and 1-q for the round-trip time average, a factor of 4 for the timeout interval) are or could be by powers of two, and therefore could be implemented as simple shift operations.
许多乘法（例如，对于往返时间平均值，q和1-q，对于超时间隔，因子为4）是或可以是2的幂，因此可以作为简单的移位操作来实现。
We note that the optional sender mechanism for preventing oscillations described in Section 4.5 uses a square-root computation.
我们注意到，第4.5节中描述的用于防止振荡的可选发送器机制使用平方根计算。
The calculation of the average loss interval in Section 5.4 involves multiplications by the weights w_0 to w_(n-1), which for n=8 are:
第5.4节中平均损失间隔的计算涉及权重w_0到w_（n-1）的乘积，对于n=8，其为：
1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2.
1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2.
With a minor loss of smoothness, it would be possible to use weights that were powers of two or sums of powers of two, e.g.,
在平滑度稍有损失的情况下，可以使用二次幂或二次幂和的权重，例如。，
1.0, 1.0, 1.0, 1.0, 0.75, 0.5, 0.25, 0.25.
1.0, 1.0, 1.0, 1.0, 0.75, 0.5, 0.25, 0.25.
The optional history discounting mechanism described in Section 5.5 is used in the calculation of the average loss rate. The history discounting mechanism is invoked only when there has been an unusually long interval with no packet losses. For a more efficient operation, the discount factor DF_i could be restricted to be a power of two.
第5.5节中描述的可选历史贴现机制用于计算平均损失率。只有在间隔异常长且没有数据包丢失时，才会调用历史折扣机制。为了更有效的操作，可以将贴现因子dfu i限制为二的幂。
TFRC is not a transport protocol in its own right, but a congestion control mechanism that is intended to be used in conjunction with a transport protocol. Therefore security primarily needs to be considered in the context of a specific transport protocol and its authentication mechanisms.
TFRC本身并不是一种传输协议，而是一种旨在与传输协议结合使用的拥塞控制机制。因此，主要需要在特定传输协议及其身份验证机制的上下文中考虑安全性。
Congestion control mechanisms can potentially be exploited to create denial of service. This may occur through spoofed feedback. Thus any transport protocol that uses TFRC should take care to ensure that feedback is only accepted from the receiver of the data. The precise mechanism to achieve this will however depend on the transport protocol itself.
拥塞控制机制可能被利用来创建拒绝服务。这可能通过欺骗反馈发生。因此，任何使用TFRC的传输协议都应该注意确保只接受来自数据接收方的反馈。然而，实现这一点的确切机制将取决于传输协议本身。
In addition, congestion control mechanisms may potentially be manipulated by a greedy receiver that wishes to receive more than its fair share of network bandwidth. A receiver might do this by claiming to have received packets that in fact were lost due to congestion. Possible defenses against such a receiver would normally include some form of nonce that the receiver must feed back to the sender to prove receipt. However, the details of such a nonce would
此外，拥塞控制机制可能被贪婪的接收者操纵，而贪婪的接收者希望接收超过其公平的网络带宽份额。接收者可以通过声称已经收到实际上由于拥塞而丢失的数据包来做到这一点。针对此类接收者的可能抗辩通常包括接收者必须反馈给发送者以证明其收到的某种形式的临时通知。然而，这样一个暂时的细节可能会被忽略
depend on the transport protocol, and in particular on whether the transport protocol is reliable or unreliable.
取决于传输协议，特别是取决于传输协议是可靠的还是不可靠的。
We expect that protocols incorporating ECN with TFRC will also want to incorporate feedback from the receiver to the sender using the ECN nonce [WES02]. The ECN nonce is a modification to ECN that protects the sender from the accidental or malicious concealment of marked packets. Again, the details of such a nonce would depend on the transport protocol, and are not addressed in this document.
我们预计，将ECN与TFRC结合在一起的协议也会希望结合使用ECN nonce从接收方到发送方的反馈[WES02]。ECN nonce是对ECN的一种修改，可保护发送方免受意外或恶意隐藏标记数据包的影响。同样，这种临时状态的细节将取决于传输协议，本文档中没有涉及。
There are no IANA actions required for this document.
本文件不需要IANA操作。
We would like to acknowledge feedback and discussions on equation-based congestion control with a wide range of people, including members of the Reliable Multicast Research Group, the Reliable Multicast Transport Working Group, and the End-to-End Research Group. We would like to thank Ken Lofgren, Mike Luby, Eduardo Urzaiz, Vladica Stanisic, Randall Stewart, Shushan Wen, and Wendy Lee (lhh@zsu.edu.cn) for feedback on earlier versions of this document, and to thank Mark Allman for his extensive feedback from using the document to produce a working implementation.
我们希望与包括可靠多播研究组、可靠多播传输工作组和端到端研究组成员在内的广泛人群就基于等式的拥塞控制进行反馈和讨论。我们要感谢肯·洛夫格伦、迈克·鲁比、爱德华多·乌尔扎伊兹、弗拉迪卡·斯坦尼西奇、兰德尔·斯图尔特、文书山和温迪·李(lhh@zsu.edu.cn)对于本文档早期版本的反馈，并感谢Mark Allman通过使用本文档生成工作实现所提供的广泛反馈。
[1] Balakrishnan, H., Rahul, H., and S. Seshan, "An Integrated Congestion Management Architecture for Internet Hosts," Proc. ACM SIGCOMM, Cambridge, MA, September 1999.
[1] Balakrishnan，H.，Rahul，H.，和S.Seshan，“互联网主机的集成拥塞管理架构”，Proc。ACM SIGCOMM，马萨诸塞州剑桥，1999年9月。
[2] Floyd, S., Handley, M., Padhye, J. and J. Widmer, "Equation-Based Congestion Control for Unicast Applications", August 2000, Proc. ACM SIGCOMM 2000.
[2] Floyd，S.，Handley，M.，Padhye，J.和J.Widmer，“单播应用中基于方程的拥塞控制”，2000年8月，Proc。ACM SIGCOMM 2000。
[3] Floyd, S., Handley, M., Padhye, J. and J. Widmer, "Equation-Based Congestion Control for Unicast Applications: the Extended Version", ICSI tech report TR-00-03, March 2000.
[3] Floyd，S.，Handley，M.，Padhye，J.和J.Widmer，“单播应用中基于方程的拥塞控制：扩展版本”，ICSI技术报告TR-00-032000年3月。
[4] Padhye, J., Firoiu, V., Towsley, D. and J. Kurose, "Modeling TCP Throughput: A Simple Model and its Empirical Validation", Proc. ACM SIGCOMM 1998.
[4] Padhye，J.，Firoiu，V.，Towsley，D.和J.Kurose，“TCP吞吐量建模：一个简单模型及其经验验证”，Proc。ACM SIGCOMM 1998。
[5] Paxson V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[5] Paxson V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[6] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[6] Ramakrishnan，K.，Floyd，S.和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[7] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[7] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[8] Wetherall, D., Ely, D., N. Spring, S. Savage, and T. Anderson, "Robust Congestion Signaling", IEEE International Conference on Network Protocols, November 2001.
[8] Wetherall，D.，Ely，D.，N.Spring，S.Savage和T.Anderson，“鲁棒拥塞信令”，IEEE网络协议国际会议，2001年11月。
[9] Widmer, J., "Equation-Based Congestion Control", Diploma Thesis, University of Mannheim, February 2000. URL "http://www.icir.org/tfrc/".
[9] Widmer，J，“基于方程的拥塞控制”，毕业论文，曼海姆大学，2000年2月。URL“http://www.icir.org/tfrc/".
Mark Handley ICIR/ICSI 1947 Center St, Suite 600 Berkeley, CA 94708
马克·汉德利ICIR/ICSI 1947中心街600号套房加利福尼亚州伯克利94708
EMail: mjh@icir.org
EMail: mjh@icir.org
Sally Floyd ICIR/ICSI 1947 Center St, Suite 600 Berkeley, CA 94708
Sally Floyd ICIR/ICSI 1947加利福尼亚州伯克利中心大街600号套房，邮编94708
EMail: floyd@icir.org
EMail: floyd@icir.org
Jitendra Padhye Microsoft Research
吉滕德拉·帕德伊微软研究院
EMail: padhye@microsoft.com
EMail: padhye@microsoft.com
Joerg Widmer Lehrstuhl Praktische Informatik IV Universitat Mannheim L 15, 16 - Room 415 D-68131 Mannheim Germany
德国曼海姆第四大学15楼16楼415 D-68131室
EMail: widmer@informatik.uni-mannheim.de
EMail: widmer@informatik.uni-mannheim.de
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。