RFC5166 日本語訳
5166 Metrics for the Evaluation of Congestion Control Mechanisms. S.Floyd, Ed.. March 2008. (Format: TXT=53609 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Floyd, Ed. Request for Comments: 5166 March 2008 Category: Informational
ワーキンググループのS.フロイド、エドをネットワークでつないでください。コメントのために以下を要求してください。 5166 2008年3月のカテゴリ: 情報
Metrics for the Evaluation of Congestion Control Mechanisms
混雑制御機構の評価のための測定基準
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
IESG Note
IESG注意
This document is not an IETF Internet Standard. It represents the individual opinion(s) of one or more members of the TMRG Research Group of the Internet Research Task Force. It may be considered for standardization by the IETF or adoption as an IRTF Research Group consensus document in the future.
このドキュメントはIETFインターネットStandardではありません。 それはインターネットResearch Task ForceのTMRG Research Groupの1人以上のメンバーの個々の意見を表します。 それは将来、標準化のためにIRTF Research GroupコンセンサスドキュメントとしてのIETFか採用で考えられるかもしれません。
Abstract
要約
This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet. These include metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. This document is the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols.
このドキュメントは、インターネットへの新しいか変更された混雑制御機構の評価で考えられるために測定基準について議論します。 これらはルータに新しいトランスポート・プロトコル、TCPへの提案された変更、アプリケーションレベル輻輳制御、およびActive Queue Management(AQM)メカニズムの評価のための測定基準を含んでいます。 このドキュメントは私たちがトランスポート・プロトコルの評価に使用するモデルを改良するのが目的とされた一連のドキュメントで1番目です。
This document is a product of the Transport Modeling Research Group (TMRG), and has received detailed feedback from many members of the Research Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or the IETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of trade-offs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of trade- offs between a range of metrics, rather than in terms of optimizing for a single metric.
このドキュメントは、Transport Modeling Research Group(TMRG)の製品であり、Research Group(RG)の多くのメンバーから詳細なフィードバックを受けました。 ドキュメントが明らかにしようとするように、スループットと遅れの間のトレードオフで公正を最適化するために、競争している流れと、同様のものの間には、混雑制御機構が設計されるべきであるという必ず測定基準に関する研究団体(または、IETF共同体、業者社会、操作共同体、またはいかなる他の共同体も)の中のコンセンサスはありません。 しかしながら、私たちは、混雑制御機構がシングルのために最適化することに関してというよりむしろさまざまな測定基準の間で貿易offsに関してメートル法で評価されるべきであるという明確なコンセンサスがあると信じています。
Floyd Informational [Page 1] RFC 5166 TMRG, METRICS March 2008
フロイド情報[1ページ]のRFC5166TMRG、2008年の測定基準行進
Table of Contents
目次
1. Introduction ....................................................2
2. Metrics .........................................................3
2.1. Throughput, Delay, and Loss Rates ..........................4
2.1.1. Throughput ..........................................5
2.1.2. Delay ...............................................6
2.1.3. Packet Loss Rates ...................................6
2.2. Response Times and Minimizing Oscillations .................7
2.2.1. Response to Changes .................................7
2.2.2. Minimizing Oscillations .............................8
2.3. Fairness and Convergence ...................................9
2.3.1. Metrics for Fairness between Flows .................10
2.3.2. Metrics for Fairness between Flows with
Different Resource Requirements ....................10
2.3.3. Comments on Fairness ...............................12
2.4. Robustness for Challenging Environments ...................13
2.5. Robustness to Failures and to Misbehaving Users ...........14
2.6. Deployability .............................................14
2.7. Metrics for Specific Types of Transport ...................15
2.8. User-Based Metrics ........................................15
3. Metrics in the IP Performance Metrics (IPPM) Working Group .....15
4. Comments on Methodology ........................................16
5. Security Considerations ........................................16
6. Acknowledgements ...............................................16
7. Informative References .........................................17
1. 序論…2 2. 測定基準…3 2.1. スループット、遅れ、および損失率…4 2.1.1. スループット…5 2.1.2. 延着してください…6 2.1.3. パケット損失は評価します…6 2.2. 応答時間と振動を最小にします…7 2.2.1. 変化への応答…7 2.2.2. 振動を最小にします…8 2.3. 公正と集合…9 2.3.1. 流れの間の公正のための測定基準…10 2.3.2. 異なったリソース要件がある流れの間の公正のための測定基準…10 2.3.3. 公正のコメント…12 2.4. やりがいがある環境のための丈夫さ…13 2.5. 失敗と、そして、ふらちな事をしているユーザへの丈夫さ…14 2.6. Deployability…14 2.7. 特定のタイプの輸送のための測定基準…15 2.8. ユーザベースの測定基準…15 3. IPパフォーマンス測定基準(IPPM)作業部会での測定基準…15 4. 方法論のコメント…16 5. セキュリティ問題…16 6. 承認…16 7. 有益な参照…17
1. Introduction
1. 序論
As a step towards improving our methodologies for evaluating congestion control mechanisms, in this document we discuss some of the metrics to be considered. We also consider the relationship between metrics, e.g., the well-known trade-off between throughput and delay. This document doesn't attempt to specify every metric that a study might consider; for example, there are domain-specific metrics that researchers might consider that are over and above the metrics laid out here.
混雑制御機構を評価するために私たちの方法論を改良することに向かったステップとして、本書では私たちは、考えられるために測定基準のいくつかについて議論します。 また、私たちは測定基準の間の関係、例えばスループットと遅れの間の周知のトレードオフを考えます。 このドキュメントが、指定するのを試みない、あらゆる、メートル法、研究は考えるかもしれません。 例えば、研究者がここに終わって、測定基準を超えて横たえられたそれであると考えるかもしれないドメイン特有の測定基準があります。
We consider metrics for aggregate traffic (taking into account the effect of flows on competing traffic in the network) as well as the heterogeneous goals of different applications or transport protocols (e.g., of high throughput for bulk data transfer, and of low delay for interactive voice or video). Different transport protocols or AQM mechanisms might have goals of optimizing different sets of metrics, with one transport protocol optimized for per-flow throughput and another optimized for robustness over wireless links, and with different degrees of attention to fairness with competing traffic. We hope this document will be used as a step in evaluating
私たちは異なったアプリケーションかトランスポート・プロトコル(例えば、バルク・データ転送のための高生産性、および対話的な声かビデオのための低い遅れの)の異種の目標と同様に集合交通と測定基準を考えます(ネットワークの競争している交通への流れの効果を考慮に入れます)。 異なったトランスポート・プロトコルかAQMメカニズムには、異なったセットの測定基準を最適化するという目標があるかもしれません、1つのトランスポート・プロトコルが1流れあたりのスループットのために最適化されて、無線のリンクの上と別のものが丈夫さのために競争している交通に伴う異なった度の公正に関する注意で最適化されている状態で。 このドキュメントが評価におけるステップとして使用されることを願っています。
Floyd Informational [Page 2] RFC 5166 TMRG, METRICS March 2008
フロイド情報[2ページ]のRFC5166TMRG、2008年の測定基準行進
proposed congestion control mechanisms for a wide range of metrics, for example, noting that Mechanism X is good at optimizing Metric A, but pays the price with poor performance for Metric B. The goal would be to have a broad view of both the strengths and weaknesses of newly proposed congestion control mechanisms.
さまざまな測定基準のための提案された混雑制御機構、例えば、そのMechanismに注意して、Xは、Metric Aを最適化するのが上手ですが、Metric B.に、不十分な性能と共に代価を払います。目標は両方の強さの広い視点と新たに提案された混雑制御機構の弱点を持つだろうことです。
Subsequent documents are planned to present sets of simulation and testbed scenarios for the evaluation of transport protocols and of congestion control mechanisms, based on the best current practice of the research community. These are not intended to be complete or final benchmark test suites, but simply to be one step of many to be used by researchers in evaluating congestion control mechanisms. Subsequent documents are also planned on the methodologies in using these sets of scenarios.
その後のドキュメントはトランスポート・プロトコルと混雑制御機構の評価のためにシミュレーションとテストベッドシナリオのセットを寄贈するために計画されています、研究団体の最も良い現在の習慣に基づいて。 完全であるか最終的なベンチマークテストスイートであることを意図するのではなく、これらは、単に混雑制御機構を評価する際に研究者によって使用されるべき多くのワンステップになるように意図します。また、その後のドキュメントは方法論でこれらのセットのシナリオを使用する際に計画されています。
This document is a product of the Transport Modeling Research Group (TMRG), and has received detailed feedback from many members of the Research Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or the IETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of trade-offs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of trade-offs between a range of metrics, rather than in terms of optimizing for a single metric.
このドキュメントは、Transport Modeling Research Group(TMRG)の製品であり、Research Group(RG)の多くのメンバーから詳細なフィードバックを受けました。 ドキュメントが明らかにしようとするように、スループットと遅れの間のトレードオフで公正を最適化するために、競争している流れと、同様のものの間には、混雑制御機構が設計されるべきであるという必ず測定基準に関する研究団体(または、IETF共同体、業者社会、操作共同体、またはいかなる他の共同体も)の中のコンセンサスはありません。 しかしながら、私たちは、混雑制御機構がシングルのために最適化することに関してというよりむしろさまざまな測定基準の間のトレードオフでメートル法で評価されるべきであるという明確なコンセンサスがあると信じています。
2. Metrics
2. 測定基準
The metrics that we discuss are the following:
私たちが議論する測定基準は以下です:
o Throughput;
o スループット。
o Delay;
o 延着してください。
o Packet loss rates;
o パケット損失は評価します。
o Response to sudden changes or to transient events;
o 突然への応答は、変化するか、または一時的事象にそうします。
o Minimizing oscillations in throughput or in delay;
o スループットか遅れにおける振動を最小にします。
o Fairness and convergence times;
o 公正と集合時間。
o Robustness for challenging environments;
o やりがいがある環境のための丈夫さ。
o Robustness to failures and to misbehaving users;
o 失敗と、そして、ふらちな事をしているユーザへの丈夫さ。
Floyd Informational [Page 3] RFC 5166 TMRG, METRICS March 2008
フロイド情報[3ページ]のRFC5166TMRG、2008年の測定基準行進
o Deployability;
o Deployability。
o Metrics for specific types of transport;
o 特定のタイプの輸送のための測定基準。
o User-based metrics.
o ユーザベースの測定基準。
We consider each of these below. Many of the metrics have network-based, flow-based, and user-based interpretations. For example, network-based metrics can consider aggregate bandwidth and aggregate drop rates, flow-based metrics can consider end-to-end transfer times for file transfers or end-to-end delay and packet drop rates for interactive traffic, and user-based metrics can consider user wait time or user satisfaction with the multimedia experience. Our main goal in this document is to explain the set of metrics that can be relevant, and not to legislate on the most appropriate methodology for using each general metric.
私たちはそれぞれの以下のこれらを考えます。 測定基準の多くには、ネットワークベースの、そして、流れベースの、そして、ユーザベースの解釈があります。 例えば、ネットワークベースの測定基準は集合帯域幅と集合低下率を考えることができます、そして、流れベースの測定基準は、対話的な通信のファイル転送か終わりから終わりへの遅れとパケット低下速度のために終わりから終わりへの転送が回であると考えることができます、そして、ユーザベースの測定基準はマルチメディア体験に対するユーザ待ち時間かユーザ満足を考えることができます。 このドキュメントの私たちの第一目的は、関連する場合がある測定基準のセットについて説明して、各一般を使用するために最も適切な方法論でメートル法であることで制定することになっていません。
For some of the metrics, such as fairness, there is not a clear agreement in the network community about the desired goals. In these cases, the document attempts to present the range of approaches.
公正などの測定基準のいくつかのために、望んでいる目標に関して明確な合意はネットワーク共同体にありません。 これらの場合では、ドキュメントは、アプローチの範囲を提示するのを試みます。
2.1. Throughput, Delay, and Loss Rates
2.1. スループット、遅れ、および損失率
Because of the clear trade-offs between throughput, delay, and loss rates, it can be useful to consider these three metrics together. The trade-offs are most clear in terms of queue management at the router; is the queue configured to maximize aggregate throughput, to minimize delay and loss rates, or some compromise between the two? An alternative would be to consider a separate metric such as power, defined in this context as throughput over delay, that combines throughput and delay. However, we do not propose in this document a clear target in terms of the trade-offs between throughput and delay; we are simply proposing that the evaluation of transport protocols include an exploration of the competing metrics.
スループットと、遅れと、損失率の間の明確なトレードオフのために、これらの3つの測定基準を一緒に考えるのは役に立つ場合があります。 トレードオフは待ち行列管理がルータが最もありませんい。 集合を最大にするために構成された待ち行列は、2つの間で遅れと損失率か、何らかの妥協を最小にするためにはスループットですか? 代替手段は別々のメートル法のそのようなものがスループットと遅れを結合する遅れの上でこのような関係においてはスループットと定義されたパワーであるとみなすだろうことです。 しかしながら、私たちはスループットと遅れの間のトレードオフで本書では明確な目標を提案しません。 私たちは、トランスポート・プロトコルの評価が競争している測定基準の探検を含んでいるよう単に提案しています。
Using flow-based metrics instead of router-based metrics, the relationship between per-flow throughput, delay, and loss rates can often be given by the transport protocol itself. For example, in TCP, the sending rate s in packets per second is given as:
ルータベースの測定基準の代わりに流れベースの測定基準を使用して、トランスポート・プロトコル自体はしばしば1流れあたりのスループットと、遅れと、損失率との関係を与えることができます。 例えば、TCPでは、以下として1秒あたりのパケットの送付レートsを与えます。
s = 1.2/(RTT*sqrt(p)),
s=1.2/(RTT*sqrt(p))
for the round-trip time RTT and loss rate p [FF99].
往復の時間に、RTTと損失は、pが[FF99]であると評定します。
Floyd Informational [Page 4] RFC 5166 TMRG, METRICS March 2008
フロイド情報[4ページ]のRFC5166TMRG、2008年の測定基準行進
2.1.1. Throughput
2.1.1. スループット
Throughput can be measured as a router-based metric of aggregate link utilization, as a flow-based metric of per-connection transfer times, and as user-based metrics of utility functions or user wait times. It is a clear goal of most congestion control mechanisms to maximize throughput, subject to application demand and to the constraints of the other metrics.
集合では、aとして流れベースで利用をリンクしてください。スループット、aとしてルータベースで測定できる、メートル法であることで1接続あたりの転送時間と、そして、ユーティリティ機能かユーザ待ち回数のユーザベースの測定基準としてメートル法です。 アプリケーション要求を条件とした他の測定基準の規制にスループットを最大にするのは、ほとんどの混雑制御機構の明確な目標です。
Throughput is sometimes distinguished from goodput, where throughput is the link utilization or flow rate in bytes per second; goodput, also measured in bytes per second, is the subset of throughput consisting of useful traffic. That is, 'goodput' excludes duplicate packets, packets that will be dropped downstream, packet fragments or ATM cells that are dropped at the receiver because they can't be re-assembled into complete packets, and the like. In general, this document doesn't distinguish between throughput and goodput, and uses the general term "throughput".
スループットはgoodputと時々区別されます。(そこでは、スループットは、リンク利用か1秒あたりのバイトで表現される流速です)。 また、1秒あたりのバイトで測定されたgoodputは役に立つ交通から成るスループットの部分集合です。 すなわち、'goodput'は、完全なパケット、および同様のものにそれらを組み立て直すことができないので、受信機で落とされる写しパケット、川下に落とされるパケット、パケット断片またはATMセルを除きます。 一般に、このドキュメントは、スループットとgoodputを見分けないで、「スループット」という一般項を使用します。
We note that maximizing throughput is of concern in a wide range of environments, from highly-congested networks to under-utilized ones, and from long-lived flows to very short ones. As an example, throughput has been used as one of the metrics for evaluating Quick-Start, a proposal to allow flows to start up faster than slow-start, where throughput has been evaluated in terms of the transfer times for connections with a range of transfer sizes [RFC4782] [SAF06].
私たちは、ものを下で利用して、長命の流れからまさしくその流れまでものをショートするように非常に混雑しているネットワークからスループットを最大にするのがさまざまな環境で重要であることに注意します。 例として、スループットはクィック-始めを評価するのに測定基準の1つとして使用されました、流れが遅れた出発より速く始動するのを許容するという提案。そこでは、スループットがさまざまな転送サイズ[RFC4782][SAF06]との関係のために転送時間に関して評価されました。
In some contexts, it might be sufficient to consider the aggregate throughput or the mean per-flow throughput [DM06], while in other contexts it might be necessary to consider the distribution of per-flow throughput. Some researchers evaluate transport protocols in terms of maximizing the aggregate user utility, where a user's utility is generally defined as a function of the user's throughput [KMT98].
いくつかの文脈では、集合スループットか1流れあたりの平均であるスループットが[DM06]であると考えるのは十分であるかもしれません、1流れあたりのスループットの分配を考えるのが他の文脈で必要であるかもしれませんが。 研究者の中には一般に、ユーザのユーティリティがユーザのスループット[KMT98]の関数と定義される集合ユーザユーティリティを最大にすることに関してトランスポート・プロトコルを評価する人もいます。
Individual applications can have application-specific needs in terms of throughput. For example, real-time video traffic can have highly variable bandwidth demands; Voice over IP (VoIP) traffic is sensitive to the amount of bandwidth received immediately after idle periods. Thus, user metrics for throughput can be more complex than simply the per-connection transfer time.
個々のアプリケーションはスループットに関してアプリケーション特有の必要性を持つことができます。 例えば、レアルタイムビデオ交通は可変帯域幅要求を非常に持つことができます。 ボイス・オーバー IP(VoIP)交通は活動していない期間直後受け取られた帯域幅の量に敏感です。 したがって、スループットのためのユーザ測定基準は単に1接続あたりの転送時間より複合体であるかもしれません。
Floyd Informational [Page 5] RFC 5166 TMRG, METRICS March 2008
フロイド情報[5ページ]のRFC5166TMRG、2008年の測定基準行進
2.1.2. Delay
2.1.2. 遅れ
Like throughput, delay can be measured as a router-based metric of queueing delay over time, or as a flow-based metric in terms of per-packet transfer times. Per-packet delay can also include delay at the sender waiting for the transport protocol to send the packet. For reliable transfer, the per-packet transfer time seen by the application includes the possible delay of retransmitting a lost packet.
待ち行列では、流れベースであることで時間がたつにつれて、延着するか、またはaとしてメートル法になってください。同様のスループット、aとしてルータベースで遅れを測定できる、メートル法、1パケットあたりの転送時間では、メートル法です。 また、1パケットあたりの遅れはトランスポート・プロトコルがパケットを送るのを待っている送付者に遅れを含むことができます。 信頼できる転送のために、アプリケーションで見られた1パケットあたりの転送時間は無くなっているパケットを再送する可能な遅れを含んでいます。
Users of bulk data transfer applications might care about per-packet transfer times only in so far as they affect the per-connection transfer time. On the other end of the spectrum, for users of streaming media, per-packet delay can be a significant concern. Note that in some cases the average delay might not capture the metric of interest to the users; for example, some users might care about the worst-case delay, or about the tail of the delay distribution.
単に1接続あたりの転送時間に影響する限り、バルク・データ転送アプリケーションのユーザは1パケットあたりの転送時間を心配するかもしれません。 スペクトルのもう一方の端における、ストリーミング・メディアのユーザにとって、1パケットあたりの遅れは重要な関心であるかもしれません。 いくつかの場合、平均した遅れがユーザにとって、興味深いメートル法を捕らえないかもしれないことに注意してください。 例えば、何人かのユーザが最悪の場合遅れの周り、または、遅れ分配のテールの周りについて気にかけるかもしれません。
Note that queueing delay at a router is shared by all flows at a FIFO (First-In First-Out) queue. Thus, the router-based queueing delay induced by bulk data transfers can be important even if the bulk data transfers themselves are not concerned with per-packet transfer times.
ルータにおける待ち行列遅れが先入れ先出し法(先入れ先出し)待ち行列のときにすべての流れによって共有されることに注意してください。 したがって、バルク・データ転送自体は1パケットあたりの転送時間に関係がなくても、バルク・データ転送で引き起こされたルータベースの待ち行列遅れが重要である場合があります。
2.1.3. Packet Loss Rates
2.1.3. パケット損失率
Packet loss rates can be measured as a network-based or as a flow-based metric.
ネットワークベースの、または、aとしての流れベースのaとしてメートル法でパケット損失率を測定できます。
When evaluating the effect of packet losses or ECN marks (Explicit Congestion Notification) [RFC3168] on the performance of a congestion control mechanism for an individual flow, researchers often use both the packet loss/mark rate for that connection and the congestion event rate (also called the loss event rate), where a congestion event or loss event consists of one or more lost or marked packets in one round-trip time [RFC3448].
個々の流れのためにパケット損失か電子証券取引ネットワークのマーク(明白なCongestion Notification)[RFC3168]の混雑制御機構の性能への効果を評価するとき、研究者はしばしばその接続のパケット損失/マルク相場と混雑イベント率(また、損失イベント率と呼ばれる)の両方を使用します、混雑出来事か損失出来事が往復の1回[RFC3448]の後に1つ以上の無くなっているか著しいパケットから成るところで。
Some users might care about the packet loss rate only in so far as it affects per-connection transfer times, while other users might care about packet loss rates directly. RFC 3611, RTP Control Protocol Extended Reports, describes a VoIP performance-reporting standard called RTP Control Protocol Extended Reports (RTCP XR), which includes a set of burst metrics. In RFC 3611, a burst is defined as the maximal sequence starting and ending with a lost packet, and not including a sequence of Gmin or more packets that are not lost [RFC3611]. The burst metrics in RFC 3611 consist of the burst density (the fraction of packets in bursts), gap density (the fraction of packets in the gaps between bursts), burst duration (the
単に1接続あたりの転送時間に影響する限り、何人かのユーザがパケット損失率を心配するかもしれません、他のユーザは直接パケット損失率を心配するかもしれませんが。 RFC3611(RTP ControlプロトコルExtended Reports)はRTP ControlプロトコルExtended Reports(RTCP XR)と呼ばれる性能を報告するVoIP規格について説明します。Extended Reportsは1セットの炸裂測定基準を含んでいます。 RFC3611では、炸裂は、無くなっているパケットで最大限度の系列始めと結末と定義されて、無くなっていないGminか、より多くのパケット[RFC3611]の系列を含めていません。 RFC3611での炸裂測定基準は炸裂密度(炸裂におけるパケットの部分)から成ります、ギャップ密度(炸裂のギャップのパケットの部分)、炸裂持続時間、(
Floyd Informational [Page 6] RFC 5166 TMRG, METRICS March 2008
フロイド情報[6ページ]のRFC5166TMRG、2008年の測定基準行進
mean duration of bursts in seconds), and gap duration (the mean duration of gaps in seconds). RFC 3357 derives metrics for "loss distance" and "loss period", along with statistics that capture loss patterns experienced by packet streams on the Internet [RFC3357].
秒の炸裂の意地悪な持続時間)、そして、ギャップ持続時間(秒のギャップの意地悪な持続時間)。 RFC3357は「損失距離」と「損失の期間」のための測定基準を引き出します、インターネット[RFC3357]におけるパケットの流れで経験された損失パターンを得る統計と共に。
In some cases, it is useful to distinguish between packets dropped at routers due to congestion and packets lost in the network due to corruption.
いくつかの場合、混雑のためルータで落とされたパケットと不正のためネットワークで失われたパケットを見分けるのは役に立ちます。
One network-related reason to avoid high steady-state packet loss rates is to avoid congestion collapse in environments containing paths with multiple congested links. In such environments, high packet loss rates could result in congested links wasting scarce bandwidth by carrying packets that will only be dropped downstream before being delivered to the receiver [RFC2914]. We also note that in some cases, the retransmit rate can be high, and the goodput correspondingly low, even with a low packet drop rate [AEO03].
高い定常状態パケット損失率を避ける1つのネットワーク関連の理由は複数の混雑しているリンクで経路を含む環境における混雑崩壊を避けることです。 そのような環境で、高いパケット損失率は受信機[RFC2914]に渡す前に川下に落とすだけであるパケットを運ぶことによって不十分な帯域幅を浪費する混雑しているリンクをもたらすかもしれません。 また、いくつかの場合、私たちがそれに注意する、高値、およびgoodputが対応する低かったなら、レート缶を再送してください、低パケット低下率[AEO03]があっても。
2.2. Response Times and Minimizing Oscillations
2.2. 応答時間と振動を最小にすること。
In this section, we consider response times and oscillations together, as there are well-known trade-offs between improving response times and minimizing oscillations. In addition, the scenarios that illustrate the dangers of poor response times are often quite different from the scenarios that illustrate the dangers of unnecessary oscillations.
このセクションでは、私たちは、応答が回と一緒に振動であると考えます、応答時間を改良して、振動を最小にするとき、周知のトレードオフがあるとき。 さらに、応答不良時間の危険を例証するシナリオは不要な振動という危険を例証するシナリオとしばしば全く異なっています。
2.2.1. Response to Changes
2.2.1. 変化への応答
One of the key concerns in the design of congestion control mechanisms has been the response times to sudden congestion in the network. On the one hand, congestion control mechanisms should respond reasonably promptly to sudden congestion from routing or bandwidth changes or from a burst of competing traffic. At the same time, congestion control mechanisms should not respond too severely to transient changes, e.g., to a sudden increase in delay that will dissipate in less than the connection's round-trip time.
混雑制御機構のデザインにおける主要な心配事の1つはネットワークにおける突然の混雑への応答時間です。 一方では、混雑制御機構はルーティングか帯域幅変化か競争している交通の炸裂から突然の混雑に合理的に即座に応じるはずです。 同時に、混雑制御機構は厳しく過渡変化に応じ過ぎるはずであるというわけではありません、例えば、接続の往復の時間以下で消散する遅れの急増に。
Congestion control mechanisms also have to contend with sudden changes in the bandwidth-delay product due to mobility. Such bandwidth-delay product changes are expected to become more frequent and to have greater impact than path changes today. As a result of both mobility and of the heterogeneity of wireless access types (802.11b,a,g, WIMAX, WCDMA, HS-WCDMA, E-GPRS, Bluetooth, etc.), both the bandwidth and the round-trip delay can change suddenly, sometimes by several orders of magnitude.
輻輳制御メカニズムも移動性のため帯域幅遅れ製品における急変を競争しなければなりません。 そのような帯域幅遅れ製品変化は、より頻繁になって、経路が今日変えるより大きい影響を与えると予想されます。 移動性と無線のアクセス型(802.11b、a、g、WIMAX、WCDMA、HS-WCDMA、E-GPRS、ブルートゥースなど)の異種性の両方の結果、帯域幅と往復の遅れの両方急転できます、時々数桁。
Floyd Informational [Page 7] RFC 5166 TMRG, METRICS March 2008
フロイド情報[7ページ]のRFC5166TMRG、2008年の測定基準行進
Evaluating the response to sudden or transient changes can be of particular concern for slowly responding congestion control mechanisms such as equation-based congestion control [RFC3448] and AIMD (Additive Increase Multiplicative Decrease) or for related mechanisms using parameters that make them more slowly-responding than TCP [BB01] [BBFS01].
突然の、または、一時的な変化への応答を評価するのは、方程式ベースの輻輳制御[RFC3448]やAIMD(付加的なIncrease Multiplicative Decrease)か関連するメカニズムのためにそれらをTCPよりゆっくり応じている[BB01][BBFS01]にするパラメタを使用することで混雑制御機構をゆっくり反応させることに関する特別の心配のものであることができます。
In addition to the responsiveness and smoothness of aggregate traffic, one can consider the trade-offs between responsiveness, smoothness, and aggressiveness for an individual connection [FHP00] [YKL01]. In this case, smoothness can be defined by the largest reduction in the sending rate in one round-trip time, in a deterministic environment with a packet drop exactly every 1/p packets. The responsiveness is defined as the number of round-trip times of sustained congestion required for the sender to halve the sending rate; aggressiveness is defined as the maximum increase in the sending rate in one round-trip time, in packets per second, in the absence of congestion. This aggressiveness can be a function of the mode of the transport protocol; for TCP, the aggressiveness of slow-start is quite different from the aggressiveness of congestion avoidance mode.
集合交通の反応性と滑らかに加えて、人は個々の接続[FHP00][YKL01]のために反応性と、滑らかと、攻撃性の間のトレードオフを考えることができます。 この場合、往復の1回で送付レートで最も大きい減少、決定論的な環境におけるパケット滴によるちょうどあらゆる1/pパケットは滑らかを定義できます。 反応性は送付者が送付レートを半分にするのに必要である持続している混雑の往復の倍の数と定義されます。 攻撃性は往復の1回の後に送付レートの最大の増加と定義されます、1秒あたりのパケットで、混雑がないとき。 この攻撃性はトランスポート・プロトコルのモードの関数であるかもしれません。 TCPに関しては、遅れた出発の攻撃性は輻輳回避モードの攻撃性と全く異なっています。
2.2.2. Minimizing Oscillations
2.2.2. 振動を最小にします。
One goal is that of stability, in terms of minimizing oscillations of queueing delay or of throughput. In practice, stability is frequently associated with rate fluctuations or variance. Rate variations can result in fluctuations in router queue size and therefore of queue overflows. These queue overflows can cause loss synchronizations across coexisting flows and periodic under-utilization of link capacity, both of which are considered to be general signs of network instability. Thus, measuring the rate variations of flows is often used to measure the stability of transport protocols. To measure rate variations, [JWL04], [RX05], and [FHPW00] use the coefficient of variation (CoV) of per-flow transmission rates, and [WCL05] suggests the use of standard deviations of per-flow rates. Since rate variations are a function of time scales, it makes sense to measure these rate variations over various time scales.
1つの目標が待ち行列遅れかスループットの振動を最小にすることに関する安定性のものです。 実際には、安定性は頻繁にレート変動か変化に関連しています。 レート変化はサイズとしたがって、待ち行列オーバーフローのルータ待ち行列における変動をもたらすことができます。 これらの待ち行列オーバーフローは共存することの向こう側の損失連動にリンク容量の流れと周期的な過少利用を引き起こす場合があります。その両方がネットワークの不安定性の一般的なサインであると考えられます。 したがって、流れのレート変化を測定するのは、トランスポート・プロトコルの安定性を測定するのにしばしば使用されます。 レート変化を測定するのに、[JWL04]、[RX05]、および[FHPW00]は1流れあたりの通信速度の変動係数(CoV)を使用します、そして、[WCL05]は流速の標準偏差の使用を示します。 レート変化がタイムスケールの関数であるので、それはこれらを測定する意味を様々なタイムスケールの上レート変化にします。
Measuring per-flow rate variations, however, is only one aspect of transport protocol stability. A realistic experimental setting always involves multiple flows of the transport protocol being observed, along with a significant amount of cross traffic, with rates varying over time on both the forward and reverse paths. As a congestion control protocol must adapt its rate to the varying rates of competing traffic, just measuring the per-flow statistics of a subset of the traffic could be misleading because it measures the
しかしながら、1流速あたりの変化を測定するのが、トランスポート・プロトコルの安定性の1つの局面にすぎません。 現実的な実験設定はいつも観測されるトランスポート・プロトコルの複数の流れにかかわります、かなりの量の交差交通と共に、レートが時間がたつにつれて両方の前進の、そして、逆の経路で異なって。 混雑制御プロトコルが競争している交通の異なった速度にレートを適合させなければならないとき、測定するので、ただ交通の部分集合の1流れあたりの統計を測定するのは紛らわしいかもしれません。
Floyd Informational [Page 8] RFC 5166 TMRG, METRICS March 2008
フロイド情報[8ページ]のRFC5166TMRG、2008年の測定基準行進
rate fluctuations due in part to the adaptation to competing traffic on the path. Thus, per-flow statistics are most meaningful if they are accompanied by the statistics measured at the network level. As a complementary metric to the per-flow statistics, [HKLRX06] uses measurements of the rate variations of the aggregate flows observed in bottleneck routers over various time scales.
変動が一部経路における競争している交通への適合のためであると評定してください。 したがって、それらがネットワークレベルで測定された統計によって伴われるなら、1流れあたりの統計は最も重要です。 1流れあたりの統計へのメートル法の補色として、[HKLRX06]はボトルネックルータで様々なタイムスケールの上観測された集合流れのレート変化の測定を使用します。
Minimizing oscillations in queueing delay or throughput has related per-flow metrics of minimizing jitter in round-trip times and loss rates.
待ち行列遅れかスループットにおける振動を最小にすると、往復の回と損失率における最小にするジターの1流れあたりの測定基準を関係づけてあります。
An orthogonal goal for some congestion control mechanisms, e.g., for equation-based congestion control, is to minimize the oscillations in the sending rate for an individual connection, given an environment with a fixed, steady-state packet drop rate. (As is well known, TCP congestion control is characterized by a pronounced oscillation in the sending rate, with the sender halving the sending rate in response to congestion.) One metric for the level of oscillations is the smoothness metric given in Section 2.2.1 above.
いくつかの混雑制御機構、例えば、方程式ベースの輻輳制御の直交した目標は個々の接続の送付速度における振動を最小にすることです、修理されて、安定した状態のパケット低下率がある環境を考えて。 (周知のとおり、TCP輻輳制御は送付レートにおける著しい振動で特徴付けられます、送付レートを混雑に対応した送付者による半分にで。) 振動のレベルにおける、メートル法の1つは上のセクション2.2.1で滑らかメートル法の当然のことです。
As discussed in [FK07], the synchronization of loss events can also affect convergence times, throughput, and delay.
また、[FK07]で議論するように、損失出来事の同期は集合時間、スループット、および遅れに影響できます。
2.3. Fairness and Convergence
2.3. 公正と集合
Another set of metrics is that of fairness and convergence times. Fairness can be considered between flows of the same protocol and between flows using different protocols (e.g., TCP-friendliness, referring to fairness between TCP and a new transport protocol). Fairness can also be considered between sessions, between users, or between other entities.
もう1セットの測定基準は公正と集合時間のものです。 同じプロトコルの流れの間と、そして、流れの間で異なったプロトコル(例えば、TCPと新しいトランスポート・プロトコルの間の公正について言及するTCP-友情)を使用することで公正を考えることができます。 また、セッションの間、または、ユーザの間、または、他の実体の間で公正を考えることができます。
There are a number of different fairness measures. These include max-min fairness [HG86], proportional fairness [KMT98] [K01], the fairness index proposed in [JCH84], and the product measure, a variant of network power [BJ81].
多くの異なった公正測定があります。 これらは最大分公正[HG86]、比例している公正[KMT98][K01]、[JCH84]で提案された公正インデックス、および製品測定(ネットワークパワー[BJ81]の異形)を含んでいます。
Floyd Informational [Page 9] RFC 5166 TMRG, METRICS March 2008
フロイド情報[9ページ]のRFC5166TMRG、2008年の測定基準行進
2.3.1. Metrics for Fairness between Flows
2.3.1. 流れの間の公正のための測定基準
This section discusses fairness metrics that consider the fairness between flows, but that don't take into account different characteristics of flows (e.g., the number of links in the path or the round-trip time). For the discussion of fairness metrics, let x_i be the throughput for the i-th connection.
このセクションは流れの間の公正を考えますが、流れの異なった特性を考慮に入れない公正測定基準(例えば、経路か往復の時間でリンクの数)について論じます。 公正測定基準の議論のために、x_iがスループットであることをさせてください、i、-、第接続。
Jain's fairness index: The fairness index in [JCH84] is:
ジャイナ教徒の公正インデックス: [JCH84]の公正インデックスは以下の通りです。
(( sum_i x_i )^2) / (n * sum_i ( (x_i)^2 )),
((合計_i x_i)^2)/(n*合計_i(x_i)^2))
where there are n users. This fairness index ranges from 0 to 1, and it is maximum when all users receive the same allocation. This index is k/n when k users equally share the resource, and the other n-k users receive zero allocation.
nユーザがいるところ。 この公正インデックスは0〜1まで及びます、そして、すべてのユーザが同じ配分を受けるとき、それは最大です。 kユーザが等しくリソースを共有するとき、このインデックスはk/nです、そして、他のn-kユーザは配分を全く受けません。
The product measure: The product measure:
製品測定: 製品測定:
product_i x_i ,
製品_i x_i
the product of the throughput of the individual connections, is also used as a measure of fairness. (In some contexts x_i is taken as the power of the i-th connection, and the product measure is referred to as network power.) The product measure is particularly sensitive to segregation; the product measure is zero if any connection receives zero throughput. In [MS91], it is shown that for a network with many connections and one shared gateway, the product measure is maximized when all connections receive the same throughput.
また、個々の接続に関するスループットの製品も公正の測定として使用されています。 接続、および製品測定はそうです。(いくつかの文脈では、x_iがパワーとしてみなされる、i、-、ネットワークパワーと第呼ばれる、) 製品測定は特に隔離に敏感です。 何か接続がスループットを全く受け取らないなら、製品測定はゼロです。 すべての接続が同じスループットを受け取るとき、[MS91]では、多くの接続と共有された1門があるネットワークにおいて、製品測定が最大にされるのが示されます。
Epsilon-fairness: A rate allocation is defined as epsilon-fair if
ε-公正: レート配分はε-フェアと定義されます。
(min_i x_i) / (max_i x_i) >= 1 - epsilon.
(分_i x_i)/(_i x_iに最大限にします)>=1--ε。
Epsilon-fairness measures the worst-case ratio between any two throughput rates [ZKL04]. Epsilon-fairness is related to max-min fairness, defined later in this document.
ε-公正はどんな2つの押出量[ZKL04]の間の最悪の場合比を測定します。 ε-公正は後で本書では定義された最大分公正に関連します。
2.3.2. Metrics for Fairness between Flows with Different Resource
Requirements
2.3.2. 異なったリソース要件がある流れの間の公正のための測定基準
This section discusses metrics for fairness between flows with different resource requirements, that is, with different utility functions, round-trip times, or number of links on the path. Many of these metrics can be described as solutions to utility maximization problems [K01]; the total utility quantifies both the fairness and the throughput.
このセクションは流れの間の公正ために異なったリソース要件に測定基準について論じます、すなわち、異なったユーティリティ機能で、経路の往復の回、または数のリンク。 効用極大化問題[K01]の解決としてこれらの測定基準の多くを記述できます。 総ユーティリティは公正とスループットの両方を定量化します。
Floyd Informational [Page 10] RFC 5166 TMRG, METRICS March 2008
フロイド情報[10ページ]のRFC5166TMRG、2008年の測定基準行進
Max-min fairness: In order to satisfy the max-min fairness criteria, the smallest throughput rate must be as large as possible. Given this condition, the next-smallest throughput rate must be as large as possible, and so on. Thus, the max-min fairness gives absolute priority to the smallest flows. (Max-min fairness can be explained by the progressive filling algorithm, where all flow rates start at zero, and the rates all grow at the same pace. Each flow rate stops growing only when one or more links on the path reach link capacity.)
マックス-分公正: 最大分公正評価基準を満たすために、最もわずかな押出量はできるだけ大きくなければなりません。 この状態を考えて、次の最もわずかな押出量は、できるだけ大きくて、とてもオンでなければなりません。 したがって、最大分公正は最も小さい流れの絶対優先を与えます。 (進歩的な腹を満たすアルゴリズムでマックス-分公正について説明できます。そこでは、すべての流速がゼロから出発して、レートは同じペースですべて成長します。 経路の1個以上のリンクがリンク容量に達する場合にだけ、各流速は成長が止まります。)
Proportional fairness: In contrast, a feasible allocation, x, is defined as proportionally fair if, for any other feasible allocation x*, the aggregate of proportional changes is zero or negative:
比例している公正: 対照的に、可能な配分(x)は比例している変化の集合がいかなる他の可能な配分x*に関するゼロかネガであるならも比例して公正であると定義されます:
sum_i ( (x*_i - x_i)/x_i ) <= 0.
sum_i ( (x*_i - x_i)/x_i ) <= 0.
"This criterion favours smaller flows, but less emphatically than max-min fairness" [K01]. (Using the language of utility functions, proportional fairness can be achieved by using logarithmic utility functions, and maximizing the sum of the per-flow utility functions; see [KMT98] for a fuller explanation.)
「この評価基準は、より小さい流れを最大分公正よりそれほど強調しないで支持しない」[K01]。 (ユーティリティ機能の言語を使用して、対数型効用関数を使用して、1流れあたりのユーティリティ機能の合計を最大にすることによって、比例している公正を達成できます; よりふくよかな説明に関して[KMT98]を見てください。)
Minimum potential delay fairness: Minimum potential delay fairness has been shown to model TCP [KS03], and is a compromise between max-min fairness and proportional fairness. An allocation, x, is defined as having minimum potential delay fairness if:
最小の潜在的遅れ公正: 最小の潜在的遅れ公正は、TCP[KS03]をモデル化するために示されて、最大分公正と比例している公正の間の妥協です。 配分(x)が最小の潜在的遅れ公正を持っていると定義される、:
sum_i (1/x_i)
合計_i(1/x_i)
is smaller than for any other feasible allocation. That is, it would minimize the average download time if each flow was an equal-sized file.
小さいいかなる他のも可能な配分はそうですか? すなわち、それは各流れが等しいサイズのファイルであるなら平均したダウンロード時間を最小にするでしょうに。
In [CRM05], Colussi, et al. propose a new definition of TCP fairness, that "a set of TCP fair flows do not cause more congestion than a set of TCP flows would cause", where congestion is defined in terms of queueing delay, queueing delay variation, the congestion event rate [e.g., loss event rate], and the packet loss rate.
[CRM05]、Colussiでは、他はTCP公正、「1セットのTCPの公正な流れは流れが引き起こすTCPの1セットより多くの混雑を引き起こすのでないこと」のその混雑が待ち行列遅れ、待ち行列遅れ変化、混雑イベント率[例えば、損失イベント率]、およびパケット損失率で定義される新しい定義を提案します。
Chiu and Tan in [CT06] argue for redefining the notion of fairness when studying traffic controls for inelastic traffic, proposing that inelastic flows adopt other traffic controls such as admission control.
[CT06]のチウとTanは弾力性のない交通のためのトラフィックコントロールを研究するとき公正の概念を再定義するために論争します、弾力性のない流れが入場コントロールなどの他のトラフィックコントロールを採用するよう提案して。
The usefulness of flow-rate fairness has been challenged in [B07] by Briscoe, and defended in [FA08] by Floyd and Allman. In [B07], Briscoe argues that flow-rate fairness should not be a desired goal, and that instead "we should judge fairness mechanisms on how they share out the 'cost' of each user's actions on others". Floyd and
流速公正の有用性は、[B07]でブリスコウによって挑戦されて、[FA08]でフロイドとオールマンによって防御されました。 [B07]では、ブリスコウは流速公正が望んでいる目標であるべきでなくて、代わりに、「私たちは、公正がそれらがどう他のものへの各ユーザの動作の'費用'を分配するかに関するメカニズムであると判断するべきである」と主張します。 そしてフロイド。
Floyd Informational [Page 11] RFC 5166 TMRG, METRICS March 2008
フロイド情報[11ページ]のRFC5166TMRG、2008年の測定基準行進
Allman in [FA08] argue that the current system based on TCP congestion control and flow-rate fairness has been useful in the real world, posing minimal demands on network and economic infrastructure and enabling users to get a share of the network resources.
[FA08]のオールマンは、TCPに基づいた現在のシステム輻輳制御と流速公正が本当の世界で役に立っていると主張します、ネットワークにおける最小量の要求と経済基盤を引き起こして、ユーザがネットワーク資源のシェアを得るのを可能にして。
2.3.3. Comments on Fairness
2.3.3. 公正のコメント
Trade-offs between fairness and throughput: The fairness measures in the section above generally measure both fairness and throughput, giving different weights to each. Potential trade-offs between fairness and throughput are also discussed by Tang, et al. in [TWL06], for a framework where max-min fairness is defined as the most fair. In particular, [TWL06] shows that in some topologies, throughput is proportional to fairness, while in other topologies, throughput is inversely proportional to fairness.
公正とスループットの間のトレードオフ: 異なった重りをそれぞれに与えて、公正はセクションで一般に測定を超えて公正とスループットの両方を測定します。 また、公正とスループットの間の潜在的トレードオフはTangが議論されています、[TWL06]の他、最大分公正が最も公正であると定義される枠組みのために。 特に、[TWL06]は、いくらかのtopologiesでは、スループットが公正に比例しているのを示します、スループットは他のtopologiesで逆に公正に変化していますが。
Fairness and the number of congested links: Some of these fairness metrics are discussed in more detail in [F91]. We note that there is not a clear consensus for the fairness goals, in particular for fairness between flows that traverse different numbers of congested links [F91]. Utility maximization provides one framework for describing this trade-off in fairness.
混雑しているリンクの公正と数: さらに詳細に[F91]でこれらの公正測定基準のいくつかについて議論します。 私たちは、公正目標に関する明確なコンセンサスがないことに注意します、異なった数の混雑しているリンク[F91]を横断する流れの間で特に公正なように。 効用極大化は公正でこのトレードオフについて説明するのに1つの枠組みを提供します。
Fairness and round-trip times: One goal cited in a number of new transport protocols has been that of fairness between flows with different round-trip times [KHR02] [XHR04]. We note that there is not a consensus in the networking community about the desirability of this goal, or about the implications and interactions between this goal and other metrics [FJ92] (Section 3.3). One common argument against the goal of fairness between flows with different round-trip times has been that flows with long round-trip times consume more resources; this aspect is covered by the previous paragraph. Researchers have also noted the difference between the RTT-unfairness of standard TCP, and the greater RTT-unfairness of some proposed modifications to TCP [LLS05].
公正と往復の回: 多くの新しいトランスポート・プロトコルで引用された1つの目標がいろいろな往復の時間[KHR02][XHR04]がある流れの間の公正のものです。 私たちは、この目標と他の測定基準[FJ92](セクション3.3)の間には、この目標の願わしさの周り、または、含意と相互作用の周りに関してコンセンサスがネットワーク共同体にないことに注意します。 いろいろな往復の時間がある流れの間の公正の目標に対する1つの一般的な議論は長い往復の回がある流れが、より多くのリソースを消費するということです。 この局面は前のパラグラフでカバーされています。 また、研究者は標準のTCPのRTT-不公平と、TCP[LLS05]へのいくつかの提案された変更の、より重大なRTT-不公平の違いに注意しました。
Fairness and packet size: One fairness issue is that of the relative fairness for flows with different packet sizes. Many file transfer applications will use the maximum packet size possible; in contrast, low-bandwidth VoIP flows are likely to send small packets, sending a new packet every 10 to 40 ms., to limit delay. Should a small-packet VoIP connection receive the same sending rate in *bytes* per second as a large-packet TCP connection in the same environment, or should it receive the same sending rate in *packets* per second? This fairness issue has been discussed in more detail in [RFC3714], with [RFC4828] also describing the ways that packet size can affect the packet drop rate experienced by a flow.
公正とパケットサイズ: 1公正冊は異なったパケットサイズに従った流れのための相対的な公正のものです。 多くのファイル転送アプリケーションが可能な最大のパケットサイズを使用するでしょう。 対照的に、低バンド幅VoIP流れは小型小包を送りそうです、遅れを制限するためにあらゆる10〜40原稿を新しいパケットに送って。 小型小包VoIP接続が同じ環境における大きいパケットTCP接続として1秒あたりの*バイト*で同じ送付レートを受け取るべきですか、またはそれは1秒あたりの*パケット*に同じ送付レートを受け取るべきですか? さらに詳細に[RFC3714]でこの公正問題について議論しました、また、[RFC4828]がパケットサイズが流れで経験されたパケット低下率に影響できる方法を述べていて。
Floyd Informational [Page 12] RFC 5166 TMRG, METRICS March 2008
フロイド情報[12ページ]のRFC5166TMRG、2008年の測定基準行進
Convergence times: Convergence times concern the time for convergence to fairness between an existing flow and a newly starting one, and are a special concern for environments with high-bandwidth long-delay flows. Convergence times also concern the time for convergence to fairness after a sudden change such as a change in the network path, the competing cross-traffic, or the characteristics of a wireless link. As with fairness, convergence times can matter both between flows of the same protocol, and between flows using different protocols [SLFK03]. One metric used for convergence times is the delta-fair convergence time, defined as the time taken for two flows with the same round-trip time to go from shares of 100/101-th and 1/101-th of the link bandwidth, to having close to fair sharing with shares of (1+delta)/2 and (1-delta)/2 of the link bandwidth [BBFS01]. A similar metric for convergence times measures the convergence time as the number of round-trip times for two flows to reach epsilon- fairness, when starting from a maximally-unfair state [ZKL04].
集合時間: 集合時間は、既存の流れと新たに始まっているものの間の公正への集合のために時間に心配していて、高帯域長時間の遅延流れに伴う環境に関する特別な心配です。 また、集合時間はネットワーク経路の変化、競争している交差交通などの急変の後の公正への集合のための時間、または無線のリンクの特性に関係があります。 公正なら、集合時間は同じプロトコルの流れの間と、そして、異なったプロトコル[SLFK03]を使用する流れの間で重要であることができます。 1つ、メートル法、集合時間に使用されているのは、2にかかる時間が100/101番目のシェアと1/101のリンク第帯域幅から同往復の時間で碁にあふれるリンク帯域幅[BBFS01]の(1+デルタ)/2と(1デルタ)/2のシェアとの公正な共有の近くの有であることと定義されたデルタ晴れている集合時間です。 A同様である、最高に不公平な状態[ZKL04]から始めるとき、2のための往復の回の数としての集合時間が注ぐ測定がイプシロン公正に達するという集合時間において、メートル法です。
2.4. Robustness for Challenging Environments
2.4. やりがいがある環境のための丈夫さ
While congestion control mechanisms are generally evaluated first over environments with static routing in a network of two-way point-to-point links, some environments bring up more challenging problems (e.g., corrupted packets, reordering, variable bandwidth, and mobility) as well as new metrics to be considered (e.g., energy consumption).
一般に、混雑制御機構が最初に、環境の上でスタティックルーティングで両用ポイントツーポイント接続のネットワークで評価されている間、いくつかの環境が、新しい測定基準と同様に(例えば、エネルギー消費)であると考えられるために、よりやりがいがある問題を持って来ます(例えば、パケット、再命令、可変帯域幅、および移動性を崩壊させます)。
Robustness for challenging environments: Robustness needs to be explored for paths with reordering, corruption, variable bandwidth, asymmetric routing, router configuration changes, mobility, and the like [GF04]. In general, the Internet architecture has valued robustness over efficiency, e.g., when there are trade-offs between robustness and the throughput, delay, and fairness metrics described above.
やりがいがある環境のための丈夫さ: 丈夫さは、再命令、不正、可変帯域幅、非対称のルーティング、ルータ構成変更、移動性、および同様のもの[GF04]で経路に探検される必要があります。 一般に、インターネット構造は丈夫さを効率の上評価しました、例えば、上で説明された丈夫さと、スループットと、遅れと、公正測定基準の間にトレードオフがあるとき。
Energy consumption: In mobile environments, the energy consumption for the mobile end-node can be a key metric that is affected by the transport protocol [TM02].
エネルギー消費: 変わりやすい環境で、キーがメートル法であったなら、可動のエンドノードのためのトランスポート・プロトコル[TM02]で影響を受けるエネルギー消費はそうすることができます。
The goodput ratio: For wireless networks, the goodput ratio can be a useful metric, where the goodput ratio can be defined as the useful data delivered to users as a fraction of the total amount of data transmitted on the network. A high goodput ratio indicates an efficient use of the radio spectrum and lower interference with other users.
goodput比: ワイヤレス・ネットワークに、goodput比はaメートル法で役に立つ場合があります、データの総量の部分がネットワークを伝わったようにユーザに送られた役に立つデータとgoodput比を定義できるところで。 高いgoodput比は他のユーザの電波スペクトルと下側の干渉の効率的な使用を示します。
Floyd Informational [Page 13] RFC 5166 TMRG, METRICS March 2008
フロイド情報[13ページ]のRFC5166TMRG、2008年の測定基準行進
2.5. Robustness to Failures and to Misbehaving Users
2.5. 失敗と、そして、ふらちな事をしているユーザへの丈夫さ
One goal is for congestion control mechanisms to be robust to misbehaving users, such as receivers that 'lie' to data senders about the congestion experienced along the path or otherwise attempt to bypass the congestion control mechanisms of the sender [SCWA99]. Another goal is for congestion control mechanisms to be as robust as possible to failures, such as failures of routers in using explicit feedback to end-nodes or failures of end-nodes to follow the prescribed protocols.
1つの目標は混雑制御機構が経路に沿って経験された混雑に関してデータ送付者に'横たわる'受信機などのユーザのふらちな事をするか、またはそうでなければ、送付者[SCWA99]の混雑制御機構を迂回させる試みのふらちな事をするのに強健であることです。 別の目標は混雑制御機構ができるだけ失敗に強健であることです、明白なフィードバックをエンドノードに使用することにおけるルータの失敗や処方されたプロトコルに従わないエンドノードのことのように。
2.6. Deployability
2.6. Deployability
One metric for congestion control mechanisms is their deployability in the current Internet. Metrics related to deployability include the ease of failure diagnosis and the overhead in terms of packet header size or added complexity at end-nodes or routers.
混雑制御機構における、メートル法の1つは現在のインターネットのそれらのdeployabilityです。 deployabilityに関連する測定基準はエンドノードかルータにおけるパケットのヘッダーサイズか加えられた複雑さに関して故障診断の容易さとオーバーヘッドを含んでいます。
One key aspect of deployability concerns the range of deployment needed for a new congestion control mechanism. Consider the following possible deployment requirements:
deployabilityの1つの特徴が新しい混雑制御機構に必要である展開の範囲に関係があります。 ↓これが可能な展開要件であると考えてください:
* Only at the sender (e.g., NewReno in TCP [RFC3782]);
* 送付者(例えば、TCP[RFC3782]のNewReno)だけで。
* Only at the receiver (e.g., delayed acknowledgements in TCP);
* 受信機(例えば、TCPで承認を遅らせる)だけで。
* Both the sender and receiver (e.g., Selective Acknowledgment
(SACK) TCP [RFC2018]);
* 送付者と受信機の両方(例えば、Selective Acknowledgment(SACK)TCP[RFC2018])。
* At a single router (e.g., Random Early Detection (RED) [FJ93]);
* ただ一つのルータ(例えば、Random Early Detection(RED)[FJ93])で。
* All of the routers along the end-to-end path;
* 終わりから端への経路に沿ったルータのすべて。
* Both end-nodes and all routers along the path (e.g., Explicit
Control Protocol (XCP) [KHR02]).
* エンドノードと経路に沿ったすべてのルータの両方(例えば、Explicit Controlプロトコル(XCP)[KHR02])。
Some congestion control mechanisms (e.g., XCP [KHR02], Quick-Start [RFC4782]) may also have deployment issues with IPsec, IP in IP, MPLS, other tunnels, or with non-router queues such as those in Ethernet switches.
また、いくつかの混雑制御機構(例えば、XCP[KHR02]、クィック-始め[RFC4782])には、IPsec、IP、MPLS、他のトンネルのIPかイーサネットスイッチのそれらなどの非ルータ待ち行列の展開問題があるかもしれません。
Floyd Informational [Page 14] RFC 5166 TMRG, METRICS March 2008
フロイド情報[14ページ]のRFC5166TMRG、2008年の測定基準行進
Another deployability issue concerns the complexity of the code. How complex is the code required to implement the mechanism in software? Is floating point math required? How much new state must be kept to implement the new mechanism, and who holds that state, the routers or the end-nodes? We note that we don't suggest these questions as ways to reduce the deployability metric to a single number; we suggest them as issues that could be considered in evaluating the deployability of a proposed congestion control mechanism.
別のdeployability問題はコードの複雑さに関係があります。 ソフトウェアでメカニズムを実行するのに必要であるコードはどれくらい複雑ですか? 浮動小数点数学が必要ですか? 新しいメカニズムを実行するためにどのくらいの新しい状態を維持しなければならないか、そして、だれがその状態、ルータまたはエンドノードを保持しますか? 私たちは、1つの数へのメートル法のdeployabilityを減少させる方法としてこれらの質問を勧めないことに注意します。 私たちは提案された混雑制御機構のdeployabilityを評価する際に考えることができた問題としてそれらを勧めます。
2.7. Metrics for Specific Types of Transport
2.7. 特定のタイプの輸送のための測定基準
In some cases, modified metrics are needed for evaluating transport protocols intended for quality-of-service (QoS)-enabled environments or for below-best-effort traffic [VKD02] [KK03].
いくつかの場合、変更された測定基準がサービスの質(QoS)の可能にされた環境か以下のベストエフォート型交通[VKD02][KK03]に意図するトランスポート・プロトコルを評価するのに必要です。
2.8. User-Based Metrics
2.8. ユーザベースの測定基準
An alternate approach that has been proposed for the evaluation of congestion control mechanisms would be to evaluate in terms of user metrics, such as user satisfaction or in terms of application-specific utility functions. Such an approach would require the definition of a range of user metrics or of application-specific utility functions for the range of applications under consideration (e.g., FTP, HTTP, VoIP).
混雑制御機構の評価のために提案された交互のアプローチはユーザ満足などのユーザ測定基準かアプリケーション特有のユーティリティで機能を評価するだろうことです。 そのようなアプローチはさまざまなユーザ測定基準かアプリケーション特有のユーティリティ機能の定義を考慮(例えば、FTP、HTTP、VoIP)でアプリケーションの範囲に必要とするでしょう。
3. Metrics in the IP Performance Metrics (IPPM) Working Group
3. IPパフォーマンス測定基準(IPPM)作業部会での測定基準
The IPPM Working Group [IPPM] was established to define performance metrics to be used by network operators, end users, or independent testing groups. The metrics include metrics for connectivity [RFC2678], delay and loss [RFC2679], [RFC2680], and [RFC2681], delay variation [RFC3393], loss patterns [RFC3357], packet reordering [RFC4737], bulk transfer capacity [RFC3148], and link capacity [RFC5136]. The IPPM documents give concrete, well-defined metrics, along with a methodology for measuring the metric. The metrics discussed in this document have a different purpose from the IPPM metrics; in this document, we are discussing metrics as used in analysis, simulations, and experiments for the evaluation of congestion control mechanisms. Further, we are discussing these metrics in a general sense, rather than looking for specific concrete definitions for each metric. However, there are many cases where the metric definitions from IPPM could be useful, for specific issues of how to measure these metrics in simulations, or in testbeds, and for providing common definitions for talking about these metrics.
IPPM作業部会[IPPM]は、ネットワーク・オペレータ、エンドユーザ、または独立しているテストグループによって使用されるように性能測定基準を定義するために設立されました。 測定基準は接続性[RFC2678]、遅れ、および損失[RFC2679]のための測定基準、[RFC2680]、[RFC2681]、遅れ変化[RFC3393]、損失パターン[RFC3357]、パケット再命令[RFC4737]、バルク転送容量[RFC3148]、およびリンク容量[RFC5136]を含んでいます。 IPPMドキュメントは、メートル法を測定するために方法論に伴う具体的で、明確な測定基準を与えます。 本書では議論した測定基準はIPPM測定基準からの異なる役割を持っています。 本書では、私たちは混雑制御機構の評価に分析、シミュレーション、および実験に使用されるように測定基準について議論しています。さらに、それぞれのための特定の具体的な定義を探すより一般的な意味ではむしろメートル法でこれらの測定基準について議論しています。 しかしながら、多くのケースがIPPMからのメートル法の定義がシミュレーション、またはテストベッドでどうこれらの測定基準を測定するかに関する特定の問題と、これらの測定基準に関して話すのに一般的な定義を提供することの役に立つかもしれないところにあります。
Floyd Informational [Page 15] RFC 5166 TMRG, METRICS March 2008
フロイド情報[15ページ]のRFC5166TMRG、2008年の測定基準行進
4. Comments on Methodology
4. 方法論のコメント
The types of scenarios that are used to test specific metrics, and the range of parameters that it is useful to consider, will be discussed in separate documents, e.g., along with specific scenarios for use in evaluating congestion control mechanisms.
別々のドキュメントで特定の測定基準をテストするのに使用されるシナリオのタイプ、および考えるのが役に立つパラメタの範囲について議論するでしょう、例えば、混雑制御機構を評価することにおける使用のための特定のシナリオと共に。
We note that it can be important to evaluate metrics over a wide range of environments, with a range of link bandwidths, congestion levels, and levels of statistical multiplexing. It is also important to evaluate congestion control mechanisms in a range of scenarios, including typical ranges of connection sizes and round-trip times [FK02]. It is also useful to compare metrics for new or modified transport protocols with those of the current standards for TCP.
私たちは、さまざまな環境の上で測定基準を評価するのが重要である場合があることに注意します、さまざまなリンク帯域幅、混雑レベル、および統計的多重化のレベルで。 また、さまざまなシナリオで混雑制御機構を評価するのも重要です、典型的な範囲の接続サイズと往復の倍[FK02]を含んでいて。 また、新しいか変更されたトランスポート・プロトコルのためにTCPの現在の規格のものと測定基準を比較するのも役に立ちます。
As an example from the literature on evaluating transport protocols, Li, et al. in "Experimental Evaluation of TCP Protocols for High- Speed Networks" [LLS05] focus on the performance of TCP in high- speed networks, and consider metrics for aggregate throughput, loss rates, fairness (including fairness between flows with different round-trip times), response times (including convergence times), and incremental deployment. More general references on methodology include [J91]. Papers that discuss the range of metrics for evaluating congestion control include [MTZ04].
評価に関する文学からの例として、プロトコル、李、高い速度ネットワークにおける、TCPの性能の「高い速度ネットワークのためのTCPプロトコルの実験的な評価」[LLS05]焦点の他を輸送してください、そして、集合スループット、損失率、公正(いろいろな往復の時間で流れの間の公正を含んでいる)、応答時間(集合時間を含んでいる)、および増加の展開のために測定基準を考えてください。 方法論に関する、より一般的な参照は[J91]を含んでいます。 輻輳制御を評価するために測定基準の範囲について議論する論文が[MTZ04]を含んでいます。
5. Security Considerations
5. セキュリティ問題
Section 2.5 discusses the robustness of congestion control mechanisms to failures and to misbehaving users. Transport protocols also have other security concerns that are unrelated to congestion control mechanisms; these are not discussed in this document.
セクション2.5は失敗と、そして、ふらちな事をしているユーザに混雑制御機構の丈夫さについて論じます。 また、トランスポート・プロトコルには、混雑制御機構に関係ない他の安全上の配慮があります。 本書ではこれらについて議論しません。
6. Acknowledgements
6. 承認
Thanks to Lachlan Andrew, Mark Allman, Armando Caro, Dah Ming Chiu, Eric Coe, Dado Colussi, Wesley Eddy, Aaron Falk, Nelson Fonseca, Janardhan Iyengar, Doug Leith, Sara Landstrom, Tony Li, Saverio Mascolo, Sean Moore, Injong Rhee, David Ros, Juergen Schoenwaelder, Andras Veres, Michael Welzl, and Damon Wischik, and members of the Transport Modeling Research Group for feedback and contributions.
ラクランアンドリュー、マーク・オールマン、アルマンドケアロ、Dah明のチウ、エリック・コー、Dado Colussi、ウエスリーEddy、アーロン・フォーク、ネルソン・フォンセカ、Janardhanアイアンガー、ダグ・リース、サラ・ランドストローム、トニー・李、Saverio Mascolo、ショーン・ムーア、Injong Rhee、デヴィッド・ロス、ユルゲンSchoenwaelder、Andras Veres、マイケルWelzl、およびダモンWischikへの感謝、およびフィードバックと貢献のためのTransport Modeling Research Groupのメンバー。
Floyd Informational [Page 16] RFC 5166 TMRG, METRICS March 2008
フロイド情報[16ページ]のRFC5166TMRG、2008年の測定基準行進
7. Informative References
7. 有益な参照
[AEO03] M. Allman, W. Eddy, and S. Ostermann, Estimating Loss Rates
With TCP, ACM Performance Evaluation Review, 31(3),
December 2003.
[AEO03] S.オステルマン、M.オールマン、W.は渦巻いて、損失を見積もっているのは2003年12月にTCP、ACMと共に業績評価がレビュー、31(3)であると評定します。
[BB01] D. Bansal and H. Balakrishnan, Binomial Congestion Control
Algorithms, IEEE Infocom, April 2001.
[BB01] D.BansalとH.Balakrishnan、二項式の混雑は2001年4月にアルゴリズム、IEEE Infocomを制御します。
[BBFS01] D. Bansal, H. Balakrishnan, S. Floyd, and S. Shenker,
Dynamic Behavior of Slowly-Responsive Congestion Control
Algorithms, SIGCOMM 2001.
[BBFS01] SIGCOMM2001、ゆっくり敏感な混雑のD.Bansal、H.Balakrishnan、S.フロイド、およびS.Shenker、動的挙動はアルゴリズムを制御します。
[BJ81] K. Bharath-Kumar and J. Jeffrey, A New Approach to
Performance-Oriented Flow Control, IEEE Transactions on
Communications, Vol.29 N.4, April 1981.
パフォーマンス指向のフロー制御、コミュニケーションにおけるIEEE取引、Vol.29 N.4(1981年4月)への[BJ81]K.Bharath-クマーとJ.ジェフリー、新しいアプローチ。
[B07] B. Briscoe, "Flow Rate Fairness: Dismantling a Religion",
Computer Communications Review, V.37 N.2, April 2007.
[B07]B.ブリスコウ、「流れは公正を評定します」。 「宗教を解体し」て、コンピュータコミュニケーションはV.37 N.2、2007年4月、再検討されます。
[CRM05] D. Colussi, A New Approach to TCP-Fairness, Report C-2005-
49, University of Helsinki, Finland, 2005.
[CRM05]D.Colussi(TCP-公正への新しいアプローチ)はC-2005- 49、ヘルシンキ(フィンランド)2005年の大学を報告します。
[CT06] D. Chiu and A. Tam, Redefining Fairness in the Study of
TCP-friendly Traffic Controls, Technical Report, 2006.
[CT06] TCPに優しいトラフィックコントロール、技術報告書、2006年の研究に公正を再定義するD.チウとA.タム。
[DM06] N. Dukkipati and N. McKeown, Why Flow-Completion Time is
the Right Metric for Congestion Control, ACM SIGCOMM,
January 2006.
[DM06] 2006年1月にN.DukkipatiとN.マキューン、Why Flow-完成TimeはCongestion Control、ACM SIGCOMMのためのRight Metricです。
[F91] S. Floyd, Connections with Multiple Congested Gateways in
Packet-Switched Networks Part 1: One-way Traffic, Computer
Communication Review, Vol.21 No.5, October 1991, p. 30-47.
[F91]S.フロイド、パケット交換網第1部における複数の混雑しているゲートウェイがあるコネクションズ: 片道Traffic、コンピュータCommunication Review、Vol.21No.5、1991年10月、p。 30-47.
[FA08] S. Floyd and M. Allman, Comments on the Usefulness of
Simple Best-Effort Traffic, Work in Progress, January 2007.
[FA08] S.フロイドとM.オールマン(簡単なベストエフォート型交通の有用性のコメント)は進歩、2007年1月に働いています。
[FF99] Floyd, S., and Fall, K., "Promoting the Use of End-to-End
Congestion Control in the Internet", IEEE/ACM Transactions
on Networking, August 1999.
[FF99] K. フロイド、S.と秋、ネットワーク(1999年8月)の「インターネットでの終わりからエンドへの輻輳制御の使用を促進すること」でのIEEE/ACM取引。
[FHP00] S. Floyd, M. Handley, and J. Padhye, A Comparison of
Equation-Based and AIMD Congestion Control, May 2000. URL
http://www.icir.org/tfrc/.
[FHP00] 方程式ベースとAIMD混雑のS.フロイド、M.ハンドレー、およびJ.Padhye、比較は2000年5月に制御されます。 URL http://www.icir.org/tfrc/ 。
[FHPW00] S. Floyd, M. Handley, J. Padhye, and J. Widmer, Equation-
Based Congestion Control for Unicast Applications, SIGCOMM
2000, August 2000.
[FHPW00] S.フロイド、M.ハンドレー、J.Padhye、およびJ.ウィトマー、方程式のベースの混雑はユニキャストアプリケーションのために制御されます、SIGCOMM2000、2000年8月。
Floyd Informational [Page 17] RFC 5166 TMRG, METRICS March 2008
フロイド情報[17ページ]のRFC5166TMRG、2008年の測定基準行進
[FJ92] S. Floyd and V. Jacobson, On Traffic Phase Effects in
Packet-Switched Gateways, Internetworking: Research and
Experience, V.3 N.3, September 1992, p.115-156.
[FJ92] パケットで切り換えられたゲートウェイ、インターネットワーキングにおける交通フェーズ効果のS.フロイドとV.ジェーコブソン: 研究とExperience、V.3 N.3、1992年9月、p.115-156。
[FJ93] S. Floyd and V. Jacobson, Random Early Detection gateways
for Congestion Avoidance, IEEE/ACM Transactions on
Networking, V.1 N.4, August 1993,
[FJ93] Congestion Avoidance、IEEE/ACM TransactionsのためのNetworking、V.1 N.4、1993年8月のS.フロイドとV.ジェーコブソン、Random Early Detectionゲートウェイ
[FK02] S. Floyd and E. Kohler, Internet Research Needs Better
Models, Hotnets-I. October 2002.
[FK02] S.フロイドとE.コーラー、インターネット研究は、より良いモデル、Hotnets-Iを必要とします。 2002年10月。
[FK07] S. Floyd and E. Kohler, "Tools for the Evaluation of
Simulation and Testbed Scenarios", Work in Progress,
February 2008.
[FK07] 「シミュレーションとテストベッドシナリオの評価のためのツール」というS.フロイドとE.コーラーは進歩、2008年2月に働いています。
[GF04] A. Gurtov and S. Floyd, Modeling Wireless Links for
Transport Protocols, ACM CCR, 34(2):85-96, April 2004.
[GF04] A.GurtovとS.フロイド、モデル無線電信は85-96と、2004年4月にトランスポート・プロトコル、ACM CCR、34(2)のために以下をリンクします。
[HKLRX06] S. Ha, Y. Kim, L. Le, I. Rhee, and L. Xu, A Step Toward
Realistic Evaluation of High-speed TCP Protocols, technical
report, North Carolina State University, January 2006.
[HKLRX06] High-速度TCPプロトコル、技術報告書、ノースカロライナ州立大学(2006年1月)のS.Ha、Y.キム、L.Le、I.Rhee、およびL.シュー、A Step Toward Realistic Evaluation。
[HG86] E. Hahne and R. Gallager, Round Robin Scheduling for Fair
Flow Control in Data Communications Networks, IEEE
International Conference on Communications, June 1986.
[HG86] E.HahneとR.Gallager、データ通信網における公正なフロー制御のためにロビンSchedulingを一周させてください、コミュニケーションに関するIEEE国際会議、1986年6月。
[IPPM] IP Performance Metrics (IPPM) Working Group, URL
http://www.ietf.org/html.charters/ippm-charter.html.
[IPPM]IPパフォーマンス測定基準(IPPM)作業部会、URL http://www.ietf.org/html.charters/ippm-charter.html 。
[J91] R. Jain, The Art of Computer Systems Performance Analysis:
Techniques for Experimental Design, Measurement,
Simulation, and Modeling, John Wiley & Sons, 1991.
[J91]R.ジャイナ教徒、コンピュータ・システム機能解析の芸術: 実験計画法と測定、シミュレーションとモデル、ジョンワイリーと息子のためのテクニック、1991。
[JCH84] R. Jain, D.M. Chiu, and W. Hawe, A Quantitative Measure of
Fairness and Discrimination for Resource Allocation in
Shared Systems, DEC TR-301, Littleton, MA: Digital
Equipment Corporation, 1984.
[JCH84] R.ジャイナ教徒、D.M.チウ、およびW.Haweと公正の量的な測定と共有システムの資源配分、12月のTR-301、リトルトン、MAへの区別: DEC、1984。
[JWL04] C. Jin, D. Wei, and S. Low, FAST TCP: Motivation,
Architecture, Algorithms, Performance, IEEE INFOCOM, March
2004.
[JWL04] C.チン、D.ウェイ、およびS.の低くて、速いTCP: 動機、構造、アルゴリズム、パフォーマンス、IEEE INFOCOM、2004年3月。
[K01] F. Kelly, Mathematical Modelling of the Internet,
"Mathematics Unlimited - 2001 and Beyond" (Editors B.
Engquist and W. Schmid), Springer-Verlag, Berlin, pp.
685-702, 2001.
[K01]F.ケリー、インターネットの数学のモデル化、「数学無制限--、2001と以遠、」(エディターズB.EngquistとW.シュミッド), 追出石-Verlag、ベルリンのページ 685-702, 2001.
Floyd Informational [Page 18] RFC 5166 TMRG, METRICS March 2008
フロイド情報[18ページ]のRFC5166TMRG、2008年の測定基準行進
[KHR02] D. Katabi, M. Handley, and C. Rohrs, Congestion Control for
High Bandwidth-Delay Product Networks, ACM Sigcomm, 2002.
[KHR02] D.Katabi、M.ハンドレー、およびC.レールス、混雑は高帯域遅れ製品ネットワーク、ACM Sigcomm、2002年のために制御されます。
[KK03] A. Kuzmanovic and E. W. Knightly, TCP-LP: A Distributed
Algorithm for Low Priority Data Transfer, IEEE INFOCOM
2003, April 2003.
[KK03]A.KuzmanovicとE.W.ナイトである、TCP-LP: 低い優先権データ転送、IEEE INFOCOM2003のための2003年4月の分配されたアルゴリズム。
[KMT98] F. Kelly, A. Maulloo and D. Tan, Rate Control in
Communication Networks: Shadow Prices, Proportional
Fairness and Stability. Journal of the Operational
Research Society 49, pp. 237-252, 1998.
[KMT98] F.ケリー、A.Maulloo、およびD.日焼けは通信ネットワークでコントロールを評定します: 価格、比例している公正、および安定性を影でおおってください。 Operational Research Society49のジャーナル、ページ 237-252, 1998.
[KS03] S. Kunniyur and R. Srikant, End-to-end Congestion Control
Schemes: Utility Functions, Random Losses and ECN Marks,
IEEE/ACM Transactions on Networking, 11(5):689-702, October
2003.
[KS03] S.KunniyurとR.Srikant、終わりからエンドへの輻輳制御は計画されます: ネットワーク、11(5)におけるユーティリティ機能と無作為の損失と電子証券取引ネットワークのマーク、IEEE/ACM取引: 689-702と、2003年10月。
[LLS05] Y-T. Li, D. Leith, and R. Shorten, Experimental Evaluation
of TCP Protocols for High-Speed Networks, Hamilton
Institute, 2005. URL
http://www.hamilton.ie/net/eval/results_HI2005.pdf.
[LLS05]Y-T。 ハミルトン、李、D.リース、およびR.は短くされて、TCPの実験的な評価は高速ネットワークのためのプロトコルです。研究所、2005。 URL http://www.hamilton.ie/net/eval/results_HI2005.pdf 。
[MS91] D. Mitra and J. Seery, Dynamic Adaptive Windows for High
Speed Data Networks with Multiple Paths and Propagation
Delays, INFOCOM '91, pp 39-48.
[MS91] D.ミトラとJ.Seery、Multiple PathsとPropagation DelaysとHigh Speed Data NetworksのためのDynamic Adaptive Windows、INFOCOM91年(pp39-48)。
[MTZ04] L. Mamatas, V. Tsaoussidis, and C. Zhang, Approaches to
Congestion Control in Packet Networks, 2004.
[MTZ04] L.Mamatas、対TsaoussidisとC.チャンはパケット網、2004年に輻輳制御にアプローチします。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018] マシスとM.とMahdaviとJ.とフロイド、S.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年10月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680]Almes、G.、Kalidindi、S.、およびM.Zekauskas、「IPPMにおける、メートル法のA One-道のパケット損失」、RFC2680、1999年9月。
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, September 1999.
[RFC2678] Mahdavi、J.、および「測定の接続性のためのIPPM測定基準」、RFC2678、1999年9月対パクソン
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679]Almes、G.、Kalidindi、S.、およびM.Zekauskas、「IPPMにおける、メートル法のA One-道の遅れ」、RFC2679、1999年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999.
1999年9月の[RFC2681]AlmesとG.とKalidindi、S.とM.Zekauskas、「IPPMにおける、メートル法の往復の遅れ」RFC2681。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。
Floyd Informational [Page 19] RFC 5166 TMRG, METRICS March 2008
フロイド情報[19ページ]のRFC5166TMRG、2008年の測定基準行進
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining
Empirical Bulk Transfer Capacity Metrics", RFC 3148, July
2001.
[RFC3148] マシスとM.とM.オールマン、「実証的なバルク転送容量測定基準を定義するための枠組み」、RFC3148、2001年7月。
[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月)。
[RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
Metrics", RFC 3357, August 2002.
[RFC3357] KoodliとR.とR.Ravikanth、「片道損失型見本測定基準」、RFC3357、2002年8月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.
[RFC3393]デミチェリスとC.とP.Chimento、「IPパフォーマンス測定基準(IPPM)における、メートル法のIPパケット遅れ変化」、RFC3393、2002年11月。
[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月。
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", RFC
3611, November 2003.
[RFC3611]フリードマン、T.(エド)、カセレス、R.(エド)、およびA.クラーク(エド)、「RTP制御プロトコルはレポート(RTCP XR)を広げました」、RFC3611、2003年11月。
[RFC3714] Floyd, S., Ed., and J. Kempf, Ed., "IAB Concerns Regarding
Congestion Control for Voice Traffic in the Internet", RFC
3714, March 2004.
[RFC3714]フロイド、S.(エド)、およびJ.ケンフ(エド)、「混雑に関するIAB心配はインターネットの音声トラヒックに制御します」、RFC3714、2004年3月。
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
Modification to TCP's Fast Recovery Algorithm", RFC 3782,
April 2004.
[RFC3782] フロイド、S.、ヘンダーソン、T.、およびA.Gurtov、「TCPの速い回復アルゴリズムへのNewReno変更」、RFC3782、2004年4月。
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S.,
and J. Perser, "Packet Reordering Metrics", RFC 4737,
November 2006.
[RFC4737] モートンとA.とCiavattoneとL.とラマチャンドランとG.とShalunov、S.とJ.Perser、「パケットReordering測定基準」、RFC4737、2006年11月。
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
Start for TCP and IP", RFC 4782, January 2007.
[RFC4782] フロイド、S.、オールマン、M.、ジャイナ教徒、A.、およびP.Sarolahti、「TCPとIPのための迅速な始め」、RFC4782、2007年1月。
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC):
The Small-Packet (SP) Variant", RFC 4828, April 2007.
[RFC4828] フロイド、S.、およびE.コーラー、「TCPの好意的なレートは(TFRC)を制御します」。 「小型小包(SP)異形」、RFC4828、2007年4月。
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC
5136, February 2008.
[RFC5136] ChimentoとP.とJ.Ishac、「ネットワーク容量を定義します」、RFC5136、2008年2月。
[RX05] I. Rhee and L. Xu, CUBIC: A New TCP-Friendly High-Speed TCP
Variant, PFLDnet 2005.
[RX05] I.RheeとL.シュー、立方体: 新しいTCPに優しい高速TCP異形、PFLDnet2005。
Floyd Informational [Page 20] RFC 5166 TMRG, METRICS March 2008
フロイド情報[20ページ]のRFC5166TMRG、2008年の測定基準行進
[SAF06] P. Sarolahti, M. Allman, and S. Floyd, Determining an
Appropriate Sending Rate Over an Underutilized Network
Path, Computer Networks, September 2006.
[SAF06] 適切な送付を決定するP.Sarolahti、M.オールマン、およびS.フロイドがUnderutilizedネットワーク経路の上で評価します、コンピュータネットワーク、2006年9月。
[SLFK03] R.N. Shorten, D.J. Leith, J. Foy, and R. Kilduff, Analysis
and Design of Congestion Control in Synchronised
Communication Networks. Proc. 12th Yale Workshop on
Adaptive & Learning Systems, May 2003.
D.J.、短くしてください。[SLFK03] R. N. 混雑のリース、J.フォイ、R.キルダフ、分析、およびデザインは連動した通信ネットワークで制御されます。 Proc。 2003年5月の適応型の、そして、学んでいるシステムに関する第12エール大学ワークショップ。
[SCWA99] S. Savage, N. Cardwell, D. Wetherall, and T. Anderson, TCP
Congestion Control with a Misbehaving Receiver, ACM
Computer Communications Review, October 1999.
[SCWA99]S.サヴェージ、N.カードウェル、D.Wetherall、およびT.アンダーソン、TCP混雑はふらちな事する受信機で制御されます、ACMコンピュータコミュニケーションレビュー、1999年10月。
[TM02] V. Tsaoussidis and I. Matta, Open Issues of TCP for Mobile
Computing, Journal of Wireless Communications and Mobile
Computing: Special Issue on Reliable Transport Protocols
for Mobile Computing, February 2002.
[TM02] TsaoussidisとI.マッタに対して、モバイル・コンピューティングのためのTCPの問題、無線通信とモバイル・コンピューティングのジャーナルを開いてください: 2002年2月のモバイル・コンピューティングのための信頼できるトランスポート・プロトコルにおける増刊。
[TWL06] A. Tang, J. Wang and S. H. Low. Counter-Intuitive
Throughput Behaviors in Networks Under End-to-End Control,
IEEE/ACM Transactions on Networking, 14(2):355-368, April
2006.
[TWL06] A.ピリッとする味、J.ワング、およびS.H.安値。 終わりからエンドへのコントロールの下におけるネットワークにおける直観に反しているスループットの振舞い、ネットワーク、14(2)におけるIEEE/ACM取引: 355-368と、2006年4月。
[WCL05] D. X. Wei, P. Cao and S. H. Low, Time for a TCP Benchmark
Suite?, Technical Report, Caltech CS, Stanford EAS,
Caltech, 2005.
[WCL05]D.X.ウェイとP.ツァオとS.H.安値、TCPベンチマークスイートへの時間--、技術報告書、カリフォルニア工科大学Cs、スタンフォードEASカリフォルニア工科大学、2005
[VKD02] A. Venkataramani, R. Kokku, and M. Dahlin, TCP Nice: A
Mechanism for Background Transfers, Fifth USENIX Symposium
on Operating System Design and Implementation (OSDI), 2002.
[VKD02] A.Venkataramani、R.Kokku、およびM.Dahlin、TCPニース: バックグラウンド転送、オペレーティングシステム設計と実装(OSDI)、2002に関する第5USENIXシンポジウムのためのメカニズム。
[XHR04] L. Xu, K. Harfoush, and I. Rhee, Binary Increase Congestion
Control for Fast, Long Distance Networks, Infocom 2004.
[XHR04] L.シュー、K.Harfoush、およびI.Rhee、バイナリーは速くて、長い距離ネットワーク、Infocom2004のために輻輳制御を増加させます。
[YKL01] Y. Yang, M. Kim, and S. Lam, Transient Behaviors of TCP-
friendly Congestion Control Protocols, Infocom 2001.
[YKL01] TCPの好意的なCongestion Controlプロトコル、Infocom2001のY.Yang、M.キム、およびS.ラム、Transient Behaviors。
[ZKL04] Y. Zhang, S.-R. Kang, and D. Loguinov, Delayed Stability
and Performance of Distributed Congestion Control, ACM
SIGCOMM, August 2004.
[ZKL04]Y.チャン、S.R。 カン、およびD.Loguinovは2004年8月に分配された輻輳制御、ACM SIGCOMMの安定性とパフォーマンスを遅らせました。
Floyd Informational [Page 21] RFC 5166 TMRG, METRICS March 2008
フロイド情報[21ページ]のRFC5166TMRG、2008年の測定基準行進
Author's Address
作者のアドレス
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
Floyd Informational [Page 22] RFC 5166 TMRG, METRICS March 2008
フロイド情報[22ページ]のRFC5166TMRG、2008年の測定基準行進
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78と http://www.rfc-editor.org/copyright.html に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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に情報を記述してください。
Floyd Informational [Page 23]
フロイドInformationalです。[23ページ]
一覧
スポンサーリンク
