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

原文URL : https://datatracker.ietf.org/doc/html/rfc5166
タイトル : RFC 5166 - 輻輳制御メカニズムの評価のためのメトリック
翻訳編集 : 自動生成

[要約] 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人以上のメンバーの個々の意見を表しています。IETFによる標準化または将来のIRTF研究グループコンセンサス文書としての採用と見なされる場合があります。

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.

これらのそれぞれを以下に検討します。メトリックの多くには、ネットワークベース、フローベース、およびユーザーベースの解釈があります。たとえば、ネットワークベースのメトリックは、帯域幅と集計ドロップレートを検討できます。フローベースのメトリックは、ファイル転送のエンドツーエンド転送時間、またはインタラクティブトラフィックのエンドツーエンドの遅延およびパケットドロップレートを考慮し、ユーザー - ベースのメトリックは、マルチメディアエクスペリエンスに対するユーザーの待ち時間またはユーザーの満足度を考慮することができます。このドキュメントの主な目標は、関連する可能性のある一連のメトリックを説明することであり、各一般的なメトリックを使用するための最も適切な方法論を立法化しないことです。

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:

ルーターベースのメトリックの代わりにフローベースのメトリックを使用すると、流れごとのスループット、遅延、および損失率の関係は、輸送プロトコル自体によってしばしば与えられます。たとえば、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]の場合。

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

スループットはGoodputと区別されることがあります。ここで、スループットはリンクの使用率またはバイト単位のフローレートです。また、1秒あたりのバイトで測定されるGoodputは、有用なトラフィックで構成されるスループットのサブセットです。つまり、「Goodput」は、完全なパケットに再組み立てられないため、レシーバーにドロップされるパケットフラグメント、またはATMセルを完全なパケットに再組み立てるなど、重複したパケット、パケットフラグメント、または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].

