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
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet.
この文書では、さらなる実験のためではなく、グローバルなインターネットで、この時に広く展開するためのメカニズムを提案しています。
TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment (RFC 3448). TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently.
TCPフレンドリーレート制御（TFRC）は、ベストエフォート型のインターネット環境（RFC 3448）で動作しているユニキャストフローの輻輳制御機構です。 TFRCは固定パケットサイズを使用するアプリケーションのために意図されていた、と同じパケットサイズを使用してTCP接続の帯域幅を競合するとき、合理的に公平であるように設計されました。この文書は、小さなパケットを送信するアプリケーションのために設計されているTFRC-SP、TFRCの小パケット（SP）の変異体を、提案しています。 TFRC-SPの設計目標は、最大1500バイトのパケットを使用してTCPフローとしてBPS（ビット毎秒）で同じ帯域幅を達成することです。 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].
この文書では、TFRC-SP、TCPフレンドリーなレート制御（TFRC）[RFC3448]の実験、小パケットのバリアントを指定します。
TFRC was designed to be reasonably fair when competing for bandwidth with TCP flows, but to avoid the abrupt changes in the sending rate characteristic of TCP's congestion control mechanisms. TFRC is intended for applications such as streaming media applications where a relatively smooth sending rate is of importance. Conventional TFRC measures loss rates by estimating the loss event ratio as described in [RFC3448], and uses this loss event rate to determine the sending rate in packets per round-trip time. This has consequences for the rate that a TFRC flow can achieve when sharing a bottleneck with large-packet TCP flows. In particular, a low-bandwidth, small-packet TFRC flow sharing a bottleneck with high-bandwidth, large-packet TCP flows may be forced to slow down, even though the TFRC application's nominal rate in bytes per second is less than the rate achieved by the TCP flows. Intuitively, this would be "fair" only if the network limitation was in packets per second (such as a routing lookup), rather than bytes per second (such as link bandwidth). Conventional wisdom is that many of the network limitations in today's Internet are in bytes per second, even though the network limitations of the future might move back towards limitations in packets per second.
TFRCはTCPフローに帯域幅を競合するとき、合理的に公平であるように設計されましたが、TCPの輻輳制御メカニズムの送信レート特性の急激な変化を避けるために。 TFRCは、比較的滑らかな送付レートが重要であるストリーミングメディアアプリケーションなどのアプリケーションを対象としています。従来のTFRCは、[RFC3448]に記載されているように損失イベント率を推定することにより損失率を測定し、ラウンドトリップ時間あたりのパケットで送信レートを決定するために、この損失イベント率を使用します。これは、大規模なパケットのTCPフローにボトルネックを共有する場合TFRCの流れを達成することができます率にも影響があります。特に、低帯域幅は、高帯域幅のボトルネックを共有する小さなパケットTFRCフローは、大パケットのTCPフローは、秒あたりのバイト数でTFRCアプリケーションの名目レートが達成率未満であっても、スローダウンするように強制することができますTCPで流れています。直感的に、これは、ネットワークの制限は、（例えば、ルーティング・ルックアップなど）秒あたりのパケットではなく、（例えばリンク帯域幅など）秒あたりのバイト数であった場合にのみ、「公正」であろう。従来の知識は、将来のネットワークの制限は、秒あたりのパケットに制限の方に戻って移動する可能性があるにもかかわらず、今日のインターネットでのネットワーク制限の多くは、秒あたりのバイト数であるということです。
TFRC-SP is intended for flows that need to send frequent small packets, with less than 1500 bytes per packet, limited by a minimum interval between packets of 10 ms. It will better support applications that do not want their sending rates in bytes per second to suffer from their use of small packets. This variant is restricted to applications that send packets no more than once every 10 ms (the Min Interval or minimum interval). Given this restriction, TFRC-SP effectively calculates the TFRC fair rate as if the bottleneck restriction was in bytes per second. Applications using TFRC-SP could have a fixed or naturally-varying packet size, or could vary their packet size in response to congestion. Applications that are not willing to be limited by a minimum interval of 10 ms between packets, or that want to send packets larger than 1500 bytes, should not use TFRC-SP. However, for applications with a minimum interval of at least 10 ms between packets and with data packets of at most 1500 bytes, the performance of TFRC-SP should be at least as good as that from TFRC.
TFRC-SPは、10ミリ秒のパケット間の最小間隔によって制限パケット当たり1500バイト未満で、頻繁に小さなパケットを送信する必要が流れるためのものです。これは、秒あたりのバイト数での送信速度は、小さなパケットの利用に苦しむしたくない支援アプリケーションをより良くします。この変異体は、パケットを送信するアプリケーションに制限されていない以上10すべての回ミリ秒（最小間隔または最小間隔）。ボトルネックの制限は秒あたりのバイト数にあったかのようにこの制限を考えると、TFRC-SPは、効果的にTFRC公正率を計算します。 TFRC-SPを使用するアプリケーションは、固定または自然に変化するパケットのサイズを持つことができ、または混雑に応じて、そのパケットサイズを変えることができます。パケット間の10ミリ秒の最小間隔によって制限されることを望んでいない場合、またはそれが1500バイトを超えるパケットを送信するアプリケーションは、TFRC-SPを使用しないでください。しかし、パケット間で最も1500バイトのデータ・パケットと少なくとも10ミリ秒の最小間隔でアプリケーションのため、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.
RFC 3448、TFRCのためのプロトコル仕様は、TFRC-PS（TFRC-たPacketSizeの場合）、固定された送信速度を有するが、混雑に応じてそれらのパケットサイズを変化させる用途のためのTFRCの変異体は、後で文書に指定されることを述べ。このドキュメントではなく、アプリケーションが固定または可変パケットサイズを持っている可能性のいずれかまたは混雑に応じて、そのパケットサイズを適応させることができTFRC-SP、小さなパケットを送信するアプリケーション用に設計されたTFRCのバリアントを指定します。このドキュメントのセクション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は、VoIPは、ネットワーク制限はなく秒あたりのパケット（PPS）で秒（bps）バイトであると仮定すると、持って流れることが許容可能であると主張しているれ、RFC 3714にアプローチによって部分的に動機付けされ1500バイトのパケットでTCPフローと同じパケットドロップレートと秒あたりのバイト数で同じ送信レート。 RFC 3714には、次のように述べています：
"While the ideal would be to have a transport protocol that is able to detect whether the bottleneck links along the path are limited in Bps or in pps, and to respond appropriately when the limitation is in pps, such an ideal is hard to achieve. We would not want to delay the deployment of congestion control for telephony traffic until such an ideal could be accomplished. In addition, we note that the current TCP congestion control mechanisms are themselves not very effective in an environment where there is a limitation along the reverse path in pps. While the TCP mechanisms do provide an incentive to use large data packets, TCP does not include any effective congestion control mechanisms for the stream of small acknowledgement packets on the reverse path. Given the arguments above, it seems acceptable to us to assume a network limitation in Bps rather than in pps in considering the minimum sending rate of telephony traffic."
理想的な経路に沿ったボトルネックリンクがbps単位やPPSが制限されているかどうかを検出するために、及び制限がPPSである場合に適切に対応することができるトランスポートプロトコルを有することであろうが」、このような理想を達成することは困難です。私たちは、このような理想的が達成できるまでテレフォニートラフィックの輻輳制御の導入を遅らせたくないでしょう。また、我々は逆に沿って制限がある場合、現在のTCPの輻輳制御機構は、自身の環境では非常に効果的ではないことに注意してくださいPPSでパス。TCPメカニズムは、大きなデータパケットを使用するためのインセンティブを提供しないが、TCPは逆の経路上の小さな確認応答パケットのストリームのための任意の効果的な輻輳制御メカニズムが含まれていません。上記の引数を考えると、それはに私たちに許容できると思われますテレフォニートラフィックのレートを送信する最小を考慮にbps単位ではなく、PPSにネットワークの制限を前提としています。」
Translating the discussion in [RFC3714] to the congestion control mechanisms of TFRC, it seems acceptable to standardize a variant of TFRC that allows low-bandwidth flows sending small packets to achieve a rough fairness with TCP flows in terms of the sending rate in Bps, rather than in terms of the sending rate in pps. This is accomplished by TFRC-SP, a small modification to TFRC, as described below.
TFRCの輻輳制御メカニズムに[RFC3714]での議論を翻訳、それはTCPがbps単位送信率で流れると粗い公平性を達成するために小さなパケットを送信するフロー低帯域幅を可能にTFRCの変異体を標準化するために許容されると思われます、むしろ、PPSにおける送信レートの観点より。後述のようにこれは、TFRC-SP、TFRCに小さな修正することによって達成されます。
Maintaining incentives for large packets: Because the bottlenecks in the network in fact can include limitations in pps as well as in Bps, we pay special attention to the potential dangers of encouraging a large deployment of best-effort traffic in the Internet consisting entirely of small packets. This is discussed in more detail in Section 4.3. In addition, as again discussed in Section 4.3, TFRC-SP includes the limitation of the Min Interval between packets of 10 ms.
大きなパケットのためのインセンティブを維持する：実際には、ネットワークのボトルネックは、PPSならびにbps単位の制限を含めることができますので、我々は小さな完全に構成されるインターネットでのベストエフォートトラフィックの大規模な展開を奨励するの潜在的な危険性に特別な注意を払いますパケット。これは、4.3節で詳しく説明されています。また、として再び4.3節で説明し、TFRC-SPは、10ミリ秒のパケット間の最小間隔の制限を含みます。
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またはTCPコネクションが単一の大規模なパケットを送信したときにTFRC-SPの接続は、多くの小さなパケットを送信することができますので、TFRC-SPは、損失イベント率のTFRCの計算に変更する必要があります。これは、繰り返し高いパケット廃棄率に直面して往復時間ごとに複数のパケットを送信するために、標準TFRCまたはTCP接続のためには不可能です。その結果、TCPおよび標準TFRCは唯一のラウンドトリップ時間ごとに単一の損失イベントに応答し、まだ検出し、ますます重いパケットロス率に対応することができます。しかし、TCP接続は往復の時間あたり、平均して、一つの大きなパケットを送信することがあり、高度に混雑した環境で、対応するTFRC-SPの接続は、ラウンドトリップ時間あたりに多くの小さなパケットを送信することがあります。結果として、順序TCPとの公平性を維持するため、および混雑度の変化を検出することができるようにするために、TFRC-SPは、高輻輳の期間中、実際のパケットドロップ率に敏感である必要があります。これは、以下のセクションで詳しく説明されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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は、損失イベント率の関数、セグメントサイズ、および往復時間として秒当たりのバイト数で許容送信レートXを与える[RFC3448]のセクション3.1で与えられたTCPスループット方程式を使用します。 [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公称セグメントサイズ：1460バイトまでの公称セグメントサイズのデフォルト値。 [RFC3714]以下、このパケットあたりのアプリケーションデータの1460バイトとTCPフローと同じパケット損失率と、秒あたりのバイト数での送信速度の点で、公平性の目標を提供します。エンドポイントがパスのMTU（最大転送単位）と派生MSS（最大セグメントサイズ）未満である1460のバイトを知っている場合、エンドポイントは、MSSバイトに公称セグメントサイズSを設定する必要があります。エンドポイントが経路の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は、パケットヘッダのサイズを考慮に低減されます。これは、不必要に小さなパケットを使用しないように、分間隔を超えて、アプリケーションにいくつかのインセンティブを提供します。特に、我々は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 - データパケットタイプを使用し、いかなるIPまたはDCCPオプションが存在しないのIPv4、オーバーデータグラム輻輳制御プロトコル（DCCP）接続[RFC4340]は20 + 12 = 32バイトにHを設定することができました。 TFRC実装はIP層は、IPv6の代わりにIPv4を使用していることを知っている場合は、次にTFRC-SPを使用して接続はまだ実装を簡単にするためにH 40バイトのデフォルトの推定値の代わりに、60バイトの実際のサイズを使用することができます。
o Measuring the loss event rate in times of high loss: During short loss intervals (those at most two round-trip times), the loss rate is computed by counting the actual number of packets lost or marked, not by counting at most one loss event per loss interval. Without this change, TFRC-SP could send multiple packets per round-trip time even in the face of heavy congestion, for a steady-state behavior of multiple packets dropped each round-trip time.
高損失の時代に、損失イベント率を測定O：短い損失間隔（最大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は、1 / Nの損失イベント率に寄与し、N個のパケットとしてその損失間隔の大きさを算出します。損失間隔がK損失を含むN個のパケットから成る場合には、、TFRC-SPのために最大2つのラウンドトリップ時間の小さな損失間隔のために、損失の間隔の大きさは、損失事象に寄与する、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は、平均損失間隔の計算が二つ以上の往復時間は、その損失間隔の開始以来経過している場合にのみ、最新のロス間隔を含むことができ、制限が追加されます。
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は、RFC 3448（セクション5.4）でRFC 3448.に定義されてw_i対応する重みを用いて、最新の損失事象を含む間隔であると、値InにI_0とする、平均損失間隔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ミリ秒のパケット間の最小間隔を強制。この最小間隔を超え、そのトランスポート・プロトコルを望む流れはむしろTFRC-SPよりも、従来のTFRC方程式を使用しなければなりません。このための動機については後述します。
TFRC uses the TCP throughput equation given in [RFC3448], with the sending rate X in bytes per second as follows:
TFRCは、次のように秒あたりのバイト数で送信率Xと、[RFC3448]で与えられたTCPスループット方程式を使用します。
s
X = ------------------------------------------------------- ,
R*sqrt(2*p/3) + (4*R* (3*sqrt(3*p/8) * p * (1+32*p^2)))
where:
どこ：
s is the packet size in bytes;
Sバイトのパケットサイズです。
R is the round-trip time in seconds;
Rは、秒単位の往復時間です。
p is the loss event rate, between 0 and 1.0, of the number of loss events as a fraction of the number of packets transmitted.
pが送信されたパケットの数の分数として損失事象の数の0と1.0との間の損失イベント率、です。
This equation uses a retransmission timeout (RTO) of 4*R, and assumes that the TCP connection sends an acknowledgement for every data packet.
この式は、4 * Rの再送タイムアウト（RTO）を使用し、TCP接続は、すべてのデータパケットの確認応答を送信することを前提としています。
This equation essentially gives the response function for TCP as well as for standard TFRC (modulo TCP's range of sender algorithms for setting the RTO). As shown in Table 1 of [RFC3714], for high packet drop rates, this throughput equation gives rough fairness with the most aggressive possible current TCP: a SACK TCP flow using timestamps and Explicit Congestion Notification (ECN). Because it is not recommended for routers to use ECN-marking in highly-congested environments with high packet dropping/marking rates (Section 7 of [RFC3168]), we note that it would be useful to have a throughput equation with a somewhat more moderate sending rate for packet drop rates of 40% and above.
この式は、基本的にTCPのためだけでなく、標準TFRC（RTOを設定するための送信側アルゴリズムの剰余TCPの範囲）のために応答機能を提供します。 [RFC3714]の表1に示すように、高いパケット損失率のために、このスループット方程式は、最も積極的な可能現在のTCPとラフの公平性を与える：タイムスタンプと明示的輻輳通知（ECN）を使用してSACKのTCPフロー。それは、高いパケット廃棄/マーキング速度（[RFC3168]のセクション7）と高度に混雑した環境でECNマーキングを使用するには、ルータにはお勧めできませんので、我々は幾分緩やかなとスループット方程式を持つことが有用であろうことに注意してくださいパケットドロップ率40％以上のための送信レート。
The effective response function of TFRC-SP can be derived from the TFRC response function by using a segment size s of 1460 bytes, and using the loss event rate actually experienced by the TFRC-SP flow. In addition, for loss intervals of at most two round-trip times, the loss event rate for TFRC-SP is estimated by counting the actual number of lost or marked packets, rather than by counting loss events. In addition, the sending rate for TFRC-SP is constrained to be at most 100 packets per second.
TFRC-SPの有効な応答関数は、1460バイトのセグメントサイズSを用いて、実際にTFRC-SPフローによって経験損失イベント率を用いてTFRC応答関数から導出することができます。また、最大で2往復時間の損失間隔のために、TFRC-SPのための損失イベント率は、むしろ損失事象をカウントするよりも、紛失したり、マークされたパケットの実際の数を数えることによって推定されます。また、TFRC-SPのための送信速度は、毎秒最大で100のパケットに制限されています。
For an environment with a fixed packet drop rate p, regardless of packet size, the response functions of TCP, TFRC, and TFRC-SP are illustrated as follows, given in KBps (kilobytes per second), for a flow with a round-trip time of 100 ms:
次のように固定されたパケットドロップ率pを有する環境に関係なく、パケットサイズの、TCP、TFRC、およびTFRC-SPの応答関数は、ラウンドトリップと流れのために、（毎秒キロバイト）kbps単位で与えられ、図示されています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のための応答関数。パケット廃棄率の関数として、Kbpsの単位でレートを送信します。
<---------- TFRC-SP -------->
Packet 14-byte 536-byte 1460-byte
DropRate Segments Segments Segments
-------- -------- -------- --------
0.00001 5.40 57.60 150.00
0.00003 5.40 57.60 150.00
0.00010 5.40 57.60 150.00
0.00030 5.40 57.60 150.00
0.00100 5.40 57.60 150.00
0.00300 5.40 57.60 150.00
0.01000 5.40 57.60 150.00
0.03000 5.40 57.60 83.07
0.10000 5.40 26.58 26.58
0.20000 5.40 8.06 8.06
0.30000 2.93 2.93 2.93
0.40000 1.26 1.26 1.26
0.50000 0.63 0.63 0.63
Table 2: Response Function for TFRC-SP. Sending Rate in KBps, as a Function of Packet Drop Rate. Maximum Sending Rate of 100 Packets per Second.
表2：TFRC-SPのための応答関数。パケット廃棄率の関数として、Kbpsの単位でレートを送信します。毎秒100のパケットの最大送信レート。
The calculations for Tables 1 and 2 use the packet loss rate for an approximation for the loss event rate p. Scripts and graphs for the tables are available from [VOIPSIMS]. As the well-known TCP response function in Table 1 shows, the sending rate for TCP and standard TFRC varies linearly with segment size. The TFRC-SP response function shown in Table 2 reflects the maximum sending rate of a hundred packets per second; when not limited by this maximum sending rate, the TFRC-SP flow receives the same sending rate in KBps as the TCP flow with 1460-byte segments, given the same packet drop rate. Simulations showing the TCP, standard TFRC, and TFRC-SP sending rates in response to a configured packet drop rate are given in Tables 7, 8, and 9, and are consistent with the response functions shown here.
表1および表2の計算は、損失イベント率pの近似のためのパケット損失率を用います。テーブルのスクリプトおよびグラフは、[VOIPSIMS]から入手可能です。表1において、周知のTCP応答関数として、TCPと標準TFRCのための送信レートは、セグメントサイズとともに直線的に変化します。表2に示したTFRC-SP応答関数は、毎秒百パケットの最大送信速度を反映しています。この最大送信速度によって制限されない場合、TFRC-SPフローが同一のパケットドロップ率を考慮すると、1460バイトのセグメントを有するTCPフローとしてkbps単位で同じ送信レートを受信します。 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の単位でレートを送信します。毎秒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は、固定バイト降下率と、TFRC-SPのための送信速度に関係なくTCPセグメントサイズの、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単位負荷に負荷に支払わなければなりません。脇最小間隔から、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）= 160分の120の係数だけ低減されるためです。送信者が突然、40バイトのデータ・セグメントに切り替えた場合は、許可される送信レートは、アプリケーション・データの64 kbpsに減少するであろう。そして1バイトのデータ・セグメントを使用すると、アプリケーションデータの3.12 kbpsに許さ送信率を減少させるであろう。 （TFRC-SPを使用するアプリケーションは、毎秒100個の以上のパケットを送信することはできませんので、実際には、分間隔は、これらのレートを達成することから、送信者を防止するであろう。）
Unless it has a more precise estimate of the header size, TFRC-SP assumes 40 bytes for the header size, although the header could be larger (due to IP options, IPv6, IP tunnels, and the like) or smaller (due to header compression) on the wire. Requiring the use of the exact header size in bytes would require significant additional complexity, and would have little additional benefit. TFRC-SP's default assumption of a 40-byte header is sufficient to get a rough estimate of the throughput, and to give the application some incentive not to use an excessive amount of small packets. Because we are only aiming at rough fairness, and at a rough incentive for applications, the default use of a 40-byte header in the calculations of the header bandwidth is sufficient for both IPv4 and IPv6.
それはヘッダサイズのより正確な推定値を持っていない限り、ヘッダが原因ヘッダに（（IPv6のIPトンネル、等、によりIPオプションに）大きくても小さくすることができるが、TFRC-SPは、ヘッダサイズの40バイトを仮定しますワイヤ上の圧縮）。バイト単位の正確なヘッダサイズの使用を必要とする重要な追加の複雑さを必要とするであろう、少し追加の利点を有するであろう。 40バイトのヘッダのTFRC-SPのデフォルトの仮定は、スループットの概算を取得するには、アプリケーションに小さなパケットを過剰に使用することなく、いくつかのインセンティブを与えるのに十分です。我々は唯一のラフな公正を目指し、およびアプリケーションのためのラフなインセンティブにされているので、ヘッダの帯域幅の計算に40バイトのヘッダーのデフォルトの使用は、IPv4とIPv6の両方のために十分です。
The header size calculation provides an incentive for applications to use fewer, but larger, packets. Another incentive is that when the path limitation is in pps, the application using more small packets is likely to cause higher packet drop rates, and to have to reduce its sending rate accordingly. That is, if the congestion is in terms of pps, then the flow sending more pps will increase the packet drop rate, and have to adjust its sending rate accordingly. However, the increased congestion caused by the use of small packets in an environment limited by pps is experienced not only by the flow using the small packets, but by all of the competing traffic on that congested link. These incentives are therefore insufficient to provide sufficient protection for pps network limitations.
ヘッダサイズ計算アプリケーションは、より少ない、より大きなパケットを使用するためのインセンティブを提供します。別のインセンティブは、パスの制限がPPSであるときに、より多くの小さなパケットを使用して、アプリケーションが高いパケットのドロップ率を引き起こす可能性があり、それに応じて送信レートを減らすために持っているということです。輻輳がPPSの面である場合には、その後、複数のPPを送信するフローは、パケットのドロップ率を増加させ、それに応じて送信レートを調整する必要がありますされています。しかし、PPSによって制限された環境での小さなパケットを使用することによって引き起こされる増加輻輳が小さいパケットを使用して流れによって、それ混雑したリンク上の競合するトラフィックのすべてではないだけで経験されます。これらのインセンティブは、PPSのネットワークの制限のための十分な保護を提供することが不十分です。
TFRC-SP, then, includes a Min Interval of 10 ms. This provides additional restrictions on the amount of small packets used.
TFRC-SPは、その後、10ミリ秒の最小間隔を含みます。これは、使用される小型のパケットの量に追加の制限を提供します。
One practical justification for the Min Interval is that the applications that currently want to send small packets are the VoIP applications that send at most one packet every 10 ms, so this restriction does not affect current traffic. A second justification is that there is no pressing need for best-effort traffic in the current Internet to send small packets more frequently than once every 10 ms (rather than taking the 10 ms delay at the sender, and merging the two small packets into one larger one). This 10 ms delay for merging small packets is likely to be dominated by the network propagation, transmission, and queueing delays of best-effort traffic in the current Internet. As a result, our judgment would be that the benefit to the user of having less than 10 ms between packets is outweighed by the benefit to the network of avoiding an excessive amount of small packets.
分間隔のための一つの実用的な正当化は、現在、小さなパケットを送信するアプリケーションは、多くても1つのパケットに10ミリ秒ごとに送信VoIPアプリケーションなので、この制限は現在のトラフィックに影響を与えないことです。二正当化はより頻繁に何度も10ミリ秒ごとに（というよりも、送信側で10ミリ秒の遅延を服用を小さなパケットを送信するために現在のインターネットでのベストエフォート型トラフィックのための差し迫った必要性がないことである、と一つに二つの小さなパケットをマージします大きい方）。小さなパケットをマージするこの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接続のために可能ではありません。 1つまたは複数のパケットが、各ラウンドトリップ時間を落としているときTCPについては、送信レートはすぐに往復時間あたり未満つのパケットに落とされます。また、タホ、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は最高でも非常に混雑した環境では、損失イベント率ではなく、損失イベントが1つ以上のパケットがドロップされたか、データの窓からマークされているパケットのドロップ率を算出することで、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で、唯一の損失イベント率[WBL04]をカウントすることにより、TCPまたは標準TFRCとの公平性を達成することはできなくなりました。代わりに、ラウンドトリップ時間ごとに1つの大きなパケットを送信する、TFRC-SPは、（N、小さなパケットが一つの大きな1500バイトのパケットに等しい）N小さなパケットを送信することができます。 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と平均損失間隔I_meanは依然として8回の最新の損失間隔にわたって平均化され、損失間隔の長さがN / Kとして計算されるパケットを紛失したり、マーク8つの連続損失間隔はN個のパケットとK損失と短い損失間隔であれば、このようRFC 3448.のセクション5.4で指定されるように、損失イベント率はK / Nとしてではなく、1 / Nとして計算されます。
The guidelines in Section 3 above say that the nominal segment size s is set to 1460 bytes, providing a goal of fairness, in terms of the sending rate in bytes per second, with a TCP flow with 1460 bytes of application data per packet but with the same packet drop rate. This follows the assumption that a TCP flow with 1460-byte segments will have a higher sending rate than a TCP flow with smaller segments. While this assumption holds in an environment where the packet drop rate is independent of packet size, this assumption does not necessarily hold in an environment where larger packets are more likely to be dropped than are small packets.
上記第3のガイドラインは、公称セグメントサイズSはパケットごとアプリケーションデータの1460バイトとTCPフローではなくで、秒あたりのバイト数で送信速度の点で、公平性の目標を提供し、1460バイトに設定されていることを言います同じパケットドロップ率。これは、1460バイトのセグメントを持つTCPフローが小さなセグメントでのTCPフローよりも高い送信レートを持っていることを前提に従います。この仮定は、パケットのドロップ率は、パケットサイズとは独立した環境で保持している間、この仮定は必ずしも大きなパケットを小さなパケットよりも廃棄される可能性が高い環境では成り立ちません。
The table below shows the results of simulations with standard (SACK) TCP flows, where, for each *byte*, the packet containing that byte is dropped with probability p. Consider the approximation for the TCP response function for packet drop rates up to 10% or so; for these environments, the sending rate in bytes per RTT is roughly 1.2 s/sqrt(p), for a packet size of s bytes and packet drop rate p.
以下の表は、各*バイト*ため、そのバイトを含むパケットは確率pでドロップされる標準（SACK）、TCPフローとシミュレーションの結果を示します。パケットドロップ率最大10％かそこらのためのTCP応答関数の近似を考えてみましょう。これらの環境のために、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パケットのサイズを考えると、パケットドロップ率が概ね1.2 SQRT（S）/ SQRT（P1）のRTTあたりのバイトで送信レートを製造する、おおよそのS * P1のです。このように、固定されたバイトのドロップ率と環境におけるTCPのために、送信率は10％程度までのパケットドロップ率のために、SQRT（S）とほぼ成長しなければなりません。
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送信速度は、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：バイト廃棄率0.0001：TCPの中央値は、パケットサイズI対レートを送ります
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は、16％のパケット損失レートに対応する、128バイトのパケットサイズにパケットサイズアップの増大に伴って成長します。 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：バイト廃棄率0.001：TCPの中央値は、パケットサイズII対レートを送ります
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の挙動は、代わりに1500バイトのパケットを使用してTCPフローと秒あたりのバイト数で同じ送信レートを達成TFRC-SPフローの目標のために、それは検討するより理にかなっていることを示唆していますパケットサイズが最も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]).
この文書では、パケットの断片化およびパス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.
TFRC-SPは、TCP MSSは、実際には唯一536バイトであるパス上の1460バイトの公称セグメントサイズSと共に使用される場合、TFRC-SPの流れはそのように、秒あたりのバイト数で、ほぼ3倍の帯域幅を受信することができます536バイトのMSSを使用してTCPフロー。同様に、4000バイトのMSSの近傍の環境では、TCPフローは、1460バイトの公称セグメントサイズSとTFRC-SP流のほぼ3倍の帯域幅を受け取ることができます。どちらの場合も、我々は、2つまたは3つの要素を持つ「不公平」のこれらのレベルは許容可能であることを感じます。特に、彼らは一つのフローが競合するTCPまたはTFRC-SPの流れを排除して、利用可能な帯域幅のすべてをつかむにはなりません。
All IPv4 *end hosts* are required to accept and reassemble IP packets of size 576 bytes [RFC791], but IPv4 *links* do not necessarily have to support this packet size. In slow networks, the largest possible packet may take a considerable amount of time to send [RFC3819], and a smaller MTU may be desirable, e.g., hundreds of bytes. If the first-hop link had a small MTU, then TCP would choose an appropriately small MSS [RFC879]. [RFC1144] quotes cases of very low link speeds where the MSS may be tens of bytes (and notes this is an extreme case). We note that if TFRC-SP is used over a path with an MTU considerably smaller than 576 bytes, and the TFRC-SP flow uses a nominal segment size s of 1460 bytes, then the TFRC-SP flow could receive considerably more than three times the bandwidth of competing TCP flows.
すべてのIPv4 *エンドホストは、576のバイトは[RFC791]が、IPv4のは*リンク*は必ずしもこのパケットサイズをサポートする必要はありませんサイズのIPパケットを受け入れ、再組み立てする必要があります*。遅いネットワークでは、最大可能パケットは[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は、パスMTUのいくつかの知識を維持していないトランスポートプロトコルでの使用は推奨されません。
For a TFRC-SP receiver, the guidelines from Section 6 of RFC 3448 govern when the receiver should send feedback messages. In particular, from [RFC3448], "a feedback packet should ... be sent whenever a new loss event is detected without waiting for the end of an RTT". In addition, feedback packets are sent at least once per RTT.
TFRC-SPの受信機については、RFC 3448のセクション6からのガイドラインでは、受信機がフィードバックメッセージを送信する必要があるときに支配します。具体的には、[RFC3448]から、「新たな損失事象が検出されるたびにフィードバックパケットは... RTTの終了を待たずに送信されなければなりません」。また、フィードバックパケットは、RTTごとに少なくとも一度送信されます。
For a TFRC-SP connection with a short current loss interval (less than two round-trip times), it is possible for the loss interval length calculated for that loss interval to change in odd ways as additional packet losses in that loss interval are detected. To prevent unnecessary oscillations in the average loss interval, Section 3 specifies that the current loss interval can be included in the calculation of the average loss interval only if the current loss interval is longer than two round-trip times.
その損失間隔における追加のパケット損失が検出されるように短絡電流損失間隔（2つ未満のラウンドトリップ時間）とTFRC-SPの接続のために、それが奇数の方法で変更すること損失間隔について計算損失インターバルの長さが可能です。平均損失区間内の不要な振動を防止するためには、第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%.
固定された送信レートに許可パケットドロップ率を決定する際に、RFC 3714は、IPテレフォニーフローはその同じパケットドロップ率を経験し1500バイトのパケットのTCPフローとして秒あたりのバイト数で同じ送信レートを使用することを許可されるべきであることを前提としていIPテレフォニーの流れ。一例として、このガイドライン以下、0.1秒の往復時間との64Kbpsの最小送信速度とVoIP接続を終了または永続的なパケットドロップ率が有意に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のための一つの可能な使用は、秒あたりのパケット内の固定の送信レートを維持するアプリケーションであってもよいが、混雑に応じて、そのパケットのサイズを変更します。 TFRC-SPは、接続のパケット廃棄率を監視し、秒あたりのバイト数で許容送信レートを決定します。秒あたりのパケットに固定された送信レートでアプリケーションを考えると、TFRC-SPの送信者は、秒あたりのバイト数で送信レートが許容送信レートを超えないために必要とされるデータ・パケットのサイズを決定することができます。パケットドロップレートは、パケットサイズに影響される環境では、パケットサイズを小さくすると、フローが経験するパケットドロップ率の減少をもたらす可能性があります。
There are many questions about how an adaptive application would use TFRC-SP that are beyond the scope of this document. In particular, an application might wish to avoid unnecessary reductions in the packet size. In this case, an application might wait for some period of time before reducing the packet size, to avoid an unnecessary reduction in the packet size. The details of how long an application might wait before reducing the packet size can be addressed in documents that are more application-specific.
適応アプリケーションは、このドキュメントの範囲を超えていTFRC-SPを使用する方法について多くの質問があります。具体的には、アプリケーションはパケットサイズで、不要な削減を避けたいかもしれません。この場合、アプリケーションはパケットサイズでの不必要な低下を回避するために、パケットサイズを縮小する前に、ある程度の期間を待つかもしれません。アプリケーションは、パケットサイズを縮小する前に待つかもしれませんどのくらいの詳細は、よりアプリケーション固有のドキュメントで対処することができます。
Similarly, an application using TFRC-SP might only have a few packet sizes that it is able to use. In this case, the application might not reduce the packet size until the current packet drop rate has significantly exceeded the packet drop rate threshold for the current sending rate, to avoid unnecessary oscillations between two packet sizes and two sending rates. Again, the details will have to be addressed in documents that are more application-specific.
同様に、TFRC-SPを使用するアプリケーションは、使用することができ、いくつかのパケットサイズを持っているかもしれません。現在のパケットのドロップ率が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で許可され、送信レートは秒あたりのバイト数ではなく、秒あたりのパケットであるため、アプリケーションは「ゲーム」システムにするためにパケットサイズを操作するために少し機会があります。これは、許容送信レートが毎秒パケットである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-SPが過度に積極的である一方、標準TFRCは、小さなパケットが良好なパフォーマンスを受け取ることができますフロー環境を探ります。
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小さなパケットは大きなパケットよりもドロップされにくいシナリオはバイト単位で、バイトモード（付録B.3、B.4）においてAQMメカニズムとドロップテールキューを有するものが含まれます。また、より大きなパケットがはるかに高いエラー率、ひいては高いドロップ確率[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は、大パケットのTCPとラフの公平性は、各パケットが略同一の確率を受信するシナリオでは、BPSに送信速度で流れる有するように流れるためTFRC-SPの目標であります削除されています。大きなパケットは、小さなパケットよりもドロップされる可能性がより高い、又はここでバースト送信速度で流れるパケットを有する可能性が高いシナリオで滑らかな送信レートのフローがよりも落とし、小さなパケット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ミリ秒の往復時間と128 Kbpsでのパケットヘッダと最大送信率を有するTFRC-SPフローが当たり2.2パケットを送信1460-バイトセグメントを有するTCPフローへの第2の当量あたりのバイトで送信レートを有するであろうラウンドトリップ時間。 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アルゴリズム（例えば、SACKか否か）、最小RTO限定送信（またはその欠如）、ECNの使用の使用、等によって影響されます。公平性を探索シミュレーションや実験は、現在の規格に準拠した最も積極的なTCPメカニズムとの公平性の探査が含まれていることを確実にするために良いです。私たちのシミュレーションは限定送信とし、200ミリ秒の最小RTOとSACK TCPを使用しています。シミュレーション結果はとか、タイムスタンプなしの大部分は同じです。タイムスタンプは、この論文で報告されたシミュレーションのために使用されませんでした。付録B.1で説明したように、私たちの期待は高いパケットドロップ体制で、ルータはポリシーからか、のいずれかから、マークパケットではなく、ドロップすることで、ので、私たちは、TFRCのレートを送信するターゲットを設定する際にECNでTCPを使用していませんでしたバッファオーバーフロー。
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バイトの代わりとすることができますデフォルト小さい10バイトのデータセグメントを持つアプリケーションについて第3の仮定40バイト、これは実際のパケットサイズが許可を計算する代わりにTFRC-SPによって想定さ50バイト、70、90、または110バイトであることを意味します送信レート。したがって、大きなヘッダをTFRC-SPのアプリケーションは、小さなヘッダをTFRC-SPアプリケーションより（ヘッダによって使用される帯域幅を含む）倍以上の帯域幅を受け取ることができます。私たちは、これが問題になることを期待しないでください。特に、大規模なヘッダを持つTFRC-SPアプリケーションが大幅に競合するTCPアプリケーションの、または小さなヘッダと競合するTFRC-SPアプリケーションのパフォーマンスが低下することはありません。
General issues for TFRC: The congestion control mechanisms in TFRC and TFRC-SP limit a flow's sending rate in packets per second. Simulations by Tom Phelan [P04] explore how such a limitation in sending rate can lead to unfairness for the TFRC flow in some scenarios, e.g., when competing with bursty TCP web traffic, in scenarios with low levels of statistical multiplexing at the congested link.
TFRCのための一般的な問題：TFRCの輻輳制御メカニズムとTFRC-SPリミット秒あたりのパケットのフローの送信レート。トム・フェラン[P04]によるシミュレーションは送信レートで、そのような制限は、いくつかのシナリオではTFRCフローのために不公平につながることができますか探検、例えば、混雑したリンクで、統計的多重化のレベルが低いシナリオでは、バースト的なTCPのWebトラフィックと競合する場合。
There are no new security considerations introduced in this document.
このドキュメントで紹介し新たなセキュリティ上の考慮事項はありません。
The issues of the fairness of TFRC-SP with standard TFRC and TCP in a range of environments, including those with byte-based queue management at the congested routers, are discussed extensively in the main body of this document.
混雑ルータのバイトベースのキュー管理を持つものも含めた環境の範囲で標準TFRCと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
TFRCのための一般的なセキュリティ上の考慮事項は、RFC 3448にTFRCと同様にRFC 3448.で議論されている、TFRC-SPは、それ自体でトランスポートプロトコルが、トランスポートプロトコルと組み合わせて使用することを意図している輻輳制御機構ではありません。したがって、セキュリティは、主に特定のトランスポートプロトコルと、その認証メカニズムの文脈において考慮される必要があります。 RFC 3448にTFRCために論じたように、TFRC-SPを使用する任意の転送プロトコルは、スプーフィングされたフィードバックから保護するため、および受信機から誤った情報に対して輻輳制御機構を保護する必要があります。再び、RFC 3448にTFRCのために説明したように、我々はTFRC-SPとECNを取り入れたプロトコルがマークされたパケットの偶発的または悪質な隠蔽から送信者を保護するためにECNナンス[RFC3540]を使用することを期待します
Security considerations for DCCP's Congestion Control ID 3, TFRC Congestion Control, the transport protocol that uses TFRC, are discussed in [RFC4342]. That document extensively discussed the mechanisms the sender can use to verify the information sent by the receiver, including the use of the ECN nonce.
DCCPの輻輳制御ID 3のセキュリティ上の考慮事項は、TFRC輻輳制御、TFRCを使用するトランスポートプロトコルは、[RFC4342]で議論されています。その文書は、広範囲送信者がECNナンスの使用を含む、受信機によって送信された情報を、確認するために使用できるメカニズムを議論しました。
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）の変異体を、指定したが、それは経験してTCP接続とBPSで同じ送信レートを望みます同じパケットレートを落とすが、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.
データグラム輻輳制御プロトコル（DCCP）におけるTFRC-SPとの実験を可能にするために、実験的な輻輳制御識別子（CCID）をTFRC-SPに基づいて、使用されるが、別の文書で指定されました。
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.
私たちは、TFRC-SPの議論をし、TCPとTFRC-SPフロー間の公平性を探求する彼の論文のためのトム・フェランに感謝します。私たちは、この文書の以前のバージョンへのフィードバックのためにラースエッゲルト、Gorry Fairhurst、マーク・ハンドリー、ミゲル・ガルシア、ラダンGharai、リチャード・ネルソン、コリンパーキンス、ユルゲンQuittek、ピートSholander、マグヌスウェスター、そしてイェルクウィドマーに感謝します。また、フィードバックや議論のためにDCCPワーキンググループに感謝します。
Appendix A. Related Work on Small-Packet Variants of TFRC
TFRCの小パケットバリアントの付録A.関連作品
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向け式にパス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.
【WBL04】また、単にTFRC式における基準TCPフローのパケットサイズを使用して、可変パケットサイズのためのTFRCを適応する高パケット損失領域で十分ではないであろうと主張しています。単一ラウンドトリップ時間内に複数の失われたパケットは、単一パケット損失に集約されることになるので、このような修飾されたTFRCは、より小さいパケットに有利に強いバイアスを有するであろう。 【WBL04]より小さいパケットに有利なバイアスを考慮して損失測定プロセスを変更することを提案しています。
The TFRC-SP variant of TFRC proposed in our document differs from [WBL04] in restricting its attention to flows that send at most 100 packets per second. The TFRC-SP variant proposed in our document also differs from the straw proposal discussed in [WBL04] in that the allowed bandwidth includes the bandwidth used by packet headers.
私たちの文書で提案されたTFRCのTFRC-SP変異体は、毎秒最大で100個のパケットを送信するフローへの注意を制限するには、[WBL04]とは異なります。我々の文書で提案された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「仮想パケット」、「ランダム・サンプリング」、および「損失不感期間（LIP）スケーリング」、「バイアス化」、損失測定処理を修正するための4つの方法を論じています。ネットワークは、独立して、パケットサイズのパケットをドロップしたときに[WBL04]のみ第二及び第三の方法は十分にロバスト認めます。ネットワークが小さいパケットより大きなパケットをドロップする可能性が高いとき、彼らは唯一の第二の方法は、十分に強固見つけます。そのランダム化を使用しない以外は、損失イベント率を計算するための我々の方法は、[WBL04]で提案されているランダムサンプリング法に多少似ています。代わりに、ランダム化、正確なパケットロス率は、短い損失間隔で計算され、そして標準の損失イベント率の計算はより長い損失間隔のために使用されます。 【WBL04】ベルヌーイ損失モデル、経時的に変化するドロップ率、およびギルバート損失モデル、ならびにTCPおよびTFRC流れの範囲がより現実的なシミュレーションとベルヌーイ損失モデルとシミュレーションを含みます。
[WBL04] produces both a byte-mode and a packet-mode variant of the TFRC transport protocol, for connections over paths with per-byte and per-packet dropping respectively. We would argue that in the absence of transport-level mechanisms for determining whether the packet dropping in the network is per-packet, per-byte, or somewhere in between, a single TFRC implementation is needed, independently of the 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.
重要な貢献は、パケットサイズの関数としてパケット廃棄の面で、今日のネットワークに実際に存在する行動の範囲を調査することです。
Appendix B. Simulation Results
付録B.シミュレーション結果
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で概説したシミュレーション結果についてこの付録レポートは、ディレクトリTCL /テストで「./test-all-friendly」NSシミュレータに追加された、および検証テストに例示されています。この文書に記載されているシミュレーションのためのシミュレーションスクリプトやグラフは、[VOIPSIMS]でご利用いただけます。
B.1. Simulations with Configured Packet Drop Rates
B.1。構成されたパケットドロップ率のシミュレーション
In this section we describe simulation results from simulations comparing the throughput of standard (SACK) TCP flows, TCP flows with timestamps and ECN, TFRC-SP flows, and standard TFRC (Stnd TFRC) flows. In these simulations we configure the router to randomly drop or mark packets at a specified rate, independently of the packet size. For each specified packet drop rate, we give a flow's average sending rate in Kbps over the second half of a 100-second simulation, averaged over ten flows.
この節では、標準（SACK）、TCPフローのスループットを比較するシミュレーションからのシミュレーション結果を説明し、TCPタイムスタンプとECN、TFRC-SPフローに流れ、標準TFRC（STND TFRC）が流れます。これらのシミュレーションでは、ランダムに独立してパケットサイズの指定速度でパケットを破棄またはマークするようにルータを設定します。指定された各パケットのドロップ率については、我々は、100秒のシミュレーションの第二の半分以上はKbps単位でのフローの平均送信レートを与える10個のフローで平均化。
Packet Send Rates (Kbps, 1460B seg)
DropRate TCP ECN TCP TFRC
-------- -------- -------- --------
0.001 2020.85 1904.61 982.09
0.005 811.10 792.11 878.08
0.01 515.45 533.19 598.90
0.02 362.93 382.67 431.41
0.04 250.06 252.64 284.82
0.05 204.48 218.16 268.51
0.1 143.30 148.41 146.03
0.2 78.65 93.23* 55.14
0.3 26.26 59.65* 32.87
0.4 9.87 47.79* 25.45
0.5 3.53 32.01* 18.52
* 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.
ルータがパケットドロップ/マーク率が20％以上である場合にパケットをマークすることは推奨されていないとしてアスタリスク* ECNのシナリオは、現実的ではありません。
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は、両方のフローは、両方のフローが同じを使用する場合、TCPとTFRCの相対的な公平性を示すために、1460-バイトのデータセグメントを有する場合、TCPおよび構成されたパケット損失率の範囲について標準TFRCフローの送信レートを示しますパケットサイズ。例えば、0.1のパケットドロップ率は、TCPおよびTFRCパケットの10％が廃棄されることを意味します。 TFRCフローは、毎秒最大100個のパケットを送信するように設定されています。 TFRCフローが標準TCPフローよりも3〜5倍以上の帯域幅を受信したときに、パケットのドロップ率は、40〜50％に達するまでの良好な相対的な公平性があります。私たちは、ECNマーキングがまだ代わりに、パケットのドロップを使用していた場合にはECN TCPフローは、これらの高いパケットドロップ率でTFRCフローよりも高いスループットを受け取ることになることに注意してください。ルータがお勧めしますしかし、我々は、輻輳（の第7節の高レベル時にパケットをドロップするのではなくマークする、TFRCのレートを送信対象として、これらの高パケットドロップのシナリオでECN TCP送信レートを使用していない[RFC3168] ）。加えて、それらを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.
ルータがパケットドロップ/マーク率が20％以上である場合にパケットをマークすることは推奨されていないとしてアスタリスク* ECNのシナリオは、現実的ではありません。
Table 8: Send Rate vs. Packet Drop Rate II:
14B TFRC Segments
(5.6 Kbps Maximum TFRC Data Sending Rate)
Table 8 shows the results of simulations where each TFRC-SP flow has a maximum data sending rate of 5.6 Kbps, with 14-byte data packets and a 32-byte packet header for DCCP and IP. Each TCP flow has a receive window of 100 packets and a data packet size of 1460 bytes, with a 40-byte packet header for TCP and IP. The TCP flow uses SACK TCP with Limited Transmit, but without timestamps or ECN. Each flow has a round-trip time of 240 ms in the absence of queueing delay.
表8は、各TFRC-SPフローは14バイトのデータ・パケットとDCCPおよびIPの32バイトのパケットヘッダと、5.6 Kbpsの速度を最大送信データを有しているシミュレーションの結果を示します。各TCPフローは、TCPおよびIPのための40バイトのパケットヘッダとパケット100の受信ウィンドウと1460バイトのデータ・パケットのサイズを有しています。 TCPフローは限定送信してSACK TCPを使用していますが、タイムスタンプやECNなし。各フローはキューイング遅延のない状態で240ミリ秒の往復時間を持っています。
The TFRC sending rate in Table 8 is the sending rate for the 14-byte data packet with the 32-byte packet header. Thus, only 30% of the TFRC sending rate is for data, and with a packet drop rate of p, only a fraction 1-p of that data makes it to the receiver. Thus, the TFRC data receive rate can be considerably less than the TFRC sending rate in the table. Because TCP uses large packets, 97% of the TCP sending rate is for data, and the same fraction 1-p of that data makes it to the receiver.
表8中のTFRC送信レートは、32バイトのパケットヘッダと14バイトのデータパケットの送信レートです。したがって、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.
表8は、パケットドロップ率が20％以上になるまで所望のようTFRC-SPと、5.6 Kbpsのデータストリームは、その送信レートを低下させないことを示しています。 50％のパケット損失レートTFRC-SPフローの送信レートのためながら30〜40％のパケット損失率と、TFRC-SPフローの送信レートは、平均的な大パケットのTCPフローのものより幾分小さいです平均大パケットTCPフローのそれよりもやや大きいです。
< - - - - - - Send Rates (Kbps) - - - - - >
Packet TCP ECN TCP TFRC-SP Stnd TFRC
DropRate (1460B seg) (1460B seg) (200B seg) (200B seg)
-------- ----------- ----------- ---------- ----------
0.001 1908.98 1869.24 183.45 178.35
0.005 854.69 835.10 185.06 138.06
0.01 564.10 531.10 185.33 92.43
0.02 365.38 369.10 185.57 62.18
0.04 220.80 257.81 185.14 45.43
0.05 208.97 219.41 180.08 39.44
0.1 141.67 143.88 127.33 21.96
0.2 62.66 91.87* 54.66 9.40
0.3 16.63 65.52* 24.50 4.73
0.4 6.62 42.00* 13.47 3.35
0.5 1.01 21.34* 10.51 2.92
* 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.
ルータがパケットドロップ/マーク率が20％以上である場合にパケットをマークすることは推奨されていないとしてアスタリスク* ECNのシナリオは、現実的ではありません。
Table 9: Sending Rate vs. Packet Drop Rate III:
200B TFRC Segments
(160 Kbps Maximum TFRC Data Sending Rate)
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フローは160 Kbpsの速度を最大送信データと、200バイトのデータパケットを使用して構成されたパケットドロップ率の結果。 30％までのパケットドロップ率について所望されるようTFRC-SPの性能は、本質的であるが、表8のように、標準TFRCの性能は、非常に貧弱です。再び予想通り、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接続のために示した送信レートに類似しています。
B.2. Simulations with Configured Byte Drop Rates
B.2。設定済みバイトドロップ率のシミュレーション
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.
ルータがパケットドロップ/マーク率が20％以上である場合にパケットをマークすることは推奨されていないとしてアスタリスク* ECNのシナリオは、現実的ではありません。
TFRC's maximum data sending rate is 5.6 Kbps.
TFRCの最大データ送信レートは5.6 Kbpsです。
Table 10: Sending Rate vs. Byte Drop Rate
表10：バイト廃棄率対送信レート
Table 10 shows the TCP and TFRC send rates for various byte drop rates. For each byte drop rate, Table 10 shows the TCP sending rate, with and without ECN, for the TCP segment size that gives the highest TCP sending rate. Simulations were run with TCP segments of 14, 128, 256, 512, and 1460 bytes. Thus, for a byte drop rate of 0.00001, the table shows the TCP sending rate with 1460-byte data segments, but with a byte drop rate of 0.001, the table shows the TCP sending rate with 128-byte data segments. For each byte drop rate, Table 10 also shows the TFRC-SP and Standard TFRC sending rates. With configured byte drop rates, TFRC-SP gives an unfair advantage to the TFRC-SP flow, while Standard TFRC gives essentially the desired performance.
表10は、TCPを示し、TFRCは、様々なバイトのドロップ率のために金利を送ります。各バイト降下率のために、表10は、TCPが最高TCP送信レートを与えるTCPセグメントサイズのために、ととECNことなく、速度を送信示します。シミュレーションは、14、128、256、512、および1460バイトのTCPセグメントを使用して実行しました。したがって、0.00001のバイト降下率のために、テーブル1460バイトのデータセグメントと速度を送信するTCPを示しているが、0.001のバイト低下率と、テーブルは、128バイトのデータセグメントとTCP送信速度を示しています。各バイト降下率のために、表10はまた、TFRC-SP標準およびTFRC送信レートを示します。標準TFRCは、本質的に所望の性能を提供しながら、構成バイト降下率と、TFRC-SPは、TFRC-SPフローに不公平な利点を与えます。
TCP Pkt TFRC Pkt
Byte DropRate DropRate TCP/TFRC
DropRate (1460B seg) (14B seg) Pkt Drop Ratio
-------- ----------- --------- --------------
0.00001 0.015 0.0006 26.59
0.0001 0.13 0.0056 24.94
0.001 0.77 0.054 14.26
0.005 0.99 0.24 4.08
0.01 1.00 0.43 2.32
0.05 1.00 0.94 1.05
Table 11: Packet Drop Rate Ratio vs. Byte Drop Rate
表11：バイト廃棄率対パケット廃棄率比
Table 11 converts the byte drop rate p to packet drop rates for the TCP and TFRC packets, where the packet drop rate for an N-byte packet is 1-(1-p)^N. Thus, a byte drop rate of 0.001, with each byte being dropped with probability 0.001, converts to a packet drop rate of 0.77, or 77%, for the 1500-byte TCP packets, and a packet drop rate of 0.054, or 5.4%, for the 56-byte TFRC packets.
表11は、Nバイトのパケットのためのパケットドロップ率は、1-（1-P）^ Nであり、TCPおよびTFRCのパケットのドロップ率をパケットするバイト降下率pを変換します。従って、各バイトと0.001のバイト低下率は、確率0.001でドロップされ、1500バイトのTCPパケットに対して、0.77、または77％のパケット損失レートに変換し、パケットドロップ0.054の割合、又は5.4％ 、56バイトのTFRCパケットの。
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パケットドロップ率との比を示しています。下位バイトのドロップ率に関しては、この比率はTCPとTFRCのパケットサイズとの比率は、26.8に近いです。最も小さなTFRCパケットが廃棄される可能性が高い上位バイトのドロップ率については、このドロップ率は、TCP接続でかなり競争、標準TFRC送信レートは、最適に近いバイトのドロップ率を、表10が示すように1に近づきます許可された範囲内で最適なパケットサイズを使用。これとは対照的に、TFRC-SPの接続は、それが（TFRC-SPの*パケットに対応する0.01以上のバイトドロップ率のためにその送信レートを下げるんが* 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バイトのセグメントを有するものであり、TCP送信レートは、パケット損失率pのために、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セグメントサイズは、パケットドロップ率p 1 / SQRT（P）によって制御レジーム速度の送信にTCPコネクションを維持、15％以下でのパケットドロップ率を維持一つであると思われます。 （ヘッダを含む）SバイトのTCPパケットサイズ、及び*バイト* Bの落下速度のために、パケットドロップ率は、おおよそのB * Sです。この領域内の指定されたバイトのドロップ率については、最適なTCPの性能は、その後、再送信タイマーの指数バックオフの制度のうち、TCP接続を維持する、最大15％のパケット廃棄率を与えるように選択パケットサイズで発生した場合これは、B * S = 0.15、又はS = 0.15 / Bを必要とします。
In the high-congestion regime of Table 10, with high congestion and with byte drop rates of 0.01 and higher, the TCP performance is dominated by the exponential backoff of the retransmit timer regardless of the segment size. Even a 40-byte packet with a zero-byte data segment would have a packet drop rate of at least 33%. In this regime, the optimal TCP *sending* rate comes with a large, 1460-byte data segment, but the TCP sending rate is low with any segment size, considerably less than one packet per round-trip time.
表10の高輻輳領域で、高い混雑で0.01と高いのバイト降下率で、TCP性能は関係なく、セグメントサイズの再送タイマーの指数バックオフによって支配されます。 0バイトのデータセグメントと偶数40バイトのパケットは、少なくとも33％のパケットドロップ率を有するであろう。この制度では、*率を送信して、最適なTCP *は大、1460バイトのデータセグメントが付属していますが、TCP送信レートは、ラウンドトリップ時間あたり1つのパケットよりもかなり少なく、任意のセグメントサイズと小さいです。
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を与えながら、この政権では、小さいパケットはより良い*グッドプット*率を与えることに注意してください。
In general, Tables 8 and 9 show good performance for TFRC-SP in environments with stable packet drop rates, where the decision to drop a packet is independent of the packet size. However, in some environments the packet size might affect the likelihood that a packet is dropped. For example, with heavy congestion and a Drop Tail queue with a fixed number of bytes rather than a fixed number of packet-sized buffers, small packets might be more likely than large packets to find room at the end of an almost-full queue. As a further complication, in a scenario with Active Queue Management, the AQM mechanism could either be in packet mode, dropping each packet with equal probability, or in byte mode, dropping each byte with equal probability. Sections B.3 and B.4 show simulations with packets dropped at Drop-Tail or AQM queues, rather that from a probabilistic process.
一般に、表8および9は、パケットをドロップする決定は、パケットサイズとは無関係である安定したパケットドロップレート、ある環境におけるTFRC-SPのための良好な性能を示します。ただし、一部の環境では、パケットのサイズは、パケットが廃棄される可能性に影響する可能性があります。例えば、混雑やバイトの固定数でドロップテイルキューではなく、パケット・サイズのバッファの固定数で、小さなパケットは、ほぼフルキューの最後に部屋を見つけることが大きなパケットよりも可能性が高いかもしれません。さらに合併症として、アクティブキュー管理とシナリオにおいて、AQM機構のいずれか等しい確率で各パケットを落とす、またはバイトモードでは、等しい確率で各バイトを落とし、パケットモードであってもよいです。パケットとセクションB.3とB.4ショーのシミュレーションは、確率過程からそのむしろ、ドロップテールまたはAQMキューでドロップ。
B.3. Packet Dropping Behavior at Routers with Drop-Tail Queues
B.3。ドロップテールキューを持つルータでのパケット廃棄動作
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つのフローのスループットを比較の問題の一つは、パケット・サイズ自体は、パケットドロップレート[V00、WBL04]に影響を与えることができるということです。
The default TFRC was designed for rough fairness with TCP, for TFRC and TCP flows with the same packet size and experiencing the same packet drop rate. When the issue of fairness between flows with different packets sizes is addressed, it matters whether the packet drop rates experienced by the flows is related to the packet size. That is, are small packets just as likely to be dropped as large TCP packets, or are the smaller packets less likely to be dropped [WBL04]? And what is the relationship between the packet-dropping behavior of the path, and the loss event measurements of TFRC?
TFRCとTCPは、同じパケットサイズと同じパケットドロップ率を経験してフローのデフォルトTFRCは、TCPとラフ公正のために設計されました。異なるパケットサイズのフロー間の公平性の問題が解決されると、流れが経験したパケット廃棄率はパケットサイズに関連しているかどうか問題になります。つまり、小さなパケットは、大きなTCPパケットとして廃棄されるだけのように思われる、または小さなパケットは[WBL04]廃棄される可能性が低いですか？そして、パスのパケットドロップ動作、およびTFRCの損失事象の測定値の間の関係は何ですか？
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.04 316.18 0.05 183.05
25 0.07 227.47 0.07 181.23
50 0.08 181.10 0.08 178.32
100 0.14 85.97 0.12 151.42
200 0.17 61.20 0.14 73.88
400 0.20 27.79 0.18 36.81
800 0.29 3.50 0.27 16.33
1600 0.37 0.63 0.33 6.29
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接続とリンクを共有する3 Mbpsの持つトポロジでWebトラフィックと競合5 TFRC-SP接続で、100秒のシミュレーションの後半の結果を示しています。 TFRC-SPアプリケーションが160 Kbpsでの最大データレートのために、10ms毎に200バイトのデータパケットを生成します。 5長命TCP接続は、1460バイトのデータ・パケット・サイズを使用して、Webトラフィックは、512バイトのデータ・パケット・サイズを使用しています。 5つのTCPコネクションは、40〜240ミリ秒から往復時間を持ち、5つのTFRC接続は、往復時間の同じセットを持っています。これらのシミュレーションでSACK TCP接続はリミテッドの送信、および200ミリ秒の最小RTOと、NSシミュレータでのデフォルトパラメータを使用します。 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つのフローにわたって平均しました。予想されるようにTCPフローとしてTFRC-SPフローはTCPが25％以上のパケットドロップレートで流れるよりも高いスループットを受信するものの、TFRC-SPフローは、同様のパケットドロップ率を参照します。
< - - - - - 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シミュレータはまだキューがバッファの固定数を持って、より現実的な中間モデルを、持っていない、各バッファは、バイトの固定数があり、各パケットは、一つ以上の空きバッファが必要となります。大きなパケットは複数のバッファを必要とする一方、このモデルでは、小さなパケットは、一つのバッファを使用します。
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の接続は、各TFRC-SPアプリケーションが160 Kbpsでの最大データレートのために、10ms毎に200バイトのデータパケットを生成して、リンクを共有し3 MbpsのとトポロジでWebトラフィックと競合します。 Webセッションの数は、混雑の異なるレベルを作成するために変更されます。しかし、代わりに最も百パケットに対応することができるドロップテールキューの、ルータのドロップテールキューは、それぞれ（500バイトの平均パケットサイズ百パケットの時間としてNSで計算）最も50,000バイトに対応することができます。
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.
表13が示すように、バイト単位のドロップテールキューと、TFRC-SPフローは、TCPフローよりもはるかに小さいパケットドロップ率を見て、そして結果は、はるかに大きな送信速度を受信します。長命TCPフローは1460バイトのデータ・セグメントを使用しながら、表13のシミュレーションのために、TFRC-SPは、200バイトのデータ・セグメントを使用して流れます。 5 TFRC-SPのフローが受信しながら、例えば、5つのTCPフローは、シミュレーションの後半には49％の平均ドロップ率をするとき5つのTCPフローと5 TFRC-SPフローは800回のWebセッションでリンクを共有見ます8％の平均低下率は、結果としてTCPのスループットフロー100回以上を受け取ります。これは、小さなパケットは大きなパケットとフローと同じパケットドロップ率を見ると流れの仮定を行うことについて深刻な問題を提起します。さらに作業は大きなパケットがかなり小さなものよりもドロップされる可能性が高いかどうかという点で、現実的なインターネット・シナリオの範囲の調査を含める必要があります。
< - - - - - Send Rates in Kbps - - - - >
Web TCP (512B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.02 335.05 0.00 185.16
25 0.02 289.94 0.00 185.36
50 0.04 139.99 0.01 184.98
100 0.06 53.50 0.01 184.66
200 0.10 16.14 0.04 167.87
400 0.16 6.36 0.07 114.85
800 0.24 0.90 0.11 67.23
1600 0.42 0.35 0.18 39.32
Table 14: Drop and Send Rates for Drop-Tail Queues in Bytes II: 512B TCP Segments
表14：バイトIIのドロップテールキューのドロップおよび送信料金：512B TCPセグメント
Table 14 shows that, in these scenarios, the long-lived TCP flows receive a higher packet drop rate than the TFRC-SP flows, and receive considerably less throughput, even when the long-lived TCP flows use 512-byte segments.
これらのシナリオでは、長寿命のTCPフローは長寿命TCPフロー場合でも、TFRC-SPフローよりも高いパケットドロップ率を受信し、かなり低いスループットを受け取る表14は、512バイトのセグメントを使用します。
To show the potential negative effect of TFRC-SP in such an environment, we consider a simulation with N TCP flows, N TFRC-SP flows, and 10*N web sessions, for N ranging from 1 to 50, so that the demand increases from all types of traffic, with routers with Drop-Tail queues in bytes.
このような環境でのTFRC-SPの潜在的な負の効果を示すために、我々は、需要が増加するようにN TCPとのシミュレーションは、N TFRC-SPの流れを流れ、10回の* NのWebセッション、Nは、1から50までの範囲のために考えますすべてのタイプのトラフィックから、バイト単位でドロップテールキューを持つルータと。
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.014 2085.36 0.001 180.29
20 0.040 788.88 0.004 183.87
30 0.074 248.80 0.006 182.94
40 0.113 163.20 0.008 185.33
50 0.127 94.70 0.011 185.14
60 0.177 53.24 0.015 185.30
70 0.174 35.31 0.016 185.07
80 0.221 19.38 0.019 183.91
90 0.188 15.63 0.019 180.42
100 0.265 7.08 0.023 176.71
200 0.324 0.38 0.042 139.48
300 0.397 0.32 0.076 93.53
400 0.529 0.40 0.100 70.40
500 0.610 0.37 0.121 57.59
Table 15: Drop and Send Rates for Drop-Tail Queues in Bytes III: TFRC-SP, 1460B TCP Segments
表15：TFRC-SP、1460B TCPセグメント：バイトIIIのドロップテールキューの料金をドロップして送信します
< - - - - - 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.
表16は、TFRC-SPの代わりに、TFRCを用いてシミュレーションを示している。表15は、TFRC-SPを使用してシミュレーションを示しています。この2つのテーブルでのシミュレーションの唯一の違いです。 TFRC-SPは、それぞれが57 Kbpsのを送り続けて流れる間に、TFRC-SPを使用する場合、TCPフローとWebトラフィックは、基本的に飢えていることに注意してください。標準TFRCは、代わりに200バイトのセグメントを送信するフローのTFRC-SPの使用されたときに、そのパケットのドロップ率があるとき、彼らはまだリンク帯域幅の彼らの「シェア」を受信していないが、これとは対照的に、TCPのフローは（餓死されていません30％以上）。シミュレーションのこれらの2セットは小さなパケットが大規模なものよりも、落下しにくい環境でのTFRC-SPの広範な展開の危険性を説明します。
B.4. Packet-dropping Behavior at Routers with AQM
B.4。 AQMとルータでのパケットドロップ動作
As expected, the packet-dropping behavior also can be varied by varying the Active Queue Management (AQM) mechanism in the router. When the routers use RED (Random Early Detection), there are several parameters than can affect the packet-dropping or marking behavior as a function of the packet size.
予想通り、パケット・ドロップ振る舞いも、ルータ内のアクティブキュー管理（AQM）メカニズムを変えることによって変化させることができます。ルータがRED（ランダム早期検出）を使用する場合は、パケットサイズの関数としてのパケットドロップまたはマーキング動作に影響を与えることができるよりも、いくつかのパラメータがあります。
First, as with Drop-Tail, the RED queue can be in units of either packets or bytes. This can affect the packet-dropping behavior when RED is unable to control the average queue size, and the queue overflows.
まず、ドロップテールと同様に、REDキューは、パケットまたはバイトのいずれかの単位にすることができます。 REDは、平均キューサイズ、およびキューのオーバーフローを制御することができないとき、これは、パケット・ドロップ動作に影響を与えることができます。
Second, and orthogonally, RED can be configured to be either in packet mode or in byte mode. In packet mode, each *packet* has the same probability of being dropped by RED, while in byte mode, each *byte* has the same probability of being dropped. In packet mode, large-packet and small-packet flows receive roughly the same packet drop rate, while in byte mode, large-packet and small-packet flows with the same throughput in bps receive roughly the same *number* of packet drops. [EA03] assessed the impact of byte vs. packet modes on RED performance.
第二に、そして直交し、REDはパケットモードまたはバイトモードのいずれかであるように構成することができます。バイトモードでは、各バイト* *はドロップされるのと同じ確率を有しているパケットモードでは、各パケット* *は、REDによって廃棄されるのと同じ確率を有します。パケットドロップのバイトモードでは、大きなパケットと小さなパケットがBPSに同じスループットで流れる間、パケット・モードでは、大きいパケットと小さいパケットフローが、ほぼ同じパケットドロップ率を受け取るは*ほぼ同じ*番号を受信します。 [EA03] REDパフォーマンス上のパケットモード対バイトの影響を評価しました。
The simulations reported below show that for RED in packet mode, the packet drop rates for the TFRC-SP flows are similar to those for the TCP flows, with a resulting acceptable throughput for the TFRC-SP flows. This is true with the queue in packets or in bytes, and with or without Adaptive RED (discussed below). As we show below, this fairness between TCP and TFRC-SP flows does not hold for RED in byte mode.
パケットモードで赤、TFRC-SPフローのパケットドロップ率がTCPの場合と同様であることを示して以下に報告するシミュレーションは、TFRC-SPフローの結果の許容されるスループットで、流れます。これは、パケットまたはバイト数、および適応RED（後述）の有無にかかわらずキューと同様です。私たちは以下を示しているように、TCPとTFRC-SPフロー間の公平性が、このバイトモードでREDのために保持していません。
The third RED parameter that affects the packet-dropping or marking behavior as a function of packet size is whether the RED mechanism is using Standard RED or Adaptive RED; Adaptive RED tries to maintain the same average queue size, regardless of the packet drop rate. The use of Adaptive RED allows the RED mechanism to function more effectively in the presence of high packet drop rates (e.g., greater than 10%). Without Adaptive RED, there is a fixed dropping threshold, and all arriving packets are dropped when the dropping or marking rate exceeds this threshold. In contrast, with Adaptive RED, the dropping function is adapted to accommodate high-drop-rate regimes. One consequence is that when byte mode is used with Adaptive RED, the byte mode extends even to high-drop-rate regimes. When byte mode is used with standard RED, however, the byte mode is no longer in use when the drop rate exceeds the fixed dropping threshold (set by default to 10% in the NS simulator).
パケットサイズの関数としてパケットドロップまたはマーキング行動に影響を与える第三のREDパラメータは、RED機構標準REDまたはAdaptive REDを使用しているかどうかです。適応REDは関係なく、パケット廃棄率の、同じ平均キューサイズを維持しようとします。適応REDの使用は、RED機構が高いパケット損失率（例えば、10％を超える）の存在下で、より効果的に機能することを可能にします。アダプティブREDがなければ、そこに固定ドロップする閾値であり、滴下またはマーキング率がこのしきい値を超えた場合、すべて到着したパケットはドロップされます。対照的に、適応REDと、滴下機能は、高ドロップ率制度を収容するように適合されています。 1つの結果は、バイトモードが適応RED、バイトモードで使用されている場合でも、高ドロップ相場制度にまで及ぶということです。バイトモードを標準REDとともに使用される場合、ドロップ率が（NSシミュレータ10％にデフォルトで設定された）固定されたドロップ閾値を超えた場合、しかし、バイトモードが使用されていません。
In the simulations in this section, we explore the TFRC-SP behavior over some of this range of scenarios. In these simulations, as in Section B.3 above, the application for the TFRC-SP flow uses 200-byte data packets, generating 100 packets per second.
このセクションのシミュレーションでは、我々はシナリオのこの範囲の一部にわたりTFRC-SPの挙動を探ります。これらのシミュレーションでは、上のセクションB.3のように、TFRC-SPフローのアプリケーションは、毎秒100個のパケットを生成、200バイトのデータパケットを使用します。
< - - - - - 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：パケットモードでREDキューの料金をドロップして送信します
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のシミュレーションのため、パケットモードにおけるREDキューに輻輳ルータと、上記の結果は、表12のように、パケットのドロップ、テールキューと同様です。それは、より混雑した環境で、より高いスループットを受けるもののTFRC-SPの流れは、TCPフローと同様のパケットドロップ率を受け取ります。シミュレーションは、バイト単位でキューのパケットモードにおけるREDキューに類似しており、そして付きまたはAdaptive REDはありません。これらのシミュレーションでは、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
表18：バイトモードでREDキューの料金をドロップして送信します
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は、バイトモードの代わりに、パケットモードにおける標準REDキューで、特に低いパケット損失率のために、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：バイトモードでREDキューの料金をドロップして送信します
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は、バイトモード及び長寿命TCPと標準REDキューは512バイトのデータセグメントに流れると、552バイトのTCPパケットのパケットドロップ率と240バイトTFRCとの間の中程度の違いがあることを示しています-SPパケット。しかし、より高いパケット損失率の表19のシナリオにおけるTFRC-SPのための送信レートが依然として所望のより大きい、さらに所定のTCPとの公平性の目標ではなく、512バイトのデータセグメントから1500バイトのデータセグメントと流れます。
< - - - - - 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：バイトモードでAdaptive REDキューで料金をドロップして送信します
For the simulations in Table 20, the congested router uses an Adaptive RED queue in byte mode.
表20におけるシミュレーションでは、混雑ルータはバイトモードでAdaptive REDキューを使用しています。
For this router, the output queue is in units of bytes rather than of packets, and each *byte* is dropped with the same probability. Also, because of the use of Adaptive RED, this byte-dropping mode extends even for the high-packet-drop-rate regime.
このルータの場合、出力キューはバイトのではなく、パケット単位であり、かつそれぞれ*バイト*は同じ確率でドロップされます。また、アダプティブREDの使用のため、このバイト・ドロップモードでも高いパケット廃棄率政権に及びます。
As Table 20 shows, for a scenario with Adaptive RED in byte mode, the packet drop rate for the TFRC-SP traffic is *much* lower than that for the TCP traffic, and as a consequence, the sending rate for the TFRC-SP traffic in a highly congested environment is *much* higher than that of the TCP traffic. In fact, in these scenarios the TFRC-SP congestion control mechanisms are largely ineffective for the small-packet traffic.
表20が示すように、バイトモードでのAdaptive REDとのシナリオのために、TFRC-SPトラフィックのパケットドロップ率は、* TFRC-SPのための送信レートのTCPトラフィックのための、そして結果として、それよりもはるかに低いです*非常に混雑した環境でのトラフィックは、* 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.
TFRC-SPパケットのドロップ率が大幅に減少するTCPパケットは、レートが上昇をドロップするので、1600台のWebサーバとのシミュレーションは、特に懸念されます。これはありませんTFRC-SPのダイナミクスについて、NSシミュレータにおける適応RED実装の詳細が原因です。特に、適応REDは50％以上のパケットのドロップ率に「適応」しないように構成されています。パケットのドロップ率が50％以下であると、Adaptive REDは、パケットサイズに比例したパケットのドロップ率を維持するのに適度に成功しています。 TCPパケットは、（ヘッダを含む）TFRC-SPパケットより6倍大きいので、TCPパケットは、パケットドロップ率が約6倍大きいはずです。
But for packet drop rates over 50%, Adaptive RED is no longer in this regime, so it is no longer successful in keeping the drop rate for TCP packets at most six times the drop rate of the TFRC-SP packets.
しかし、50％を超えるパケット廃棄率のために、適応REDは、この政権ではなくなり、それはもはやTFRC-SPパケットのほとんどの6倍、ドロップ率でTCPパケットのドロップ率を維持するのに成功しています。
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に示す不公平よりもあることに注意してください。バイトモードでのAdaptive RED持つ任意のルータのインターネットで、または類似の挙動を持つ任意のアクティブキュー管理機構のいずれかの展開がある場合は、同時に、それが知られていません。私たちは、あるいは、提案AQMメカニズムのいずれかの、標準REDの展開の度合いを知りません。
< - - - - - 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：バイトモードでAdaptive REDキューの料金をドロップして送信します
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は、バイトモードでのAdaptive REDとシナリオで552バイトのパケットとTCPと競合する場合TCPフローよりも、TFRC-SPフローは依然として多くの帯域幅を受け取ることを示しているが、不公平のレベルそれほど深刻で、TCPフローのパケットドロップ率が二倍で最もTFRC-SPフローのことです。すなわち、TFRC-SPフローは依然として帯域幅のシェアよりも受信するが、TFRC-SP輻輳制御は、上記表20に比べてより効果的です。
Appendix C. Exploring Possible Oscillations in the Loss Event Rate
付録C.は、ロスイベントレートで可能な振動を探ります
TFRC-SP estimates the loss interval size differently for short and long loss intervals, counting only one loss event for long loss intervals, but counting all packet losses as loss events for the short loss intervals. One question that has been raised is whether this can lead to oscillations in the average loss event rate in environments where there are many packet drops in a single loss event, and loss events switch from short to long and vice versa. As an example, consider a loss interval with N packets, including N/4 losses. If this loss interval is short (at most two round-trip times), the loss interval length is measured as 4 packets. If this loss interval is long, then the loss interval length is measured as N packets.
TFRC-SPは長い損失間隔のために一つだけの損失イベントを数えますが、短い損失間隔のための損失イベントなど、すべてのパケットロスを数え、短期および長期の損失間隔ごとに異なる損失間隔のサイズを推定します。提起されている一つの質問は、これは、多くのパケットがある環境での平均損失イベント率の振動につながることができるかどうかである単一の損失イベントに低下し、損失事象は、短期から長期およびその逆に切り替えます。一例として、N / 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.
バック長いショートからスイッチング損失間隔が平均パケットドロップ率が厳しい振動につながる場合、したがって許容送信レートで、一つの解決策は、略し損失インターバル長の算出の間のより緩やかな遷移を有することであろうそして、長い損失間隔。例えば、一つの可能性は、二つの往復時間のロス間隔からパケット損失の2/3を使用するように、損失区間長を計算する際に1往復時間の損失間隔のパケット損失の全てを使用することであろう、3ラウンドトリップ時間のロス間隔からパケットロスの1/3を使用すると、4以上の往復時間のロス間隔からわずか1パケットロスを使用します。これより緩やかなメカニズムは、唯一の往復時間のロス間隔のためのすべての損失を数え、そして4以上の往復時間の損失間隔のために一つだけの損失イベントをカウントへの移行を与えるだろう。
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]から入手できます。したがって、今の私たちは、この文書で説明する短い損失間隔のための損失イベント率を推定するための単純なデフォルト機構が滞在しています。
Appendix D. A Discussion of Packet Size and Packet Dropping
パケットサイズの付録D. Aディスカッションおよびパケットドロップ
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:
パケットサイズのパケットドロップ独立の利点：
Advantages of Packet Dropping as a Function of Packet Size:
パケットサイズの関数としてパケット廃棄の利点：
1. Small control packets are less likely to be dropped than are large data packets, improving TCP performance.
1.小型の制御パケットは、大きなデータパケットよりもTCP性能を向上、廃棄される可能性は低いです。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 3448、2003年1月。
Informative References
参考文献
[EA03] W. Eddy and M. Allman. A Comparison of RED's Byte and Packet Modes, Computer Networks, 42(2), June 2003.
[EA03] W.渦およびM.オールマン。 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]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC879] Postel, J., "TCP maximum segment size and related topics", RFC 879, November 1983.
[RFC879]ポステル、J.、 "TCPの最大セグメントサイズと関連項目"、RFC 879、1983年11月。
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[RFC1144]ジェーコブソン、V.、RFC 1144、1990年2月 "低速シリアルリンク用のTCP / IPヘッダの圧縮"。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、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]春、N.、Wetherall、D.、およびD.イーリー、 "ロバスト明示的輻輳通知（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]フロイド、S.とJ.ケンプ、「インターネットでの音声トラフィックのための輻輳制御に関する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]カーン、P.、ボルマン、C.、Fairhurst、G.、グロスマン、D.、ルートヴィヒ、R.、Mahdavi、J.、モンテネグロ、G.、タッチ、J.、およびL.ウッド、「アドバイスインターネットサブネットワークデザイナー」、BCP 89、RFC 3819、2004年7月のため。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（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]フロイド、S.、コーラー、E.、およびJ. Padhye、 "データグラム混雑制御プロトコル（DCCP）輻輳制御ID 3のプロフィール：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]ハンドリー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、進歩、2007年3月に作業。
[S05] Peter Sholander, private communications, August 2005. Citation for acknowledgement purposes only.
[S05]ピーターSholander、プライベート通信、確認のみを目的として2005年8月の引用。
[V00] P. Vasallo. Variable Packet Size Equation-Based Congestion Control. ICSI Technical Report TR-00-008, April 2000, <http://www.icsi.berkeley.edu/cgi-bin/ pubs/publication.pl?ID=001183>
[V00] P. Vasallo。可変パケットサイズの方程式ベースの輻輳制御。 ICSI技術レポートTR-00から008、2000年4月、<http://www.icsi.berkeley.edu/cgi-bin/パブ/ 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.ウィドマー、C. Boutremans、およびジャンイヴルBoudec。可変パケットサイズ、ACM CCR、34（2）、2004フローの輻輳制御。
Authors' Addresses
著者のアドレス
Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
インターネットリサーチ1947センターストリートのためのサリーフロイドICSIセンター、スイート600バークレー、CA 94704 USA
EMail: floyd@icir.org
メールアドレス：floyd@icir.org
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
エディー・コーラー4531C BoelterホールUCLAコンピュータサイエンス学部ロサンゼルス、CA 90095 USA
EMail: kohler@cs.ucla.edu
メールアドレス：kohler@cs.ucla.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。