RFC 5166 - Metrics for the Evaluation of Congestion Control Mechanisms 日本語訳

URL : https://tools.ietf.org/html/rfc5166
タイトル : RFC 5166 - 輻輳制御機構の評価のためのメトリクス
翻訳編集 : 自動生成

Network Working Group                                      S. Floyd, Ed.
Request for Comments: 5166                                    March 2008
Category: Informational

      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インターネット標準ではありません。これは、インターネット研究タスクフォースのTMRG研究グループの1つまたは複数のメンバーの個々の意見（複数可）を表しています。これは、将来的にはIRTF研究グループの合意文書として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に提案された修正の、アプリケーションレベルの輻輳制御の、およびルータのアクティブキュー管理（AQM）メカニズムの指標を含みます。この文書では、我々はトランスポートプロトコルの評価に使用するモデルの改善を目的とした一連の文書で初めてです。

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.

この文書では、輸送モデリング研究グループ（TMRG）の産物であり、研究グループ（RG）の多くのメンバーからの詳細なフィードバックを受けています。文書を明確にしようとして、輻輳制御メカニズムが最適化するように設計されるべきメトリクスに関する研究コミュニティ（またはIETFコミュニティ、ベンダー・コミュニティ、操作コミュニティ、または任意の他のコミュニティ）内のコンセンサスは、必ずしも存在しませんスループットと遅延、競合フロー間の公平性、等の間のトレードオフの点から好ましいです。しかし、我々は、輻輳制御メカニズムではなく、単一のメトリックの最適化の観点より、指標の範囲との間のトレードオフの観点から評価されるべきであることは明らかなコンセンサスがあると信じています。

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. 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 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.

私たちは、集約トラフィック（アカウントに、ネットワーク内のトラフィックを競争上のフローの影響を取って）だけでなく、大量のデータ転送のための高スループットの、かつインタラクティブなため、低遅延の異なるアプリケーションやトランスポートプロトコルの異質な目標（例えば、のための評価指標を検討します音声またはビデオ）。異なるトランスポートプロトコルやAQMメカニズムは、フローごとのスループットおよび無線リンク上、および競合するトラフィックとの公平性への注目度が異なると堅牢性のために最適化された別の用に最適化された1つのトランスポートプロトコルで、メトリックの異なるセットを最適化する目標を持っているかもしれません。我々は、機構Xは、メトリックAを最適化するのが得意であることを指摘し、この文書は、たとえば、メトリックの広い範囲のために提案された輻輳制御メカニズムを評価するステップとして使用することを願っていますが、メトリック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.

それ以降の文書は、研究コミュニティの現在のベストプラクティスに基づいて、トランスポートプロトコルの評価のための輻輳制御機構のシミュレーションとテストベッドのシナリオのセットを提示するために計画されています。これらは、完全または最終ベンチマークテストスイートであるためには、単に輻輳制御メカニズムを評価する研究者によって使用される多くの一歩であることを意図していません。それ以降の文書はまた、シナリオのこれらのセットを使用する際の方法論に予定されています。

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;

o Deployability;

展開性O;

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.

当社は、以下のこれらのそれぞれを考えます。メトリックの多くは、ネットワークベースの、フローベース、およびユーザーベースの解釈を持っています。例えば、ネットワークベースのメトリックは、ファイル転送やインタラクティブなトラフィックのためのエンドツーエンド遅延およびパケットドロップ率、およびUSER-のためのエンドツーエンドの転送時間を考慮することができる総帯域幅と集約ドロップ率、フローベースの指標を考慮することができますベースのメトリックは、マルチメディア体験をユーザーの待ち時間やユーザーの満足度を考慮することができます。この文書に記載されている私たちの主な目標は、関連することができ、かつそれぞれ一般的なメトリックを使用するための最も適切な方法論に法律を制定していないメトリックのセットを説明することです。

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.

そのため、スループット、遅延、および損失率の間に明確なトレードオフのために、それは一緒にこれら三つの指標を考慮すると便利です。トレードオフは、ルータのキュー管理の点で最も明確です。キューは、遅延と損失率、または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:

