[要約] RFC 4828は、TCP Friendly Rate Control（TFRC）プロトコルのSmall-Packet（SP）バリアントに関するものです。このRFCの目的は、小さなパケットサイズに最適化されたTFRCアルゴリズムを提供することです。
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）The IETF Trust（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）は、最高のインターネット環境（RFC 3448）で動作するユニキャストフローの輻輳制御メカニズムです。TFRCは、固定パケットサイズを使用するアプリケーションを対象としており、同じパケットサイズを使用してTCP接続と帯域幅を競うときに合理的に公平になるように設計されています。このドキュメントは、小さなパケットを送信するアプリケーション向けに設計されたTFRCの小パケット（SP）バリアントであるTFRC-SPを提案しています。TFRC-SPの設計目標は、最大1500バイトのパケットを使用したTCPフローと同じ帯域幅（1秒あたりのビット）を達成することです。TFRC-SPは、データパケット間で10ミリ秒の最小間隔を強制して、単一のフローが小さなパケットが頻繁に頻繁に送信するのを防ぎます。
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
This document specifies TFRC-SP, an experimental, Small-Packet variant of TCP-friendly Rate Control (TFRC) [RFC3448].
このドキュメントは、TCPフレンドリーレートコントロール（TFRC）[RFC3448]の実験的で小パケットバリアントであるTFRC-SPを指定します。
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]に記載されているように損失イベント比を推定することにより損失率を測定し、この損失イベント率を使用して、往復時間ごとにパケットの送信率を決定します。これは、大型パケットTCPフローでボトルネックを共有するときにTFRCフローが達成できる速度に影響を与えます。特に、TFRCアプリケーションの名目レートが1秒あたりの名目レートが達成されていない場合でも、高帯域幅のボトルネックを共有する低帯域幅のTFRCフローがボトルネックを共有する大型パケットTCPフローは、遅くなることを余儀なくされる可能性があります。TCPフローによって。直感的には、これは、ネットワークの制限が毎秒（ルーティングの検索など）パケット（リンク帯域幅など）ではなく（ルーティングの検索など））の場合にのみ「公正」になります。従来の知恵は、将来のネットワークの制限が1秒あたりのパケットの制限に戻る可能性があるにもかかわらず、今日のインターネットのネットワークの制限の多くは毎秒1秒あたりのバイトにあるということです。
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 msのパケット間の最小間隔によって制限されています。これにより、1秒あたりの送信金利が小さなパケットの使用に苦しむことを望まないアプリケーションをより適切にサポートします。このバリアントは、10ミリ秒ごとに1回しかパケット（最小間隔または最小間隔）を送信するアプリケーションに制限されています。この制限を考えると、TFRC-SPは、ボトルネックの制限が毎秒バイトにあるかのように、TFRCの公正レートを効果的に計算します。TFRC-SPを使用したアプリケーションは、固定または自然に変化するパケットサイズを持つことができます。また、混雑に応じてパケットサイズを変える可能性があります。パケット間で10 msの最小間隔によって制限されることをいとわないアプリケーション、または1500バイトを超えるパケットを送信したいアプリケーションは、TFRC-SPを使用しないでください。ただし、パケット間で少なくとも10ミリ秒の最小間隔と最大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 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.
TFRCのプロトコル仕様であるRFC 3448は、固定送信速度を持つが混雑に応じてパケットサイズを変えるアプリケーションのTFRCのバリアントであるTFRC-PS（TFRC-Packetsize）のTFRC-PS（TFRC-Packetsize）が後の文書で指定されると述べました。。代わりに、このドキュメントは、アプリケーションを送信するアプリケーション用に設計されたTFRC-SPであるTFRC-SPを指定します。アプリケーションは、固定またはさまざまなパケットサイズを持つか、混雑に応じてパケットサイズを適応させることができます。ただし、このドキュメントのセクション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フローが1秒あたりのパケット（PPS）ではなく、ネットワークの制限が毎秒（BPS）であると仮定し、1500バイトのパケットと同じパケットドロップレートを備えたTCPフローと同じ送信レートが1秒あたりのバイトで。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に制限がある場合に適切に対応することです。そのような理想は達成するのが困難です。そのような理想を達成することができるまで、電話交通の輻輳制御の展開を遅らせたくありません。さらに、現在のTCP混雑制御メカニズムは、それ自体が逆に沿って制限がある環境ではそれほど効果的ではないことに注意してください。PPSのパス。TCPメカニズムは大きなデータパケットを使用するインセンティブを提供しますが、TCPにはリバースパス上の小さな確認パケットのストリームの効果的な輻輳制御メカニズムは含まれていません。上記の引数を考えると、電話トラフィックの最小送信率を考慮する際に、PPSではなくBPSのネットワーク制限を仮定します。」
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の輻輳制御メカニズムに翻訳すると、BPSの送信率でTCPフローで大まかな公平性を達成するために小さなパケットを送信する低帯域幅の流れを可能にするTFRCのバリアントを標準化することは許容されるように思われます。PPSの送信率の観点からではなく。これは、以下で説明するように、TFRCの小さな変更であるTFRC-SPによって達成されます。
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-SP接続が標準のTFRCまたはTCP接続が単一の大きなパケットを送信する場合に多くの小さなパケットを送信できるため、TFRCの損失イベント率の計算の変更が必要です。標準のTFRCまたはTCP接続が、高いパケットドロップレートに直面して往復時間ごとに複数のパケットを繰り返し送信することはできません。その結果、TCPと標準のTFRCは、往復時間ごとに単一の損失イベントにのみ応答し、ますます重いパケット損失率を検出して応答することができます。ただし、高度に組み立てられた環境では、TCP接続が平均して往復時間ごとに1つの大きなパケットを送信する可能性がある場合、対応する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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[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が1秒あたりのバイト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]に続いて、これは、パケットごとに1460バイトのアプリケーションデータを備えたTCPフローで、同じパケットドロップレートを備えたTCPフローで、公平性の目標を提供します。エンドポイントがパスの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は、1秒あたりのバイトでのパケットヘッダーサイズを説明する係数によって減少します。これにより、不必要に小さなパケットを使用しないように、最小間隔を超えて、アプリケーションにある程度のインセンティブが得られます。特に、TFRC接続のパケットで使用するネットワークおよびトランスポートヘッダーのバイトの予想されるサイズを表す新しいパラメーターHを導入します。これは、許可された送信速度xを次のように削減するために使用されます。
X := X * s_true / (s_true + H),
x：= x * s_true /（s_true 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に使用される場合、推定値は少なくとも最後の4つの損失間隔で計算する必要があります。ただし、このドキュメントでは、平均セグメントサイズを推定するための特定のアルゴリズムを指定していません。
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 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.
Hパラメーターは、定数40バイトに設定されています。したがって、TFRC-SPアプリケーションが40バイトのデータセグメントを使用した場合、送信率の半分がヘッダーによって使用されるという事実を説明するために、許可された送信速度xが半分になります。セクション4.2は、この定義を正当化します。ただし、TFRC-SPを使用する接続は、接続のパケットで使用する実際のネットワークとトランスポートヘッダーに基づいて、Hのより正確な推定値を使用する場合があります。たとえば、データパケットがDCCP-DATAパケットタイプを使用し、IPまたはDCCPオプションがない場合、データパケットがIPv4を介してデータグラムの混雑制御プロトコル（DCCP）接続[RFC4340]を使用すると、Hを20 12 = 32バイトに設定できます。ただし、TFRCの実装がIPレイヤーがIPv4の代わりにIPv6を使用していることを知っている場合、TFRC-SPを使用した接続は、実装の単純さのために、実際の60バイトの代わりにHのデフォルト推定値40バイトを使用する場合があります。
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 高い損失時の損失イベント率の測定：短い損失間隔（最大2回の往復時間）の間、損失率は、最大1つの損失イベントではなく、失われたパケットまたはマークの実際の数をカウントすることによって計算されます。損失間隔ごと。この変更がなければ、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の場合、最大2回の往復時間の小さな損失間隔の場合、損失間隔がK損失を含むNパケットで構成されている場合、損失間隔のサイズはn/kとして計算され、損失イベントに寄与します1/nの代わりにk/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は、平均損失間隔の計算には、その損失間隔の開始以来2回以上の往復時間が経過した場合にのみ、最新の損失間隔を含めることができるという制限を追加します。
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が最新の損失イベントを含む間隔であり、RFC 3448で定義されている対応する重みW_Iと同様に、RFC 3448（セクション5.4）では、平均損失間隔I_MEANが計算されます。フォロー：
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_Meanが次のように計算されます。
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ミリ秒のパケット間の最小間隔を強制します。輸送プロトコルがこのMIN間隔を超えることを望むフローは、TFRC-SPではなく、従来のTFRC方程式を使用する必要があります。これの動機については、以下で説明します。
TFRC uses the TCP throughput equation given in [RFC3448], with the sending rate X in bytes per second as follows:
TFRCは、[RFC3448]に与えられたTCPスループット方程式を使用し、送信速度xは次のように1秒あたりのバイト単位で使用します。
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.
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応答関数から導出できます。さらに、最大2回の往復時間の損失間隔では、TFRC-SPの損失イベント率は、損失イベントをカウントするのではなく、実際の紛失またはマークされたパケットをカウントすることによって推定されます。さらに、TFRC-SPの送信率は、1秒あたり最大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の固定ドロップレートPを持つ環境の場合、TCP、TFRC、およびTFRC-SPの応答関数を次のように示します。100ミリ秒の時間：
<-- 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の応答関数。パケットドロップレートの関数として、KBPのレートを送信します。
<---------- 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の応答関数。パケットドロップレートの関数として、KBPのレートを送信します。1秒あたり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応答関数は、1秒あたり100個のパケットの最大送信率を反映しています。この最大送信率によって制限されない場合、TFRC-SPフローは、同じパケットドロップレートを与えられた1460バイトセグメントのTCPフローと同じKBPで同じ送信レートを受け取ります。構成されたパケットドロップレートに応答したTCP、標準TFRC、およびTFRC-SPの送信レートを示すシミュレーションは、表7、8、および9に記載されており、ここに示す応答関数と一致しています。
<-- 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
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でレートを送信します。1秒あたり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の場合、パケットドロップレートは、bのバイトドロップレート、およびnバイトのパケットサイズの場合、1-（1-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.
構成されたバイトドロップレートに応答したTCP、標準TFRC、およびTFRC-SPの送信レートを示すシミュレーションは、付録B.2に示されています。
[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, by including the bandwidth used by the packet header in the allowed sending rate.
[RFC3714]は、ネットワークの制限がCPUサイクルまたは秒あたりのパケット（PPS）ではなく帯域幅（BPS）であるという楽観的な仮定を行います。ただし、PPSの負荷とBPSの負荷に注意を払う必要があります。MIN間隔を除いて、TFRC-SPは、許可された送信レートでパケットヘッダーが使用する帯域幅を含めることにより、より大きなパケットを十分に使用する場合、より少ないが大きなパケットを使用するインセンティブをアプリケーションに提供します。
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バイトパケットを使用する送信者は、96 kbpsのアプリケーションデータを送信するために128 kbpsのTCPフレンドリーレートを必要とします。これは、パケットヘッダーの効果を説明するために、TCPに優しいレートがS_True/（S_True H）= 120/160の係数によって削減されるためです。送信者が突然40バイトのデータセグメントに切り替えた場合、許可される送信率は64 kbpsのアプリケーションデータに減少します。また、1バイトのデータセグメントを使用すると、許可された送信率が3.12 kbpsのアプリケーションデータに低下します。（実際、TFRC-SPを使用するアプリケーションが1秒あたり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バイトヘッダーのデフォルト使用で十分です。
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 msの最小間隔が含まれます。これにより、使用される小さなパケットの量に追加の制限が提供されます。
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.
最小間隔の実際の正当化の1つは、現在小さなパケットを送信したいアプリケーションが10ミリ秒ごとに最大1つのパケットを送信するVoIPアプリケーションであるため、この制限は現在のトラフィックに影響しないことです。2番目の正当化は、現在のインターネットで最高のエフォルトトラフィックが10ミリ秒ごとに1回より頻繁に小さなパケットを送信する必要がないということです（送信者で10ミリ秒の遅延を取得し、2つの小さなパケットを1つにマージするのではなく、大きいもの）。小さなパケットをマージするためのこの10ミリ秒の遅延は、現在のインターネットでのベストエフォートトラフィックのネットワーク伝播、送信、およびキューイングの遅延によって支配される可能性があります。その結果、私たちの判断は、パケット間に10ミリ秒未満のユーザーにとっての利益が、過剰な量の小さなパケットを回避するネットワークの利益によって上回るということです。
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.
フローが複数の接続を開くのを防ぐために、それぞれが10ミリ秒の間隔で、それによって最小間隔の制限を回避することは何ですか？明らかに、フローが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の場合、往復時間ごとに1つ以上のパケットがドロップされると、送信レートは往復時間ごとに1パケット未満に迅速に低下します。さらに、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]。往復時間ごとに1つの大きなパケットを送信する代わりに、TFRC-SPはn小さなパケット（nの小さなパケットが1つの大きな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では、損失イベント率は、2回の往復時間よりも長い損失間隔で最大1つの損失イベントをカウントし、各パケットが損失またはより短い損失間隔でマークされたカウントをカウントすることにより計算されます。特に、kの紛失またはマークされたパケットを含むNパケットを使用した短い損失間隔では、損失間隔の長さはN/kとしてn/kとして計算されます。、RFC 3448のセクション5.4で指定されているように。したがって、8つの連続した損失間隔がNパケットとKの損失による短い損失間隔である場合、損失イベント率は1/NではなくK/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バイトに設定されており、パケットごとに1460バイトのアプリケーションデータを備えたTCPフローで、1秒あたりのバイトの送信レートの観点から、公平性の目標を提供します。同じパケットドロップレート。これは、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あたりのバイトの送信速度は、Sバイトのパケットサイズとパケットドロップレートpの場合、約1.2 s/sqrt（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であり、約1.2 SQRT/SQRT（P1）のRTTあたりのバイトで送信レートを生成します。したがって、固定バイトドロップレートの環境での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の各行は、10のTCP接続と0.0001の固定バイトドロップレートを備えた個別のシミュレーションを示しており、各シミュレーションは異なるセグメントサイズを使用して使用しています。各シミュレーションについて、TCP送信レートとグッドプットは10のフローで平均化されます。上記の段落から予想されるように、TCP送信率は、パケットサイズの1460バイトまでのパケットサイズの増加とともに、13％のパケットサイズの1460バイトまで増加します。その後、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
Table 5: TCP Median Send Rate vs. Packet Size I: Byte Drop Rate 0.0001
表5：TCP中央値送信レート対パケットサイズI：バイトドロップレート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グッドプット率は本質的にゼロのままであることに注意してください。送信されるほとんどすべてのパケットが削除されるため、これは理にかなっています。
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：バイトドロップレート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フローと同じ送信レートを達成することを示唆しています。パケットサイズが最大1500バイトであることを考えると、最適なパケットサイズでTCPフローと同じ送信率を達成するTFRC-SPフローの理想的な目標。これは、許可された送信速度を計算するためにTFRC-SPメカニズムを変更する必要があるという意味ではありません。これは、TFRC-SPの公平性を評価する際に、その環境の最適なパケットサイズ（まだ最大1500バイト）を使用してTCPフローに対する公平性を考慮する必要があることを意味します。
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]).
このドキュメントは、パケットの断片化とPATH 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 available bandwidth, to the exclusion of the competing TCP or TFRC-SP flow.
TCP MSSが実際に536バイトのみであるパス上の1460バイトの公称セグメントサイズsでTFRC-SPを使用する場合、TFRC-SPフローは、帯域幅のほぼ3倍、1秒あたりのバイトで、536バイトのMSSを使用したTCPフロー。同様に、MSSが4000バイトに近い環境では、TCPフローは、1460バイトの公称セグメントサイズsを備えたTFRC-SPフローの帯域幅のほぼ3倍を受け取る可能性があります。どちらの場合も、2つまたは3つの要因を持つこれらのレベルの「不公平」は受け入れられると感じています。特に、競合するTCPまたはTFRC-SPフローを除外して、利用可能な帯域幅をすべて把握する1つのフローになりません。
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 * ENDホスト *は、サイズ576バイト[RFC791]のIPパケットを受け入れて再組み立てる必要がありますが、IPv4 *リンク *は必ずしもこのパケットサイズをサポートする必要はありません。遅いネットワークでは、可能な最大のパケットが[RFC3819]を送信するのにかなりの時間がかかる場合があり、より小さなMTUが望ましい場合があります。たとえば、数百バイトです。ファーストホップリンクに小さなMTUがある場合、TCPは適切に小さなMSS [RFC879]を選択します。[RFC1144]は、MSSが数十バイトである可能性がある非常に低いリンク速度のケースを引用します（これは極端なケースです）。TFRC-SPが576バイトよりもかなり小さいMTUのパスで使用され、TFRC-SPフローが1460バイトの公称セグメントサイズsを使用する場合、TFRC-SPフローは3回以上を受信できる可能性があることに注意してください。競合する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が536バイト未満の名目セグメントサイズsで使用されている場合（パスMTUが576バイト未満であることが知られているため）、TFRC-SPはアプリケーションにとって最小限の利点になる可能性があります。TFRC-SPが576バイト未満のパスMTUを持つパスで使用される場合、パスMTUを追跡するためにトランスポートプロトコルが必要とされなかった場合、これにより、デフォルトの名目上を使用してTFRC-SPフローが発生する可能性があります。1460バイトのセグメントサイズ、その結果、競合するTCPフローよりもかなり多くの帯域幅を受け取ります。その結果、TFRC-SPは、PATH 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ごとに少なくとも1回送信されます。
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接続（2回の往復時間未満）の場合、その損失間隔がその損失間隔の追加パケット損失が検出されると、その損失間隔が変化する可能性があります。。平均損失間隔の不必要な振動を防ぐために、セクション3は、現在の損失間隔が2回の往復時間より長い場合にのみ、平均損失間隔の計算に現在の損失間隔を含めることができることを指定します。
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月の文書は、TFRCとDCCPの作業を含むIETFでの継続的な取り組みを引用しています。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%.
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で説明されている最小限のメカニズムに細粒の制御がないことの1つの制限は、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 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の使用可能な1つの使用は、1秒あたりパケットの固定送信率を維持するアプリケーションですが、混雑に応じてパケットサイズを変更するアプリケーションです。TFRC-SPは、接続のパケットドロップレートを監視し、1秒あたりのバイトでの許可された送信レートを決定します。1秒あたりのパケットに固定送信率があるアプリケーションを考えると、TFRC-SP送信者は、許可された送信率を超えないように、1秒あたりのバイトの送信率に必要なデータパケットサイズを決定できます。パケットドロップレートがパケットサイズの影響を受ける環境では、パケットサイズを減らすと、フローが経験するパケットドロップレートが低下する可能性があります。
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.
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を使用するアプリケーションには、使用できるパケットサイズが少ない場合があります。この場合、2つのパケットサイズと2つの送信レートの間の不必要な振動を避けるために、現在のパケットドロップレートが現在の送信レートのパケットドロップレートのしきい値を大幅に超えるまで、アプリケーションはパケットサイズを縮小しない場合があります。繰り返しますが、詳細は、よりアプリケーション固有のドキュメントで対処する必要があります。
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の送信レートは、1秒あたりのパケットではなく、1秒あたりのバイトであるため、システムを「ゲーム」するためにパケットサイズを操作する機会はほとんどありません。これは、CCID 3（[RFC4342]のセクション5.3）のTFRCとは異なり、許可された送信率は毎秒パケットにあります。特に、しばらく小さなパケットを送信する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フローよりもかなり多くの帯域幅を受け取ることができます。場合によっては、大型パケットTCPフローは、競合する小パケットTFRC-SPフローによって本質的に飢えている可能性があります（付録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フローで大まかな公平性を持つことです。各パケットがほぼ同じ確率を受信するシナリオで落とされている。大きなパケットが小さなパケットよりもドロップされる可能性が高いシナリオや、滑らかな送信レートでフローよりもパケットがドロップされる可能性が高い場合、小パケットTFRC-SPフローは大幅に受信できます。競合する大パケット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 the TCP response function in representing the actual sending rate of a TCP connection.
TFRCで使用されるTCP応答関数の精度：96 kbps以下の最大送信レート（つまり、最大120バイトのパケット）のアプリケーションの場合、TFRC-SPは、パケットドロップレートがかなり高い場合にのみ送信レートを制限します。、たとえば、10％を超える。[派生：200 msの往復時間と128 kbpsのパケットヘッダーを伴う最大送信レートのTFRC-SPフローは、1460バイトのセグメントが2.2パケットあたり2.2パケットを送信するTCPフローに相当する1秒あたりのバイトで送信速度を持ちます。往復時間。RFC 3714の表1から、この送信レートは、10％をわずかに大きくパケットドロップレートで維持できます。]このハイパケットドロップ制度では、TFRC-SPの性能は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アルゴリズム（例：サックなど）、最小RTO、限られた送信（またはその欠如）の使用、ECNの使用などの影響を受けます。公平性を探るシミュレーションや実験には、現在の標準に適合した最も積極的なTCPメカニズムを備えた公平性の調査が含まれるようにすることは良いことです。私たちのシミュレーションでは、送信が限られており、最小RTOの200ミリ秒のSack TCPを使用しています。シミュレーション結果は、タイムスタンプの有無にかかわらずほとんど同じです。この論文では、タイムスタンプはシミュレーションには使用されませんでした。TFRCのターゲット送信率を設定する際にECNを使用してTCPを使用しませんでした。付録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バイト3は、小さな10バイトデータセグメントを備えたアプリケーションの場合、実際のパケットサイズは、許可された50バイトで想定される50バイトではなく、70、90、または110バイトになる可能性があることを意味します。送信レート。したがって、大きなヘッダーを備えたTFRC-SPアプリケーションは、小さなヘッダーを備えたTFRC-SPアプリケーションよりも帯域幅（ヘッダーが使用する帯域幅を含む）を2倍以上受信できます。これが問題になるとは考えていません。特に、大きなヘッダーを備えた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の混雑制御メカニズムは、1秒あたりのパケットのフローの送信速度を制限します。Tom Phelan [P04]によるシミュレーションでは、そのような送信率の制限が、いくつかのシナリオでTFRCフローの不公平につながる可能性があることを探ります。
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およびTCPを備えた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
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.
DCCPの混雑制御ID 3のセキュリティ上の考慮事項、TFRCを使用する輸送プロトコルであるTFRC混雑制御は、[RFC4342]で説明されています。この文書は、送信者が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を指定しました。これは、最大のパケットを1秒あたり100個のパケットで送信するアプリケーション用に設計されていますが、TCP接続と同じ送信レートを経験することを望んでいます。同じパケットドロップレートですが、1500バイトのパケットを送信します。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.
Datagramうっ血制御コントロールプロトコル（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.
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]は、TFRCで使用される実際のパケットサイズではなく、TCPに優しい方程式でPATH MTUを使用することを提案し、パケットドロップを集約して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.
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]とは異なり、1秒あたり最大100個のパケットを送信するフローへの注意を制限します。私たちのドキュメントで提案されているTFRC-SPバリアントは、許可された帯域幅にパケットヘッダーが使用する帯域幅が含まれるという点で、[WBL04]で説明されているストロー提案とは異なります。
[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]は、損失測定プロセスを変更するための4つの方法、「アンベイシング」、「仮想パケット」、「ランダムサンプリング」、および「損失不感期（LIP）スケーリング」について説明します。[WBL04]は、ネットワークがパケットサイズとは無関係にパケットをドロップすると、2番目と3番目のメソッドのみが十分に堅牢になります。ネットワークが小さなパケットよりも大きなパケットをドロップする可能性が高い場合、2番目の方法のみが十分に堅牢になります。損失イベント率を計算する方法は、ランダム化が使用されていないことを除いて、[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 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).
[WBL04]は、それぞれバイトとパケットごとのドロップがあるパス上の接続に対して、TFRCトランスポートプロトコルのバイトモードとパケットモードバリアントの両方を生成します。ネットワーク内のパケットがパケットごと、バイトごとにあるか、その間のどこかであるかどうかを判断するためのトランスポートレベルのメカニズムがない場合、のパケットドロップ動作とは無関係に、単一のTFRC実装が必要であると主張します。パスに沿ったルーター。もちろん、接続とネットワーク全体に、ほぼ許容される動作を提供するメカニズムを持つことが望ましいでしょう。バイトドロップメカニズム、パケットごとのドロップメカニズムを備えたメカニズム、およびパケットごととパケットごとのどこかにあるドロップメカニズムを備えたものもあります）。
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/テストの検証テスト「./test-allフレンドリー」に示されています。このドキュメントのシミュレーションのシミュレーションスクリプトとグラフは、[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フローのスループット、タイムスタンプと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
* 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)
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は、両方のフローが1460バイトのデータセグメントを持っている場合、TCPとTFRCの相対的な公平性を説明するために、両方のフローが1460バイトデータセグメントを持っている場合、TCPの送信レートと構成されたパケットドロップレートの標準TFRCフローを示しています。パケットサイズ。たとえば、0.1のパケットドロップレートは、TCPおよびTFRCパケットの10％がドロップされることを意味します。TFRCフローは、1秒あたり最大100個のパケットを送信するように構成されています。TFRCフローが標準のTCPフローの3〜5倍の帯域幅を受け取る場合、パケットドロップの割合が40および50％に達するまで、相対的な公平性が良好です。ECNマークがパケットドロップの代わりに使用されている場合、ECN TCPフローは、これらの高いパケットドロップレートでTFRCフローよりも高いスループットを受信することに注意してください。ただし、これらのハイパケットドロップシナリオのECN TCP送信率は、TFRCのターゲット送信レートとして使用しません。）。さらに、このような高いパケットドロップ/マーキングレートを備えたシナリオにバッファオーバーフローが発生する可能性が高く、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
* 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セグメント（5.6 kbps最大TFRCデータ送信率）
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.
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バイトデータパケットの送信率です。したがって、TFRC送信率の30％のみがデータ用であり、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）が、大規模なTCP接続の送信率と比較して、BPSの送信率が非常に低いことを示しています。対照的に、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.
< - - - - - - 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.
*
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
* 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は、ECNの有無にかかわらず、TCPセグメントサイズの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
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.
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は、本質的に3つの別々の領域を示しています。バイトドロップレートが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 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.
表10の中央領域では、バイトドロップレートが0.0001から0.005になり、最適なTCPセグメントサイズはバイトドロップレートの関数です。特に、最適なTCPセグメントサイズは、パケットドロップレートを最大15％に保つパケットドロップレートを最大15％に保つものであると思われます。パケットドロップレートの1/SQRT（P）送信レートで制御されるレジームのTCP接続を維持します。Sバイト（ヘッダーを含む）のTCPパケットサイズ、およびbの*バイト*ドロップレートの場合、パケットドロップレートはほぼb*sです。このレジームの特定のバイトドロップレートの場合、最適なTCPパフォーマンスが最大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.
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.
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].
異なるパケットサイズを使用して2つのフローのスループットを比較する際の問題の1つは、パケットサイズ自体がパケットドロップレートに影響を与える可能性があることです[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は、同じパケットサイズのTFRCおよびTCPフローのために、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
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は、5つのTCP接続と5つのTFRC-SP接続が3 Mbps共有リンクを使用してトポロジでWebトラフィックと競合する5つのTCP接続と5つのTFRC-SP接続を備えた100秒シミュレーションの後半の結果を示しています。TFRC-SPアプリケーションは、160 kbpsの最大データレートで、10ミリ秒ごとに200バイトのデータパケットを生成します。5つの長寿命のTCP接続は、1460バイトのデータパケットサイズを使用し、Webトラフィックは512バイトのデータパケットサイズを使用します。5つのTCP接続には、40〜240ミリ秒の往復時間があり、5つの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送信率を示し、それぞれが5つのフローで平均しました。予想どおり、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
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.
ただし、混雑した出力リンクのドロップテールキューがパケットではなくバイト単位にある場合、公平性の結果は大幅に変化する可能性があります。パケットのキューの場合、キューには固定数のバッファーがあり、各バッファーはバイトのサイズに関係なく、正確に1つのパケットを保持できます。バイトのキューの場合、キューには固定数の *バイト *があり、ほぼフルなキューには小さなパケット用のスペースがありますが、大きなパケットではありません。したがって、バイトにドロップテールキューを備えたシミュレーションの場合、小さなパケットが小さなパケットよりもドロップされる可能性が高くなります。NSシミュレーターには、キューに固定数のバッファーがあり、各バッファーには固定数のバイトがあり、各パケットには1つ以上のフリーバッファーが必要です。このモデルでは、小さなパケットは1つのバッファーを使用しますが、大きなパケットにはいくつかのバッファーが必要です。
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のシナリオと同じです。したがって、5つのTCP接続と5つのTFRC-SP接続は、3 Mbps共有リンクを使用してトポロジでWebトラフィックと競合し、各TFRC-SPアプリケーションは10ミリ秒ごとに200バイトのデータパケットを生成し、160 kbpsの最大データレートを生成します。さまざまなレベルの混雑を作成するために、Webセッションの数はさまざまです。ただし、最大100個のパケットに対応できるドロップテールキューの代わりに、ルーターのドロップテールキューはそれぞれ最大50,000バイトに対応できます（NSで500バイトの平均パケットサイズの100倍に計算）。
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 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.
< - - - - - 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
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セッションを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
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
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 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.
表15はTFRC-SPを使用したシミュレーションを示し、表16はTFRC-SPの代わりにTFRCを使用したシミュレーションを示しています。これは、2つのテーブルのシミュレーションの唯一の違いです。TFRC-SPを使用すると、TCPフローとWebトラフィックが本質的に飢えていますが、TFRC-SPフローはそれぞれ57 kbpsを送信し続けます。対照的に、200バイトセグメントを送信するフローにTFRC-SPの代わりに標準のTFRCを使用する場合、TCPフローは飢えていません（ただし、パケットドロップレートがある場合、リンク帯域幅の「共有」を受け取りませんが30％以上）。これらの2つのシミュレーションは、小さなパケットが大きなパケットよりもドロップされる可能性が低い環境での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）メカニズムを変化させることで変化させることもできます。ルーターが赤（ランダム早期検出）を使用する場合、パケットサイズの関数としてパケットドロップまたはマーキングの動作に影響を与えるよりもいくつかのパラメーターがあります。
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.
まず、ドロップテールと同様に、赤いキューはパケットまたはバイトのいずれかの単位にある場合があります。これは、赤が平均キューサイズとキューのオーバーフローを制御できない場合のパケットドロップ動作に影響を与える可能性があります。
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]は、赤の性能に対するバイトモードとパケットモードの影響を評価しました。
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フローの許容可能なスループットが得られることを示しています。これは、パケットまたはバイト内のキュー、および適応赤色の有無にかかわらずに当てはまります（以下で説明します）。以下に示すように、TCPとTFRC-SPフローの間のこの公平性は、バイトモードで赤の場合は保持されません。
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 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).
パケットサイズの関数としてパケットドロップまたはマーキングの動作に影響を与える3番目の赤いパラメーターは、赤いメカニズムが標準赤または適応型赤を使用しているかどうかです。Adaptive Redは、パケットドロップレートに関係なく、同じ平均キューサイズを維持しようとします。適応型赤の使用により、赤いメカニズムは、高いパケットドロップレート（たとえば、10％を超える）の存在下でより効果的に機能することができます。適応型赤がなければ、固定されたドロップしきい値があり、ドロップまたはマーキングレートがこのしきい値を超えると、すべての到着パケットが削除されます。対照的に、適応性のある赤とは、低ドロップレートレジームに対応するように滴下機能が適合しています。結果の1つは、適応型赤でバイトモードを使用する場合、バイトモードが高レートレートレジームにも拡張されることです。ただし、標準赤でバイトモードを使用すると、ドロップレートが固定ドロップしきい値を超えると、バイトモードが使用されなくなります（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
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
Table 18: Drop and Send Rates for RED Queues in Byte Mode
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
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 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.
表19は、バイトモードの標準的な赤いキューと512バイトのデータセグメントを持つ長寿命のTCPフローで、552バイトのTCPパケットと240バイトのTFRCのパケットドロップレートの間に中程度の違いしかないことを示しています。-SPパケット。ただし、パケットドロップ率が高い表19のシナリオでのTFRC-SPの送信率は、512バイトのデータセグメントではなく1500バイトのデータセグメントでTCPフローの公平性の目標を考えると、目的よりも大きくなります。
< - - - - - 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のシミュレーションでは、混雑したルーターはバイトモードで適応レッドキューを使用します。
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.
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が示しているように、バイトモードの適応レッドのシナリオの場合、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.
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.
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に示す不公平よりもさらに深刻であることに注意してください。同時に、バイトモードで適応性のある赤いレッドを備えたルーターのインターネットに展開があるか、同様の動作を持つAQMメカニズムの展開があるかどうかは不明です。標準の赤、または提案されている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
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と競合する場合、TFRC-SPフローはTCPフローよりも多くの帯域幅を受け取ることを示しています。深刻ではなく、TCPフローのパケットドロップレートは、TFRC-SPフローの最大2倍です。つまり、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は、短い損失間隔と長い損失間隔で損失間隔のサイズを異なると推定し、長い損失間隔で1つの損失イベントのみをカウントしますが、すべてのパケット損失を短い損失間隔の損失イベントとしてカウントします。提起された質問の1つは、これが単一の損失イベントに多くのパケットドロップがある環境での平均損失イベント率の振動につながる可能性があるかどうか、そして損失イベントは短いものから長い間に切り替わるかどうかです。例として、N/4損失を含むNパケットを使用した損失間隔を検討してください。この損失間隔が短い場合（最大2回の往復時間）、損失間隔の長さは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.
損失間隔が短いものから長いバックに切り替えると、平均パケットドロップドロップレートの重度の振動につながり、したがって許可された送信速度で、1つの解決策が、短い損失間隔の長さの計算の間により段階的な遷移を持つことです。そして長い損失間隔。たとえば、1つの可能性は、1つの往復時間の損失間隔にすべてのパケット損失を使用して、損失間隔の長さを計算することで、2つの往復時間の損失間隔からのパケット損失の2/3を使用することです。、3回の往復時間の損失間隔からのパケット損失の1/3を使用し、4回以上の往復時間の損失間隔から1つのパケット損失のみを使用します。このより漸進的なメカニズムは、1回の往復時間の損失間隔のすべての損失をカウントすることへの移行を与え、4回以上の往復時間の損失間隔の1つの損失イベントのみをカウントします。
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. BPSではなくPPSの制限で環境を一致させます。
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.
2. Matches an environment with a limitation in bps rather than pps.
2. PPSではなくBPSの制限で環境を一致させます。
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 Friendry Rate Control（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。Redのバイトモードとパケットモード、コンピューターネットワーク、42（2）、2003年6月の比較。
[P04] T. Phelan, TFRC with Self-Limiting Sources, October 2004, <http://www.phelan-4.com/dccp/>.
[P04] T.フェラン、自己制限ソースを備えたTFRC、2004年10月、<http://www.phelan-4.com/dccp/>。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC879] Postel, J., "TCP maximum segment size and related topics", RFC 879, November 1983.
[RFC879] Postel、J。、「TCP最大セグメントサイズと関連トピック」、RFC 879、1983年11月。
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[RFC1144] Jacobson、V。、「低速シリアルリンクのTCP/IPヘッダーの圧縮」、RFC 1144、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.、Wetherall、D。、およびD. Ely、「Noncesによる堅牢な明示的な混雑通知（ECN）シグナル伝達」、RFC 3540、2003年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.、Ludwig、R.、Mahdavi、J.、Montenegro、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、「Datagramうっ血制御プロトコル（DCCP）」、RFC 4340、2006年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のプロファイル：TCPに優しいレート制御（TFRC）」、RFC 4342、2006年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 Friendry Rate Control（TFRC）：プロトコル仕様」、2007年3月の作業。
[S05] Peter Sholander, private communications, August 2005. Citation for acknowledgement purposes only.
[S05] Peter Sholander、Private Communications、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。可変パケットサイズ方程式ベースの混雑制御。ICSIテクニカルレポートTR-00-008、2000年4月、<http://www.icsi.berkeley.edu/cgi-bin/ pubs/publication.pl？id = 001183>
[VOIPSIMS] Web page <http://www.icir.org/tfrc/voipsims.html>.
[Voipsims] Webページ<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. Widmer、C。Boutremans、およびJean-Yves Le Boudec。可変パケットサイズのフローの輻輳制御、ACM CCR、34（2）、2004。
Authors' Addresses
著者のアドレス
Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
サリーフロイドICSIセンターフォーインターネットリサーチ1947センターストリート、スイート600バークレー、カリフォルニア州94704 USA
EMail: floyd@icir.org
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
Eddie Kohler 4531C Boelter Hall UCLAコンピューターサイエンス部ロサンゼルス、カリフォルニア州90095 USA
EMail: kohler@cs.ucla.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。