Network Working Group S. Floyd
Request for Comments: 4828 ICIR
Category: Experimental E. Kohler
UCLA
April 2007
Network Working Group S. Floyd
Request for Comments: 4828 ICIR
Category: Experimental E. Kohler
UCLA
April 2007
TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant
TCP友好速率控制（TFRC）：小数据包（SP）变体
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet.
本文件提出了一种用于进一步试验的机制，但不适用于目前在全球互联网上的广泛部署。
TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment (RFC 3448). TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently.
TCP友好速率控制（TFRC）是一种用于在尽力而为的Internet环境（RFC 3448）中运行的单播流的拥塞控制机制。TFRC适用于使用固定数据包大小的应用程序，在与使用相同数据包大小的TCP连接竞争带宽时，TFRC的设计是合理公平的。本文档提出了TFRC-SP，TFRC的一种小包（SP）变体，专为发送小包的应用程序而设计。TFRC-SP的设计目标是使用高达1500字节的数据包实现与TCP流相同的带宽（bps）（比特/秒）。TFRC-SP强制数据包之间的最小间隔为10 ms，以防止单个流任意频繁地发送小数据包。
Flows using TFRC-SP compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small-packet flows experience similar packet drop rates. However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with Drop-Tail queues in units of bytes), TFRC-SP can receive considerably more than its share of the bandwidth.
在大数据包流和小数据包流经历相似丢包率的环境中，使用TFRC-SP的流与大数据包TCP和TFRC流公平竞争。然而，在小数据包流经历的数据包丢弃率低于大数据包流的环境中（例如，具有以字节为单位的丢弃尾队列），TFRC-SP可以接收远远超过其带宽份额的数据包。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions .....................................................5
3. TFRC-SP Congestion Control ......................................5
4. TFRC-SP Discussion ..............................................9
4.1. Response Functions and Throughput Equations ................9
4.2. Accounting for Header Size ................................12
4.3. The TFRC-SP Min Interval ..................................13
4.4. Counting Packet Losses ....................................14
4.5. The Nominal Packet Size ...................................15
4.5.1. Packet Size and Packet Drop Rates ..................15
4.5.2. Fragmentation and the Path MTU .....................17
4.5.3. The Nominal Segment Size and the Path MTU ..........17
4.6. The Loss Interval Length for Short Loss Intervals .........18
5. A Comparison with RFC 3714 .....................................19
6. TFRC-SP with Applications that Modify the Packet Size ..........19
7. Simulations ....................................................20
8. General Discussion .............................................21
9. Security Considerations ........................................22
10. Conclusions ...................................................23
11. Acknowledgements ..............................................24
Appendix A. Related Work on Small-Packet Variants of TFRC .........25
Appendix B. Simulation Results ....................................26
B.1. Simulations with Configured Packet Drop Rates .............26
B.2. Simulations with Configured Byte Drop Rates ...............30
B.3. Packet Dropping Behavior at Routers with Drop-Tail
Queues ....................................................32
B.4. Packet Dropping Behavior at Routers with AQM ..............37
Appendix C. Exploring Possible Oscillations in the Loss Event
Rate ...........................................................42
Appendix D. A Discussion of Packet Size and Packet Dropping .......43
Normative References ..............................................44
Informative References ............................................44
1. Introduction ....................................................3
2. Conventions .....................................................5
3. TFRC-SP Congestion Control ......................................5
4. TFRC-SP Discussion ..............................................9
4.1. Response Functions and Throughput Equations ................9
4.2. Accounting for Header Size ................................12
4.3. The TFRC-SP Min Interval ..................................13
4.4. Counting Packet Losses ....................................14
4.5. The Nominal Packet Size ...................................15
4.5.1. Packet Size and Packet Drop Rates ..................15
4.5.2. Fragmentation and the Path MTU .....................17
4.5.3. The Nominal Segment Size and the Path MTU ..........17
4.6. The Loss Interval Length for Short Loss Intervals .........18
5. A Comparison with RFC 3714 .....................................19
6. TFRC-SP with Applications that Modify the Packet Size ..........19
7. Simulations ....................................................20
8. General Discussion .............................................21
9. Security Considerations ........................................22
10. Conclusions ...................................................23
11. Acknowledgements ..............................................24
Appendix A. Related Work on Small-Packet Variants of TFRC .........25
Appendix B. Simulation Results ....................................26
B.1. Simulations with Configured Packet Drop Rates .............26
B.2. Simulations with Configured Byte Drop Rates ...............30
B.3. Packet Dropping Behavior at Routers with Drop-Tail
Queues ....................................................32
B.4. Packet Dropping Behavior at Routers with AQM ..............37
Appendix C. Exploring Possible Oscillations in the Loss Event
Rate ...........................................................42
Appendix D. A Discussion of Packet Size and Packet Dropping .......43
Normative References ..............................................44
Informative References ............................................44
This document specifies TFRC-SP, an experimental, Small-Packet variant of TCP-friendly Rate Control (TFRC) [RFC3448].
本文档指定了TFRC-SP，它是TCP友好速率控制（TFRC）的一种实验性小数据包变体[RFC3448]。
TFRC was designed to be reasonably fair when competing for bandwidth with TCP flows, but to avoid the abrupt changes in the sending rate characteristic of TCP's congestion control mechanisms. TFRC is intended for applications such as streaming media applications where a relatively smooth sending rate is of importance. Conventional TFRC measures loss rates by estimating the loss event ratio as described in [RFC3448], and uses this loss event rate to determine the sending rate in packets per round-trip time. This has consequences for the rate that a TFRC flow can achieve when sharing a bottleneck with large-packet TCP flows. In particular, a low-bandwidth, small-packet TFRC flow sharing a bottleneck with high-bandwidth, large-packet TCP flows may be forced to slow down, even though the TFRC application's nominal rate in bytes per second is less than the rate achieved by the TCP flows. Intuitively, this would be "fair" only if the network limitation was in packets per second (such as a routing lookup), rather than bytes per second (such as link bandwidth). Conventional wisdom is that many of the network limitations in today's Internet are in bytes per second, even though the network limitations of the future might move back towards limitations in packets per second.
TFRC被设计为在与TCP流竞争带宽时合理公平，但避免TCP拥塞控制机制的发送速率特性发生突变。TFRC适用于诸如流媒体应用等相对平滑的发送速率非常重要的应用。传统TFRC通过估算[RFC3448]中所述的丢失事件比率来测量丢失率，并使用此丢失事件比率来确定每个往返时间的发送速率（以数据包为单位）。这会影响TFRC流在与大型数据包TCP流共享瓶颈时可以达到的速率。特别是，共享瓶颈的低带宽、小分组TFRC流与高带宽、大分组TCP流可能会被迫减速，即使TFRC应用程序的标称速率（以字节/秒为单位）小于TCP流实现的速率。直观地说，只有当网络限制是每秒包数（如路由查找）而不是每秒字节数（如链路带宽）时，这才是“公平的”。传统观点认为，当今互联网的许多网络限制是以每秒字节为单位的，尽管未来的网络限制可能会回到以每秒数据包为单位的限制。
TFRC-SP is intended for flows that need to send frequent small packets, with less than 1500 bytes per packet, limited by a minimum interval between packets of 10 ms. It will better support applications that do not want their sending rates in bytes per second to suffer from their use of small packets. This variant is restricted to applications that send packets no more than once every 10 ms (the Min Interval or minimum interval). Given this restriction, TFRC-SP effectively calculates the TFRC fair rate as if the bottleneck restriction was in bytes per second. Applications using TFRC-SP could have a fixed or naturally-varying packet size, or could vary their packet size in response to congestion. Applications that are not willing to be limited by a minimum interval of 10 ms between packets, or that want to send packets larger than 1500 bytes, should not use TFRC-SP. However, for applications with a minimum interval of at least 10 ms between packets and with data packets of at most 1500 bytes, the performance of TFRC-SP should be at least as good as that from TFRC.
TFRC-SP适用于需要频繁发送小数据包的流，每个数据包少于1500字节，数据包之间的最小间隔为10毫秒。它将更好地支持不希望其发送速率（字节/秒）因使用小数据包而受到影响的应用程序。此变体仅限于每10ms（最小间隔或最小间隔）发送数据包不超过一次的应用程序。鉴于此限制，TFRC-SP有效地计算TFRC公平率，就好像瓶颈限制是以字节/秒为单位。使用TFRC-SP的应用程序可以具有固定或自然变化的数据包大小，或者可以根据拥塞情况改变其数据包大小。如果应用程序不希望数据包之间的最小间隔为10 ms，或者希望发送大于1500字节的数据包，则不应使用TFRC-SP。但是，对于数据包之间的最小间隔为10 ms且数据包最多为1500字节的应用程序，TFRC-SP的性能至少应与TFRC的性能相同。
RFC 3448, the protocol specification for TFRC, stated that TFRC-PS (for TFRC-PacketSize), a variant of TFRC for applications that have a fixed sending rate but vary their packet size in response to congestion, would be specified in a later document. This document instead specifies TFRC-SP, a variant of TFRC designed for
TFRC协议规范RFC 3448指出，TFRC-PS（用于TFRC PacketSize）是TFRC的一个变体，用于具有固定发送速率但因拥塞而改变其数据包大小的应用程序，将在稍后的文档中指定。本文档指定了TFRC-SP，这是TFRC的一个变体，设计用于
applications that send small packets, where applications could either have a fixed or varying packet size or could adapt their packet size in response to congestion. However, as discussed in Section 6 of this document, there are many questions about how such an adaptive application would use TFRC-SP that are beyond the scope of this document, and that would need to be addressed in documents that are more application-specific.
发送小数据包的应用程序，其中应用程序可以具有固定或变化的数据包大小，或者可以调整其数据包大小以响应拥塞。但是，如本文件第6节所述，关于此类自适应应用程序如何使用TFRC-SP，存在许多问题，这些问题超出了本文件的范围，需要在更具体的应用程序文件中加以解决。
TFRC-SP is motivated in part by the approach in RFC 3714, which argues that it is acceptable for VoIP flows to assume that the network limitation is in bytes per second (Bps) rather in packets per second (pps), and to have the same sending rate in bytes per second as a TCP flow with 1500-byte packets and the same packet drop rate. RFC 3714 states the following:
TFRC-SP的部分动机来自RFC 3714中的方法，该方法认为VoIP流可以接受假设网络限制为每秒字节数（Bps），而不是每秒分组数（pps），并且具有与具有1500字节分组和相同分组丢弃率的TCP流相同的每秒字节数发送速率。RFC 3714规定如下：
"While the ideal would be to have a transport protocol that is able to detect whether the bottleneck links along the path are limited in Bps or in pps, and to respond appropriately when the limitation is in pps, such an ideal is hard to achieve. We would not want to delay the deployment of congestion control for telephony traffic until such an ideal could be accomplished. In addition, we note that the current TCP congestion control mechanisms are themselves not very effective in an environment where there is a limitation along the reverse path in pps. While the TCP mechanisms do provide an incentive to use large data packets, TCP does not include any effective congestion control mechanisms for the stream of small acknowledgement packets on the reverse path. Given the arguments above, it seems acceptable to us to assume a network limitation in Bps rather than in pps in considering the minimum sending rate of telephony traffic."
“虽然理想的传输协议能够检测路径上的瓶颈链路是否在Bps或pps中受到限制，并在pps中受到限制时做出适当的响应，但这样的理想很难实现。我们不希望在这样的ide出现之前延迟对电话流量的拥塞控制部署此外，我们注意到，当前的TCP拥塞控制机制本身在pps中沿反向路径存在限制的环境中不是非常有效。虽然TCP机制确实鼓励使用大数据包，但TCP不包括任何有效的拥塞控制机制对于反向路径上的小确认数据包流。鉴于上述参数，在考虑电话流量的最小发送速率时，我们似乎可以接受以Bps而不是pps为网络限制。”
Translating the discussion in [RFC3714] to the congestion control mechanisms of TFRC, it seems acceptable to standardize a variant of TFRC that allows low-bandwidth flows sending small packets to achieve a rough fairness with TCP flows in terms of the sending rate in Bps, rather than in terms of the sending rate in pps. This is accomplished by TFRC-SP, a small modification to TFRC, as described below.
将[RFC3714]中的讨论转化为TFRC的拥塞控制机制，标准化TFRC的一个变体似乎是可以接受的，该变体允许低带宽流发送小数据包，从而在发送速率（以Bps为单位）而不是发送速率（以pps为单位）方面实现TCP流的大致公平性。这是由TFRC-SP完成的，它是对TFRC的一个小修改，如下所述。
Maintaining incentives for large packets: Because the bottlenecks in the network in fact can include limitations in pps as well as in Bps, we pay special attention to the potential dangers of encouraging a large deployment of best-effort traffic in the Internet consisting entirely of small packets. This is discussed in more detail in Section 4.3. In addition, as again discussed in Section 4.3, TFRC-SP includes the limitation of the Min Interval between packets of 10 ms.
保持对大数据包的激励：因为网络中的瓶颈事实上可能包括pps和Bps中的限制，我们特别关注鼓励在完全由小数据包组成的互联网中大规模部署尽力而为流量的潜在危险。第4.3节对此进行了更详细的讨论。此外，如第4.3节中再次讨论的，TFRC-SP包括10 ms数据包之间最小间隔的限制。
Packet drop rates as a function of packet size: TFRC-SP essentially assumes that the small-packet TFRC-SP flow receives roughly the same packet drop rate as a large-packet TFRC or TCP flow. As we show, this assumption is not necessarily correct for all environments in the Internet.
作为数据包大小函数的数据包丢弃率：TFRC-SP基本上假设小数据包TFRC-SP流接收的数据包丢弃率与大数据包TFRC或TCP流大致相同。正如我们所展示的，这个假设并不一定适用于互联网上的所有环境。
Initializing the Loss History after the First Loss Event: Section 6.3.1 of RFC 3448 specifies that the TFRC receiver initializes the loss history after the first loss event by calculating the loss interval that would be required to produce the receive rate measured over the most recent round-trip time. In calculating this loss interval, TFRC-SP uses the segment size of 1460 bytes, rather than the actual segment size used in the connection.
在第一次丢失事件后初始化丢失历史记录：RFC 3448第6.3.1节规定，TFRC接收器通过计算产生在最近往返时间内测量的接收速率所需的丢失间隔，在第一次丢失事件后初始化丢失历史记录。在计算此丢失间隔时，TFRC-SP使用1460字节的段大小，而不是连接中使用的实际段大小。
Calculating the loss event rate for TFRC-SP: TFRC-SP requires a modification in TFRC's calculation of the loss event rate, because a TFRC-SP connection can send many small packets when a standard TFRC or TCP connection would send a single large packet. It is not possible for a standard TFRC or TCP connection to repeatedly send multiple packets per round-trip time in the face of a high packet drop rate. As a result, TCP and standard TFRC only respond to a single loss event per round-trip time, and are still able to detect and respond to increasingly heavy packet loss rates. However, in a highly-congested environment, when a TCP connection might be sending, on average, one large packet per round-trip time, a corresponding TFRC-SP connection might be sending many small packets per round-trip time. As a result, in order to maintain fairness with TCP, and to be able to detect changes in the degree of congestion, TFRC-SP needs to be sensitive to the actual packet drop rate during periods of high congestion. This is discussed in more detail in the section below.
计算TFRC-SP的丢失事件率：TFRC-SP需要修改TFRC对丢失事件率的计算，因为当标准TFRC或TCP连接发送单个大数据包时，TFRC-SP连接可以发送许多小数据包。面对高丢包率，标准TFRC或TCP连接不可能在每个往返时间重复发送多个数据包。因此，TCP和标准TFRC在每个往返时间内只响应一个丢失事件，并且仍然能够检测和响应日益严重的数据包丢失率。然而，在高度拥挤的环境中，当TCP连接可能平均每个往返时间发送一个大数据包时，相应的TFRC-SP连接可能每个往返时间发送许多小数据包。因此，为了保持TCP的公平性，并能够检测拥塞程度的变化，TFRC-SP需要对高拥塞期间的实际丢包率敏感。下文将对此进行更详细的讨论。
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]中所述进行解释。
TFRC uses the TCP throughput equation given in Section 3.1 of [RFC3448], which gives the allowed sending rate X in bytes per second as a function of the loss event rate, segment size, and round-trip time. [RFC3448] specifies that the segment size s used in the throughput equation should be the segment size used by the application, or the estimated mean segment size if there are variations in the segment size depending on the data. This gives rough fairness with TCP flows using the same segment size.
TFRC使用[RFC3448]第3.1节中给出的TCP吞吐量方程，该方程给出了允许的发送速率X（字节/秒），作为丢失事件速率、段大小和往返时间的函数。[RFC3448]指定吞吐量方程中使用的段大小s应为应用程序使用的段大小，或者如果段大小因数据而异，则为估计的平均段大小。这为使用相同段大小的TCP流提供了大致的公平性。
TFRC-SP changes this behavior in the following ways.
TFRC-SP通过以下方式更改此行为。
o The nominal segment size: The nominal segment size s defaults to 1460 bytes. Following [RFC3714], this provides a goal of fairness, in terms of the sending rate in bytes per second, with a TCP flow with 1460 bytes of application data per packet but with the same packet drop rate. If the endpoint knows the MTU (Maximum Transmission Unit) of the path and the derived MSS (Maximum Segment Size) is less than 1460 bytes, then the endpoint SHOULD set the nominal segment size s to MSS bytes. In addition, if the endpoint knows the MTU of the path and the resulting MSS is less than 536 bytes, then the endpoint MUST set the nominal segment size s to MSS bytes.
o 标称段大小：标称段大小s默认为1460字节。在[RFC3714]之后，这提供了一个公平性目标，即发送速率（以字节/秒为单位），TCP流每个数据包具有1460字节的应用程序数据，但具有相同的数据包丢弃率。如果端点知道路径的MTU（最大传输单元）和导出的MSS（最大段大小）小于1460字节，则端点应将标称段大小s设置为MSS字节。此外，如果端点知道路径的MTU，并且生成的MSS小于536字节，则端点必须将标称段大小s设置为MSS字节。
However, this document does not require that TFRC-SP endpoints determine the path MTU. While most paths allow an MSS of 1460 bytes, some paths have a slightly smaller MSS due to tunnels (e.g., IPv6 over IPv4). In some specific cases, IPv4 paths may experience a much smaller path MTU. Due to the complications of estimating the path MTU, and to the fact that most paths support an MSS of at least 536 bytes, TFRC-SP as a default uses a nominal segment size of 1460 bytes. The nominal segment size is discussed in more detail in Section 4.5.3.
但是，本文档不要求TFRC-SP端点确定MTU路径。虽然大多数路径允许1460字节的MSS，但由于隧道（例如，IPv4上的IPv6），一些路径的MSS稍小一些。在某些特定情况下，IPv4路径可能会遇到更小的路径MTU。由于估算路径MTU的复杂性，以及大多数路径支持至少536字节的MSS，TFRC-SP默认使用1460字节的标称段大小。第4.5.3节详细讨论了标称管段尺寸。
o Taking packet headers into account: The allowed transmit rate X in bytes per second is reduced by a factor that accounts for packet header size. This gives the application some incentive, beyond the Min Interval, not to use unnecessarily small packets. In particular, we introduce a new parameter H, which represents the expected size in bytes of network and transport headers to be used on the TFRC connection's packets. This is used to reduce the allowed transmit rate X as follows:
o 考虑到数据包头：允许的传输速率X（以字节/秒为单位）减少了一个因素，该因素考虑了数据包头的大小。这给了应用程序一些激励，在最小间隔之外，不要使用不必要的小数据包。特别是，我们引入了一个新参数H，它表示TFRC连接的数据包上使用的网络和传输头的预期大小（以字节为单位）。这用于降低允许的传输速率X，如下所示：
X := X * s_true / (s_true + H),
X:=X*s_真/（s_真+H），
where s_true is the true average data segment size for the connection in bytes, excluding the transport and network headers. Section 4.1 of RFC 3448 states that where the packet size varies naturally with the data, an estimate of the mean segment size can be used for s_true. As suggested in Section 4.1 of [RFC3448bis], when an estimate of the mean segment size is used for s_true, the estimate SHOULD be calculated over at least the last four loss intervals. However, this document does not specify a specific algorithm for estimating the mean segment size.
其中s_true是连接的真实平均数据段大小（字节），不包括传输和网络头。RFC 3448第4.1节规定，如果数据包大小随数据自然变化，则平均段大小的估计值可用于s_true。如[RFC3448bis]第4.1节所述，当平均段大小的估算用于s_true时，应至少在最后四个损失间隔内计算估算值。然而，本文件并未规定估算平均段大小的具体算法。
The H parameter is set to the constant 40 bytes. Thus, if the TFRC-SP application used 40-byte data segments, the allowed transmit rate X would be halved to account for the fact that half
H参数设置为恒定的40字节。因此，如果TFRC-SP应用程序使用40字节的数据段，则允许的传输速率X将减半，以说明
of the sending rate would be used by the headers. Section 4.2 justifies this definition. However, a connection using TFRC-SP MAY instead use a more precise estimate of H, based on the actual network and transport headers to be used on the connection's packets. For example, a Datagram Congestion Control Protocol (DCCP) connection [RFC4340] over IPv4, where data packets use the DCCP-Data packet type, and there are no IP or DCCP options, could set H to 20 + 12 = 32 bytes. However, if the TFRC implementation knows that the IP layer is using IPv6 instead of IPv4, then the connection using TFRC-SP MAY still use the default estimate of 40 bytes for H instead of the actual size of 60 bytes, for simplicity of implementation.
报头将使用发送速率的百分比。第4.2节证明了这一定义的合理性。然而，使用TFRC-SP的连接可能会根据连接数据包上使用的实际网络和传输报头，使用更精确的H估计值。例如，IPv4上的数据报拥塞控制协议（DCCP）连接[RFC4340]，其中数据包使用DCCP数据包类型，并且没有IP或DCCP选项，可以将H设置为20+12=32字节。但是，如果TFRC实现知道IP层正在使用IPv6而不是IPv4，则为简化实现，使用TFRC-SP的连接可能仍然会使用默认的H估计值40字节，而不是实际大小60字节。
o Measuring the loss event rate in times of high loss: During short loss intervals (those at most two round-trip times), the loss rate is computed by counting the actual number of packets lost or marked, not by counting at most one loss event per loss interval. Without this change, TFRC-SP could send multiple packets per round-trip time even in the face of heavy congestion, for a steady-state behavior of multiple packets dropped each round-trip time.
o 在高丢失时测量丢失事件率：在短丢失间隔期间（最多两次往返时间），通过计算丢失或标记的数据包的实际数量来计算丢失率，而不是每个丢失间隔最多计算一个丢失事件。如果没有这种变化，TFRC-SP可以在每个往返时间发送多个数据包，即使在严重拥塞的情况下也是如此，因为每个往返时间丢弃的多个数据包的稳态行为。
In standard TFRC, the TFRC receiver estimates the loss event rate by calculating the average loss interval in packets, and inverting to get the loss event rate. Thus, for a short loss interval with N packets and K losses, standard TFRC calculates the size of that loss interval as N packets, contributing to a loss event rate of 1/N. However, for TFRC-SP, for small loss intervals of at most two round-trip times, if the loss interval consists of N packets including K losses, the size of the loss interval is calculated as N/K, contributing to a loss event rate of K/N instead of 1/N.
在标准TFRC中，TFRC接收器通过计算数据包中的平均丢失间隔来估计丢失事件率，并反转以获得丢失事件率。因此，对于具有N个数据包和K个丢失的短丢失间隔，标准TFRC将该丢失间隔的大小计算为N个数据包，导致丢失事件率为1/N。但是，对于TFRC-SP，对于最多两个往返时间的小丢失间隔，如果丢失间隔由包含K个丢失的N个数据包组成，损失间隔的大小计算为N/K，导致损失事件率为K/N而不是1/N。
Section 5.4 of RFC 3448 specifies that the calculation of the average loss interval includes the most recent loss interval only if this increases the calculated average loss interval, as in the pseudocode below. However, in TFRC-SP the calculated loss interval size for a short loss interval varies as a function of the number of packet losses that have been detected, allowing either increases or decreases in the calculated loss interval size for the current short loss interval as new packets are received. Therefore, TFRC-SP adds the restriction that the calculation of the average loss interval can include the most recent loss interval only if more than two round-trip times have passed since the beginning of that loss interval.
RFC 3448第5.4节规定，平均损失间隔的计算仅在增加计算的平均损失间隔时才包括最近的损失间隔，如下面的伪代码所示。然而，在TFRC-SP中，短丢失间隔的计算丢失间隔大小随检测到的数据包丢失数量的变化而变化，当接收到新数据包时，允许增加或减少当前短丢失间隔的计算丢失间隔大小。因此，TFRC-SP增加了一个限制，即平均损耗间隔的计算只能包括最近的损耗间隔，前提是自该损耗间隔开始以来已经过两次以上的往返时间。
Let the most recent loss intervals be I_0 to I_n, with I_0 being the interval including the most recent loss event, with the corresponding weights w_i as defined in RFC 3448. In RFC 3448 (Section 5.4), the average loss interval I_mean is calculated as follows:
设最近的损失间隔为I_0至I_n，I_0为包括最近损失事件的间隔，其相应权重w_I如RFC 3448中所定义。在RFC 3448（第5.4节）中，平均损失间隔I_平均值计算如下：
I_tot0 = 0;
I_tot1 = 0;
W_tot = 0;
for (i = 0 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1));
}
I_tot = max(I_tot0, I_tot1);
I_mean = I_tot/W_tot;
I_tot0 = 0;
I_tot1 = 0;
W_tot = 0;
for (i = 0 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1));
}
I_tot = max(I_tot0, I_tot1);
I_mean = I_tot/W_tot;
In TFRC-SP, the average loss interval I_mean is instead calculated as follows:
在TFRC-SP中，平均损失间隔I_平均值计算如下：
I_tot0 = 0;
I_tot1 = 0;
W_tot = 0;
for (i = 0 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1));
}
If the current loss interval I_0 is "short"
then I_tot = I_tot1;
else I_tot = max(I_tot0, I_tot1);
I_mean = I_tot/W_tot;
I_tot0 = 0;
I_tot1 = 0;
W_tot = 0;
for (i = 0 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1));
}
If the current loss interval I_0 is "short"
then I_tot = I_tot1;
else I_tot = max(I_tot0, I_tot1);
I_mean = I_tot/W_tot;
o A minimum interval between packets: TFRC-SP enforces a Min Interval between packets of 10 ms. A flow that wishes its transport protocol to exceed this Min Interval MUST use the conventional TFRC equations, rather than TFRC-SP. The motivation for this is discussed below.
o 数据包之间的最小间隔：TFRC-SP强制数据包之间的最小间隔为10毫秒。希望其传输协议超过该最小间隔的流必须使用传统的TFRC方程，而不是TFRC-SP。下面讨论其动机。
TFRC uses the TCP throughput equation given in [RFC3448], with the sending rate X in bytes per second as follows:
TFRC使用[RFC3448]中给出的TCP吞吐量公式，发送速率为X字节/秒，如下所示：
s
X = ------------------------------------------------------- ,
R*sqrt(2*p/3) + (4*R* (3*sqrt(3*p/8) * p * (1+32*p^2)))
s
X = ------------------------------------------------------- ,
R*sqrt(2*p/3) + (4*R* (3*sqrt(3*p/8) * p * (1+32*p^2)))
where:
哪里：
s is the packet size in bytes;
s是以字节为单位的数据包大小；
R is the round-trip time in seconds;
R是以秒为单位的往返时间；
p is the loss event rate, between 0 and 1.0, of the number of loss events as a fraction of the number of packets transmitted.
p是丢失事件率，介于0和1.0之间，丢失事件数占传输的数据包数的一小部分。
This equation uses a retransmission timeout (RTO) of 4*R, and assumes that the TCP connection sends an acknowledgement for every data packet.
该等式使用4*R的重传超时（RTO），并假设TCP连接为每个数据包发送确认。
This equation essentially gives the response function for TCP as well as for standard TFRC (modulo TCP's range of sender algorithms for setting the RTO). As shown in Table 1 of [RFC3714], for high packet drop rates, this throughput equation gives rough fairness with the most aggressive possible current TCP: a SACK TCP flow using timestamps and Explicit Congestion Notification (ECN). Because it is not recommended for routers to use ECN-marking in highly-congested environments with high packet dropping/marking rates (Section 7 of [RFC3168]), we note that it would be useful to have a throughput equation with a somewhat more moderate sending rate for packet drop rates of 40% and above.
该方程基本上给出了TCP以及标准TFRC（modulo TCP设置RTO的发送方算法范围）的响应函数。如[RFC3714]表1所示，对于高丢包率，该吞吐量方程给出了最具攻击性的当前TCP的大致公平性：使用时间戳和显式拥塞通知（ECN）的SACK TCP流。由于不建议路由器在高分组丢弃/标记率（RFC3168第7节）的高度拥挤环境中使用ECN标记，因此我们注意到，对于40%及以上的分组丢弃率，具有稍微适中的发送率的吞吐量方程是有用的。
The effective response function of TFRC-SP can be derived from the TFRC response function by using a segment size s of 1460 bytes, and using the loss event rate actually experienced by the TFRC-SP flow. In addition, for loss intervals of at most two round-trip times, the loss event rate for TFRC-SP is estimated by counting the actual number of lost or marked packets, rather than by counting loss events. In addition, the sending rate for TFRC-SP is constrained to be at most 100 packets per second.
TFRC-SP的有效响应函数可通过使用1460字节的段大小s，并使用TFRC-SP流实际经历的丢失事件率，从TFRC响应函数中导出。此外，对于最多两次往返时间的丢失间隔，TFRC-SP的丢失事件率是通过计算丢失或标记数据包的实际数量而不是通过计算丢失事件来估计的。此外，TFRC-SP的发送速率被限制为每秒最多100个数据包。
For an environment with a fixed packet drop rate p, regardless of packet size, the response functions of TCP, TFRC, and TFRC-SP are illustrated as follows, given in KBps (kilobytes per second), for a flow with a round-trip time of 100 ms:
对于具有固定丢包率p的环境，无论数据包大小如何，TCP、TFRC和TFRC-SP的响应函数如下所示，对于往返时间为100 ms的流，以KBps（每秒千字节）为单位给出：
<-- TCP and Standard TFRC -->
Packet 14-byte 536-byte 1460-byte
DropRate Segments Segments Segments
-------- -------- -------- --------
0.00001 209.25 2232.00 5812.49
0.00003 120.79 1288.41 3355.24
0.00010 66.12 705.25 1836.58
0.00030 38.10 406.44 1058.45
0.00100 20.74 221.23 576.12
0.00300 11.76 125.49 326.79
0.01000 6.07 64.75 168.61
0.03000 2.99 31.90 83.07
0.10000 0.96 10.21 26.58
0.20000 0.29 3.09 8.06
0.30000 0.11 1.12 2.93
0.40000 0.05 0.48 1.26
0.50000 0.02 0.24 0.63
<-- TCP and Standard TFRC -->
Packet 14-byte 536-byte 1460-byte
DropRate Segments Segments Segments
-------- -------- -------- --------
0.00001 209.25 2232.00 5812.49
0.00003 120.79 1288.41 3355.24
0.00010 66.12 705.25 1836.58
0.00030 38.10 406.44 1058.45
0.00100 20.74 221.23 576.12
0.00300 11.76 125.49 326.79
0.01000 6.07 64.75 168.61
0.03000 2.99 31.90 83.07
0.10000 0.96 10.21 26.58
0.20000 0.29 3.09 8.06
0.30000 0.11 1.12 2.93
0.40000 0.05 0.48 1.26
0.50000 0.02 0.24 0.63
Table 1: Response Function for TCP and TFRC. Sending Rate in KBps, as a Function of Packet Drop Rate.
表1:TCP和TFRC的响应函数。发送速率，以KBps为单位，作为数据包丢弃速率的函数。
<---------- TFRC-SP -------->
Packet 14-byte 536-byte 1460-byte
DropRate Segments Segments Segments
-------- -------- -------- --------
0.00001 5.40 57.60 150.00
0.00003 5.40 57.60 150.00
0.00010 5.40 57.60 150.00
0.00030 5.40 57.60 150.00
0.00100 5.40 57.60 150.00
0.00300 5.40 57.60 150.00
0.01000 5.40 57.60 150.00
0.03000 5.40 57.60 83.07
0.10000 5.40 26.58 26.58
0.20000 5.40 8.06 8.06
0.30000 2.93 2.93 2.93
0.40000 1.26 1.26 1.26
0.50000 0.63 0.63 0.63
<---------- TFRC-SP -------->
Packet 14-byte 536-byte 1460-byte
DropRate Segments Segments Segments
-------- -------- -------- --------
0.00001 5.40 57.60 150.00
0.00003 5.40 57.60 150.00
0.00010 5.40 57.60 150.00
0.00030 5.40 57.60 150.00
0.00100 5.40 57.60 150.00
0.00300 5.40 57.60 150.00
0.01000 5.40 57.60 150.00
0.03000 5.40 57.60 83.07
0.10000 5.40 26.58 26.58
0.20000 5.40 8.06 8.06
0.30000 2.93 2.93 2.93
0.40000 1.26 1.26 1.26
0.50000 0.63 0.63 0.63
Table 2: Response Function for TFRC-SP. Sending Rate in KBps, as a Function of Packet Drop Rate. Maximum Sending Rate of 100 Packets per Second.
表2:TFRC-SP的响应函数。发送速率（KBps），作为丢包率的函数。每秒100个数据包的最大发送速率。
The calculations for Tables 1 and 2 use the packet loss rate for an approximation for the loss event rate p. Scripts and graphs for the tables are available from [VOIPSIMS]. As the well-known TCP response function in Table 1 shows, the sending rate for TCP and standard TFRC varies linearly with segment size. The TFRC-SP response function shown in Table 2 reflects the maximum sending rate of a hundred packets per second; when not limited by this maximum sending rate, the TFRC-SP flow receives the same sending rate in KBps as the TCP flow with 1460-byte segments, given the same packet drop rate. Simulations showing the TCP, standard TFRC, and TFRC-SP sending rates in response to a configured packet drop rate are given in Tables 7, 8, and 9, and are consistent with the response functions shown here.
表1和表2的计算使用分组丢失率作为丢失事件率p的近似值。表的脚本和图形可从[VOIPSIMS]获得。正如表1中众所周知的TCP响应函数所示，TCP和标准TFRC的发送速率随段大小线性变化。表2中所示的TFRC-SP响应函数反映了每秒100个数据包的最大发送速率；如果不受此最大发送速率的限制，TFRC-SP流接收的发送速率（单位为KBps）与具有1460字节段的TCP流接收的发送速率（给定相同的数据包丢弃速率）相同。表7、表8和表9给出了TCP、标准TFRC和TFRC-SP发送速率响应配置丢包率的仿真结果，这些仿真结果与此处显示的响应函数一致。
<-- TCP and Standard TFRC -->
Byte 14-byte 536-byte 1460-byte
DropRate Segments Segments Segments
-------- -------- -------- --------
0.0000001 284.76 929.61 1498.95
0.0000003 164.39 536.17 863.16
0.0000010 90.01 292.64 468.49
0.0000030 51.92 167.28 263.68
0.0000100 28.34 88.56 132.75
0.0000300 16.21 46.67 61.70
0.0001000 8.60 19.20 16.25
0.0003000 4.56 4.95 1.70
0.0010000 1.90 0.37 0.15
0.0030000 0.52 0.05 0.06
0.0100000 0.04 0.02 0.06
0.0300000 0.00 0.02 0.06
<-- TCP and Standard TFRC -->
Byte 14-byte 536-byte 1460-byte
DropRate Segments Segments Segments
-------- -------- -------- --------
0.0000001 284.76 929.61 1498.95
0.0000003 164.39 536.17 863.16
0.0000010 90.01 292.64 468.49
0.0000030 51.92 167.28 263.68
0.0000100 28.34 88.56 132.75
0.0000300 16.21 46.67 61.70
0.0001000 8.60 19.20 16.25
0.0003000 4.56 4.95 1.70
0.0010000 1.90 0.37 0.15
0.0030000 0.52 0.05 0.06
0.0100000 0.04 0.02 0.06
0.0300000 0.00 0.02 0.06
Table 3: Response Function for TCP and TFRC. Sending Rate in KBps, as a Function of Byte Drop Rate.
表3:TCP和TFRC的响应函数。以KBps为单位的发送速率，是字节丢失率的函数。
<---------- TFRC-SP -------->
Byte 14-byte 536-byte 1460-byte
DropRate Segments Segments Segments
-------- -------- -------- --------
0.0000001 5.40 57.60 150.00
0.0000003 5.40 57.60 150.00
0.0000010 5.40 57.60 150.00
0.0000030 5.40 57.60 150.00
0.0000100 5.40 57.60 132.75
0.0000300 5.40 57.60 61.70
0.0001000 5.40 50.00 16.25
0.0003000 5.40 12.89 1.70
0.0010000 5.40 0.95 0.15
0.0030000 5.40 0.12 0.06
0.0100000 1.10 0.06 0.06
0.0300000 0.13 0.06 0.06
<---------- TFRC-SP -------->
Byte 14-byte 536-byte 1460-byte
DropRate Segments Segments Segments
-------- -------- -------- --------
0.0000001 5.40 57.60 150.00
0.0000003 5.40 57.60 150.00
0.0000010 5.40 57.60 150.00
0.0000030 5.40 57.60 150.00
0.0000100 5.40 57.60 132.75
0.0000300 5.40 57.60 61.70
0.0001000 5.40 50.00 16.25
0.0003000 5.40 12.89 1.70
0.0010000 5.40 0.95 0.15
0.0030000 5.40 0.12 0.06
0.0100000 1.10 0.06 0.06
0.0300000 0.13 0.06 0.06
Table 4: Response Function for TFRC-SP. Sending Rate in KBps, as a Function of Byte Drop Rate. Maximum Sending Rate of 100 Packets per Second.
表4:TFRC-SP的响应函数。发送速率（以KBps为单位），作为字节丢失率的函数。每秒100个数据包的最大发送速率。
For Tables 3 and 4, the packet drop rate is calculated as 1-(1-b)^N, for a byte drop rate of b, and a packet size of N bytes. These tables use the packet loss rate as an approximation for the loss event rate p. The TCP response functions shown in Table 3 for fixed byte drop rates are rather different from the response functions shown in Table 1 for fixed packet drop rates; with higher byte drop rates, a TCP connection can have a higher sending rate using *smaller* packets. Table 4 also shows that with fixed byte drop rates, the sending rate for TFRC-SP can be significantly higher than that for TCP or standard TFRC, regardless of the TCP segment size. This is because in this environment, with small packets, TFRC-SP receives a small packet drop rate, but is allowed to send at the sending rate of a TCP or standard TFRC flow using larger packets but receiving the same packet drop rate.
对于表3和表4，数据包丢弃率计算为1-（1-b）^N，字节丢弃率为b，数据包大小为N字节。这些表使用数据包丢失率作为丢失事件率p的近似值。表3所示的固定字节丢弃率的TCP响应函数与表1所示的固定数据包丢弃率的响应函数大不相同；使用更高的字节丢弃率，TCP连接可以使用*更小*的数据包具有更高的发送速率。表4还显示，在固定字节丢弃率的情况下，无论TCP段大小如何，TFRC-SP的发送速率都可能显著高于TCP或标准TFRC的发送速率。这是因为在此环境中，对于小数据包，TFRC-SP接收小数据包丢弃率，但允许使用较大数据包以TCP或标准TFRC流的发送率发送，但接收相同的数据包丢弃率。
Simulations showing TCP, standard TFRC, and TFRC-SP sending rates in response to a configured byte drop rate are given in Appendix B.2.
附录B.2中给出了显示TCP、标准TFRC和TFRC-SP发送速率响应配置字节丢弃率的模拟。
[RFC3714] makes the optimistic assumption that the limitation of the network is in bandwidth in bytes per second (Bps), and not in CPU cycles or in packets per second (pps). However, some attention must be paid to the load in pps as well as to the load in Bps. Even aside from the Min Interval, TFRC-SP gives the application some incentive to use fewer but larger packets, when larger packets would suffice,
[RFC3714]乐观地假设网络的限制是以字节/秒（Bps）为单位的带宽，而不是以CPU周期或每秒数据包（pps）为单位的带宽。但是，必须注意pps中的负载以及Bps中的负载。即使在最小间隔之外，TFRC-SP也会在一定程度上鼓励应用程序使用较少但较大的数据包，而较大的数据包就足够了，
by including the bandwidth used by the packet header in the allowed sending rate.
通过将包头使用的带宽包括在允许的发送速率中。
As an example, a sender using 120-byte packets needs a TCP-friendly rate of 128 Kbps to send 96 Kbps of application data. This is because the TCP-friendly rate is reduced by a factor of s_true/(s_true + H) = 120/160, to account for the effect of packet headers. If the sender suddenly switched to 40-byte data segments, the allowed sending rate would reduce to 64 Kbps of application data; and the use of one-byte data segments would reduce the allowed sending rate to 3.12 Kbps of application data. (In fact, the Min Interval would prevent senders from achieving these rates, since applications using TFRC-SP cannot send more than 100 packets per second.)
例如，使用120字节数据包的发送方需要128 Kbps的TCP友好速率来发送96 Kbps的应用程序数据。这是因为TCP友好速率减少了s_真/（s_真+H）=120/160的系数，以考虑数据包头的影响。如果发送方突然切换到40字节的数据段，允许的发送速率将降低到64 Kbps的应用程序数据；使用单字节数据段会将允许的应用程序数据发送速率降低到3.12 Kbps。（事实上，最小间隔将阻止发送方达到这些速率，因为使用TFRC-SP的应用程序每秒发送的数据包不能超过100个。）
Unless it has a more precise estimate of the header size, TFRC-SP assumes 40 bytes for the header size, although the header could be larger (due to IP options, IPv6, IP tunnels, and the like) or smaller (due to header compression) on the wire. Requiring the use of the exact header size in bytes would require significant additional complexity, and would have little additional benefit. TFRC-SP's default assumption of a 40-byte header is sufficient to get a rough estimate of the throughput, and to give the application some incentive not to use an excessive amount of small packets. Because we are only aiming at rough fairness, and at a rough incentive for applications, the default use of a 40-byte header in the calculations of the header bandwidth is sufficient for both IPv4 and IPv6.
除非TFRC-SP对报头大小有更精确的估计，否则它假定报头大小为40字节，尽管报头在线路上可能更大（由于IP选项、IPv6、IP隧道等）或更小（由于报头压缩）。需要使用以字节为单位的确切报头大小将需要显著的额外复杂性，并且几乎没有额外的好处。TFRC-SP对40字节报头的默认假设足以粗略估计吞吐量，并为应用程序提供一些不使用过多小数据包的激励。由于我们的目标只是粗略的公平性，以及对应用程序的粗略激励，因此在计算报头带宽时默认使用40字节报头对于IPv4和IPv6都是足够的。
The header size calculation provides an incentive for applications to use fewer, but larger, packets. Another incentive is that when the path limitation is in pps, the application using more small packets is likely to cause higher packet drop rates, and to have to reduce its sending rate accordingly. That is, if the congestion is in terms of pps, then the flow sending more pps will increase the packet drop rate, and have to adjust its sending rate accordingly. However, the increased congestion caused by the use of small packets in an environment limited by pps is experienced not only by the flow using the small packets, but by all of the competing traffic on that congested link. These incentives are therefore insufficient to provide sufficient protection for pps network limitations.
报头大小计算鼓励应用程序使用更少但更大的数据包。另一个激励因素是，当路径限制在pps中时，使用更多小数据包的应用程序可能会导致更高的数据包丢弃率，并且必须相应地降低其发送速率。也就是说，如果拥塞是基于pps的，那么发送更多pps的流将增加丢包率，并且必须相应地调整其发送速率。然而，在受pps限制的环境中，由于使用小数据包而导致的拥塞增加不仅由使用小数据包的流所经历，而且由该拥塞链路上的所有竞争流量所经历。因此，这些激励措施不足以为pps网络限制提供足够的保护。
TFRC-SP, then, includes a Min Interval of 10 ms. This provides additional restrictions on the amount of small packets used.
然后，TFRC-SP包括10毫秒的最小间隔。这对使用的小包数量提供了额外的限制。
One practical justification for the Min Interval is that the applications that currently want to send small packets are the VoIP applications that send at most one packet every 10 ms, so this restriction does not affect current traffic. A second justification is that there is no pressing need for best-effort traffic in the current Internet to send small packets more frequently than once every 10 ms (rather than taking the 10 ms delay at the sender, and merging the two small packets into one larger one). This 10 ms delay for merging small packets is likely to be dominated by the network propagation, transmission, and queueing delays of best-effort traffic in the current Internet. As a result, our judgment would be that the benefit to the user of having less than 10 ms between packets is outweighed by the benefit to the network of avoiding an excessive amount of small packets.
最小间隔的一个实际理由是，当前希望发送小数据包的应用程序是每10ms最多发送一个数据包的VoIP应用程序，因此该限制不会影响当前流量。第二个理由是，当前互联网上的尽力而为流量并不迫切需要比每10毫秒发送一次小数据包更频繁地发送小数据包（而不是在发送者处采用10毫秒的延迟，并将两个小数据包合并为一个更大的数据包）。合并小数据包的10ms延迟可能主要由当前Internet中尽力而为流量的网络传播、传输和排队延迟决定。因此，我们的判断是，用户在数据包之间的间隔小于10ms的好处大于网络避免过多小数据包的好处。
The Min Interval causes TFRC-SP not to support applications sending small packets very frequently. Consider a TFRC flow with a fixed packet size of 100 bytes, but with a variable sending rate and a fairly uncongested path. When this flow is sending at most 100 pps, it would be able to use TFRC-SP. If the flow wishes to increase its sending rate to more than 100 pps, but keep the same packet size, it would no longer be able to achieve this with TFRC-SP, and would have to switch to the default TFRC, receiving a dramatic, discontinuous decrease in its allowed sending rate. This seems not only acceptable, but desirable for the global Internet.
最小间隔导致TFRC-SP不支持非常频繁地发送小数据包的应用程序。考虑具有100字节的固定分组大小的TFRC流，但具有可变的发送速率和相当不拥塞的路径。当该流最多发送100 pps时，它将能够使用TFRC-SP。如果该流希望将其发送速率增加到100 pps以上，但保持相同的数据包大小，它将无法再使用TFRC-SP实现这一点，并且将不得不切换到默认TFRC，接收到显著的，允许发送速率的不连续下降。这似乎不仅可以接受，而且对全球互联网来说也是可取的。
What is to prevent flows from opening multiple connections, each with a 10 ms Min Interval, thereby getting around the limitation of the Min Interval? Obviously, there is nothing to prevent flows from doing this, just as there is currently nothing to prevent flows from using UDP, or from opening multiple parallel TCP connections, or from using their own congestion control mechanism. Of course, implementations or middleboxes are also free to limit the number of parallel TFRC connections opened to the same destination in times of congestion, if that seems desirable. And flows that open multiple parallel connections are subject to the inconveniences of reordering and the like.
如何防止流打开多个连接（每个连接的间隔为10ms-Min），从而绕过最小间隔的限制？显然，没有什么可以阻止流这样做，就像当前没有什么可以阻止流使用UDP、打开多个并行TCP连接或使用它们自己的拥塞控制机制一样。当然，如果需要的话，实现或中间盒也可以在拥塞时自由限制打开到同一目的地的并行TFRC连接的数量。并且打开多个并行连接的流受到重新排序等的不便。
It is not possible for a TCP connection to persistently send multiple packets per round-trip time in the face of high congestion, with a steady-state with multiple packets dropped per round-trip time. For TCP, when one or more packets are dropped each round-trip time, the sending rate is quickly dropped to less than one packet per round-trip time. In addition, for TCP with Tahoe, NewReno, or SACK congestion control mechanisms, the response to congestion is largely independent of the number of packets dropped per round-trip time.
在高拥塞情况下，TCP连接不可能在每个往返时间持续发送多个数据包，而在稳态情况下，每个往返时间会丢弃多个数据包。对于TCP，当每个往返时间丢弃一个或多个数据包时，发送速率会迅速降低到每个往返时间少于一个数据包。此外，对于采用Tahoe、NewReno或SACK拥塞控制机制的TCP，对拥塞的响应在很大程度上与每次往返时间丢弃的数据包数量无关。
As a result, standard TFRC can best achieve fairness with TCP, even in highly congested environments, by calculating the loss event rate rather than the packet drop rate, where a loss event is one or more packets dropped or marked from a window of data.
因此，即使在高度拥挤的环境中，标准TFRC也可以通过计算丢失事件率而不是数据包丢失率（其中丢失事件是从数据窗口丢弃或标记的一个或多个数据包）来最好地实现TCP的公平性。
However, with TFRC-SP, it is no longer possible to achieve fairness with TCP or with standard TFRC by counting only the loss event rate [WBL04]. Instead of sending one large packet per round-trip time, TFRC-SP could be sending N small packets (where N small packets equal one large 1500-byte packet). The loss measurement used with TFRC-SP has to be able to detect a connection that is consistently receiving multiple packet losses or marks per round-trip time, to allow TFRC-SP to respond appropriately.
但是，对于TFRC-SP，不再可能通过仅计算丢失事件率来实现TCP或标准TFRC的公平性[WBL04]。TFRC-SP可以发送N个小数据包（其中N个小数据包等于一个1500字节的大数据包），而不是每个往返时间发送一个大数据包。TFRC-SP使用的损耗测量必须能够检测到每次往返时间一致接收多个数据包丢失或标记的连接，以允许TFRC-SP做出适当响应。
In TFRC-SP, the loss event rate is calculated by counting at most one loss event in loss intervals longer than two round-trip times, and by counting each packet lost or marked in shorter loss intervals. In particular, for a short loss interval with N packets, including K lost or marked packets, the loss interval length is calculated as N/K, instead of as N. The average loss interval I_mean is still averaged over the eight most recent loss intervals, as specified in Section 5.4 of RFC 3448. Thus, if eight successive loss intervals are short loss intervals with N packets and K losses, the loss event rate is calculated as K/N, rather than as 1/N.
在TFRC-SP中，丢失事件率的计算方法是：在超过两个往返时间的丢失间隔内最多计算一个丢失事件，并在较短的丢失间隔内计算每个丢失或标记的数据包。特别是，对于包含N个数据包（包括K个丢失或标记的数据包）的短丢失间隔，丢失间隔长度计算为N/K，而不是N。按照RFC 3448第5.4节的规定，平均丢失间隔I_平均值仍然是最近八个丢失间隔的平均值。因此，如果八个连续的丢失间隔是具有N个分组和K个丢失的短丢失间隔，则丢失事件率计算为K/N，而不是1/N。
The guidelines in Section 3 above say that the nominal segment size s is set to 1460 bytes, providing a goal of fairness, in terms of the sending rate in bytes per second, with a TCP flow with 1460 bytes of application data per packet but with the same packet drop rate. This follows the assumption that a TCP flow with 1460-byte segments will have a higher sending rate than a TCP flow with smaller segments. While this assumption holds in an environment where the packet drop rate is independent of packet size, this assumption does not necessarily hold in an environment where larger packets are more likely to be dropped than are small packets.
上面第3节中的指南指出，标称段大小s设置为1460字节，以每秒字节数的发送速率为单位，提供公平性目标，TCP流每个数据包具有1460字节的应用程序数据，但具有相同的数据包丢弃率。这遵循以下假设：具有1460字节段的TCP流将比具有较小段的TCP流具有更高的发送速率。虽然该假设在分组丢弃率独立于分组大小的环境中成立，但在较大分组比较小分组更可能被丢弃的环境中，该假设不一定成立。
The table below shows the results of simulations with standard (SACK) TCP flows, where, for each *byte*, the packet containing that byte is dropped with probability p. Consider the approximation for the TCP response function for packet drop rates up to 10% or so; for these environments, the sending rate in bytes per RTT is roughly 1.2 s/sqrt(p), for a packet size of s bytes and packet drop rate p.
下表显示了标准（SACK）TCP流的模拟结果，其中，对于每个*字节*，包含该字节的数据包以概率p丢弃。考虑TCP响应函数对丢包率的近似10%左右；对于这些环境，每个RTT的发送速率（以字节为单位）约为1.2 s/sqrt（p），数据包大小为s字节，数据包丢弃速率为p。
Given a fixed *byte* drop rate p1, and a TCP packet size of s bytes, the packet drop rate is roughly s*p1, producing a sending rate in bytes per RTT of roughly 1.2 sqrt(s)/sqrt(p1). Thus, for TCP in an environment with a fixed byte drop rate, the sending rate should grow roughly as sqrt(s), for packet drop rates up to 10% or so.
给定固定的*字节*丢弃率p1和s字节的TCP数据包大小，数据包丢弃率大致为s*p1，每RTT产生的发送率（以字节为单位）约为1.2 sqrt（s）/sqrt（p1）。因此，对于具有固定字节丢弃率的环境中的TCP，对于高达10%左右的数据包丢弃率，发送速率应大致增长为sqrt。
Each row of Table 5 below shows a separate simulation with ten TCP connections and a fixed byte drop rate of 0.0001, with each simulation using a different segment size. For each simulation, the TCP sending rate and goodput are averaged over the ten flows. As one would expect from the paragraph above, the TCP sending rate grows somewhat less than linearly with an increase in packet size, up to a packet size of 1460 bytes, corresponding to a packet drop rate of 13%. After that, further increases in the packet size result in a *decrease* in the TCP sending rate, as the TCP connection enters the regime of exponential backoff of the retransmit timer.
下表5的每一行显示了一个单独的模拟，其中有十个TCP连接，固定字节丢弃率为0.0001，每个模拟使用不同的段大小。对于每个模拟，TCP发送速率和goodput在十个流上取平均值。正如人们从上面的段落中所期望的那样，TCP发送速率随着分组大小的增加而稍微小于线性地增长，达到1460字节的分组大小，对应于13%的分组丢弃率。之后，当TCP连接进入重传定时器的指数退避的状态时，分组大小的进一步增加导致TCP发送速率的*降低*。
Segment Packet TCP Rates (Kbps)
Size (B) DropRate SendRate Goodput
-------- -------- -------- -------
14 0.005 6.37 6.34
128 0.016 30.78 30.30
256 0.028 46.54 44.96
512 0.053 62.43 58.37
1460 0.134 94.15 80.02
4000 0.324 35.20 21.44
8000 0.531 15.36 5.76
Segment Packet TCP Rates (Kbps)
Size (B) DropRate SendRate Goodput
-------- -------- -------- -------
14 0.005 6.37 6.34
128 0.016 30.78 30.30
256 0.028 46.54 44.96
512 0.053 62.43 58.37
1460 0.134 94.15 80.02
4000 0.324 35.20 21.44
8000 0.531 15.36 5.76
Table 5: TCP Median Send Rate vs. Packet Size I: Byte Drop Rate 0.0001
表5:TCP中间发送速率与数据包大小I:Byte Drop Rate 0.0001
Table 6 below shows similar results for a byte drop rate of 0.001. In this case, the TCP sending rate grows with increasing packet size up to a packet size of 128 bytes, corresponding to a packet drop rate of 16%. After that, the TCP sending rate decreases and then increases again, as the TCP connection enters the regime of exponential backoff of the retransmit timer. Note that with this byte drop rate, with packet sizes of 4000 and 8000 bytes, the TCP sending rate increases but the TCP goodput rate remains essentially zero. This makes sense, as almost all packets that are sent are dropped.
下表6显示了字节丢失率为0.001的类似结果。在这种情况下，TCP发送速率随着分组大小的增加而增加，最大分组大小为128字节，对应于16%的分组丢弃率。之后，随着TCP连接进入重传计时器的指数退避状态，TCP发送速率先降低，然后再次增加。请注意，使用此字节丢弃率，当数据包大小为4000和8000字节时，TCP发送速率会增加，但TCP goodput速率基本上保持为零。这是有道理的，因为几乎所有发送的数据包都会被丢弃。
Segment Packet TCP Rates (Kbps)
Size (B) DropRate SendRate Goodput
-------- -------- -------- -------
14 0.053 1.68 1.56
128 0.159 7.66 6.13
256 0.248 6.21 4.32
512 0.402 1.84 1.11
1460 0.712 1.87 0.47
4000 0.870 3.20 0.00
8000 0.890 5.76 0.00
Segment Packet TCP Rates (Kbps)
Size (B) DropRate SendRate Goodput
-------- -------- -------- -------
14 0.053 1.68 1.56
128 0.159 7.66 6.13
256 0.248 6.21 4.32
512 0.402 1.84 1.11
1460 0.712 1.87 0.47
4000 0.870 3.20 0.00
8000 0.890 5.76 0.00
Table 6: TCP Median Send Rate vs. Packet Size II: Byte Drop Rate 0.001
表6:TCP中间发送速率与数据包大小II:Byte Drop Rate 0.001
The TCP behavior in the presence of a fixed byte drop rate suggests that instead of the goal of a TFRC-SP flow achieving the same sending rate in bytes per second as a TCP flow using 1500-byte packets, it makes more sense to consider an ideal goal of a TFRC-SP flow achieving the same sending rate as a TCP flow with the optimal packet size, given that the packet size is at most 1500 bytes. This does not mean that we need to change the TFRC-SP mechanisms for computing the allowed transmit rate; this means simply that in evaluating the fairness of TFRC-SP, we should consider fairness relative to the TCP flow using the optimal packet size (though still at most 1500 bytes) for that environment.
在固定字节丢弃率存在下的TCP行为表明，代替TFRC-SP流以每秒字节相同的发送速率作为使用1500字节分组的TCP流的目标，考虑TFRC-SP流的理想目标与实现具有最佳分组大小的TCP流相同的发送速率更有意义。假设数据包大小最多为1500字节。这并不意味着我们需要改变TFRC-SP机制来计算允许的传输速率；这意味着，在评估TFRC-SP的公平性时，我们应该考虑相对于该TCP流的公平性，使用最优分组大小（尽管仍然最多为1500字节）用于该环境。
This document doesn't specify TFRC-SP behavior in terms of packet fragmentation and Path MTU Discovery (PMTUD). That is, should the transport protocol using TFRC-SP use PMTUD information to set an upper bound on the segment size? Should the transport protocol allow packets to be fragmented in the network? We leave these as questions for the transport protocol. As an example, we note that DCCP requires that endpoints keep track of the current PMTU, and says that fragmentation should not be the default (Section 14 of [RFC4340]).
本文档未就数据包碎片和路径MTU发现（PMTUD）指定TFRC-SP行为。也就是说，使用TFRC-SP的传输协议是否应该使用PMTUD信息来设置段大小的上限？传输协议是否应允许数据包在网络中分段？我们将这些问题留给传输协议。例如，我们注意到，DCCP要求端点跟踪当前的PMTU，并表示不应将碎片作为默认值（RFC4340）的第14节）。
When TFRC-SP is used with a nominal segment size s of 1460 bytes on a path where the TCP MSS is in fact only 536 bytes, the TFRC-SP flow could receive almost three times the bandwidth, in bytes per second, as that of a TCP flow using an MSS of 536 bytes. Similarly, in an environment with an MSS close to 4000 bytes, a TCP flow could receive almost three times the bandwidth of a TFRC-SP flow with its nominal segment size s of 1460 bytes. In both cases, we feel that these levels of "unfairness" with factors of two or three are acceptable; in particular, they won't result in one flow grabbing all of the
当TFRC-SP在TCP MSS实际上仅为536字节的路径上与1460字节的标称段大小s一起使用时，TFRC-SP流可接收的带宽几乎是使用536字节MSS的TCP流带宽的三倍（以字节/秒为单位）。类似地，在MSS接近4000字节的环境中，TCP流可以接收的带宽几乎是TFRC-SP流的三倍，其标称段大小为1460字节。在这两种情况下，我们都认为这两个或三个因素的“不公平”程度是可以接受的；特别是，它们不会导致一个流捕获所有流
available bandwidth, to the exclusion of the competing TCP or TFRC-SP flow.
可用带宽，不包括竞争的TCP或TFRC-SP流。
All IPv4 *end hosts* are required to accept and reassemble IP packets of size 576 bytes [RFC791], but IPv4 *links* do not necessarily have to support this packet size. In slow networks, the largest possible packet may take a considerable amount of time to send [RFC3819], and a smaller MTU may be desirable, e.g., hundreds of bytes. If the first-hop link had a small MTU, then TCP would choose an appropriately small MSS [RFC879]. [RFC1144] quotes cases of very low link speeds where the MSS may be tens of bytes (and notes this is an extreme case). We note that if TFRC-SP is used over a path with an MTU considerably smaller than 576 bytes, and the TFRC-SP flow uses a nominal segment size s of 1460 bytes, then the TFRC-SP flow could receive considerably more than three times the bandwidth of competing TCP flows.
所有IPv4*终端主机*都需要接受和重新组装大小为576字节的IP数据包[RFC791]，但IPv4*链路*不一定必须支持此数据包大小。在慢速网络中，最大可能的数据包可能需要相当长的时间来发送[RFC3819]，并且可能需要较小的MTU，例如数百字节。如果第一跳链路有一个小MTU，那么TCP将选择一个适当小的MSS[RFC879]。[RFC1144]引用了链路速度非常低的情况，其中MSS可能为数十个字节（注意这是一种极端情况）。我们注意到，如果TFRC-SP在MTU大大小于576字节的路径上使用，并且TFRC-SP流使用1460字节的标称段大小s，那么TFRC-SP流可以接收相当于竞争TCP流带宽三倍以上的带宽。
If TFRC-SP is used with a nominal segment size s of less than 536 bytes (because the path MTU is known to be less than 576 bytes), then TFRC-SP is likely to be of minimal benefit to applications. If TFRC-SP was to be used on paths that have a path MTU of considerably less than 576 bytes, and the transport protocol was not required to keep track of the path MTU, this could result in the TFRC-SP flow using the default nominal segment size of 1460 bytes, and as a result receiving considerably more bandwidth than competing TCP flows. As a result, TFRC-SP is not recommended for use with transport protocols that don't maintain some knowledge of the path MTU.
如果TFRC-SP的标称段大小s小于536字节（因为已知路径MTU小于576字节），则TFRC-SP对应用程序的好处可能最小。如果TFRC-SP要在路径MTU大大小于576字节的路径上使用，并且不需要传输协议来跟踪路径MTU，这可能会导致TFRC-SP流使用默认的标称段大小1460字节，从而接收比竞争TCP流多得多的带宽。因此，不建议将TFRC-SP用于对MTU路径没有一定了解的传输协议。
For a TFRC-SP receiver, the guidelines from Section 6 of RFC 3448 govern when the receiver should send feedback messages. In particular, from [RFC3448], "a feedback packet should ... be sent whenever a new loss event is detected without waiting for the end of an RTT". In addition, feedback packets are sent at least once per RTT.
对于TFRC-SP接收器，RFC 3448第6节的指南规定了接收器何时应发送反馈消息。特别是，在[RFC3448]中，“在不等待RTT结束的情况下，只要检测到新的丢失事件，就应该……发送反馈数据包”。此外，每个RTT至少发送一次反馈数据包。
For a TFRC-SP connection with a short current loss interval (less than two round-trip times), it is possible for the loss interval length calculated for that loss interval to change in odd ways as additional packet losses in that loss interval are detected. To prevent unnecessary oscillations in the average loss interval, Section 3 specifies that the current loss interval can be included in the calculation of the average loss interval only if the current loss interval is longer than two round-trip times.
对于具有短电流损耗间隔（小于两个往返时间）的TFRC-SP连接，当检测到该损耗间隔中的额外数据包损耗时，为该损耗间隔计算的损耗间隔长度可能以奇数方式变化。为了防止平均损耗间隔中出现不必要的振荡，第3节规定，只有当电流损耗间隔大于两个往返时间时，才可将电流损耗间隔包括在平均损耗间隔的计算中。
RFC 3714 considers the problems of fairness, potential congestion collapse, and poor user quality that could occur with the deployment of non-congestion-controlled IP telephony over congested best-effort networks. The March 2004 document cites ongoing efforts in the IETF, including work on TFRC and DCCP. RFC 3714 recommends that for best-effort traffic with applications that have a fixed or minimum sending rate, the application or transport protocol should monitor the packet drop rate, and discontinue sending for a period if the steady-state packet drop rate significantly exceeds the allowed threshold for that minimum sending rate.
RFC 3714考虑了在拥挤的尽力而为网络上部署非拥塞控制IP电话时可能出现的公平性、潜在拥塞崩溃和用户质量差等问题。2004年3月的文件引用了IETF正在进行的工作，包括TFRC和DCCP方面的工作。RFC 3714建议，对于具有固定或最小发送速率的应用程序的尽力而为流量，应用程序或传输协议应监控分组丢弃速率，并在稳态分组丢弃速率显著超过该最小发送速率的允许阈值时停止发送一段时间。
In determining the allowed packet drop rate for a fixed sending rate, RFC 3714 assumes that an IP telephony flow should be allowed to use the same sending rate in bytes per second as a 1500-byte packet TCP flow experiencing the same packet drop rate as that of the IP telephony flow. As an example, following this guideline, a VoIP connection with a round-trip time of 0.1 sec and a minimum sending rate of 64 Kbps would be required to terminate or suspend when the persistent packet drop rate significantly exceeded 25%.
在确定固定发送速率的允许分组丢弃率时，RFC 3714假设应允许IP电话流使用与经历与IP电话流相同分组丢弃率的1500字节分组TCP流相同的发送速率（以字节/秒为单位）。例如，根据本指南，当持续丢包率显著超过25%时，需要终止或挂起往返时间为0.1秒、最小发送速率为64 Kbps的VoIP连接。
One limitation of the lack of fine-grained control in the minimal mechanism described in RFC 3714 is that an IP telephony flow would not adapt its sending rate in response to congestion. In contrast, with TFRC-SP, a small-packet flow would reduce its sending rate somewhat in response to moderate packet drop rates, possibly avoiding a period with unnecessarily-heavy packet drop rates.
RFC 3714中描述的最小机制中缺少细粒度控制的一个限制是IP电话流不会调整其发送速率以响应拥塞。相比之下，对于TFRC-SP，小数据包流将在一定程度上降低其发送速率，以响应中等数据包丢弃率，可能避免出现不必要的高数据包丢弃率。
Because RFC 3714 assumes that the allowed packet drop rate for an IP telephony flow is determined by the sending rate that a TCP flow would use *with the same packet drop rate*, the minimal mechanism in RFC 3714 would not provide fairness between TCP and IP telephony traffic in an environment where small packets are less likely to be dropped than large packets. In such an environment, the small-packet IP telephony flow would make the optimistic assumption that a large-packet TCP flow would receive the same packet drop rate as the IP telephony flow, and as a result the small-packet IP telephony flow would receive a larger fraction of the link bandwidth than a competing large-packet TCP flow.
因为RFC 3714假定IP电话流的允许分组丢弃率由TCP流将使用的发送速率*以相同的分组丢弃率*确定，在小数据包比大数据包更不可能被丢弃的环境中，RFC 3714中的最小机制不能在TCP和IP电话流量之间提供公平性。在这样的环境中，小包IP电话流将作出乐观的假设，即大包TCP流将接收与IP电话流相同的分组丢弃率，并且因此小包IP电话流将接收比竞争的大包TCP流更大的链路带宽的一部分。
One possible use for TFRC-SP would be with applications that maintain a fixed sending rate in packets per second, but modify their packet size in response to congestion. TFRC-SP monitors the connection's packet drop rate, and determines the allowed sending rate in bytes per second. Given an application with a fixed sending rate in
TFRC-SP的一个可能用途是应用程序保持固定的发送速率（以每秒数据包为单位），但根据拥塞情况修改数据包大小。TFRC-SP监视连接的数据包丢弃率，并确定允许的发送速率（以字节/秒为单位）。给定一个应用程序，在中具有固定的发送速率
packets per second, the TFRC-SP sender could determine the data packet size that would be needed for the sending rate in bytes per second not to exceed the allowed sending rate. In environments where the packet drop rate is affected by the packet size, decreasing the packet size could also result in a decrease in the packet drop rate experienced by the flow.
每秒数据包数，TFRC-SP发送方可以确定数据包大小，以字节/秒为单位的发送速率不超过允许的发送速率所需的数据包大小。在分组丢弃率受分组大小影响的环境中，减小分组大小还可能导致流经历的分组丢弃率降低。
There are many questions about how an adaptive application would use TFRC-SP that are beyond the scope of this document. In particular, an application might wish to avoid unnecessary reductions in the packet size. In this case, an application might wait for some period of time before reducing the packet size, to avoid an unnecessary reduction in the packet size. The details of how long an application might wait before reducing the packet size can be addressed in documents that are more application-specific.
关于自适应应用程序如何使用TFRC-SP，有许多问题超出了本文档的范围。具体而言，应用程序可能希望避免不必要的数据包大小减少。在这种情况下，应用程序可能在减小数据包大小之前等待一段时间，以避免不必要地减小数据包大小。应用程序在减少数据包大小之前可能等待多长时间的详细信息可以在更特定于应用程序的文档中解决。
Similarly, an application using TFRC-SP might only have a few packet sizes that it is able to use. In this case, the application might not reduce the packet size until the current packet drop rate has significantly exceeded the packet drop rate threshold for the current sending rate, to avoid unnecessary oscillations between two packet sizes and two sending rates. Again, the details will have to be addressed in documents that are more application-specific.
类似地，使用TFRC-SP的应用程序可能只能使用几个数据包大小。在这种情况下，在当前分组丢弃率显著超过当前发送速率的分组丢弃率阈值之前，应用程序可能不会减小分组大小，以避免两个分组大小和两个发送速率之间不必要的振荡。更多细节将在应用程序中再次说明。
Because the allowed sending rate in TFRC-SP is in bytes per second rather than in packets per second, there is little opportunity for applications to manipulate the packet size in order to "game" the system. This differs from TFRC in CCID 3 (Section 5.3 of [RFC4342]), where the allowed sending rate is in packets per second. In particular, a TFRC-SP application that sends small packets for a while, building up a fast sending rate, and then switches to large packets, would not increase its overall sending rate by the change of packet size.
由于TFRC-SP中允许的发送速率是以字节/秒为单位，而不是以数据包/秒为单位，因此应用程序几乎没有机会操纵数据包大小以“游戏”系统。这不同于CCID 3（RFC4342）中的TFRC（第5.3节），其中允许的发送速率为每秒包数。特别是，TFRC-SP应用程序发送小数据包一段时间，建立快速发送速率，然后切换到大数据包，不会通过改变数据包大小来增加其总体发送速率。
This section describes the performance of TFRC-SP in simulation scenarios with configured packet or byte drop rates, and in scenarios with a range of queue management mechanisms at the congested link. The simulations, described in detail in Appendix B, explore environments where standard TFRC significantly limits the throughput of small-packet flows, and TFRC-SP gives the desired throughput. The simulations also explore environments where standard TFRC allows small-packet flows to receive good performance, while TFRC-SP is overly aggressive.
本节描述了TFRC-SP在具有配置的数据包或字节丢弃率的模拟场景中的性能，以及在拥塞链路上具有一系列队列管理机制的场景中的性能。附录B中详细描述的模拟探索了标准TFRC显著限制小数据包流吞吐量的环境，TFRC-SP提供了所需吞吐量。模拟还探索了标准TFRC允许小数据包流获得良好性能，而TFRC-SP过于激进的环境。
The general lessons from the simulations are as follows.
模拟的一般经验教训如下。
o In scenarios where large and small packets receive similar packet drop rates, TFRC-SP gives roughly the desired sending rate (Appendix B.1, B.2).
o 在大小数据包接收相似数据包丢弃率的情况下，TFRC-SP给出了大致所需的发送率（附录B.1，B.2）。
o In scenarios where each *byte* is equally likely to be dropped, standard TFRC gives reasonable fairness between small-packet TFRC flows and large-packet TCP flows (Appendix B.2).
o 在每个*字节*都有可能被丢弃的情况下，标准TFRC在小数据包TFRC流和大数据包TCP流之间提供了合理的公平性（附录B.2）。
o In scenarios where small packets are less likely to be dropped than large packets, TFRC-SP does not give reasonable fairness between small-packet TFRC-SP flows and large-packet TCP flows; small-packet TFRC-SP flows can receive considerably more bandwidth than competing large-packet TCP flows, and in some cases large-packet TCP flows can be essentially starved by competing small-packet TFRC-SP flows (Appendix B.2, B.3, B.4).
o 在小数据包比大数据包更不可能被丢弃的情况下，TFRC-SP不能在小数据包TFRC-SP流和大数据包TCP流之间提供合理的公平性；小包TFRC-SP流可以接收比竞争的大包TCP流多得多的带宽，并且在某些情况下，竞争的小包TFRC-SP流基本上会耗尽大包TCP流（附录B.2、B.3、B.4）。
o Scenarios where small packets are less likely to be dropped than large packets include those with Drop-Tail queues in bytes, and with AQM mechanisms in byte mode (Appendix B.3, B.4). It has also been reported that wireless links are sometimes good enough to let small packets through, while larger packets have a much higher error rate, and hence a higher drop probability [S05].
o 小数据包比大数据包更不可能被丢弃的场景包括以字节为单位的丢弃尾队列，以及以字节模式为单位的AQM机制（附录B.3，B.4）。也有报道称，无线链路有时足以让小数据包通过，而较大的数据包具有更高的错误率，因此丢弃概率更高[S05]。
Dropping rates for small packets: The goal of TFRC-SP is for small-packet TFRC-SP flows to have rough fairness with large-packet TCP flows in the sending rate in bps, in a scenario where each packet receives roughly the same probability of being dropped. In a scenario where large packets are more likely to be dropped than small packets, or where flows with a bursty sending rate are more likely to have packets dropped than are flows with a smooth sending rate, small-packet TFRC-SP flows can receive significantly more bandwidth than competing large-packet TCP flows.
小包丢弃率：TFRC-SP的目标是使小包TFRC-SP流在发送速率（以bps为单位）上与大包TCP流具有大致的公平性，在这种情况下，每个包接收到的丢弃概率大致相同。在发送小数据包的情况下，流可能比发送大数据包的情况下具有更高的丢包率，在发送小数据包的情况下，流可能比接收大数据包的情况下具有更高的丢包率。
The accuracy of the TCP response function used in TFRC: For applications with a maximum sending rate of 96 Kbps or less (i.e., packets of at most 120 bytes), TFRC-SP only restricts the sending rate when the packet drop rate is fairly high, e.g., greater than 10%. [Derivation: A TFRC-SP flow with a 200 ms round-trip time and a maximum sending rate with packet headers of 128 Kbps would have a sending rate in bytes per second equivalent to a TCP flow with 1460- byte segments sending 2.2 packets per round-trip time. From Table 1 of RFC 3714, this sending rate can be sustained with a packet drop rate slightly greater than 10%.] In this high-packet-drop regime, the performance of TFRC-SP is determined in part by the accuracy of
TFRC中使用的TCP响应函数的准确性：对于最大发送速率为96 Kbps或更低的应用程序（即最多120字节的数据包），TFRC-SP仅在数据包丢弃率相当高（例如大于10%）时限制发送速率。[推导：TFRC-SP流的往返时间为200毫秒，包头最大发送速率为128 Kbps，其发送速率以字节/秒为单位，相当于TCP流的1460字节段每往返时间发送2.2个包。根据RFC 3714的表1，该发送速率可在丢包率略为g的情况下维持大于10%。]在这种高丢包情况下，TFRC-SP的性能部分取决于
the TCP response function in representing the actual sending rate of a TCP connection.
TCP响应函数，表示TCP连接的实际发送速率。
In the regime of high packet drop rates, TCP performance is also affected by the TCP algorithm (e.g., SACK or not), the minimum RTO, the use of Limited Transmit (or lack thereof), the use of ECN, and the like. It is good to ensure that simulations or experiments exploring fairness include the exploration of fairness with the most aggressive TCP mechanisms conformant with the current standards. Our simulations use SACK TCP with Limited Transmit and with a minimum RTO of 200 ms. The simulation results are largely the same with or without timestamps; timestamps were not used for simulations reported in this paper. We didn't use TCP with ECN in setting the target sending rate for TFRC, because, as explained in Appendix B.1, our expectation is that in high packet drop regimes, routers will drop rather than mark packets, either from policy or from buffer overflow.
在高分组丢弃率的情况下，TCP性能还受TCP算法（例如，SACK与否）、最小RTO、有限传输的使用（或缺乏限制传输）、ECN的使用等的影响。最好确保探索公平性的模拟或实验包括探索符合当前标准的最具攻击性的TCP机制的公平性。我们的模拟使用SACK TCP，传输受限，最小RTO为200ms。模拟结果在有或没有时间戳的情况下基本相同；本文报告的模拟没有使用时间戳。我们没有在设置TFRC的目标发送速率时使用TCP和ECN，因为正如附录B.1中所解释的，我们的预期是，在高丢包状态下，路由器将丢包而不是标记数据包，无论是来自策略还是来自缓冲区溢出。
Fairness with different packet header sizes: In an environment with IPv6 and/or several layers of network-layer tunnels (e.g., IPsec, Generic Routing Encapsulation (GRE)), the packet header could be 60, 80, or 100 bytes instead of the default 40 bytes assumed in Section 3. For an application with small ten-byte data segments, this means that the actual packet size could be 70, 90, or 110 bytes, instead of the 50 bytes assumed by TFRC-SP in calculating the allowed sending rate. Thus, a TFRC-SP application with large headers could receive more than twice the bandwidth (including the bandwidth used by headers) than a TFRC-SP application with small headers. We do not expect this to be a problem; in particular, TFRC-SP applications with large headers will not significantly degrade the performance of competing TCP applications, or of competing TFRC-SP applications with small headers.
不同数据包头大小的公平性：在具有IPv6和/或多层网络层隧道（例如IPsec、通用路由封装（GRE））的环境中，数据包头可以是60、80或100字节，而不是第3节中假定的默认40字节。对于具有小10字节数据段的应用程序，这意味着实际数据包大小可以是70、90或110字节，而不是TFRC-SP在计算允许发送速率时假定的50字节。因此，与具有小标头的TFRC-SP应用程序相比，具有大标头的TFRC-SP应用程序可以接收两倍以上的带宽（包括标头使用的带宽）。我们不认为这是一个问题；特别是，具有大报头的TFRC-SP应用程序不会显著降低竞争TCP应用程序或具有小报头的竞争TFRC-SP应用程序的性能。
General issues for TFRC: The congestion control mechanisms in TFRC and TFRC-SP limit a flow's sending rate in packets per second. Simulations by Tom Phelan [P04] explore how such a limitation in sending rate can lead to unfairness for the TFRC flow in some scenarios, e.g., when competing with bursty TCP web traffic, in scenarios with low levels of statistical multiplexing at the congested link.
TFRC的一般问题：TFRC和TFRC-SP中的拥塞控制机制限制流的发送速率（以每秒数据包为单位）。Tom Phelan的模拟[P04]探讨了在某些情况下，发送速率的这种限制如何导致TFRC流不公平，例如，在拥塞链路上统计复用水平较低的情况下，与突发TCP web流量竞争时。
There are no new security considerations introduced in this document.
本文档中没有引入新的安全注意事项。
The issues of the fairness of TFRC-SP with standard TFRC and TCP in a range of environments, including those with byte-based queue management at the congested routers, are discussed extensively in the main body of this document.
本文主体部分广泛讨论了TFRC-SP在一系列环境中的公平性问题，包括在拥塞路由器上使用基于字节的队列管理的环境。
General security considerations for TFRC are discussed in RFC 3448. As with TFRC in RFC 3448, TFRC-SP 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. As discussed for TFRC in RFC 3448, any transport protocol that uses TFRC-SP needs to protect against spoofed feedback, and to protect the congestion control mechanisms against incorrect information from the receiver. Again as discussed for TFRC in RFC 3448, we expect that protocols incorporating ECN with TFRC-SP will want to use the ECN nonce [RFC3540] to protect the sender from the accidental or malicious concealment of marked packets
RFC 3448中讨论了TFRC的一般安全注意事项。与RFC 3448中的TFRC一样，TFRC-SP本身不是一种传输协议，而是一种旨在与传输协议结合使用的拥塞控制机制。因此，主要需要在特定传输协议及其身份验证机制的上下文中考虑安全性。正如RFC 3448中针对TFRC所讨论的，任何使用TFRC-SP的传输协议都需要防止欺骗反馈，并保护拥塞控制机制免受来自接收器的错误信息的影响。同样如RFC 3448中针对TFRC所讨论的，我们期望结合ECN和TFRC-SP的协议将希望使用ECN nonce[RFC3540]来保护发送方免受标记数据包的意外或恶意隐藏
Security considerations for DCCP's Congestion Control ID 3, TFRC Congestion Control, the transport protocol that uses TFRC, are discussed in [RFC4342]. That document extensively discussed the mechanisms the sender can use to verify the information sent by the receiver, including the use of the ECN nonce.
[RFC4342]中讨论了DCCP拥塞控制ID 3、TFRC拥塞控制（使用TFRC的传输协议）的安全注意事项。该文件广泛讨论了发送方可用于验证接收方发送的信息的机制，包括ECN nonce的使用。
This document has specified TFRC-SP, a Small-Packet (SP) variant of TFRC, designed for applications that send small packets, with at most a hundred packets per second, but that desire the same sending rate in bps as a TCP connection experiencing the same packet drop rate but sending packets of 1500 bytes. TFRC-SP competes reasonably well with large-packet TCP and TFRC flows in environments where large-packet flows and small-packet flows experience similar packet drop rates, but receives more than its share of the bandwidth in bps in environments where small packets are less likely to be dropped or marked than are large packets. As a result, TFRC-SP is experimental, and is not intended for widespread deployment at this time in the global Internet.
本文档指定了TFRC-SP，TFRC的一种小包（SP）变体，专为发送小包（每秒最多100个包）的应用程序而设计，但需要与经历相同丢包率但发送1500字节包的TCP连接相同的发送速率（bps）。TFRC-SP在大数据包流和小数据包流经历相似丢包率的环境中与大数据包TCP和TFRC流竞争相当好，但在小数据包比大数据包更不可能被丢包或标记的环境中，接收的带宽超过其在bps中的份额。因此，TFRC-SP是实验性的，目前不打算在全球互联网上广泛部署。
In order to allow experimentation with TFRC-SP in the Datagram Congestion Control Protocol (DCCP), an experimental Congestion Control IDentifier (CCID) will be used, based on TFRC-SP but specified in a separate document.
为了允许在数据报拥塞控制协议（DCCP）中使用TFRC-SP进行实验，将使用基于TFRC-SP但在单独文件中指定的实验拥塞控制标识符（CCID）。
We thank Tom Phelan for discussions of TFRC-SP and for his paper exploring the fairness between TCP and TFRC-SP flows. We thank Lars Eggert, Gorry Fairhurst, Mark Handley, Miguel Garcia, Ladan Gharai, Richard Nelson, Colin Perkins, Juergen Quittek, Pete Sholander, Magnus Westerlund, and Joerg Widmer for feedback on earlier versions of this document. We also thank the DCCP Working Group for feedback and discussions.
我们感谢Tom Phelan对TFRC-SP的讨论以及他关于TCP和TFRC-SP流之间公平性的论文。我们感谢Lars Eggert、Gorry Fairhurst、Mark Handley、Miguel Garcia、Ladan Gharai、Richard Nelson、Colin Perkins、Juergen Quitek、Pete Sholander、Magnus Westerlund和Joerg Widmer对本文件早期版本的反馈。我们还感谢DCCP工作组的反馈和讨论。
Other proposals for variants of TFRC for applications with variable packet sizes include [WBL04] and [V00]. [V00] proposed that TFRC should be modified so that flows are not penalized by sending smaller packets. In particular, [V00] proposes using the path MTU in the TCP-friendly equation, instead of the actual packet size used by TFRC, and counting the packet drop rate by using an estimation algorithm that aggregates both packet drops and received packets into MTU-sized units.
对于具有可变数据包大小的应用程序，TFRC变体的其他建议包括[WBL04]和[V00]。[V00]建议修改TFRC，以便流不会因发送较小的数据包而受到惩罚。具体而言，[V00]建议在TCP友好方程中使用路径MTU，而不是TFRC使用的实际数据包大小，并通过使用将数据包丢弃和接收数据包聚合为MTU大小单位的估计算法来计算数据包丢弃率。
[WBL04] also argues that adapting TFRC for variable packet sizes by just using the packet size of a reference TCP flow in the TFRC equation would not suffice in the high-packet-loss regime; such a modified TFRC would have a strong bias in favor of smaller packets, because multiple lost packets in a single round-trip time would be aggregated into a single packet loss. [WBL04] proposes modifying the loss measurement process to account for the bias in favor of smaller packets.
[WBL04]还认为，仅使用TFRC方程中参考TCP流的数据包大小来调整TFRC以适应可变数据包大小在高数据包丢失情况下是不够的；这种改进的TFRC将有利于较小的数据包，因为在单个往返时间内多个丢失的数据包将聚合为单个数据包丢失。[WBL04]建议修改损耗测量过程，以考虑有利于较小数据包的偏差。
The TFRC-SP variant of TFRC proposed in our document differs from [WBL04] in restricting its attention to flows that send at most 100 packets per second. The TFRC-SP variant proposed in our document also differs from the straw proposal discussed in [WBL04] in that the allowed bandwidth includes the bandwidth used by packet headers.
我们在文档中提出的TFRC的TFRC-SP变体与[WBL04]不同，它将注意力限制在每秒最多发送100个数据包的流上。我们在文件中提出的TFRC-SP变体也不同于[WBL04]中讨论的STROW方案，因为允许的带宽包括数据包头使用的带宽。
[WBL04] discusses four methods for modifying the loss measurement process, "unbiasing", "virtual packets", "random sampling", and "Loss Insensitive Period (LIP) scaling". [WBL04] finds only the second and third methods sufficiently robust when the network drops packets independently of packet size. They find only the second method sufficiently robust when the network is more likely to drop large packets than small packets. Our method for calculating the loss event rate is somewhat similar to the random sampling method proposed in [WBL04], except that randomization is not used; instead of randomization, the exact packet loss rate is computed for short loss intervals, and the standard loss event rate calculation is used for longer loss intervals. [WBL04] includes simulations with a Bernoulli loss model, a Bernoulli loss model with a drop rate varying over time, and a Gilbert loss model, as well as more realistic simulations with a range of TCP and TFRC flows.
[WBL04]讨论了修改损耗测量过程的四种方法，“无偏”、“虚拟数据包”、“随机采样”和“损耗不敏感周期（LIP）缩放”。[WBL04]发现，当网络丢弃独立于数据包大小的数据包时，只有第二和第三种方法具有足够的鲁棒性。他们发现，当网络更可能丢弃大数据包而不是小数据包时，只有第二种方法具有足够的鲁棒性。我们计算损失事件率的方法与[WBL04]中提出的随机抽样方法有些相似，只是没有使用随机化；对于较短的丢失间隔，计算准确的数据包丢失率，对于较长的丢失间隔，使用标准丢失事件率计算，而不是随机化。[WBL04]包括伯努利损失模型、下降率随时间变化的伯努利损失模型和吉尔伯特损失模型的模拟，以及一系列TCP和TFRC流的更真实模拟。
[WBL04] produces both a byte-mode and a packet-mode variant of the TFRC transport protocol, for connections over paths with per-byte and per-packet dropping respectively. We would argue that in the absence of transport-level mechanisms for determining whether the packet dropping in the network is per-packet, per-byte, or somewhere in between, a single TFRC implementation is needed, independently of the
[WBL04]产生TFRC传输协议的字节模式和数据包模式变体，分别用于每字节和每数据包丢弃路径上的连接。我们认为，如果没有传输级机制来确定网络中的分组丢弃是每个分组、每个字节还是介于两者之间，则需要独立于
packet-dropping behaviors of the routers along the path. It would of course be preferable to have a mechanism that gives roughly acceptable behavior, to the connection and to the network as a whole, on paths with both per-byte and per-packet dropping (and on paths with multiple congested routers, some with per-byte dropping mechanisms, some with per-packet dropping mechanisms, and some with dropping mechanisms that lie somewhere between per-byte and per-packet).
路由器沿路径的丢包行为。当然，最好有一种机制，在每字节和每包丢弃的路径上，为连接和整个网络提供大致可接受的行为（并且在具有多个拥塞路由器的路径上，有些具有每字节丢弃机制，有些具有每包丢弃机制，有些具有介于每字节和每包之间的丢弃机制）。
An important contribution would be to investigate the range of behaviors actually present in today's networks, in terms of packet dropping as a function of packet size.
一个重要的贡献将是调查当今网络中实际存在的行为范围，即作为数据包大小函数的数据包丢弃。
This appendix reports on the simulation results outlined in Section 7. TFRC-SP has been added to the NS simulator, and is illustrated in the validation test "./test-all-friendly" in the directory tcl/tests. The simulation scripts and graphs for the simulations in this document are available at [VOIPSIMS].
本附录报告了第7节中概述的模拟结果。TFRC-SP已添加到NS模拟器中，并在目录tcl/tests中的验证测试“/test all-friendly”中进行了说明。本文件中的仿真脚本和仿真图可在[VOIPSIMS]上获得。
In this section we describe simulation results from simulations comparing the throughput of standard (SACK) TCP flows, TCP flows with timestamps and ECN, TFRC-SP flows, and standard TFRC (Stnd TFRC) flows. In these simulations we configure the router to randomly drop or mark packets at a specified rate, independently of the packet size. For each specified packet drop rate, we give a flow's average sending rate in Kbps over the second half of a 100-second simulation, averaged over ten flows.
在本节中，我们描述了比较标准（SACK）TCP流、带时间戳的TCP流和ECN、TFRC-SP流以及标准TFRC（Stnd TFRC）流吞吐量的模拟结果。在这些模拟中，我们将路由器配置为以指定速率随机丢弃或标记数据包，与数据包大小无关。对于每个指定的数据包丢弃率，我们给出了在100秒模拟的后半部分中，流的平均发送速率（以Kbps为单位），在10个流中取平均值。
Packet Send Rates (Kbps, 1460B seg)
DropRate TCP ECN TCP TFRC
-------- -------- -------- --------
0.001 2020.85 1904.61 982.09
0.005 811.10 792.11 878.08
0.01 515.45 533.19 598.90
0.02 362.93 382.67 431.41
0.04 250.06 252.64 284.82
0.05 204.48 218.16 268.51
0.1 143.30 148.41 146.03
0.2 78.65 93.23* 55.14
0.3 26.26 59.65* 32.87
0.4 9.87 47.79* 25.45
0.5 3.53 32.01* 18.52
Packet Send Rates (Kbps, 1460B seg)
DropRate TCP ECN TCP TFRC
-------- -------- -------- --------
0.001 2020.85 1904.61 982.09
0.005 811.10 792.11 878.08
0.01 515.45 533.19 598.90
0.02 362.93 382.67 431.41
0.04 250.06 252.64 284.82
0.05 204.48 218.16 268.51
0.1 143.30 148.41 146.03
0.2 78.65 93.23* 55.14
0.3 26.26 59.65* 32.87
0.4 9.87 47.79* 25.45
0.5 3.53 32.01* 18.52
* ECN scenarios marked with an asterisk are not realistic, as routers are not recommended to mark packets when packet drop/mark rates are 20% or higher.
* 标有星号的ECN方案不现实，因为当数据包丢弃/标记率为20%或更高时，不建议路由器标记数据包。
Table 7: Send Rate vs. Packet Drop Rate I: 1460B TFRC Segments (1.184 Kbps Maximum TFRC Data Sending Rate)
表7：发送速率与丢包速率I:1460B TFRC段（最大TFRC数据发送速率为1.184 Kbps）
Table 7 shows the sending rate for a TCP and a standard TFRC flow for a range of configured packet drop rates, when both flows have 1460- byte data segments, in order to illustrate the relative fairness of TCP and TFRC when both flows use the same packet size. For example, a packet drop rate of 0.1 means that 10% of the TCP and TFRC packets are dropped. The TFRC flow is configured to send at most 100 packets per second. There is good relative fairness until the packet drop percentages reach 40 and 50%, when the TFRC flow receives three to five times more bandwidth than the standard TCP flow. We note that an ECN TCP flow would receive a higher throughput than the TFRC flow at these high packet drop rates, if ECN-marking was still being used instead of packet dropping. However, we don't use the ECN TCP sending rate in these high-packet-drop scenarios as the target sending rate for TFRC, as routers are advised to drop rather than mark packets during high levels of congestion (Section 7 of [RFC3168]). In addition, there is likely to be buffer overflow in scenarios with such high packet dropping/marking rates, forcing routers to drop packets instead of ECN-marking them.
表7显示了TCP和标准TFRC流在一系列配置的丢包率下的发送速率（当两个流都有1460字节的数据段时），以说明当两个流使用相同的数据包大小时TCP和TFRC的相对公平性。例如，数据包丢弃率为0.1意味着10%的TCP和TFRC数据包被丢弃。TFRC流配置为每秒最多发送100个数据包。当TFRC流接收到的带宽是标准TCP流的三到五倍时，在丢包率达到40%和50%之前，存在良好的相对公平性。我们注意到，如果仍然使用ECN标记而不是数据包丢弃，则在这些高数据包丢弃率下，ECN TCP流将接收到比TFRC流更高的吞吐量。然而，在这些高分组丢弃场景中，我们不使用ECN TCP发送速率作为TFRC的目标发送速率，因为建议路由器在高拥塞水平期间丢弃而不是标记分组（RFC3168第7节）。此外，在数据包丢弃/标记率如此之高的情况下，可能会出现缓冲区溢出，迫使路由器丢弃数据包，而不是使用ECN标记数据包。
< - - - - - - Send Rates (Kbps) - - - - - >
Packet TCP ECN TCP TFRC-SP Stnd TFRC
DropRate (1460B seg) (1460B seg) (14B seg) (14B seg)
-------- ----------- ----------- --------- ---------
0.001 1787.54 1993.03 17.71 17.69
0.005 785.11 823.75 18.11 17.69
0.01 533.38 529.01 17.69 17.80
0.02 317.16 399.62 17.69 13.41
0.04 245.42 260.57 17.69 8.84
0.05 216.38 223.75 17.69 7.63
0.1 142.75 138.36 17.69 4.29
0.2 58.61 91.54* 17.80 1.94
0.3 21.62 63.96* 10.26 1.00
0.4 10.51 41.74* 4.78 0.77
0.5 1.92 19.03* 2.41 0.56
< - - - - - - Send Rates (Kbps) - - - - - >
Packet TCP ECN TCP TFRC-SP Stnd TFRC
DropRate (1460B seg) (1460B seg) (14B seg) (14B seg)
-------- ----------- ----------- --------- ---------
0.001 1787.54 1993.03 17.71 17.69
0.005 785.11 823.75 18.11 17.69
0.01 533.38 529.01 17.69 17.80
0.02 317.16 399.62 17.69 13.41
0.04 245.42 260.57 17.69 8.84
0.05 216.38 223.75 17.69 7.63
0.1 142.75 138.36 17.69 4.29
0.2 58.61 91.54* 17.80 1.94
0.3 21.62 63.96* 10.26 1.00
0.4 10.51 41.74* 4.78 0.77
0.5 1.92 19.03* 2.41 0.56
* ECN scenarios marked with an asterisk are not realistic, as routers are not recommended to mark packets when packet drop/mark rates are 20% or higher.
* 标有星号的ECN方案不现实，因为当数据包丢弃/标记率为20%或更高时，不建议路由器标记数据包。
Table 8: Send Rate vs. Packet Drop Rate II: 14B TFRC Segments (5.6 Kbps Maximum TFRC Data Sending Rate)
表8：发送速率与丢包速率II:14B TFRC段（最大TFRC数据发送速率为5.6 Kbps）
Table 8 shows the results of simulations where each TFRC-SP flow has a maximum data sending rate of 5.6 Kbps, with 14-byte data packets and a 32-byte packet header for DCCP and IP. Each TCP flow has a receive window of 100 packets and a data packet size of 1460 bytes, with a 40-byte packet header for TCP and IP. The TCP flow uses SACK TCP with Limited Transmit, but without timestamps or ECN. Each flow has a round-trip time of 240 ms in the absence of queueing delay.
表8显示了模拟结果，其中每个TFRC-SP流的最大数据发送速率为5.6 Kbps，DCCP和IP的数据包为14字节，数据包头为32字节。每个TCP流的接收窗口为100个数据包，数据包大小为1460字节，TCP和IP的数据包头为40字节。TCP流使用SACK TCP进行有限的传输，但没有时间戳或ECN。在没有排队延迟的情况下，每个流的往返时间为240毫秒。
The TFRC sending rate in Table 8 is the sending rate for the 14-byte data packet with the 32-byte packet header. Thus, only 30% of the TFRC sending rate is for data, and with a packet drop rate of p, only a fraction 1-p of that data makes it to the receiver. Thus, the TFRC data receive rate can be considerably less than the TFRC sending rate in the table. Because TCP uses large packets, 97% of the TCP sending rate is for data, and the same fraction 1-p of that data makes it to the receiver.
表8中的TFRC发送速率是具有32字节数据包头的14字节数据包的发送速率。因此，只有30%的TFRC发送速率用于数据，并且在丢包率为p的情况下，只有该数据的一小部分1-p发送到接收器。因此，TFRC数据接收速率可以大大小于表中的TFRC发送速率。因为TCP使用大数据包，所以TCP发送速率的97%用于数据，而数据中的1-p部分同样用于发送到接收器。
Table 8 shows that for the 5.6 Kbps data stream with TFRC, Standard TFRC (Stnd TFRC) gives a very poor sending rate in bps, relative to the sending rate for the large-packet TCP connection. In contrast, the sending rate for the TFRC-SP flow is relatively close to the desired goal of fairness in bps with TCP.
表8显示，对于具有TFRC的5.6 Kbps数据流，标准TFRC（Stnd TFRC）的发送速率（以bps为单位）相对于大数据包TCP连接的发送速率非常低。相比之下，TFRC-SP流的发送速率相对接近使用TCP的bps中所需的公平性目标。
Table 8 shows that with TFRC-SP, the 5.6 Kbps data stream doesn't reduce its sending rate until packet drop rates are greater than 20%, as desired. With packet drop rates of 30-40%, the sending rate for the TFRC-SP flow is somewhat less than that of the average large-packet TCP flow, while for packet drop rates of 50% the sending rate for the TFRC-SP flow is somewhat greater than that of the average large- packet TCP flow.
表8显示，使用TFRC-SP，5.6 Kbps数据流在分组丢弃率达到所需的20%之前不会降低其发送速率。在丢包率为30-40%的情况下，TFRC-SP流的发送率略低于平均大数据包TCP流的发送率，而在丢包率为50%的情况下，TFRC-SP流的发送率略高于平均大数据包TCP流的发送率。
< - - - - - - Send Rates (Kbps) - - - - - >
Packet TCP ECN TCP TFRC-SP Stnd TFRC
DropRate (1460B seg) (1460B seg) (200B seg) (200B seg)
-------- ----------- ----------- ---------- ----------
0.001 1908.98 1869.24 183.45 178.35
0.005 854.69 835.10 185.06 138.06
0.01 564.10 531.10 185.33 92.43
0.02 365.38 369.10 185.57 62.18
0.04 220.80 257.81 185.14 45.43
0.05 208.97 219.41 180.08 39.44
0.1 141.67 143.88 127.33 21.96
0.2 62.66 91.87* 54.66 9.40
0.3 16.63 65.52* 24.50 4.73
0.4 6.62 42.00* 13.47 3.35
0.5 1.01 21.34* 10.51 2.92
< - - - - - - Send Rates (Kbps) - - - - - >
Packet TCP ECN TCP TFRC-SP Stnd TFRC
DropRate (1460B seg) (1460B seg) (200B seg) (200B seg)
-------- ----------- ----------- ---------- ----------
0.001 1908.98 1869.24 183.45 178.35
0.005 854.69 835.10 185.06 138.06
0.01 564.10 531.10 185.33 92.43
0.02 365.38 369.10 185.57 62.18
0.04 220.80 257.81 185.14 45.43
0.05 208.97 219.41 180.08 39.44
0.1 141.67 143.88 127.33 21.96
0.2 62.66 91.87* 54.66 9.40
0.3 16.63 65.52* 24.50 4.73
0.4 6.62 42.00* 13.47 3.35
0.5 1.01 21.34* 10.51 2.92
* ECN scenarios marked with an asterisk are not realistic, as routers are not recommended to mark packets when packet drop/mark rates are 20% or higher.
* 标有星号的ECN方案不现实，因为当数据包丢弃/标记率为20%或更高时，不建议路由器标记数据包。
Table 9: Sending Rate vs. Packet Drop Rate III: 200B TFRC Segments (160 Kbps Maximum TFRC Data Sending Rate)
表9：发送速率与丢包速率III:200B TFRC段（160 Kbps最大TFRC数据发送速率）
Table 9 shows results with configured packet drop rates when the TFRC flow uses 200-byte data packets, with a maximum data sending rate of 160 Kbps. As in Table 8, the performance of Standard TFRC is quite poor, while the performance of TFRC-SP is essentially as desired for packet drop rates up to 30%. Again as expected, with packet drop rates of 40-50% the TFRC-SP sending rate is somewhat higher than desired.
表9显示了TFRC流使用200字节数据包时配置的数据包丢弃率的结果，最大数据发送速率为160 Kbps。如表8所示，标准TFRC的性能相当差，而TFRC-SP的性能基本上与丢包率高达30%的情况相同。同样如预期的那样，在数据包丢弃率为40-50%的情况下，TFRC-SP发送速率略高于预期。
For these simulations, the sending rate of a TCP connection using timestamps is similar to the sending rate shown for a standard TCP connection without timestamps.
对于这些模拟，使用时间戳的TCP连接的发送速率与没有时间戳的标准TCP连接的发送速率相似。
In this section we explore simulations where the router is configured to drop or mark each *byte* at a specified rate. When a byte is chosen to be dropped (or marked), the entire packet containing that byte is dropped (or marked).
在本节中，我们将探讨路由器配置为以指定速率删除或标记每个*字节*的模拟。当选择删除（或标记）一个字节时，包含该字节的整个数据包将被删除（或标记）。
< - - - - - Send Rates (Kbps) - - - - - >
Byte TCP TFRC-SP Stnd TFRC
DropRate SegSize TCP ECN TCP (14B seg) (14B seg)
-------- ------- -------- -------- --------- ---------
0.00001 1460 423.02 431.26 17.69 17.69
0.0001 1460 117.41 114.34 17.69 17.69
0.001 128 10.78 11.50 17.69 8.37
0.005 14 1.75 2.89 18.39 1.91
0.010 1460 0.31 0.26 7.07 0.84
0.020 1460 0.29 0.26 1.61 0.43
0.040 1460 0.12 0.26* 0.17 0.12
0.050 1460 0.15 0.26* 0.08 0.06
< - - - - - Send Rates (Kbps) - - - - - >
Byte TCP TFRC-SP Stnd TFRC
DropRate SegSize TCP ECN TCP (14B seg) (14B seg)
-------- ------- -------- -------- --------- ---------
0.00001 1460 423.02 431.26 17.69 17.69
0.0001 1460 117.41 114.34 17.69 17.69
0.001 128 10.78 11.50 17.69 8.37
0.005 14 1.75 2.89 18.39 1.91
0.010 1460 0.31 0.26 7.07 0.84
0.020 1460 0.29 0.26 1.61 0.43
0.040 1460 0.12 0.26* 0.17 0.12
0.050 1460 0.15 0.26* 0.08 0.06
* ECN scenarios marked with an asterisk are not realistic, as routers are not recommended to mark packets when packet drop/mark rates are 20% or higher.
* 标有星号的ECN方案不现实，因为当数据包丢弃/标记率为20%或更高时，不建议路由器标记数据包。
TFRC's maximum data sending rate is 5.6 Kbps.
TFRC的最大数据发送速率为5.6 Kbps。
Table 10: Sending Rate vs. Byte Drop Rate
表10：发送速率与字节丢弃速率
Table 10 shows the TCP and TFRC send rates for various byte drop rates. For each byte drop rate, Table 10 shows the TCP sending rate, with and without ECN, for the TCP segment size that gives the highest TCP sending rate. Simulations were run with TCP segments of 14, 128, 256, 512, and 1460 bytes. Thus, for a byte drop rate of 0.00001, the table shows the TCP sending rate with 1460-byte data segments, but with a byte drop rate of 0.001, the table shows the TCP sending rate with 128-byte data segments. For each byte drop rate, Table 10 also shows the TFRC-SP and Standard TFRC sending rates. With configured byte drop rates, TFRC-SP gives an unfair advantage to the TFRC-SP flow, while Standard TFRC gives essentially the desired performance.
表10显示了各种字节丢失率的TCP和TFRC发送率。对于每个字节丢弃率，表10显示了TCP发送率，包括和不包括ECN，以及给出最高TCP发送率的TCP段大小。模拟使用14、128、256、512和1460字节的TCP段运行。因此，对于0.00001的字节删除率，该表显示了1460字节数据段的TCP发送率，但对于0.001的字节删除率，该表显示了128字节数据段的TCP发送率。对于每个字节丢弃率，表10还显示了TFRC-SP和标准TFRC发送率。通过配置字节丢弃率，TFRC-SP为TFRC-SP流提供了不公平的优势，而标准TFRC基本上提供了所需的性能。
TCP Pkt TFRC Pkt
Byte DropRate DropRate TCP/TFRC
DropRate (1460B seg) (14B seg) Pkt Drop Ratio
-------- ----------- --------- --------------
0.00001 0.015 0.0006 26.59
0.0001 0.13 0.0056 24.94
0.001 0.77 0.054 14.26
0.005 0.99 0.24 4.08
0.01 1.00 0.43 2.32
0.05 1.00 0.94 1.05
TCP Pkt TFRC Pkt
Byte DropRate DropRate TCP/TFRC
DropRate (1460B seg) (14B seg) Pkt Drop Ratio
-------- ----------- --------- --------------
0.00001 0.015 0.0006 26.59
0.0001 0.13 0.0056 24.94
0.001 0.77 0.054 14.26
0.005 0.99 0.24 4.08
0.01 1.00 0.43 2.32
0.05 1.00 0.94 1.05
Table 11: Packet Drop Rate Ratio vs. Byte Drop Rate
表11：数据包丢弃率与字节丢弃率
Table 11 converts the byte drop rate p to packet drop rates for the TCP and TFRC packets, where the packet drop rate for an N-byte packet is 1-(1-p)^N. Thus, a byte drop rate of 0.001, with each byte being dropped with probability 0.001, converts to a packet drop rate of 0.77, or 77%, for the 1500-byte TCP packets, and a packet drop rate of 0.054, or 5.4%, for the 56-byte TFRC packets.
表11将字节丢弃率p转换为TCP和TFRC数据包的数据包丢弃率，其中N字节数据包的数据包丢弃率为1-（1-p）^N。因此，如果字节丢弃率为0.001，每个字节丢弃的概率为0.001，则1500字节TCP数据包的数据包丢弃率为0.77，或77%，数据包丢弃率为0.054，对于56字节的TFRC数据包，为5.4%。
The right column of Table 11 shows the ratio between the TCP packet drop rate and the TFRC packet drop rate. For low byte drop rates, this ratio is close to 26.8, the ratio between the TCP and TFRC packet sizes. For high byte drop rates, where even most small TFRC packets are likely to be dropped, this drop ratio approaches 1. As Table 10 shows, with byte drop rates, the Standard TFRC sending rate is close to optimal, competing fairly with a TCP connection using the optimal packet size within the allowed range. In contrast, the TFRC-SP connection gets more than its share of the bandwidth, though it does reduce its sending rate for a byte drop rate of 0.01 or more (corresponding to a TFRC-SP *packet* drop rate of 0.43.
表11的右栏显示了TCP数据包丢弃率和TFRC数据包丢弃率之间的比率。对于低字节丢弃率，该比率接近26.8，即TCP和TFRC数据包大小之间的比率。对于高字节丢弃率，即使是最小的TFRC数据包也可能被丢弃，该丢弃率接近1。如表10所示，对于字节丢弃率，标准TFRC发送率接近最优，在允许范围内使用最佳数据包大小与TCP连接公平竞争。相比之下，TFRC-SP连接获得的带宽超过了它所占的带宽份额，尽管它确实降低了其发送速率（字节丢弃率为0.01或更高）（对应于TFRC-SP*数据包*丢弃率为0.43）。
Table 10 essentially shows three separate regions. In the low-congestion region, with byte drop rates less than 0.0001, the TFRC-SP connection is sending at its maximum sending rate. In this region the optimal TCP connection is the one with 1460-byte segments, and the TCP sending rate goes as 1/sqrt(p), for packet drop rate p. This low-congestion region holds for packet drop rates up to 10-15%.
表10基本上显示了三个独立的区域。在低拥塞区域，当字节丢失率小于0.0001时，TFRC-SP连接以其最大发送速率发送。在此区域中，最佳TCP连接是具有1460字节段的连接，对于丢包率p，TCP发送速率为1/sqrt（p）。此低拥塞区域可容纳高达10-15%的丢包率。
In the middle region of Table 10, with byte drop rates from 0.0001 to 0.005, the optimal TCP segment size is a function of the byte drop rate. In particular, the optimal TCP segment size seems to be the one that keeps the packet drop rate at most 15%, keeping the TCP connection in the regime controlled by a 1/sqrt(p) sending rate, for packet drop rate p. For a TCP packet size of S bytes (including headers), and a *byte* drop rate of B, the packet drop rate is roughly B*S. For a given byte drop rate in this regime, if the optimal TCP performance occurs with a packet size chosen to give a
在表10的中间区域中，字节丢弃率从0.0001到0.005，最优TCP段大小是字节丢弃率的函数。特别是，对于丢包率p，最佳TCP段大小似乎是将丢包率保持在15%以下，将TCP连接保持在由1/sqrt（p）发送率控制的状态。对于大小为S字节（包括标头）的TCP数据包，以及*字节*丢弃率为B的情况下，数据包丢弃率大致为B*S。对于这种情况下的给定字节丢弃率，如果选择数据包大小以提供
packet drop rate of at most 15%, keeping the TCP connection out of the regime of exponential backoffs of the retransmit timer, then this requires B*S = 0.15, or S = 0.15/B.
丢包率不超过15%，使TCP连接不受重传计时器指数退避的影响，则需要B*S=0.15或S=0.15/B。
In the high-congestion regime of Table 10, with high congestion and with byte drop rates of 0.01 and higher, the TCP performance is dominated by the exponential backoff of the retransmit timer regardless of the segment size. Even a 40-byte packet with a zero-byte data segment would have a packet drop rate of at least 33%. In this regime, the optimal TCP *sending* rate comes with a large, 1460-byte data segment, but the TCP sending rate is low with any segment size, considerably less than one packet per round-trip time.
在表10的高拥塞状态下，在高拥塞和字节丢失率为0.01或更高的情况下，TCP性能主要取决于重传计时器的指数退避，而与段大小无关。即使是带有零字节数据段的40字节数据包，其丢包率也至少为33%。在这种情况下，最佳TCP*发送*速率带有一个大的1460字节的数据段，但无论数据段大小如何，TCP发送速率都很低，大大低于每往返时间一个数据包。
We note that in this regime, while a larger packet gives a higher TCP *sending* rate, a smaller packet gives a better *goodput* rate.
我们注意到，在这种情况下，虽然较大的数据包提供较高的TCP*发送*速率，但较小的数据包提供更好的*goodput*速率。
In general, Tables 8 and 9 show good performance for TFRC-SP in environments with stable packet drop rates, where the decision to drop a packet is independent of the packet size. However, in some environments the packet size might affect the likelihood that a packet is dropped. For example, with heavy congestion and a Drop Tail queue with a fixed number of bytes rather than a fixed number of packet-sized buffers, small packets might be more likely than large packets to find room at the end of an almost-full queue. As a further complication, in a scenario with Active Queue Management, the AQM mechanism could either be in packet mode, dropping each packet with equal probability, or in byte mode, dropping each byte with equal probability. Sections B.3 and B.4 show simulations with packets dropped at Drop-Tail or AQM queues, rather that from a probabilistic process.
通常，表8和表9显示了TFRC-SP在具有稳定丢包率的环境中的良好性能，其中丢包的决定与数据包大小无关。然而，在某些环境中，数据包大小可能会影响数据包被丢弃的可能性。例如，在严重拥塞和具有固定字节数（而不是固定数量的数据包大小的缓冲区）的丢弃尾队列中，小包可能比大包更有可能在几乎满的队列末尾找到空间。更复杂的是，在具有主动队列管理的场景中，AQM机制可以处于分组模式，以相同的概率丢弃每个分组，或者处于字节模式，以相同的概率丢弃每个字节。第B.3和B.4节显示了在丢弃尾队列或AQM队列中丢弃的数据包的模拟，而不是从概率过程中丢弃的数据包。
One of the problems with comparing the throughput of two flows using different packet sizes is that the packet size itself can influence the packet drop rate [V00, WBL04].
比较使用不同数据包大小的两个流的吞吐量的问题之一是数据包大小本身会影响数据包丢弃率[V00，WBL04]。
The default TFRC was designed for rough fairness with TCP, for TFRC and TCP flows with the same packet size and experiencing the same packet drop rate. When the issue of fairness between flows with different packets sizes is addressed, it matters whether the packet drop rates experienced by the flows is related to the packet size. That is, are small packets just as likely to be dropped as large TCP packets, or are the smaller packets less likely to be dropped [WBL04]? And what is the relationship between the packet-dropping behavior of the path, and the loss event measurements of TFRC?
默认TFRC设计用于TCP的粗略公平性，用于具有相同数据包大小且经历相同数据包丢弃率的TFRC和TCP流。当处理具有不同分组大小的流之间的公平性问题时，流所经历的分组丢弃率是否与分组大小相关很重要。也就是说，小数据包是否与大TCP数据包一样可能被丢弃，或者较小的数据包是否不太可能被丢弃[WBL04]？路径的丢包行为与TFRC的丢失事件度量之间的关系是什么？
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.04 316.18 0.05 183.05
25 0.07 227.47 0.07 181.23
50 0.08 181.10 0.08 178.32
100 0.14 85.97 0.12 151.42
200 0.17 61.20 0.14 73.88
400 0.20 27.79 0.18 36.81
800 0.29 3.50 0.27 16.33
1600 0.37 0.63 0.33 6.29
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.04 316.18 0.05 183.05
25 0.07 227.47 0.07 181.23
50 0.08 181.10 0.08 178.32
100 0.14 85.97 0.12 151.42
200 0.17 61.20 0.14 73.88
400 0.20 27.79 0.18 36.81
800 0.29 3.50 0.27 16.33
1600 0.37 0.63 0.33 6.29
Table 12: Drop and Send Rates for Drop-Tail Queues in Packets
表12：数据包中丢弃尾部队列的丢弃和发送速率
Table 12 shows the results of the second half of 100-second simulations, with five TCP connections and five TFRC-SP connections competing with web traffic in a topology with a 3 Mbps shared link. The TFRC-SP application generates 200-byte data packets every 10 ms, for a maximum data rate of 160 Kbps. The five long-lived TCP connections use a data packet size of 1460 bytes, and the web traffic uses a data packet size of 512 bytes. The five TCP connections have round-trip times from 40 to 240 ms, and the five TFRC connections have the same set of round-trip times. The SACK TCP connections in these simulations use the default parameters in the NS simulator, with Limited Transmit, and a minimum RTO of 200 ms. Adding timestamps to the TCP connection didn't change the results appreciably. The simulations include reverse-path traffic, to add some small control packets to the forward path, and some queueing delay to the reverse path. The number of web sessions is varied to create different levels of congestion. The Drop-Tail queue is in units of packets, which each packet arriving to the queue requires a single buffer, regardless of the packet size.
表12显示了100秒模拟的后半部分的结果，其中五个TCP连接和五个TFRC-SP连接在一个具有3 Mbps共享链路的拓扑中与web流量竞争。TFRC-SP应用程序每10毫秒生成200字节的数据包，最大数据速率为160 Kbps。五个长寿命TCP连接使用1460字节的数据包大小，web流量使用512字节的数据包大小。五个TCP连接的往返时间为40到240毫秒，五个TFRC连接的往返时间相同。这些模拟中的SACK TCP连接使用NS模拟器中的默认参数，传输有限，最小RTO为200毫秒。向TCP连接添加时间戳不会明显改变结果。模拟包括反向路径流量，向正向路径添加一些小的控制数据包，以及向反向路径添加一些排队延迟。web会话的数量会有所不同，从而造成不同程度的拥塞。掉尾队列以数据包为单位，到达队列的每个数据包都需要一个缓冲区，而与数据包大小无关。
Table 12 shows the average TCP and TFRC sending rates, each averaged over the five flows. As expected, the TFRC-SP flows see similar packet drop rates as the TCP flows, though the TFRC-SP flows receives higher throughput than the TCP flows with packet drop rates of 25% or higher.
表12显示了TCP和TFRC的平均发送速率，每种速率在五个流上的平均值。正如所料，TFRC-SP流的丢包率与TCP流相似，尽管TFRC-SP流的吞吐量高于丢包率为25%或更高的TCP流。
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.061 239.81 0.004 185.19
25 0.089 189.02 0.006 184.95
50 0.141 99.46 0.013 185.07
100 0.196 16.42 0.022 183.77
200 0.256 4.46 0.032 181.98
400 0.291 4.61 0.051 151.88
800 0.487 1.01 0.078 113.10
1600 0.648 0.67 0.121 65.17
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.061 239.81 0.004 185.19
25 0.089 189.02 0.006 184.95
50 0.141 99.46 0.013 185.07
100 0.196 16.42 0.022 183.77
200 0.256 4.46 0.032 181.98
400 0.291 4.61 0.051 151.88
800 0.487 1.01 0.078 113.10
1600 0.648 0.67 0.121 65.17
Table 13: Drop and Send Rates for Drop-Tail Queues in Bytes I: 1460B TCP Segments
表13：丢弃尾队列的丢弃和发送速率（字节I:1460B TCP段）
However, the fairness results can change significantly if the Drop-Tail queue at the congested output link is in units of bytes rather than packets. For a queue in packets, the queue has a fixed number of buffers, and each buffer can hold exactly one packet, regardless of its size in bytes. For a queue in bytes, the queue has a fixed number of *bytes*, and an almost-full queue might have room for a small packet but not for a large one. Thus, for a simulation with a Drop-Tail queue in bytes, large packets are more likely to be dropped than are small ones. The NS simulator doesn't yet have a more realistic intermediate model, where the queue has a fixed number of buffers, each buffer has a fixed number of bytes, and each packet would require one or more free buffers. In this model, a small packet would use one buffer, while a larger packet would require several buffers.
然而，如果拥塞输出链路上的丢弃尾队列以字节为单位而不是以数据包为单位，则公平性结果可能会发生显著变化。对于以数据包为单位的队列，队列具有固定数量的缓冲区，每个缓冲区可以仅容纳一个数据包，而不管其大小（以字节为单位）。对于以字节为单位的队列，队列具有固定数量的*字节*，几乎满的队列可能有空间容纳一个小数据包，但不能容纳一个大数据包。因此，对于以字节为单位的丢弃尾队列的模拟，大数据包比小数据包更有可能被丢弃。NS模拟器还没有一个更现实的中间模型，队列有固定数量的缓冲区，每个缓冲区有固定数量的字节，每个数据包需要一个或多个空闲缓冲区。在这个模型中，一个小数据包将使用一个缓冲区，而一个大数据包将需要几个缓冲区。
The scenarios in Table 13 are identical to those in Table 12, except that the Drop-Tail queue is in units of bytes instead of packets. Thus, five TCP connections and five TFRC-SP connections compete with web traffic in a topology with a 3 Mbps shared link, with each TFRC-SP application generating 200-byte data packets every 10 ms, for a maximum data rate of 160 Kbps. The number of web sessions is varied to create different levels of congestion. However, instead of Drop-Tail queues able to accommodate at most a hundred packets, the routers' Drop-Tail queues are each able to accommodate at most 50,000 bytes (computed in NS as a hundred packets times the mean packet size of 500 bytes).
表13中的场景与表12中的场景相同，不同之处在于丢弃尾队列以字节为单位，而不是以数据包为单位。因此，五个TCP连接和五个TFRC-SP连接在具有3 Mbps共享链路的拓扑中与web流量竞争，每个TFRC-SP应用程序每10 ms生成200字节的数据包，最大数据速率为160 Kbps。web会话的数量会有所不同，从而造成不同程度的拥塞。然而，与最多可容纳100个数据包的掉尾队列不同，路由器的掉尾队列每个最多可容纳50000字节（以NS为单位计算为100个数据包乘以500字节的平均数据包大小）。
As Table 13 shows, with a Drop-Tail queue in bytes, the TFRC-SP flow sees a much smaller packet drop rate than the TCP flow, and as a consequence receives a much larger sending rate. For the simulations in Table 13, the TFRC-SP flows use 200-byte data segments, while the
如表13所示，对于以字节为单位的丢弃尾队列，TFRC-SP流看到的数据包丢弃率比TCP流小得多，因此接收到的发送率要大得多。对于表13中的模拟，TFRC-SP流使用200字节的数据段，而
long-lived TCP flows use 1460-byte data segments. For example, when the five TCP flows and five TFRC-SP flows share the link with 800 web sessions, the five TCP flows see an average drop rate of 49% in the second half of the simulation, while the five TFRC-SP flows receive an average drop rate of 8%, and as a consequence receive more than 100 times the throughput of the TCP flows. This raises serious questions about making the assumption that flows with small packets see the same packet drop rate as flows with larger packets. Further work will have to include an investigation into the range of realistic Internet scenarios, in terms of whether large packets are considerably more likely to be dropped than are small ones.
长寿命TCP流使用1460字节的数据段。例如，当五个TCP流和五个TFRC-SP流与800个web会话共享链路时，五个TCP流在模拟的后半部分中的平均丢弃率为49%，而五个TFRC-SP流的平均丢弃率为8%，因此，它们的吞吐量是TCP流的100倍以上。这就提出了一个严重的问题，即假设具有较小数据包的流与具有较大数据包的流具有相同的数据包丢弃率。进一步的工作将包括调查现实互联网场景的范围，即大数据包是否比小数据包更容易被丢弃。
< - - - - - Send Rates in Kbps - - - - >
Web TCP (512B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.02 335.05 0.00 185.16
25 0.02 289.94 0.00 185.36
50 0.04 139.99 0.01 184.98
100 0.06 53.50 0.01 184.66
200 0.10 16.14 0.04 167.87
400 0.16 6.36 0.07 114.85
800 0.24 0.90 0.11 67.23
1600 0.42 0.35 0.18 39.32
< - - - - - Send Rates in Kbps - - - - >
Web TCP (512B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.02 335.05 0.00 185.16
25 0.02 289.94 0.00 185.36
50 0.04 139.99 0.01 184.98
100 0.06 53.50 0.01 184.66
200 0.10 16.14 0.04 167.87
400 0.16 6.36 0.07 114.85
800 0.24 0.90 0.11 67.23
1600 0.42 0.35 0.18 39.32
Table 14: Drop and Send Rates for Drop-Tail Queues in Bytes II: 512B TCP Segments
表14：丢弃尾队列的丢弃和发送速率（字节II:512B TCP段）
Table 14 shows that, in these scenarios, the long-lived TCP flows receive a higher packet drop rate than the TFRC-SP flows, and receive considerably less throughput, even when the long-lived TCP flows use 512-byte segments.
表14显示，在这些场景中，长寿命TCP流比TFRC-SP流接收到更高的丢包率，并且接收到的吞吐量大大降低，即使长寿命TCP流使用512字节的段。
To show the potential negative effect of TFRC-SP in such an environment, we consider a simulation with N TCP flows, N TFRC-SP flows, and 10*N web sessions, for N ranging from 1 to 50, so that the demand increases from all types of traffic, with routers with Drop-Tail queues in bytes.
为了显示TFRC-SP在这样的环境中潜在的负面影响，我们考虑了N个TCP流、N TFRC-SP流和10×N Web会话的仿真，对于N从1到50，使得需求从所有类型的流量增加，具有带尾尾队列的路由器以字节为单位。
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.014 2085.36 0.001 180.29
20 0.040 788.88 0.004 183.87
30 0.074 248.80 0.006 182.94
40 0.113 163.20 0.008 185.33
50 0.127 94.70 0.011 185.14
60 0.177 53.24 0.015 185.30
70 0.174 35.31 0.016 185.07
80 0.221 19.38 0.019 183.91
90 0.188 15.63 0.019 180.42
100 0.265 7.08 0.023 176.71
200 0.324 0.38 0.042 139.48
300 0.397 0.32 0.076 93.53
400 0.529 0.40 0.100 70.40
500 0.610 0.37 0.121 57.59
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.014 2085.36 0.001 180.29
20 0.040 788.88 0.004 183.87
30 0.074 248.80 0.006 182.94
40 0.113 163.20 0.008 185.33
50 0.127 94.70 0.011 185.14
60 0.177 53.24 0.015 185.30
70 0.174 35.31 0.016 185.07
80 0.221 19.38 0.019 183.91
90 0.188 15.63 0.019 180.42
100 0.265 7.08 0.023 176.71
200 0.324 0.38 0.042 139.48
300 0.397 0.32 0.076 93.53
400 0.529 0.40 0.100 70.40
500 0.610 0.37 0.121 57.59
Table 15: Drop and Send Rates for Drop-Tail Queues in Bytes III: TFRC-SP, 1460B TCP Segments
表15：丢弃尾队列的丢弃和发送速率（字节III）：TFRC-SP，1460B TCP段
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.016 1926.00 0.002 178.47
20 0.030 805.20 0.003 178.23
30 0.062 346.24 0.005 161.19
40 0.093 219.18 0.007 136.28
50 0.110 132.77 0.010 83.02
60 0.170 88.88 0.014 69.75
70 0.149 70.73 0.015 55.59
80 0.213 43.17 0.020 42.82
90 0.188 36.19 0.017 43.61
100 0.233 24.77 0.026 35.17
200 0.311 5.46 0.034 24.85
300 0.367 3.74 0.049 20.19
400 0.421 2.59 0.055 17.71
500 0.459 1.10 0.069 15.95
Table 16: Drop and Send Rates for Drop-Tail Queues in Bytes IV:
Standard TFRC, 1460B TCP Segments
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.016 1926.00 0.002 178.47
20 0.030 805.20 0.003 178.23
30 0.062 346.24 0.005 161.19
40 0.093 219.18 0.007 136.28
50 0.110 132.77 0.010 83.02
60 0.170 88.88 0.014 69.75
70 0.149 70.73 0.015 55.59
80 0.213 43.17 0.020 42.82
90 0.188 36.19 0.017 43.61
100 0.233 24.77 0.026 35.17
200 0.311 5.46 0.034 24.85
300 0.367 3.74 0.049 20.19
400 0.421 2.59 0.055 17.71
500 0.459 1.10 0.069 15.95
Table 16: Drop and Send Rates for Drop-Tail Queues in Bytes IV:
Standard TFRC, 1460B TCP Segments
Table 15 shows simulations using TFRC-SP, while Table 16 shows simulations using TFRC instead of TFRC-SP. This is the only difference between the simulations in the two tables. Note that when TFRC-SP is used, the TCP flows and web traffic are essentially
表15显示了使用TFRC-SP的模拟，而表16显示了使用TFRC而不是TFRC-SP的模拟。这是两个表中模拟的唯一区别。请注意，当使用TFRC-SP时，TCP流和web流量基本上是相同的
starved, while the TFRC-SP flows each continue to send 57 Kbps. In contrast, when standard TFRC is used instead of TFRC-SP for the flows sending 200-byte segments, the TCP flows are not starved (although they still don't receive their "share" of the link bandwidth when their packet drop rates are 30% or higher). These two sets of simulations illustrate the dangers of a widespread deployment of TFRC-SP in an environment where small packets are less likely to be dropped than large ones.
饥饿，而TFRC-SP流继续发送57 Kbps。相反，当发送200字节段的流使用标准TFRC而不是TFRC-SP时，TCP流不会被饿死（尽管当它们的丢包率为30%或更高时，它们仍然不会收到链路带宽的“共享”）。这两组模拟说明了在小数据包比大数据包更不可能被丢弃的环境中广泛部署TFRC-SP的危险。
As expected, the packet-dropping behavior also can be varied by varying the Active Queue Management (AQM) mechanism in the router. When the routers use RED (Random Early Detection), there are several parameters than can affect the packet-dropping or marking behavior as a function of the packet size.
正如预期的那样，分组丢弃行为也可以通过改变路由器中的主动队列管理（AQM）机制来改变。当路由器使用RED（随机早期检测）时，有几个参数可以影响作为数据包大小函数的数据包丢弃或标记行为。
First, as with Drop-Tail, the RED queue can be in units of either packets or bytes. This can affect the packet-dropping behavior when RED is unable to control the average queue size, and the queue overflows.
首先，与Drop-Tail一样，红色队列可以以数据包或字节为单位。当RED无法控制平均队列大小且队列溢出时，这会影响数据包丢弃行为。
Second, and orthogonally, RED can be configured to be either in packet mode or in byte mode. In packet mode, each *packet* has the same probability of being dropped by RED, while in byte mode, each *byte* has the same probability of being dropped. In packet mode, large-packet and small-packet flows receive roughly the same packet drop rate, while in byte mode, large-packet and small-packet flows with the same throughput in bps receive roughly the same *number* of packet drops. [EA03] assessed the impact of byte vs. packet modes on RED performance.
第二，正交地，红色可以被配置为分组模式或字节模式。在数据包模式下，每个*数据包*被红色丢弃的概率相同，而在字节模式下，每个*字节*被丢弃的概率相同。在分组模式下，大分组和小分组流接收的分组丢弃率大致相同，而在字节模式下，在bps中具有相同吞吐量的大分组和小分组流接收的分组丢弃率大致相同。[EA03]评估了字节与数据包模式对RED性能的影响。
The simulations reported below show that for RED in packet mode, the packet drop rates for the TFRC-SP flows are similar to those for the TCP flows, with a resulting acceptable throughput for the TFRC-SP flows. This is true with the queue in packets or in bytes, and with or without Adaptive RED (discussed below). As we show below, this fairness between TCP and TFRC-SP flows does not hold for RED in byte mode.
下面报告的模拟表明，对于分组模式下的RED，TFRC-SP流的分组丢弃率与TCP流的分组丢弃率相似，因此TFRC-SP流的吞吐量可以接受。对于以数据包或字节为单位的队列，以及具有或不具有自适应RED（下文讨论）的情况，都是如此。如下所示，TCP和TFRC-SP流之间的这种公平性在字节模式下不适用于RED。
The third RED parameter that affects the packet-dropping or marking behavior as a function of packet size is whether the RED mechanism is using Standard RED or Adaptive RED; Adaptive RED tries to maintain the same average queue size, regardless of the packet drop rate. The use of Adaptive RED allows the RED mechanism to function more effectively in the presence of high packet drop rates (e.g., greater than 10%). Without Adaptive RED, there is a fixed dropping threshold, and all arriving packets are dropped when the dropping or
作为包大小的函数影响包丢弃或标记行为的第三个RED参数是RED机制是使用标准RED还是自适应RED；自适应RED尝试保持相同的平均队列大小，而不考虑丢包率。自适应RED的使用允许RED机制在存在高分组丢弃率（例如，大于10%）的情况下更有效地工作。如果没有自适应RED，则存在固定的丢弃阈值，并且在丢弃或删除数据包时丢弃所有到达的数据包
marking rate exceeds this threshold. In contrast, with Adaptive RED, the dropping function is adapted to accommodate high-drop-rate regimes. One consequence is that when byte mode is used with Adaptive RED, the byte mode extends even to high-drop-rate regimes. When byte mode is used with standard RED, however, the byte mode is no longer in use when the drop rate exceeds the fixed dropping threshold (set by default to 10% in the NS simulator).
评分率超过此阈值。相比之下，使用自适应RED时，下降功能适用于高下降率区域。一个结果是，当字节模式与自适应RED一起使用时，字节模式甚至扩展到高丢弃率区域。但是，当字节模式与标准红色一起使用时，当丢弃率超过固定丢弃阈值（在NS模拟器中默认设置为10%）时，字节模式不再使用。
In the simulations in this section, we explore the TFRC-SP behavior over some of this range of scenarios. In these simulations, as in Section B.3 above, the application for the TFRC-SP flow uses 200-byte data packets, generating 100 packets per second.
在本节的模拟中，我们将探讨TFRC-SP在这一系列场景中的行为。在这些模拟中，如上文第B.3节所述，TFRC-SP流的应用程序使用200字节的数据包，每秒生成100个数据包。
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.05 305.76 0.04 182.82
25 0.06 224.16 0.06 175.91
50 0.09 159.12 0.08 152.51
100 0.13 90.77 0.11 106.13
200 0.14 48.53 0.14 70.25
400 0.20 22.08 0.19 41.50
800 0.27 3.55 0.25 17.50
1600 0.42 1.87 0.34 8.81
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.05 305.76 0.04 182.82
25 0.06 224.16 0.06 175.91
50 0.09 159.12 0.08 152.51
100 0.13 90.77 0.11 106.13
200 0.14 48.53 0.14 70.25
400 0.20 22.08 0.19 41.50
800 0.27 3.55 0.25 17.50
1600 0.42 1.87 0.34 8.81
Table 17: Drop and Send Rates for RED Queues in Packet Mode
表17：分组模式下红色队列的丢弃和发送速率
For the simulations in Table 17, with a congested router with a RED queue in packet mode, the results are similar to those with a Drop-Tail queue in packets, as in Table 12 above. The TFRC-SP flow receives similar packet drop rates as the TCP flow, though it receives higher throughput in the more congested environments. The simulations are similar with a RED queue in packet mode with the queue in bytes, and with or without Adaptive RED. In these simulations, TFRC-SP gives roughly the desired performance.
对于表17中的模拟，在分组模式下具有红色队列的拥塞路由器，结果类似于分组中具有丢弃尾队列的路由器，如上面的表12所示。TFRC-SP流接收到的数据包丢弃率与TCP流相似，尽管它在更拥挤的环境中接收到更高的吞吐量。模拟类似于分组模式下的红色队列，队列以字节为单位，有无自适应红色。在这些模拟中，TFRC-SP提供了大致所需的性能。
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.06 272.16 0.02 184.37
25 0.07 175.82 0.02 184.06
50 0.10 75.65 0.04 180.56
100 0.14 38.98 0.07 151.65
200 0.19 16.66 0.11 106.80
400 0.26 4.85 0.15 69.41
800 0.35 3.12 0.20 27.07
1600 0.42 0.67 0.29 10.68
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.06 272.16 0.02 184.37
25 0.07 175.82 0.02 184.06
50 0.10 75.65 0.04 180.56
100 0.14 38.98 0.07 151.65
200 0.19 16.66 0.11 106.80
400 0.26 4.85 0.15 69.41
800 0.35 3.12 0.20 27.07
1600 0.42 0.67 0.29 10.68
Table 18: Drop and Send Rates for RED Queues in Byte Mode
表18：字节模式下红色队列的丢弃和发送速率
Table 18 shows that with a standard RED queue in byte mode instead of packet mode, there is a somewhat greater difference between the packet drop rates of the TCP and TFRC-SP flows, particularly for lower packet drop rates. For the simulation in Table 18, the packet drop rates for the TCP flows can range from 1 1/2 to four times greater than the packet drop rates for the TFRC-SP flows. However, because the TFRC-SP flow has an upper bound on the sending rate, its sending rate is not affected in the lower packet-drop-rate regimes; its sending rate is only affected in the regimes with packet drop rates of 10% or more. The sending rate for TFRC-SP in the scenarios in Table 18 with higher packet drop rates are greater than desired, e.g., for the scenarios with 400 web sessions or greater. However, the results with TFRC-SP are at least better than that of small-packet flows with no congestion control at all.
表18显示，在字节模式而非数据包模式下的标准红色队列中，TCP和TFRC-SP流的数据包丢弃率之间存在较大差异，尤其是对于较低的数据包丢弃率。对于表18中的模拟，TCP流的丢包率可以是TFRC-SP流丢包率的1 1/2到4倍。然而，由于TFRC-SP流在发送速率上有一个上限，其发送速率在较低的丢包率情况下不受影响；其发送速率仅在丢包率为10%或以上的情况下受影响。表18中具有较高丢包率的场景中TFRC-SP的发送速率大于期望值，例如，对于具有400个或更多web会话的场景。然而，TFRC-SP的结果至少比完全没有拥塞控制的小数据包流的结果要好。
< - - - - - Send Rates in Kbps - - - - >
Web TCP (512B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.01 337.86 0.01 184.06
25 0.02 258.71 0.01 184.03
50 0.02 184.71 0.01 183.99
100 0.04 63.63 0.03 184.43
200 0.08 28.95 0.06 149.80
400 0.12 17.03 0.10 88.21
800 0.24 5.94 0.15 36.80
1600 0.32 3.37 0.21 19.45
< - - - - - Send Rates in Kbps - - - - >
Web TCP (512B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.01 337.86 0.01 184.06
25 0.02 258.71 0.01 184.03
50 0.02 184.71 0.01 183.99
100 0.04 63.63 0.03 184.43
200 0.08 28.95 0.06 149.80
400 0.12 17.03 0.10 88.21
800 0.24 5.94 0.15 36.80
1600 0.32 3.37 0.21 19.45
Table 19: Drop and Send Rates for RED Queues in Byte Mode
表19：字节模式下红色队列的丢弃和发送速率
Table 19 shows that with a standard RED queue in byte mode and with long-lived TCP flows with 512-byte data segments, there is only a moderate difference between the packet drop rate for the 552-byte TCP
表19显示，对于字节模式下的标准红色队列和具有512字节数据段的长寿命TCP流，552字节TCP的丢包率之间只有中等差异
packets and the 240-byte TFRC-SP packets. However, the sending rates for TFRC-SP in the scenarios in Table 19 with higher packet drop rates are still greater than desired, even given the goal of fairness with TCP flows with 1500-byte data segments instead of 512-byte data segments.
数据包和240字节TFRC-SP数据包。然而，在表19中具有较高丢包率的场景中，TFRC-SP的发送速率仍然高于预期，即使考虑到TCP流具有1500字节数据段而不是512字节数据段的公平性目标。
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.04 318.10 0.02 185.34
25 0.08 175.34 0.03 184.38
50 0.10 81.60 0.04 181.95
100 0.12 28.51 0.05 178.79
200 0.20 3.65 0.06 173.78
400 0.27 1.44 0.08 161.41
800 0.40 0.58 0.06 159.62
1600 0.55 0.29 0.02 180.92
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.04 318.10 0.02 185.34
25 0.08 175.34 0.03 184.38
50 0.10 81.60 0.04 181.95
100 0.12 28.51 0.05 178.79
200 0.20 3.65 0.06 173.78
400 0.27 1.44 0.08 161.41
800 0.40 0.58 0.06 159.62
1600 0.55 0.29 0.02 180.92
Table 20: Drop and Send Rates with Adaptive RED Queues in Byte Mode
表20：字节模式下自适应红色队列的丢弃和发送速率
For the simulations in Table 20, the congested router uses an Adaptive RED queue in byte mode.
对于表20中的模拟，拥塞路由器在字节模式下使用自适应RED队列。
For this router, the output queue is in units of bytes rather than of packets, and each *byte* is dropped with the same probability. Also, because of the use of Adaptive RED, this byte-dropping mode extends even for the high-packet-drop-rate regime.
对于这个路由器，输出队列是以字节为单位的，而不是以数据包为单位的，并且每个*字节*都以相同的概率丢弃。此外，由于使用了自适应RED，这种字节丢弃模式甚至可以扩展到高分组丢弃率模式。
As Table 20 shows, for a scenario with Adaptive RED in byte mode, the packet drop rate for the TFRC-SP traffic is *much* lower than that for the TCP traffic, and as a consequence, the sending rate for the TFRC-SP traffic in a highly congested environment is *much* higher than that of the TCP traffic. In fact, in these scenarios the TFRC-SP congestion control mechanisms are largely ineffective for the small-packet traffic.
如表20所示，对于字节模式下具有自适应RED的场景，TFRC-SP流量的丢包率*远*低于TCP流量的丢包率，因此，高度拥挤环境下TFRC-SP流量的发送率*远*高于TCP流量的发送率。事实上，在这些场景中，TFRC-SP拥塞控制机制对于小数据包流量基本上是无效的。
The simulation with 1600 web servers is of particular concern, because the TCP packet drop rate increases, while the TFRC-SP packet drop rate decreases significantly. This is due to a detail of the Adaptive RED implementation in the NS simulator, and not about the dynamics of TFRC-SP. In particular, Adaptive RED is configured not to "adapt" to packet drop rates over 50%. When the packet drop rate is at most 50%, Adaptive RED is moderately successful in keeping the packet drop rate proportional to the packet size. TCP packets are six times larger than the TFRC-SP packets (including headers), so the TCP packets should see a packet drop rate roughly six times larger.
对1600台web服务器的模拟特别值得关注，因为TCP丢包率增加，而TFRC-SP丢包率显著降低。这是由于NS模拟器中的自适应RED实现的细节，而不是TFRC-SP的动态。特别是，自适应RED配置为不“适应”超过50%的丢包率。当分组丢弃率最多为50%时，自适应RED在保持分组丢弃率与分组大小成比例方面取得了适度的成功。TCP数据包比TFRC-SP数据包（包括报头）大六倍，因此TCP数据包的丢包率大约要大六倍。
But for packet drop rates over 50%, Adaptive RED is no longer in this regime, so it is no longer successful in keeping the drop rate for TCP packets at most six times the drop rate of the TFRC-SP packets.
但是，对于超过50%的数据包丢弃率，自适应RED不再在此机制中，因此它不再成功地将TCP数据包的丢弃率保持在TFRC-SP数据包丢弃率的六倍以下。
We note that the unfairness in these simulations, in favor of TFRC-SP, is even more severe than the unfairness shown in Table 13 for a Drop-Tail queue in bytes. At the same time, it is not known if there is any deployment in the Internet of any routers with Adaptive RED in byte mode, or of any AQM mechanisms with similar behavior; we don't know the extent of the deployment of standard RED, or of any of the proposed AQM mechanisms.
我们注意到，在这些模拟中，有利于TFRC-SP的不公平性甚至比表13所示的以字节为单位的掉尾队列的不公平性更严重。同时，不知道是否在互联网上部署了任何字节模式下具有自适应RED的路由器，或任何具有类似行为的AQM机制；我们不知道标准RED的部署程度，也不知道任何提议的AQM机制。
< - - - - - Send Rates in Kbps - - - - >
Web TCP (512B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.01 306.56 0.01 185.11
25 0.02 261.41 0.01 184.41
50 0.02 185.07 0.01 184.54
100 0.04 59.25 0.03 181.58
200 0.08 16.32 0.06 150.87
400 0.12 11.53 0.10 98.10
800 0.25 5.85 0.15 46.59
1600 0.32 1.43 0.22 19.40
< - - - - - Send Rates in Kbps - - - - >
Web TCP (512B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.01 306.56 0.01 185.11
25 0.02 261.41 0.01 184.41
50 0.02 185.07 0.01 184.54
100 0.04 59.25 0.03 181.58
200 0.08 16.32 0.06 150.87
400 0.12 11.53 0.10 98.10
800 0.25 5.85 0.15 46.59
1600 0.32 1.43 0.22 19.40
Table 21: Drop and Send Rates for Adaptive RED Queues in Byte Mode
表21：字节模式下自适应红色队列的丢弃和发送速率
Table 21 shows that when TFRC-SP with 240-byte packets competes with TCP with 552-byte packets in a scenario with Adaptive RED in byte mode, the TFRC-SP flows still receive more bandwidth than the TCP flows, but the level of unfairness is less severe, and the packet drop rates of the TCP flows are at most twice that of the TFRC-SP flows. That is, the TFRC-SP flows still receive more than their share of the bandwidth, but the TFRC-SP congestion control is more effective than that in Table 20 above.
表21显示，当具有240字节数据包的TFRC-SP与具有552字节数据包的TCP在字节模式自适应RED的情况下竞争时，TFRC-SP流仍然比TCP流接收更多带宽，但不公平程度较低，TCP流的丢包率最多是TFRC-SP流的两倍。也就是说，TFRC-SP流接收的带宽仍然超过其所占的带宽份额，但TFRC-SP拥塞控制比上表20中的拥塞控制更有效。
TFRC-SP estimates the loss interval size differently for short and long loss intervals, counting only one loss event for long loss intervals, but counting all packet losses as loss events for the short loss intervals. One question that has been raised is whether this can lead to oscillations in the average loss event rate in environments where there are many packet drops in a single loss event, and loss events switch from short to long and vice versa. As an example, consider a loss interval with N packets, including N/4 losses. If this loss interval is short (at most two round-trip times), the loss interval length is measured as 4 packets. If this loss interval is long, then the loss interval length is measured as N packets.
TFRC-SP对短丢失间隔和长丢失间隔的丢失间隔大小进行了不同的估计，长丢失间隔仅计算一个丢失事件，但短丢失间隔将所有数据包丢失作为丢失事件计算。已经提出的一个问题是，在单个丢失事件中存在多个丢包，并且丢失事件从短切换到长，反之亦然的环境中，这是否会导致平均丢失事件率的振荡。作为一个例子，考虑具有N个包的损失间隔，包括N／4损失。如果此丢失间隔较短（最多两次往返时间），则丢失间隔长度将测量为4个数据包。如果该丢失间隔很长，则丢失间隔长度被测量为N个数据包。
If the loss interval switching from short to long and back leads to severe oscillations in the average packet drop rate, and therefore in the allowed sending rate, one solution would be to have a more gradual transition between the calculation of the loss interval length for short and long loss intervals. For example, one possibility would be to use all of the packet losses for a loss interval of one round-trip time in calculating the loss interval length, to use 2/3 of the packet losses from a loss interval of two round-trip times, to use 1/3 of the packet losses from a loss interval of three round-trip time, and to use only one packet loss from a loss interval of four or more round-trip times. This more gradual mechanism would give a transition to counting all losses for a loss interval of only one round-trip time, and counting only one loss event for a loss interval of four or more round-trip times.
如果丢失间隔从短到长和向后切换导致平均分组丢弃率中的严重振荡，因此在允许的发送速率中，一种解决方案是在短丢失间隔和长丢失间隔的丢失间隔长度的计算之间有一个更渐进的过渡。例如，一种可能性是在计算丢失间隔长度时使用一个往返时间的丢失间隔的所有分组丢失，使用两个往返时间的丢失间隔的2/3分组丢失，使用三个往返时间的丢失间隔的1/3分组丢失，以及在四个或更多往返时间的丢失间隔中仅使用一个分组丢失。这种更为渐进的机制将提供一种过渡，即在仅一个往返时间的损失间隔内计算所有损失，在四个或更多往返时间的损失间隔内仅计算一个损失事件。
However, our simulations so far have not shown a great difference in oscillations in the estimate loss event rate between the default mechanism for estimating the loss interval length for short loss interval and the gradual mechanism described above. Simulation scripts are available from [VOIPSIMS]. Therefore, for now we are staying with the simple default mechanism for estimating the loss event rate for short loss intervals described in this document.
然而，到目前为止，我们的模拟结果表明，对于上述短时间内的损失，我们对损失率的估计并没有显示出很大的差异。模拟脚本可从[VOIPSIMS]获得。因此，目前我们使用简单的默认机制来估算本文档中描述的短期损失间隔的损失事件率。
The lists below give a general summary of the relative advantages of packet-dropping behavior at routers independent of packet size, versus packet-dropping behavior where large packets are more likely to be dropped than small ones.
下面的列表概括了独立于数据包大小的路由器上的数据包丢弃行为相对于大数据包比小数据包更容易丢弃的数据包丢弃行为的相对优势。
Advantages of Packet Dropping Independent of Packet Size:
独立于数据包大小的数据包丢弃的优点：
1. Adds another incentive for end nodes to use large packets.
1. 为终端节点使用大数据包增加了另一个激励因素。
2. Matches an environment with a limitation in pps rather than bps.
2. 匹配具有pps（而非bps）限制的环境。
Advantages of Packet Dropping as a Function of Packet Size:
作为数据包大小函数的数据包丢弃的优点：
1. Small control packets are less likely to be dropped than are large data packets, improving TCP performance.
1. 与大数据包相比，较小的控制包不太可能被丢弃，从而提高了TCP性能。
2. Matches an environment with a limitation in bps rather than pps.
2. 匹配具有bps（而非pps）限制的环境。
3. Reduces the penalty of TCP and other transport protocols against flows with small packets (where the allowed sending rate is roughly a linear function of packet size).
3. 减少TCP和其他传输协议对小数据包流的惩罚（其中允许的发送速率大致是数据包大小的线性函数）。
4. A queue limited in bytes is better than a queue limited in packets for matching the worst-case queue size to the worst-case queueing delay in seconds.
4. 在将最坏情况下的队列大小与最坏情况下的排队延迟（以秒为单位）相匹配方面，以字节为单位的队列优于以数据包为单位的队列。
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
资料性引用
[EA03] W. Eddy and M. Allman. A Comparison of RED's Byte and Packet Modes, Computer Networks, 42(2), June 2003.
[EA03]W.Eddy和M.Allman。雷德字节和数据包模式的比较，计算机网络，42（2），2003年6月。
[P04] T. Phelan, TFRC with Self-Limiting Sources, October 2004, <http://www.phelan-4.com/dccp/>.
[P04]T.Phelan，具有自限源的TFRC，2004年10月<http://www.phelan-4.com/dccp/>.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC879] Postel, J., "TCP maximum segment size and related topics", RFC 879, November 1983.
[RFC879]Postel，J.，“TCP最大段大小和相关主题”，RFC879，1983年11月。
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[RFC1144]Jacobson，V.，“压缩低速串行链路的TCP/IP报头”，RFC1144，1990年2月。
[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月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]Spring，N.，Weterral，D.，和D.Ely，“带有nonce的鲁棒显式拥塞通知（ECN）信令”，RFC 35402003年6月。
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[RFC3714]Floyd，S.和J.Kempf，“IAB对互联网语音流量拥塞控制的关注”，RFC 3714，2004年3月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]Karn，P.，Bormann，C.，Fairhurst，G.，Grossman，D.，路德维希，R.，Mahdavi，J.，黑山，G.，Touch，J.，和L.Wood，“互联网子网络设计师的建议”，BCP 89，RFC 3819，2004年7月。
[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月。
[RFC3448bis] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", Work in Progress, March 2007.
[RFC3448bis]Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，正在进行的工作，2007年3月。
[S05] Peter Sholander, private communications, August 2005. Citation for acknowledgement purposes only.
[S05]Peter Sholander，《私人通信》，2005年8月。引文仅供确认之用。
[V00] P. Vasallo. Variable Packet Size Equation-Based
Congestion Control. ICSI Technical Report TR-00-008,
April 2000, <http://www.icsi.berkeley.edu/cgi-bin/
pubs/publication.pl?ID=001183>
[V00] P. Vasallo. Variable Packet Size Equation-Based
Congestion Control. ICSI Technical Report TR-00-008,
April 2000, <http://www.icsi.berkeley.edu/cgi-bin/
pubs/publication.pl?ID=001183>
[VOIPSIMS] Web page <http://www.icir.org/tfrc/voipsims.html>.
[VOIPSIMS]网页<http://www.icir.org/tfrc/voipsims.html>.
[WBL04] J. Widmer, C. Boutremans, and Jean-Yves Le Boudec. Congestion Control for Flows with Variable Packet Size, ACM CCR, 34(2), 2004.
[WBL04]J.威德默、C.布特雷曼斯和让·伊夫·勒布德克。可变数据包大小流的拥塞控制，ACM CCR，34（2），2004。
Authors' Addresses
作者地址
Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
Sally Floyd ICSI互联网研究中心美国加利福尼亚州伯克利中心街1947号600室，邮编94704
EMail: floyd@icir.org
EMail: floyd@icir.org
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
Eddie Kohler 4531C Boelter Hall加州大学洛杉矶分校计算机科学系美国加利福尼亚州洛杉矶90095
EMail: kohler@cs.ucla.edu
EMail: kohler@cs.ucla.edu
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。