一部のコンテキストでは、集計スループットまたは平均流量スループット[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.

個々のアプリケーションは、スループットに関してアプリケーション固有のニーズを持つことができます。たとえば、リアルタイムのビデオトラフィックには、帯域幅の需要が非常に変動します。Voice over 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.

混雑制御メカニズムの設計における重要な懸念の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、Bluetoothなど）の不均一性の両方の結果、帯域幅と往復遅延の両方が可能です。突然、時には数桁変化します。

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.

総トラフィックの応答性と滑らかさに加えて、個々の接続の応答性、滑らかさ、攻撃性のトレードオフ[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.

1つの目標は、キューイング遅延またはスループットの振動を最小限に抑えるという点で、安定性の目標です。実際には、安定性は速度の変動または分散にしばしば関連付けられています。レートの変動により、ルーターキューサイズが変動し、キューオーバーフローが変動する可能性があります。これらのキューオーバーフローは、共存するフロー全体で損失同期とリンク容量の周期的な過少利用を引き起こす可能性があり、どちらもネットワークの不安定性の一般的な兆候と見なされます。したがって、輸送プロトコルの安定性を測定するために、フローの速度変動を測定することがよくあります。レートの変動を測定するには、[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.

ただし、流量あたりの変動の測定は、輸送プロトコルの安定性の1つの側面にすぎません。現実的な実験的設定には、常に輸送プロトコルの複数のフローが観察され、かなりの量の交差トラフィックが含まれ、前方と逆パスの両方で時間の経過とともにレートが異なります。輻輳制御プロトコルは、競合するトラフィックのさまざまなレートにそのレートを適応させる必要があるため、トラフィックのサブセットの流量ごとの統計を測定するだけで、誤解を招く可能性があります。道。したがって、フローごとの統計は、ネットワークレベルで測定された統計を伴う場合、最も意味があります。流量あたりの統計の相補的なメトリックとして、[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の混雑制御は、送信者が輻輳に応じて送信速度を半分にするために、送信速度の顕著な振動によって特徴付けられます。）振動のレベルの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.

別のメトリックのセットは、公平性と収束時間のセットです。同じプロトコルのフローと、異なるプロトコルを使用したフローの間で公平性を考慮することができます（たとえば、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].

さまざまな公平性の測定があります。これらには、Max-Minの公平性[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:

Jainの公平性指数：[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ユーザーがゼロ割り当てを受け取る場合、このインデックスはK/Nです。

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.

個々の接続のスループットの積は、公平性の尺度としても使用されます。（一部のコンテキストでは、X_IはI番目の接続のパワーと見なされ、製品測定値はネットワークパワーと呼ばれます。）製品測定値は、分離に特に敏感です。接続がゼロスループットを受信する場合、製品の測定値はゼロです。[MS91]では、多くの接続と1つの共有ゲートウェイを持つネットワークでは、すべての接続が同じスループットを受信すると製品測定が最大化されることが示されています。

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

epsilon-fairness：レート割り当ては、epsilon-fairとして定義されます

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

（min_i x_i） /（max_i x_i）> = 1 -epsilon。

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.

Epsilon-Fairnessは、任意の2つのスループットレートの間の最悪の比率を測定します[ZKL04]。Epsilon-Fairnessは、このドキュメントの後半で定義されているMax-Minの公平性に関連しています。

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

Max-Minの公平性：Max-Minの公平性基準を満たすためには、最小のスループットレートが可能な限り大きくなければなりません。この条件を考えると、次のsmallestスループットレートは可能な限り大きくなければなりません。したがって、最大ミンの公平性は、最小の流れを絶対に優先します。（Max-Minの公平性は、すべての流量がゼロで始まり、すべてが同じペースで成長するプログレッシブ充填アルゴリズムによって説明できます。各流量は、パスリンク容量に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、et al。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]のChiuと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 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.

フローレートの公平性の有用性は、ブリスコーによって[B07]で挑戦されており、フロイドとオールマンによって[FA08]で擁護されています。[B07]では、ブリスコーは、フローレートの公平性は望ましい目標ではないはずであり、代わりに「各ユーザーのアクションの「コスト」を他者に対する「コスト」と共有する方法についての公平性メカニズムを判断する必要がある」と主張しています。[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 et al。[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].

公平性と往復時間：多くの新しい輸送プロトコルで引用された1つの目標は、異なる往復時間のフロー間の公平性のものでした[KHR02] [XHR04]。ネットワーキングコミュニティには、この目標の望ましさ、またはこの目標と他のメトリックとの影響と相互作用についてのコンセンサスはないことに注意してください[FJ92]（セクション3.3）。異なる往復時間のフロー間の公平性の目標に対する1つの一般的な議論は、長い往復時間のあるフローがより多くのリソースを消費するということです。この側面は、前の段落でカバーされています。また、研究者は、標準TCPのRTT不在と、TCPに対するいくつかの提案された修正のRTT不定の違い[LLS05]の違いにも注目しています。

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]は、パケットサイズがフローが経験するパケットドロップレートに影響を与える方法についても説明しています。

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つのメトリックは、リンク帯域幅の100/101-Th/101-Theの株式からの同じ往復時間で2つのフローにかかった時間として定義されるデルタフェアの収束時間です。（1 Delta）/2および（1-Delta）/2のリンク帯域幅[BBFS01]の株式との公正な共有に近い。収束時間の同様のメトリックは、最大の不在状態[ZKL04]から始まるとき、2つのフローの往復時間の数としてepsilonフェアネスに到達するための収束時間を測定します。

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比は有用なメトリックになります。ここで、Goodput比は、ネットワーク上に送信されるデータの総量の一部としてユーザーに配信される有用なデータとして定義できます。高いグッドプット比は、無線スペクトルを効率的に使用し、他のユーザーとの干渉が低いことを示しています。

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]です[SCWA99]。もう1つの目標は、混雑制御メカニズムが、明示的なフィードバックを使用して、エンドノードに明示的なフィードバックを使用して、規定のプロトコルに従うためのエンドノードの障害など、誤りに対して可能な限り堅牢であることです。

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:

展開性の重要な側面の1つは、新しい輻輳制御メカニズムに必要な展開範囲に関係しています。次の可能な展開要件を考慮してください。

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

* 送信者でのみ（例：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]);

* 送信者と受信機の両方（例：Selective Aumponedment（sack）TCP [RFC2018]）;

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

* 単一のルーター（例：ランダムアーリー検出（赤）[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]、Quick-Start [RFC4782]）には、IPSEC、IP、MPLS、その他のトンネル、またはイーサネットスイッチのような非ルーターキューの展開の問題もあります。

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）対応環境またはベストエフォルト以下のトラフィック[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]、[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].

輸送プロトコルの評価に関する文献の例として、Li、et al。「高速ネットワーク用の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.

ラクラン・アンドリュー、マーク・オールマン、アルマンド・カロ、ダー・ミン・チウ、エリック・コー、ダド・コルッシ、ウェスリー・エディ、アーロン・フォーク、ネルソン・フォンセカ、ジャナルダン・アイエンガー、ダグ・リース、サラ・ランドストローム、トニー・リー、サヴェリオ・マスコロ、インド・ムーア、デビッド・ロス、ジュエルゲン・シェーンワールダー、アンドラス・ヴェレス、マイケル・ウェルツル、デイモン・ウィスキク、およびフィードバックと貢献のためのトランスポートモデリング研究グループのメンバー。

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. Allman、W。Eddy、および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. Balakrishnan、Binomial Commestion Control Algorithms、IEEE Infocom、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。Balakrishnan、S。Floyd、および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. Bharath-KumarとJ. Jeffrey、パフォーマンス指向のフロー制御への新しいアプローチ、IEEE Communications、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. Briscoe、「流量の公平性：宗教の解体」、コンピューターコミュニケーションレビュー、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-Fairnessへの新しいアプローチ、レポート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. ChiuおよびA. Tam、TCPに優しい交通規制の研究における公平性の再定義、Technical Report、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. McKeown、なぜフロー完了時間が渋滞制御に適したメトリックであるのか、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 No.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. FloydとM. Allman、単純なベストエフォルトトラフィックの有用性についてのコメント、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] Floyd、S。、およびFall、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/.