フローベースのメトリックの代わりに、ルータベースのメトリックを使用して、フローごとのスループット、遅延、損失率との関係は、多くの場合、トランスポートプロトコル自体で与えることができます。例えば、TCPで、秒あたりのパケットで送信レート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]について。

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.

スループットは、接続ごとの転送時間のフローベースのメトリックとして、およびユーティリティ機能やユーザーの待ち時間のユーザーベースのメトリックとして、集約リンク利用率のルータベースのメトリックとして測定することができます。アプリケーションの要求に、その他のメトリックの制約を受け、スループットを最大化するための最も輻輳制御メカニズムの明確な目標です。

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".

スループットは、スループットは、リンク利用率または秒あたりのバイト数で流量であるグッドプットから時々区別されます。グッドプットは、また、秒あたりのバイト数で測定され、有用なトラフィックからなるスループットのサブセットです。すなわち、「グッドプット」除外は、それらが完全なパケットに再組み立てすることができないため、受信側でドロップされたパケット、下流ドロップされたパケット、パケットのフラグメントまたはATMセルを複製し、等、です。一般的には、この文書では、スループットとグッドプットを区別し、一般的な用語「スループット」を使用しません。

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].

いくつかの状況では、他のコンテキストでは、フロー毎のスループットの分布を考慮することが必要かもしれないが、総スループットまたは平均フローごとのスループット[DM06]を検討するのに十分であるかもしれません。一部の研究者は、ユーザーのユーティリティは、一般的に、ユーザのスループット[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）のトラフィックはすぐにアイドル期間後に受信した帯域幅の量に敏感です。したがって、スループットのためのユーザ・メトリックは、単に、接続ごとの転送時間よりも複雑であることができます。

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.

スループットように、遅延は、時間の経過、またはパケットごとの転送時間の点でフローベースのメトリックとしてキューイング遅延のルータベースの指標として測定することができます。パケットごとの遅延は、パケットを送信するためのトランスポートプロトコルを待っている送信者に遅延を含めることができます。信頼性の高い転送のために、アプリケーションから見たパケットごとの転送時間が失われたパケットを再送する可能性遅延が含まれています。

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.

バルクデータ転送アプリケーションのユーザーは、これまでのところ、彼らは接続ごとの転送時間に影響を与えるように、パケットごとの転送時間を気にすることがあります。スペクトルのもう一方の端には、ストリーミングメディアのユーザーのために、パケットごとの遅延が重大な問題になることができます。いくつかのケースでは、平均遅延はユーザへの関心のメトリックをキャプチャしない可能性があることに注意してください。例えば、一部のユーザーは、最悪の場合の遅延について、または遅延分布の裾を気にすることがあります。

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.

すべてによって共有されているルータでキューイング遅延するFIFO（先入れ先出し）キューで流れることに注意してください。したがって、バルクデータ転送によって誘発されるルータ・ベースのキューイング遅延は、バルクデータ自体は、パケットごとの転送時間に関係していない転送する場合にも重要であることができます。

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.

パケットロス率は、ネットワークベースとして、またはフローベースの指標として測定することができます。

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].

個々の流れのための輻輳制御機構の性能に対するパケット損失またはECNマーク（明示的輻輳通知）[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 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].

