RFC4828 日本語訳
4828 TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant.S. Floyd, E. Kohler. April 2007. (Format: TXT=116808 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Floyd
Request for Comments: 4828 ICIR
Category: Experimental E. Kohler
UCLA
April 2007
コメントを求めるワーキンググループS.フロイド要求をネットワークでつないでください: 4828年のICIRカテゴリ: 実験的なE.コーラーUCLA2007年4月
TCP Friendly Rate Control (TFRC):
The Small-Packet (SP) Variant
TCPの好意的な速度制御(TFRC): 小型小包(SP)異形
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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好意的なRate Control(TFRC)はベストエフォート型インターネット環境(RFC3448)で作動するユニキャスト流れのための混雑制御機構です。 TFRCは、固定パケットサイズを使用するアプリケーションのために意図して、TCP接続と共に同じパケットサイズを使用することで帯域幅を競争するとき、合理的に公正になるように設計されました。 このドキュメントはTFRC-SP、小型小包を送るアプリケーションのために設計されているTFRCのSmall-パケット(SP)異形を提案します。 TFRC-SPのデザイン目標はTCP流動としてビーピーエス(bps)で最大1500バイトのパケットを使用することで同じ帯域幅を達成することです。 TFRC-SPは、ただ一つの流れが頻繁に任意に小型小包を送るのを防ぐためにデータ・パケットの間の10msの最小間隔を実施します。
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は大きいパケット流れと小さいパケット流れが同様のパケット低下率になる環境で流れます。 しかしながら、小型小包流れが大きいパケットの流れ(例えば、ユニットのバイトにおけるDrop-テール待ち行列がある)より低パケット低下率になる環境で、TFRC-SPは帯域幅のシェアよりさらにかなり受信できます。
Floyd & Kohler Experimental [Page 1] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[1ページ]RFC4828TFRC: SP異形2007年4月
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions .....................................................5
3. TFRC-SP Congestion Control ......................................5
4. TFRC-SP Discussion ..............................................9
4.1. Response Functions and Throughput Equations ................9
4.2. Accounting for Header Size ................................12
4.3. The TFRC-SP Min Interval ..................................13
4.4. Counting Packet Losses ....................................14
4.5. The Nominal Packet Size ...................................15
4.5.1. Packet Size and Packet Drop Rates ..................15
4.5.2. Fragmentation and the Path MTU .....................17
4.5.3. The Nominal Segment Size and the Path MTU ..........17
4.6. The Loss Interval Length for Short Loss Intervals .........18
5. A Comparison with RFC 3714 .....................................19
6. TFRC-SP with Applications that Modify the Packet Size ..........19
7. Simulations ....................................................20
8. General Discussion .............................................21
9. Security Considerations ........................................22
10. Conclusions ...................................................23
11. Acknowledgements ..............................................24
Appendix A. Related Work on Small-Packet Variants of TFRC .........25
Appendix B. Simulation Results ....................................26
B.1. Simulations with Configured Packet Drop Rates .............26
B.2. Simulations with Configured Byte Drop Rates ...............30
B.3. Packet Dropping Behavior at Routers with Drop-Tail
Queues ....................................................32
B.4. Packet Dropping Behavior at Routers with AQM ..............37
Appendix C. Exploring Possible Oscillations in the Loss Event
Rate ...........................................................42
Appendix D. A Discussion of Packet Size and Packet Dropping .......43
Normative References ..............................................44
Informative References ............................................44
1. 序論…3 2. コンベンション…5 3. TFRC-SP輻輳制御…5 4. TFRC-SP議論…9 4.1. レスポンス関数とスループット方程式…9 4.2. ヘッダーサイズのための会計…12 4.3. TFRC-SP分、間隔…13 4.4. パケット損失を数えます…14 4.5. 名目上のパケットサイズ…15 4.5.1. パケットサイズとパケットはレートを落とします…15 4.5.2. 断片化と経路MTU…17 4.5.3. 名目上のセグメントサイズと経路MTU…17 4.6. 短い損失間隔の間の損失間隔の長さ…18 5. RFC3714との比較…19 6. Applicationsに伴うTFRC-SPそのModify Packet Size…19 7. シミュレーション…20 8. 一般議論…21 9. セキュリティ問題…22 10. 結論…23 11. 承認…24 付録A.はTFRCの小型小包異形に対する仕事を関係づけました…25 付録B.シミュレーションは結果として生じます…26 B.1。 構成されたパケットとのシミュレーションはレートを落とします…26 B.2。 構成されたバイトとのシミュレーションはレートを落とします…30 B.3。 低下テールでルータで振舞いを落とすパケットが列を作ります…32 B.4。 AQMと共にルータで振舞いを落とすパケット…損失出来事で可能な振動を探検する37付録C.が評価します…42 パケットサイズとパケット低下の付録D.A議論…43 標準の参照…44 有益な参照…44
Floyd & Kohler Experimental [Page 2] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[2ページ]RFC4828TFRC: SP異形2007年4月
1. Introduction
1. 序論
This document specifies TFRC-SP, an experimental, Small-Packet variant of TCP-friendly Rate Control (TFRC) [RFC3448].
このドキュメントはTFRC-SP、TCPに優しいRate Control(TFRC)[RFC3448]の実験的なSmall-パケット異形を指定します。
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.
TCPと共に帯域幅を競争するのが流れますが、メカニズムTFRCがTCPの輻輳制御の送付レートの特性における突然の変化を避けるために比較的滑らかな送付レートが重要であるストリーミング・メディアアプリケーションなどの応用のために意図するとき、TFRCは、合理的に公正になるように設計されました。 従来のTFRCは、[RFC3448]で説明されるように損失イベント比を見積もっていることによって損失率を測定して、往復の時間あたりのパケットで送付レートを測定するのにこの損失イベント率を使用します。 これには、大きいパケットTCP流れとボトルネックを共有するときTFRC流動が実現できるレートのための結果があります。 特に低バンド幅、小型小包TFRC流動が高帯域とボトルネックを共有する場合、大きいパケットTCP流れはやむを得ず減速するかもしれません、1秒あたりのバイトで表現されるTFRCアプリケーションの名目上のレートがTCP流れによって達成されたレートより少ないのですが。 ネットワーク制限が秒(リンク帯域幅などの)あたりのバイトよりむしろ秒(ルーティングルックアップなどの)あたりのパケットにある場合にだけ、これは直観的に、「公正でしょうに」。 一般通念は今日のインターネットでのネットワーク制限の多くが1秒あたりのバイトであるということです、未来のネットワーク制限が1秒あたりのパケットで制限に近づき返すかもしれませんが。
TFRC-SP is intended for flows that need to send frequent small packets, with less than 1500 bytes per packet, limited by a minimum interval between packets of 10 ms. It will better support applications that do not want their sending rates in bytes per second to suffer from their use of small packets. This variant is restricted to applications that send packets no more than once every 10 ms (the Min Interval or minimum interval). Given this restriction, TFRC-SP effectively calculates the TFRC fair rate as if the bottleneck restriction was in bytes per second. Applications using TFRC-SP could have a fixed or naturally-varying packet size, or could vary their packet size in response to congestion. Applications that are not willing to be limited by a minimum interval of 10 ms between packets, or that want to send packets larger than 1500 bytes, should not use TFRC-SP. However, for applications with a minimum interval of at least 10 ms between packets and with data packets of at most 1500 bytes, the performance of TFRC-SP should be at least as good as that from TFRC.
TFRC-SPは頻繁な小型小包を送る必要がある流れのために意図します、1原稿Itが彼らの小型小包の使用から受けるために1秒あたりのバイトで表現されるそれらの送付レートを必要としないアプリケーションをよりよく支持する10のパケットの最小間隔で制限されたパケットあたり1500バイト未満で。 この異形はかつてのあらゆる10msだけをパケットに送るアプリケーション(Min Intervalか最小間隔)に制限されます。 この制限を考えて、まるでボトルネック制限が1秒あたりのバイトであるかのように事実上、TFRC-SPはTFRCの公正なレートについて計算します。 TFRC-SPを使用するアプリケーションは、修理されたか自然に変えているパケットサイズを持つことができたか、または混雑に対応してそれらのパケットサイズを変えるかもしれません。 パケットの間の10msの最小間隔のそばで制限されることを望んでいないか、または1500バイトより大きいパケットを送りたがっているアプリケーションはTFRC-SPを使用するべきではありません。 しかしながら、パケットの間の少なくとも10msの最小間隔と高々1500バイトのデータ・パケットがあるアプリケーションにおいて、TFRC-SPの性能はTFRCからのそれと少なくとも同じくらい良いはずです。
RFC 3448, the protocol specification for TFRC, stated that TFRC-PS (for TFRC-PacketSize), a variant of TFRC for applications that have a fixed sending rate but vary their packet size in response to congestion, would be specified in a later document. This document instead specifies TFRC-SP, a variant of TFRC designed for
RFC3448(TFRCのためのプロトコル仕様)は、TFRC-PS(TFRC-PacketSizeのための)(固定送付レートを持っていますが、混雑に対応してそれらのパケットサイズを変えるアプリケーションのためのTFRCの異形)が後のドキュメントで指定されると述べました。 このドキュメントは代わりにTFRC-SP、設計されたTFRCのa異形を指定します。
Floyd & Kohler Experimental [Page 3] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[3ページ]RFC4828TFRC: SP異形2007年4月
applications that send small packets, where applications could either have a fixed or varying packet size or could adapt their packet size in response to congestion. However, as discussed in Section 6 of this document, there are many questions about how such an adaptive application would use TFRC-SP that are beyond the scope of this document, and that would need to be addressed in documents that are more application-specific.
アプリケーションが修理されたか異なったパケットサイズを持つことができたか、または混雑に対応してそれらのパケットサイズを適合させるかもしれないところで小型小包を送るアプリケーション。 しかしながら、このドキュメントのセクション6で議論するように、そのような適応型のアプリケーションがどうこのドキュメントの範囲にあって、よりアプリケーション特有のドキュメントに記述される必要があるTFRC-SPを使用するだろうかに関する多くの質問があります。
TFRC-SP is motivated in part by the approach in RFC 3714, which argues that it is acceptable for VoIP flows to assume that the network limitation is in bytes per second (Bps) rather in packets per second (pps), and to have the same sending rate in bytes per second as a TCP flow with 1500-byte packets and the same packet drop rate. RFC 3714 states the following:
TFRC-SPはRFC3714でアプローチで一部動機づけられています。(RFCはVoIP流れが、ネットワーク制限がむしろ2番目の(pps)あたりのパケットの2番目の(bps)あたりのバイトであると仮定して、1500年のバイトのパケットがあるTCP流動としての2番目で同じパケット低下率あたりのバイトで同じ送付レートを持っているのが許容できると主張します)。 RFC3714は以下を述べます:
"While the ideal would be to have a transport protocol that is
able to detect whether the bottleneck links along the path are
limited in Bps or in pps, and to respond appropriately when the
limitation is in pps, such an ideal is hard to achieve. We would
not want to delay the deployment of congestion control for
telephony traffic until such an ideal could be accomplished. In
addition, we note that the current TCP congestion control
mechanisms are themselves not very effective in an environment
where there is a limitation along the reverse path in pps. While
the TCP mechanisms do provide an incentive to use large data
packets, TCP does not include any effective congestion control
mechanisms for the stream of small acknowledgement packets on the
reverse path. Given the arguments above, it seems acceptable to
us to assume a network limitation in Bps rather than in pps in
considering the minimum sending rate of telephony traffic."
「理想が経路に沿ったボトルネックリンクがBpsかppsで制限されるかどうか検出して、制限がppsにあるとき適切にこたえることができるトランスポート・プロトコルを持つだろうことですが、そのような理想は達成しにくいです。」 そのような理想を達成できるまで電話交通のための輻輳制御の展開を遅らせたいと思わないでしょう。 さらに、私たちは、現在のTCP混雑制御機構がppsの逆の経路に沿って制限があるところで環境で自分たちでそれほど効果的でないことに注意します。 TCPメカニズムは大きいデータ・パケットを使用するために動機を提供しますが、TCPは逆の経路における小さい確認応答パケットの流れのための少しの有効な混雑制御機構も含んでいません。 「上の議論を考えて、ppsでというよりむしろBpsでの考慮におけるネットワーク制限が電話交通の最小の送付速度であると仮定するように私たちにとって許容できるように思えます。」
Translating the discussion in [RFC3714] to the congestion control mechanisms of TFRC, it seems acceptable to standardize a variant of TFRC that allows low-bandwidth flows sending small packets to achieve a rough fairness with TCP flows in terms of the sending rate in Bps, rather than in terms of the sending rate in pps. This is accomplished by TFRC-SP, a small modification to TFRC, as described below.
[RFC3714]でTFRCの混雑制御機構に議論を翻訳して、小型小包を送る低バンド幅流れにppsの送付レートに関してというよりむしろBpsに送付レートに関してTCP流れに伴う乱暴な公正を実現させるTFRCの異形を標準化するのは許容できるように思えます。 これは以下で説明されるように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原稿のパケットの間のMin Intervalの限界を含んでいます。
Floyd & Kohler Experimental [Page 4] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[4ページ]RFC4828TFRC: SP異形2007年4月
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.
最初の損失出来事の後に損失歴史を初期化します: .1セクション6.3RFC3448が、TFRC受信機が最初の損失出来事の後に生産するのに必要である損失間隔について計算することによって損失歴史を初期化すると指定する、最新の往復の時間測定されたレートを受け取ってください。 この損失間隔に計算する際に、TFRC-SPは接続に使用される実際のセグメントサイズよりむしろ1460バイトのセグメントサイズを使用します。
Calculating the loss event rate for TFRC-SP: TFRC-SP requires a modification in TFRC's calculation of the loss event rate, because a TFRC-SP connection can send many small packets when a standard TFRC or TCP connection would send a single large packet. It is not possible for a standard TFRC or TCP connection to repeatedly send multiple packets per round-trip time in the face of a high packet drop rate. As a result, TCP and standard TFRC only respond to a single loss event per round-trip time, and are still able to detect and respond to increasingly heavy packet loss rates. However, in a highly-congested environment, when a TCP connection might be sending, on average, one large packet per round-trip time, a corresponding TFRC-SP connection might be sending many small packets per round-trip time. As a result, in order to maintain fairness with TCP, and to be able to detect changes in the degree of congestion, TFRC-SP needs to be sensitive to the actual packet drop rate during periods of high congestion. This is discussed in more detail in the section below.
TFRC-SPの損失イベント率について計算します: TFRC-SPはTFRCの損失イベント率の計算で修正を要します、標準のTFRCかTCP接続が単一の大きいパケットを送るだろうというとき、TFRC-SP接続が多くの小型小包を送ることができるので。 標準のTFRCかTCP接続が高いパケット低下率に直面して繰り返して複数の往復の時間あたりのパケットを送るのは、可能ではありません。 TFRCがますます重いパケットに往復の時間あたり1回の単一の損失出来事に反応して、検出して、まだ反応させることができるだけである結果、TCP、および規格として、損失は評価します。 しかしながら、非常に混雑している環境で、TCP接続が往復の時間あたり1つの大きいパケットを平均的に送るかもしれないとき、対応するTFRC-SP接続は多くの往復の時間あたりの小型小包を送るかもしれません。 その結果、TCPがある公正を維持して、混雑の度合いにおける変化を検出できるように、TFRC-SPは、高い混雑の期間、実際のパケット低下率に敏感である必要があります。 さらに詳細に下のセクションでこれについて議論します。
2. Conventions
2. コンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. TFRC-SP Congestion Control
3. TFRC-SP輻輳制御
TFRC uses the TCP throughput equation given in Section 3.1 of [RFC3448], which gives the allowed sending rate X in bytes per second as a function of the loss event rate, segment size, and round-trip time. [RFC3448] specifies that the segment size s used in the throughput equation should be the segment size used by the application, or the estimated mean segment size if there are variations in the segment size depending on the data. This gives rough fairness with TCP flows using the same segment size.
TFRCは[RFC3448]のセクション3.1で与えられたTCPスループット方程式を使用します。(それは、損失イベント率、セグメントサイズ、および往復の時間の関数として1秒あたりのバイトで表現される許容送付レートXを与えます)。 [RFC3448]は、セグメントサイズのデータによる変化があればスループット方程式で使用されるセグメントサイズsがアプリケーション、またはおよそ平均であるセグメントサイズに従ってサイズが使用したセグメントであるべきであると指定します。 これはTCP流れが同じセグメントサイズを使用している乱暴な公正を与えます。
Floyd & Kohler Experimental [Page 5] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[5ページ]RFC4828TFRC: SP異形2007年4月
TFRC-SP changes this behavior in the following ways.
TFRC-SPは以下の方法でこの振舞いを変えます。
o The nominal segment size: The nominal segment size s defaults to
1460 bytes. Following [RFC3714], this provides a goal of
fairness, in terms of the sending rate in bytes per second, with a
TCP flow with 1460 bytes of application data per packet but with
the same packet drop rate. If the endpoint knows the MTU (Maximum
Transmission Unit) of the path and the derived MSS (Maximum
Segment Size) is less than 1460 bytes, then the endpoint SHOULD
set the nominal segment size s to MSS bytes. In addition, if the
endpoint knows the MTU of the path and the resulting MSS is less
than 536 bytes, then the endpoint MUST set the nominal segment
size s to MSS bytes.
o 名目上のセグメントサイズ: 名目上のセグメントサイズsは1460バイトをデフォルトとします。 これは公正の目標を提供します、1秒あたりのバイトで表現される送付レートに関して、次のです[RFC3714]、1パケットあたりの1460バイトのアプリケーションデータにもかかわらず、同じパケット低下率に従ったTCP流動で。 終点が経路についてMTU(最大のTransmission Unit)を知って、派生しているMSS(最大のSegment Size)が1460バイト未満であるなら、終点SHOULDは名目上のセグメントサイズsをMSSバイトに設定します。 さらに、終点が経路についてMTUを知って、結果として起こるMSSが536バイト未満であるなら、終点は名目上のセグメントサイズsをMSSバイトに設定しなければなりません。
However, this document does not require that TFRC-SP endpoints
determine the path MTU. While most paths allow an MSS of 1460
bytes, some paths have a slightly smaller MSS due to tunnels
(e.g., IPv6 over IPv4). In some specific cases, IPv4 paths may
experience a much smaller path MTU. Due to the complications of
estimating the path MTU, and to the fact that most paths support
an MSS of at least 536 bytes, TFRC-SP as a default uses a nominal
segment size of 1460 bytes. The nominal segment size is discussed
in more detail in Section 4.5.3.
しかしながら、このドキュメントは、TFRC-SP終点が経路MTUを決定するのを必要としません。 トンネル(例えば、IPv4の上のIPv6)のため、ほとんどの経路が1460バイトのMSSを許容している間、いくつかの経路には、わずかに小さい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を伝えます。パケットのヘッダーサイズを説明する要素によって2番目単位で低下されます。 これは、不必要に小型小包を使用しないようにMin Intervalを超えて何らかの誘因をアプリケーションに与えます。 特に、私たちは新しいパラメタHを紹介します。(それは、TFRC接続のパケットの上で使用されるためにネットワークと輸送ヘッダーのバイトで表現される予想されたサイズを表します)。 これによる減少するのに使用されて、許容が以下のレートXを伝えるということです:
X := X * s_true / (s_true + H),
X:=の_の本当のX*s/(s_の本当の+H)
where s_true is the true average data segment size for the
connection in bytes, excluding the transport and network headers.
Section 4.1 of RFC 3448 states that where the packet size varies
naturally with the data, an estimate of the mean segment size can
be used for s_true. As suggested in Section 4.1 of [RFC3448bis],
when an estimate of the mean segment size is used for s_true, the
estimate SHOULD be calculated over at least the last four loss
intervals. However, this document does not specify a specific
algorithm for estimating the mean segment size.
どこ、s、_輸送とネットワークヘッダーを除いて、本当であるのは、バイトにおける接続のための正確な平均数データ・セグメントサイズであるか。 RFC3448のセクション4.1は、パケットサイズがデータで自然に異なるところでsに_本当に平均であるセグメントサイズの見積りを使用できると述べます。 (その時、平均であるセグメントサイズの見積りはsに_本当に使用されて、見積りはSHOULDです)。セクション4.1に示されるように、[RFC3448bis]では少なくとも最後の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
Hパラメタは一定の40バイトに設定されます。 したがって、中古の40バイトのデータが区分するTFRC-SPアプリケーション、許容が伝わるならレートXが事実を説明するために半分にされるだろう、その半分
Floyd & Kohler Experimental [Page 6] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[6ページ]RFC4828TFRC: SP異形2007年4月
of the sending rate would be used by the headers. Section 4.2
justifies this definition. However, a connection using TFRC-SP
MAY instead use a more precise estimate of H, based on the actual
network and transport headers to be used on the connection's
packets. For example, a Datagram Congestion Control Protocol
(DCCP) connection [RFC4340] over IPv4, where data packets use the
DCCP-Data packet type, and there are no IP or DCCP options, could
set H to 20 + 12 = 32 bytes. However, if the TFRC implementation
knows that the IP layer is using IPv6 instead of IPv4, then the
connection using TFRC-SP MAY still use the default estimate of 40
bytes for H instead of the actual size of 60 bytes, for simplicity
of implementation.
発信では、レートはヘッダーによって使用されるでしょう。 セクション4.2はこの定義を正当化します。 しかしながら、TFRC-SP MAYを使用している接続は、実際のネットワークと輸送ヘッダーに基づいて接続のパケットの上で使用されるのに代わりにHの、より正確な見積りを使用します。 例えば、IPv4の上のデータグラムCongestion Controlプロトコル(DCCP)接続[RFC4340]は20+12 = 32バイトにHを設定できました。そこには、データ・パケットがDCCP-データ・パケットタイプを使用して、IPかDCCPオプションが全くありません。 しかしながら、TFRC実現が、IP層がIPv4の代わりにIPv6を使用しているのを知っているなら、接続使用TFRC-SP MAYは60バイトの実サイズの代わりにHにまだ40バイトのデフォルト見積りを使用しています、実現の簡単さのために。
o Measuring the loss event rate in times of high loss: During short
loss intervals (those at most two round-trip times), the loss rate
is computed by counting the actual number of packets lost or
marked, not by counting at most one loss event per loss interval.
Without this change, TFRC-SP could send multiple packets per
round-trip time even in the face of heavy congestion, for a
steady-state behavior of multiple packets dropped each round-trip
time.
o 損失出来事を測定して、高い損失の時代に評価してください: 短い損失間隔(ほとんどの往復の2回のそれら)の間、損失率は、損失間隔あたり1回の損失出来事を高々数えることによって計算されるのではなく、失われたか、またはマークされたパケットの実数を数えることによって、計算されます。 この変化がなければ、TFRC-SPは重い混雑の表面でさえ複数の往復の時間あたりのパケットを送ることができました、往復の毎回落とされた複数のパケットの定常状態動きのために。
In standard TFRC, the TFRC receiver estimates the loss event rate
by calculating the average loss interval in packets, and inverting
to get the loss event rate. Thus, for a short loss interval with
N packets and K losses, standard TFRC calculates the size of that
loss interval as N packets, contributing to a loss event rate of
1/N. However, for TFRC-SP, for small loss intervals of at most
two round-trip times, if the loss interval consists of N packets
including K losses, the size of the loss interval is calculated as
N/K, contributing to a loss event rate of K/N instead of 1/N.
標準のTFRC、TFRC受信機見積りにおける損失イベント率を得るためにパケット、および逆にすることにおける海損間隔について計算するのによる損失イベント率。 したがって、NパケットとKの損失を伴う短い損失間隔の間、標準のTFRCはNパケットとしてその損失間隔のサイズについて計算します、1/Nの損失イベント率に貢献して。 しかしながら、損失間隔が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.
RFC3448のセクション5.4は、これが計算された海損間隔を増加させる場合にだけ海損間隔の計算が最新の損失間隔を含んでいると指定します、以下の擬似コードのように。 しかしながら、TFRC-SPでは、短い損失間隔の間の計算された損失間隔サイズは検出されたパケット損失の数の関数として異なります、新しいパケットが受け取られているので現在の短い損失間隔の間、計算された損失間隔サイズの増加か減少のどちらかを許して。 したがって、TFRC-SPはその損失間隔の始まり以来往復の2回以上が通っている場合にだけ海損間隔の計算が最新の損失間隔を含むことができるという制限を加えます。
Floyd & Kohler Experimental [Page 7] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[7ページ]RFC4828TFRC: SP異形2007年4月
Let the most recent loss intervals be I_0 to I_n, with I_0 being
the interval including the most recent loss event, with the
corresponding weights w_i as defined in RFC 3448. In RFC 3448
(Section 5.4), the average loss interval I_mean is calculated as
follows:
最新の損失間隔がI_0であることをIにさせてください、間隔包含最新の損失出来事であるI_0で、RFC3448で定義される対応する重りw_iで。 RFC3448(セクション5.4)、_が、私が以下の通り計算されることを意味する海損間隔で:
I_tot0 = 0;
I_tot1 = 0;
W_tot = 0;
for (i = 0 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1));
}
I_tot = max(I_tot0, I_tot1);
I_mean = I_tot/W_tot;
I_tot0=0。 I_tot1=0。 W_は=0を加えます。 iは(1〜i=n)のためにn-1) I_tot0=I_tot0+(I_i*w_i)(W_幼児=W_幼児+w_i)への0と等しいです。(I_tot1=I_tot1+(I_i*w_(i-1)); I_は=最大(__I tot0、I tot1)を加えます。 I_は、= I_幼児/W_が合計を意味します。
In TFRC-SP, the average loss interval I_mean is instead calculated as follows:
TFRC-SP、_が、私が代わりに以下の通り計算されることを意味する海損間隔で:
I_tot0 = 0;
I_tot1 = 0;
W_tot = 0;
for (i = 0 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i);
W_tot = W_tot + w_i;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1));
}
If the current loss interval I_0 is "short"
then I_tot = I_tot1;
else I_tot = max(I_tot0, I_tot1);
I_mean = I_tot/W_tot;
I_tot0=0。 I_tot1=0。 W_は=0を加えます。 iは(1〜i=n)のためにn-1) I_tot0=I_tot0+(I_i*w_i)(W_幼児=W_幼児+w_i)への0と等しいです。(I_tot1=I_tot1+(I_i*w_(i-1)); I_0が「短い」当期損失間隔であるなら、I_は=I_tot1を加えます。 ほかに、I_は=最大(__I tot0、I tot1)を加えます。 I_は、= I_幼児/W_が合計を意味します。
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原稿A流動のパケットの間のこのMin Intervalを超えるトランスポート・プロトコルがTFRC-SPよりむしろ従来のTFRC方程式を使用しなければならないことを願っているMin Intervalを実施します。 以下でこれに関する動機について議論します。
Floyd & Kohler Experimental [Page 8] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[8ページ]RFC4828TFRC: SP異形2007年4月
4. TFRC-SP Discussion
4. TFRC-SP議論
4.1. Response Functions and Throughput Equations
4.1. レスポンス関数とスループット方程式
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)))
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(法TCPのRTOを設定するための送付者アルゴリズムの範囲)のために本質的にはレスポンス関数を与えます。 [RFC3714]のTable1に示される高いパケット低下率のために、このスループット方程式は可能な限り攻撃的な現在のTCPがある乱暴な公正を与えます: タイムスタンプを使用するSACK TCP流動とExplicit Congestion Notification(電子証券取引ネットワーク)。 それがルータがレートが([RFC3168]のセクション7)であると低下するか、または高いパケットが、マークしている非常に混雑している環境で電子証券取引ネットワーク-マークを使用することが勧められないので、私たちは、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レスポンス関数から1460バイトのセグメントサイズsを使用して、実際にTFRC-SP流動によって経験された損失イベント率を使用することによって、TFRC-SPの有効なレスポンス関数を得ることができます。 さらに、高々往復の2回の損失間隔の間、TFRC-SPの損失イベント率は、損失出来事を数えることによってというよりむしろ無くなっているか著しいパケットの実数を数えることによって、見積もられています。 さらに、TFRC-SPの送付レートは高々1秒あたり100のパケットであることが抑制されます。
Floyd & Kohler Experimental [Page 9] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[9ページ]RFC4828TFRC: SP異形2007年4月
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(1秒あたりのキロバイト)で以下の通りであって、与えた状態で例証されます、100msの往復の時間がある流れのために:
<-- TCP and Standard TFRC -->
Packet 14-byte 536-byte 1460-byte
DropRate Segments Segments Segments
-------- -------- -------- --------
0.00001 209.25 2232.00 5812.49
0.00003 120.79 1288.41 3355.24
0.00010 66.12 705.25 1836.58
0.00030 38.10 406.44 1058.45
0.00100 20.74 221.23 576.12
0.00300 11.76 125.49 326.79
0.01000 6.07 64.75 168.61
0.03000 2.99 31.90 83.07
0.10000 0.96 10.21 26.58
0.20000 0.29 3.09 8.06
0.30000 0.11 1.12 2.93
0.40000 0.05 0.48 1.26
0.50000 0.02 0.24 0.63
<--TCPと標準のTFRC--パケット14バイトの536バイトの1460年のバイトのDropRate>セグメントセグメントセグメント-------- -------- -------- -------- 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のためのレスポンス関数。 パケット低下率の関数としてキロビット毎秒でレートを送ります。
<---------- TFRC-SP -------->
Packet 14-byte 536-byte 1460-byte
DropRate Segments Segments Segments
-------- -------- -------- --------
0.00001 5.40 57.60 150.00
0.00003 5.40 57.60 150.00
0.00010 5.40 57.60 150.00
0.00030 5.40 57.60 150.00
0.00100 5.40 57.60 150.00
0.00300 5.40 57.60 150.00
0.01000 5.40 57.60 150.00
0.03000 5.40 57.60 83.07
0.10000 5.40 26.58 26.58
0.20000 5.40 8.06 8.06
0.30000 2.93 2.93 2.93
0.40000 1.26 1.26 1.26
0.50000 0.63 0.63 0.63
<。---------- TFRC-SP--------14バイトの>の536バイトの1460年のバイトのDropRateセグメントセグメントパケットセグメント-------- -------- -------- -------- 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.のためのレスポンス関数 パケット低下率の関数としてキロビット毎秒でレートを送ります。 1秒あたり100のパケットの最大の送付レート。
Floyd & Kohler Experimental [Page 10] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[10ページ]RFC4828TFRC: SP異形2007年4月
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.
Tables1と2のための計算は損失イベント率pに近似のパケット損失率を使用します。 テーブルのためのスクリプトとグラフは[VOIPSIMS]から利用可能です。 Table1の周知のTCPレスポンス関数が目立っているように、セグメントサイズに従って、TCPと標準のTFRCの送付レートは直線的に異なります。 Table2に示されたTFRC-SPレスポンス関数は1秒あたり100のパケットの最大の送付レートを反映します。 この最大の送付レートによって制限されないと、TCPが1460年のバイトのセグメントであふれるとき、TFRC-SP流動はKBpsに同じ送付レートを受け取ります、同じパケット低下率を考えて。 TCP、標準のTFRC、およびTFRC-SPが構成されたパケット低下率に対応してレートを送るのを示すシミュレーションは、Tables7、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
<--TCPと標準のTFRC--バイト14バイトの536バイトの1460年のバイトのDropRate>セグメントセグメントセグメント-------- -------- -------- -------- 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のためのレスポンス関数。 バイト低下率の関数としてキロビット毎秒でレートを送ります。
Floyd & Kohler Experimental [Page 11] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[11ページ]RFC4828TFRC: SP異形2007年4月
<---------- TFRC-SP -------->
Byte 14-byte 536-byte 1460-byte
DropRate Segments Segments Segments
-------- -------- -------- --------
0.0000001 5.40 57.60 150.00
0.0000003 5.40 57.60 150.00
0.0000010 5.40 57.60 150.00
0.0000030 5.40 57.60 150.00
0.0000100 5.40 57.60 132.75
0.0000300 5.40 57.60 61.70
0.0001000 5.40 50.00 16.25
0.0003000 5.40 12.89 1.70
0.0010000 5.40 0.95 0.15
0.0030000 5.40 0.12 0.06
0.0100000 1.10 0.06 0.06
0.0300000 0.13 0.06 0.06
<。---------- TFRC-SP--------14バイトの>の536バイトの1460年のバイトのDropRateセグメントセグメントバイトセグメント-------- -------- -------- -------- 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.のためのレスポンス関数 バイト低下率の関数としてキロビット毎秒でレートを送ります。 1秒あたり100のパケットの最大の送付レート。
For Tables 3 and 4, the packet drop rate is calculated as 1-(1-b)^N, for a byte drop rate of b, and a packet size of N bytes. These tables use the packet loss rate as an approximation for the loss event rate p. The TCP response functions shown in Table 3 for fixed byte drop rates are rather different from the response functions shown in Table 1 for fixed packet drop rates; with higher byte drop rates, a TCP connection can have a higher sending rate using *smaller* packets. Table 4 also shows that with fixed byte drop rates, the sending rate for TFRC-SP can be significantly higher than that for TCP or standard TFRC, regardless of the TCP segment size. This is because in this environment, with small packets, TFRC-SP receives a small packet drop rate, but is allowed to send at the sending rate of a TCP or standard TFRC flow using larger packets but receiving the same packet drop rate.
Tables3と4に関しては、パケット低下率は1(1-b)^Nとして計算されます、bのバイト低下率、およびNバイトのパケットサイズのために。 これらのテーブルは損失イベント率pに近似としてパケット損失率を使用します。 固定バイトTable3に低下率が固定パケットのためにTable1に示されたレスポンス関数とかなり異なっているのが示されたTCPレスポンス関数はレートを落とします。 より高いバイト低下率のために、TCP接続は、*より小さい*パケットを使用することで、より高い送付レートを持つことができます。 また、テーブル4は、固定バイト低下率で、TFRC-SPの送付レートがTCPのためのそれか標準のTFRCよりかなり高い場合があるのを示します、TCPセグメントサイズにかかわらず。 これは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.
Appendix B.2で構成されたバイトに対応した送付レートがレートを落とすのをTCP、標準のTFRC、およびTFRC-SPに示すシミュレーションを与えます。
4.2. Accounting for Header Size
4.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,
[RFC3714]はネットワークの制限がCPUサイクルかパケットであるのではなく、帯域幅に2番目の(pps)単位で2番目の(bps)あたりのバイトであるという楽観的な想定をします。 しかしながら、Bpsの負荷に関してまた、ppsの負荷に何らかの注意を向けなければなりません。 Min Intervalは別としてさえ、TFRC-SPは、より少ない、しかし、より大きいパケットを使用する何らかの誘因をアプリケーションに与えます、より大きいパケットが十分であると
Floyd & Kohler Experimental [Page 12] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[12ページ]RFC4828TFRC: SP異形2007年4月
by including the bandwidth used by the packet header in the allowed sending rate.
許容送付レートにパケットのヘッダーによって使用された帯域幅を含んでいることによって。
As an example, a sender using 120-byte packets needs a TCP-friendly rate of 128 Kbps to send 96 Kbps of application data. This is because the TCP-friendly rate is reduced by a factor of s_true/(s_true + H) = 120/160, to account for the effect of packet headers. If the sender suddenly switched to 40-byte data segments, the allowed sending rate would reduce to 64 Kbps of application data; and the use of one-byte data segments would reduce the allowed sending rate to 3.12 Kbps of application data. (In fact, the Min Interval would prevent senders from achieving these rates, since applications using TFRC-SP cannot send more than 100 packets per second.)
例として、120バイトのパケットを使用している送付者は、128KbpsのTCPに優しいレートにアプリケーションデータの96Kbpsを送る必要があります。 これはTCPに優しいレートはs_本当の/(s_の本当の+H)=120/160の要素によって低下させられて、パケットのヘッダーの効果の原因になるからです。 送付者が突然40バイトのデータ・セグメントに切り替わるなら、許容送付レートはアプリケーションデータの64Kbpsまで減少するでしょうに。 そして、1バイトのデータ・セグメントの使用は許容送付レートをアプリケーションデータの3.12Kbpsまで低下させるでしょう。 (事実上、Min Intervalは、送付者がこれらのレートを達成するのを防ぐでしょう、TFRC-SPを使用するアプリケーションが1秒あたり100以上のパケットを送ることができないので。)
Unless it has a more precise estimate of the header size, TFRC-SP assumes 40 bytes for the header size, although the header could be larger (due to IP options, IPv6, IP tunnels, and the like) or smaller (due to header compression) on the wire. Requiring the use of the exact header size in bytes would require significant additional complexity, and would have little additional benefit. TFRC-SP's default assumption of a 40-byte header is sufficient to get a rough estimate of the throughput, and to give the application some incentive not to use an excessive amount of small packets. Because we are only aiming at rough fairness, and at a rough incentive for applications, the default use of a 40-byte header in the calculations of the header bandwidth is sufficient for both IPv4 and IPv6.
それにヘッダーサイズの、より正確な見積りがない場合、TFRC-SPはヘッダーサイズのために40バイトを仮定します、ヘッダーが、より大きいか(IPオプション、IPv6、IPトンネル、および同様のものによる)、またはワイヤでは、より小さいかもしれませんが(ヘッダー圧縮による)。 バイトにおける正確なヘッダーサイズの使用を必要とする場合、重要な追加複雑さが必要であるだろう、追加利益はほとんど持たれていないでしょう。 TFRC-SPの40バイトのヘッダーのデフォルト仮定は、スループットの概算を得て、過量の小型小包を使用しない何らかの誘因をアプリケーションに与えるために十分です。 私たちが乱暴な公正においてアプリケーションのための荒い誘因を目的としているだけであるので、ヘッダー帯域幅の計算における40バイトのヘッダーのデフォルト使用はIPv4とIPv6の両方に十分です。
4.3. The TFRC-SP Min Interval
4.3. TFRC-SP分、間隔
The header size calculation provides an incentive for applications to use fewer, but larger, packets. Another incentive is that when the path limitation is in pps, the application using more small packets is likely to cause higher packet drop rates, and to have to reduce its sending rate accordingly. That is, if the congestion is in terms of pps, then the flow sending more pps will increase the packet drop rate, and have to adjust its sending rate accordingly. However, the increased congestion caused by the use of small packets in an environment limited by pps is experienced not only by the flow using the small packets, but by all of the competing traffic on that congested link. These incentives are therefore insufficient to provide sufficient protection for pps network limitations.
アプリケーションが、より少なくて、しかし、より大きいパケットを使用するように、ヘッダーサイズ計算は動機を提供します。 別の誘因は経路制限がppsにあるとき、より小さいパケットを使用するアプリケーションが、より高いパケット低下率を引き起こして、送付レートをそれに従って、低下させなければならないのにおいて傾向があるということです。 すなわち、ppsに関して混雑があると、より多くのppsを送る流れは、パケット低下率を増加させて、それに従って、送付レートを調整しなければならないでしょう。 しかしながら、ppsによって制限された環境における小型小包の使用で引き起こされた増加する混雑は小型小包を使用する流れで経験されるだけではなく、その混雑しているリンクにおける競争している交通のすべてによっても経験されます。 したがって、これらの誘因は、ppsネットワーク制限のための十分な保護を提供するためには不十分です。
TFRC-SP, then, includes a Min Interval of 10 ms. This provides additional restrictions on the amount of small packets used.
そして、TFRC-SPは原稿Thisが使用される小型小包の量で追加制限を提供する10のMin Intervalを含んでいます。
Floyd & Kohler Experimental [Page 13] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[13ページ]RFC4828TFRC: SP異形2007年4月
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.
Min Intervalのための1つの実用的な正当化が現在小型小包を送りたがっているアプリケーションが10ms毎を1つのパケットに高々送るVoIPアプリケーションであるということであるので、この制限は現在の交通に影響しません。 2番目の正当化は現在のインターネットのベストエフォート型交通がかつてのあらゆる10msより頻繁(送付者で10msに遅れを取って、1つより大きい1つに2つの小型小包を合併するよりむしろ)に小型小包を送るように差し迫った必要性が全くないということです。 小型小包を合併するためのこの10ms遅れは現在のインターネットのベストエフォート型交通のネットワーク伝播、トランスミッション、および待ち行列遅れによって支配されそうです。 その結果、私たちの判断はパケットの間に10未満msを持つユーザへの利益が過量の小型小包を避けるネットワークへの利益より軽いということでしょう。
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.
Min IntervalはTFRC-SPに非常に頻繁に小型小包を送るアプリケーションを支持させません。 100バイトの固定パケットサイズにもかかわらず、可変送付レートと公正に非充血している経路があるTFRC流動を考えてください。 この流れが100ppsを高々送るとき、それはTFRC-SPを使用できるでしょう。 100以上ppsに送付レートを増加させますが、同じパケットサイズを保つという流れ願望であるなら、もうTFRC-SPと共にこれを達成できないで、デフォルトTFRCに切り替わらなければならないでしょう、許容送付レートの劇的で、不連続な減少を受け取って。 これは許容できるだけではなく、世界的なインターネットに望ましくも思えます。
What is to prevent flows from opening multiple connections, each with a 10 ms Min Interval, thereby getting around the limitation of the Min Interval? Obviously, there is nothing to prevent flows from doing this, just as there is currently nothing to prevent flows from using UDP, or from opening multiple parallel TCP connections, or from using their own congestion control mechanism. Of course, implementations or middleboxes are also free to limit the number of parallel TFRC connections opened to the same destination in times of congestion, if that seems desirable. And flows that open multiple parallel connections are subject to the inconveniences of reordering and the like.
何が、それぞれ10ms Min Intervalと共に流れが複数の接続を開くのを防ぐか、そして、その結果、Min Intervalの限界を迂回することになっていますか? 明らかに、何も流れがこれをするのを防ぐものがありません、ちょうど現在、何も流れを防ぐものがUDPを使用するか、複数の初めの平行なTCP接続、またはそれら自身の混雑制御機構を使用することのでないとき。 もちろん、また、実現かmiddleboxesが無料で混雑の回で同じ目的地に開かれた平行なTFRC接続の数を制限できます、それが望ましく思えるなら。 そして、複数の並列接続を開く流れは再命令と同様のものの不便に被りやすいです。
4.4. Counting Packet Losses
4.4. パケット損失を数えます。
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に関しては、送付レートはすばやく丸い旅行時間あたり1つ未満のパケットまで落とされます。 さらに、タホ、NewReno、またはSACK混雑制御機構があるTCPに関して、混雑への応答は往復の時間単位で落とされたパケットの数から主に独立しています。
Floyd & Kohler Experimental [Page 14] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[14ページ]RFC4828TFRC: SP異形2007年4月
As a result, standard TFRC can best achieve fairness with TCP, even in highly congested environments, by calculating the loss event rate rather than the packet drop rate, where a loss event is one or more packets dropped or marked from a window of data.
その結果、標準のTFRCはTCPと共に公正を最もよく達成できます、パケット低下率よりむしろ損失イベント率について計算するのによる非常に混雑している環境でさえ。そこでは、損失出来事がデータの窓から落とされたか、またはマークされた1つ以上のパケットです。
However, with TFRC-SP, it is no longer possible to achieve fairness with TCP or with standard TFRC by counting only the loss event rate [WBL04]. Instead of sending one large packet per round-trip time, TFRC-SP could be sending N small packets (where N small packets equal one large 1500-byte packet). The loss measurement used with TFRC-SP has to be able to detect a connection that is consistently receiving multiple packet losses or marks per round-trip time, to allow TFRC-SP to respond appropriately.
しかしながら、TFRC-SPでは、TCPか標準のTFRCと共に損失イベント率[WBL04]だけを数えることによって公正を達成するのはもう可能ではありません。 往復の時間あたり1つの大きいパケットを送ることの代わりに、TFRC-SPはN小型小包(N小型小包が1つの大きい1500年のバイトのパケットと等しいところ)を送ることができました。 TFRC-SPと共に使用される損失測定は、往復の時間あたりの一貫して複数のパケット損失を受け取っている接続かマークを検出して、TFRC-SPが適切に応じるのを許容できなければなりません。
In TFRC-SP, the loss event rate is calculated by counting at most one loss event in loss intervals longer than two round-trip times, and by counting each packet lost or marked in shorter loss intervals. In particular, for a short loss interval with N packets, including K lost or marked packets, the loss interval length is calculated as N/K, instead of as N. The average loss interval I_mean is still averaged over the eight most recent loss intervals, as specified in Section 5.4 of RFC 3448. Thus, if eight successive loss intervals are short loss intervals with N packets and K losses, the loss event rate is calculated as K/N, rather than as 1/N.
TFRC-SPでは、損失イベント率は、往復の2回より長い間損失間隔の1回の損失出来事を高々数えて、より短い損失間隔で失われているか、またはマークされた各パケットを数えることによって、計算されます。 パケットであると失われているか、またはマークされたKを含むNパケットがある短い損失間隔の間、特に、損失間隔の長さはN/Kとして計算されます、N. 私がまだ平均されている_が8回の最新の損失間隔の間に意味する海損間隔の代わりに、RFC3448のセクション5.4で指定されるように。 したがって、損失イベント率は8回の連続した損失間隔がNパケットとKの損失を伴う短い損失間隔であるなら、K/Nとして計算されます、むしろ1/Nより。
4.5. The Nominal Packet Size
4.5. 名目上のパケットサイズ
4.5.1. Packet Size and Packet Drop Rates
4.5.1. パケットサイズとパケット低下率
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バイトに設定されると言います、公正の目標を提供して、1秒あたりのバイトで表現される送付レートに関して、1パケットあたりの1460バイトのアプリケーションデータにもかかわらず、同じパケット低下率に従ったTCP流動で。 これは、より小さいセグメントで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レスポンス関数のための近似を考えてください。 これらの環境のために、1RTTあたりのバイトで表現される送付レートはおよそ1.2秒間/のsqrt(p)です、バイトとパケットがsのパケットサイズにレートpを落とすので。
Floyd & Kohler Experimental [Page 15] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[15ページ]RFC4828TFRC: SP異形2007年4月
Given a fixed *byte* drop rate p1, and a TCP packet size of s bytes, the packet drop rate is roughly s*p1, producing a sending rate in bytes per RTT of roughly 1.2 sqrt(s)/sqrt(p1). Thus, for TCP in an environment with a fixed byte drop rate, the sending rate should grow roughly as sqrt(s), for packet drop rates up to 10% or so.
固定*バイト*低下レートp1、およびsバイトのTCPパケットサイズを考えて、パケット低下率はおよそs*p1です、およそ1.2sqrt(s)/sqrt(p1)のRTTあたりのバイトで表現される送付レートを生産して。 したがって、固定バイト低下率がある環境におけるTCPに関して、送付レートはsqrt(s)として手荒く成長するべきです、最大およそ10%のパケット低下率のために。
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.
以下のTable5の各列は、10のTCP接続による別々のシミュレーションと固定バイトが0.0001のレートを落とすのを示します、各シミュレーションが異なったセグメントサイズを使用していて。 各シミュレーションにおいて、TCP送付レートとgoodputは10回の流れの上で平均されています。 人がパラグラフから予想するように、パケットサイズの増加に応じて、上では、TCP送付レートが直線的よりいくらか少なくなります、1460バイトのパケットサイズまで、13%のパケット低下率に対応しています。 その後に、*のパケットサイズ結果のさらなる増加はTCP送付レートにおける*を減少させます、TCP接続が再送信タイマの指数のbackoffの政権に入るとき。
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
セグメントパケットTCPは(B) (キロビット毎秒)サイズDropRate SendRate Goodputを評定します。-------- -------- -------- ------- 14 0.005 6.37 6.34 128 0.016 30.78 30.30 256 0.028 46.54 44.96 512 0.053 62.43 58.37 1460 0.134 94.15 80.02 4000 0.324 35.20 21.44 8000 0.531 15.36 5.76
Table 5: TCP Median Send Rate vs. Packet Size I:
Byte Drop Rate 0.0001
テーブル5: TCPメディアンはパケットサイズIに従ったレートを送ります: バイトはレート0.0001を落とします。
Table 6 below shows similar results for a byte drop rate of 0.001. In this case, the TCP sending rate grows with increasing packet size up to a packet size of 128 bytes, corresponding to a packet drop rate of 16%. After that, the TCP sending rate decreases and then increases again, as the TCP connection enters the regime of exponential backoff of the retransmit timer. Note that with this byte drop rate, with packet sizes of 4000 and 8000 bytes, the TCP sending rate increases but the TCP goodput rate remains essentially zero. This makes sense, as almost all packets that are sent are dropped.
テーブル6 ショーの下に、1バイト同様の結果は0.001のレートを落とします。 この場合、128バイトのパケットサイズまでの増加するパケットサイズに応じて、TCP送付レートは成長します、16%のパケット低下率に対応しています。 TCP送付レートは、その後に減少して、次に、再び増加します、TCP接続が再送信タイマの指数のbackoffの政権に入るとき。 このバイト低下率、4000と8000バイトのパケットサイズに従って、TCP送付レートが増加しますが、TCP goodputレートが本質的にはゼロのままで残っていることに注意してください。 送られるほとんどすべてのパケットが落とされるのに従って、これは理解できます。
Floyd & Kohler Experimental [Page 16] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[16ページ]RFC4828TFRC: SP異形2007年4月
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
セグメントパケットTCPは(B) (キロビット毎秒)サイズDropRate SendRate Goodputを評定します。-------- -------- -------- ------- 14 0.053 1.68 1.56 128 0.159 7.66 6.13 256 0.248 6.21 4.32 512 0.402 1.84 1.11 1460 0.712 1.87 0.47 4000 0.870 3.20 0.00 8000 0.890 5.76 0.00
Table 6: TCP Median Send Rate vs. Packet Size II:
Byte Drop Rate 0.001
テーブル6: TCPメディアンはパケットサイズIIに従ったレートを送ります: バイトはレート0.001を落とします。
The TCP behavior in the presence of a fixed byte drop rate suggests that instead of the goal of a TFRC-SP flow achieving the same sending rate in bytes per second as a TCP flow using 1500-byte packets, it makes more sense to consider an ideal goal of a TFRC-SP flow achieving the same sending rate as a TCP flow with the optimal packet size, given that the packet size is at most 1500 bytes. This does not mean that we need to change the TFRC-SP mechanisms for computing the allowed transmit rate; this means simply that in evaluating the fairness of TFRC-SP, we should consider fairness relative to the TCP flow using the optimal packet size (though still at most 1500 bytes) for that environment.
固定バイト低下率があるときTCPの振舞いは、1500年のバイトのパケットを使用しながらTCP流動として1秒あたりのバイトで同じ送付レートを実現するTFRC-SP流動の目標の代わりに同じ送付レートを実現するTFRC-SP流動の理想的な目標を最適のパケットサイズに従ったTCP流動と考えるより多くの意味になるのを示します、パケットサイズが高々1500バイトであるなら。 これは私たちが許容を計算するためのメカニズムが伝えるTFRC-SPを変えるために必要とするどんな平均にもレートをしません。 これはTFRC-SPの公正を評価する際に単にそれを意味して、私たちは、その環境に、最適のパケットサイズ(もっとも、それでも、高々1500バイト)を使用することでTCP流動に比例して公正を考えるべきです。
4.5.2. Fragmentation and the Path MTU
4.5.2. 断片化と経路MTU
This document doesn't specify TFRC-SP behavior in terms of packet fragmentation and Path MTU Discovery (PMTUD). That is, should the transport protocol using TFRC-SP use PMTUD information to set an upper bound on the segment size? Should the transport protocol allow packets to be fragmented in the network? We leave these as questions for the transport protocol. As an example, we note that DCCP requires that endpoints keep track of the current PMTU, and says that fragmentation should not be the default (Section 14 of [RFC4340]).
このドキュメントはパケット断片化とPath MTUディスカバリー(PMTUD)に関してTFRC-SPの振舞いを指定しません。 TFRC-SPを使用するトランスポート・プロトコルがセグメントサイズに上限をけしかけるのにPMTUD情報を使用するなら、それはそうですか? トランスポート・プロトコルで、パケットはネットワークで断片化するはずですか? 輸送のための質問が議定書を作るのに従って、私たちはこれらを残します。 例として、私たちは、DCCPが、終点が現在のPMTUの動向をおさえるのが必要であり、断片化がデフォルトであるべきでない([RFC4340]のセクション14)と言うことに注意します。
4.5.3. The Nominal Segment Size and the Path MTU
4.5.3. 名目上のセグメントサイズと経路MTU
When TFRC-SP is used with a nominal segment size s of 1460 bytes on a path where the TCP MSS is in fact only 536 bytes, the TFRC-SP flow could receive almost three times the bandwidth, in bytes per second, as that of a TCP flow using an MSS of 536 bytes. Similarly, in an environment with an MSS close to 4000 bytes, a TCP flow could receive almost three times the bandwidth of a TFRC-SP flow with its nominal segment size s of 1460 bytes. In both cases, we feel that these levels of "unfairness" with factors of two or three are acceptable; in particular, they won't result in one flow grabbing all of the
TFRC-SPが事実上TCP MSSが536バイトであるにすぎない経路の1460バイトの名目上のセグメントサイズsと共に使用されるとき、TFRC-SP流動は帯域幅のおよそ3倍受信されることができました、1秒あたりのバイトで、536バイトのMSSを使用するTCP流動のものとして。 同様に、MSSがある環境で、1460バイトの名目上のセグメントサイズsに従ったTFRC-SP流動帯域幅のおよそ3倍は4000バイト、流れが受けることができたTCPに休んでいます。 どちらの場合も、私たちは、2か3の要素がある「不公平」のこれらのレベルが許容していると感じます。 特に、それらはすべてをつかむある流れように結果にならないでしょう。
Floyd & Kohler Experimental [Page 17] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[17ページ]RFC4828TFRC: SP異形2007年4月
available bandwidth, to the exclusion of the competing TCP or TFRC-SP flow.
競争しているTCPかTFRC-SP流動を除外した利用可能な帯域幅。
All IPv4 *end hosts* are required to accept and reassemble IP packets of size 576 bytes [RFC791], but IPv4 *links* do not necessarily have to support this packet size. In slow networks, the largest possible packet may take a considerable amount of time to send [RFC3819], and a smaller MTU may be desirable, e.g., hundreds of bytes. If the first-hop link had a small MTU, then TCP would choose an appropriately small MSS [RFC879]. [RFC1144] quotes cases of very low link speeds where the MSS may be tens of bytes (and notes this is an extreme case). We note that if TFRC-SP is used over a path with an MTU considerably smaller than 576 bytes, and the TFRC-SP flow uses a nominal segment size s of 1460 bytes, then the TFRC-SP flow could receive considerably more than three times the bandwidth of competing TCP flows.
すべてのIPv4*終わりのホスト*が576バイト[RFC791]のサイズのIPパケットを受け入れて、組み立て直すのに必要です、しかし、IPv4*リンク*は必ずこのパケットサイズを支持する必要はありません。 遅いネットワークでは、可能な限り大きいパケットは発信する[RFC3819]にはかなりの時かかるかもしれません、そして、より小さいMTUは望ましいかもしれません、例えば、何百バイト。 最初に、ホップリンクに小さいMTUがあるなら、TCPは適切に小さいMSS[RFC879]を選ぶでしょうに。 [RFC1144]はMSSが何十バイトであるかもしれない(そして、これが極端なそうであることに注意する)非常に低いリンク速度に関するケースを引用します。 私たちは、MTUが576バイトよりかなり小さい状態でTFRC-SPが経路の上で使用されて、TFRC-SP流動が1460バイトの名目上のセグメントサイズsを使用するならTFRC-SP流動が競争しているTCPの帯域幅の3倍が流れるよりさらにかなり受信されるかもしれないことに注意します。
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では、これが1460バイトのデフォルトの名目上のセグメントサイズを使用することでTFRC-SP流動をもたらすかもしれないでしょうに、そして、その結果競争するよりかなり多くの帯域幅を受けて、TCPは流れます。 その結果、TFRC-SPは使用のために経路MTUに関する何らかの知識を維持しないトランスポート・プロトコルで推薦されません。
4.6. The Loss Interval Length for Short Loss Intervals
4.6. 短い損失間隔の間の損失間隔の長さ
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受信機に関しては、RFC3448のセクション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回より長い場合にだけ海損間隔の計算に当期損失間隔を含むことができると指定します。
Floyd & Kohler Experimental [Page 18] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[18ページ]RFC4828TFRC: SP異形2007年4月
5. A Comparison with RFC 3714
5. RFC3714との比較
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.
RFC3714は混雑しているベストエフォート型ネットワークの上に非混雑が制御されたIP電話技術の展開で起こるかもしれない公正の問題、潜在的混雑崩壊、および劣ったユーザ品質を考えます。 2004年3月のドキュメントはTFRCとDCCPへの作業を含むIETFで進行中の努力を引用します。 RFC3714は、アプリケーションかトランスポート・プロトコルが、修理されたか最小の送付レートを持っているアプリケーションによる最も良い努力交通として、パケット低下率をモニターして、定常状態パケット低下率がその最小の送付レートのために許容敷居をかなり超えているならしばらく発信するのを中止するべきであることを勧めます。
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%.
固定送付レートの許容パケット低下率を測定する際に、RFC3714は、IP電話技術流動がIP電話技術流動のものと同じパケット低下率になる1500年のバイトのパケットTCP流動として1秒あたりのバイトで同じ送付レートを使用できるべきであると仮定します。 例として、このガイドライン、0.1秒の往復の時間とのVoIP関係、および64の最小の送付レートにしつこいパケット低下率であるときにKbpsが終えなければならないか、または中断させていなければならないだろう従うと、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.
RFC3714で説明された最小量のメカニズムにおける、きめ細かに粒状のコントロールの不足の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.
RFC3714が、送付レートに従ってIP電話技術流動の許容パケット低下速度がTCP流動が同じパケット低下率*と共に*を使用することを決定していると仮定するので、RFC3714の最小量のメカニズムは小型小包が大きいパケットほど落とされそうにない環境でTCPとIP電話技術交通の間に公正を供給しないでしょう。 そのような環境で、小さいパケットIP電話技術流動は大きいパケットTCP流動が同じパケット低下率にIP電話技術流動を受け取るだろうという楽観的な想定をするでしょう、そして、その結果、小型小包IP電話技術流動はリンク帯域幅の競争している大きいパケットTCP流動より大きい部分を受けるでしょう。
6. TFRC-SP with Applications that Modify the Packet Size
6. ApplicationsそのModify Packet SizeとTFRC-SP
One possible use for TFRC-SP would be with applications that maintain a fixed sending rate in packets per second, but modify their packet size in response to congestion. TFRC-SP monitors the connection's packet drop rate, and determines the allowed sending rate in bytes per second. Given an application with a fixed sending rate in
TFRC-SPの1つの活用可能性が1秒あたりのパケットで固定送付レートを維持するアプリケーションであるでしょうが、混雑に対応してそれらのパケットサイズを変更してください。 TFRC-SPは接続のパケット低下率をモニターして、1秒あたりのバイトで表現される許容送付レートを測定します。 中に固定送付レートがある状態で、アプリケーションを与えました。
Floyd & Kohler Experimental [Page 19] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[19ページ]RFC4828TFRC: SP異形2007年4月
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.
1秒あたりのパケット、TFRC-SP送付者は1秒あたりのバイトで表現される送付レートが許容送付レートを超えないように必要であるデータ・パケットサイズを決定できました。 また、パケット低下率がパケットサイズで影響を受ける環境で、パケットサイズを減少させると、流れによって経験されたパケット低下率の減少はもたらされるかもしれません。
There are many questions about how an adaptive application would use TFRC-SP that are beyond the scope of this document. In particular, an application might wish to avoid unnecessary reductions in the packet size. In this case, an application might wait for some period of time before reducing the packet size, to avoid an unnecessary reduction in the packet size. The details of how long an application might wait before reducing the packet size can be addressed in documents that are more application-specific.
適応型のアプリケーションがどうこのドキュメントの範囲にある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の許容送付レートがパケットでというよりむしろ秒あたりのバイトで2番目に、そして、そこ単位であるので、アプリケーションが「勝負事をする」ためにパケットサイズを操る少ない機会がシステムですか? これはCCID3([RFC4342]のセクション5.3)でTFRCと異なっています。そこに、許容送付レートが1秒あたりのパケットにあります。 特に、速い送付レートを確立して、しばらく小型小包を送って、次に大きいパケットに切り替わるTFRC-SPアプリケーションはパケットサイズの変化で総合的な送付レートを増加させないでしょう。
7. Simulations
7. シミュレーション
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の性能について説明します。 Appendix Bで詳細に説明されたシミュレーションは標準のTFRCが小型小包流れに関するスループットをかなり制限する環境について調査します、そして、TFRC-SPは必要なスループットを与えます。 また、シミュレーションは標準のTFRCが小型小包流れに望ましい市場成果を受け取らせる環境について調査しますが、TFRC-SPはひどく攻撃的です。
Floyd & Kohler Experimental [Page 20] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[20ページ]RFC4828TFRC: SP異形2007年4月
The general lessons from the simulations are as follows.
シミュレーションからの一般的な教訓は以下の通りです。
o In scenarios where large and small packets receive similar packet
drop rates, TFRC-SP gives roughly the desired sending rate
(Appendix B.1, B.2).
o 大きくて小さいパケットが同様のパケット低下率を受けるシナリオでは、TFRC-SPはおよそ必要な送付レート(付録B.1、B.2)を与えます。
o In scenarios where each *byte* is equally likely to be dropped,
standard TFRC gives reasonable fairness between small-packet TFRC
flows and large-packet TCP flows (Appendix B.2).
o それぞれの*バイト*が等しく落とされそうであるシナリオでは、標準のTFRCは小型小包TFRC流れの間に妥当な公正を与えます、そして、大きいパケットTCPは流れます(付録B.2)。
o In scenarios where small packets are less likely to be dropped
than large packets, TFRC-SP does not give reasonable fairness
between small-packet TFRC-SP flows and large-packet TCP flows;
small-packet TFRC-SP flows can receive considerably more bandwidth
than competing large-packet TCP flows, and in some cases large-
packet TCP flows can be essentially starved by competing small-
packet TFRC-SP flows (Appendix B.2, B.3, B.4).
o 小型小包が大きいパケットほど落とされそうにないシナリオでは、TFRC-SPは小型小包TFRC-SP流れの間に妥当な公正を与えません、そして、大きいパケットTCPは流れます。 小型小包TFRC-SP流れは競争している大きいパケットTCP流れよりかなり多くの帯域幅を受けることができます、そして、競争している小さいパケットTFRC-SP流れ(付録B.2、B.3、B.4)でいくつかの場合大きいパケットTCP流れは本質的には飢えさせられることができます。
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)にバイトにおけるDrop-テール待ち行列、およびAQMメカニズムがあるそれらを含んでいます。 また、無線のリンクが時々小型小包を通すことができるくらい良いと報告されました、より大きいパケットは、はるかに高い誤り率を持っていて、したがって、より高い低下確率[S05]を持っていますが。
8. General Discussion
8. 一般議論
Dropping rates for small packets: The goal of TFRC-SP is for small- packet TFRC-SP flows to have rough fairness with large-packet TCP flows in the sending rate in bps, in a scenario where each packet receives roughly the same probability of being dropped. In a scenario where large packets are more likely to be dropped than small packets, or where flows with a bursty sending rate are more likely to have packets dropped than are flows with a smooth sending rate, small-packet TFRC-SP flows can receive significantly more bandwidth than competing large-packet TCP flows.
低下は小型小包のために評価します: TFRC-SPの目標は小さいパケットTFRC-SP流れがビーピーエスで送付レートにおける大きいパケットTCP流れに伴う乱暴な公正を持つことです、各パケットが落とされるというおよそ同じ確率を受けるシナリオで。 大きいパケットが小型小包より落とされそうであるか、またはbursty送付レートに従った流れが滑らかな送付レートに従った流れよりパケットが落とされそうで小型小包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
TFRCで使用されるTCPレスポンス関数の精度: パケット低下率がかなり高いときにだけ、96Kbps(すなわち、高々120バイトのパケット)の最大の送付レートがあるアプリケーションのために、TFRC-SPは送付レートを制限します、例えば、10%以上。 [派生: 200のmsの往復の時間と128Kbpsのパケットのヘッダーがいる最大の送付レートに従ったTFRC-SP流動には、送付レートが1460バイトセグメントが往復の時間あたり2.2のパケットを送るTCP流動と2番目の同等物あたりのバイトであるでしょう。 RFC3714のTable1から、パケット低下率でこの送付レートをわずかに10%以上支えることができます。] この高パケット滴の政権では、TFRC-SPの性能が精度で一部決定しています。
Floyd & Kohler Experimental [Page 21] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[21ページ]RFC4828TFRC: SP異形2007年4月
the TCP response function in representing the actual sending rate of a TCP connection.
TCP接続の実際の送付速度を表すことにおけるTCPレスポンス関数。
In the regime of high packet drop rates, TCP performance is also affected by the TCP algorithm (e.g., SACK or not), the minimum RTO, the use of Limited Transmit (or lack thereof), the use of ECN, and the like. It is good to ensure that simulations or experiments exploring fairness include the exploration of fairness with the most aggressive TCP mechanisms conformant with the current standards. Our simulations use SACK TCP with Limited Transmit and with a minimum RTO of 200 ms. The simulation results are largely the same with or without timestamps; timestamps were not used for simulations reported in this paper. We didn't use TCP with ECN in setting the target sending rate for TFRC, because, as explained in Appendix B.1, our expectation is that in high packet drop regimes, routers will drop rather than mark packets, either from policy or from buffer overflow.
また、高いパケット低下率の政権では、TCP性能がTCPアルゴリズム(例えば、SACKであるか否かに関係なく)、最小のRTO、株式会社Transmit(または、それの不足)の使用、電子証券取引ネットワークの使用、および同様のもので影響を受けます。 公正について調査するシミュレーションか実験が現在の規格で最も攻撃的なTCPメカニズムconformantとの公正の探検を含んでいるのを保証するのは良いです。 私たちのシミュレーションは株式会社TransmitとSACK TCPを使用します、そして、200原稿の最小のRTOと共に、シミュレーションの結果はタイムスタンプのあるなしにかかわらず主に同じです。 タイムスタンプはこの紙で報告されたシミュレーションに使用されませんでした。 私たちはTFRCの目標送付レートを設定する際に電子証券取引ネットワークがあるTCPを使用しませんでした、私たちの期待がAppendix B.1で説明されるように高いパケット低下政権では、ルータが方針かバッファオーバーフローからパケットをマークするよりむしろ落とすということであるので。
Fairness with different packet header sizes: In an environment with IPv6 and/or several layers of network-layer tunnels (e.g., IPsec, Generic Routing Encapsulation (GRE)), the packet header could be 60, 80, or 100 bytes instead of the default 40 bytes assumed in Section 3. For an application with small ten-byte data segments, this means that the actual packet size could be 70, 90, or 110 bytes, instead of the 50 bytes assumed by TFRC-SP in calculating the allowed sending rate. Thus, a TFRC-SP application with large headers could receive more than twice the bandwidth (including the bandwidth used by headers) than a TFRC-SP application with small headers. We do not expect this to be a problem; in particular, TFRC-SP applications with large headers will not significantly degrade the performance of competing TCP applications, or of competing TFRC-SP applications with small headers.
異なったパケットのヘッダーがいる公正は以下を大きさで分けます。 IPv6、そして/または、数個の層のネットワーク層トンネル(例えば、IPsec、Genericルート設定Encapsulation(GRE))がある環境で、40バイトがセクション3で仮定したデフォルトの代わりに、パケットのヘッダーは、60、80、または100バイトであるかもしれません。 小さい10バイトのデータ・セグメントがあるアプリケーションのために、これは、実際のパケットサイズが70バイトか90バイトか110バイトであるかもしれないことを意味します、許容送付レートについて計算する際にTFRC-SPによって想定された50バイトの代わりに。 したがって、大きいヘッダーによるTFRC-SPアプリケーションは小さいヘッダーによるTFRC-SPアプリケーションより帯域幅(ヘッダーによって使用された帯域幅を含んでいる)の2倍より受信されることができました。 私たちは、これが問題であると予想しません。 特に、大きいヘッダーによるTFRC-SPアプリケーションは小さいヘッダーと共に競争しているTCPアプリケーション、または競争しているTFRC-SPアプリケーションの性能をかなり下げないでしょう。
General issues for TFRC: The congestion control mechanisms in TFRC and TFRC-SP limit a flow's sending rate in packets per second. Simulations by Tom Phelan [P04] explore how such a limitation in sending rate can lead to unfairness for the TFRC flow in some scenarios, e.g., when competing with bursty TCP web traffic, in scenarios with low levels of statistical multiplexing at the congested link.
TFRCのための一般答弁: TFRCの輻輳制御メカニズムと流れが送るTFRC-SP限界は1秒あたりのパケットで評価します。 例えば、bursty TCPウェブ・トラフィックと競争するとき、トムフェラン[P04]によるシミュレーションはいくつかのシナリオにおけるTFRC流動のために送付レートにおけるそのような制限がどう不公平に通じることができるかを探検します、低レベルの統計的多重化が混雑しているリンクにあるシナリオで。
9. Security Considerations
9. セキュリティ問題
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とTFRC-SPとさまざまな環境におけるTCPの公正の問題について議論します。
Floyd & Kohler Experimental [Page 22] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[22ページ]RFC4828TFRC: SP異形2007年4月
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
RFC3448でTFRCのための総合証券問題について議論します。 RFC3448のTFRCのように、TFRC-SPはそれ自身の権利におけるトランスポート・プロトコルではなく、トランスポート・プロトコルに関連して使用されることを意図する混雑制御機構です。 したがって、セキュリティは、主として特定のトランスポート・プロトコルとその認証機構の文脈で考えられる必要があります。RFC3448のTFRCのために議論するように、TFRC-SPを使用するどんなトランスポート・プロトコルも、だまされたフィードバックから守って、不正確な情報に対して受信機から混雑制御機構を保護する必要があります; RFC3448のTFRCのために再び議論するように、私たちは、TFRC-SPと共に電子証券取引ネットワークを法人組織にするプロトコルが著しいパケットの偶然の、または、悪意がある隠すことから送付者を保護するのに電子証券取引ネットワークの一回だけの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のCongestion Control ID3のためのセキュリティ問題、[RFC4342]でTFRC Congestion Control(TFRCを使用するトランスポート・プロトコル)について議論します。 そのドキュメントは手広く送付者が受信機によって送られた情報について確かめるのに使用できるメカニズムについて議論しました、電子証券取引ネットワーク一回だけの使用を含んでいて。
10. Conclusions
10. 結論
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のSmall-パケット(SP)異形、高々100のパケットがある1秒あたりの小型小包に発信しますが、同じパケット低下率を経験するTCP接続としてビーピーエスで同じ送付レートを望んでいるアプリケーションのために設計されていますが、1500バイトのパケットを送って。 TFRC-SPが合理的に大きいパケットTCPとよく競争して、TFRCは大きいパケット流れと小型小包流れが同様のパケット低下率になる環境で流れますが、環境におけるビーピーエスにおける帯域幅のシェアより小型小包が落とされそうにはありませんし、大きいパケットほどマークされそうにないところで受信します。 その結果、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.
データグラムCongestion Controlプロトコル(DCCP)のTFRC-SPと共に実験を許すために、実験的なCongestion Control IDentifier(CCID)は使用されますが、TFRC-SPに基づいていますが、別々のドキュメントで指定されるでしょう。
Floyd & Kohler Experimental [Page 23] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[23ページ]RFC4828TFRC: SP異形2007年4月
11. Acknowledgements
11. 承認
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.
私たちは、TCPとTFRC-SPの間の公正が流れるのをTFRC-SPの議論と彼の紙の探検のためのトムフェランに感謝します。 私たちはこのドキュメントの以前のバージョンのフィードバックについてラース・エッゲルト、ゴーリーFairhurst、マーク・ハンドレー、ミゲル・ガルシア、Ladan Gharai、リチャード・ネルソン、コリン・パーキンス、ユルゲンQuittek、ピートSholander、マグヌスWesterlund、およびヨルク・ウィトマーに感謝します。 また、私たちはフィードバックと議論についてDCCP作業部会に感謝します。
Floyd & Kohler Experimental [Page 24] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[24ページ]RFC4828TFRC: SP異形2007年4月
Appendix A. Related Work on Small-Packet Variants of TFRC
付録A.はTFRCの小型小包異形に対する仕事を関係づけました。
Other proposals for variants of TFRC for applications with variable packet sizes include [WBL04] and [V00]. [V00] proposed that TFRC should be modified so that flows are not penalized by sending smaller packets. In particular, [V00] proposes using the path MTU in the TCP-friendly equation, instead of the actual packet size used by TFRC, and counting the packet drop rate by using an estimation algorithm that aggregates both packet drops and received packets into MTU-sized units.
可変パケットサイズがあるアプリケーションのためのTFRCの異形のための他の提案は[WBL04]と[V00]を含んでいます。 [V00]が、TFRCが変更されるべきであるよう提案したので、流れは送付の、より小さいパケットによって罰せられません。 特に、[V00]は、TCPに優しい方程式で経路MTUを使用するよう提案します、パケット滴と容認されたパケットの両方に集められる見積りアルゴリズムをMTUサイズの単位に使用することによってTFRCによって使用されて、パケット低下率を数える実際のパケットサイズの代わりに。
[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異形はほとんどの1秒あたり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]は損失測定の過程、「「非-バイアス」」、「仮想のパケット」、「無作為抽出法」、および「損失Insensitive Period(LIP)スケーリング」を変更するための4つの方法について議論します。 ネットワークがパケットサイズの如何にかかわらずパケットを落とすとき、[WBL04]は、2番目と3番目の方法だけが十分強健であることがわかります。 ネットワークが小型小包より大きいパケットを落としそうなとき、彼らは、2番目の方法だけが十分強健であることがわかります。 損失イベント率について計算するための私たちの方法は[WBL04]で提案された無作為抽出法方法といくらか同様です、無作為化が使用されていないのを除いて。 無作為化の代わりに、正確なパケット損失率は短い損失間隔の間、計算されます、そして、標準の損失イベントレート計算は、より長い損失間隔の間、使用されます。 [WBL04]はベルヌーイ損失モデル、低下率が時間がたつにつれて異なるベルヌーイ損失モデル、およびギルバート損失モデルによるシミュレーションを含んでいます、TCPの1つの範囲がある、より現実的なシミュレーションとTFRC流れと同様に。
[WBL04] produces both a byte-mode and a packet-mode variant of the TFRC transport protocol, for connections over paths with per-byte and per-packet dropping respectively. We would argue that in the absence of transport-level mechanisms for determining whether the packet dropping in the network is per-packet, per-byte, or somewhere in between, a single TFRC implementation is needed, independently of the
[WBL04]は、それぞれ低下しながら、バイトモードとバイトがある経路の上の関係とパケットあたりのTFRCトランスポート・プロトコルのパケット形態異形の両方を生産します。 私たちはネットワークをちょっと立ち寄らせるパケットがパケットであるかどうか決定するための輸送レベルメカニズムがないときそれについて論争するでしょう、1バイト単位で、または、どこかで中間で、ただ一つのTFRC実現が独自に必要です。
Floyd & Kohler Experimental [Page 25] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[25ページ]RFC4828TFRC: SP異形2007年4月
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).
経路に沿ったルータのパケットが低下する振舞い。 そして、全体で接続と、そして、ネットワークにおよそ許容できる振舞いを与えるメカニズムを持っているのはもちろん望ましいでしょう、バイトとパケットあたりの低下がある経路で(間に、どこかに1バイト単位であるメカニズムを落とす複数の混雑しているルータがある経路、1バイトあたりの滴下メカニズムがあるいくつか、1パケットあたりの滴下メカニズムがあるいくつか、およびいくつか、-、パケット)
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はNSシミュレータに加えられます、そして、合法化がテストするイラスト入りのコネは/試しにオール味方である」というtcl/テスト。 シミュレーションのためのシミュレーションスクリプトとグラフは[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はタイムスタンプと電子証券取引ネットワークであふれます、そして、TFRC-SPは流れます、そして、標準のTFRC(Stnd TFRC)は流れます。 これらのシミュレーションで、私たちは指定された速度で手当たりしだいにパケットを低下するか、またはマークするためにルータを構成します、パケットサイズの如何にかかわらず。 それぞれの指定されたパケット低下率のために、私たちは10回の流れの上で平均された100秒のシミュレーションの後半の間、Kbpsで流れの平均した送付レートを与えます。
Floyd & Kohler Experimental [Page 26] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[26ページ]RFC4828TFRC: SP異形2007年4月
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
パケットSend Rates(キロビット毎秒、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%であるときに、ルータがパケットをマークすることが勧められないとき。
Table 7: Send Rate vs. Packet Drop Rate I:
1460B TFRC Segments
(1.184 Kbps Maximum TFRC Data Sending Rate)
テーブル7: パケット低下率Iに従ったレートを送ってください: 1460B TFRCセグメント(1.184のキロビット毎秒の最大のTFRCデータ送付速度)
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流動は、1秒あたり100のパケットを高々送るために構成されます。 パケット低下割合が40と50%に達するまで、良い相対的な公正があります、TFRC流動が標準のTCP流動より3〜5倍多くの帯域幅を受けるとき。 私たちは、ECN TCP流動がこれらの高いパケット低下率でTFRC流動より高いスループットを受け取ることに注意します、それでも、電子証券取引ネットワーク-マークがパケット低下の代わりに中古の存在であったなら。 しかしながら、私たちはTFRCの目標送付レートとしてこれらの高パケット滴のシナリオでECN TCP送付レートを使用しません、ルータが高いレベルの混雑([RFC3168]のセクション7)の間、マークするよりむしろパケットを落とすように教えられるとき。 さらに、レートを低下するか、またはそのような高いパケットがマークしているシナリオにおけるバッファオーバーフローがありそうです、電子証券取引ネットワークをマークするそれらの代わりにパケットがルータが落とされて。
Floyd & Kohler Experimental [Page 27] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[27ページ]RFC4828TFRC: SP異形2007年4月
< - - - - - - 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
<------------Rates(キロビット毎秒)を送ってください--、--、--、--、--、>Packet TCP電子証券取引ネットワーク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%であるときに、ルータがパケットをマークすることが勧められないとき。
Table 8: Send Rate vs. Packet Drop Rate II:
14B TFRC Segments
(5.6 Kbps Maximum TFRC Data Sending Rate)
テーブル8: パケット低下率IIに従ったレートを送ってください: 14B TFRCセグメント(5.6のキロビット毎秒の最大のTFRCデータ送付速度)
Table 8 shows the results of simulations where each TFRC-SP flow has a maximum data sending rate of 5.6 Kbps, with 14-byte data packets and a 32-byte packet header for DCCP and IP. Each TCP flow has a receive window of 100 packets and a data packet size of 1460 bytes, with a 40-byte packet header for TCP and IP. The TCP flow uses SACK TCP with Limited Transmit, but without timestamps or ECN. Each flow has a round-trip time of 240 ms in the absence of queueing delay.
テーブル8は、それぞれのTFRC-SP流動がどこに5.6Kbpsの最大のデータ送付速度を持っているかをシミュレーションの結果に示します、DCCPのための14バイトのデータ・パケットと32バイトのパケットのヘッダーとIPと共に。 aはそれぞれのTCP流動で100のパケットの窓と1460バイトのデータ・パケットサイズを受けます、TCPのための40バイトのパケットのヘッダーとIPと共に。 TCP流動は株式会社Transmitにもかかわらず、タイムスタンプも電子証券取引ネットワークなしでSACK TCPを使用します。 各流れは待ち行列遅れがないとき240msの往復の時間を過します。
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.
Table8の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.6Kbpsに関して、Standard TFRC(Stnd TFRC)がビーピーエスで非常に低い送付レートを与えるのを示します、大きいパケットTCP接続の送付速度に比例して。 対照的に、TFRC-SP流動の送付速度がTCPと共にビーピーエスにおける公正の望んでいる目標の比較的近くにあります。
Floyd & Kohler Experimental [Page 28] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[28ページ]RFC4828TFRC: SP異形2007年4月
Table 8 shows that with TFRC-SP, the 5.6 Kbps data stream doesn't reduce its sending rate until packet drop rates are greater than 20%, as desired. With packet drop rates of 30-40%, the sending rate for the TFRC-SP flow is somewhat less than that of the average large- packet TCP flow, while for packet drop rates of 50% the sending rate for the TFRC-SP flow is somewhat greater than that of the average large- packet TCP flow.
テーブル8は、TFRC-SPと共に、データが流す5.6Kbpsが、パケット低下率が20%以上になるまでレートを送るのを減少させないのを示します、望まれているように。 30-40%のパケット低下率と共に、TFRC-SP流動の送付速度がTFRC-SP流動の送付速度が50%のパケット低下率にいくらかすばらしい間の平均した大きいパケット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
<------------Rates(キロビット毎秒)を送ってください--、--、--、--、--、>Packet TCP電子証券取引ネットワーク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%であるときに、ルータがパケットをマークすることが勧められないとき。
Table 9: Sending Rate vs. Packet Drop Rate III:
200B TFRC Segments
(160 Kbps Maximum TFRC Data Sending Rate)
テーブル9: パケット低下率IIIに従った送付レート: 200B TFRCセグメント(160のキロビット毎秒の最大のTFRCデータ送付速度)
Table 9 shows results with configured packet drop rates when the TFRC flow uses 200-byte data packets, with a maximum data sending rate of 160 Kbps. As in Table 8, the performance of Standard TFRC is quite poor, while the performance of TFRC-SP is essentially as desired for packet drop rates up to 30%. Again as expected, with packet drop rates of 40-50% the TFRC-SP sending rate is somewhat higher than desired.
テーブル9は、TFRC流動がいつ200バイトのデータ・パケットを使用するかを構成されたパケット低下率がある結果に示します、160Kbpsの最大のデータ送付速度で。 Table8のように、Standard TFRCの性能はかなり不十分です、TFRC-SPの性能が最大30%のパケット低下率のために望まれているように本質的にはそうですが。 再び予想される40-50%のパケット低下率で、TFRC-SP送付レートは望まれているよりいくらか高いです。
For these simulations, the sending rate of a TCP connection using timestamps is similar to the sending rate shown for a standard TCP connection without timestamps.
これらのシミュレーションにおいて、タイムスタンプを使用しているTCP接続の送付速度は標準のTCP接続のためにタイムスタンプなしで示された送付レートと同様です。
Floyd & Kohler Experimental [Page 29] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[29ページ]RFC4828TFRC: SP異形2007年4月
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).
このセクションでは、私たちはルータが指定された速度で各*がバイト*であると低下するか、またはマークするために構成されるシミュレーションを探ります。 1バイトが落とされる(または、マークされる)ために選ばれているとき、そのバイトを含む全体のパケットは落とされます(または、マークされます)。
< - - - - - 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
<----------Rates(キロビット毎秒)を送ってください--、--、--、--、--、>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%であるときに、ルータがパケットをマークすることが勧められないとき。
TFRC's maximum data sending rate is 5.6 Kbps.
TFRCの最大のデータ送付速度は5.6Kbpsです。
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が様々なバイト低下率のレートを送るのを示します。 それぞれのバイト低下率のために、Table10はTCP送付レートを示しています、電子証券取引ネットワークのあるなしにかかわらず、最も高いTCP送付レートを与えるTCPセグメントサイズのために。 シミュレーションは14、128、256、512、および1460バイトのTCPセグメントで走りました。 したがって、0.00001のバイト低下率のために、テーブルは、1460年のバイトのデータ・セグメントにもかかわらず、0.001のバイト低下率で、テーブルが128バイトのデータ・セグメントでTCP送付レートを示すのをTCP送付レートに示します。 TFRC-SPとStandard TFRCがレートを送るのを各バイトには、レートを落としてください、そして、また、Table10は、示します。 構成されたバイト低下率で、TFRC-SPはTFRC-SP流動の不正な利益を与えます、Standard TFRCが本質的には必要なパフォーマンスを行いますが。
Floyd & Kohler Experimental [Page 30] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[30ページ]RFC4828TFRC: SP異形2007年4月
TCP Pkt TFRC Pkt
Byte DropRate DropRate TCP/TFRC
DropRate (1460B seg) (14B seg) Pkt Drop Ratio
-------- ----------- --------- --------------
0.00001 0.015 0.0006 26.59
0.0001 0.13 0.0056 24.94
0.001 0.77 0.054 14.26
0.005 0.99 0.24 4.08
0.01 1.00 0.43 2.32
0.05 1.00 0.94 1.05
TCP Pkt TFRC Pkt Byte DropRate DropRate TCP/TFRC DropRate(1460B seg)(14B seg)Pkt Drop Ratio-------- ----------- --------- -------------- 0.00001 0.015 0.0006 26.59 0.0001 0.13 0.0056 24.94 0.001 0.77 0.054 14.26 0.005 0.99 0.24 4.08 0.01 1.00 0.43 2.32 0.05 1.00 0.94 1.05
Table 11: Packet Drop Rate Ratio vs. Byte Drop Rate
テーブル11: バイト低下率に従ったパケット低下レート比
Table 11 converts the byte drop rate p to packet drop rates for the TCP and TFRC packets, where the packet drop rate for an N-byte packet is 1-(1-p)^N. Thus, a byte drop rate of 0.001, with each byte being dropped with probability 0.001, converts to a packet drop rate of 0.77, or 77%, for the 1500-byte TCP packets, and a packet drop rate of 0.054, or 5.4%, for the 56-byte TFRC packets.
テーブル11はTCPとTFRCパケットのパケット低下率にバイト低下率pを変換します、N-バイトパケットのパケット低下率が1(1-p)^Nであるところで。 したがって、各バイトが確率0.001で落とされている状態で、1バイト、0.001の低下率は0.77、または77のパケット低下率に1500年のバイトのTCPパケットのための%、および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.
Table11に関する正しいコラムはTCPパケット低下率とTFRCパケット低下率の間の比率を示しています。 低バイト低下率のために、この比率はおよそ26.8、TCPとTFRCパケットサイズの間の比率です。 高いバイト低下率のために、ほとんどの小さいTFRCパケットさえ落とされそうであるところに、この低下比は1にアプローチします。 Table10が、レートを落とすようにバイトで示すとき、最適な近くにStandard TFRC送付レートがあります、許容範囲の中で最適のパケットサイズを使用するTCP接続と公正に競争して。 対照的に、TFRC-SP接続は帯域幅のシェアより多くなります、さらに0.01以上のバイト低下率の送付レートを低下させますが。(TFRC-SP*パケット*に対応するのは0.43のレートを落とします。
Table 10 essentially shows three separate regions. In the low- congestion region, with byte drop rates less than 0.0001, the TFRC-SP connection is sending at its maximum sending rate. In this region the optimal TCP connection is the one with 1460-byte segments, and the TCP sending rate goes as 1/sqrt(p), for packet drop rate p. This low-congestion region holds for packet drop rates up to 10-15%.
テーブル10は本質的には3つの別々の領域を示しています。 低い混雑領域では、0.0001未満のバイト低下率と共に、TFRC-SP接続が最大の送付レートで発信します。 この領域では、最適のTCP接続が1460年のバイトのセグメントがあるものです、そして、TCP送付レートが1/sqrt(p)に仮装して出演します、パケット低下率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
Table10の中央領域では、0.0001〜0.005までのバイト低下率で、最適のTCPセグメントサイズがバイト低下率の関数です。 特に、最適のTCPセグメントサイズはパケット低下率が高々15%であることを保つものであるように思えます、1/sqrt(p)送付レートで政権でのTCP接続を監督しておいて、パケット低下率pのために。 Sバイト(ヘッダーを含んでいる)のTCPパケットサイズ、およびBの*バイト*低下率のために、パケット低下率はおよそB*Sです。 与えられたバイトには、この政権でレートを落としてください、パケットサイズがaを与えるために選ばれている状態で最適のTCP性能が起こるなら
Floyd & Kohler Experimental [Page 31] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[31ページ]RFC4828TFRC: SP異形2007年4月
packet drop rate of at most 15%, keeping the TCP connection out of the regime of exponential backoffs of the retransmit timer, then this requires B*S = 0.15, or S = 0.15/B.
高々15%のパケット低下率、再送信タイマの指数のbackoffsの政権にTCP接続を入れないようにして、次に、これがB*S=0.15を必要とするか、またはSは0.15/Bと等しいです。
In the high-congestion regime of Table 10, with high congestion and with byte drop rates of 0.01 and higher, the TCP performance is dominated by the exponential backoff of the retransmit timer regardless of the segment size. Even a 40-byte packet with a zero- byte data segment would have a packet drop rate of at least 33%. In this regime, the optimal TCP *sending* rate comes with a large, 1460-byte data segment, but the TCP sending rate is low with any segment size, considerably less than one packet per round-trip time.
Table10の高混雑政権、高い混雑、およびバイトで、0.01のレートを落としてください。そうすれば、より高く、TCP性能はセグメントサイズにかかわらず再送信タイマの指数のbackoffによって支配されます。 無バイトデータ・セグメントがある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*送付*レートを与えますが、この政権では、より小さいパケットが、より良い*goodput*レートを与えることに注意します。
In general, Tables 8 and 9 show good performance for TFRC-SP in environments with stable packet drop rates, where the decision to drop a packet is independent of the packet size. However, in some environments the packet size might affect the likelihood that a packet is dropped. For example, with heavy congestion and a Drop Tail queue with a fixed number of bytes rather than a fixed number of packet-sized buffers, small packets might be more likely than large packets to find room at the end of an almost-full queue. As a further complication, in a scenario with Active Queue Management, the AQM mechanism could either be in packet mode, dropping each packet with equal probability, or in byte mode, dropping each byte with equal probability. Sections B.3 and B.4 show simulations with packets dropped at Drop-Tail or AQM queues, rather that from a probabilistic process.
一般に、Tables8と9はTFRC-SPのために安定したパケット低下率がある環境で望ましい市場成果を示しています。そこでは、パケットを落とすという決定がパケットサイズから独立しています。 しかしながら、いくつかの環境で、パケットサイズはパケットが落とされるという見込みに影響するかもしれません。 例えば、定数よりむしろバイトのパケットサイズのバッファの定数がある重い混雑とDrop Tail待ち行列で、小型小包はほとんど完全な待ち行列の終わりに大きいパケットより余地を見つけるかもしれなそうです。 さらなる複雑さとして、Active Queue Managementがあるシナリオには、AQMメカニズムがパケット形態であるかもしれません、等しい確率、またはバイトモードで各パケットを落として、各バイト単位で等しい確率と共に低下して。 セクションのB.3とB.4はパケットがDrop-テールで落とされているシミュレーションか確率的な過程からの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回の流れに関するスループットを比較することに関する問題の1つはパケットサイズ自体がパケット低下率[V00、WBL04]に影響を及ぼすことができるということです。
The default TFRC was designed for rough fairness with TCP, for TFRC and TCP flows with the same packet size and experiencing the same packet drop rate. When the issue of fairness between flows with different packets sizes is addressed, it matters whether the packet drop rates experienced by the flows is related to the packet size. That is, are small packets just as likely to be dropped as large TCP packets, or are the smaller packets less likely to be dropped [WBL04]? And what is the relationship between the packet-dropping behavior of the path, and the loss event measurements of TFRC?
デフォルトTFRCはTCPがある乱暴な公正、同じパケットサイズに従ったTFRCとTCP流れのために設計されて、同じパケット低下率を経験していました。 流れの間の異なったパケットサイズがある公正の問題が記述されるとき、レートが流れでなったパケット滴がパケットサイズに関連するかどうかが重要です。 すなわち、小型小包が大きいTCPパケットとちょうど同じくらい落とされそうですか、または、より落とされそうにないより小さいパケットは[WBL04]ですか? そして、経路のパケットが低下する振舞いと、TFRCの損失イベント測定値との関係は何ですか?
Floyd & Kohler Experimental [Page 32] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[32ページ]RFC4828TFRC: SP異形2007年4月
< - - - - - 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
<----------KbpsでRatesを送ってください--、--、--、--、>ウェブTCP(1460B seg)TFRC-SP(200B seg)セッション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は、3Mbpsが共有されている状態でトポロジーのウェブ・トラフィックと競争する接続がリンクするのを5つのTCP接続と5TFRC-SPとの100秒のシミュレーションの後半の結果に示します。 TFRC-SPアプリケーションはあらゆる10が160Kbpsの最大のデータ信号速度のためにmsする200バイトのデータ・パケットを発生させます。 5つの長命のTCP接続が1460バイトのデータ・パケットサイズを使用します、そして、ウェブ・トラフィックは512バイトのデータ・パケットサイズを使用します。 5つのTCP接続が40〜240msからの往復の時を過します、そして、5つのTFRC接続が同じセットの往復の倍を過します。 これらのシミュレーションにおけるSACK TCP接続は株式会社Transmitと共にNSシミュレータでデフォルトパラメタを使用します、そして、TCP接続への200の原稿Addingタイムスタンプの最小のRTOはかなり結果を変えませんでした。 シミュレーションは、いくつかの小さいコントロールパケットをフォワードパスに加えて、何らかの待ち行列遅れを逆の経路に加えるために逆経路交通を含んでいます。 ウェブ・セッションの数は、異なったレベルの混雑を作成するために変えられます。 Drop-テール待ち行列がパケットのユニットにあります、パケットサイズにかかわらず。(各パケットが待ち行列に到達して、ユニットはただ一つのバッファを必要とします)。
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流れは同様のパケット低下率を見て、TFRC-SP流れは受信されますが、TCPより高いスループットは25%のパケット低下率であふれます。
Floyd & Kohler Experimental [Page 33] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[33ページ]RFC4828TFRC: SP異形2007年4月
< - - - - - 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
<----------KbpsでRatesを送ってください--、--、--、--、>ウェブTCP(1460B seg)TFRC-SP(200B seg)セッション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.
しかしながら、公正結果は、混雑している出力リンクのDropテール待ち行列がパケットよりむしろユニットのバイトであるかをかなり変えることができます。 待ち行列に、パケットの待ち行列のために、バッファの定数があります、そして、各バッファはちょうど1つのパケットを保持できます、バイトで表現されるサイズにかかわらず。 ほとんど完全な待ち行列は、待ち行列に、バイトにおける待ち行列のために、*バイト*の定数があって、小型小包の余地を持っていますが、大きいもののために持っていないかもしれません。 したがって、バイトにおけるDrop-テール待ち行列によるシミュレーションにおいて、大きいパケットは小さいものより落とされそうです。 NSシミュレータには、より現実的な中間的モデルがまだありません、そして、各バッファには、バイトの定数があります、そして、各パケットは1つ以上の無料のバッファを必要とするでしょう。(そこでは、待ち行列がバッファの定数を持っています)。 このモデルでは、小型小包は1つのバッファを使用するでしょうが、より大きいパケットはいくつかのバッファを必要とするでしょう。
The scenarios in Table 13 are identical to those in Table 12, except that the Drop-Tail queue is in units of bytes instead of packets. Thus, five TCP connections and five TFRC-SP connections compete with web traffic in a topology with a 3 Mbps shared link, with each TFRC- SP application generating 200-byte data packets every 10 ms, for a maximum data rate of 160 Kbps. The number of web sessions is varied to create different levels of congestion. However, instead of Drop- Tail queues able to accommodate at most a hundred packets, the routers' Drop-Tail queues are each able to accommodate at most 50,000 bytes (computed in NS as a hundred packets times the mean packet size of 500 bytes).
Table13のシナリオはTable12のそれらと同じです、Drop-テール待ち行列がパケットの代わりにユニットのバイトであるのを除いて。 したがって、5つのTCP接続と5つのTFRC-SP接続がa3Mbpsの分配しているリンク、それぞれのTFRC- SPアプリケーションが200バイトのデータ・パケットを発生させている10ms毎でトポロジーのウェブ・トラフィックと競争します、160Kbpsの最大のデータ信号速度のために。 ウェブ・セッションの数は、異なったレベルの混雑を作成するために変えられます。 しかしながら、ほとんどの100のパケットに収容できるDropテール待ち行列の代わりに、ルータのDrop-テール待ち行列はそれぞれ、5万バイト(NSでは、500バイトの平均であるパケットサイズの100パケット倍として計算される)を高々収容できます。
As Table 13 shows, with a Drop-Tail queue in bytes, the TFRC-SP flow sees a much smaller packet drop rate than the TCP flow, and as a consequence receives a much larger sending rate. For the simulations in Table 13, the TFRC-SP flows use 200-byte data segments, while the
Table13がバイトにおけるDrop-テール待ち行列で示すように、TCP流動、結果がはるかに大きい送付レートを受け取るとき、TFRC-SP流動ははるかにわずかなパケット低下率を見ます。 中のTable13(200バイトのデータが区分するTFRC-SP流れ使用)がゆったり過ごすシミュレーション
Floyd & Kohler Experimental [Page 34] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[34ページ]RFC4828TFRC: SP異形2007年4月
long-lived TCP flows use 1460-byte data segments. For example, when the five TCP flows and five TFRC-SP flows share the link with 800 web sessions, the five TCP flows see an average drop rate of 49% in the second half of the simulation, while the five TFRC-SP flows receive an average drop rate of 8%, and as a consequence receive more than 100 times the throughput of the TCP flows. This raises serious questions about making the assumption that flows with small packets see the same packet drop rate as flows with larger packets. Further work will have to include an investigation into the range of realistic Internet scenarios, in terms of whether large packets are considerably more likely to be dropped than are small ones.
長命のTCP流れは1460年のバイトのデータ・セグメントを使用します。 5TCPが流れて、5回のTFRC-SP流れが800のウェブ・セッションとのリンクを共有するとき、例えば、5回のTCP流れが、流れが8%の平均した低下率と、結果として受ける5TFRC-SPが受信する間のTCPに関するスループットの100倍以上のシミュレーションの後半の49%の平均した低下率が流れるのを見ます。 これは小型小包がある流れが、より大きいパケットで同じパケット低下率を流れであるとみなすという仮定をすることに関する重大問題を挙げます。 さらなる仕事は現実的なインターネットシナリオの範囲に調査を含まなければならないでしょう、大きいパケットが小さいものよりかなり落とされそうであるかどうかに関して。
< - - - - - 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
<----------KbpsでRatesを送ってください--、--、--、--、>ウェブTCP(512B seg)TFRC-SP(200B seg)セッション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の及ぶ1〜50までのN TCP流れ、N TFRC-SP流れ、および10の*Nウェブ・セッションによるシミュレーションを考えます、需要がすべてのタイプの交通から増えるように、バイトにおけるDropテール待ち行列があるルータで。
Floyd & Kohler Experimental [Page 35] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[35ページ]RFC4828TFRC: SP異形2007年4月
< - - - - - 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
<----------KbpsでRatesを送ってください--、--、--、--、>ウェブTCP(1460B seg)TFRC-SP(200B seg)セッションDropRate SendRate DropRate SendRate-------- -------- -------- -------- -------- 10 0.014 2085.36 0.001 180.29 20 0.040 788.88 0.004 183.87 30 0.074 248.80 0.006 182.94 40 0.113 163.20 0.008 185.33 50 0.127 94.70 0.011 185.14 60 0.177 53.24 0.015 185.30 70 0.174 35.31 0.016 185.07 80 0.221 19.38 0.019 183.91 90 0.188 15.63 0.019 180.42 100 0.265 7.08 0.023 176.71 200 0.324 0.38 0.042 139.48 300 0.397 0.32 0.076 93.53 400 0.529 0.40 0.100 70.40 500 0.610 0.37 0.121 57.59
Table 15: Drop and Send Rates for Drop-Tail Queues in Bytes III:
TFRC-SP, 1460B TCP Segments
テーブル15: バイトIIIにおける低下テール待ち行列の速度を落として、送ってください: TFRC-SP、1460B TCPセグメント
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.016 1926.00 0.002 178.47
20 0.030 805.20 0.003 178.23
30 0.062 346.24 0.005 161.19
40 0.093 219.18 0.007 136.28
50 0.110 132.77 0.010 83.02
60 0.170 88.88 0.014 69.75
70 0.149 70.73 0.015 55.59
80 0.213 43.17 0.020 42.82
90 0.188 36.19 0.017 43.61
100 0.233 24.77 0.026 35.17
200 0.311 5.46 0.034 24.85
300 0.367 3.74 0.049 20.19
400 0.421 2.59 0.055 17.71
500 0.459 1.10 0.069 15.95
Table 16: Drop and Send Rates for Drop-Tail Queues in Bytes IV:
Standard TFRC, 1460B TCP Segments
<----------KbpsでRatesを送ってください--、--、--、--、>ウェブTCP(1460B seg)TFRC(200B seg)セッション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 テーブル16: バイトIVにおける低下テール待ち行列の速度を落として、送ってください: 標準のTFRC、1460B TCPセグメント
Table 15 shows simulations using TFRC-SP, while Table 16 shows simulations using TFRC instead of TFRC-SP. This is the only difference between the simulations in the two tables. Note that when TFRC-SP is used, the TCP flows and web traffic are essentially
テーブル15はTFRC-SPを使用することでシミュレーションを示していますが、Table16は、TFRC-SPの代わりにTFRCを使用することでシミュレーションを示しています。 これは2個のテーブルでのシミュレーションの唯一の違いです。 TFRC-SPが使用されているとき、TCP流れとウェブ・トラフィックが本質的には使用することに注意してください。
Floyd & Kohler Experimental [Page 36] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[36ページ]RFC4828TFRC: SP異形2007年4月
starved, while the TFRC-SP flows each continue to send 57 Kbps. In contrast, when standard TFRC is used instead of TFRC-SP for the flows sending 200-byte segments, the TCP flows are not starved (although they still don't receive their "share" of the link bandwidth when their packet drop rates are 30% or higher). These two sets of simulations illustrate the dangers of a widespread deployment of TFRC-SP in an environment where small packets are less likely to be dropped than large ones.
飢えて、TFRC-SPがそれぞれ流れる間、57Kbpsを送り続けてください。 標準のTFRCが流れのためのTFRC-SPの代わりに200バイトのセグメントを送りながら使用されるとき、対照的に、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.
予想されるように、ルータでActive Queue Management(AQM)メカニズムを変えることによって、パケットが低下する振舞いも変えることができます。 ルータがRED(無作為のEarly Detection)を使用するとき、いくつかのパラメタがパケットサイズの関数としてパケット低下かマーキング行動に影響できるよりあります。
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待ち行列がDrop-テールなら、あることができます。 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を2番目に、直交して、構成できます。 パケット形態で、それぞれの*パケット*にはREDが立ち寄られるという同じ確率にあります、それぞれの*バイト*には、落とされるという同じ確率がバイトモードでありますが。 パケット形態で、大きいパケットと小型小包流れは手荒く同じパケット低下率に受信されます、ビーピーエスにおける同じスループットに従った大きいパケットと小型小包流れはバイトモードでおよそ同じ*番号*のパケット滴を受けますが。 [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のためにパケット形態、パケット低下率でそれを示しています。 これはパケットかバイトにおける待ち行列、Adaptive 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
パケットサイズの関数としてパケット低下かマーキング行動に影響する3番目のREDパラメタはREDメカニズムがStandard REDかAdaptive REDを使用しているかどうかということです。 適応型のREDはパケット低下率にかかわらず同じ平均した待ち行列サイズを維持しようとします。 Adaptive REDの使用で、REDメカニズムは高いパケット低下率(例えば、10%以上)があるときより効果的に機能します。 またはAdaptive REDがなければ、固定低下敷居があって、すべて到着しているパケットが落とされる、いつ、低下。
Floyd & Kohler Experimental [Page 37] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[37ページ]RFC4828TFRC: SP異形2007年4月
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).
レートをマークすると、この敷居は超えられています。 対照的に、Adaptive REDと共に、低下機能は、高低下率の政権を収容するために適合させられます。 1つの結果はバイトモードがAdaptive REDと共に使用されるとき、バイトモードが高低下率の政権にさえ達するということです。 しかしながら、バイトモードが標準のREDと共に使用されるとき、低下率が固定低下敷居(デフォルトで、10%に、NSシミュレータでは、セットする)を超えているとき、バイトモードはもう使用中ではありません。
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のように、1秒あたり100のパケットを発生させて、上では、TFRC-SP流動のアプリケーションが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
<----------KbpsでRatesを送ってください--、--、--、--、>ウェブTCP(1460B seg)TFRC-SP(200B seg)セッションDropRate SendRate DropRate SendRate-------- -------- -------- -------- -------- 10 0.05 305.76 0.04 182.82 25 0.06 224.16 0.06 175.91 50 0.09 159.12 0.08 152.51 100 0.13 90.77 0.11 106.13 200 0.14 48.53 0.14 70.25 400 0.20 22.08 0.19 41.50 800 0.27 3.55 0.25 17.50 1600 0.42 1.87 0.34 8.81
Table 17: Drop and Send Rates for RED Queues in Packet Mode
テーブル17: パケット形態における赤い待ち行列の速度を落として、送ってください。
For the simulations in Table 17, with a congested router with a RED queue in packet mode, the results are similar to those with a Drop- Tail queue in packets, as in Table 12 above. The TFRC-SP flow receives similar packet drop rates as the TCP flow, though it receives higher throughput in the more congested environments. The simulations are similar with a RED queue in packet mode with the queue in bytes, and with or without Adaptive RED. In these simulations, TFRC-SP gives roughly the desired performance.
Table17でのシミュレーションに、パケット形態におけるRED待ち行列がある混雑しているルータについて、結果はDropテール待ち行列がパケットにあるそれらと同様です、上のTable12のように。 TCPが流れるとき、TFRC-SP流動は同様のパケット低下率を受けます、より混雑している環境における、より高いスループットを受け取りますが。 シミュレーションはバイト、Adaptive REDおよびのあるなしにかかわらずパケット形態における待ち行列によるRED待ち行列について同様です。 これらのシミュレーションで、TFRC-SPはおよそ必要なパフォーマンスを行います。
Floyd & Kohler Experimental [Page 38] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[38ページ]RFC4828TFRC: SP異形2007年4月
< - - - - - 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
<----------KbpsでRatesを送ってください--、--、--、--、>ウェブTCP(1460B seg)TFRC-SP(200B seg)セッションDropRate SendRate DropRate SendRate-------- -------- -------- -------- -------- 10 0.06 272.16 0.02 184.37 25 0.07 175.82 0.02 184.06 50 0.10 75.65 0.04 180.56 100 0.14 38.98 0.07 151.65 200 0.19 16.66 0.11 106.80 400 0.26 4.85 0.15 69.41 800 0.35 3.12 0.20 27.07 1600 0.42 0.67 0.29 10.68
Table 18: Drop and Send Rates for RED Queues in Byte Mode
テーブル18: バイトモードにおける赤い待ち行列の速度を落として、送ってください。
Table 18 shows that with a standard RED queue in byte mode instead of packet mode, there is a somewhat greater difference between the packet drop rates of the TCP and TFRC-SP flows, particularly for lower packet drop rates. For the simulation in Table 18, the packet drop rates for the TCP flows can range from 1 1/2 to four times greater than the packet drop rates for the TFRC-SP flows. However, because the TFRC-SP flow has an upper bound on the sending rate, its sending rate is not affected in the lower packet-drop-rate regimes; its sending rate is only affected in the regimes with packet drop rates of 10% or more. The sending rate for TFRC-SP in the scenarios in Table 18 with higher packet drop rates are greater than desired, e.g., for the scenarios with 400 web sessions or greater. However, the results with TFRC-SP are at least better than that of small- packet flows with no congestion control at all.
テーブル18は、パケット形態の代わりにバイトモードにおける標準のRED待ち行列と共に、TCPのパケット低下率の間には、いくらか大きい違いがあって、TFRC-SPが流れるのを示します、特に低いパケット低下率のために。 Table18でのシミュレーションのために、TCPが流れるので、パケット低下率はTFRC-SPのパケット低下率より1 1/2〜4倍すごい流れから変化できます。 しかしながら、TFRC-SP流動が送付レートに上限を持っているので、送付レートは下側のパケット低下率の政権で影響を受けません。 送付レートは政権で10%以上のパケット低下率で影響を受けるだけです。 Table18の、より高いパケット低下率があるシナリオのTFRC-SPの送付レートは望まれているより大きいです、例えば、400以上のウェブ・セッションがあるシナリオのために。 しかしながら、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
<----------KbpsでRatesを送ってください--、--、--、--、>ウェブTCP(512B seg)TFRC-SP(200B seg)セッションDropRate SendRate DropRate SendRate-------- -------- -------- -------- -------- 10 0.01 337.86 0.01 184.06 25 0.02 258.71 0.01 184.03 50 0.02 184.71 0.01 183.99 100 0.04 63.63 0.03 184.43 200 0.08 28.95 0.06 149.80 400 0.12 17.03 0.10 88.21 800 0.24 5.94 0.15 36.80 1600 0.32 3.37 0.21 19.45
Table 19: Drop and Send Rates for RED Queues in Byte Mode
テーブル19: バイトモードにおける赤い待ち行列の速度を落として、送ってください。
Table 19 shows that with a standard RED queue in byte mode and with long-lived TCP flows with 512-byte data segments, there is only a moderate difference between the packet drop rate for the 552-byte TCP
テーブル19は、バイトモードにおける標準のRED待ち行列と512バイトのデータ・セグメントがある長命のTCP流れと共に、552バイトのTCPのパケット低下率の間には、適度の違いしかないのを示します。
Floyd & Kohler Experimental [Page 39] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[39ページ]RFC4828TFRC: SP異形2007年4月
packets and the 240-byte TFRC-SP packets. However, the sending rates for TFRC-SP in the scenarios in Table 19 with higher packet drop rates are still greater than desired, even given the goal of fairness with TCP flows with 1500-byte data segments instead of 512-byte data segments.
パケットと240バイトのTFRC-SPパケット。 しかしながら、Table19の、より高いパケット低下率があるシナリオのTFRC-SPの送付レートは望まれているよりなお大きいです、1500年のバイトのデータ・セグメントが512バイトのデータ・セグメントの代わりにあるTCP流れに伴う公正の目標を考えさえして。
< - - - - - Send Rates in Kbps - - - - >
Web TCP (1460B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.04 318.10 0.02 185.34
25 0.08 175.34 0.03 184.38
50 0.10 81.60 0.04 181.95
100 0.12 28.51 0.05 178.79
200 0.20 3.65 0.06 173.78
400 0.27 1.44 0.08 161.41
800 0.40 0.58 0.06 159.62
1600 0.55 0.29 0.02 180.92
<----------KbpsでRatesを送ってください--、--、--、--、>ウェブTCP(1460B seg)TFRC-SP(200B seg)セッションDropRate SendRate DropRate SendRate-------- -------- -------- -------- -------- 10 0.04 318.10 0.02 185.34 25 0.08 175.34 0.03 184.38 50 0.10 81.60 0.04 181.95 100 0.12 28.51 0.05 178.79 200 0.20 3.65 0.06 173.78 400 0.27 1.44 0.08 161.41 800 0.40 0.58 0.06 159.62 1600 0.55 0.29 0.02 180.92
Table 20: Drop and Send Rates with Adaptive RED Queues in Byte Mode
テーブル20: バイトモードにおける適応型の赤い待ち行列があるレートを落として、送ってください。
For the simulations in Table 20, the congested router uses an Adaptive RED queue in byte mode.
Table20でのシミュレーションのために、混雑しているルータはバイトモードにおける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.
このルータのために、出力キューはパケットについてというよりむしろユニットのバイトで表現されるものです、そして、それぞれの*バイト*は同じ確率で落とされます。 また、Adaptive 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.
Table20がシナリオのためにAdaptive REDと共にバイトモードで示すように、TFRC-SP交通のパケット低下速度は*TCP交通へのそれよりはるかに低く*です、そして、結果として、非常に混雑している環境におけるTFRC-SP交通の送付速度は*TCP交通のものよりはるかに高く*です。 事実上、これらのシナリオでは、小型小包交通には、TFRC- SP混雑制御機構は主に効力がありません。
The simulation with 1600 web servers is of particular concern, because the TCP packet drop rate increases, while the TFRC-SP packet drop rate decreases significantly. This is due to a detail of the Adaptive RED implementation in the NS simulator, and not about the dynamics of TFRC-SP. In particular, Adaptive RED is configured not to "adapt" to packet drop rates over 50%. When the packet drop rate is at most 50%, Adaptive RED is moderately successful in keeping the packet drop rate proportional to the packet size. TCP packets are six times larger than the TFRC-SP packets (including headers), so the TCP packets should see a packet drop rate roughly six times larger.
1600のウェブサーバーによるシミュレーションは特別の関心のものです、TCPパケット低下率が増加するので、TFRC-SPパケット低下率はかなり減少しますが。 これはTFRC-SPの力学ではなく、NSシミュレータのAdaptive RED実現の詳細のためです。 特に、Adaptive REDは、パケット低下率に50%以上を「適合させない」ように構成されます。 パケット低下率が高々50%であるときに、Adaptive REDは適度にパケット低下率をパケットサイズに比例しているように保つのに成功しています。 TCPパケットがTFRC-SPパケットより6倍大きいので(ヘッダーを含んでいて)、TCPパケットは、パケット低下率がおよそ6倍より大きいのを見るはずです。
Floyd & Kohler Experimental [Page 40] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[40ページ]RFC4828TFRC: SP異形2007年4月
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%以上のパケット低下率のために、Adaptive REDがもうどんなこの政権にもないので、TCPパケットの低下率が高々TFRC-SPパケットの低下率の6倍であることを保つのにそれはもう成功していません。
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.
私たちは、バイトにおけるDrop-テール待ち行列には、これらのシミュレーションにおける不公平がTFRC- SPを支持してTable13に示された不公平よりさらに厳しいことに注意します。 同時に、何か展開がバイトモードによるAdaptive REDがあるどんなルータ、または同様の振舞いがあるどんなAQMメカニズムのインターネットにもあれば、それは知られていません。 私たちは標準のREDの展開、または提案されたAQMメカニズムのどれかの範囲を知りません。
< - - - - - Send Rates in Kbps - - - - >
Web TCP (512B seg) TFRC-SP (200B seg)
Sessions DropRate SendRate DropRate SendRate
-------- -------- -------- -------- --------
10 0.01 306.56 0.01 185.11
25 0.02 261.41 0.01 184.41
50 0.02 185.07 0.01 184.54
100 0.04 59.25 0.03 181.58
200 0.08 16.32 0.06 150.87
400 0.12 11.53 0.10 98.10
800 0.25 5.85 0.15 46.59
1600 0.32 1.43 0.22 19.40
<----------KbpsでRatesを送ってください--、--、--、--、>ウェブTCP(512B seg)TFRC-SP(200B seg)セッションDropRate SendRate DropRate SendRate-------- -------- -------- -------- -------- 10 0.01 306.56 0.01 185.11 25 0.02 261.41 0.01 184.41 50 0.02 185.07 0.01 184.54 100 0.04 59.25 0.03 181.58 200 0.08 16.32 0.06 150.87 400 0.12 11.53 0.10 98.10 800 0.25 5.85 0.15 46.59 1600 0.32 1.43 0.22 19.40
Table 21: Drop and Send Rates for Adaptive RED Queues in Byte Mode
テーブル21: バイトモードにおける適応型の赤い待ち行列の速度を落として、送ってください。
Table 21 shows that when TFRC-SP with 240-byte packets competes with TCP with 552-byte packets in a scenario with Adaptive RED in byte mode, the TFRC-SP flows still receive more bandwidth than the TCP flows, but the level of unfairness is less severe, and the packet drop rates of the TCP flows are at most twice that of the TFRC-SP flows. That is, the TFRC-SP flows still receive more than their share of the bandwidth, but the TFRC-SP congestion control is more effective than that in Table 20 above.
テーブル21はいつ552バイトのパケットがシナリオにある状態で240バイトのパケットがあるTFRC-SPがAdaptive REDと共にTCPとバイトモードで競争しますが、TFRC-SP流れがまだTCP流れより帯域幅を受けていますが、不公平のレベルがそれほど厳しくなく、TCP流れのパケット低下速度が高々二度、TFRC-SPのものが流れるということであるかをそれに示します。 すなわち、TFRC-SP流れるのがまだ受信されていますが、TFRC-SP輻輳制御は上のTable20のそれよりそれらの帯域幅のシェアより効果的です。
Floyd & Kohler Experimental [Page 41] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[41ページ]RFC4828TFRC: SP異形2007年4月
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は短くて長い損失間隔の間、損失間隔サイズを異なって見積もっています、長い損失間隔の間1回の損失出来事だけを数えますが、短い損失間隔の間損失出来事にすべてのパケット損失をみなして。 引き起こされた1つの疑問は単一の損失出来事には多くのパケット滴があって、損失出来事が短いのから長いことで逆もまた同様に切り替わる環境で海損イベント率がこれが振動に通じることができるかどうかということです。 例と、N/4回の損失を含むNパケットで損失間隔を考えてください。 この損失間隔が短いなら(高々往復の2回)、損失間隔の長さは4つのパケットとして測定されます。 この損失間隔が長いなら、損失間隔の長さはNパケットとして測定されます。
If the loss interval switching from short to long and back leads to severe oscillations in the average packet drop rate, and therefore in the allowed sending rate, one solution would be to have a more gradual transition between the calculation of the loss interval length for short and long loss intervals. For example, one possibility would be to use all of the packet losses for a loss interval of one round-trip time in calculating the loss interval length, to use 2/3 of the packet losses from a loss interval of two round-trip times, to use 1/3 of the packet losses from a loss interval of three round-trip time, and to use only one packet loss from a loss interval of four or more round-trip times. This more gradual mechanism would give a transition to counting all losses for a loss interval of only one round-trip time, and counting only one loss event for a loss interval of four or more round-trip times.
短いのから長いことで行き帰り切り替わる損失間隔が平均したパケット低下率、およびしたがって、許容送付レートにおける厳しい振動に通じるなら、1つの解決策は略して損失間隔の長さと長い損失間隔の計算の間によりゆるやかな変遷を持つだろうことです。 例えば、1つの可能性は、往復の1回の損失間隔の間、損失間隔の長さについて計算する際にパケット損失のすべてを使用して、往復の2回の損失間隔からの2/3回のパケット損失を使用して、3の往復の時間の損失間隔からの1/3回のパケット損失を使用して、往復の4回以上の損失間隔からの1回のパケット損失だけを使用するだろうことです。 このよりゆるやかなメカニズムは往復の1回だけの損失間隔の間、すべての損失を数えて、往復の4回以上の損失間隔の間、1回の損失出来事だけを数えることへの変遷を与えるでしょう。
However, our simulations so far have not shown a great difference in oscillations in the estimate loss event rate between the default mechanism for estimating the loss interval length for short loss interval and the gradual mechanism described above. Simulation scripts are available from [VOIPSIMS]. Therefore, for now we are staying with the simple default mechanism for estimating the loss event rate for short loss intervals described in this document.
しかしながら、今までのところの私たちのシミュレーションは短い損失間隔の間、損失間隔が長さであると見積もるためのデフォルトメカニズムとゆるやかなメカニズムの間の損失イベント率が上で説明した見積りにおける振動の大差を示していません。 シミュレーションスクリプトは[VOIPSIMS]から利用可能です。 したがって、当分、私たちは、本書では説明された短い損失間隔の損失イベント率を見積もるために簡単なデフォルトメカニズムで滞在しています。
Floyd & Kohler Experimental [Page 42] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[42ページ]RFC4828TFRC: SP異形2007年4月
Appendix D. A Discussion of Packet Size and Packet Dropping
付録D.はパケットサイズとパケット低下の議論です。
The lists below give a general summary of the relative advantages of packet-dropping behavior at routers independent of packet size, versus packet-dropping behavior where large packets are more likely to be dropped than small ones.
以下のリストはパケットサイズからパケットが低下する振舞いに対して独立しているルータにおけるパケットが低下する振舞いの相対的な利点の一般的な概要を大きいパケットが小さいものより落とされそうであるところにします。
Advantages of Packet Dropping Independent of Packet Size:
パケットがパケットサイズの如何にかかわらず低下する利点:
1. Adds another incentive for end nodes to use large packets.
1. エンドノードが大きいパケットを使用する別の誘因を加えます。
2. Matches an environment with a limitation in pps rather than bps.
2. ビーピーエスよりむしろppsで環境を制限に合わせます。
Advantages of Packet Dropping as a Function of Packet Size:
パケットがパケットサイズの関数として低下する利点:
1. Small control packets are less likely to be dropped than are
large data packets, improving TCP performance.
1. TCP性能を向上させて、小さいコントロールパケットは大きいデータ・パケットほど落とされそうにはありません。
2. Matches an environment with a limitation in bps rather than pps.
2. ppsよりむしろビーピーエスにおける制限に環境を合わせます。
3. Reduces the penalty of TCP and other transport protocols against
flows with small packets (where the allowed sending rate is
roughly a linear function of packet size).
3. 小型小包(許容送付レートがおよそパケットサイズの一次関数であるところ)で流れに対してTCPと他のトランスポート・プロトコルの刑罰を下げます。
4. A queue limited in bytes is better than a queue limited in
packets for matching the worst-case queue size to the worst-case
queueing delay in seconds.
4. バイトで制限された待ち行列は秒に最悪の場合待ち行列サイズを最悪の場合待ち行列遅れに合わせるためにパケットで制限された待ち行列より良いです。
Floyd & Kohler Experimental [Page 43] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[43ページ]RFC4828TFRC: SP異形2007年4月
Normative References
引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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)を制御します」。 「プロトコル仕様」、RFC3448、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.オールマン。 2003年6月の赤のバイトとパケット形態、コンピュータネットワーク、42(2)の比較。
[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.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC879] Postel, J., "TCP maximum segment size and related
topics", RFC 879, November 1983.
[RFC879] ポステル、J.、「TCPの最大のセグメントサイズの、そして、関連する話題」、RFC879、1983年11月。
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-
speed serial links", RFC 1144, February 1990.
[RFC1144]ジェーコブソン、V.、「低い速度シリーズのためにTCP/IPヘッダーを圧縮するのはリンクする」RFC1144、1990年2月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN) to
IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168(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.イーリー、「一回だけで合図する体力を要している明白な混雑通知(電子証券取引ネットワーク)」、RFC3540、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心配はインターネットの音声トラヒックに制御します」、RFC3714、2004年3月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J.,
and L. Wood, "Advice for Internet Subnetwork
Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]KarnとP.とボルマンとC.とFairhurstとG.とグロースマンとD.とラドウィグとR.とMahdaviとJ.とモンテネグロとG.と接触、J.とL.木、「インターネットサブネットワークデザイナーのためのアドバイス」BCP89、RFC3819(2004年7月)。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March
2006.
[RFC4340] コーラー、E.、ハンドレー、M.、およびS.フロイド、「データグラム混雑制御プロトコル(DCCP)」、RFC4340、2006年3月。
Floyd & Kohler Experimental [Page 44] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[44ページ]RFC4828TFRC: SP異形2007年4月
[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)輻輳制御ID3のために以下の輪郭を描きます」。 「TCPに優しい速度制御(TFRC)」、2006年3月のRFC4342。
[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。 可変パケットサイズ方程式ベースの輻輳制御。 <http://www.icsi.berkeley.edu/cgi-bin/パブ/publication.pl?ICSI技術報告書TR-00-008、2000年4月、IDは001183>と等しいです。
[VOIPSIMS] Web page <http://www.icir.org/tfrc/voipsims.html>.
[VOIPSIMS]ウェブページ<http://www.icir.org/tfrc/voipsims.html>。
[WBL04] J. Widmer, C. Boutremans, and Jean-Yves Le Boudec.
Congestion Control for Flows with Variable Packet
Size, ACM CCR, 34(2), 2004.
[WBL04] ジーン-イヴLe Boudec J.ウィトマー、C.Boutremans、および混雑は流れのために可変パケットサイズ、ACM CCR、34(2)、2004で制御されます。
Authors' Addresses
作者のアドレス
Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
サリーフロイドICSIは米国をInternet Research1947Center通り、Suite600バークレー、カリフォルニア 94704の中心に置きます。
EMail: floyd@icir.org
メール: floyd@icir.org
Eddie Kohler 4531C Boelter Hall UCLA Computer Science Department Los Angeles, CA 90095 USA
エディ・コーラー4531・C BoelterホールUCLAコンピュータサイエンス部のカリフォルニア90095ロサンゼルス(米国)
EMail: kohler@cs.ucla.edu
メール: kohler@cs.ucla.edu
Floyd & Kohler Experimental [Page 45] RFC 4828 TFRC: The SP Variant April 2007
フロイドとコーラー実験的な[45ページ]RFC4828TFRC: SP異形2007年4月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Floyd & Kohler Experimental [Page 46]
フロイドとコーラーExperimentalです。[46ページ]
一覧
スポンサーリンク