[FHPW00] S. Floyd, M. Handley, J. Padhye, and J. Widmer, Equation-Based Congestion Control for Unicast Applications, SIGCOMM 2000, August 2000.

[FHPW00] S. Floyd、M。Handley、J。Padhye、およびJ. Widmer、Unicast Applicationsの方程式ベースの混雑制御、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.ジェイコブソン、パケットスイッチされたゲートウェイの交通段階の影響、インターネットワーキング：研究と経験、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.ジェイコブソン、渋滞回避のためのランダムな早期検出ゲートウェイ、ネットワーキングに関するIEEE/ACMトランザクション、v.1 n.4、1993年8月、

[FK02] S. Floyd and E. Kohler, Internet Research Needs Better Models, Hotnets-I. October 2002.

[FK02] S. FloydとE. Kohler、インターネット調査にはより良いモデルが必要です。2002年10月。

[FK07] S. Floyd and E. Kohler, "Tools for the Evaluation of Simulation and Testbed Scenarios", Work in Progress, February 2008.

[FK07] S. FloydおよびE. Kohler、「シミュレーションとテストベッドシナリオの評価のためのツール」、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. Floyd、輸送プロトコルのワイヤレスリンクのモデリング、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. HA、Y。Kim、L。LE、I。Rhee、およびL. Xu、高速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.ハーンと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. Jain、The Art of Computer Systemsパフォーマンス分析：実験設計、測定、シミュレーション、およびモデリングの技術、John Wiley＆Sons、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。Chiu、およびW. Hawe、共有システムにおけるリソース割り当ての公平性と差別の定量的尺度、DEC TR-301、MA：Digital Equipment Corporation、1984。

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