他のユーザーが直接パケット損失率を気かもしれないが、一部のユーザーは、唯一のこれまでのところ、それが影響して接続ごとの転送時間でパケット損失率を気にすることがあります。 RFC 3611は、RTP制御プロトコル拡張レポートは、バーストメトリックのセットが含まれてRTP制御プロトコル拡張レポート（RTCP XR）と呼ばれるのVoIPパフォーマンス報告基準について説明します。 RFC 3611においては、バーストは最大シーケンスが開始し、失われたパケットで終了し、Gminのシーケンスまたは[RFC3611]を失っていない複数のパケットを含めないように定義されます。 RFC 3611におけるバーストメトリックは（バースト密度（バースト内のパケットの割合）、ギャップ密度、バースト持続時間（秒バーストの平均期間）（バースト間のギャップ内のパケットの割合）、及びギャップ持続時間から成り秒のギャップの平均所要時間）。 RFC 3357は、キャプチャロスパターンがインターネット[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]に配信される前に下流ドロップされたパケットを搬送することにより、乏しい帯域幅を浪費混雑リンクをもたらす可能性があります。我々はまた、いくつかのケースでは、再送率が低くても、パケットのドロップ率[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.

輻輳制御機構の設計における重要な関心事の一つは、ネットワークの急激な混雑に応答時間となっています。一方では、輻輳制御機構は、ルーティングや帯域幅の変化からか、トラフィックを、競合のバーストからの突然の渋滞に合理的に迅速に対応する必要があります。同時に、輻輳制御機構は、コネクションのラウンドトリップ時間も経たないうちに消費します遅延が急激に増加し、例えば、過渡変化にあまり厳しく反応してはなりません。

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.11、G、WIMAX、WCDMA、HS-WCDMA、E-GPRS、ブルートゥース、等）の不均一性、帯域幅、および往復遅延の両方缶数桁時々、急に変更。

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（添加増加乗算減少）として、又はそれらをよりゆっくりと応答するパラメータを使用して、関連するメカニズムの輻輳制御メカニズムを応答するための特定の関心のものであり得ます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.

集約トラフィックの応答性と平滑性に加えて、1つは、個々の接続[FHP00] [YKL01]を応答性、平滑性、及び攻撃性との間のトレードオフを考慮することができます。この場合、滑らかさが正確にパケットドロップごとに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.

一つの目標は、キューイング遅延のか、スループットの振動を最小限に抑えるという点で、安定性のものです。実際には、安定性はしばしば率の変動または分散に関連付けられています。レートの変動は、ルータのキューサイズの変動につながるため、キューのオーバーフローのことができます。これらのキューのオーバーフローが共存フローやアンダー利用ネットワークが不安定の一般的な兆候であると考えられ、どちらもリンク容量の定期的な全体に損失の同期を引き起こす可能性があります。したがって、流れの速度の変化を測定することは、多くの場合、トランスポートプロトコルの安定性を測定するために使用されます。速度変動を測定し、[JWL04]、[RX05]、および[FHPW00]フロー毎の伝送レートの変動係数（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 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.

フローごとのレートの変化を測定すること、しかし、トランスポートプロトコル安定の唯一の態様です。現実的な実験設定では常にレートは両方前方および経路を逆に経時的に変化させて、クロストラフィックのかなりの量と共に、観察されるトランスポートプロトコルの複数のフローを含みます。輻輳制御プロトコルは、トラフィックの競合の変化率にそのレートを適応しなければならないとして、それは上のトラフィックを競合への適応に一部起因レートの変動を測定しているため、単にトラフィックのサブセットのフローごとの統計情報を測定することは誤解を招く可能性があり道。それらがネットワークレベルで測定された統計情報を伴っている場合はこのように、フローごとの統計は、ほとんど意味があります。フロー毎の統計に相補的指標として、[HKLRX06様々な時間スケールにわたってボトルネックルータにおいて観察された集約フローの速度変動の測定値を使用します。

Minimizing oscillations in queueing delay or throughput has related per-flow metrics of minimizing jitter in round-trip times and loss rates.

遅延やスループットをキューイングで振動を最小限に抑えることにより、往復時間と損失率のジッタを最小化するフローごとのメトリックを関連しています。

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の輻輳制御は、輻輳に応じて送信レートを半分に送信者に、送信速度の顕著な振動することを特徴とする。）振動のレベルのメトリックの一つは、セクション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.

メトリックの別のセットは、公平性と収束時間のことです。公平性（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]ネットワーク電力の変異体を含みます。

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 )),

（（sum_i X_I）^ 2）/（N * sum_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 / N k個のユーザが均等にリソースを共有し、他のN-Kのユーザーがゼロ割り当てを受信したとき。

The product measure: The product measure:

製品対策：製品の測定：

product_i x_i ,

product_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.

個々の接続のスループットの生成物は、また、公平性の尺度として使用されます。（i番目の接続のパワー、および製品の尺度としてとられるX_Iいくつかの状況では、ネットワークパワーと呼ぶ。）積測度が偏析に対して特に敏感です。任意の接続がゼロスループットを受信した場合、製品の測定値はゼロです。 [MS91]において、すべての接続が同じスループットを受信したときに多くの接続とつの共有ゲートウェイとネットワークのために、製品の尺度が最大になることが示されています。

