[要約] RFC 3148は、実証的な大容量転送能力メトリックを定義するためのフレームワークです。その目的は、ネットワークの性能評価と改善のための一貫性のある方法を提供することです。
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.
Copyright（c）The Internet Society（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実装の予想される長期平均データレート（1秒あたりのビット）です。ただし、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
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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と、大きな画像やドキュメントを配信する際のWorld Wide Webが含まれます。BTCの直感的な定義は、問題のパス上の単一の理想的なTCP実装の予想される長期平均データレート（1秒あたりのビット）です。BTCツールで報告する必要があるバルク転送容量の特定の定義は次のとおりです。
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」は、転送される一意の「データ」ビットを表します（つまり、ヘッダービットまたはエミュレートヘッダービットは含まれません）。また、送信されるデータの量には、送信される一意のビット数のみが含まれている必要があることに注意してください（つまり、特定のパケットが再送信された場合、含むデータは1回だけカウントする必要があります）。
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実装が動作地域の一部で非線形性能を示すという証拠もあります。パス（リンクデータレートの上昇など）の増分改善により、全体的なTCPスループット（またはBTC）が低下する[MAT98]が低下する単純なシミュレーションの例を構築することができます。
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方法論間の格差を解決するのに役立つことが期待されています。たとえば、クラスター化されたパケット損失を主に経験するパスは、Tahoe、Reno、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).
将来のある時点で、すべての単純なパスメトリック（セグメント損失率、往復時間など）およびBTC補助メトリック（例えば、キューサイズとパケットの並べ替えを統一するAフレーム[RFC2330]が存在することが予想されます。）BTCメトリックのさまざまなバージョン（たとえば、その平行リノまたはサック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]で指定されているように、スロースタートおよび輻輳回避を実装する必要があります（以下に概説するように、追加の詳細も指定されています）。すべてのBTC方法論は、[RFC2581]で概説されているように、高速な再送信と高速回復を実装する必要があります。最後に、すべての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]では把握されていないか、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]により、TCPSは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.
* 実際のセグメントサイズ、またはセグメントサイズを選択する方法（例：Path MTU Discovery [RFC1191]）および各セグメントに加えられると想定されるヘッダーバイトの数を指定する必要があります。さらに、セグメントサイズが人工的にPATH 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）メトリックは、再送信時刻とスロースタートアルゴリズムが呼び出されないという制限を条件として、混雑回避アルゴリズムの完全に指定された実装のデータレート（1秒あたりのビット）です。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.
原則として、CACメトリックは理想的なBTCメトリックになります。これは、TCPの定常状態の動作をキャプチャするためです。しかし、そのように使用することにはかなり大きな困難があります。鬱血回避アルゴリズムの自己融合は、高速再送信、高速回復、または高度な回復アルゴリズムの特定の詳細に応じて、非常に壊れやすい場合があります。遅いスタート損失回復のタイムアウトと期間は、インターネットのトラフィック[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がデータの部分的なウィンドウを失った後にタイムアウトを経験した場合、一部のデータが配信された後に生成された少なくとも1つの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は、これが混雑制御アルゴリズムのさらなる改善につながる可能性があることを期待して、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によってトリガーされたデータ送信である場合に検出できます。データ/Acksのウィンドウ全体の損失により、回復のタイムアウトとスロースタートを介して回復を強制します。
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が他のアルゴリズムがない場合にセルフクロックを維持できるようにするすべてのアルゴリズムを計測する必要があります。さらに、使用されるアルゴリズムの詳細は完全に文書化する必要があります（セクション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つの往復内で複数の損失が存在する場合に自己詰まっているBTCメトリックは、損失分布を装備し、代替渋滞制御アルゴリズムのパフォーマンスを推定することができます（例：RENOスタイル）。
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期間の停止の場合のように、これらは低いレート（RTTごとに1パケット未満）で診断することは不可能であり、ネットワークパスのBTCを超えるレートでテストするのは不適切です。
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メトリックは、並べ替えを計装する必要があります。周波数と距離は、すべてのオーダーアウトオブオーダーパケットに対して計装する必要があります。並べ替えの重症度は、3つの異なるケースのいずれかに分類でき、それぞれを報告する必要があります。
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.
セグメントが十分に注文不足の場合、遅延パケットの到着が遅れている前に、高速再送信アルゴリズムが呼び出されます。これらのイベントは計装する必要があります。遅れて到着するパケットは回復を完了しますが、ウィンドウはまだ半分に削減されます。
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.
BTCメトリック内で測定できる他のパスプロパティがいくつかあります。たとえば、埋め込まれた一方向遅延メトリックでは、キューイングの遅延と（赤）ドロップの確率がウィンドウサイズとどのように相関するかを測定することが可能かもしれません。これらはオープンな研究の質問です。
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がBTCパフォーマンス（RFC 1323やRFC 2018機能など）に一致するように高度な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.
ウィル・リーランド、ジェフ・セムケ、マット・ゼカウスカス、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] Hari Balakrishnan、Venkata Padmanabhan、Srinivasan Seshan、Mark Stemm、およびRandy Katz。忙しいWebサーバーのTCP動作：分析と改善。テクニカルレポートUCB/CSD-97-966、1997年8月。http：//nms.lcs.mit.edu/~hari/papers/csd-97-966.psから入手できます。（また、1998年3月、カリフォルニア州サンフランシスコのIEEE INFOCOM Conf。
[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] Fall、K.、Floyd、S ..「タホ、リノ、サック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] Floyd、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] Hoe、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] Hoe、J。、「TCPの混雑制御と回避スキームのスタートアップダイナミクス」。修士論文、マサチューセッツ工科大学、1995年6月。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Proceedings of SIGCOMM '88, Stanford, CA., August 1988.
[Jac88] Jacobson、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. Lakshmanおよび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] Lin、D。およびKung、H.T。、「TCP高速回復戦略：分析と改善」、Infocomの議事録、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 Transactions on Networking、vol。5、No。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] Mathis、M。、「経験的バルク転送能力」、IPパフォーマンスメトリックワーキンググループレポート40の第3インターネットエンジニアリングタスクフォース、フロリダ州オーランド、1988年12月。http：//www.ietf.orgから入手可能/proceedings/98dec/43rd-ietf-98dec-122.html and 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] Mathis、M。and Mahdavi、J。
[MM96b] M. Mathis, J. Mahdavi, "TCP Rate-Halving with Bounding Parameters". Available from http://www.psc.edu/networking/papers/FACKnotes/current.
[MM96B] M. Mathis、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] Mathis、M.、Semke、J.、Mahdavi、J.、Lahey、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] Mathis、M.、Semke、J.、Mahdavi、J.、Ott、T。、「TCP混雑回避アルゴリズムの巨視的挙動」、Computer Communications Review、27（3）、1997年。
[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]、Ott、T.、Kemperman、J.、Mathis、M。、「理想的なTCP混雑回避の静止行動」、進行中、1996年8月。Pub/TJO/TCPWINDOW.PSを介して匿名FTPをFTPに使用して入手してください.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]、Ott、T.、Kemperman、J.、Mathis、M。、「一定の損失確率を備えたTCP/IPのウィンドウサイズの動作」、Dimacs Special Year on Networks、ワークショップインターネット上のリアルタイムアプリケーションのパフォーマンスに関するワークショップ、1996年11月。
[Pax97a] Paxson, V., "Automated Packet Trace Analysis of TCP Implementations", Proceedings of ACM SIGCOMM '97, August 1997.
[Pax97a] Paxson、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] Paxson、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。、およびKurose、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] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. Obtain via: http://www.rfc-editor.org/rfc/rfc1191.txt
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[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] Jacobson、V.、Braden、R。、およびD. Borman、「TCP拡張機能のための高性能」、1992年5月。
[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] Braden R.、Clark D.およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年6月。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
[RFC2001] Stevens、W。、「TCPスロースタート、混雑回避、高速再送信、および高速回復アルゴリズム」、RFC 2001、1997年1月。http：//www.rfc-editor.org/rfc/rfc2001TXT
[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] Mathis、M.、Mahdavi、J。Floyd、S.、Romanow、A。、「TCP Selective Aumponredcement Options」、RFC 2018、1996年10月。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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Paxson、V.、Almes、G.、Mahdavi、J.およびM. Mathis、「IPパフォーマンスメトリックのフレームワーク」、RFC 2330、1998年4月。/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] Black D.、Blake S.、Carlson M.、Davies E.、Wang Z.、W。Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。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] Ramakrishnan、K。およびS. Floyd、「IPに明示的な混雑通知（ECN）を追加する提案」、RFC 2481、1999年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] Paxson、V.、Allman、M.、Dawson、S.、Fenner、W.、Griner、J.、Heavens、I.、Lahey、K.、Semke、J. and B. Volz、 "既知のTCP実装の問題」、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] Allman、M.、Paxson、V。and W. Stevens、「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] Floyd、S。およびT. Henderson、「TCPの高速回復アルゴリズムへのNewreno修正」、RFC 2582、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
[RFC2988] Paxson、V。およびM. Allman、「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
[RFC3042] Allman、M.、Balakrishnan、H。およびS. Floyd、「限定送信を使用したTCPの損失回復の強化」、RFC 3042、2001年1月。RFC3042.txt
[Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.
[Ste94] Stevens、W。、「TCP/IP Illustrated、Volume 1：The Protocols」、Addison-Wesley、1994。
[WS95] Wright, G., Stevens, W., "TCP/IP Illustrated Volume II: The Implementation", Addison-Wesley, 1995.
[WS95] Wright、G.、Stevens、W。、「TCP/IP Illustrated Volume II：The Information」、Addison-Wesley、1995。
Author's Addresses
著者のアドレス
Matt Mathis Pittsburgh Supercomputing Center 4400 Fifth Ave. Pittsburgh PA 15213
マットマティスピッツバーグスーパーコンピューティングセンター4400フィフスアベニューピッツバーグペンシルバニア州15213
EMail: 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 Brookpark Rd。MS 54-2クリーブランド、OH 44135
Phone: 216-433-6586
EMail: mallman@bbn.com
http://roland.grc.nasa.gov/~mallman
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。