[JWL04] C. Jin、D。Wei、およびS. Low、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. Kelly、インターネットの数学モデリング、「数学無制限-2001 and Beyond」（編集者B. EngquistおよびW. Schmid）、Springer-Verlag、Berlin、pp。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。Handley、および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. Knightly、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. Kelly、A。MaullooおよびD. Tan、通信ネットワークのレート制御：影の価格、比例公平性、安定性。Journal of the Operational Research Society 49、pp。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。Li、D。Leith、およびR. Shorten、高速ネットワーク用のTCPプロトコルの実験的評価、Hamilton Institute、2005年。URLhttp://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. MitraおよびJ. Seery、複数のパスと伝播遅延を備えた高速データネットワークの動的適応ウィンドウ、Infocom '91、pp 39-48。

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

[MTZ04] L. Mamatas、V。Tsaoussidis、およびC. Zhang、パケットネットワークの混雑制御へのアプローチ、2004年。

[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.

[RFC2018] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Ascondage Options」、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.

[RFC2678] Mahdavi、J。およびV. Paxson、「接続性を測定するためのIPPMメトリック」、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] Mathis、M。およびM. Allman、「経験的バルク容量メトリックを定義するためのフレームワーク」、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.

[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、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] Demichelis、C。およびP. Chimento、「IPパフォーマンスメトリック（IPPM）のIPパケット遅延変動メトリック」、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] Handley、M.、Floyd、S.、Padhye、J。、およびJ. Widmer、「TCP Friendry Rate Control（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] Friedman、T.、Ed。、Caceres、R.、ed。、およびA. Clark、ed。、「RTP Control Protocol拡張レポート（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] Floyd、S.、ed。、およびJ. Kempf、ed。、「インターネットでの音声トラフィックの混雑制御に関する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] Floyd、S.、Henderson、T。、およびA. Gurtov、「TCPの高速回復アルゴリズムへのNewreno修正」、RFC 3782、2004年4月。

[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006.

[RFC4737] Morton、A.、Ciavattone、L.、Ramachandran、G.、Shalunov、S。、およびJ. Perser、「Packet Redoring Metrics」、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] Floyd、S.、Allman、M.、Jain、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] Floyd、S。およびE. Kohler、「TCP Friendly Rate Control（TFRC）：The Small-Packet（SP）Variant」、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. RheeおよびL. Xu、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。Allman、およびS. Floydは、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。Leith、J。Foy、およびR. Kilduff、同期された通信ネットワークにおける混雑制御の分析と設計。Proc。2003年5月、Adaptive＆Learning Systemsに関する第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. Savage、N。Cardwell、D。Wetherall、およびT. Anderson、TCP輻輳制御、誤った受信機、ACM Computer Communications Review、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. Matta、モバイルコンピューティング用のTCPのオープンな問題、Journal of Wireless CommunicationsおよびMobile Computing：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. Tang、J。Wang、S。H。Low。エンドツーエンド制御下のネットワークでの直感に反するスループット動作、ネットワークに関する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.

[WCL05] D. X. Wei、P。Cao、S。H。Low、TCPベンチマークスイートの時間、テクニカルレポート、Caltech CS、Stanford Eas、Caltech、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 Nice：バックグラウンド転送のメカニズム、オペレーティングシステムの設計と実装に関する第5回USENIXシンポジウム（OSDI）、2002。

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

[XHR04] L. Xu、K。Harfoush、およびI. Rhee、バイナリは、高速、長距離ネットワークの混雑制御を増加させます、Infocom 2004。

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

[YKL01] Y. Yang、M。Kim、およびS. Lam、TCPに優しい混雑制御プロトコルの過渡行動、Infocom 2001。

[ZKL04] Y. Zhang, S.-R. Kang, and D. Loguinov, Delayed Stability and Performance of Distributed Congestion Control, ACM SIGCOMM, August 2004.

[ZKL04] Y. Zhang、S.-R。Kang、およびD. Loguinov、2004年8月、ACM Sigcomm、分散渋滞制御の安定性と性能の遅延。

Author's Address

著者の連絡先

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

サリーフロイドICSIセンターフォーインターネットリサーチ1947センターストリート、スイート600バークレー、カリフォルニア州94704 USA

   EMail: floyd@icir.org

Full Copyright Statement

完全な著作権声明

著作権（c）The IETF Trust（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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。

Intellectual Property

知的財産

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

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

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

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

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

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。