Epsilon-fairness: A rate allocation is defined as epsilon-fair if

イプシロン - 公平：レート割り当てがイプシロン - 公正かのように定義されています

(min_i x_i) / (max_i x_i) >= 1 - epsilon.

（Min_iのch_i）/（MAX_I ch_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]の溶液として説明することができます。総効用は、公平性とスループットの両方を定量化します。

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]「この基準はあまり強調最大最小公平性よりも小さい流れを好むが、」。（ユーティリティ関数の言語を使用して、比例公平性は、対数効用関数を使用して、そしてフローごとの効用関数の和を最大にすることによって達成することができ、より完全に説明するための[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)

sum_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公正なフローのセットが原因となるTCPフローのセットよりも渋滞を起こさない」という、TCP公平性の新しい定義を提案例えば、損失イベント率]、およびパケット損失率。

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]でチウとタンは、非弾性フローは、このようなアドミッション制御などの他のトラフィック制御を採用することを提案し、非弾性トラフィックのトラフィック制御を勉強したときに、公平性の概念を再定義するために主張しています。

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]でチャレンジし、そしてFloydおよびオールマンによって[FA08]に擁護されています。 [B07]で、ブリスコーは流量公平性が望ましい目標であるべきではない、その代わりに、「我々は、彼らが他の人に各ユーザのアクションの『コスト』を実施共有する方法については、公平性のメカニズムを判断すべきである」と主張しています。フロイドと

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.

公平性とスループットとの間のトレードオフ：一般各々に異なる重みを与え、公平性とスループットの両方を測定上記セクションにおけるフェアネス測定。公平性とスループットとの間の潜在的なトレードオフもら唐によって議論されています。【TWL06]において、最大最小公平性が最も公正として定義されているフレームワーク。具体的には、[TWL06]他のトポロジで、スループットが公平に逆比例するいくつかのトポロジで、スループットは、公平に比例することを示しています。

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].

公正かつ往復時間：一つの目標は、新しいトランスポートプロトコルの数で引用は[XHR04] [KHR02]異なる往復時間とフロー間の公平性のものとなっています。私たちは、この目標の望ましさについて、またはこの目標およびその他のメトリック[FJ92]（3.3節）の間の影響との相互作用についてのネットワーキングコミュニティのコンセンサスがないことに注意してください。別の往復時間を持つフロー間の公平性の目標に対する一つの共通の引数は、それがより多くのリソースを消費し、長い往復時間と流れてきました。この態様は、前の段落で覆われています。研究者はまた、標準的な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.

公正かつパケットサイズ：ワン公平性の問題は、異なるパケットサイズとフローの相対的な公正さのものです。多くのファイル転送アプリケーションは、可能な最大パケットサイズを使用します。対照的に、低帯域幅のVoIPフローは、すべて10〜40ミリ秒、新たなパケットを送信し、小さなパケットを送信する可能性がある。、遅延を制限します。小さなパケットのVoIP接続は、同じ環境で大きなパケットTCP接続として毎秒*バイト*で同じ送信レートを受けるべきである、またはそれは、毎秒*パケット*で同じ送信レートを受け取りますか？この公平性の問題は[RFC4828]は、パケットサイズがフローによって経験されるパケットドロップ率に影響を与えることができる方法を説明すると、[RFC3714]で詳しく説明されています。

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].

