Network Working Group M. Mathis
Request for Comments: 3148 Pittsburgh Supercomputing Center
Category: Informational M. Allman
BBN/NASA Glenn
July 2001
A Framework for Defining Empirical Bulk Transfer Capacity Metrics
実証バルク転送容量のメトリックを定義するためのフレームワーク
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document defines a framework for standardizing multiple BTC (Bulk Transport Capacity) metrics that parallel the permitted transport diversity.
この文書では許可輸送ダイバーシティを平行に複数BTC（バルク輸送能力）指標を標準化するためのフレームワークを定義します。
1 Introduction
1はじめに
Bulk Transport Capacity (BTC) is a measure of a network's ability to transfer significant quantities of data with a single congestion-aware transport connection (e.g., TCP). The intuitive definition of BTC is the expected long term average data rate (bits per second) of a single ideal TCP implementation over the path in question. However, there are many congestion control algorithms (and hence transport implementations) permitted by IETF standards. This diversity in transport algorithms creates a difficulty for standardizing BTC metrics because the allowed diversity is sufficient to lead to situations where different implementations will yield non-comparable measures -- and potentially fail the formal tests for being a metric.
バルク輸送能力（BTC）は、単一の輻輳認識トランスポート接続（例えば、TCP）との間でデータのかなりの量を転送するネットワークの能力の尺度です。 BTCの直感的な定義は、当該経路上の単一の理想的なTCP実装の予想される長期平均データレート（ビット毎秒）です。しかしながら、IETF規格によって許可多くの輻輳制御アルゴリズム（従って、搬送実装）があります。そして潜在的にメートル法であることを正式にテストに失敗 - 許可される多様性は異なる実装が非同等の措置が得られるような状況につながるのに十分であるため、輸送アルゴリズムのこの多様性は、BTC測定基準を標準化するための困難を作成します。
Two approaches are used. First, each BTC metric must be much more tightly specified than the typical IETF protocol. Second, each BTC methodology is expected to collect some ancillary metrics which are potentially useful to support analytical models of BTC.
2つのアプローチが使用されています。まず、各BTCのメトリックがはるかに緊密に典型的なIETFプロトコルよりも指定しなければなりません。第二に、各BTC方法論は、BTCの分析モデルをサポートするために有用である可能性があるいくつかの補助的なメトリックを収集することが期待されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Although
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。であるが
[RFC2119] was written with protocols in mind, the key words are used in this document for similar reasons. They are used to ensure that each BTC methodology defined contains specific pieces of information.
[RFC2119]は念頭にプロトコルで書かれた、キー・ワードは、同様の理由でこの文書で使用されています。これらは定義されている各BTC方法論が特定の情報が含まれていることを確認するために使用されています。
Bulk Transport Capacity (BTC) is a measure of a network's ability to transfer significant quantities of data with a single congestion-aware transport connection (e.g., TCP). For many applications the BTC of the underlying network dominates the overall elapsed time for the application to run and thus dominates the performance as perceived by a user. Examples of such applications include FTP, and the world wide web when delivering large images or documents. The intuitive definition of BTC is the expected long term average data rate (bits per second) of a single ideal TCP implementation over the path in question. The specific definition of the bulk transfer capacity that MUST be reported by a BTC tool is:
バルク輸送能力（BTC）は、単一の輻輳認識トランスポート接続（例えば、TCP）との間でデータのかなりの量を転送するネットワークの能力の尺度です。多くのアプリケーションでは、基盤となるネットワークのBTCは、アプリケーションが実行するための全体的な経過時間を支配し、ユーザによって知覚されるため、パフォーマンスを支配します。大きな画像や文書を配信する際、このようなアプリケーションの例としては、FTP、およびワールドワイドウェブが含まれます。 BTCの直感的な定義は、当該経路上の単一の理想的なTCP実装の予想される長期平均データレート（ビット毎秒）です。 BTCツールによって報告されなければならないバルク転送能力の特定の定義は次のとおりです。
BTC = data_sent / elapsed_time
BTC = data_sent /のelapsed_time
where "data_sent" represents the unique "data" bits transfered (i.e., not including header bits or emulated header bits). Also note that the amount of data sent should only include the unique number of bits transmitted (i.e., if a particular packet is retransmitted the data it contains should be counted only once).
ここで、「data_sent」は（すなわち、ヘッダビットまたはエミュレートされたヘッダビットを含まない）移しユニークな「データ」ビットを表します。また、送信されたデータの量だけ送信されるビットの一意の番号を（特定のパケットが再送される場合、すなわち、それに含まれるデータを一度だけカウントされるべきである）を含むべきであることに注意してください。
Central to the notion of bulk transport capacity is the idea that all transport protocols should have similar responses to congestion in the Internet. Indeed the only form of equity significantly deployed in the Internet today is that the vast majority of all traffic is carried by TCP implementations sharing common congestion control algorithms largely due to a shared developmental heritage.
バルク輸送能力の概念の中心は、すべてのトランスポートプロトコルは、インターネット上の混雑に同様の応答を持っていなければならないという考えです。確かに大幅に今日のインターネットで展開資本の唯一の形式は、すべてのトラフィックの大部分は共有発達遺産によるところが大きい共通輻輳制御アルゴリズムを共有するTCP実装によって運ばれていることです。
[RFC2581] specifies the standard congestion control algorithms used by TCP implementations. Even though this document is a (proposed) standard, it permits considerable latitude in implementation. This latitude is by design, to encourage ongoing evolution in congestion control algorithms.
[RFC2581]はTCPの実装によって使用される標準的な輻輳制御アルゴリズムを指定します。この文書は、（提案）規格であっても、それは実装にかなりの自由度を可能にします。この緯度は、輻輳制御アルゴリズムにおける継続的な発展を奨励するために、仕様です。
This legal diversity in congestion control algorithms creates a difficulty for standardizing BTC metrics because the allowed diversity is sufficient to lead to situations where different implementations will yield non-comparable measures -- and potentially fail the formal tests for being a metric.
そして潜在的にメートル法であることを正式にテストに失敗 - 許可される多様性は異なる実装が非同等の措置が得られるような状況につながるのに十分であるため、輻輳制御アルゴリズムのこの法的な多様性は、BTC測定基準を標準化するための困難を作成します。
There is also evidence that most TCP implementations exhibit non-linear performance over some portion of their operating region. It is possible to construct simple simulation examples where incremental improvements to a path (such as raising the link data rate) results in lower overall TCP throughput (or BTC) [Mat98].
ほとんどのTCP実装は、その動作領域の一部の上に非直線性能を示すという証拠もあります。 [Mat98】経路（例えばリンクデータレートを上げるように）低い全体的なTCPのスループット（又はBTC）における結果に漸進的な改善、単純なシミュレーション例を構成することができます。
We believe that such non-linearity reflects weakness in our current understanding of congestion control and is present to some extent in all TCP implementations and BTC metrics. Note that such non-linearity (in either TCP or a BTC metric) is potentially problematic in the market because investment in capacity might actually reduce the perceived quality of the network. Ongoing research in congestion dynamics has some hope of mitigating or modeling the these non-linearities.
私たちは、このような非直線性は、輻輳制御の私達の現在の理解の低迷を反映して、すべてのTCPの実装とBTCのメトリックである程度存在していると信じています。能力への投資は実際にネットワークの知覚品質が低下する可能性がありますので、そのような非直線性は、（TCPまたはBTCのメトリックのいずれかで）市場に潜在的に問題があることに注意してください。混雑力学における継続的な研究は、これらの非線形性を軽減するか、モデリングのいくつかの希望を持っています。
Related areas, including integrated services [RFC1633,RFC2216], differentiated services [RFC2475] and Internet traffic analysis [MSMO97,PFTK98,Pax97b,LM97] are all currently receiving significant attention from the research community. It is likely that we will see new experimental congestion control algorithms in the near future. In addition, Explicit Congestion Notification (ECN) [RFC2481] is being tested for Internet deployment. We do not yet know how any of these developments might affect BTC metrics, and thus the BTC framework and metrics may need to be revisited in the future.
統合サービス[RFC1633、RFC2216]、差別化されたサービス[RFC2475]とインターネットトラフィック分析などの関連分野、[MSMO97、PFTK98、Pax97b、LM97]は、すべての現在の研究コミュニティから大きな注目を集めています。我々が近い将来に新しい実験輻輳制御アルゴリズムを参照してくださいする可能性があります。また、明示的輻輳通知（ECN）[RFC2481]インターネットの展開について試験されています。私たちは、まだこれらの開発のいずれかがBTCのメトリックに影響を与える可能性があるのか分からないので、BTCの枠組みとメトリックは、将来的に再検討する必要があるかもしれません。
This document defines a framework for standardizing multiple BTC metrics that parallel the permitted transport diversity. Two approaches are used. First, each BTC metric must be much more tightly specified than the typical IETF transport protocol. Second, each BTC methodology is expected to collect some ancillary metrics which are potentially useful to support analytical models of BTC. If a BTC methodology does not collect these ancillary metrics, it should collect enough information such that these metrics can be derived (for instance a segment trace file).
この文書では許可輸送ダイバーシティを平行複数BTCのメトリックを標準化するためのフレームワークを定義します。 2つのアプローチが使用されています。まず、各BTCのメトリックがはるかに緊密に典型的なIETFトランスポートプロトコルよりも指定しなければなりません。第二に、各BTC方法論は、BTCの分析モデルをサポートするために有用である可能性があるいくつかの補助的なメトリックを収集することが期待されます。 BTC方法論は、これらの補助的なメトリックを収集しない場合は、これらのメトリックは、（例えばセグメントトレースファイル）を導出することができるように、十分な情報を収集する必要があります。
As an example, the models in [PFTK98, MSMO97, OKM96a, Lak94] all predict bulk transfer performance based on path properties such as loss rate and round trip time. A BTC methodology that also provides ancillary measures of these properties is stronger because agreement with the analytical models can be used to corroborate the direct BTC measurement results.
一例として、[PFTK98、MSMO97、OKM96a、Lak94]全てのモデルは、損失率との往復時間として路特性に基づいて、バルク転送の性能を予測します。解析モデルとの合意が直接BTC測定結果を裏付けるために使用することができるのでまた、これらのプロパティの補助的な手段を提供するBTC方法論が強いです。
More importantly the ancillary metrics are expected to be useful for resolving disparity between different BTC methodologies. For example, a path that predominantly experiences clustered packet losses is likely to exhibit vastly different measures from BTC metrics that mimic Tahoe, Reno, NewReno, and SACK TCP algorithms [FF96]. The differences in the BTC metrics over such a path might be diagnosed by an ancillary measure of loss clustering.
さらに重要な補助的なメトリクスは異なるBTC方法論との格差を解消するために有用であると期待されています。例えば、主に経験は、パケット損失をクラスタ化されたパスは、タホ、リノ、NewRenoの、およびSACK TCPアルゴリズム[FF96]を模倣するBTC測定基準とは大きく異なる措置を発揮する可能性があります。そのような経路を経てBTCメトリックの違いは、損失のクラスタリングの補助的な指標によって診断される可能性があります。
There are some path properties which are best measured as ancillary metrics to a transport protocol. Examples of such properties include bottleneck queue limits or the tendency to reorder packets. These are difficult or impossible to measure at low rates and unsafe to measure at rates higher than the bulk transport capacity of the path.
最高のトランスポートプロトコルへの補助的な測定基準として測定されているいくつかのパスのプロパティがあります。このような性質の例は、ボトルネックキュー制限やパケットの順序を変更する傾向があります。これらは、パスのバルク輸送能力よりも高いレートで測定するのが困難または低レートで測定することは不可能と安全ではありません。
It is expected that at some point in the future there will exist an A-frame [RFC2330] which will unify all simple path metrics (e.g., segment loss rates, round trip time) and BTC ancillary metrics (e.g., queue size and packet reordering) with different versions of BTC metrics (e.g., that parallel Reno or SACK TCP).
これは、将来のある時点で、すべての単純なパスメトリックを統一しますA-フレーム[RFC2330]を存在することが予想される（例えば、セグメント損失率、ラウンドトリップ時間）とBTC補助的指標（例えば、キュー・サイズ及びパケット並べ替え）BTCメトリック（例えば、その平行リノ又はSACK TCP）の異なるバージョンを有します。
2 Congestion Control Algorithms
2個の輻輳制御アルゴリズム
Nearly all TCP implementations in use today utilize the congestion control algorithms published in [Jac88] and further refined in [RFC2581]. In addition to using the basic notion of using an ACK clock, TCP (and therefore BTC) implements five standard congestion control algorithms: Congestion Avoidance, Retransmission timeouts, Slow-start, Fast Retransmit and Fast Recovery. All BTC implementations MUST implement slow start and congestion avoidance, as specified in [RFC2581] (with extra details also specified, as outlined below). All BTC methodologies SHOULD implement fast retransmit and fast recovery as outlined in [RFC2581]. Finally, all BTC methodologies MUST implement a retransmission timeout.
ほとんど使用されているすべてのTCPの実装今日は[Jac88]に掲載された輻輳制御アルゴリズムを利用して、[RFC2581]でさらに洗練されました。輻輳回避、再送信タイムアウト、スロースタート、高速再送信および高速リカバリ：ACKクロックを使用しての基本的な概念を使用することに加えて、TCP（したがって、BTC）は、5つの標準の輻輳制御アルゴリズムを実装しています。全てBTC実装はスロースタートと輻輳回避を実装しなければならない、[RFC2581]で指定されるように（余分な詳細も指定して、以下に概説されるように）。 [RFC2581]に概説されているようすべてのBTC方法論は、高速再送と高速リカバリを実装する必要があります。最後に、すべてのBTC方法論は、再送タイムアウトを実装しなければなりません。
The algorithms specified in [RFC2581] give implementers some choices in the details of the implementation. The following is a list of details about the congestion control algorithms that are either underspecified in [RFC2581] or very important to define when constructing a BTC methodology. These details MUST be specifically defined in each BTC methodology.
[RFC2581]で指定されたアルゴリズムは、実装の詳細で実装にいくつかの選択肢を与えます。以下のいずれか[RFC2581]でunderspecifiedされたり、非常に重要BTC方法論を構築する際に定義する輻輳制御アルゴリズムについての詳細のリストです。これらの詳細は、具体的には、各BTC方法で定義されなければなりません。
* [RFC2581] does not standardize a specific algorithm for increasing cwnd during congestion avoidance. Several candidate algorithms are given in [RFC2581]. The algorithm used in a particular BTC methodology MUST be defined.
* [RFC2581]は、輻輳回避中にcwndを増加させるための特定のアルゴリズムを標準化しません。いくつかの候補アルゴリズムは[RFC2581]に記載されています。特定のBTC方法で使用されるアルゴリズムを定義しなければなりません。
* [RFC2581] does not specify which cwnd increase algorithm (slow start or congestion avoidance) should be used when cwnd equals ssthresh. This MUST be specified for each BTC methodology.
* [RFC2581] CWNDがSSTHRESHに等しいとき増加アルゴリズム（スロースタートや輻輳回避）が使用されるべきであるcwndをその指定されていません。これは、各BTC方法を指定しなければなりません。
* [RFC2581] allows TCPs to use advanced loss recovery mechanism such as NewReno [RFC2582,FF96,Hoe96] and SACK-based algorithms [FF96,MM96a,MM96b]. If used in a BTC implementation, such an algorithm MUST be fully defined.
* [RFC2581]はのTCPは、NewRenoの[RFC2582、FF96、Hoe96]とSACKベースのアルゴリズム[FF96、MM96a、MM96b]などの高度な損失回復機構を使用することを可能にします。 BTCの実装で使用される場合、そのようなアルゴリズムは完全に定義されなければなりません。
* The actual segment size, or method of choosing a segment size (e.g., path MTU discovery [RFC1191]) and the number of header bytes assumed to be prepended to each segment MUST be specified. In addition, if the segment size is artificially limited to less than the path MTU this MUST be indicated.
*実際のセグメントサイズ、又はセグメントサイズを選択する方法（例えば、パスMTU探索[RFC1191]）と各セグメントに付加されているものとヘッダ・バイトの数を指定する必要があります。また、セグメントのサイズは、人工的にこれは示さなければならない経路MTU以下に制限されている場合。
* TCP includes a retransmission timeout (RTO) to trigger retransmissions of segments that have not been acknowledged within an appropriate amount of time and have not been retransmitted via some more advanced loss recovery algorithm. A BTC implementation MUST include a retransmission timer. Calculating the RTO is subject to a number of details that MUST be defined for each BTC metric. In addition, a BTC metric MUST define when the clock is set and the granularity of the clock.
* TCPは、適切な時間内に認められていないと、いくつかのより高度な損失回復アルゴリズムを経由して再送されていないセグメントの再送をトリガーする再送タイムアウト（RTO）が含まれています。 BTCの実装では、再送タイマーを含まなければなりません。 RTOを算出し、各BTCメトリックに対して定義されなければならない細部の数を受けます。クロックが設定され、クロックの細分された場合に加えて、BTCメトリックを定義しなければなりません。
[RFC2988] specifies the behavior of the retransmission timer. However, there are several details left to the implementer which MUST be specified for each BTC metric defined.
[RFC2988]は再送タイマーの動作を指定します。しかし、定義された各BTCメトリックに指定されなければならない実装に任さいくつかの詳細があります。
Note that as new congestion control algorithms are placed on the standards track they may be incorporated into BTC metrics (e.g., the Limited Transmit algorithm [ABF00]). However, any implementation decisions provided by the relevant RFCs SHOULD be fully specified in the particular BTC metric.
新たな輻輳制御アルゴリズムが標準に置かれるように、彼らはBTCのメトリックに組み入れることができる追跡することに留意されたい（例えば、限定送信アルゴリズム[ABF00]）。しかし、関連するRFCで提供される任意の実施の決定は完全に特定のBTC測定基準で指定する必要があります。
3 Ancillary Metrics
3つの補助メトリック
The following ancillary metrics can provide additional information about the network and the behavior of the implemented congestion control algorithms in response to the behavior of the network path. It is RECOMMENDED that these metrics be built into each BTC methodology. Alternatively, it is RECOMMENDED that the BTC implementation provide enough information such that the ancillary metrics can be derived via post-processing (e.g., by providing a segment trace of the connection).
次の補助的指標は、ネットワークとネットワークパスの挙動に応じて実装輻輳制御アルゴリズムの動作に関する追加情報を提供することができます。これらの指標は、各BTC方法論に組み込まれることが推奨されます。あるいは、BTC実装が補助的なメトリックは、後処理（例えば、接続のセグメント・トレースを提供することによって）を介して導出することができるように十分な情報を提供することが推奨されます。
The "Congestion Avoidance Capacity" (CAC) metric is the data rate (bits per second) of a fully specified implementation of the Congestion Avoidance algorithm, subject to the restriction that the Retransmission Timeout and Slow-Start algorithms are not invoked. The CAC metric is defined to have no meaning across Retransmission Timeouts or Slow-Start periods (except the single segment Slow-Start that is permitted to follow recovery, as discussed in section 2).
メトリック「輻輳回避容量」（CAC）は、再送タイムアウトとスロースタートアルゴリズムが起動されないという制限を受ける輻輳回避アルゴリズムの完全指定された実装のデータレート（ビット毎秒）です。 CACメトリックが再送タイムアウトまたはスロースタート期間を横切って意味を持たないように定義される（セクション2で説明したように、回復に従うことが許可されている単一のセグメントスロースタートを除きます）。
In principle a CAC metric would be an ideal BTC metric, as it captures what should be TCP's steady state behavior. But, there is a rather substantial difficulty with using it as such. The Self-Clocking of the Congestion Avoidance algorithm can be very fragile, depending on the specific details of the Fast Retransmit, Fast Recovery or advanced recovery algorithms chosen. It has been found that timeouts and periods of slow start loss recovery are prevalent in traffic on the Internet [LK98,BPS+97] and therefore these should be captured by the BTC metric.
それはTCPの定常状態の挙動がどうあるべきかキャプチャとして原則的にはCACメトリックは、理想的なBTCのメトリックになります。しかし、そのように使用すると、むしろかなりの困難があります。輻輳回避アルゴリズムのセルフクロッキングは、選択された高速再送、高速回復や高度な回復アルゴリズムの具体的な詳細に応じて、非常に壊れやすいことができます。 [LK98、BPS + 97]スロースタート損失回復のタイムアウトおよび期間は、インターネット上のトラフィックに蔓延していることが判明しているので、これらは、BTCのメトリックによって捕獲されなければなりません。
When TCP loses Self-Clock it is re-established through a retransmission timeout and Slow-Start. These algorithms nearly always require more time than Congestion Avoidance would have taken. It is easily observed that unless the network loses an entire window of data (which would clearly require a retransmit timeout) TCP likely missed some opportunity to safely transmit data. That is, if TCP experiences a timeout after losing a partial window of data, it must have received at least one ACK that was generated after some of the partial data was delivered, but did not trigger the transmission of new data. Recent research in congestion control (e.g., FACK [MM96a], NewReno [FF96,RFC2582], rate-halving [MSML99]) can be characterized as making TCP's Self-Clock more tenacious, while preserving fairness under adverse conditions. This work is motivated by how poorly current TCP implementations perform under some conditions, often due to repeated clock loss. Since this is an active research area, different TCP implementations have rather considerable differences in their ability to preserve Self-Clock.
TCPは、自己のクロックを失うと、それは再送タイムアウトとスロースタートによって再確立されます。これらのアルゴリズムは、ほぼ常に輻輳回避がかかったでしょうよりも多くの時間を必要とします。簡単にネットワークが（明確に再送タイムアウト時間を必要とする）データのウィンドウ全体を失うしない限り、TCPはおそらく安全にデータを送信するためにいくつかのチャンスを逃したことが観察されます。これは、TCPがデータの部分的なウィンドウを失った後、タイムアウトが発生した場合、それは部分的なデータの一部が配信された後に生成された少なくとも一つのACKを受け取っている必要がありますされていますが、新しいデータの送信をトリガしませんでした。不利な条件の下で公平性を維持しながら（例えば、FACK [MM96a]、NewRenoの[FF96、RFC2582]、[MSML99]レート半減）輻輳制御における最近の研究では、TCPの自己時計はもっと粘り強い作るとして特徴づけることができます。この作品は、現在のTCP実装がしばしば繰り返さクロック損失のために、いくつかの条件の下で実行する方法不十分によって動機づけられています。これは、アクティブな研究領域であるので、異なるTCP実装は自己時計を維持する能力ではなく、かなりの違いがあります。
Losing the ACK clock can have a large effect on the overall BTC, and the clock is itself fragile in ways that are dependent on the loss recovery algorithm. Therefore, the transition between timer driven and Self-Clocked operation SHOULD be instrumented.
ACKクロックを失うことは、全体のBTCに大きな影響を与える、とクロックが損失回復アルゴリズムに依存している方法で、壊れやすい自体であることができます。したがって、タイマー駆動セルフクロック動作の間の移行は、計測されるべきです。
If the last event before a timeout was the receipt of an ACK that did not trigger a transmission, the possibility exists that an alternate congestion control algorithm would have successfully preserved the Self-Clock. A BTC SHOULD instrument key items in the BTC state (such as the congestion window) in the hopes that this may lead to further improvements in congestion control algorithms.
タイムアウト前の最後のイベントが送信をトリガしませんでしたACKを受信した場合は、可能性は別の輻輳制御アルゴリズムが正常にセルフクロックを保存しているだろうと存在しています。 BTC SHOULD器具これは輻輳制御アルゴリズムの更なる改善をもたらし得ることを期待して（例えば、輻輳ウィンドウ等）BTC状態のキーアイテム。
Note that in the absence of knowledge about the future, it is not possible to design an algorithm that never misses transmission opportunities. However, there are ever more subtle ways to gauge network state, and to estimate if a given ACK is likely to be the last.
将来についての知識がない場合には、送信機会を逃したことがないアルゴリズムを設計することが可能ではないことに注意してください。しかし、ネットワークの状態を測定するために、与えられたACKが最後になりそうであるならば推定することがこれまで以上に微妙な方法があります。
If an entire window of data (or ACKs) is lost, there will be no returning ACKs to clock out additional data. This condition can be detected if the last event before a timeout was a data transmission triggered by an ACK. The loss of an entire window of data/ACKs forces recovery to be via a Retransmission Timeout and Slow-Start.
データ（またはACKの）のウィンドウ全体が失われた場合、クロックアウト追加データをへの帰国のACKはありません。タイムアウト前の最後のイベントがACKによってトリガデータ伝送した場合、この条件を検出することができます。データ/のACKの力の回復のウィンドウ全体の損失は、再送タイムアウトとスロースタートを介して行うことができます。
Losing an entire window of data implies an outage with a duration at least as long as a round trip time. Such an outage can not be diagnosed with low rate metrics and is unsafe to diagnose at higher rates than the BTC. Therefore all BTC metrics SHOULD instrument and report losses of an entire window of data.
データのウィンドウ全体を失うことの期間、少なくとも限り、往復時間と停止を意味します。このような障害は、低金利の指標と診断され、BTCよりも高いレートで診断するのは危険ですすることはできません。したがって、すべてのBTCのメトリックデータのウィンドウ全体の機器との報告損失する必要があります。
Note that there are some conditions, such as when operating with a very small window, in which there is a significant probability that an entire window can be lost through individual random losses (again highlighting the importance of instrumenting cwnd).
そのようなウィンドウ全体が（再びのcwndを計測することの重要性を強調し）、個々のランダムな損失によって失われることが重要な確率が存在する非常に小さなウィンドウで動作しているときのように、いくつかの条件があることに注意してください。
All algorithms that permit a given BTC to sustain Self-Clock when other algorithms might not, SHOULD be instrumented. Furthermore, the details of the algorithms used MUST be fully documented (as discussed in section 2).
ときに、他のアルゴリズムではないかもしれない自己時計を維持するために与えられたBTCを許可するすべてのアルゴリズムは、インストルメントされるべきである（SHOULD）。 （セクション2で説明したように）さらに、使用されるアルゴリズムの詳細は完全に文書化されなければなりません。
BTC metrics that can sustain Self-Clock in the presence of multiple losses within one round trip SHOULD instrument the loss distribution, such that the performance of alternate congestion control algorithms may be estimated (e.g., Reno style).
1つの往復SHOULD器具損失分布、代替の輻輳制御アルゴリズムの性能を推定することができるように（例えば、リノスタイル）内の複数の損失の存在下で自己クロックを維持することができるBTCメトリクス。
All false timeouts, (where the retransmission timer expires before the ACK for some previously transmitted data arrives) SHOULD be instrumented when possible. Note that depending upon how the BTC metric implements sequence numbers, this may be difficult to detect.
可能な場合はすべての偽タイムアウト、（いくつかの以前に送信したデータのためのACKが到着する前に、再送タイマが満了したところ）が計測されるべきです。 BTCのメトリックは、シーケンス番号を実装する方法に応じて、これは検出が困難であってもよいことに注意してください。
All BTC metrics provide unique vantage points for observing certain path properties relating to closely spaced packets. As in the case of RTT duration outages, these can be impossible to diagnose at low rates (less than 1 packet per RTT) and inappropriate to test at rates above the BTC of the network path.
全てBTCメトリックは、近接したパケットに関連する特定のパスの特性を観察するためのユニークな有利な点を提供します。 RTT時間の停止の場合のように、これらは、ネットワーク経路のBTC上記速度でテストするために、低速度（RTTあたり1つのパケット未満）と不適切に診断することは不可能であることができます。
All BTC metrics SHOULD instrument packet reordering. The frequency and distance out-of-sequence SHOULD be instrumented for all out-of-order packets. The severity of the reordering can be classified as one of three different cases, each of which SHOULD be reported.
すべてのBTCのメトリックは、機器のパケットの並べ替えをする必要があります。アウトオブシーケンス周波数との距離は、全てのアウトオブオーダーパケットのためにインストルメントされるべきです。並べ替えの重症度が報告されるべきであるそれぞれが、三つの異なるケースのいずれかに分類することができます。
Segments that are only slightly out-of-order should not trigger the fast retransmit algorithm, but they may affect the window calculation. BTC metrics SHOULD document how slightly out-of-order segments affect the congestion window calculation.
アウトオブオーダーわずかにあるセグメントは高速再送アルゴリズムをトリガーするものではありませんが、ウィンドウの計算に影響を与える可能性があります。 BTCのメトリックは、わずかにアウトオブオーダーセグメントは、輻輳ウィンドウ計算にどのように影響するかを文書化する必要があります。
If segments are sufficiently out-of-order, the Fast Retransmit algorithm will be invoked in advance of the delayed packet's late arrival. These events SHOULD be instrumented. Even though the the late arriving packet will complete recovery, the the window will still be reduced by half.
セグメントは十分にアウトオブオーダーであれば、高速再送アルゴリズムが遅れ、パケットの到着が遅れるの前に呼び出されます。これらのイベントは、計測されるべきである（SHOULD）。遅れて到着したパケットは、回復を完了しますにもかかわらず、ウィンドウはまだ半分に削減されます。
Under some rare conditions segments have been observed that are far out of order - sometimes many seconds late [Pax97b]. These SHOULD always be instrumented.
遠く順不同であるセグメントが観察されているいくつかのまれな条件の下で - 時には何秒後半[Pax97b]。これらは、常に計測されるべきです。
BTC implementations SHOULD instrument the maximum cwnd observed during congestion avoidance and slow start. A TCP running over the same path as the BTC metric must have sufficient sender buffer space and receiver window (and window shift [RFC1323]) to cover this cwnd in order to expect the same performance.
BTCの実装は、機器輻輳回避とスロースタートの際に観測された最大のcwndをする必要があります。 BTCメトリックと同じ経路上で動作するTCPは、同じ性能を期待するためにこのCWNDをカバーするのに十分な差出人バッファ領域と受信機ウインドウ（窓シフト[RFC1323]）を有していなければなりません。
There are several other path properties that one might measure within a BTC metric. For example, with an embedded one-way delay metric it may be possible to measure how queuing delay and and (RED) drop probabilities are correlated to window size. These are open research questions.
1は、BTCメートル以内に測定するかもしれない他のいくつかのパスのプロパティがあります。例えば、メトリック埋め込み一方向遅延とキューイング遅延とし、（RED）は、ウィンドウサイズに相関している確率を落とす方法を計測することが可能です。これらは、オープンな研究の質問です。
Unlike low rate metrics, BTC SHOULD include explicit checks that the test platform is not the bottleneck.
低金利の指標とは異なり、BTCは、テストプラットフォームがボトルネックではないことを明示的なチェックを含むべきです。
Any detected dropped packets within the sending host MUST be reported. Unless the sending interface is the path bottleneck, any dropped packets probably indicates a measurement failure.
送信ホスト内の任意の検出破棄されたパケットを報告しなければなりません。送信インターフェイスは、パスのボトルネックがある場合を除き、すべてのドロップされたパケットは、おそらく、測定の失敗を示しています。
The maximum queue lengths within the sending host SHOULD be instrumented. Any significant queue may indicate that the sending host has insufficient burst data rate, and is smoothing the data being transmitted into the network.
送信ホスト内の最大キューの長さが計測されるべきです。有意なキューは、送信ホストが不十分バーストデータレートを有し、ネットワークに送信されたデータを平滑化していることを示してもよいです。
If TCP would require advanced TCP extensions to match BTC performance (such as RFC 1323 or RFC 2018 features), it SHOULD be reported.
TCPは、（例えばRFC 1323やRFC 2018の特徴など）BTCの性能を一致させるために、高度なTCP拡張を必要とする場合は、報告する必要があります。
To the extent possible, the BTC metric SHOULD distinguish between the properties of the forward and reverse paths.
可能な限り、BTCのメトリックは、順方向の特性を区別及び経路を逆にすべきです。
BTC methodologies which rely on non-cooperating receivers may only be able to measure round trip path properties and may not be able to independently differentiate between the properties of the forward and reverse paths. In this case the load on the reverse path contributed by the BTC metric SHOULD be instrumented (or computed) to permit other means of gauge the proportion of the round trip path properties attributed to the the forward and reverse paths.
非協働する受信機に頼るBTC方法は、往復経路の特性を測定することであってもよく、独立して、順方向および逆方向経路の特性を区別することができないかもしれません。この場合、BTCのメトリックが寄与する逆の経路上の負荷は、ゲージの他の手段を可能にするために、インストルメント（または計算）されるべきである順方向および逆方向のパスに起因する往復路特性の割合。
To the extent possible, BTC methodologies that rely on cooperating receivers SHOULD support separate ancillary metrics for the forward and reverse paths.
可能な限り、協働する受信機に頼るBTC方法は、順方向のための別個の補助的なメトリックをサポートし、経路を逆にすべきです。
4 Security Considerations
4つのセキュリティの考慮事項
Conducting Internet measurements raises security concerns. This memo does not specify a particular implementation of a metric, so it does not directly affect the security of the Internet nor of applications which run on the Internet. However, metrics produced within this framework, and in particular implementations of the metrics may create security issues.
インターネット測定を実施することは、セキュリティ上の懸念を提起します。このメモは、メトリックの特定の実装を指定していないので、直接インターネットのも、インターネット上で動作するアプリケーションのセキュリティに影響を与えません。しかし、この枠組みの中で、指標の特定の実装で生成メトリックは、セキュリティ上の問題を作成することができます。
Bulk Transport Capacity metrics, as defined in this document, naturally attempt to fill a bottleneck link. The BTC metrics based on this specification will be as "network friendly" as current well-tuned TCP connections. However, since the "connection" may not be using TCP packets, a BTC test may appear to network operators as a denial of service attack.
バルク輸送能力の指標は、この文書で定義されるように、自然にボトルネックリンクを埋めるためにしよう。この仕様に基づいたBTCのメトリックは、現在よく調整されたTCP接続などの「ネットワークにやさしい」のようになります。 「接続」は、TCPパケットを使用することはできませんので、しかし、BTCテストは、サービス拒否攻撃としてネットワークオペレータに見えることがあります。
Administrators of the source host of a test, the destination host of a test, and the intervening network(s) may wish to establish bilateral or multi-lateral agreements regarding the timing, size, and frequency of collection of BTC metrics.
試験、試験の宛先ホスト、及び介在するネットワーク（複数可）のソース・ホストの管理者は、BTCのメトリックの収集のタイミング、サイズ、および頻度に関する両側またはマルチラテラル契約を確立することを望むかもしれません。
Metrics within this framework generate packets for a sample, rather than taking samples based on user data. Thus, a BTC metric does not threaten user data confidentiality.
このフレームワーク内のメトリックはなくユーザデータに基づいてサンプルを取るよりも、サンプルのためのパケットを生成します。このように、BTCのメトリックは、ユーザデータの機密性を脅かすものではありません。
It may be possible to identify that a certain packet or stream of packets are part of a BTC metric. With that knowledge at the destination and/or the intervening networks, it is possible to change the processing of the packets (e.g., increasing or decreasing delay, introducing or heroically preventing loss) that may distort the measured performance. It may also be possible to generate additional packets that appear to be part of a BTC metric. These additional packets are likely to perturb the results of the sample measurement.
パケットの特定のパケット又はストリームはBTCメトリックの一部であることを識別することが可能です。宛先及び/又は介在するネットワークでその知識と、それはパケットの処理を変更することが可能である（例えば、増加または遅延を減少させる、導入または英雄的損失防止）測定された性能を歪ませることができます。また、BTCのメトリックの一部であるように思われる追加のパケットを生成することも可能です。これらの追加のパケットはサンプル測定の結果を混乱させる可能性が高いです。
To discourage the kind of interference mentioned above, packet interference checks, such as cryptographic hash, may be used.
このような暗号ハッシュのようなパケット干渉チェックを、上記干渉の種類を阻止するために、使用されてもよいです。
5 IANA Considerations
5つのIANAの考慮事項
Since this metric framework does not define a specific protocol, nor does it define any well-known values, there are no IANA considerations for this document. However, a bulk transport capacity metric within this framework, and in particular protocols that implement a metric may have IANA considerations that need to be addressed.
このメトリックフレームワークは、特定のプロトコルを定義していない、またそれは、任意の周知の値を定義しないので、このドキュメントに関するIANAの考慮事項はありません。しかし、この枠組みの中で、およびメトリックを実装して、特定のプロトコルにおけるバルク輸送能力メトリックが対処する必要がIANA問題を有していても良いです。
6 Acknowledgments
6つの謝辞
Thanks to Wil Leland, Jeff Semke, Matt Zekauskas and the IPPM working group for numerous clarifications.
ウィル・リーランド、ジェフSemke、マットZekauskasおよび多数の明確化のためのIPPMワーキンググループに感謝します。
Matt Mathis's work was supported by the National Science Foundation under Grant Numbers 9415552 and 9870758.
マット・マティスの作品は、グラント番号9415552と9870758の下で国立科学財団によってサポートされていました。
7 References
7つの参考文献
[BPS+97] Hari Balakrishnan, Venkata Padmanabhan, Srinivasan Seshan, Mark Stemm, and Randy Katz. TCP Behavior of a Busy Web Server: Analysis and Improvements. Technical Report UCB/CSD-97-966, August 1997. Available from http://nms.lcs.mit.edu/~hari/papers/csd-97-966.ps. (Also in Proc. IEEE INFOCOM Conf., San Francisco, CA, March 1998.)
[BPS + 97]ハリ・バラクリシュナン、ヴェンカタPadmanabhan、スリニバサン・セシャン、マークStemm、およびランディカッツ。忙しいWebサーバのTCPの挙動：分析と改善。テクニカルレポートUCB / CSD-97から966、http://nms.lcs.mit.edu/~hari/papers/csd-97-966.psから利用可能な1997年8月。 （また、PROC。IEEE INFOCOMコンファレンスインチ、サンフランシスコ、CA、1998年3月）
[FF96] Fall, K., Floyd, S.. "Simulation-based Comparisons of Tahoe, Reno and SACK TCP". Computer Communication Review, July 1996. ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.
[FF96]秋、K.、フロイド、S .. "タホ、リノとSACK TCPのシミュレーションベースの比較"。コンピュータコミュニケーションレビュー、1996年7月ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z。
[Flo95] Floyd, S., "TCP and successive fast retransmits", March 1995, Obtain via ftp://ftp.ee.lbl.gov/papers/fastretrans.ps.
[Flo95]フロイド、S.、 "TCPおよび連続した高速な再送"、1995年3月には、ftp://ftp.ee.lbl.gov/papers/fastretrans.psを経由して入手します。
[Hoe96] Hoe, J., "Improving the start-up behavior of a congestion control scheme for TCP, Proceedings of ACM SIGCOMM '96, August 1996.
[Hoe96]鍬、J.、「TCP、ACMのSIGCOMM '96の議事録、1996年8月のための輻輳制御方式の起動動作を改善。
[Hoe95] Hoe, J., "Startup dynamics of TCP's congestion control and avoidance schemes". Master's thesis, Massachusetts Institute of Technology, June 1995.
[Hoe95]鍬、J.、「TCPの輻輳制御と回避スキームのスタートアップダイナミクス」。修士論文、技術、1995年6月のマサチューセッツ工科大学。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Proceedings of SIGCOMM '88, Stanford, CA., August 1988.
[Jac88]ジェーコブソン、V.、 "輻輳回避とコントロール"、SIGCOMM '88の議事録、スタンフォード大学、カリフォルニア、1988年8月。
[Lak94] V. T. Lakshman and U. Madhow. The Performance of TCP/IP for Networks with High Bandwidth-Delay Products and Random Loss. IFIP Transactions C-26, High Performance Networking, pages 135--150, 1994.
【Lak94] V. T.ラクシュマン及びU. Madhow。高帯域幅、遅延製品とのネットワークとランダム損失のためのTCP / IPのパフォーマンス。 IFIP取引C-26、高性能ネットワーキング、ページ135--150、1994。
[LK98] Lin, D. and Kung, H.T., "TCP Fast Recovery Strategies: Analysis and Improvements", Proceedings of InfoCom, March 1998.
[LK98]林、D.とクン、H.T.、 "TCP高速リカバリ戦略：分析と改善"、インフォコム、1998年3月の議事。
[LM97] T.V.Lakshman and U.Madhow. "The Performance of TCP/IP for Networks with High Bandwidth-Delay Products and Random Loss". IEEE/ACM Transactions on Networking, Vol. 5, No. 3, June 1997, pp.336-350.
[LM97] T.V.LakshmanとU.Madhow。 「高帯域幅遅延製品とのネットワークとランダム損失のためのTCP / IPのパフォーマンス」。ネットワーキング、巻上のIEEE / ACM取引。図5に示すように、第3号、1997年6月、pp.336-350。
[Mat98] Mathis, M., "Empirical Bulk Transfer Capacity", IP Performance Metrics Working Group report in Proceedings of the Forty Third Internet Engineering Task Force, Orlando, FL, December 1988. Available from http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-122.html and http://www.ietf.org/proceedings/98dec/slides/ippm-mathis-98dec.pdf.
[Mat98]マシス、M.、「実証バルク転送容量」、第43インターネットエンジニアリングタスクフォース、オーランド、FL、12月1988 http://www.ietf.orgから入手可能の議事録でIPパフォーマンス・メトリックワーキンググループ報告書/proceedings/98dec/43rd-ietf-98dec-122.htmlとhttp://www.ietf.org/proceedings/98dec/slides/ippm-mathis-98dec.pdf。
[MM96a] Mathis, M. and Mahdavi, J. "Forward acknowledgment: Refining TCP congestion control", Proceedings of ACM SIGCOMM '96, Stanford, CA., August 1996.
【MM96a]マティス、M.とMahdavi、J. "回送肯定応答：精製のTCP輻輳制御"、ACM SIGCOMM '96の議事録、スタンフォード、カリフォルニア、1996年8月。
[MM96b] M. Mathis, J. Mahdavi, "TCP Rate-Halving with Bounding Parameters". Available from http://www.psc.edu/networking/papers/FACKnotes/current.
【MM96b] M.マシス、J. Mahdavi、 "バウンディングパラメータとTCPレート半減"。 http://www.psc.edu/networking/papers/FACKnotes/currentから入手できます。
[MSML99] Mathis, M., Semke, J., Mahdavi, J., Lahey, K., "The Rate-Halving Algorithm for TCP Congestion Control", June 1999, Work in Progress.
【MSML99]マティス、M.、Semke、J.、Mahdavi、J.、レイヒー、K.、 "TCP輻輳制御のレート半減アルゴリズム"、1999年6月、進行中で働いています。
[MSMO97] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", Computer Communications Review, 27(3), July 1997.
【MSMO97]マティス、M.、Semke、J.、Mahdavi、J.、オット、T.、 "TCP輻輳回避アルゴリズムの巨視的挙動"、コンピュータコミュニケーションレビュー、27（3）、1997年7月。
[OKM96a], Ott, T., Kemperman, J., Mathis, M., "The Stationary Behavior of Ideal TCP Congestion Avoidance", In progress, August 1996. Obtain via pub/tjo/TCPwindow.ps using anonymous ftp to ftp.bellcore.com
[OKM96a]、オット、T.、Kemperman、J.、マティス、M.、 "理想的なTCPの輻輳回避の定常動作は、" 進行中の、1996年8月には、FTPに匿名FTPを使用してパブ/ TJO / TCPwindow.ps介して取得します.bellcore.com
[OKM96b], Ott, T., Kemperman, J., Mathis, M., "Window Size Behavior in TCP/IP with Constant Loss Probability", DIMACS Special Year on Networks, Workshop on Performance of Real-Time Applications on the Internet, Nov 1996.
[OKM96b]、オット、T.、Kemperman、J.、マティス、M.、「定数損失確率でTCP / IPにおけるウィンドウサイズの動作」、DIMACS特別な年ネットワーク上の、インターネット上でリアルタイムアプリケーションのパフォーマンスに関するワークショップ、1996年11月。
[Pax97a] Paxson, V., "Automated Packet Trace Analysis of TCP Implementations", Proceedings of ACM SIGCOMM '97, August 1997.
[Pax97a]パクソン、V.、 "TCP実装の自動化されたパケットトレース解析"、ACMのSIGCOMM '97の議事録、1997年8月。
[Pax97b] Paxson, V., "End-to-End Internet Packet Dynamics," Proceedings of SIGCOMM '97, Cannes, France, Sep. 1997.
[Pax97b]パクソン、V.、「エンドツーエンドインターネットパケットダイナミクス、」SIGCOMM '97の議事録、カンヌ、フランス、1997年9月。
[PFTK98] Padhye, J., Firoiu. V., Towsley, D., and Kurose, J., "TCP Throughput: A Simple Model and its Empirical Validation", Proceedings of ACM SIGCOMM '98, August 1998.
【PFTK98] Padhye、J.、Firoiu。 V.、Towsley、D.、および黒瀬、J.、 "TCPのスループット：簡単なモデルとその実証的検証"、ACMのSIGCOMM '98の予稿集、1998年8月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. Obtain via: http://www.rfc-editor.org/rfc/rfc793.txt
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793は、1981年9月に取得を介し：http://www.rfc-editor.org/rfc/rfc793.txt
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. Obtain via: http://www.rfc-editor.org/rfc/rfc1191.txt
[RFC1191]モーグル、J.およびS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月に入手介し：http://www.rfc-editor.org/rfc/rfc1191.txt
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", May 1992. Obtain via: http://www.rfc-editor.org/rfc/rfc1323.txt
[RFC1323]ジェーコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、月1992年は入手経由：http://www.rfc-editor.org/rfc/rfc1323.txt
[RFC1633] Braden R., Clark D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. Obtain via: http://www.rfc-editor.org/rfc/rfc1633.txt
[RFC1633]ブレーデンR.、クラークD.とS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月には入手経由：http://www.rfc-editor.org/rfc/ rfc1633.txt
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997. Obtain via: http://www.rfc-editor.org/rfc/rfc2001.txt
http://www.rfc-editor.org/rfc/rfc2001：[RFC2001]スティーブンス、W.は、 "TCPスロースタート、輻輳回避、高速再送、および高速リカバリアルゴリズム"、RFC 2001、1997年1月には、経由して入手します。 txt
[RFC2018] Mathis, M., Mahdavi, J. Floyd, S., Romanow, A., "TCP Selective Acknowledgment Options", RFC 2018, October 1996. Obtain via: http://www.rfc-editor.org/rfc/rfc2018.txt
[RFC2018]マティス、M.、Mahdavi、J.フロイド、S.、Romanow、A.、 "TCP選択的確認応答オプション"、RFC 2018、1996年10月に入手介し：http://www.rfc-editor.org/ RFC / rfc2018.txt
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Obtain via: http://www.rfc-editor.org/rfc/rfc2119.txt
[RFC2119]ブラドナーの、S.は、「要件レベルを示すためにRFCsにおける使用のためのキーワード」、BCP 14、RFC 2119、1997年3月には、経由して取得します。http://www.rfc-editor.org/rfc/rfc2119.txt
[RFC2216] Shenker, S. and J. Wroclawski, "Network Element Service Specification Template", RFC 2216, September 1997. Obtain via: http://www.rfc-editor.org/rfc/rfc2216.txt
[RFC2216] Shenker、S.とJ. Wroclawski、 "ネットワーク要素サービス仕様テンプレート"、RFC 2216、1997年9月には入手経由：http://www.rfc-editor.org/rfc/rfc2216.txt
[RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, April 1998. Obtain via: http://www.rfc-editor.org/rfc/rfc2330.txt
[RFC2330]パクソン、V.、Almes、G.、Mahdavi、J.とM.マティス、 "IPパフォーマンス・メトリックのためのフレームワーク"、RFC 2330、1998年4月に入手介し：http://www.rfc-editor.org /rfc/rfc2330.txt
[RFC2475] Black D., Blake S., Carlson M., Davies E., Wang Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. Obtain via: http://www.rfc-editor.org/rfc/rfc2475.txt
[RFC2475]ブラックD.、ブレイクS.、カールソンM.、デイヴィスE.、王Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月には経由して取得します。http：// WWWを。 rfc-editor.org/rfc/rfc2475.txt
[RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999. Obtain via: http://www.rfc-editor.org/rfc/rfc2481.txt
[RFC2481]ラマクリシュナン、K.およびS.フロイド、 "IPに明示的輻輳通知（ECN）を追加する提案"、RFC 2481、1999年1月に入手介し：http://www.rfc-editor.org/rfc/ rfc2481.txt
[RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, J. and B. Volz, "Known TCP Implementation Problems", RFC 2525, March 1999. Obtain via: http://www.rfc-editor.org/rfc/rfc2525.txt
[RFC2525]パクソン、V.、オールマン、M.、ドーソン、S.、フェナー、W.、Griner、J.、天、I.、レイヒー、K.、Semke、J.およびB.フォルツ、「既知のTCP http://www.rfc-editor.org/rfc/rfc2525.txt：実装の問題」、RFC 2525、1999年3月には、経由して入手します
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999. Obtain via: http://www.rfc-editor.org/rfc/rfc2581.txt
[RFC2581]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月には入手経由：http://www.rfc-editor.org/rfc/rfc2581.txt
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999. Obtain via: http://www.rfc-editor.org/rfc/rfc2582.txt
[RFC2582]フロイド、S.とT.ヘンダーソン、RFC 2582 "TCPの速い回復アルゴリズムへのNewRenoの変更"、1999年4月には入手経由：http://www.rfc-editor.org/rfc/rfc2582.txt
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. Obtain via: http://www.rfc-editor.org/rfc/rfc2988.txt
http://www.rfc-editor.org/rfc/rfc2988.txt：[RFC2988]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月を経て取得し
[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001. Obtain via: http://www.rfc-editor.org/rfc/rfc3042.txt
http://www.rfc-editor.org/rfc/：[RFC3042]オールマン、M.、バラクリシュナン、H.とS.フロイドは、RFC 3042 "限定ミットを使用したTCPの損失回復の強化"、2001年1月には、経由して入手しますrfc3042.txt
[Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.
[Ste94]スティーブンス、W.、 "TCP / IPイラスト、第1巻：プロトコル"、アディソン・ウェズリー、1994。
[WS95] Wright, G., Stevens, W., "TCP/IP Illustrated Volume II: The Implementation", Addison-Wesley, 1995.
[WS95]ライト、G.、スティーブンス、W.、 "TCP / IPイラストボリュームII：インプリメンテーション"、アディソン・ウェズリー、1995。
Author's Addresses
著者のアドレス
Matt Mathis Pittsburgh Supercomputing Center 4400 Fifth Ave. Pittsburgh PA 15213
マット・マシスピッツバーグ・スーパーコンピューティング・センター4400フィフスアベニューピッツバーグPA 15213
EMail: mathis@psc.edu http://www.psc.edu/~mathis
メールアドレス：mathis@psc.edu http://www.psc.edu/~mathis
Mark Allman BBN Technologies/NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
マーク・オールマンBBNテクノロジーズ/ NASAグレンリサーチセンタールイス・フィールド21000ブルックパークRdを。 MS 54-2クリーブランド、オハイオ州44135
Phone: 216-433-6586 EMail: mallman@bbn.com http://roland.grc.nasa.gov/~mallman
電話：216-433-6586 Eメール：mallman@bbn.com http://roland.grc.nasa.gov/~mallman
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。