Network Working Group S. Floyd
Request for Comments: 5348 ICIR
Obsoletes: 3448 M. Handley
Updates: 4342 University College London
J. Padhye
Microsoft
J. Widmer
DoCoMo
September 2008
Network Working Group S. Floyd
Request for Comments: 5348 ICIR
Obsoletes: 3448 M. Handley
Updates: 4342 University College London
J. Padhye
Microsoft
J. Widmer
DoCoMo
September 2008
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）。本备忘录的分发不受限制。
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 streaming media where a relatively smooth sending rate is of importance.
本文档规定了TCP友好速率控制（TFRC）。TFRC是一种用于在尽力而为的Internet环境中运行的单播流的拥塞控制机制。当与TCP流竞争带宽时，它是合理的，但与TCP相比，吞吐量随时间的变化要小得多，这使得它更适合于相对平滑的发送速率非常重要的流媒体等应用。
This document obsoletes RFC 3448 and updates RFC 4342.
本文件淘汰RFC 3448并更新RFC 4342。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Protocol Mechanism ..............................................4
3.1. TCP Throughput Equation ....................................5
3.2. Packet Contents ............................................7
3.2.1. Data Packets ........................................7
3.2.2. Feedback Packets ....................................8
4. Data Sender Protocol ............................................8
4.1. Measuring the Segment Size .................................9
4.2. Sender Initialization .....................................10
4.3. Sender Behavior When a Feedback Packet Is Received ........10
4.4. Expiration of Nofeedback Timer ............................15
4.5. Reducing Oscillations .....................................17
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Protocol Mechanism ..............................................4
3.1. TCP Throughput Equation ....................................5
3.2. Packet Contents ............................................7
3.2.1. Data Packets ........................................7
3.2.2. Feedback Packets ....................................8
4. Data Sender Protocol ............................................8
4.1. Measuring the Segment Size .................................9
4.2. Sender Initialization .....................................10
4.3. Sender Behavior When a Feedback Packet Is Received ........10
4.4. Expiration of Nofeedback Timer ............................15
4.5. Reducing Oscillations .....................................17
4.6. Scheduling of Packet Transmissions ........................18
5. Calculation of the Loss Event Rate (p) .........................19
5.1. Detection of Lost or Marked Packets .......................19
5.2. Translation from Loss History to Loss Events ..............20
5.3. The Size of a Loss Interval ...............................22
5.4. Average Loss Interval .....................................22
5.5. History Discounting .......................................24
6. Data Receiver Protocol .........................................26
6.1. Receiver Behavior When a Data Packet Is Received ..........27
6.2. Expiration of Feedback Timer ..............................27
6.3. Receiver Initialization ...................................28
6.3.1. Initializing the Loss History after the
First Loss Event ...................................29
7. Sender-Based Variants ..........................................30
8. Implementation Issues ..........................................31
8.1. Computing the Throughput Equation .........................31
8.2. Sender Behavior When a Feedback Packet Is Received ........32
8.2.1. Determining If an Interval Was a
Data-Limited Interval ..............................32
8.2.2. Maintaining X_recv_set .............................34
8.3. Sending Packets before Their Nominal Send Time ............34
8.4. Calculation of the Average Loss Interval ..................36
8.5. The Optional History Discounting Mechanism ................36
9. Changes from RFC 3448 ..........................................36
9.1. Overview of Changes .......................................36
9.2. Changes in Each Section ...................................37
10. Security Considerations .......................................39
10.1. Security Considerations for TFRC in DCCP .................40
11. Acknowledgments ...............................................40
Appendix A. Terminology ...........................................41
Appendix B. The Initial Value of the Nofeedback Timer .............43
Appendix C. Response to Idle or Data-Limited Periods ..............44
C.1. Long Idle or Data-Limited Periods ........................45
C.2. Short Idle or Data-Limited Periods .......................48
C.3. Moderate Idle or Data-Limited Periods ....................49
C.4. Losses During Data-Limited Periods .......................50
C.5. Other Patterns ...........................................53
C.6. Evaluating TFRC's Response to Idle Periods ...............53
References ........................................................54
Normative References ...........................................54
Informative References .........................................54
4.6. Scheduling of Packet Transmissions ........................18
5. Calculation of the Loss Event Rate (p) .........................19
5.1. Detection of Lost or Marked Packets .......................19
5.2. Translation from Loss History to Loss Events ..............20
5.3. The Size of a Loss Interval ...............................22
5.4. Average Loss Interval .....................................22
5.5. History Discounting .......................................24
6. Data Receiver Protocol .........................................26
6.1. Receiver Behavior When a Data Packet Is Received ..........27
6.2. Expiration of Feedback Timer ..............................27
6.3. Receiver Initialization ...................................28
6.3.1. Initializing the Loss History after the
First Loss Event ...................................29
7. Sender-Based Variants ..........................................30
8. Implementation Issues ..........................................31
8.1. Computing the Throughput Equation .........................31
8.2. Sender Behavior When a Feedback Packet Is Received ........32
8.2.1. Determining If an Interval Was a
Data-Limited Interval ..............................32
8.2.2. Maintaining X_recv_set .............................34
8.3. Sending Packets before Their Nominal Send Time ............34
8.4. Calculation of the Average Loss Interval ..................36
8.5. The Optional History Discounting Mechanism ................36
9. Changes from RFC 3448 ..........................................36
9.1. Overview of Changes .......................................36
9.2. Changes in Each Section ...................................37
10. Security Considerations .......................................39
10.1. Security Considerations for TFRC in DCCP .................40
11. Acknowledgments ...............................................40
Appendix A. Terminology ...........................................41
Appendix B. The Initial Value of the Nofeedback Timer .............43
Appendix C. Response to Idle or Data-Limited Periods ..............44
C.1. Long Idle or Data-Limited Periods ........................45
C.2. Short Idle or Data-Limited Periods .......................48
C.3. Moderate Idle or Data-Limited Periods ....................49
C.4. Losses During Data-Limited Periods .......................50
C.5. Other Patterns ...........................................53
C.6. Evaluating TFRC's Response to Idle Periods ...............53
References ........................................................54
Normative References ...........................................54
Informative References .........................................54
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 [FHPW00]. Instead of specifying a complete protocol, this document simply specifies a congestion control mechanism that could be used in a transport protocol such as DCCP (Datagram Congestion Control Protocol) [RFC4340], in an application incorporating end-to-end congestion control at the application level, or in the context of endpoint congestion management [BRS99]. This document does not discuss packet formats or reliability. Implementation-related issues are discussed only briefly, in Section 8.
本文档规定了TCP友好速率控制（TFRC）。TFRC是一种拥塞控制机制，设计用于在Internet环境中运行的单播流，并与TCP流量竞争[FHPW00]。本文档没有指定完整的协议，而是简单地指定了可用于传输协议（如DCCP（数据报拥塞控制协议）[RFC4340]）中的拥塞控制机制，该传输协议在应用程序级别合并了端到端拥塞控制，或者在端点拥塞管理的上下文中[BRS99]。本文件不讨论数据包格式或可靠性。第8节仅简要讨论了与实施有关的问题。
TFRC is designed to be reasonably fair when competing for bandwidth with TCP flows, where we call a flow "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 best performance with applications that use a fixed segment size, and vary their sending rate in packets per second in response to congestion. TFRC can also be used, perhaps with less optimal performance, with applications that do not have a fixed segment size, but where the segment size varies according to the needs of the application (e.g., video applications).
TFRC设计用于使用固定段大小的应用程序的最佳性能，并根据拥塞情况改变其发送速率（以每秒数据包为单位）。TFRC也可用于没有固定段大小，但段大小根据应用需要而变化的应用程序（例如，视频应用程序），其性能可能不太理想。
Some applications (e.g., some audio applications) require a fixed interval of time between packets and vary their segment size instead of their packet rate in response to congestion. The congestion control mechanism in this document is not designed for those applications; TFRC-SP (Small-Packet TFRC) is a variant of TFRC for applications that have a fixed sending rate in packets per second but either use small packets or vary their packet size in response to congestion. TFRC-SP is specified in a separate document [RFC4828].
一些应用程序（例如，一些音频应用程序）需要数据包之间的固定时间间隔，并根据拥塞情况改变其段大小而不是数据包速率。本文件中的拥塞控制机制不是为这些应用而设计的；TFRC-SP（Small Packet TFRC）是TFRC的一种变体，适用于具有固定发送速率（以每秒数据包为单位）但使用小数据包或改变其数据包大小以响应拥塞的应用程序。TFRC-SP在单独的文件[RFC4828]中规定。
This document specifies TFRC as 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. However, it is also possible to implement TFRC in sender-based variants, as allowed in DCCP's Congestion Control ID 3 (CCID 3) [RFC4342].
本文档将TFRC指定为基于接收方的机制，用于计算数据接收方而非数据发送方的拥塞控制信息（即丢失事件率）。这非常适合于发送方是处理许多并发连接的大型服务器，而接收方有更多的内存和CPU周期可用于计算的应用程序。此外，基于接收器的机制更适合作为多播拥塞控制的构建块。然而，也可以在基于发送方的变体中实现TFRC，正如DCCP的拥塞控制ID 3（CCID 3）[RFC4342]中所允许的那样。
This document obsoletes RFC 3448. In the transport protocol DCCP (Datagram Congestion Control Protocol) [RFC4340], the Congestion Control ID Profiles CCID-3 [RFC4342] and CCID-4 [CCID-4] both specify the use of TFRC from RFC 3448. CCID-3 and CCID-4 implementations SHOULD use this document instead of RFC 3448 for the specification of TFRC.
本文件淘汰RFC 3448。在传输协议DCCP（数据报拥塞控制协议）[RFC4340]中，拥塞控制ID配置文件CCID-3[RFC4342]和CCID-4[CCID-4]都指定了来自RFC 3448的TFRC的使用。对于TFRC规范，CCID-3和CCID-4实施应使用本文档而不是RFC 3448。
The normative specification of TFRC is in Sections 3-6. Section 7 discusses sender-based variants, Section 8 discusses implementation issues, and Section 9 gives a non-normative overview of differences with RFC 3448.
TFRC的规范性规范见第3-6节。第7节讨论了基于发送方的变体，第8节讨论了实现问题，第9节给出了RFC 3448差异的非规范性概述。
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]中所述进行解释。
Appendix A gives a list of technical terms used in this document.
附录A列出了本文件中使用的技术术语清单。
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 segment 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) [RFC3168].
对于其拥塞控制机制，TFRC直接使用允许发送速率的吞吐量方程作为丢失事件速率和往返时间的函数。为了与TCP公平竞争，TFRC使用TCP吞吐量方程，该方程将TCP的发送速率粗略地描述为丢失事件率、往返时间和段大小的函数。我们将丢失事件定义为来自数据窗口的一个或多个丢失或标记的数据包，其中标记的数据包指来自显式拥塞通知（ECN）的拥塞指示[RFC3168]。
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, and the resulting sending rate is limited to at most twice the receive rate to give the allowed transmit rate X.
o 然后将丢失事件速率和RTT反馈到TFRC的吞吐量方程中，得到的发送速率最多限制为接收速率的两倍，以给出允许的传输速率X。
o The sender then adjusts its transmit rate to match the allowed transmit rate X.
o 然后，发送方调整其传输速率以匹配允许的传输速率X。
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 currently REQUIRED for TFRC is a slightly simplified version of the throughput equation for Reno TCP from [PFTK98]. Ideally, we would prefer a throughput equation based on selective acknowledgment (SACK) TCP, but no one has yet derived the throughput equation for SACK TCP, and simulations and experiments suggest that the differences between the two equations would be relatively minor [FF99] (Appendix B).
TFRC目前需要的吞吐量方程是[PFTK98]中雷诺TCP吞吐量方程的稍微简化版本。理想情况下，我们更喜欢基于选择性确认（SACK）TCP的吞吐量方程，但还没有人推导出SACK TCP的吞吐量方程，模拟和实验表明，这两个方程之间的差异相对较小[FF99]（附录B）。
The throughput equation for X_Bps, TCP's average sending rate in bytes per second, is:
X_Bps（TCP的平均发送速率，以字节/秒为单位）的吞吐量方程为：
s
X_Bps = ----------------------------------------------------------
R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8)*p*(1+32*p^2)))
s
X_Bps = ----------------------------------------------------------
R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8)*p*(1+32*p^2)))
Where:
哪里：
X_Bps is TCP's average transmit rate in bytes per second. (X_Bps is the same as X_calc in RFC 3448.)
X_Bps是TCP的平均传输速率，以字节/秒为单位。（X_Bps与RFC 3448中的X_计算相同。）
s is the segment size in bytes (excluding IP and transport protocol headers).
s是以字节为单位的段大小（不包括IP和传输协议头）。
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 maximum number of packets acknowledged by a single TCP acknowledgement.
b是单个TCP确认确认的最大数据包数。
Setting the TCP retransmission timeout value t_RTO: Implementations SHOULD set t_RTO = 4*R. Implementations MAY choose to implement a more accurate calculation of t_RTO. Implementations MAY also set t_RTO to max(4*R, one second), to match the recommended minimum of one second on the RTO [RFC2988].
设置TCP重传超时值t_RTO：实现应设置t_RTO=4*R。实现可选择实现更精确的t_RTO计算。实现还可以将t_RTO设置为max（4*R，1秒），以匹配RTO上建议的最小1秒[RFC2988]。
Setting the parameter b for delayed acknowledgements: Some current TCP connections use delayed acknowledgements, sending an acknowledgement for every two data packets received. However, TCP is also allowed to send an acknowledgement for every data packet. For the revised TCP congestion control mechanisms, [RFC2581bis] currently specifies that the delayed acknowledgement algorithm should be used with TCP. However, [RFC2581bis] recommends increasing the congestion window during congestion avoidance by one segment per RTT even in the face of delayed acknowledgements, consistent with a TCP throughput equation with b = 1. On an experimental basis, [RFC2581bis] allows for increases of the congestion window during slow-start that are also consistent with a TCP throughput equation with b = 1. Thus, the use of b = 1 is consistent with [RFC2581bis]. The use of b = 1 is RECOMMENDED.
为延迟确认设置参数b：一些当前TCP连接使用延迟确认，每收到两个数据包就发送一个确认。但是，TCP也允许为每个数据包发送确认。对于修改后的TCP拥塞控制机制，[RFC2581bis]当前指定延迟确认算法应与TCP一起使用。然而，[RFC2581bis]建议在拥塞避免期间，即使在延迟确认的情况下，每个RTT增加一段拥塞窗口，这与b=1的TCP吞吐量方程一致。在实验基础上，[RFC2581bis]允许在慢启动期间增加拥塞窗口，这也符合b=1的TCP吞吐量方程。因此，b=1的使用与[RFC2581bis]一致。建议使用b=1。
With t_RTO=4*R and b=1, the throughput equation for X_Bps, the TCP sending rate in bytes per second, can be simplified as:
当t_RTO=4*R和b=1时，X_Bps的吞吐量方程（TCP发送速率，以字节/秒为单位）可以简化为：
s
X_Bps = -----------------------------------------------
R * (sqrt(2*p/3) + 12*sqrt(3*p/8)*p*(1+32*p^2))
s
X_Bps = -----------------------------------------------
R * (sqrt(2*p/3) + 12*sqrt(3*p/8)*p*(1+32*p^2))
In the future, updates to this document could specify different TCP equations to 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 throughput equation can also be expressed in terms of X_pps, the sending rate in packets per second, with
吞吐量方程也可以表示为X_pps，即每秒分组的发送速率，其中
X_pps = X_Bps / s .
X_pps=X_Bps/s。
The parameters s (segment 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, the measurement of R is specified in Section 4.3, and the measurement of p is specified in Section 5. In the rest of this document, data rates are measured in bytes per second unless otherwise specified.
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 MUST be 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.
o 指示数据包何时发送的时间戳。我们用ts_i表示序列号为i的数据包的时间戳。时间戳的分辨率通常应以毫秒为单位。
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 MAY be used 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 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. The round-trip time estimate is also used by the receiver to determine the interval to use for calculating the receive rate and to determine when to send feedback packets.
o 发送方对往返时间的当前估计。包i中报告的估计用R_i表示。接收器使用往返时间估计以及时间戳来确定多个损失何时属于同一损失事件。接收机还使用往返时间估计来确定用于计算接收速率的间隔以及确定何时发送反馈分组。
If the sender sends a coarse-grained "timestamp" that increments every quarter of a round-trip time, as discussed above, then the sender is not required to send its current estimate of the round trip time.
如上文所述，如果发送方发送每四分之一往返时间递增的粗粒度“时间戳”，则发送方无需发送其当前的往返时间估计。
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 the 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 in the previous round-trip time. 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 four round-trip times, then the sender 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 segment size being sent.
o 正在发送的平均段大小的测量。
o Sender initialization.
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 packet transmission and allowed burstiness.
o 分组传输的调度和允许的突发性。
The TFRC sender uses the segment size, s, in the throughput equation, in the setting of the maximum receive rate, the setting of the minimum and initial sending rates, and the setting of the nofeedback timer. The TFRC receiver MAY use the average segment size, s, in initializing the loss history after the first loss event. As specified in Section 6.3.1, if the TFRC receiver does not know the segment size, s, used by the sender, the TFRC receiver MAY instead use the arrival rate in packets per second in initializing the loss history.
TFRC发送方在吞吐量方程中，在最大接收速率的设置、最小和初始发送速率的设置以及无反馈定时器的设置中使用段大小s。TFRC接收器可在第一次丢失事件之后初始化丢失历史时使用平均段大小s。如第6.3.1节所述，如果TFRC接收器不知道发送方使用的段大小s，则TFRC接收器可以在初始化丢失历史时使用每秒数据包的到达率。
The segment size is normally known to an application. This may not be so in two cases:
应用程序通常知道段大小。在两种情况下可能并非如此：
1) The segment size naturally varies depending on the data. In this case, although the segment size varies, that variation is not coupled to the transmit rate. The TFRC sender can either compute the average segment size or use the maximum segment size for the segment size, s.
1) 段大小自然随数据的不同而变化。在这种情况下，尽管段大小变化，但该变化不与传输速率耦合。TFRC发送方可以计算平均段大小，也可以使用最大段大小作为段大小s。
2) The application needs to change the segment size rather than the number of segments 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.
2) 应用程序需要更改段大小而不是每秒的段数来执行拥塞控制。这通常是分组音频应用的情况，其中每个分组需要表示固定的时间间隔。这种应用需要有一种完全不同的测量参数的方法。
For the first class of applications where the segment size varies depending on the data, the sender SHOULD estimate the segment size, s, as the average segment size over the last four loss intervals. The sender MAY estimate the average segment size over longer time intervals, if so desired.
对于段大小因数据而异的第一类应用，发送方应将段大小s估计为过去四个丢失间隔内的平均段大小。如果需要，发送方可以估计更长时间间隔上的平均段大小。
The second class of applications are discussed separately in a separate document on TFRC-SP [RFC4828]. For the remainder of this section we assume the sender can estimate the segment size and that congestion control is performed by adjusting the number of packets sent per second.
第二类应用程序将在TFRC-SP[RFC4828]的单独文档中单独讨论。对于本节的其余部分，我们假设发送方可以估计段大小，并且通过调整每秒发送的数据包数量来执行拥塞控制。
The initial values for X (the allowed sending rate in bytes per second) and tld (the Time Last Doubled during slow-start, in seconds) are undefined until they are set as described below. If the sender is ready to send data when it does not yet have a round-trip sample, the value of X is set to s bytes per second, for segment size s, the nofeedback timer is set to expire after two seconds, and tld is set to 0 (or to -1, either one is okay). Upon receiving the first round-trip time measurement (e.g., after the first feedback packet or the SYN exchange from the connection setup, or from a previous connection [RFC2140]), tld is set to the current time, and the allowed transmit rate, X, is set to the initial_rate, specified as W_init/R, for W_init based on [RFC3390]:
X（允许的发送速率，以字节/秒为单位）和tld（慢启动期间最后一次翻倍的时间，以秒为单位）的初始值未定义，直到按如下所述进行设置。如果发送方准备在没有往返样本时发送数据，则X的值设置为每秒s字节，对于段大小s，nofeedback定时器设置为两秒后过期，tld设置为0（或-1，任何一个都可以）。在接收到第一次往返时间测量时（例如，在第一次反馈数据包或来自连接设置的SYN交换之后，或从先前的连接[RFC2140]），tld被设置为当前时间，并且允许的传输速率X被设置为初始速率，指定为W_init/R，用于基于[RFC3390]的W_init：
initial_rate = W_init/R; W_init = min(4*MSS, max(2*MSS, 4380)).
初始利率=W_初始/R；W_init=min（4*MSS，max（2*MSS，4380））。
In computing W_init, instead of using Maximum Segment Size (MSS), the TFRC sender SHOULD use the maximum segment size to be used for the initial round-trip time of data, if that is known by the TFRC sender when X is initialized.
在计算W_init时，如果TFRC发送方在初始化X时知道最大段大小，则TFRC发送方应使用用于数据初始往返时间的最大段大小，而不是使用最大段大小（MSS）。
For responding to the initial feedback packet, this replaces step (4) of Section 4.3 below.
为了响应初始反馈数据包，这将取代下面第4.3节的步骤（4）。
Appendix B explains why the initial value of TFRC's nofeedback timer is set to two seconds, instead of the recommended initial value of three seconds for TCP's retransmit timer from [RFC2988].
附录B解释了为什么TFRC的nofeedback定时器的初始值设置为2秒，而不是[RFC2988]中TCP的重传定时器的建议初始值3秒。
The sender knows its current allowed sending rate, X, and maintains an estimate of the current round-trip time R. The sender also maintains X_recv_set as a small set of recent X_recv values (typically only two values).
发送方知道其当前允许的发送速率X，并维护当前往返时间R的估计值。发送方还将X_recv_集维护为一组最近的X_recv值（通常只有两个值）。
Initialization: X_recv_set is first initialized to contain a single item, with value Infinity. (As an implementation-specific issue, X_recv_set MAY be initialized to a large number instead of to Infinity, e.g., to the largest integer that is easily representable.)
初始化：X_recv_集合首先初始化为包含单个项，值为无穷大。（作为一个特定于实现的问题，可以将X_recv_set初始化为一个大数字，而不是无穷大，例如，初始化为易于表示的最大整数。）
When a feedback packet is received by the sender at time t_now, the current time in seconds, the following actions MUST be performed.
当发送方在时间t_now（以秒为单位的当前时间）收到反馈数据包时，必须执行以下操作。
1) Calculate a new round-trip sample:
1) 计算新的往返样本：
R_sample = (t_now - t_recvdata) - t_delay.
R_sample = (t_now - t_recvdata) - t_delay.
As described in Section 3.2.2, t_delay gives the elapsed time at the receiver.
如第3.2.2节所述，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 a default value of 0.9 is RECOMMENDED.
TFRC对过滤器常数q的精确值不敏感，但建议使用默认值0.9。
3) Update the timeout interval:
3) 更新超时间隔：
RTO = max(4*R, 2*s/X)
RTO = max(4*R, 2*s/X)
4) Update the allowed sending rate as follows. This procedure uses the variables t_mbi and recv_limit:
4) 更新允许的发送速率，如下所示。此过程使用变量t_mbi和recv_limit：
t_mbi: the maximum backoff interval of 64 seconds. recv_limit: the limit on the sending rate computed from X_recv_set.
t_mbi：最大退避间隔为64秒。recv_limit：根据X_recv_集合计算的发送速率限制。
This procedure also uses the procedures Maximize X_recv_set() and Update X_recv_set(), which are defined below.
此过程还使用以下定义的过程Maximize X_recv_set（）和Update X_recv_set（）。
The procedure for updating the allowed sending rate:
更新允许的发送速率的过程：
If (the entire interval covered by the feedback packet
was a data-limited interval) {
If (the feedback packet reports a new loss event or an
increase in the loss event rate p) {
Halve entries in X_recv_set;
X_recv = 0.85 * X_recv;
Maximize X_recv_set();
recv_limit = max (X_recv_set);
} Else {
Maximize X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
} Else { // typical behavior
Update X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
If (p > 0) { // congestion avoidance phase
Calculate X_Bps using the TCP throughput equation.
X = max(min(X_Bps, recv_limit), s/t_mbi);
} Else if (t_now - tld >= R) {
// initial slow-start
X = max(min(2*X, recv_limit), initial_rate);
tld = t_now;
}
If (the entire interval covered by the feedback packet
was a data-limited interval) {
If (the feedback packet reports a new loss event or an
increase in the loss event rate p) {
Halve entries in X_recv_set;
X_recv = 0.85 * X_recv;
Maximize X_recv_set();
recv_limit = max (X_recv_set);
} Else {
Maximize X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
} Else { // typical behavior
Update X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
If (p > 0) { // congestion avoidance phase
Calculate X_Bps using the TCP throughput equation.
X = max(min(X_Bps, recv_limit), s/t_mbi);
} Else if (t_now - tld >= R) {
// initial slow-start
X = max(min(2*X, recv_limit), initial_rate);
tld = t_now;
}
5) If oscillation reduction is used, calculate the instantaneous transmit rate, X_inst, following Section 4.5.
5) 如果使用振荡抑制，根据第4.5节计算瞬时传输速率X_inst。
6) Reset the nofeedback timer to expire after RTO seconds.
6) 重置nofeedback计时器，使其在RTO秒后过期。
The procedure for maximizing X_recv_set keeps a single value, the largest value from X_recv_set and the new X_recv.
最大化X_recv_集的过程保留单个值，即X_recv_集的最大值和新的X_recv。
Maximize X_recv_set():
Add X_recv to X_recv_set;
Delete initial value Infinity from X_recv_set,
if it is still a member.
Set the timestamp of the largest item to the current time;
Delete all other items.
Maximize X_recv_set():
Add X_recv to X_recv_set;
Delete initial value Infinity from X_recv_set,
if it is still a member.
Set the timestamp of the largest item to the current time;
Delete all other items.
The procedure for updating X_recv_set keeps a set of X_recv values with timestamps from the two most recent round-trip times.
更新X_recv_set的过程会保留一组X_recv值，这些值带有最近两次往返时间的时间戳。
Update X_recv_set(): Add X_recv to X_recv_set; Delete from X_recv_set values older than two round-trip times.
更新X_recv_集（）：将X_recv添加到X_recv_集；从X_recv_集合中删除超过两个往返时间的值。
Definition of a data-limited interval: We define a sender as data-limited any time it is not sending as much as it is allowed to send. We define an interval as a 'data-limited interval' if the sender was data-limited over the *entire* interval; Section 8.2.1 discusses implementation issues for a sender in determining if an interval was a data-limited interval. The term 'data-limited interval' is used in the first "if" condition in step (4), which prevents a sender from having to reduce its sending rate as a result of a feedback packet reporting the receive rate from a data-limited period.
数据限制间隔的定义：我们将发送方定义为数据限制，只要它发送的数据没有允许发送的那么多。如果发送方在*整个*间隔内受到数据限制，我们将间隔定义为“数据限制间隔”；第8.2.1节讨论了发送方在确定某个间隔是否为数据受限间隔时的实施问题。在步骤（4）中的第一个“如果”条件中使用术语“数据限制间隔”，其防止发送者由于报告来自数据限制时段的接收速率的反馈分组而不得不降低其发送速率。
As an example, consider a sender that is sending at its full allowed rate, except that it is sending packets in pairs, rather than sending each packet as soon as it can. Such a sender is considered data-limited part of the time, because it is not always sending packets as soon as it can. However, consider an interval that covers this sender's transmission of at least two data packets; such an interval does not meet the definition of a data-limited interval because the sender was not data-limited *over the entire interval*.
作为一个例子，考虑一个发送者以完全允许的速率发送，除了它是成对发送分组，而不是尽可能快地发送每个分组。这种发送者在一定程度上被认为是数据受限的，因为它并不总是尽可能快地发送数据包。然而，考虑覆盖该发送者对至少两个数据分组的传输的间隔；这样的间隔不符合数据限制间隔的定义，因为发送方在整个间隔内没有数据限制*。
If the feedback packet reports a receive rate X_recv of zero (i.e., the first feedback packet), the sender does not consider that the entire interval covered by the feedback packet was a data-limited interval.
如果反馈分组报告接收速率XY-ReV为零（即，第一反馈分组），发送者不认为由反馈分组覆盖的整个间隔是数据受限的间隔。
X_recv_set and the first feedback packet: Because X_recv_set is initialized with a single item, with value Infinity, recv_limit is set to Infinity for the first two round-trip times of the connection. As a result, the sending rate is not limited by the receive rate during that period. This avoids the problem of the sending rate being limited by the value of X_recv from the first feedback packet.
X_recv_集和第一个反馈数据包：因为X_recv_集是用单个项初始化的，值为无穷大，所以连接的前两个往返时间的recv_limit设置为无穷大。因此，发送速率不受该期间的接收速率的限制。这避免了发送速率受来自第一反馈分组的X_recv的值限制的问题。
The interval covered by a feedback packet: How does the sender determine the period covered by a feedback packet? This is discussed in more detail in Section 8.2. In general, the receiver will be sending a feedback packet once per round-trip time; so typically, the sender will be able to determine exactly the period covered by the current feedback packet from the previous feedback packet. However, in cases when the previous
反馈包覆盖的时间间隔：发送者如何确定反馈包覆盖的时间段？第8.2节对此进行了更详细的讨论。通常，接收器将在每个往返时间发送一次反馈包；因此，通常，发送方将能够从先前的反馈数据包准确地确定当前反馈数据包覆盖的时间段。但是，如果以前的
feedback packet was lost, or when the receiver sends a feedback packet early because it detected a lost or ECN-marked packet, the sender will have to estimate the interval covered by the feedback packet. As specified in Section 6.2, each feedback packet sent by the receiver covers a round-trip time, for the round-trip time estimate R_m maintained by the receiver R_m seconds before the feedback packet was sent.
反馈数据包丢失，或者当接收方因为检测到丢失或带有ECN标记的数据包而提前发送反馈数据包时，发送方必须估计反馈数据包覆盖的间隔。如第6.2节所述，接收器发送的每个反馈数据包包含一个往返时间，用于接收器在发送反馈数据包之前维持的往返时间估计R_m秒。
The response to a loss during a data-limited interval: In TFRC, after the initial slow-start, the sender always updates the calculated transmit rate, X_Bps, after a feedback packet is received, and the allowed sending rate, X, is always limited by X_Bps. However, during a data-limited interval, when the actual sending rate is usually below X_Bps, the sending rate is still limited by recv_limit, derived from X_recv_set. If the sender is data-limited, possibly with a varying sending rate from one round-trip time to the next, and is experiencing losses, then we decrease the entry in X_recv_set in order to reduce the allowed sending rate.
在数据限制间隔期间对丢失的响应：在TFRC中，在初始慢启动之后，发送方总是在接收到反馈数据包之后更新计算的传输速率X_Bps，并且允许的发送速率X总是受到X_Bps的限制。但是，在数据有限的时间间隔内，当实际发送速率通常低于X_Bps时，发送速率仍然受到从X_recv_set导出的recv_limit的限制。如果发送方受到数据限制，可能在往返时间之间具有不同的发送速率，并且正在经历丢失，那么我们减少X_recv_集合中的条目以降低允许的发送速率。
The sender can detect a loss event during a data-limited period either from explicit feedback from the receiver, or from a reported increase in the loss event rate. When the sender receives a feedback packet reporting such a loss event in a data-limited interval, the sender limits the allowed increases in the sending rate during the data-limited interval.
发送方可以从接收方的明确反馈或从报告的丢失事件率增加中检测数据有限期内的丢失事件。当发送方在数据限制间隔内收到报告此类丢失事件的反馈数据包时，发送方限制数据限制间隔内发送速率的允许增加。
The initial slow-start phase: Note that when p=0, the sender has not yet learned of any loss events, and the sender is in the initial slow-start phase. In this initial slow-start phase, the sender can approximately double the sending rate each round-trip time until a loss occurs. The initial_rate term in step (4) gives a minimum allowed sending rate during slow-start of the initial allowed sending rate.
初始慢启动阶段：请注意，当p=0时，发送方尚未获悉任何丢失事件，发送方处于初始慢启动阶段。在这个初始的慢启动阶段，发送方可以在每次往返时间内将发送速率大约提高一倍，直到发生丢失。步骤（4）中的初始_速率项给出了初始允许发送速率缓慢启动期间的最小允许发送速率。
We note that if the sender is data-limited during slow-start, or if the connection is limited by the path bandwidth, then the sender is not necessarily able to double its sending rate each round-trip time; the sender's sending rate is limited to at most twice the past receive rate, or at most initial_rate, whichever is larger. This is similar to TCP's behavior, where the sending rate is limited by the rate of incoming acknowledgement packets as well as by the congestion window. Thus, in TCP's slow-start, for the most aggressive case of the TCP receiver acknowledging every data packet, the TCP sender's sending rate is limited to at most twice the rate of these incoming acknowledgment packets.
我们注意到，如果发送方在慢启动期间受到数据限制，或者如果连接受到路径带宽的限制，则发送方不一定能够在每次往返时间将其发送速率加倍；发送方的发送速率限制为过去接收速率的两倍，或最多为初始速率，以较大者为准。这类似于TCP的行为，其中发送速率受传入确认数据包的速率以及拥塞窗口的限制。因此，在TCP缓慢启动的情况下，对于TCP接收器确认每个数据包的最具攻击性的情况，TCP发送方的发送速率限制为这些传入确认包速率的两倍。
The minimum allowed sending rate: The term s/t_mbi ensures that when p > 0, the sender is allowed to send at least one packet every 64 seconds.
允许的最小发送速率：术语s/t_mbi确保当p>0时，发送方允许每64秒至少发送一个数据包。
This section specifies the sender's response to a nofeedback timer. The nofeedback timer could expire because of an idle period or because of data or feedback packets dropped in the network.
本节指定发送方对反馈计时器的响应。nofeedback计时器可能因空闲时间或网络中丢弃的数据或反馈数据包而过期。
This section uses the variable recover_rate. If the TFRC sender has been idle ever since the nofeedback timer was set, the allowed sending rate is not reduced below the recover_rate. For this document, the recover_rate is set to the initial_rate (specified in Section 4.2). Future updates to this specification may explore other possible values for the recover_rate.
本节使用可变恢复率。如果自设置nofeedback计时器后TFRC发送器一直处于空闲状态，则允许的发送速率不会降低到恢复速率以下。对于本文件，恢复率设置为初始恢复率（在第4.2节中规定）。本规范的未来更新可能会探讨恢复率的其他可能值。
If the nofeedback timer expires, the sender MUST perform the following actions:
如果nofeedback计时器过期，发送方必须执行以下操作：
1) Cut the allowed sending rate in half.
1) 将允许的发送速率减半。
If the nofeedback timer expires when the sender has had at least one RTT measurement, the allowed sending rate is reduced by modifying X_recv_set as described in the pseudocode below (including item (2)). In the general case, the sending rate is limited to at most twice X_recv. Modifying X_recv_set limits the sending rate, but still allows the sender to slow-start, doubling its sending rate each RTT, if feedback messages resume reporting no losses.
如果当发送方至少进行了一次RTT测量时，nofeedback计时器过期，则通过修改下面伪代码（包括第（2）项）中所述的X_recv_集合来降低允许的发送速率。在一般情况下，发送速率最多限制为X_recv的两倍。修改X_recv_set会限制发送速率，但仍允许发送方减慢启动速度，如果反馈消息继续报告没有丢失，则每次RTT的发送速率将增加一倍。
If the sender has been idle since this nofeedback timer was set and X_recv is less than the recover_rate, then the allowed sending rate is not halved, and X_recv_set is not changed. This ensures that the allowed sending rate is not reduced to less than half the recover_rate as a result of an idle period.
如果自设置此nofeedback定时器后发送方一直处于空闲状态，且X_recv小于recover_速率，则允许的发送速率不会减半，X_recv_set也不会更改。这可确保允许的发送速率不会因空闲时间而降低到恢复速率的一半以下。
In the general case, the allowed sending rate is halved in response to the expiration of the nofeedback timer. The details, in the pseudocode below, depend on whether the sender is in slow-start, is in congestion avoidance limited by X_recv, or is in congestion avoidance limited by the throughput equation.
在一般情况下，允许的发送速率将减半，以响应nofeedback计时器的到期。下面的伪代码中的详细信息取决于发送方是否处于慢启动状态，是否处于受X_recv限制的拥塞避免状态，或者是否处于受吞吐量方程限制的拥塞避免状态。
X_recv = max (X_recv_set);
If (sender does not have an RTT sample,
has not received any feedback from receiver,
and has not been idle ever since the nofeedback timer
was set) {
// We do not have X_Bps or recover_rate yet.
// Halve the allowed sending rate.
X = max(X/2, s/t_mbi);
} Else if (((p>0 && X_recv < recover_rate) or
(p==0 && X < 2 * recover_rate)), and
sender has been idle ever
since nofeedback timer was set) {
// Don't halve the allowed sending rate.
Do nothing;
} Else if (p==0) {
// We do not have X_Bps yet.
// Halve the allowed sending rate.
X = max(X/2, s/t_mbi);
} Else if (X_Bps > 2*X_recv)) {
// 2*X_recv was already limiting the sending rate.
// Halve the allowed sending rate.
Update_Limits(X_recv;)
} Else {
// The sending rate was limited by X_Bps, not by X_recv.
// Halve the allowed sending rate.
Update_Limits(X_Bps/2);
}
X_recv = max (X_recv_set);
If (sender does not have an RTT sample,
has not received any feedback from receiver,
and has not been idle ever since the nofeedback timer
was set) {
// We do not have X_Bps or recover_rate yet.
// Halve the allowed sending rate.
X = max(X/2, s/t_mbi);
} Else if (((p>0 && X_recv < recover_rate) or
(p==0 && X < 2 * recover_rate)), and
sender has been idle ever
since nofeedback timer was set) {
// Don't halve the allowed sending rate.
Do nothing;
} Else if (p==0) {
// We do not have X_Bps yet.
// Halve the allowed sending rate.
X = max(X/2, s/t_mbi);
} Else if (X_Bps > 2*X_recv)) {
// 2*X_recv was already limiting the sending rate.
// Halve the allowed sending rate.
Update_Limits(X_recv;)
} Else {
// The sending rate was limited by X_Bps, not by X_recv.
// Halve the allowed sending rate.
Update_Limits(X_Bps/2);
}
The term s/t_mbi limits the backoff to one packet every 64 seconds.
术语s/t_mbi将回退限制为每64秒一个数据包。
The procedure Update_Limits() uses the variable timer_limit for the limit on the sending rate computed from the expiration of the nofeedback timer, as follows:
过程Update_Limits（）使用变量timer_limit作为从nofeedback timer过期计算的发送速率限制，如下所示：
Update_Limits(timer_limit):
If (timer_limit < s/t_mbi)
timer_limit = s/t_mbi;
Replace X_recv_set contents with the single item
timer_limit/2;
Recalculate X as in step (4) of Section 4.3;
Update_Limits(timer_limit):
If (timer_limit < s/t_mbi)
timer_limit = s/t_mbi;
Replace X_recv_set contents with the single item
timer_limit/2;
Recalculate X as in step (4) of Section 4.3;
2) Restart the nofeedback timer to expire after max(4*R, 2*s/X) seconds.
2) 重新启动nofeedback计时器，使其在最长（4*R，2*s/X）秒后过期。
If the sender has been data-limited but not idle since the nofeedback timer was set, it is possible that the nofeedback timer expired because data or feedback packets were dropped in the network. In
如果自设置nofeedback定时器以来，发送方一直受到数据限制，但未处于空闲状态，则nofeedback定时器可能因数据或反馈数据包在网络中丢失而过期。在里面
this case, the nofeedback timer is the backup mechanism for the sender to detect these losses, similar to the retransmit timer in TCP.
在这种情况下，nofeedback计时器是发送方检测这些丢失的备份机制，类似于TCP中的重传计时器。
Note that when the sender stops sending data for a period of time, the receiver will stop sending feedback. When the sender's nofeedback timer expires, the sender could use the procedure above to limit the sending rate. If the sender subsequently starts to send again, X_recv_set will be used to limit the transmit rate, and slow-start behavior will occur until the transmit rate reaches X_Bps.
请注意，当发送方停止发送数据一段时间后，接收方将停止发送反馈。当发送方的nofeedback计时器过期时，发送方可以使用上述过程限制发送速率。如果发送方随后再次开始发送，X_recv_set将用于限制传输速率，并且在传输速率达到X_Bps之前，将出现缓慢启动行为。
The TFRC sender's reduction of the allowed sending rate after the nofeedback timer expires is similar to TCP's reduction of the congestion window, cwnd, after each RTO seconds of an idle period, for TCP with Congestion Window Validation [RFC2861].
对于具有拥塞窗口验证的TCP，TFRC发送方在nofeedback计时器过期后对允许发送速率的减少类似于TCP在空闲期的每RTO秒后对拥塞窗口cwnd的减少[RFC2861]。
To reduce oscillations in queueing delay and sending rate in environments with a low degree of statistical multiplexing at the congested link, it is RECOMMENDED that the sender reduce the transmit rate as the queueing delay (and hence RTT) increases. To do this, the sender maintains R_sqmean, a long-term estimate of the square root of the RTT, and modifies its sending rate depending on how the square root of R_sample, the most recent sample of the RTT, differs from the long-term estimate. The long-term estimate R_sqmean is set as follows:
为了减少拥挤链路上统计复用程度较低的环境中排队延迟和发送速率的振荡，建议发送方随着排队延迟（因此RTT）的增加而降低传输速率。为此，发送方维护RTT平方根的长期估计值R_sqmean，并根据R_样本（RTT的最近样本）的平方根与长期估计值的差异来修改其发送速率。长期估计R_sq均值设置如下：
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, the constant used in the round-trip time estimate R. A value of 0.9 as the default for q2 is RECOMMENDED.
因此，R_sqmean给出RTT样本平方根的指数加权移动平均值。常数q2的设置应与q类似，q是往返时间估算R中使用的常数。建议将q2的默认值设置为0.9。
When sqrt(R_sample) is greater than R_sqmean, then the current round-trip time is greater than the long-term average, implying that queueing delay is probably increasing. In this case, the transmit rate is decreased to minimize oscillations in queueing delay.
当sqrt（R_sample）大于R_sqmean时，则当前往返时间大于长期平均值，这意味着排队延迟可能正在增加。在这种情况下，降低传输速率以最小化排队延迟中的振荡。
The sender obtains the base allowed transmit rate, X, as described in step (4) of Section 4.3 above. It then calculates a modified instantaneous transmit rate X_inst, as follows:
如上文第4.3节步骤（4）所述，发送方获得基本允许传输速率X。然后计算修改后的瞬时传输速率X_inst，如下所示：
X_inst = X * R_sqmean / sqrt(R_sample);
If (X_inst < s/t_mbi)
X_inst = s/t_mbi;
X_inst = X * R_sqmean / sqrt(R_sample);
If (X_inst < s/t_mbi)
X_inst = s/t_mbi;
Because we are using square roots, there is generally only a moderate difference between the instantaneous transmit rate X_inst and the allowed transmit rate X. For example, in a somewhat extreme case when the current RTT sample R_sample is twice as large as the long-term average, then sqrt(R_sample) will be roughly 1.44 times R_sqmean, and the allowed transmit rate will be reduced by a factor of roughly 0.7.
因为我们使用的是平方根，所以瞬时传输速率X_inst和允许传输速率X之间通常只有适度的差异。例如，在某种极端情况下，当当前RTT样本R_样本是长期平均值的两倍时，sqrt（R_样本）大约是R_sqmean的1.44倍，允许的传输速率将减少大约0.7倍。
We note that this modification for reducing oscillatory behavior is not always needed, especially if the degree of statistical multiplexing in the network is high. We also note that the modification for reducing oscillatory behavior could cause problems for connections where the round-trip time is not strongly correlated with the queueing delay (e.g., in some wireless links, over paths with frequent routing changes, etc.). However, this modification SHOULD be implemented because it makes TFRC behave better in some environments with a low level of statistical multiplexing. The performance of this modification is illustrated in Section 3.1.3 of [FHPW00]. If it is not implemented, implementations SHOULD use a very low value of the weight q for the average round-trip time.
我们注意到，这种减少振荡行为的修改并不总是需要的，特别是当网络中的统计复用度较高时。我们还注意到，减少振荡行为的修改可能会导致往返时间与排队延迟不密切相关的连接出现问题（例如，在某些无线链路中，通过频繁路由更改的路径等）。但是，应该实施此修改，因为它使TFRC在某些统计复用级别较低的环境中表现得更好。[FHPW00]第3.1.3节说明了该修改的性能。如果未实现，则实现应使用非常低的权重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 coarse-grain or irregular scheduling of the operating system. To help maintain the correct average sending rate, the TFRC sender MAY send some packets before their nominal send time.
由于TFRC是基于速率的，并且由于操作系统通常无法精确地调度事件，因此在发送数据包时必须机会主义，以便在操作系统的粗粒度或不规则调度的情况下保持正确的平均速率。为了帮助保持正确的平均发送速率，TFRC发送方可以在其标称发送时间之前发送一些数据包。
In addition, the scheduling of packet transmissions controls the allowed burstiness of senders after an idle or data-limited period. The TFRC sender MAY accumulate sending 'credits' for past unused send times; this allows the TFRC sender to send a burst of data after an idle or data-limited period. To compare with TCP, TCP may send up to a round-trip time's worth of packets in a single burst, but never more. As examples, packet bursts can be sent by TCP when an ACK arrives acknowledging a window of data, or when a data-limited sender suddenly has a window of data to send after a delay of nearly a round-trip time.
此外，分组传输的调度控制空闲或数据受限时段后发送方的允许突发性。TFRC发送方可以累积过去未使用的发送时间的发送“积分”；这允许TFRC发送方在空闲或数据限制期后发送突发数据。与TCP相比，TCP可以在一次突发中发送最多相当于往返时间的数据包，但不会超过。例如，当确认数据窗口的ACK到达时，或者当数据受限的发送方在将近一个往返时间的延迟之后突然有一个数据窗口要发送时，可以通过TCP发送分组突发。
To limit burstiness, a TFRC implementation MUST prevent bursts of arbitrary size. This limit MUST be less than or equal to one round-trip time's worth of packets. A TFRC implementation MAY limit bursts to less than a round-trip time's worth of packets. In addition, a TFRC implementation MAY use rate-based pacing to smooth bursts.
为了限制突发性，TFRC实现必须防止任意大小的突发。此限制必须小于或等于一个往返时间的数据包。TFRC实现可以将突发限制为少于往返时间的数据包。此外，TFRC实现可以使用基于速率的起搏来平滑突发。
As an implementation-specific example, a sending loop could calculate the correct inter-packet interval, t_ipi, as follows:
作为实现特定的示例，发送循环可以计算正确的包间间隔t_ipi，如下所示：
t_ipi = s/X_inst;
t_ipi = s/X_inst;
Let t_now be the current time and i be a natural number, i = 0, 1, ..., with t_i the nominal send time for the i-th packet. Then, the nominal send time t_(i+1) would derive recursively as:
现在让t_为当前时间，i为自然数，i=0，1，…，t_i为第i个数据包的标称发送时间。然后，标称发送时间t_（i+1）将递归推导为：
t_0 = t_now, t_(i+1) = t_i + t_ipi.
t_0=t_现在，t_（i+1）=t_i+t_ipi。
For TFRC senders allowed to accumulate sending credits for unused send time over the last T seconds, the sender would be allowed to use unused nominal send times t_j for t_j < now - T, for T set to the round-trip time.
对于允许在过去T秒内累积未使用发送时间的TFRC发送方，将允许发送方使用未使用的标称发送时间T_j，T_j<now-T，T设置为往返时间。
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. If the receiver has not yet detected a lost or marked packet, then the receiver does not calculate the loss event rate, but reports a loss event rate of zero.
准确、稳定地测量损失事件率对于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, it is REQUIRED 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 this 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 NDUPACK packets with a higher sequence number than the lost packet, for NDUPACK set to 3. The requirement for NDUPACK 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 NDUPACK 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 rate. Future versions of TFRC might make the requirement for NDUPACK subsequent packets adaptive based on experienced packet reordering, but such a mechanism is not part of the current specification.
对于设置为3的NDUPACK，通过至少具有比丢失的数据包更高序列号的NDUPACK数据包的到达来检测数据包的丢失。NDUPACK后续数据包的要求与TCP相同，是为了使TFRC在重新排序时更加健壮。与TCP相反，如果数据包在TFRC中延迟到达（在NDUPACK后续数据包到达之后），则延迟的数据包可以填充TFRC接收记录中的漏洞，并且接收方可以重新计算丢失事件率。TFRC的未来版本可能会使NDUPACK后续数据包的要求基于有经验的数据包重新排序进行自适应，但这种机制不是当前规范的一部分。
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的连接，标记的数据包一到达即被检测为拥塞事件，而不必等待后续数据包的到达。
If an ECN-marked packet is preceded by a possibly-lost packet, then the first detected congestion event begins with the lost packet. For example, if the receiver receives a data packet with sequence number n-1, followed by an unmarked data packet with sequence number n+1, and a marked data packet with sequence number n+2, then the receiver detects a congestion event when it receives the marked packet n+2. The first congestion event detected begins with the lost packet n. The guidelines in Section 5.2 below are used to determine whether the lost and marked packets belong to the same loss event or to separate loss events.
如果ECN标记的数据包前面有可能丢失的数据包，则第一个检测到的拥塞事件从丢失的数据包开始。例如，如果接收机接收到序列号为n-1的数据分组，随后是序列号为n+1的未标记数据分组，以及序列号为n+2的标记数据分组，则接收机在接收到标记的分组n+2时检测到拥塞事件。检测到的第一个拥塞事件从丢失的数据包n开始。下面第5.2节中的指南用于确定丢失和标记的数据包属于同一丢失事件还是属于单独的丢失事件。
TFRC requires that the loss fraction be robust to several consecutive packets lost or marked in 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 or marked 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
TFRC要求丢失分数对在同一丢失事件中丢失或标记的多个连续数据包具有鲁棒性。这与TCP类似，TCP（通常）在任何单个RTT期间只执行拥塞窗口的一半。因此，接收机需要将分组丢失历史映射到丢失事件记录中，其中丢失事件是在RTT中丢失或标记的一个或多个分组。要执行此映射，接收方需要知道要使用的RTT，并且这通常由发送方定期提供，作为控制信息
piggy-backed onto a data packet. TFRC is not sensitive to how the RTT measurement sent to the receiver is made, but it is RECOMMENDED to use the sender's calculated RTT, R, (see Section 4.3) for this purpose.
piggy返回到一个数据包上。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, before any packet arrivals with a sequence number above S_loss, with a sequence number below S_loss.
S_before是最后一个到达的数据包的序列号，在序列号高于S_损耗、序列号低于S_损耗的任何数据包到达之前。
S_after is the sequence number of the first packet to arrive after S_before with a sequence number above S_loss.
S_after是在S_before之后到达的第一个数据包的序列号，序列号高于S_loss。
S_max is the largest sequence number.
S_max是最大的序列号。
Therefore, S_before < S_loss < S_after <= S_max.
因此，S_之前<S_损失<S_之后<=S_最大值。
T_loss is the nominal estimated arrival time for the lost packet.
T_loss是丢失数据包的标称估计到达时间。
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 < T_after.
请注意，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_loss，我们可以根据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) );
To address sequence number wrapping, let S_MAX = 2^b, where b is the bit-length of sequence numbers in a given implementation. In this case, we can interpolate the arrival time T_loss as follows:
为了解决序列号换行问题，让S_MAX=2^b，其中b是给定实现中序列号的位长度。在这种情况下，我们可以按如下方式插值到达时间T_损失：
T_loss = T_before + (T_after - T_before)
* Dist(S_loss, S_before)/Dist(S_after, S_before)
T_loss = T_before + (T_after - T_before)
* Dist(S_loss, S_before)/Dist(S_after, S_before)
where
哪里
Dist(S_A, S_B) = (S_A + S_MAX - S_B) % S_MAX
Dist(S_A, S_B) = (S_A + S_MAX - S_B) % S_MAX
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是新丢失事件中的第一个数据包。
After the detection of the first loss event, the receiver divides the sequence space into loss intervals. 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). Thus, loss interval A contains all of the packets transmitted by the sender starting with the first packet transmitted in loss interval A and ending with but not including the first packet transmitted in loss interval B.
在检测到第一个丢失事件之后，接收器将序列空间划分为丢失间隔。如果确定丢失间隔a以分组序列号S_a开始，而下一个丢失间隔B以分组序列号S_B开始，则丢失间隔a中的分组数由（S_B-S_a）给出。因此，丢失间隔A包含由发送方发送的所有分组，从在丢失间隔A中发送的第一分组开始，以但不包括在丢失间隔B中发送的第一分组结束。
The current loss interval I_0 is defined as the loss interval containing the most recent loss event. If that loss event started with packet sequence number S_A, and S_C is the highest received sequence number so far, then the size of I_0 is S_C - S_A + 1. As an example, if the current loss interval consists of a single ECN-marked packet, then S_A == S_C, and the size of the loss interval is one.
当前损失间隔I_0定义为包含最近损失事件的损失间隔。如果丢失事件以数据包序列号S_A开始，并且S_C是迄今为止接收到的最高序列号，那么I_0的大小是S_C-S_A+1。例如，如果当前丢失间隔由单个ECN标记的数据包组成，则S_a==S_C，并且丢失间隔的大小为1。
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. If the receiver has not yet seen a lost or marked packet, then the receiver does not calculate the average loss interval.
为了计算损失事件率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 = 2 * (n-i)/(n+2);
}
If (i < n/2) {
w_i = 1;
} Else {
w_i = 2 * (n-i)/(n+2);
}
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. It is RECOMMENDED to set the value n to 8. TFRC SHOULD NOT use values of n 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响应拥塞级别变化的速度。建议将值n设置为8。对于可能与TCP在全球互联网上竞争的流量，TFRC不应使用大于8的n值。至少，在n值大于8的情况下，安全运行需要对TFRC的机制进行轻微更改，以包括对两个或更多往返时间的更严重响应，并伴有严重的数据包丢失。
When calculating the average loss interval, we need to decide whether to include the current loss interval. We only include the current loss interval if it is sufficiently large to increase the average loss interval.
在计算平均损耗间隔时，我们需要决定是否包括当前损耗间隔。只有当电流损耗间隔足够大以增加平均损耗间隔时，我们才包括电流损耗间隔。
Let the most recent loss intervals be I_0 to I_k, where I_0 is the current loss interval. If there have been at least n loss intervals, then k is set to n; otherwise, k is the maximum number of loss intervals seen so far. We calculate the average loss interval I_mean as follows:
设最近的损耗间隔为I_0到I_k，其中I_0是当前损耗间隔。如果至少存在n个丢失间隔，则k被设置为n；否则，k是迄今为止看到的最大损失间隔数。我们计算平均损失间隔I_平均值如下：
I_tot0 = 0;
I_tot1 = 0;
W_tot = 0;
for (i = 0 to k-1) {
I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i;
}
for (i = 1 to k) {
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 k-1) {
I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i;
}
for (i = 1 to k) {
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, when there have been at least n loss intervals, 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 [FHPW00a] and [W00], 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节所述，当至少存在n个损失间隔时，在计算平均损失间隔时，最近的损失间隔仅为总重量的1/（0.75*n），而与最近损失间隔的大小无关。本节描述了[FHPW00a]和[W00]中进一步讨论的可选历史贴现机制，该机制允许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与i>0的每个损失区间L_i相关联，其中每个贴现因子都是一个浮点数。折扣数组维护每个损失间隔的累计折扣历史记录。开始时，折扣数组中DF_i的值初始化为1：
for (i = 0 to n) {
DF_i = 1;
}
for (i = 0 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 current loss interval I_0. 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计算平均损耗间隔。使用贴现系数计算平均损失间隔是对第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 size of current loss interval. 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_平均值与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.25. Note that with each new packet arrival, I_0 will increase further, and the discount factor DF will be updated.
阈值的非零值可确保早期高拥塞时间的较旧丢失间隔不会被完全打折。我们建议阈值为0.25。请注意，随着每个新数据包的到达，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 respond 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 sent for every data 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应至少发送一次反馈数据包，除非发送方以低于每个RTT一个数据包的速率发送，在这种情况下，应为接收到的每个数据包发送反馈数据包。每当检测到新的丢失事件而不等待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.
如果发送方以高速率（每个RTT发送多个分组）发送，则每个RTT多次发送周期性反馈消息可能有一些优势，因为这允许对变化的RTT测量做出更快的响应，并且对反馈分组丢失具有更大的弹性。
If the receiver was sending k feedback packets per RTT, for k>1, step (4) of Section 6.2 would be modified to set the feedback timer to expire after R_m/k seconds. However, each feedback packet would still report the receiver rate over the last RTT, not over a fraction of an RTT. In this document, we do not specify the modifications that might be required for a receiver sending more than one feedback packet per RTT. We note that there is little gain from sending a large number of feedback messages per RTT.
如果接收器每RTT发送k个反馈数据包，对于k>1，将修改第6.2节的步骤（4），以将反馈计时器设置为在R_m/k秒后过期。然而，每个反馈数据包仍然会报告最后一个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) Check if done: If the new packet results in the detection of a new loss event, or if no feedback packet was sent when the feedback timer last expired, go to step 3. Otherwise, no action need be performed (unless the optimization in the next paragraph is used), so exit the procedure.
2) 检查是否完成：如果新数据包导致检测到新的丢失事件，或者如果反馈计时器上次过期时没有发送反馈数据包，请转至步骤3。否则，不需要执行任何操作（除非使用下一段中的优化），因此退出该过程。
An OPTIONAL 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.
可选的优化可以检查数据包的到达是否导致数据包历史中的漏洞被填满，从而将两个丢失间隔合并为一个。如果是这种情况，接收者也可能立即发送反馈。这种优化的影响通常很小。
3) Calculate p: Let the previous value of p be p_prev. Calculate the new value of p as described in Section 5.
3) 计算p：让p的上一个值为p_prev。按第5节所述计算新的p值。
4) Expire feedback timer: If p > p_prev, cause the feedback timer to expire and perform the actions described in Section 6.2.
4) 使反馈计时器过期：如果p>p_prev，使反馈计时器过期，并执行第6.2节中描述的操作。
If p <= p_prev and no feedback packet was sent when the feedback timer last expired, cause the feedback timer to expire and perform the actions described in Section 6.2. If p <= p_prev and a feedback packet was sent when the feedback timer last expired, no action need be performed.
如果p<=p_prev且反馈计时器上次过期时未发送反馈数据包，则导致反馈计时器过期，并执行第6.2节中所述的操作。如果p<=p_prev，并且在反馈计时器上次过期时发送了反馈数据包，则无需执行任何操作。
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.
当接收器处的反馈定时器到期时，要采取的操作取决于自上次反馈发送以来是否已接收到数据包。
For the m-th expiration of the feedback timer, 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. As described in Section 3.2.1, R_m is the sender's most recent estimate of the round-trip time, as reported in data packets. If data packets have been received since the previous feedback was sent, the receiver performs the following steps:
对于反馈定时器的第m个到期日，让接收器处的分组的最大序列号（到目前为止）为sm，并且分组sm中包括的RTT测量值为rm。如第3.2.1节所述，R_m是发送方对往返时间的最新估计，如数据包中所报告。如果自上次反馈发送后已收到数据包，则接收器执行以下步骤：
1) Calculate the average loss event rate using the algorithm described in Section 5.
1) 使用第5节中描述的算法计算平均损失事件率。
2) Calculate the measured receive rate, X_recv, based on the packets received within the previous R_(m-1) seconds. This is performed whether the feedback timer expired at its normal time or expired early due to a new lost or marked packet (i.e., step (3) in Section 6.1).
2) 根据前R_u（m-1）秒内接收到的数据包，计算测量的接收速率X_recv。无论反馈定时器是在其正常时间过期，还是由于新丢失或标记的数据包而提前过期（即第6.1节中的步骤（3）），都会执行此操作。
In the typical case, when the receiver is sending only one feedback packet per round-trip time and the feedback timer did not expire early due to a new lost packet, then the time interval since the feedback timer last expired would be R_(m-1) seconds.
在典型情况下，当接收器在每个往返时间仅发送一个反馈数据包，并且反馈定时器没有由于新的丢失数据包而提前到期时，则自反馈定时器上次到期以来的时间间隔将为R_m（m-1）秒。
We note that when the feedback timer expires early due to a new lost or marked packet, the time interval since the feedback timer last expired is likely to be smaller than R_(m-1) seconds.
我们注意到，当反馈计时器由于新的丢失或标记的数据包而提前到期时，自反馈计时器上次到期以来的时间间隔可能小于R_m（m-1）秒。
For ease of implementation, if the time interval since the feedback timer last expired is not R_(m-1) seconds, the receive rate MAY be calculated over a longer time interval, the time interval going back to the most recent feedback timer expiration that was at least R_(m-1) seconds ago.
为便于实施，如果自反馈定时器上次到期以来的时间间隔不是R_um（m-1）秒，则可以在更长的时间间隔上计算接收速率，该时间间隔返回到至少R_m（m-1）秒之前的最近反馈定时器到期。
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秒后过期。
Note that rule 2) above gives a minimum value for the measured receive rate X_recv of one packet per round-trip time. If the sender is limited to a sending rate of less than one packet per round-trip time, this will be due to the loss event rate, not from a limit imposed by the measured receive rate at the receiver.
注意，上面的规则2）给出了每个往返时间一个数据包的测量接收速率X_recv的最小值。如果发送方被限制为每个往返时间少于一个数据包的发送速率，这将是由于丢失事件速率造成的，而不是由于接收方测量的接收速率所施加的限制。
If no data packets have been received since the last feedback was sent, then 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 data 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秒后过期。
If the first data packet does not contain an estimate R_i of the round-trip time, then the receiver sends a feedback packet for every arriving data packet until a data packet arrives containing an estimate of the round-trip time.
如果第一数据分组不包含往返时间的估计R_i，则接收器针对每个到达的数据分组发送反馈分组，直到包含往返时间估计的数据分组到达。
If the sender is using a coarse-grained timestamp that increments every quarter of a round-trip time, then a feedback timer is not needed, and the following procedure from RFC 4342 is used to determine when to send feedback messages.
如果发送方正在使用每四分之一往返时间递增的粗粒度时间戳，则不需要反馈定时器，并且使用来自RFC 4342的以下过程来确定何时发送反馈消息。
o Whenever the receiver sends a feedback message, the receiver sets a local variable last_counter to the greatest received value of the window counter since the last feedback message was sent, if any data packets have been received since the last feedback message was sent.
o 每当接收器发送反馈消息时，如果自上次反馈消息发送以来已收到任何数据包，则接收器将局部变量last_计数器设置为自上次反馈消息发送以来窗口计数器的最大接收值。
o If the receiver receives a data packet with a window counter value greater than or equal to last_counter + 4, then the receiver sends a new feedback packet. ("Greater" and "greatest" are measured in circular window counter space.)
o 如果接收器接收到窗口计数器值大于或等于last_计数器+4的数据包，则接收器发送新的反馈包。（“较大”和“最大”在圆形窗口计数器空间中测量。）
This section describes the procedure that MUST be used for initializing the loss history after the first loss event.
本节介绍在第一次丢失事件后初始化丢失历史记录时必须使用的过程。
The number of packets until the first loss cannot be used to compute the allowed 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 maximum sending rate before the loss occurred. TFRC approximates this target rate, X_target, by the maximum value of X_recv so far. (For slow-start, for a particular round-trip time, the sender's sending rate is generally twice the receiver's receive rate for data sent over the previous round-trip time.)
直到第一次丢失的数据包数不能直接用于计算允许的发送速率，因为在此期间发送速率变化很快。TFRC假设第一次丢失后的正确数据速率是丢失发生前最大发送速率的一半。TFRC将该目标速率X_target近似为迄今为止X_recv的最大值。（对于慢速启动，对于特定的往返时间，发送方的发送速率通常是前一往返时间内发送的数据的接收方接收速率的两倍。）
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_target, and uses this synthetic loss interval to seed the loss history mechanism.
在第一次丢失之后，TFRC接收器计算生成数据速率X_目标所需的丢失间隔，并使用此合成丢失间隔来为丢失历史机制种子，而不是将第一次丢失间隔初始化为在第一次丢失之前发送的数据包数。
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_target, given the round-trip time R, and the first loss interval is then set to 1/p. If the receiver knows the segment size, s, used by the
TFRC通过找到某个值p来实现这一点，对于该值，第3.1节中的吞吐量方程给出了X_目标的5%以内的发送速率，给定往返时间R，然后将第一个丢失间隔设置为1/p。如果接收器知道接收器使用的段大小s
sender, then the receiver MAY use the throughput equation for X; otherwise, the receiver MAY measure the receive rate in packets per second instead of bytes per second for this purpose, and use the throughput equation for X_pps. (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.)
发送方，则接收方可以使用X的吞吐量方程；否则，接收机可为此目的以分组/秒而不是字节/秒来测量接收速率，并使用X_pps的吞吐量方程。（引入5%公差的原因很简单，因为吞吐量方程很难反转，我们希望减少数值计算p的成本。）
Special care is needed for initializing the first loss interval when the first data packet is lost or marked. When the first data packet is lost in TCP, the TCP sender retransmits the packet after the retransmit timer expires. If TCP's first data packet is ECN-marked, the TCP sender resets the retransmit timer, and sends a new data packet only when the retransmit timer expires [RFC3168] (Section 6.1.2). For TFRC, if the first data packet is lost or ECN-marked, then the first loss interval consists of the null interval with no data packets. In this case, the loss interval length for this (null) loss interval SHOULD be set to give a similar sending rate to that of TCP, as specified in the paragraph below.
当第一个数据包丢失或标记时，需要特别注意初始化第一个丢失间隔。当第一个数据包在TCP中丢失时，TCP发送方在重传计时器过期后重传该数据包。如果TCP的第一个数据包带有ECN标记，则TCP发送方将重置重传计时器，并仅在重传计时器过期时发送新数据包[RFC3168]（第6.1.2节）。对于TFRC，如果第一个数据包丢失或标记了ECN，则第一个丢失间隔由无数据包的空间隔组成。在这种情况下，应设置此（空）丢失间隔的丢失间隔长度，以提供与TCP相似的发送速率，如下段所述。
When the first TFRC loss interval is null, meaning that the first data packet is lost or ECN-marked, in order to follow the behavior of TCP, TFRC wants the allowed sending rate to be 1 packet every two round-trip times, or equivalently, 0.5 packets per RTT. Thus, the TFRC receiver calculates the loss interval that would be required to produce the target rate X_target of 0.5/R packets per second, for the round-trip time R, and uses this synthetic loss interval for the first loss interval. The TFRC receiver uses 0.5/R packets per second as the minimum value for X_target when initializing the first loss interval.
当第一个TFRC丢失间隔为null时，意味着第一个数据包丢失或标记ECN，为了遵循TCP的行为，TFRC希望允许的发送速率为每两个往返时间1个数据包，或者等效地，每RTT 0.5个数据包。因此，对于往返时间R，TFRC接收机计算产生每秒0.5/R分组的目标速率X_目标所需的丢失间隔，并将该合成丢失间隔用于第一丢失间隔。在初始化第一个丢失间隔时，TFRC接收器每秒使用0.5/R数据包作为X_目标的最小值。
We note that even though the TFRC receiver reports a synthetic loss interval after the first loss event, the TFRC receiver still reports the measured receive rate X_recv, as specified in Section 6.2 above.
我们注意到，即使TFRC接收器在第一次丢失事件后报告合成丢失间隔，TFRC接收器仍报告测量的接收速率X_recv，如上文第6.2节所述。
In a sender-based variant of TFRC, 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.
在基于发送方的TFRC变体中，接收方使用可靠传递向发送方发送有关数据包丢失的信息，发送方计算数据包丢失率和可接受的传输率。
The main advantage of a sender-based variant of TFRC is that the sender does 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 where it is desirable to offload work from the server to the client as much as possible.
相比之下，本文中指定的基于接收器的TFRC变体对反馈数据包的丢失具有鲁棒性，因此不需要可靠地传递反馈数据包。它还更适合于希望尽可能多地将工作从服务器转移到客户端的应用程序。
RFC 4340 and RFC 4342 together specify DCCP's CCID 3, which can be used as a sender-based variant of TFRC. In CCID 3, each feedback packet from the receiver contains a Loss Intervals option, reporting the lengths of the most recent loss intervals. Feedback packets may also include the Ack Vector option, allowing the sender to determine exactly which packets were dropped or marked and to check the information reported in the Loss Intervals options. The Ack Vector option can also include ECN Nonce Echoes, allowing the sender to verify the receiver's report of having received an unmarked data packet. The Ack Vector option allows the sender to see for itself which data packets were lost or ECN-marked, to determine loss intervals, and to calculate the loss event rate. Section 9 of RFC 4342 discusses issues in the sender verifying information reported by the receiver.
RFC 4340和RFC 4342一起指定了DCCP的CCID 3，它可以用作TFRC的基于发送方的变体。在CCID3中，来自接收器的每个反馈包都包含一个丢失间隔选项，报告最近丢失间隔的长度。反馈分组还可以包括Ack Vector选项，允许发送方准确地确定丢弃或标记了哪些分组，并检查丢失间隔选项中报告的信息。Ack Vector选项还可以包括ECN Nonce回波，允许发送方验证接收方已接收到未标记数据分组的报告。Ack Vector选项允许发送方自行查看哪些数据包丢失或标记了ECN，以确定丢失间隔，并计算丢失事件率。RFC 4342的第9节讨论了发送方验证接收方报告的信息的问题。
This document has specified the TFRC congestion control mechanism, for use by applications and transport protocols. This section mentions briefly some of the 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_Bps = --------
R * f(p)
s
X_Bps = --------
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的幂，因此可以作为简单的移位操作来实现。
This section discusses implementation issues for sender behavior when a feedback packet is received, from Section 4.3.
本节从第4.3节讨论收到反馈数据包时发送方行为的实现问题。
When a feedback packet is received, the sender has to determine if the entire interval covered by that feedback packet was a data-limited period. This section discusses one possible implementation for the sender to determine if the interval covered by a feedback packet was a data-limited period.
当接收到反馈数据包时，发送方必须确定该反馈数据包覆盖的整个时间间隔是否为数据有限期。本节讨论发送方确定反馈数据包覆盖的时间间隔是否为数据有限期的一种可能实现。
If the feedback packets all report the timestamp of the last data packet received, then let t_new be the timestamp reported by this feedback packet. Because all feedback packets cover an interval of at least a round-trip time, it is sufficient for the sender to determine if there was any time in the period (t_old, t_new] when the sender was not data-limited, for R the sender's estimate of the round-trip time, and for t_old set to t_new - R. (This procedure estimates the interval covered by the feedback packet, rather than computing it exactly. This seems fine to us.)
如果反馈数据包都报告接收到的最后一个数据包的时间戳，那么t_new就是该反馈数据包报告的时间戳。因为所有反馈分组覆盖至少一个往返时间的间隔，所以发送方可以确定在发送方不受数据限制的时段（t_old，t_new）中是否有任何时间，对于R发送方对往返时间的估计，以及对于t_old设置为t_new-R。（此过程估计反馈数据包覆盖的时间间隔，而不是精确计算。这对我们来说似乎很好。）
The pseudocode for determining if the sender was data-limited over the entire interval covered in a feedback packet is given below. The variables NotLimited1 and NotLimited2 both represent times when the sender was *not* data-limited.
下面给出了用于确定发送方是否在反馈数据包覆盖的整个间隔内受到数据限制的伪代码。变量NotLimited1和NotLimited2都表示发送方*不*数据受限的时间。
Initialization:
NotLimited1 = NotLimited2 = t_new = t_next = 0;
t_now = current time;
Initialization:
NotLimited1 = NotLimited2 = t_new = t_next = 0;
t_now = current time;
After sending a segment:
If (sender has sent all it is allowed to send) {
// Sender is not data-limited at this instant.
If NotLimited1 <= t_new
// Goal: NotLimited1 > t_new.
NotLimited1 = t_now;
Else if (NotLimited2 <= t_next)
// Goal: NotLimited2 > t_next.
NotLimited2 = t_now;
}
After sending a segment:
If (sender has sent all it is allowed to send) {
// Sender is not data-limited at this instant.
If NotLimited1 <= t_new
// Goal: NotLimited1 > t_new.
NotLimited1 = t_now;
Else if (NotLimited2 <= t_next)
// Goal: NotLimited2 > t_next.
NotLimited2 = t_now;
}
When a feedback packet is received, is this interval data-limited:
t_new = timestamp reported in feedback packet.
t_old = t_new - R. // local variable
t_next = t_now;
If ((t_old < NotLimited1 <= t_new) or
(t_old < NotLimited2 <= t_new))
This was not a data-limited interval;
Else
This was a data-limited interval.
If (NotLimited1 <= t_new && NotLimited2 > t_new)
NotLimited1 = NotLimited2;
When a feedback packet is received, is this interval data-limited:
t_new = timestamp reported in feedback packet.
t_old = t_new - R. // local variable
t_next = t_now;
If ((t_old < NotLimited1 <= t_new) or
(t_old < NotLimited2 <= t_new))
This was not a data-limited interval;
Else
This was a data-limited interval.
If (NotLimited1 <= t_new && NotLimited2 > t_new)
NotLimited1 = NotLimited2;
Transmission times refer to transmission of a segment or segments to the layer below.
传输时间是指将一个或多个段传输到下面的层。
Between feedback packets, (t_old, t_new] gives the transmission time interval estimated to be covered by the most recent feedback packet, and t_next gives a time at least a round-trip time greater than t_new. The next feedback packet can be expected to cover roughly the interval (t_new, t_next] (unless the receiver sends the feedback packet early because it is reporting a new loss event). The goal is for NotLimited1 to save a non-data-limited time in (t_new, t_next], if there was one, and for NotLimited2 to save a non-data-limited time after t_next.
在反馈数据包之间，（t_old，t_new）给出估计由最近的反馈数据包覆盖的传输时间间隔，而t_next给出的时间至少比t_new大一个往返时间。下一个反馈数据包可以大致覆盖该间隔（t_new，t_next）（除非接收方提前发送反馈数据包，因为它正在报告新的丢失事件）。目标是NotLimited1在（t_new，t_next）中保存非数据限制时间（如果有），NotLimited2在t_next之后保存非数据限制时间。
When a feedback packet was received, if either NotLimited1 or NotLimited2 is in the time interval covered by the feedback packet, then the interval is not a data-limited interval; the sender was not data-limited at least once during that time interval. If neither NotLimited1 nor NotLimited2 is in the time interval covered by a feedback packet, then the sender is assumed to have been data-limited over that time interval.
当接收到反馈分组时，如果NotLimited1或NotLimited2在反馈分组所覆盖的时间间隔内，则该间隔不是数据限制间隔；在该时间间隔内，发送方至少有一次不受数据限制。如果NotLimited1和NotLimited2都不在反馈数据包覆盖的时间间隔内，则假定发送方在该时间间隔内受到数据限制。
We note that this procedure is a heuristic, and in some cases the sender might not determine correctly if the sender was data-limited over the entire interval covered by the feedback packet. This heuristic does not address the possible complications of reordering.
我们注意到，这个过程是一个启发式过程，在某些情况下，发送方可能无法正确确定发送方是否在反馈数据包覆盖的整个时间间隔内受到数据限制。这种启发式方法不能解决重新排序可能带来的复杂问题。
That seems acceptable to us. In order to improve its accuracy in identifying if the entire interval covered by a feedback packet was a data-limited interval, the sender could save more NotLimited times.
我们似乎可以接受。为了提高其识别反馈包覆盖的整个间隔是否为数据受限间隔的准确性，发送方可以节省更多的非受限时间。
In some implementations of TFRC, the sender sends coarse-grained timestamps that increment every quarter of a round-trip time, and the feedback packet reports the greatest valid sequence number received so far instead of reporting the timestamp of the last packet received. In this case, the sender can maintain per-packet state to
在TFRC的一些实现中，发送方发送每四分之一往返时间递增的粗粒度时间戳，反馈数据包报告迄今为止收到的最大有效序列号，而不是报告最后收到的数据包的时间戳。在这种情况下，发送方可以将每个数据包的状态保持为
determine t_new (the time that the acknowledged packet was sent), or the sender can estimate t_new from its estimate of the round-trip time and the elapsed time t_delay reported by the feedback packet.
确定t_new（确认的数据包被发送的时间），或者发送方可以根据其对往返时间和反馈数据包报告的经过时间t_延迟的估计来估计t_new。
To reduce the complexity of maintaining X_recv_set, it is sufficient to limit X_recv_set to at most N=3 elements. In this case, the procedure Update X_recv_set() would be modified as follows:
为了降低维护X_recv_集的复杂性，将X_recv_集限制为最多N=3个元素就足够了。在这种情况下，更新X_recv_set（）过程将修改如下：
Update X_recv_set(): Add X_recv to X_recv_set; Delete from X_recv_set values older than two round-trip times. Keep only the most recent N values.
更新X_recv_集（）：将X_recv添加到X_recv_集；从X_recv_集合中删除超过两个往返时间的值。仅保留最近的N值。
Maintaining at most *two* elements in X_recv_set would be sufficient for the sender to save an old value of X_recv from before a data-limited period, and to allow the sender not to be limited by the first feedback packet after an idle period (reporting a receive rate of one packet per round-trip time). However, it is *possible* that maintaining at most two elements in X_recv_set would not give quite as good performance as maintaining at most three elements. Maintaining three elements in X_recv_set would allow X_recv_set to contain X_recv values from two successive feedback packets, plus a more recent X_recv value from a loss event.
在X_recv_集合中保持最多*两个*元素将足以使发送方保存数据限制期之前的旧X_recv值，并允许发送方在空闲期后不受第一个反馈数据包的限制（报告每个往返时间一个数据包的接收率）。然而，在X_recv_集合中维护最多两个元素的性能可能不如维护最多三个元素的性能好。在X_recv_集合中保留三个元素将允许X_recv_集合包含来自两个连续反馈数据包的X_recv值，以及来自丢失事件的最近X_recv值。
This section discusses one possible scheduling mechanism for a sender in an operating system with a coarse-grained timing granularity (from Section 4.6).
本节讨论了操作系统中具有粗粒度定时粒度的发送方的一种可能的调度机制（来自第4.6节）。
Let t_gran be the scheduling timer granularity of the operating system. Let t_ipi be the inter-packet interval, as specified in Section 4.6. If the operating system has a coarse timer granularity or otherwise cannot support short t_ipi intervals, then either the TFRC sender will be restricted to a sending rate of at most 1 packet every t_gran seconds, or the TFRC sender must be allowed to send short bursts of packets. In addition to allowing the sender to accumulate sending credits for past unused send times, it can be useful to allow the sender to send a packet before its scheduled send time, as described in the section below.
设t_gran为操作系统的调度计时器粒度。设t_ipi为第4.6节规定的包间间隔。如果操作系统具有较粗的计时器粒度，或者无法支持较短的t_ipi间隔，则TFRC发送器将被限制为每t_gran秒最多发送1个数据包，或者必须允许TFRC发送器发送短突发数据包。除了允许发送方在过去未使用的发送时间内累积发送信用之外，允许发送方在其预定发送时间之前发送数据包也是有用的，如以下部分所述。
A parameter, t_delta, may be used to allow a packet to be sent before its nominal send time. Consider an application that becomes idle and requests re-scheduling for time t_i = t_(i-1) + t_ipi, for t_(i-1) the send time for the previous packet. When the application is
参数t_delta可用于允许在分组的标称发送时间之前发送分组。考虑一个变为空闲的应用程序，并请求Tyi= Ty（I-1）+Tay-IPi的重新调度，用于Ty（I-1）上一个分组的发送时间。当应用程序
rescheduled, it checks the current time, t_now. If (t_now > t_i - t_delta), then packet i is sent. When the nominal send time, t_i, of the next packet is calculated, it may already be the case that t_now > t_i - t_delta. In such a case, the packet would be sent immediately.
重新安排，它检查当前时间，t_now。如果（t_now>t_i-t_delta），则发送数据包i。当计算下一个分组的标称发送时间t_i时，可能已经出现t_now>t_i-t_delta的情况。在这种情况下，数据包将立即发送。
In order to send at most one packet before its nominal send time, and never to send a packet more than a round-trip time before its nominal send time, the parameter t_delta would be set as follows:
为了在其标称发送时间之前最多发送一个数据包，并且在其标称发送时间之前不发送超过往返时间的数据包，参数t_delta将设置如下：
t_delta = min(t_ipi, t_gran, rtt)/2;
t_delta = min(t_ipi, t_gran, rtt)/2;
(The scheduling granularity t_gran is 10 ms on some older Unix systems.)
（在一些较旧的Unix系统上，调度粒度t_gran为10 ms。）
As an example, consider a TFRC flow with an allowed sending rate X of 10 packets per round-trip time (PPR), a round-trip time of 100 ms, a system with a scheduling granularity t_gran of 10 ms, and the ability to accumulate unused sending credits for a round-trip time. In this case, t_ipi is 1 ms. The TFRC sender would be allowed to send packets 0.5 ms before their nominal sending time, and would be allowed to save unused sending credits for 100 ms. The scheduling granularity of 10 ms would not significantly affect the performance of the connection.
作为一个例子，考虑一个TFRC流，其允许的发送速率x为每回程时间10个分组（PPR），往返时间为100毫秒，具有调度粒度为10毫秒的系统，以及累积用于往返时间的未使用的发送信用的能力。在这种情况下，t_ipi为1 ms。TFRC发送方将允许在其标称发送时间之前0.5 ms发送数据包，并允许将未使用的发送信用保存100 ms。10 ms的调度粒度不会显著影响连接的性能。
As a different example, consider a TFRC flow with a scheduling granularity greater than the round-trip time, for example, with a round-trip time of 0.1 ms and a system with a scheduling granularity of 1 ms, and with the ability to accumulate unused sending credits for a round-trip time. The TFRC sender would be allowed to save unused sending credits for 0.1 ms. If the scheduling granularity *did not* affect the sender's response to an incoming feedback packet, then the TFRC sender would be able to send an RTT of data (as determined by the allowed sending rate) each RTT, in response to incoming feedback packets. In this case, the coarse scheduling granularity would not significantly reduce the sending rate, but the sending rate would be bursty, with a round-trip time of data sent in response to each feedback packet.
作为一个不同的例子，考虑具有大于往返时间的调度粒度的TFRC流，例如，具有0.1毫秒的往返时间和具有1毫秒的调度粒度的系统，并且具有累积用于往返时间的未使用的发送信用的能力。TFRC发送方将被允许将未使用的发送信用保存0.1毫秒。如果调度粒度*不*影响发送方对传入反馈数据包的响应，则TFRC发送方将能够对每个RTT发送数据的RTT（由允许的发送速率确定），以响应传入反馈数据包。在这种情况下，粗调度粒度不会显著降低发送速率，但发送速率将是突发性的，响应于每个反馈数据包发送数据的往返时间。
However, performance would be different, in this case, if the operating system scheduling granularity affected the sender's response to feedback packets as well as the general scheduling of the sender. In this case, the sender's performance would be severely limited by the scheduling granularity being greater than the round-trip time, with the sender able to send an RTT of data, at the allowed sending rate, at most once every 1 ms. This restriction of the sending rate is an unavoidable consequence of allowing burstiness of at most a round-trip time of data.
但是，在这种情况下，如果操作系统调度粒度影响发送方对反馈数据包的响应以及发送方的一般调度，则性能会有所不同。在这种情况下，发送方的性能将受到调度粒度大于往返时间的严重限制，发送方能够以允许的发送速率发送RTT数据，最多每1ms一次。发送速率的这种限制是允许最多数据往返时间突发的不可避免的结果。
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节中描述的可选历史贴现机制用于计算平均损失率。只有在间隔异常长且没有数据包丢失时，才会调用历史折扣机制。为了更有效地操作，贴现因子DF_i可以限制为2的幂。
This section summarizes the changes from RFC 3448. At a high level, the main change is to add mechanisms to address the case of a data-limited sender. This document also explicitly allows the TFRC sender to accumulate up to a round-trip time of unused send credits, and as a result to send a burst of packets if data arrives from the application in a burst after a data-limited period. This issue was not explicitly addressed in RFC 3448.
本节总结了RFC 3448的更改。在较高的层次上，主要的变化是添加机制来解决数据受限发送者的情况。本文档还明确允许TFRC发送方累积多达一个未使用发送信用的往返时间，因此，如果数据在数据限制期后以突发方式从应用程序到达，则发送突发数据包。RFC 3448中未明确说明此问题。
This document changes RFC 3448 to incorporate TCP's higher initial sending rates from RFC 3390. This document also changes RFC 3448 to allow RFC 4342's use of a coarse-grained timestamp on data packets instead of a more fine-grained timestamp.
本文档将RFC 3448更改为包含来自RFC 3390的TCP较高初始发送速率。本文档还更改了RFC 3448，以允许RFC 4342在数据包上使用粗粒度时间戳，而不是更细粒度的时间戳。
Other changes address corner cases involving slow-start, the response when the first data packet is dropped, and the like. This document also incorporates the items in the RFC 3448 Errata.
其他改变处理涉及慢启动、第一个数据包被丢弃时的响应等的拐角情况。本文件还包含RFC 3448勘误表中的项目。
This section is non-normative; the normative text is in the cited sections.
本节不规范；规范性文本见引用章节。
Section 4.1, estimating the average segment size: Section 4.1 was modified to give a specific algorithm that could be used for estimating the average segment size.
第4.1节，估计平均分段大小：对第4.1节进行了修改，以给出可用于估计平均分段大小的特定算法。
Section 4.2, update to the initial sending rate: In RFC 3448, the initial sending rate was two packets per round-trip time. In this document, the initial sending rate can be as high as four packets per round-trip time, following RFC 3390. The initial sending rate was changed to be in terms of the segment size s, not in terms of the MSS.
第4.2节，初始发送速率的更新：在RFC 3448中，初始发送速率为每往返时间两个数据包。在本文档中，初始发送速率可高达RFC 3390之后的每往返时间四个数据包。初始发送速率已更改为以段大小s为单位，而不是以MSS为单位。
Section 4.2 now says that tld, the Time Last Doubled during slow-start, can be initialized to either 0 or to -1. Section 4.2 was also clarified to say that RTT measurements do not only come from feedback packets; they could also come from other places, such as the SYN exchange.
第4.2节现在指出，tld（慢启动期间最后一次加倍的时间）可以初始化为0或-1。第4.2节还澄清了RTT测量不只是来自反馈数据包；它们也可能来自其他地方，例如SYN交换。
Section 4.3, response to feedback packets: Section 4.3 was modified to change the way that the receive rate is used in limiting the sender's allowed sending rate, by using the set of receive rate values of the last two round-trip times, and initializing the set of receive rate values by a large value.
第4.3节，对反馈数据包的响应：对第4.3节进行了修改，通过使用最后两个往返时间的接收速率值集，并将接收速率值集初始化为一个较大的值，来改变接收速率用于限制发送方允许的发送速率的方式。
The larger initial sending rate in Section 4.2 is of little use if the receiver sends a feedback packet after the first packet is received, and the sender, in response, reduces the allowed sending rate to at most two packets per RTT, which would be twice the receive rate. Because of the change in the sender's processing of the receive rate, the sender now does not reduce the allowed sending rate to twice the reported receive rate in response to the first feedback packet.
如果接收方在收到第一个数据包后发送反馈数据包，并且发送方相应地将允许的发送速率降低到每个RTT最多两个数据包，则第4.2节中较大的初始发送速率几乎没有用处，这将是接收速率的两倍。由于发送方对接收速率的处理发生了变化，发送方现在不会响应第一个反馈数据包，将允许的发送速率降低到报告接收速率的两倍。
During a data-limited period, the sender saves the receive rate reported from just before the data-limited period, if it is larger than the receive rate during the data-limited period. The sender also reduces the saved values in X_recv_set in response to a loss during a data-limited period. Appendix C discusses this response further.
在数据限制期内，如果接收速率大于数据限制期内的接收速率，则发送方保存在数据限制期之前报告的接收速率。发送方还减少X_recv_集合中保存的值，以响应数据有限期间的丢失。附录C进一步讨论了这一回应。
Section 4.4, response to an idle period: Following Section 5.1 from [RFC4342], this document specifies that when the sending rate is reduced after an idle period that covers the period since the nofeedback timer was set, the allowed sending rate is not reduced below the initial sending rate. (In Section 4.4, the variable recover_rate is set to the initial sending rate.)
第4.4节，对空闲时间段的响应：根据[RFC4342]第5.1节，本文件规定，当空闲时间段（涵盖自设置无反馈定时器以来的时间段）后发送速率降低时，允许的发送速率不会降低到初始发送速率以下。（在第4.4节中，可变恢复速率设置为初始发送速率。）
Section 4.4, correction from [RFC3448Err]. RFC 3448 had contradictory text about whether the sender halved its sending rate after *two* round-trip times without receiving a feedback report, or after *four* round-trip times. This document clarifies that the sender halves its sending rate after four round-trip times without receiving a feedback report [RFC3448Err].
第4.4节，来自[RFC3448Err]的修正。RFC 3448有一个矛盾的文本，关于发送者是在没有收到反馈报告的*两*次往返时间之后，还是在*四*次往返时间之后，将其发送速率减半。本文件阐明，发送方在四次往返后，在未收到反馈报告的情况下，将发送速率减半[RFC3448Err]。
Section 4.4, clarification for slow-start: Section 4.4 was clarified to specify that on the expiration of the nofeedback timer, if p = 0, X_Bps cannot be used, because the sender does not yet have a value for X_Bps. Section 4.4 was also clarified to check the case when the sender does not yet have an RTT sample, but has sent a packet since the nofeedback timer was set.
第4.4节，慢启动说明：第4.4节说明了在nofeedback计时器到期时，如果p=0，则无法使用X_Bps，因为发送方尚未具有X_Bps的值。还澄清了第4.4节，以检查发送方尚未收到RTT样本，但自设置了NOFEEDING定时器后已发送数据包的情况。
Section 4.6: credits for unused send time:
第4.6节：未使用发送时间的积分：
Section 4.6 has been clarified to say that the TFRC sender gets to accumulate up to an RTT of credits for unused send time. Section 4.6 was also rewritten to clarify what is specification and what is implementation.
第4.6节已经澄清，TFRC发送方可以在未使用的发送时间内累积多达RTT的信用。第4.6节也被改写，以澄清什么是规范，什么是实施。
Section 5.4, clarification: Section 5.4 was modified to clarify the receiver's calculation of the average loss interval when the receiver has not yet seen n loss intervals.
第5.4节，澄清：对第5.4节进行了修改，以澄清当接收方尚未看到n个损失间隔时，接收方对平均损失间隔的计算。
Section 5.5, correction: Section 5.5 was corrected to say that the loss interval I_0 includes all transmitted packets, including lost and marked packets (as defined in Section 5.3 in the general definition of loss intervals).
第5.5节，更正：第5.5节被更正为丢失间隔I_0包括所有传输的数据包，包括丢失和标记的数据包（如丢失间隔的一般定义中第5.3节所定义）。
Section 5.5, correction from [RFC3448Err]: A line in Section 5.5 was changed from
第5.5节，修正自[RFC3448Err]：第5.5节中的一行已从
for (i = 1 to n) { DF_i = 1; }
for (i = 1 to n) { DF_i = 1; }
to
到
for (i = 0 to n) { DF_i = 1; }
for (i = 0 to n) { DF_i = 1; }
[RFC3448Err].
[RFC3448Err]。
Section 5.5, history discounting: THRESHOLD, the lower bound on the history discounting parameter DF, has been changed from 0.5 to 0.25, to allow more history discounting when the current interval is long.
第5.5节，历史贴现：阈值，历史贴现参数DF的下限，已从0.5更改为0.25，以允许在当前间隔较长时进行更多的历史贴现。
Section 6, multiple feedback packets: Section 6 now contains more discussion of procedures if the receiver sends multiple feedback packets each round-trip time.
第6节，多个反馈数据包：第6节现在包含更多关于如果接收者每次往返发送多个反馈数据包的过程的讨论。
Section 6.3, initialization of the feedback timer: Section 6.3 now specifies the receiver's initialization of the feedback timer if the first data packet received does not have an estimate of the round-trip time.
第6.3节，反馈定时器的初始化：如果接收到的第一个数据包没有对往返时间的估计，则第6.3节现在规定接收器对反馈定时器的初始化。
Section 6.3, a coarse-grained timestamp: Section 6.3 was modified to incorporate, as an option, a coarse-grained timestamp from the sender that increments every quarter of a round-trip time, instead of a more fine-grained timestamp. This follows RFC 4342.
第6.3节，粗粒度时间戳：对第6.3节进行了修改，将发送方的粗粒度时间戳（每四分之一往返时间递增一次）作为一个选项，而不是更细粒度的时间戳。这遵循RFC 4342。
Section 6.3.1, after the first loss event: Section 6.3.1 now says that for initializing the loss history after the first loss event, the receiver uses the maximum receive rate so far, instead of the receive rate in the last round-trip time.
第6.3.1节，在第一次丢失事件之后：第6.3.1节现在说，为了在第一次丢失事件之后初始化丢失历史，接收器使用迄今为止的最大接收速率，而不是上一次往返时间的接收速率。
Section 6.3.1, if the first data packet is dropped: Section 6.3.1 now contains a specification for initializing the loss history if the first data packet sent is lost or ECN-marked.
第6.3.1节，如果第一个数据包丢失：第6.3.1节现在包含一个规范，用于在发送的第一个数据包丢失或标记ECN时初始化丢失历史记录。
Section 7, sender-based variants: Section 7's discussion of sender-based variants has been expanded, with reference to RFC 4342.
第7节，基于发送者的变体：第7节对基于发送者的变体的讨论已经扩展，参考RFC 4342。
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.
此外，拥塞控制机制可能被贪婪的接收者操纵，而贪婪的接收者希望接收超过其公平的网络带宽份额。接收者可以通过声称已经收到实际上由于拥塞而丢失的数据包来实现这一点。针对此类接收者的可能抗辩通常包括接收者必须反馈给发送者以证明其收到的某种形式的临时通知。然而，这种nonce的细节将取决于传输协议，特别是取决于传输协议是可靠的还是不可靠的。
We expect that protocols incorporating ECN with TFRC will also want to incorporate feedback from the receiver to the sender using the ECN nonce [RFC3540]. 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[RFC3540]从接收器到发送器的反馈。ECN nonce是对ECN的一种修改，可保护发送方免受意外或恶意隐藏标记数据包的影响。同样，这种临时状态的细节将取决于传输协议，本文档中没有涉及。
TFRC is currently used in Congestion Control ID 3 (CCID 3) [RFC4342] of the Datagram Congestion Control Protocol (DCCP) [RFC4340]. The Security Considerations section of RFC 4340 [RFC4340] (Section 18) discusses some of the security issues of DCCP, including sequence number validity checks to protect against hijacked connections. Section 18 of RFC 4340 also discusses mechanisms in DCCP to limit the potential impact of denial-of-service attacks.
TFRC目前用于数据报拥塞控制协议（DCCP）[RFC4340]的拥塞控制ID 3（CCID 3）[RFC4342]。RFC 4340[RFC4340]（第18节）的安全注意事项部分讨论了DCCP的一些安全问题，包括防止连接被劫持的序列号有效性检查。RFC 4340第18节还讨论了DCCP中限制拒绝服务攻击潜在影响的机制。
RFC 4342 specifies the use of TFRC in CCID 3. RFC 4342 includes extensive discussions of the mechanisms the sender can use to verify the information sent by the receiver. When ECN is used with CCID 3, the receiver returns ECN Nonce information to the sender, to allow the sender to verify information sent by the receiver. When ECN is not used, Section 9 of RFC 4342 discusses how the sender could still use various techniques that might catch the receiver in an error in reporting congestion. However, as stated in RFC 4342, this is not as robust or non-intrusive as the verification provided by the ECN Nonce.
RFC 4342规定了在CCID 3中使用TFRC。RFC 4342包括发送方可用于验证接收方发送的信息的机制的广泛讨论。当ECN与CCID 3一起使用时，接收方将ECN Nonce信息返回给发送方，以允许发送方验证接收方发送的信息。当不使用ECN时，RFC 4342的第9节讨论了发送方如何仍然可以使用各种技术来捕获接收方在报告拥塞时的错误。然而，如RFC 4342所述，这不像ECN Nonce提供的验证那样可靠或非侵入性。
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 Dado Colussi, Gorry Fairhurst, Ladan Gharai, Wim Heirman, Eddie Kohler, Ken Lofgren, Mike Luby, Ian McDonald, Vladimir Moltchanov, Colin Perkins, Michele R., Gerrit Renker, Arjuna Sathiaseelan, Vladica Stanisic, Randall Stewart, Eduardo Urzaiz, 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 [RFC3448] to produce a working implementation.
我们希望与包括可靠多播研究组、可靠多播传输工作组和端到端研究组成员在内的广泛人群就基于等式的拥塞控制进行反馈和讨论。我们要感谢达多·科鲁西、戈里·费尔赫斯特、拉丹·加莱、维姆·赫曼、埃迪·科勒、肯·洛夫格伦、迈克·鲁比、伊恩·麦克唐纳、弗拉基米尔·莫尔切诺夫、科林·帕金斯、米歇尔·R、格瑞特·伦克、阿朱纳·萨蒂亚希兰、弗拉迪卡·斯坦尼西奇、兰德尔·斯图尔特、爱德华多·乌尔扎兹、文书山和温迪·李(lhh@zsu.edu.cn)对于本文档早期版本的反馈，并感谢Mark Allman通过使用[RFC3448]生成工作实现所提供的广泛反馈。
This document uses the following terms. Timer variables (e.g., t_now, tld) are assumed to be in seconds, with a timer resolution of at least a millisecond.
本文件使用以下术语。定时器变量（例如，t_now、tld）假定为秒，定时器分辨率至少为毫秒。
data-limited interval: An interval where the sender is data-limited (not sending as much as it is allowed to send) over the entire interval (Section 4.3).
数据限制间隔：发送方在整个间隔内受数据限制的间隔（不发送允许发送的数据量）（第4.3节）。
DF: Discount factor for a loss interval (Section 5.5).
DF：损失间隔的贴现系数（第5.5节）。
initial_rate: Allowed initial sending rate.
初始发送速率：允许的初始发送速率。
last_counter: Greatest received value of the window counter (Section 6.3).
last_计数器：窗口计数器的最大接收值（第6.3节）。
n: Number of loss intervals.
n：丢失间隔的数量。
NDUPACK: Number of dupacks for inferring loss (constant) (Section 5.1).
NDUPACK：用于推断损失的DUPACK数（常数）（第5.1节）。
nofeedback timer: Sender-side timer (Section 4).
无反馈定时器：发送方端定时器（第4节）。
p: Estimated Loss Event Rate.
p：估计损失事件率。
p_prev: Previous value of p (Section 6.1).
p_prev：p的先前值（第6.1节）。
q: Filter constant for RTT (constant) (Section 4.3).
q:RTT的过滤器常数（常数）（第4.3节）。
q2: Filter constant for long-term RTT (constant) (Section 4.6).
q2：长期RTT的过滤器常数（常数）（第4.6节）。
R: Estimated path round-trip time.
R：估计路径往返时间。
R_m: A specific estimate of the path round-trip time (Sections 4.3, 6).
R_m：路径往返时间的具体估计（第4.3、6节）。
R_sample: Measured path RTT (Section 4.3).
R_样本：测量路径RTT（第4.3节）。
R_sqmean: Long-term estimate of the square root of the RTT (Section 4.6).
R_sqmean：RTT平方根的长期估计（第4.6节）。
recover_rate: Allowed rate for resuming after an idle period (Section 4.4).
恢复速率：空闲期后恢复的允许速率（第4.4节）。
recv_limit; Limit on sending rate computed from X_recv_set (Section 4.3).
回收限额；根据X_recv_集合计算的发送速率限制（第4.3节）。
s: Nominal packet size in bytes.
s：以字节为单位的标称数据包大小。
S: Sequence number.
序列号。
t_delay: Reported time delay between receipt of the last packet at the receiver and the generation of the feedback packet (Section 3.2.2).
t_延迟：在接收器接收到最后一个数据包和生成反馈数据包之间的报告时间延迟（第3.2.2节）。
t_delta: Parameter for flexibility in send time (Section 8.3).
t_delta：发送时间灵活性参数（第8.3节）。
t_gran: Scheduling timer granularity of the operating system (constant) (Section 8.3).
t_gran：操作系统的调度计时器粒度（常数）（第8.3节）。
t_ipi: Inter-packet interval for sending packets (Section 4.6).
t_ipi：发送数据包的数据包间隔（第4.6节）。
t_mbi: Maximum RTO value of TCP (constant) (Section 4.3).
t_mbi：TCP的最大RTO值（常数）（第4.3节）。
t_recvdata: Timestamp of the last data packet received (Section 3.2.2).
t_recvdata：接收到的最后一个数据包的时间戳（第3.2.2节）。
timer_limit: Limit on the sending rate from the expiration of the nofeedback timer (Section 4.4).
timer_limit：从nofeedback定时器到期起对发送速率的限制（第4.4节）。
tld: Time Last Doubled (Section 4.2).
tld：上次加倍的时间（第4.2节）。
t_now: Current time (Section 4.3).
现在：当前时间（第4.3节）。
t_RTO: Estimated RTO of TCP (Section 4.3).
t_RTO：TCP的估计RTO（第4.3节）。
X: Allowed transmit rate, as limited by the receive rate.
X：允许的传输速率，受接收速率限制。
X_Bps: Calculated sending rate in bytes per second (Section 3.1).
X_Bps：以字节/秒为单位计算的发送速率（第3.1节）。
X_pps: Calculated sending rate in packets per second (Section 3.1).
X_pps：以每秒数据包为单位的计算发送速率（第3.1节）。
X_inst: Instantaneous allowed transmit rate (Section 4.6).
X_inst：瞬时允许传输速率（第4.6节）。
X_recv: Estimated receive rate at the receiver (Section 3.2.2).
X_recv：接收机处的估计接收速率（第3.2.2节）。
X_recv_set: A small set of recent X_recv values (Section 4.3).
X_recv_集：一组最近的X_recv值（第4.3节）。
X_target: The target sending rate after the first loss event (Section 6.3.1).
X_目标：第一次丢失事件后的目标发送速率（第6.3.1节）。
W_init: TCP initial window (constant) (Section 4.2).
W_init:TCP初始窗口（常数）（第4.2节）。
Why is the initial value of TFRC's nofeedback timer set to two seconds, instead of the recommended initial value of three seconds for TCP's retransmit timer, from [RFC2988]? There is not any particular reason why TFRC's nofeedback timer should have the same initial value as TCP's retransmit timer. TCP's retransmit timer is used not only to reduce the sending rate in response to congestion, but also to retransmit a packet that is assumed to have been dropped in the network. In contrast, TFRC's nofeedback timer is only used to reduce the allowed sending rate, not to trigger the sending of a new packet. As a result, there is no danger to the network for the initial value of TFRC's nofeedback timer to be smaller than the recommended initial value for TCP's retransmit timer.
为什么TFRC的nofeedback计时器的初始值设置为2秒，而不是[RFC2988]中TCP的重传计时器的建议初始值3秒？TFRC的nofeedback计时器应该与TCP的重传计时器具有相同的初始值，这没有任何特殊原因。TCP的重传计时器不仅用于降低响应拥塞的发送速率，还用于重传假定已在网络中丢弃的数据包。相比之下，TFRC的nofeedback计时器仅用于降低允许的发送速率，而不是触发新数据包的发送。因此，TFRC的nofeedback timer的初始值小于TCP的重新传输计时器的建议初始值对网络没有危险。
Further, when the nofeedback timer has not yet expired, TFRC has a more slowly responding congestion control mechanism than TCP, and TFRC's use of the receive rate for limiting the sending rate is somewhat less precise than TCP's use of windows and ack-clocking, so the nofeedback timer is a particularly important safety mechanism for TFRC. For all of these reasons, it is perfectly reasonable for TFRC's nofeedback timer to have a smaller initial value than that of TCP's retransmit timer.
此外，当nofeedback计时器尚未过期时，TFRC具有比TCP更慢的响应拥塞控制机制，并且TFRC使用接收速率来限制发送速率的精度略低于TCP使用窗口和ack时钟的精度，因此nofeedback计时器是TFRC特别重要的安全机制。由于所有这些原因，TFRC的nofeedback计时器的初始值比TCP的重传计时器的初始值小是完全合理的。
Future work could explore alternate responses to using the receive rate during a data-limited period, and to responding to a loss event during a data-limited period.
未来的工作可以探索在数据有限期内使用接收速率和在数据有限期内响应丢失事件的替代响应。
In particular, an Experimental RFC [RFC2861] specifies Congestion Window Validation (CWV) for TCP. For this discussion, we use the term "Standard TCP" to refer to the TCP congestion control mechanisms in [RFC2581] and [RFC2581bis]. [RFC2861] specifies a different response to idle or data-limited periods than those of Standard TCP. With CWV, the TCP sender halves the congestion window after each RTO during an idle period, down to the initial window. Similarly, with CWV the TCP sender halves the congestion window half-way down to the flight size after each RTO during a data-limited period.
特别是，实验性RFC[RFC2861]指定TCP的拥塞窗口验证（CWV）。在本讨论中，我们使用术语“标准TCP”来指代[RFC2581]和[RFC2581bis]中的TCP拥塞控制机制。[RFC2861]指定与标准TCP不同的对空闲或数据受限时间段的响应。在CWV中，TCP发送方在空闲期间的每个RTO之后将拥塞窗口减半，直至初始窗口。类似地，对于CWV，TCP发送方在数据有限期内每次RTO后将拥塞窗口减半至航班大小的一半。
This document already specifies a TFRC response to idle periods that is similar to that of TCP with Congestion Window Validation. However, this document does not specify a TFRC response to data-limited periods similar to that of CWV. Adding such a mechanism to TFRC would require a one-line change to step (4) of Section 4.3. In particular, the sender's response to a feedback packet could be changed from:
本文档已经指定了对空闲时段的TFRC响应，该响应类似于TCP拥塞窗口验证。然而，本文件并未规定TFRC对数据有限期的响应，类似于CWV的响应。将这种机制添加到TFRC需要对第4.3节的步骤（4）进行一行更改。具体而言，发送方对反馈数据包的响应可以从：
If (the entire interval covered by the feedback packet
was a data-limited interval) {
If (the feedback packet reports a new loss event or an
increase in the loss event rate p) {
Halve entries in X_recv_set;
X_recv = 0.85 * X_recv;
Maximize X_recv_set();
recv_limit = max (X_recv_set);
} Else {
Maximize X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
}
If (the entire interval covered by the feedback packet
was a data-limited interval) {
If (the feedback packet reports a new loss event or an
increase in the loss event rate p) {
Halve entries in X_recv_set;
X_recv = 0.85 * X_recv;
Maximize X_recv_set();
recv_limit = max (X_recv_set);
} Else {
Maximize X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
}
to:
致：
If (the entire interval covered by the feedback packet
was a data-limited interval) {
Multiply old entries in X_recv_set by 0.85;
If (the feedback packet reports a new loss event or an
increase in the loss event rate p) {
Multiply new value X_recv by 0.85.
}
Maximize X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
If (the entire interval covered by the feedback packet
was a data-limited interval) {
Multiply old entries in X_recv_set by 0.85;
If (the feedback packet reports a new loss event or an
increase in the loss event rate p) {
Multiply new value X_recv by 0.85.
}
Maximize X_recv_set();
recv_limit = 2 * max (X_recv_set);
}
In particular, if the receive rate from before a data-limited period is saved in X_recv_set, then the change in step (4) above would multiply that receive rate by 0.85 each time that a feedback packet is received and the above code is executed. As a result, after four successive round-trip times of data-limited intervals, the receive rate from before the data-limited period would be reduced by 0.85^4 = 0.52. Thus, this one-line change to step (4) of Section 4.3 would result in the allowed sending rate being halved for each four roundtrip times in which the sender was data-limited. Because of the nature of X_recv_set, this mechanism would never reduce the allowed sending rate below twice the most recent receive rate.
特别地，如果在X_recv_集合中保存了来自数据限制时段之前的接收速率，则上述步骤（4）中的更改将在每次接收到反馈分组并且执行上述代码时将该接收速率乘以0.85。因此，在连续四次往返数据限制时间间隔之后，数据限制时间之前的接收速率将减少0.85^4=0.52。因此，将这一行更改为第4.3节的步骤（4），将导致允许的发送速率在发送方数据受限的每四次往返时间中减半。由于X_recv_set的性质，此机制不会将允许的发送速率降低到最近接收速率的两倍以下。
We note that in the suggested code above, with CWV-style behavior in response to data-limited intervals, we keep
我们注意到，在上面建议的代码中，使用CWV风格的行为来响应有限的数据间隔，我们保持
recv_limit = 2 * max (X_recv_set);
recv_limit = 2 * max (X_recv_set);
instead of using
而不是使用
recv_limit = max (X_recv_set);
recv_limit=最大值（X_recv_集）；
following loss events in data-limited intervals. This relaxed response to a loss event is allowed because the CWV-style behavior itself limits rapid fluctuations in the sending rate during data-limited periods.
在数据有限的时间间隔内跟踪丢失事件。这种对丢失事件的放松响应是允许的，因为CWV风格的行为本身限制了数据有限期间发送速率的快速波动。
Table 1 summarizes the response of Standard TCP [RFC2581], TCP with Congestion Window Validation [RFC2861], Standard TFRC [RFC3448], and Revised TFRC (this document) in response to long idle or data-limited periods. For the purposes of this section, we define a long period as a period of at least an RTO.
表1总结了标准TCP[RFC2581]、带拥塞窗口验证的TCP[RFC2861]、标准TFRC[RFC3448]和修订的TFRC（本文件）对长空闲或数据受限周期的响应。在本节中，我们将长周期定义为至少一个RTO的周期。
Protocol Long idle periods Long data-limited periods
-------------- -------------------- ----------------------
Standard TCP: Window -> initial. Window increases for
each cwnd of data.
Protocol Long idle periods Long data-limited periods
-------------- -------------------- ----------------------
Standard TCP: Window -> initial. Window increases for
each cwnd of data.
TCP with CWV: Halve window Reduce window half way (not below initial cwnd). to used window.
带CWV的TCP：将窗口减半将窗口减半（不低于初始cwnd）。用过的窗户。
Standard TFRC: Halve rate Rate limited to (not below 2 pkts/rtt). twice receive rate. One RTT after sending pkt, rate is limited by X_recv.
标准TFRC：减半费率限制为（不低于2件/rtt）。两倍的接收率。发送pkt后一次RTT，速率受X_recv限制。
Revised TFRC: Halve rate Rate limited to twice (not below initial rate). max (current X_recv, receive rate before data-limited period).
修订的TFRC：减半费率，限两次（不低于初始费率）。最大值（当前X_recv，数据限制期前的接收速率）。
Table 1: Response to Long Idle or Data-Limited Periods
表1：对长空闲或数据受限周期的响应
Standard TCP after long idle periods: For Standard TCP, [RFC2581] specifies that TCP SHOULD set the congestion window to no more than the initial window after an idle period of at least an RTO. (To be precise, RFC 2581 specifies that the TCP sender should set cwnd to the initial window if the sender has not sent data in an interval exceeding the retransmission timeout.)
长空闲期后的标准TCP：对于标准TCP，[RFC2581]指定TCP应在至少一个RTO的空闲期后将拥塞窗口设置为不超过初始窗口。（确切地说，RFC 2581规定，如果发送方未在超过重传超时的时间间隔内发送数据，则TCP发送方应将cwnd设置为初始窗口。）
Standard TCP after long data-limited periods: Standard TCP [RFC2581] does not reduce TCP's congestion window after a data-limited period, when the congestion window is not fully used. Standard TCP in [RFC2581] uses the FlightSize, the amount of outstanding data in the network, only in setting the slow-start threshold after a retransmit timeout. Standard TCP is not limited by TCP's ack-clocking mechanism during a data-limited period.
长数据限制期后的标准TCP：当拥塞窗口未完全使用时，标准TCP[RFC2581]在数据限制期后不会减少TCP的拥塞窗口。[RFC2581]中的标准TCP仅在重新传输超时后设置慢启动阈值时使用FlightSize，即网络中未完成的数据量。在数据受限期间，标准TCP不受TCP的ack时钟机制的限制。
Standard TCP's lax response to a data-limited period is quite different from its stringent response to an idle period.
标准TCP对数据有限期的宽松响应与对空闲期的严格响应大不相同。
TCP with Congestion Window Validation (CWV) after long idle periods: As an experimental alternative, [RFC2861] specifies a more moderate response to an idle period than that of Standard TCP, where during an idle period the TCP sender halves cwnd after each RTO, down to the initial cwnd.
长空闲期后使用拥塞窗口验证（CWV）的TCP：作为一种实验替代方案，[RFC2861]指定对空闲期的响应比标准TCP更温和，在空闲期内，TCP发送方在每个RTO后将cwnd减半，直至初始cwnd。
TCP with Congestion Window Validation after long data-limited periods: As an experimental alternative, [RFC2861] specifies a more stringent response to a data-limited period than that of Standard TCP, where after each RTO seconds of a data-limited period, the
在长数据限制期后使用拥塞窗口验证的TCP：作为一种实验替代方案，[RFC2861]指定了比标准TCP更严格的对数据限制期的响应，其中在数据限制期的每个RTO秒后
congestion window is reduced half way down to the window that is actually used.
拥塞窗口减少到实际使用窗口的一半。
The response of TCP with CWV to an idle period is similar to its response to a data-limited period. TCP with CWV is less restrictive than Standard TCP in response to an idle period, and more restrictive than Standard TCP in response to a data-limited period.
带有CWV的TCP对空闲时间段的响应类似于对数据有限时间段的响应。与标准TCP相比，带有CWV的TCP对空闲时间段的限制更小，而对数据有限时间段的限制更大。
Standard TFRC after long idle periods: For Standard TFRC, [RFC3448] specifies that the allowed sending rate is halved after each RTO seconds of an idle period. The allowed sending rate is not reduced below two packets per RTT after idle periods. After an idle period, the first feedback packet received reports a receive rate of one packet per round-trip time, and this receive rate is used to limit the sending rate. Standard TFRC effectively slow-starts up from this allowed sending rate.
长空闲期后的标准TFRC：对于标准TFRC，[RFC3448]指定在空闲期的每个RTO秒后，允许的发送速率减半。空闲期后，允许的发送速率不会降低到每RTT两个数据包以下。在空闲时段之后，接收到的第一反馈分组报告每往返时间一个分组的接收速率，并且该接收速率用于限制发送速率。标准TFRC有效地降低了从该允许发送速率启动的速度。
Standard TFRC after long data-limited periods: [RFC3448] does not distinguish between data-limited and non-data-limited periods. As a consequence, the allowed sending rate is limited to at most twice the receive rate during and after a data-limited period. This is a very restrictive response, more restrictive than that of either Standard TCP or of TCP with CWV.
长数据限制期后的标准TFRC:[RFC3448]不区分数据限制期和非数据限制期。因此，在数据限制期间和之后，允许的发送速率最多限制为接收速率的两倍。这是一个非常严格的响应，比标准TCP或带有CWV的TCP的响应更严格。
Revised TFRC after long idle periods: For Revised TFRC, this document specifies that the allowed sending rate is halved after each RTO seconds of an idle period. The allowed sending rate is not reduced below the initial sending rate as the result of an idle period. The first feedback packet received after the idle period reports a receive rate of one packet per round-trip time. However, the Revised TFRC sender does not use this receive rate for limiting the sending rate. Thus, Revised TFRC differs from Standard TFRC in the lower limit used in the reduction of the sending rate, and in the better response to the first feedback packet received after the idle period.
长空闲期后修订的TFRC：对于修订的TFRC，本文档规定在空闲期的每个RTO秒后，允许的发送速率减半。允许的发送速率不会因空闲时间而降低到初始发送速率以下。在空闲时段之后接收的第一反馈分组报告每往返时间一个分组的接收速率。但是，修改后的TFRC发送方不使用此接收速率来限制发送速率。因此，修正后的TFRC与标准TFRC的不同之处在于用于降低发送速率的下限，以及对空闲时段之后接收到的第一反馈分组的更好响应。
Revised TFRC after long data-limited periods: For Revised TFRC, this document distinguishes between data-limited and non-data-limited periods. As specified in Section 4.3, during a data-limited period Revised TFRC remembers the receive rate before the data-limited period began, and does not reduce the allowed sending rate below twice that receive rate. This is somewhat similar to the response of Standard TCP, and is quite different from the very restrictive response of Standard TFRC to a data-limited period. However, the response of Revised TFRC is not as conservative as the response of TCP with Congestion Window Validation, where the congestion window is gradually reduced down to the window actually used during a data-limited period.
长期数据限制期后修订的TFRC：对于修订的TFRC，本文件区分数据限制期和非数据限制期。如第4.3节所述，在数据限制期内，修改后的TFRC会记住数据限制期开始前的接收速率，并且不会将允许的发送速率降低到该接收速率的两倍以下。这有点类似于标准TCP的响应，与标准TFRC对数据有限期的非常严格的响应截然不同。然而，修改后的TFRC的响应并不像TCP的响应那样具有拥塞窗口验证的保守性，在TCP的响应中，拥塞窗口逐渐减小到数据有限期内实际使用的窗口。
We note that for current TCP implementations, the congestion window is generally not increased during a data-limited period (when the current congestion window is not being fully used) [MAF05] (Section 5.7). We note that there is no mechanism comparable to this in Revised TFRC.
我们注意到，对于当前的TCP实施，拥塞窗口通常不会在数据有限期内增加（当前拥塞窗口未被完全使用）[MAF05]（第5.7节）。我们注意到，修订后的TFRC中没有类似的机制。
Recovery after idle or data-limited periods: When TCP reduces the congestion window after an idle or data-utilized period, TCP can set the slow-start threshold, ssthresh, to allow the TCP sender to slow-start back up towards its old sending rate when the idle or data-limited period is over. However, in TFRC, even when the TFRC sender's sending rate is restricted by twice the previous receive rate, this results in the sender being able to double the sending rate from one round-trip time to the next, if permitted by the throughput equation. Thus, TFRC does not need a mechanism such as TCP's setting of ssthresh to allow a slow-start after an idle or data-limited period.
空闲或数据限制期后的恢复：当TCP在空闲或数据使用期后减少拥塞窗口时，TCP可以设置慢启动阈值ssthresh，以允许TCP发送方在空闲或数据限制期结束时慢启动恢复到其旧的发送速率。然而，在TFRC中，即使TFRC发送方的发送速率受到前一个接收速率的两倍的限制，如果吞吐量方程允许，这也会导致发送方能够将发送速率从一个往返时间增加一倍。因此，TFRC不需要TCP设置ssthresh这样的机制来允许在空闲或数据受限时间后缓慢启动。
For future work, one avenue to explore would be the addition of Congestion Window Validation mechanisms for TFRC's response to data-limited periods. Currently, following Standard TCP, during data-limited periods Revised TFRC does not limit its allowed sending rate as a function of the receive rate.
对于未来的工作，一个需要探索的途径是为TFRC对数据有限期的响应增加拥塞窗口验证机制。目前，按照标准TCP，在数据有限期内，修订后的TFRC不会将其允许的发送速率限制为接收速率的函数。
Table 2 summarizes the response of Standard TCP [RFC2581], TCP with Congestion Window Validation [RFC2861], Standard TFRC [RFC3448], and Revised TFRC (this document) in response to short idle or data-limited periods. For the purposes of this section, we define a short period as a period of less than an RTT.
表2总结了标准TCP[RFC2581]、带拥塞窗口验证的TCP[RFC2861]、标准TFRC[RFC3448]和修订的TFRC（本文件）对短空闲或数据受限周期的响应。在本节中，我们将短周期定义为小于RTT的周期。
Protocol Short idle periods Short data-limited periods
-------------- -------------------- ----------------------
Standard TCP: Send a burst up to cwnd. Send a burst up to cwnd.
Protocol Short idle periods Short data-limited periods
-------------- -------------------- ----------------------
Standard TCP: Send a burst up to cwnd. Send a burst up to cwnd.
TCP with CWV: Send a burst up to cwnd. Send a burst up to cwnd.
带CWV的TCP：向cwnd发送突发消息。向cwnd发送突发消息。
Standard TFRC: ? ?
标准TFRC:？
Revised TFRC: Send a burst Send a burst (up to an RTT of (up to an RTT of unused send credits). unused send credits).
修订的TFRC：发送突发发送突发（最多RTT为（最多RTT为未使用的发送信用）。未使用的发送信用）。
Table 2: Response to Short Idle or Data-Limited Periods
表2：对短空闲或数据受限周期的响应
Table 2 shows that Revised TFRC has a similar response to that of Standard TCP and of TCP with CWV to a short idle or data-limited
表2显示，修改后的TFRC对短空闲或数据受限的响应与标准TCP和带有CWV的TCP相似
period. For a short idle or data-limited period, TCP is limited only by the size of the unused congestion window, and Revised TFRC is limited only by the number of unused send credits (up to an RTT's worth). For Standard TFRC, [RFC3448] did not explicitly specify the behavior with respect to unused send credits.
时期对于较短的空闲或数据受限期间，TCP仅受未使用的拥塞窗口大小的限制，而修订的TFRC仅受未使用的发送信用数的限制（达到RTT的价值）。对于标准TFRC，[RFC3448]没有明确指定与未使用的发送信用相关的行为。
Table 3 summarizes the response of Standard TCP [RFC2581], TCP with Congestion Window Validation [RFC2861], Standard TFRC [RFC3448], and Revised TFRC (this document) in response to moderate idle or data-limited periods. For the purposes of this section, we define a moderate period as a period greater than an RTT, but less than an RTO.
表3总结了标准TCP[RFC2581]、带有拥塞窗口验证的TCP[RFC2861]、标准TFRC[RFC3448]和修订的TFRC（本文件）对中等空闲或数据限制期的响应。在本节中，我们将中等期限定义为大于RTT但小于RTO的期限。
Protocol Moderate idle periods Moderate data-limited periods
------------- --------------------- -------------------------
Standard TCP: Send a burst up to cwnd. Send a burst up to cwnd.
Protocol Moderate idle periods Moderate data-limited periods
------------- --------------------- -------------------------
Standard TCP: Send a burst up to cwnd. Send a burst up to cwnd.
TCP with CWV: Send a burst up to cwnd. Send a burst up to cwnd.
带CWV的TCP：向cwnd发送突发消息。向cwnd发送突发消息。
Standard TFRC: ? Limited by X_recv.
标准TFRC:？受X_recv限制。
Revised TFRC: Send a burst Send a burst (up to an RTT of (up to an RTT of unused send credits). unused send credits).
修订的TFRC：发送突发发送突发（最多RTT为（最多RTT为未使用的发送信用）。未使用的发送信用）。
Table 3: Response to Moderate Idle or Data-Limited Periods
表3：对中等怠速或数据限制期的响应
Table 3 shows that Revised TFRC has a similar response to that of Standard TCP and of TCP with CWV to a moderate idle or data-limited period. For a moderate idle or data-limited period, TCP is limited only by the size of the unused congestion window. For a moderate idle period, Revised TFRC is limited only by the number of unused send credits (up to an RTT's worth). For a moderate data-limited period, Standard TFRC would be limited by X_recv from the most recent feedback packet. In contrast, Revised TFRC is not limited by the receive rate from data-limited periods that cover an entire feedback period of a round-trip time. For Standard TFRC, [RFC3448] did not explicitly specify the behavior with respect to unused send credits.
表3显示，修订后的TFRC与标准TCP和带有CWV的TCP在中等空闲或数据限制期间的响应类似。对于中等空闲或数据受限时间段，TCP仅受未使用拥塞窗口大小的限制。对于中等闲置期，修改后的TFRC仅受未使用发送信用的数量限制（最多为RTT的价值）。对于中等数据限制期，标准TFRC将受到来自最新反馈数据包的X_recv的限制。相比之下，修订后的TFRC不受数据有限期的接收速率的限制，该数据有限期涵盖往返时间的整个反馈期。对于标准TFRC，[RFC3448]没有明确指定与未使用的发送信用相关的行为。
This section discusses the response to a loss during a data-limited period.
本节讨论在数据有限期间对丢失的响应。
Protocol Response to a loss during a data-limited period
------------- -----------------------------------------------
Standard TCP: Set ssthresh, cwnd to FlightSize/2.
Protocol Response to a loss during a data-limited period
------------- -----------------------------------------------
Standard TCP: Set ssthresh, cwnd to FlightSize/2.
TCP with CWV: Same as Standard TCP.
带CWV的TCP：与标准TCP相同。
Standard TFRC: Calculate X_Bps, send at most 2*X_recv.
标准TFRC：计算X_Bps，最多发送2*X_recv。
Revised TFRC: Calculate X_Bps, send at most recv_limit. In addition, modify X_recv_set.
修订的TFRC：计算X_Bps，最多发送recv_限制。此外，修改X_recv_集。
Table 4: Response to a Loss during a Data-Limited Period
表4：数据有限期内对损失的响应
In TCP [RFC2581], the response to a loss during a data-limited period is the same as the response to a loss at any other time in TCP. This response is to set the congestion window to half of the FlightSize, where the FlightSize is the actual amount of unacknowledged data. Thus, after a loss during a data-limited period, the TCP sender must halve its allowed sending rate, as it normally does in response to a loss.
在TCP[RFC2581]中，在数据限制期间对丢失的响应与TCP中任何其他时间对丢失的响应相同。此响应将拥塞窗口设置为FlightSize的一半，其中FlightSize是未确认数据的实际数量。因此，在数据有限的时间内丢失数据后，TCP发送方必须将其允许的发送速率减半，就像它通常响应丢失时所做的那样。
In Standard TFRC, the response to a loss during a data-limited period is also the same as the response to a loss at any other time in Standard TFRC. The sending rate is limited by X_Bps, from the throughput equation, and the sending rate is also limited by twice X_recv, the most recent receive rate. As a result, after a loss in a data-limited period, the sender can at most double its sending rate to twice X_recv, even if the throughput equation X_Bps would allow a sending rate much higher than that.
在标准TFRC中，在数据有限期内对丢失的响应也与在标准TFRC中任何其他时间对丢失的响应相同。根据吞吐量方程，发送速率受X_Bps限制，发送速率也受X_recv（最近的接收速率）的两倍限制。因此，在数据有限期内丢失数据后，发送方最多可以将其发送速率加倍到两倍X_recv，即使吞吐量方程X_Bps允许发送速率远远高于此值。
In Revised TFRC, there have been changes to the use of the receive rate X_recv during data-limited intervals; the sender is limited to sending at most recv_limit, where the sender can remember the receive rate X_recv from just before the data-limited period. This allows the sender to more than double its sending rate during data-limited periods, up to the receive rate from before the data-limited period (if allowed by the throughput equation as given in X_Bps). This is similar to Standard TCP's practice of not reducing the window during data-limited periods (in the absence of loss).
在修订后的TFRC中，在数据有限的时间间隔内，接收速率X_recv的使用发生了变化；发送方最多只能发送recv_limit，发送方可以记住数据限制期之前的接收速率X_recv。这允许发送方在数据限制期间将其发送速率增加一倍以上，直至数据限制期间之前的接收速率（如果X_Bps中给出的吞吐量方程允许）。这类似于标准TCP的做法，即在数据有限期间（在没有丢失的情况下）不减少窗口。
As with Standard TFRC, during a data-limited period the Revised TFRC sender is sending less than is allowed by the throughput equation X_Bps. After the loss event, the sender still might not want to be
与标准TFRC一样，在数据有限期内，修改后的TFRC发送方发送的数据少于吞吐量方程X_Bps允许的数量。在丢失事件之后，发送方可能仍然不希望
sending as much as allowed by the recalculated value of X_Bps that takes into account the new loss event. Revised TFRC adds an additional mechanism to gradually limit the sender's sending rate after losses during data-limited periods. Unlike TCP's response of setting cwnd to half the FlightSize, this additional mechanism in Revised TFRC uses TFRC's practice of using slowly-responding changes for both increases and decreases in the allowed sending rate.
发送考虑到新损失事件的X_Bps的重新计算值所允许的数量。修改后的TFRC增加了一个额外的机制，在数据有限期内丢失后逐渐限制发送方的发送速率。与TCP将cwnd设置为FlightSize的一半的响应不同，修改后的TFRC中的这个附加机制使用了TFRC的做法，即对允许发送速率的增加和减少使用缓慢响应的更改。
This is done in Revised TFRC (in step (4) of Section 4.3) by decreasing the entry in X_recv_set after a loss in a data-limited interval, and by allowing the sender to send at most max (X_recv_set), instead of at most twice max (X_recv_set), in the immediate round-trip time following the reported loss. Thus, the 'price' for allowing the sender to send more than twice the most immediately reported value of X_recv during a data-limited interval is the introduction of an additional mechanism to reduce this allowed sending rate following losses in data-limited periods.
在修改后的TFRC（第4.3节第（4）步）中，通过在数据有限的时间间隔内丢失后减少X_recv_集合中的条目，并通过允许发送方在报告丢失后的立即往返时间内最多发送max（X_recv_集合），而不是最多发送两次max（X_recv_集合），可以实现这一点。因此，允许发送方在数据有限的时间间隔内发送两倍以上最立即报告的X_recv值的“价格”是引入一种额外的机制，以在数据有限的时间段内丢失后降低该允许发送率。
In TFRC's response to a loss in a data-limited interval, we have considered the following examples.
在TFRC对数据有限时间间隔内丢失的响应中，我们考虑了以下示例。
Example 1, Losses *after* a Data-Limited Period: This example shows that losses after a data-limited period has ended are addressed by the throughput equation X_Bps.
示例1，数据限制期后的损失*：该示例显示数据限制期结束后的损失由吞吐量方程X_Bps解决。
-------------------------------------------------------------------
Stage 1: Not data-limited.
Sending 100 packets per round-trip time (PPR).
Stage 2: Data-limited, sending 10 PPR.
Stage 3: Not data-limited.
Sending 100 PPR again, as allowed by X_Bps.
A packet loss in the first RTT of Stage 3.
X_Bps is updated,
Response of Revised TFRC: a slight reduction in the allowed sending
rate, depending on the number of packets since the last loss event.
-------------------------------------------------------------------
-------------------------------------------------------------------
Stage 1: Not data-limited.
Sending 100 packets per round-trip time (PPR).
Stage 2: Data-limited, sending 10 PPR.
Stage 3: Not data-limited.
Sending 100 PPR again, as allowed by X_Bps.
A packet loss in the first RTT of Stage 3.
X_Bps is updated,
Response of Revised TFRC: a slight reduction in the allowed sending
rate, depending on the number of packets since the last loss event.
-------------------------------------------------------------------
Table 5: Example 1, Losses after a Data-Limited Period
表5：示例1，数据有限期后的损失
For example 1, when there is a packet loss in the first RTT of Stage 3, this will be reflected in a modified value of X_Bps, and future loss events would result in future reductions of the throughput equation X_Bps. In particular, following TFRC's standard use of the throughput equation [FHPW00] (Section A.2), the allowed TFRC sending rate would be halved after something like five successive round-trip times with loss.
例如，当在阶段3的第一RTT中存在分组丢失时，这将反映在X_Bps的修改值中，并且未来的丢失事件将导致吞吐量等式X_Bps的未来减少。特别是，在TFRC标准使用吞吐量方程[FHPW00]（第A.2节）之后，允许的TFRC发送速率将在连续五次往返时间后减半。
Example 2, a Mildly Data-Limited Sender: This example considers losses in a data-limited period when, during the data-limited period, the sender is sending *almost* as much as it is allowed to send.
示例2，轻度数据限制的发送方：此示例考虑了数据限制期间的损失，在数据限制期间，发送方发送的*几乎*与允许发送的*相同。
-------------------------------------------------------------------
Stage 1: Not data-limited. Sending 100 PPR.
Stage 2: Data-limited, sending 99 PPR.
A packet loss in Stage 2.
Response of Revised TFRC: a slight reduction in the allowed sending
rate, down to 85 PPR or less, depending on the number of packets
since the last loss event.
-------------------------------------------------------------------
-------------------------------------------------------------------
Stage 1: Not data-limited. Sending 100 PPR.
Stage 2: Data-limited, sending 99 PPR.
A packet loss in Stage 2.
Response of Revised TFRC: a slight reduction in the allowed sending
rate, down to 85 PPR or less, depending on the number of packets
since the last loss event.
-------------------------------------------------------------------
Table 6: Example 2, a Mildly Data-Limited Sender
表6：示例2，轻度数据受限的发送方
Consider a Revised TFRC connection where the sender has been sending a hundred PPR and then enters a data-limited period of sending only 99 PPR because of data limitations from the application. (That is, at every instance of time during the data-limited period, the sender could have sent one more packet.) If there are losses in the data-limited period, the allowed sending rate is reduced to min(X_Bps, recv_limit), where both the throughput equation X_Bps and the limit recv_limit force a slight reduction in the allowed sending rate.
考虑修改后的TFRC连接，其中发送方已经发送一百PPR，然后由于应用程序的数据限制而进入仅发送99 PPR的数据限制期。（也就是说，在数据限制期内的每个时间实例中，发送方可能已经发送了一个以上的数据包。）如果在数据限制期内有丢失，则允许的发送速率降低到min（X_Bps，recv_limit），其中吞吐量方程X_Bps和限制recv_limit都会强制允许的发送速率略微降低。
Example 3, a Single Packet Loss during a Data-Limited Period. This example considers the loss of a single packet during a data-limited period, after the sender has not sent a packet for two RTTs.
示例3，在数据限制期间的单个分组丢失。此示例考虑在发送方未发送两个RTT的数据包之后，在数据限制期间单个数据包的丢失。
-------------------------------------------------------------------
Stage 1: Not data-limited. Sending 100 PPR.
Stage 2: Data-limited, sending 10 PPR.
Stage 3: Data-limited, sending no data for two RTTs.
Stage 4: Data-limited, sending one packet, which is ECN-marked.
Response of Revised TFRC: a reduction in the allowed sending
rate, down to 50 PPR or less. For each loss event during
the data-limited period, the 'remembered' X_recv from before
the data-limited period is effectively halved.
-------------------------------------------------------------------
-------------------------------------------------------------------
Stage 1: Not data-limited. Sending 100 PPR.
Stage 2: Data-limited, sending 10 PPR.
Stage 3: Data-limited, sending no data for two RTTs.
Stage 4: Data-limited, sending one packet, which is ECN-marked.
Response of Revised TFRC: a reduction in the allowed sending
rate, down to 50 PPR or less. For each loss event during
the data-limited period, the 'remembered' X_recv from before
the data-limited period is effectively halved.
-------------------------------------------------------------------
Table 7: Example 3, a Single Packet Loss
表7：示例3，单个数据包丢失
Consider a Revised TFRC connection where the sender has been sending a hundred PPR, and then enters a data-limited period of sending only ten PPR, and then does not send any packets for two RTTs, and then sends a single packet, which is ECN-marked. In this case, with Revised TFRC, for each loss event during the data-limited period, the sender halves its 'remembered' X_recv from before the data-limited period
考虑一个修改的TFRC连接，其中发送方已经发送了一百个PPR，然后进入仅发送十个PPR的数据限制期，然后不发送两个RTT的任何包，然后发送一个被ECN标记的数据包。在这种情况下，对于修改后的TFRC，对于数据限制期内的每个损失事件，发送方将其“记住的”X_recv从数据限制期之前减半
Example 4, Losses after Increasing the Sending Rate during a Data-Limited Period. This example considers losses when the sender significantly increases its sending rate during a data-limited period.
示例4，在数据限制期间增加发送速率后的损失。此示例考虑了当发送方在数据限制期间显著增加其发送速率时的损失。
-------------------------------------------------------------------
Stage 1: Not data-limited. Sending 100 PPR.
Stage 2: Data-limited, sending 1 PPR.
Stage 3: Data-limited, sending 20 PPR.
Several packets are lost in each RTT of Stage 3.
During Stage 3, the sender would *like* to send 20 PPR.
Response of Revised TFRC: For each loss event during
the data-limited period, the 'remembered' X_recv from before
the data-limited period is effectively halved, and the most
recent X_recv is reduced by 0.85.
-------------------------------------------------------------------
-------------------------------------------------------------------
Stage 1: Not data-limited. Sending 100 PPR.
Stage 2: Data-limited, sending 1 PPR.
Stage 3: Data-limited, sending 20 PPR.
Several packets are lost in each RTT of Stage 3.
During Stage 3, the sender would *like* to send 20 PPR.
Response of Revised TFRC: For each loss event during
the data-limited period, the 'remembered' X_recv from before
the data-limited period is effectively halved, and the most
recent X_recv is reduced by 0.85.
-------------------------------------------------------------------
Table 8: Example 4, Losses after Increasing the Sending Rate
表8：示例4，增加发送速率后的损失
Consider a Revised TFRC connection where the sender has been sending a hundred PPR, and then enters a data-limited period of sending only one PPR, and then, while still data-limited, increases its sending rate to twenty PPR, where it experiences a number of successive loss events.
考虑修改的TFRC连接，其中发送方已经发送一百个PPR，然后进入仅发送一个PPR的有限数据周期，然后，当仍然是数据限制时，将其发送速率提高到二十PPR，在那里它经历多个连续的丢失事件。
In this case, with Revised TFRC, for each loss event during the data-limited period, the sender halves its 'remembered' X_recv from before the data-limited period, and the most recent X_recv is reduced by 0.85.
在这种情况下，对于修改后的TFRC，对于数据限制期内的每个损失事件，发送方将其“记住的”X_recv从数据限制期之前减半，最近的X_recv减少0.85。
Other possible patterns to consider in evaluating Revised TFRC would be to compare the behavior of TCP, Standard TFRC, and Revised TFRC for connections with alternating busy and idle periods, alternating idle and data-limited periods, or with idle or data-limited periods during slow-start.
在评估修订后的TFRC中考虑的其他可能的模式将是比较TCP、标准TFRC和修改的TFRC的行为，用于与交替的繁忙和空闲周期的连接、交替空闲和数据受限的周期，或者在慢速启动期间具有空闲或数据受限的周期。
In this section we focus on evaluating Revised TFRC's response to idle or data-limited periods.
在本节中，我们将重点评估修订后的TFRC对闲置或数据有限期的响应。
One drawback to Standard TFRC's strict response to idle or data-limited periods is that it could be seen as encouraging applications to pad their sending rate during idle or data-limited periods, by sending dummy data when there was no other data to send. Because Revised TFRC has a less strict response to data-limited periods than
标准TFRC严格响应空闲或数据限制期间的一个缺点是，它可以被视为鼓励应用程序在空闲或数据限制期间提高发送速率，在没有其他数据可发送时发送虚拟数据。因为修订后的TFRC对数据有限期的响应不如
that of Standard TFRC, Revised TFRC also could be seen as giving applications less of an incentive to pad their sending rates during data-limited periods. Work in progress, such as Faster Restart [KFS07], can also decrease an application's incentive to pad its sending rate, by allowing faster start-up after idle periods. Further research would be useful to understand, in more detail, the interaction between TCP or TFRC's congestion control mechanisms, and an application's incentive to pad its sending rate during idle or data-limited periods.
与标准TFRC相比，修订后的TFRC也可以被视为减少了应用程序在数据有限期内提高发送速率的动机。正在进行的工作，例如更快的重新启动[KFS07]，也可以通过允许在空闲时间后更快地启动来降低应用程序增加发送速率的动机。进一步的研究将有助于更详细地了解TCP或TFRC拥塞控制机制之间的相互作用，以及应用程序在空闲或数据受限期间增加发送速率的动机。
TCP Congestion Window Validation, described in Appendix C.1 above, is an Experimental standard specifying that the TCP sender slowly reduces the congestion window during an idle or data-limited period [RFC2861]. While TFRC and Revised TFRC's responses to idle periods are roughly similar to those of TCP with Congestion Window Validation, Revised TFRC's response to data-limited periods is less conservative than those of TCP with Congestion Window Validation (and Standard TFRC's response to data-limited periods was considerably *more* conservative than those of Congestion Window Validation). Future work could include modifications to this document so that the response of Revised TFRC to a data-limited period includes a slow reduction of the allowed sending rate; Section C specifies a possible mechanism for this. Such a modification would be particularly compelling if Congestion Window Validation became a Proposed Standard in the IETF for TCP.
上文附录C.1中所述的TCP拥塞窗口验证是一项实验标准，规定TCP发送方在空闲或数据受限期间缓慢减少拥塞窗口[RFC2861]。虽然TFRC和修正后的TFRC对空闲时间段的响应与采用拥塞窗口验证的TCP大致相似，但修正后的TFRC对数据有限时间段的响应不如采用拥塞窗口验证的TCP保守（标准TFRC对数据有限期的响应比拥塞窗口验证的响应要保守得多）.未来的工作可能包括对本文件的修改，以便修改后的TFRC对数据有限期的响应包括允许发送速率的缓慢降低；C节规定了一种可能的机制。如果拥塞窗口验证成为IET中的拟议标准，则这种修改将特别引人注目F代表TCP。
References
工具书类
Normative References
规范性引用文件
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
Informative References
资料性引用
[BRS99] Balakrishnan, H., Rahul, H., and Seshan, S., "An Integrated Congestion Management Architecture for Internet Hosts," Proc. ACM SIGCOMM, Cambridge, MA, September 1999.
[BRS99]Balakrishnan，H.，Rahul，H.，和Seshan，S.，“互联网主机的集成拥塞管理架构”，Proc。ACM SIGCOMM，马萨诸塞州剑桥，1999年9月。
[CCID-4] Floyd, S., and E. Kohler, "Profile for DCCP Congestion Control ID 4: the Small-Packet Variant of TFRC Congestion Control", Work in Progress, February 2008.
[CCID-4]Floyd，S.和E.Kohler，“DCCP拥塞控制ID 4的配置文件：TFRC拥塞控制的小数据包变体”，正在进行的工作，2008年2月。
[FHPW00] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based Congestion Control for Unicast Applications", August 2000, Proc SIGCOMM 2000.
[FHPW00]S.Floyd，M.Handley，J.Padhye和J.Widmer，“单播应用中基于方程的拥塞控制”，2000年8月，Proc SIGCOMM 2000。
[FHPW00a] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based Congestion Control for Unicast Applications: the Extended Version", ICSI tech report TR-00-03, March 2000.
[FHPW00a]S.Floyd，M.Handley，J.Padhye和J.Widmer，“单播应用中基于方程的拥塞控制：扩展版本”，ICSI技术报告TR-00-032000年3月。
[FF99] Floyd, S., and K. Fall, Promoting the Use of End-to-End Congestion Control in the Internet, IEEE/ACM Transactions on Networking, August 1999.
[FF99]Floyd，S.和K.Fall，促进互联网中端到端拥塞控制的使用，IEEE/ACM网络事务，1999年8月。
[KFS07] E. Kohler, S. Floyd, and A. Sathiaseelan, "Faster Restart for TCP Friendly Rate Control (TFRC)", Work in Progress, November 2007.
[KFS07]E.Kohler，S.Floyd和A.Sathiaseelan，“TCP友好速率控制（TFRC）的更快重启”，正在进行的工作，2007年11月。
[MAF05] A. Medina, M. Allman, and S. Floyd, "Measuring the Evolution of Transport Protocols in the Internet", ACM Computer Communications Review, April 2005.
[MAF05]A.Medina，M.Allman和S.Floyd，“测量互联网传输协议的演变”，ACM计算机通信评论，2005年4月。
[PFTK98] Padhye, J. and Firoiu, V. and Towsley, D. and Kurose, J., "Modeling TCP Throughput: A Simple Model and its Empirical Validation", Proc ACM SIGCOMM 1998.
[PFTK98]Padhye，J.和Firoiu，V.和Towsley，D.和Kurose，J.，“TCP吞吐量建模：一个简单模型及其经验验证”，Proc ACM SIGCOMM 1998。
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[RFC2140]Touch，J.，“TCP控制块相互依赖”，RFC 2140，1997年4月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2581bis] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", Work in Progress, April 2008.
[RFC2581bis]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，正在进行的工作，2008年4月。
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861]Handley，M.，Padhye，J.，和S.Floyd，“TCP拥塞窗口验证”，RFC 28612000年6月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]奥尔曼，M.，弗洛伊德，S.，和C.帕特里奇，“增加TCP的初始窗口”，RFC3390，2002年10月。
[RFC3448Err] RFC 3448 Errata, <http://www.rfc-editor.org/errata_search.php./rfc3448>.
[RFC3448Err]RFC 3448勘误表<http://www.rfc-editor.org/errata_search.php./rfc3448>.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]Spring，N.，Weterral，D.，和D.Ely，“带有nonce的鲁棒显式拥塞通知（ECN）信令”，RFC 35402003年6月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006.
[RFC4342]Floyd，S.，Kohler，E.，和J.Padhye，“数据报拥塞控制协议（DCCP）拥塞控制ID 3的配置文件：TCP友好速率控制（TFRC）”，RFC 43422006年3月。
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007.
[RFC4828]Floyd，S.和E.Kohler，“TCP友好速率控制（TFRC）：小数据包（SP）变体”，RFC 48282007年4月。
[W00] Widmer, J., "Equation-Based Congestion Control", Diploma Thesis, University of Mannheim, February 2000, <http://www.icir.org/tfrc/>.
〔W00〕Widmer，J，“基于方程的拥塞控制”，毕业论文，曼海姆大学，2000年2月，<http://www.icir.org/tfrc/>.
Authors' Addresses
作者地址
Sally Floyd ICSI 1947 Center St, Suite 600 Berkeley, CA 94708 EMail: floyd@icir.org
Sally Floyd ICSI 1947加利福尼亚州伯克利中心大街600号套房94708电子邮件：floyd@icir.org
Mark Handley, Department of Computer Science University College London Gower Street London WC1E 6BT UK EMail: M.Handley@cs.ucl.ac.uk
马克·汉德利，计算机科学系伦敦大学学院伦敦高尔街伦敦WC1E 6BT英国电子邮件：M。Handley@cs.ucl.ac.uk
Jitendra Padhye Microsoft Research EMail: padhye@microsoft.com
Jitendra Padhye Microsoft Research电子邮件：padhye@microsoft.com
Joerg Widmer DoCoMo Euro-Labs Landsberger Strasse 312 80687 Munich Germany EMail: widmer@acm.org
Joerg Widmer DoCoMo Euro Labs Landsberger Strasse 312 80687慕尼黑德国电子邮件：widmer@acm.org
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.