コンバージェンス時間：コンバージェンス時間が既存のフローと、新たに始まる1間の公平性への収束のための時間を懸念し、高帯域幅の長い遅延が流れると環境のための特別な関心事です。コンバージェンス時間はまた、ネットワーク経路の変化、競合するクロストラフィック、または無線リンクの特性として、急変後の公正さへの収束のための時間に関係します。公平性と同様に、収束時間は、同じプロトコルの流れの間、及び異なるプロトコル[SLFK03]を使用して流れる間に、両方の問題で可能です。コンバージェンス時間のために使用される一つのメトリックは、リンク帯域幅の101分の100番目と101分の1番目の株から行くために同じラウンドトリップ時間との二つの流れに要する時間として定義され、デルタ公正収束時間ですリンク帯域幅[BBFS01]の（1 +デルタ）/ 2と（1-デルタ）/ 2の株式と公平な共有に近い有すること。最大-不当状態から起動する際に、収束時間の同様のメトリックは、[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.

グッドプット比：無線ネットワークでは、グッドプット率はグッドプット率はネットワーク上で送信されるデータの総量の割合としてユーザに配信有用なデータとして定義することができる有用なメトリックであることができます。高いグッドプット率は、他のユーザとの無線スペクトルの効率的な使用およびより低い干渉を示しています。

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.

一つの目標は、そのような経路に沿って、またはそうでなければ経験渋滞に関するデータの送信者に「嘘」は、送信者[SCWA99]の輻輳制御メカニズムを迂回しようとすることを受信機としてユーザーに、誤動作に対してロバストであることが輻輳制御機構のためのものです。輻輳制御メカニズムが、このような所定のプロトコルに従うように、またはエンドノードの故障・ノードを終了する明示的フィードバックを使用してルータの障害などの障害、できるだけ堅牢であるために別の目標です。

2.6. Deployability

2.6. 展開性

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つのメトリックは、現在のインターネットでの展開性です。展開性に関連するメトリックは、エンドノードまたはルータにおける故障診断の容易さ及びパケットのヘッダサイズの点でオーバーヘッド又は追加の複雑さを含みます。

One key aspect of deployability concerns the range of deployment needed for a new congestion control mechanism. Consider the following possible deployment requirements:

展開性の一つの重要な側面は、新たな輻輳制御機構に必要な展開の範囲に関するものです。次の可能な展開の要件を考慮してください。

* Only at the sender (e.g., NewReno in TCP [RFC3782]);

*のみ送信側で（例えば、NewRenoのTCPに[RFC3782]）。

* Only at the receiver (e.g., delayed acknowledgements in TCP);

*のみが受信機で（TCPで例えば、遅延確認応答）。

* Both the sender and receiver (e.g., Selective Acknowledgment (SACK) TCP [RFC2018]);

*送信側と受信側の両方（例えば、選択的確認応答（SACK）、TCP [RFC2018]）。

* At a single router (e.g., Random Early Detection (RED) [FJ93]);

*単一のルータで（例えば、ランダム早期検出（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]).

*パスに沿って両方のエンドノードとすべてのルータ（例えば、明示的な制御プロトコル（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、または非ルータキューとを有する配置の問題を有していてもよいです。

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.

別の展開性の問題は、コードの複雑さに関係します。どのように複雑なコードは、ソフトウェアでのメカニズムを実装するために必要ですか？浮動小数点演算が必要ですか？どのくらいの新しい状態は、新たなメカニズムを実装するために保管しなければならない、と誰がその状態を保持し、ルータまたはエンドノード？我々は、単一の番号に展開性メトリックを削減する方法として、これらの質問を示唆していないことに注意してください。我々は、提案された輻輳制御機構の展開性を評価する際に考慮することができるの問題としてそれらを示唆しています。

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）のために意図トランスポートプロトコルを評価するために必要とされる[KK03] [VKD02]環境を-enabled以下、ベストエフォート型トラフィックのため。

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

IPパフォーマンス・メトリック（IPPM）ワーキンググループ3.メトリクス

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からのメトリックの定義は、シミュレーションでこれらの指標を測定する方法の特定の問題のため、またはテストベッドでは、これらのメトリックの話のための一般的な定義を提供するために、有用である可能性が多いです。

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プロトコルの実験的評価」で[LLS05]高速ネットワークにおけるTCPのパフォーマンスに焦点を当て、そして異なる往復時間を持つフロー間の公平性を含めトータルスループット、損失率、公平さ（のための指標を検討します）、収束時間）、および増分展開などの応答時間（。方法論上のより一般的な参照は、[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.

ラクランアンドリューのおかげで、マーク・オールマン、アルマンドカロ、ダーミンチウ、エリック・コー、ダドColussi、ウェズリーエディ、アーロンフォーク、ネルソン・フォンセカ、Janardhanアイアンガー、ダグリース、サラLandstrom、トニー・リー、サヴェリオMascolo、ショーン・ムーア、Injong李承晩、デビッド・ロス、ユルゲンSchoenwaelder、アンドラーシュVeres、マイケルWelzl、とデイモンWischik、およびフィードバックと貢献のための輸送モデリング研究グループのメンバー。

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] M.オールマン、W.エディ、およびS. Ostermann、TCP、ACM性能評価レビュー、31で推定損失率（3）、2003年12月。

[BB01] D. Bansal and H. Balakrishnan, Binomial Congestion Control Algorithms, IEEE Infocom, April 2001.

[BB01] D. Bansal氏とH.バラクリシュナン、二項輻輳制御アルゴリズム、IEEEインフォコム、2001年4月。

[BBFS01] D. Bansal, H. Balakrishnan, S. Floyd, and S. Shenker, Dynamic Behavior of Slowly-Responsive Congestion Control Algorithms, SIGCOMM 2001.

【BBFS01] D. Bansal氏、H.バラクリシュナン、S.フロイド、およびS. Shenker、ゆっくり応答輻輳制御アルゴリズムの動的挙動、SIGCOMM 2001。

[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.

[BJ81] K.バーラト・クマーとJ.ジェフリー、パフォーマンス指向のフロー制御への新しいアプローチ、コミュニケーションに関するIEEEトランザクション、Vol.29 N.4、1981年4月。

[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] D.チウとA.タム、TCPフレンドリーなトラフィックコントロールの研究では再定義公正、技術報告書、2006。

[DM06] N. Dukkipati and N. McKeown, Why Flow-Completion Time is the Right Metric for Congestion Control, ACM SIGCOMM, January 2006.

[DM06] N. DukkipatiとN.マッケオン、なぜフロー完了時間は、輻輳制御のための右のメトリック、ACM SIGCOMM、2006年1月です。

[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内の複数の混雑のゲートウェイとの接続：一方通行、コンピュータコミュニケーションレビュー、Vol.21 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]フロイド、S.、および秋、K.、「インターネットにおけるエンドツーエンドの輻輳制御の利用促進」、ネットワーキング、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] S.フロイド、M.ハンドレー、及びJ. Padhye、式ベースおよびAIMD輻輳制御の比較、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.ウィドマー、ユニキャストアプリケーションのための方程式ベースの輻輳制御、SIGCOMM 2000、2000年8月。

[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. Jacobson氏、インターネットワーキング：研究と経験、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] S.フロイドとV.ヤコブソン、輻輳回避のためのランダム早期検出・ゲートウェイ、ネットワーク、V.1 N.4、1993年8月にIEEE / ACM取引、

[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.フロイド、トランスポートプロトコルのためのモデル無線リンク、ACM CCR、34（2）：85-96、2004年4月。

[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] S.ハ、Y.キム、L.ル、I.李承晩、およびL.徐、高速TCPプロトコルの現実的な評価に向けてのステップ、技術報告書、ノースカロライナ州立大学、2006年1月。

[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.ギャラガー、データ通信ネットワークにおける公正フロー制御のためのラウンドロビンスケジューリング、通信に関する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. Jainさん、D.M.チウ、およびW. HAWE、共有システムにおける資源配分のための公正かつ差別の定量的測定、12月TR-301、リトルトン、MA：ディジタルイクイップメント社、1984。

[JWL04] C. Jin, D. Wei, and S. Low, FAST TCP: Motivation, Architecture, Algorithms, Performance, IEEE INFOCOM, March 2004.

[JWL04] C.ジン、D.魏、およびS.低、FAST 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.シュミット）、シュプリンガー・フェアラーク、ベルリン、頁685から702、2001。。

[KHR02] D. Katabi, M. Handley, and C. Rohrs, Congestion Control for High Bandwidth-Delay Product Networks, ACM Sigcomm, 2002.

[KHR02] D. Katabi、M.ハンドリー、およびC. Rohrs、高帯域幅、遅延積ネットワークの輻輳制御、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 INFOCOM 2003、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.タン、通信ネットワークにおけるレート制御：シャドウ価格は、プロポーショナルフェアネスと安定性。オペレーショナルリサーチ学会49誌、頁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、エンドツーエンドの輻輳制御方式：ユーティリティ関数、ランダム損失およびECNマークス、ネットワーク上のIEEE / ACMの取引、11（5）：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、高速データネットワークのための動的適応のWindows、インフォコム'91、頁39から48。

[MTZ04] L. Mamatas, V. Tsaoussidis, and C. Zhang, Approaches to Congestion Control in Packet Networks, 2004.

[MTZ04] L. Mamatas、V. 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の選択確認応答オプション"、RFC 2018、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ための一方向パケット損失メトリック"、RFC 2680、1999年9月。

[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999.

"接続の測定IPPMメトリック" [RFC2678] Mahdavi、J.およびV.パクソン、RFC 2678、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の遅延メトリック"、RFC 2679、1999年9月。

[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.

[RFC2681] Almes、G.、Kalidindi、S.、およびM. Zekauskas、 "IPPMのラウンドトリップ遅延メトリック"、RFC 2681、1999年9月。

[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.

[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。

[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001.

[RFC3148]マティス、M.およびM.オールマン、「実証バルク転送容量のメトリックを定義するためのフレームワーク」、RFC 3148、2001年7月。

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.

"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。

[RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample Metrics", RFC 3357, August 2002.

[RFC3357] Koodli、R.とR. Ravikanth、 "ワンウェイ損失パターンのサンプルメトリック"、RFC 3357、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パフォーマンス・メトリックのためのIPパケット遅延変動メトリック（IPPM）"、RFC 3393、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）：プロトコル仕様"、RFC 3448、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）"、RFC 3611、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心配"、RFC 3714、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、RFC 3782、2004年4月 "TCPの高速回復アルゴリズムにNewRenoの変更"。

[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、 "パケット並べ替えメトリック"、RFC 4737、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のためのクイックスタート"、RFC 4782、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）バリアント"、RFC 4828、2007年4月。

[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, February 2008.

[RFC5136] Chimento、P.およびJ. Ishac、 "定義ネットワーク容量"、RFC 5136、2008年2月。

[RX05] I. Rhee and L. Xu, CUBIC: A New TCP-Friendly High-Speed TCP Variant, PFLDnet 2005.

[RX05] I.李承晩とL.徐、CUBIC：新しいTCPフレンドリー高速TCPバリアント、PFLDnet 2005。

[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.フロイド、遊休ネットワーク経路上で適切な送信レートを決定する、コンピュータネットワーク、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.

【SLFK03] R.N.短く、D.J.同期通信ネットワークにおける輻輳制御のリース、J.フォイ、およびR. Kilduffの、分析および設計。 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] V. TsaoussidisとI.マッタ、モバイルコンピューティング、ワイヤレス通信の雑誌とモバイルコンピューティングのためのTCPのオープンIssues：モバイルコンピューティング、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.低いです。エンドツーエンドのコントロール下にあるネットワークで直感的スループット行動、ネットワーク上のIEEE / ACMの取引、14（2）：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.

TCPベンチマークスィート？テクニカルレポート、カリフォルニア工科大学CS、スタンフォードEAS、カリフォルニア工科大学、2005年の[WCL05] D. X.魏、P.曹操とS. H.ロー、時間。

[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.ダーリン、TCPニース：オペレーティングシステムの設計と実装（OSDI）、2002年のバックグラウンド転送のためのメカニズム、第五USENIXシンポジウム。

[XHR04] L. Xu, K. Harfoush, and I. Rhee, Binary Increase Congestion Control for Fast, Long Distance Networks, Infocom 2004.

[XHR04] L.徐、K. Harfoush、およびI.李承晩、高速、長距離ネットワーク、インフォコム2004のバイナリ増加輻輳制御。

[YKL01] Y. Yang, M. Kim, and S. Lam, Transient Behaviors of TCP-friendly Congestion Control Protocols, Infocom 2001.

【YKL01] Y.ヤン、M.金、及びS.ラム、TCP向け輻輳制御プロトコルの過渡挙動、インフォコム2001。

[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、分散型輻輳制御、ACM SIGCOMM、2004年8月の遅延安定性とパフォーマンス。

Author's Address

著者のアドレス

Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA

インターネットリサーチ1947センターストリートのためのサリーフロイドICSIセンター、スイート600バークレー、CA 94704 USA

EMail: floyd@icir.org

メールアドレス：floyd@icir.org

Full Copyright Statement

完全な著作権声明

著作権（C）IETFトラスト（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.

この文書では、BCP 78に及び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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。