RFC3148 日本語訳
3148 A Framework for Defining Empirical Bulk Transfer CapacityMetrics. M. Mathis, M. Allman. July 2001. (Format: TXT=36041 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Mathis
Request for Comments: 3148 Pittsburgh Supercomputing Center
Category: Informational M. Allman
BBN/NASA Glenn
July 2001
コメントを求めるワーキンググループM.マシス要求をネットワークでつないでください: 3148年のピッツバーグスーパーコンピューティングセンターカテゴリ: 情報のM.オールマンBBN/NASAグレン2001年7月
A Framework for Defining Empirical Bulk Transfer Capacity Metrics
実証的なバルク転送容量測定基準を定義するための枠組み
Status of this Memo
この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)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document defines a framework for standardizing multiple BTC (Bulk Transport Capacity) metrics that parallel the permitted transport diversity.
このドキュメントは、受入れられた輸送の多様性に沿う複数のBTC(大量Transport Capacity)測定基準を標準化するために枠組みを定義します。
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.
大量Transport Capacity(BTC)は単独の混雑意識している輸送接続(例えば、TCP)と共にデータの有意量を移すネットワークの能力の基準です。 BTCの直感的な定義は問題の経路の上のただ一つの理想的なTCP実現の予想された長期平均したデータ信号速度(bps)です。 しかしながら、IETF規格によって受入れられた多くの輻輳制御アルゴリズム(したがって、実現を輸送する)があります。 輸送アルゴリズムによるこの多様性はメートル法で許容多様性がaであるために異なった実現が非匹敵する測定をもたらして、潜在的に形式テストに失敗する状況に通じるように十分であるので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プロトコルよりしっかり指定したということであるに違いありません。 2番目に、それぞれの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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか? although
Mathis, et al. Informational [Page 1] RFC 3148 Framework for Defining Empirical BTC Metrics July 2001
マシス、他 測定基準2001年7月に実証的なBTCを定義するための情報[1ページ]のRFC3148枠組み
[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:
大量Transport Capacity(BTC)は単独の混雑意識している輸送接続(例えば、TCP)と共にデータの有意量を移すネットワークの能力の基準です。 多くのアプリケーションのために、基本的なネットワークのBTCはアプリケーションが走るように総合的な経過時間を支配していて、その結果、ユーザによって知覚されるように性能を支配しています。 大きいイメージかドキュメントを届けるとき、そのようなアプリケーションに関する例はFTP、および世界的なウェブを含んでいます。 BTCの直感的な定義は問題の経路の上のただ一つの理想的なTCP実現の予想された長期平均したデータ信号速度(bps)です。 BTCツールで報告しなければならないバルク転送容量の特定の定義は以下の通りです。
BTC = data_sent / elapsed_time
BTCはデータの_の送られたか経過した_時間と等しいです。
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).
「_が送ったデータ」がユニークな「データ」を表すところでは、ビットはtransferedされました(すなわち、ヘッダービットか見習われたヘッダービットを含んでいません)。 また、データ量が発信したというメモは伝えられたビットのユニークな数を含んでいるだけであるはずです(すなわち、特定のパケットが再送されるなら、それが含むデータは一度だけ数えられるべきです)。
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.
輻輳制御アルゴリズムによるこの法的な多様性はメートル法で許容多様性がaであるために異なった実現が非匹敵する測定をもたらして、潜在的に形式テストに失敗する状況に通じるように十分であるので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]をもたらす簡単なシミュレーションの例を構成するのは可能です。
Mathis, et al. Informational [Page 2] RFC 3148 Framework for Defining Empirical BTC Metrics July 2001
マシス、他 測定基準2001年7月に実証的なBTCを定義するための情報[2ページ]のRFC3148枠組み
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]は現在、研究団体から重要な配慮をすべて受けています。 私たちは近い将来、新しい実験輻輳制御アルゴリズムを見そうでしょう。 さらに、Explicit Congestion Notification(電子証券取引ネットワーク)[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トランスポート・プロトコルよりしっかり指定したということであるに違いありません。 2番目に、それぞれの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方法論の間の不一致を決議することの役に立つと予想されます。 例えば、群生しているパケット損失に支配的になる経路は広大にタホをまねるBTC測定基準、リノ、NewReno、およびSACK TCPアルゴリズム[FF96]と異なった測定を示しそうです。 そのような経路の上のBTC測定基準の違いは損失クラスタリングの付属の手段によって診断されるかもしれません。
Mathis, et al. Informational [Page 3] RFC 3148 Framework for Defining Empirical BTC Metrics July 2001
マシス、他 測定基準2001年7月に実証的なBTCを定義するための情報[3ページ]のRFC3148枠組み
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測定基準(例えば、その平行なリノかSACK TCP)の異なった見解ですべての簡単な経路測定基準(例えば、旅行時間の周りのセグメント損失率)とBTCの付属の測定基準(例えば、待ち行列サイズとパケット再命令)を統一するA-フレーム[RFC2330]が将来存在すると予想されます。
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つの標準の輻輳制御アルゴリズムを実行します: 混雑Avoidance、Retransmissionタイムアウト、Slow-始め、Fast Retransmit、およびFast Recovery。 すべてのBTC実現が遅れた出発と輻輳回避を実行しなければなりません、[RFC2581](また、以下に概説されているように指定された余分な詳細がある)で指定されるように。 方法論SHOULD道具が速く再送するすべての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]で指定されたアルゴリズムは実現の詳細にいくつかの選択をimplementersに与えます。 ↓これはBTC方法論を構成するとき、定義するために[RFC2581]でunderspecifiedされたか、または非常に重要な輻輳制御アルゴリズムに関する詳細のリストです。 それぞれの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.
* cwndがssthreshと等しい場合、[RFC2581]は、アルゴリズム(遅れた出発か輻輳回避)がどの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]はNewRenoなどの高度な損失回収機構を使用するTCPs[RFC2582、FF96、Hoe96]とSACKベースのアルゴリズム[FF96、MM96a、MM96b]を許容します。 BTC実現に使用されるなら、そのようなアルゴリズムを完全に定義しなければなりません。
Mathis, et al. Informational [Page 4] RFC 3148 Framework for Defining Empirical BTC Metrics July 2001
マシス、他 測定基準2001年7月に実証的なBTCを定義するための情報[4ページ]のRFC3148枠組み
* 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.
* バイトがそれぞれにprependedされて、セグメントを指定しなければならないということであると仮定した実際のセグメントサイズか、セグメントサイズ(例えば、経路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にメートル法で指定しなければならないimplementerのままで残っています。
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測定基準(例えば、株式会社Transmitアルゴリズム[ABF00])に組み入れられるかもしれないことに注意してください。 しかしながら、特定のBTCでメートル法で完全に指定されていて、どんな実現決定も関連RFCs SHOULDで提供しました。
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方法論がこれらの測定基準に組み込まれるのは、RECOMMENDEDです。 あるいはまた、BTC実現が後工程(例えば、接続のセグメント跡を提供するのによる)を通して付属の測定基準を引き出すことができるように十分な情報を提供するのは、RECOMMENDEDです。
3.1 Congestion Avoidance Capacity
3.1 輻輳回避容量
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)メートル法であることは、Congestion Avoidanceアルゴリズムの完全に指定された実現のデータ信号速度(bps)です、Retransmission TimeoutとSlow-スタートアルゴリズムが呼び出されないという制限を受けることがあります。 CAC、メートル法、Retransmission TimeoutsかSlow-スタートの期間(セクション2で議論するように回復に続くことが許可されているただ一つのセグメントSlow-始めを除いた)の向こう側に意味でないのを持つために、定義されます。
Mathis, et al. Informational [Page 5] RFC 3148 Framework for Defining Empirical BTC Metrics July 2001
マシス、他 測定基準2001年7月に実証的なBTCを定義するための情報[5ページ]のRFC3148枠組み
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.
原則としてa CACメートル法であることは、それとしてのメートル法の理想的なBTCがTCPの定常状態の振舞いであるべきであるものを得るということでしょう。 しかし、そういうものとしてそれを使用するかなりかなりの困難があります。 Congestion AvoidanceアルゴリズムのSelf時計は非常にこわれやすい場合があります、Fast Retransmit、Fast Recoveryまたは選ばれた高度な回復アルゴリズムの特定の詳細によって。 遅れた出発損失回復のタイムアウトと期間がインターネット[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がSelf-時計をなくすとき、それは再送タイムアウトとSlow-始めで復職します。 これらのアルゴリズムはCongestion Avoidanceが取っただろうより多くの時間をほとんどいつも必要とします。 ネットワークがデータの全体の窓をなくさない場合(どれが明確にaを必要とするだろうかがタイムアウトを再送します)TCPがおそらく安全にデータを送る何らかの機会を逃したのが容易に観測されます。 すなわち、データの部分的な窓をなくした後にTCPがタイムアウトを経験するなら、それはいくつかの部分的なデータを送った後に発生しましたが、新しいデータの伝達の引き金とならなかった少なくとも1ACKを受けたに違いありません。 逆の条件の下で公正を保持している間、TCPのSelf-時計をよりしぶとくするとして輻輳制御(例えば、ファーク[MM96a]、NewReno[FF96、RFC2582]、レートを半分にする[MSML99])における最近の研究を特徴付けることができます。 不十分に現在のTCP実現がしばしば繰り返された時計の損失のためいくつかの条件のもとでどう働くかによってこの仕事は動機づけられています。 これがアクティブな研究領域であるので、異なったTCP実現はSelf-時計を保存する彼らの能力でかなりかなりの違いを持っています。
3.2 Preservation of Self-Clock
3.2 自己時計の保存
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に大きい影響を与えることができます、そして、時計はそれ自体で損失回復アルゴリズムに依存する方法でこわれやすいです。 したがって、タイマの間の変遷は、操作SHOULDを運転して、Self時間を計りました。器具を取り付けられます。
3.2.1 Lost Transmission Opportunities
3.2.1無くなっているトランスミッションの機会
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の領収書であったなら、交互の輻輳制御アルゴリズムが首尾よくSelf-時計を保存しただろう可能性は存在しています。 これが混雑におけるさらなる改良に通じるかもしれないという望みにおけるBTC状態(混雑ウィンドウなどの)のBTC SHOULD器具重要品目はアルゴリズムを制御します。
Mathis, et al. Informational [Page 6] RFC 3148 Framework for Defining Empirical BTC Metrics July 2001
マシス、他 測定基準2001年7月に実証的なBTCを定義するための情報[6ページ]のRFC3148枠組み
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が最終である傾向があるなら、ネットワーク状態を測って、見積もるかつてより微妙な方法があります。
3.2.2 Loosing an Entire Window
3.2.2 全体の窓を発射すること。
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.
データ(または、ACKs)の全体の窓が無くなると、追加データの仕事を終えるためにACKsを返してはいけないでしょう。 タイムアウトの前の最後の出来事がACKによって引き起こされたデータ伝送であったならこの状態を検出できます。 データ/ACKsの全体の窓の損失によって、回復がRetransmission TimeoutとSlow-始めでやむを得ずあります。
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測定基準SHOULD器具とレポートの損失。
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に器具を取り付けるのについて重要性を前面に出す)で全体の窓がなくされる場合があるという重要な確率があるかで。
3.2.3 Heroic Clock Preservation
3.2.3 大胆な時計保存
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).
SHOULD、他のアルゴリズムであるときに与えられたBTCがSelf-時計を支えることを許可するすべてのアルゴリズムはそうしないかもしれません。器具を取り付けられます。 その上、使用されるアルゴリズムの詳細を完全に記録しなければなりません(セクション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).
それが支えることができるBTC測定基準は複数の損失の面前で1個の周遊旅行SHOULD器具の中に損失分配のSelf時間を計ります、(例えば、リノスタイル)であると交互の輻輳制御アルゴリズムの性能を見積もることができるように。
3.2.4 False Timeouts
3.2.4 誤ったタイムアウト
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が到着する前に再送信タイマーはそこで期限が切れます)SHOULD、可能であるときには、器具を取り付けられてください。 BTCのメートル法の道具一連番号でありこれは検出するのがどう難しいかもしれないかよって、それに注意してください。
Mathis, et al. Informational [Page 7] RFC 3148 Framework for Defining Empirical BTC Metrics July 2001
マシス、他 測定基準2001年7月に実証的なBTCを定義するための情報[7ページ]のRFC3148枠組み
3.3 Ancillary Metrics Relating to Flow Based Path Properties
3.3 流れに関連する付属の測定基準が経路の特性を基礎づけました。
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持続時間供給停止に関するケースのように、これらは、低率(1RTTあたり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測定基準SHOULD器具パケット再命令。 頻度と順序が狂って距離SHOULD、すべてのアウトのために器具を取り付けられてください、-、オーダーパケットについて。 3つの異なったケースの1つとしてどのSHOULDについてそれぞれ再命令の厳しさを分類できるか。報告されます。
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測定基準SHOULDは、-わずかに外では、オーダーでは、セグメントがどのように混雑窓の計算に影響するかを記録します。
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.
セグメントが十分不適切であるなら、Fast Retransmitアルゴリズムは遅れたパケットの遅刻者の前に呼び出されるでしょう。 これらのイベント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]。 これらのSHOULD、いつも器具を取り付けられてください。
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.
最大のcwndが輻輳回避と遅れた出発の間に観測したBTC実現SHOULD器具。 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)低下確率はウィンドウサイズに関連します。 これらは未解決の研究問題です。
3.4 Ancillary Metrics as Calibration Checks
3.4 較正チェックとしての付属の測定基準
Unlike low rate metrics, BTC SHOULD include explicit checks that the test platform is not the bottleneck.
低いレート測定基準と異なって、BTC SHOULDはボトルネックではなく、テストプラットホームがそうである明白なチェックを含んでいます。
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.
送付ホストの中のどんな検出された低下しているパケットも報告しなければなりません。 送付インタフェースが経路ボトルネックでないなら、どんな低下しているパケットもたぶん測定失敗を示します。
Mathis, et al. Informational [Page 8] RFC 3148 Framework for Defining Empirical BTC Metrics July 2001
マシス、他 測定基準2001年7月に実証的なBTCを定義するための情報[8ページ]のRFC3148枠組み
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.
最大は長さを列に並ばせます。発信しているホストSHOULDの中では、器具を取り付けられてください。 どんな重要な待ち行列も、送付ホストには不十分な炸裂データ信号速度があるのを示すかもしれなくて、ネットワークに送られるデータを整えています。
3.5 Ancillary Metrics Relating to the Need for Advanced TCP Features
3.5 高度なTCPの特徴の必要性に関連する付属の測定基準
If TCP would require advanced TCP extensions to match BTC performance (such as RFC 1323 or RFC 2018 features), it SHOULD be reported.
TCPは、高度なTCP拡張子がBTC性能(RFC1323かRFC2018の特徴などの)に合っているのを必要として、それはSHOULDです。報告されます。
3.6 Validate Reverse Path Load
3.6は逆の経路負荷を有効にします。
To the extent possible, the BTC metric SHOULD distinguish between the properties of the forward and reverse paths.
可能な範囲内で、BTCのメートル法のSHOULDはフォワードの特性を見分けて、経路を覆します。
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のメートル法のSHOULDで貢献しました。
To the extent possible, BTC methodologies that rely on cooperating receivers SHOULD support separate ancillary metrics for the forward and reverse paths.
可能な範囲内で、受信機SHOULDが支持する協力を当てにする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.
インターネット測定値を行うと、安全上の配慮は上げられます。 このメモがメートル法でaの特定の実現を指定しないので、それは直接インターネットで動くインターネットとアプリケーションのセキュリティに影響しません。 しかしながら、測定基準は、この枠組みの中で生産して、測定基準の特定の実現で安全保障問題を作成するかもしれません。
4.1 Denial of Service Attacks
4.1 サービス妨害攻撃
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.
本書では定義される大量のTransport Capacity測定基準は、ボトルネックリンクをいっぱいにするのを自然に試みます。 この仕様に基づくBTC測定基準は電流がTCP接続をよく調整したから「ネットワーク好意的である」としてです。 しかしながら、「接続」がTCPパケットを使用していないかもしれないので、BTCテストはサービス不能攻撃としてネットワーク・オペレータにとって現れるかもしれません。
Mathis, et al. Informational [Page 9] RFC 3148 Framework for Defining Empirical BTC Metrics July 2001
マシス、他 測定基準2001年7月に実証的なBTCを定義するための情報[9ページ]のRFC3148枠組み
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測定基準の収集のタイミング、サイズ、および頻度に関する双方の、または、マルチ側部の協定を確立したがっているかもしれません。
4.2 User data confidentiality
4.2 ユーザデータの機密性
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.
この枠組みの中の測定基準はサンプルのために利用者データに基づいて見本を作るよりパケットをむしろ発生させます。 その結果、a BTCメートル法、ユーザデータの機密性を脅かしません。
4.3 Interference with metrics
4.3 測定基準の干渉
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.
パケットのそのaあるパケットか流れを特定するのにおいて可能であるのが、a 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問題が全くありません。 しかしながら、メートル法でaを実行する特定のプロトコルにおけるこの枠組み以内とメートル法のバルク輸送容量には、記述される必要がある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.
マット・マシスの仕事はグラントNumbers9415552と9870758の下で国立科学財団によって支持されました。
Mathis, et al. Informational [Page 10] RFC 3148 Framework for Defining Empirical BTC Metrics July 2001
マシス、他 測定基準2001年7月に実証的なBTCを定義するための情報[10ページ]のRFC3148枠組み
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]ハーリBalakrishnan(Venkata Padmanabhan、Srinivasan Seshan)はStemm、およびランディ・キャッツをマークします。 忙しいウェブサーバーのTCP働き: 分析と改良。 1997年8月の技術報告書UCB/CSD-97-966。 http://nms.lcs.mit.edu/~hari/papers/csd-97-966.ps から、利用可能です。 (Procでも。 IEEE INFOCOM Conf、サンフランシスコ(カリフォルニア)3月1998番目)
[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.。 「タホ、リノ、および袋の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 を通したObtain。
[Hoe96] Hoe, J., "Improving the start-up behavior of a
congestion control scheme for TCP, Proceedings of ACM
SIGCOMM '96, August 1996.
[Hoe96]は鍬を入れます、J.、「1996年8月96年の間、TCP、ACM SIGCOMMのProceedingsの輻輳制御計画の始動の振舞いを改良し」て。
[Hoe95] Hoe, J., "Startup dynamics of TCP's congestion control
and avoidance schemes". Master's thesis, Massachusetts
Institute of Technology, June 1995.
J.、[Hoe95]は鍬を入れます、そして、「TCPの混雑の始動力学は制御されます、そして、回避は計画します」。 修士論文、マサチューセッツ工科大学、1995年6月。
[Jac88] Jacobson, V., "Congestion Avoidance and Control",
Proceedings of SIGCOMM '88, Stanford, CA., August 1988.
[Jac88] ジェーコブソンと、V.と、「輻輳回避とコントロール」、SIGCOMM88年、スタンフォード(カリフォルニア)の議事、8月1988日
[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 Transactions C-26、HighパフォーマンスNetworking、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の速い回復戦略:」 「分析と改良」(InfoComの議事)は1998を行進させます。
[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のパフォーマンス。」 Networkingの上のIEEE/ACM Transactions、Vol.5、No.3、1997年6月、pp.336-350。
Mathis, et al. Informational [Page 11] RFC 3148 Framework for Defining Empirical BTC Metrics July 2001
マシス、他 測定基準2001年7月に実証的なBTCを定義するための情報[11ページ]のRFC3148枠組み
[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.、「実証的なバルク転送容量」、IPパフォーマンスMetrics作業部会はForty Thirdインターネット・エンジニアリング・タスク・フォースのProceedingsで報告します、オーランド(フロリダ)1988年12月。 http://www.ietf.org/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 SIGCOMM96年、スタンフォードのProceedings、カリフォルニア、8月1996日
[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輻輳回避の静止した振舞い」とInは、1996年8月に進行します。 ftp.bellcore.comにアノニマスFTPを使用して、パブ/を通してtjo/TCPwindow.psを入手してください。
[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におけるウィンドウサイズの振舞い」、ネットワーク、インターネット(1996年11月)におけるリアルタイムのアプリケーションのパフォーマンスに関するワークショップでのDIMACSの特別な年。
[Pax97a] Paxson, V., "Automated Packet Trace Analysis of TCP
Implementations", Proceedings of ACM SIGCOMM '97, August
1997.
[Pax97a] パクソン、V.、「TCP実現の自動化されたパケット微量成分分析」、ACM SIGCOMM97年、1997年8月の議事。
[Pax97b] Paxson, V., "End-to-End Internet Packet Dynamics,"
Proceedings of SIGCOMM '97, Cannes, France, Sep. 1997.
[Pax97b] パクソン、V.、「終わりから終わりへのインターネットパケット力学」、SIGCOMM97年、カンヌ(フランス)9月1997の議事
[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スループット:」 「Simple ModelとそのEmpirical Validation」、ACM SIGCOMM98年、8月1998のProceedings
Mathis, et al. Informational [Page 12] RFC 3148 Framework for Defining Empirical BTC Metrics July 2001
マシス、他 測定基準2001年7月に実証的なBTCを定義するための情報[12ページ]のRFC3148枠組み
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. Obtain via: http://www.rfc-
editor.org/rfc/rfc793.txt
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、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発見」、RFC1191、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
V.、ブレーデン、R. and D.ボーマン、「高性能のためのTCP拡張子」という[RFC1323]ジェーコブソンは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、「インターネット構造における統合サービス:」 「概観」、RFC1633、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
[RFC2001] スティーブンスと、W.と、「遅れた出発、輻輳回避が速く再送するTCP、および速い回復アルゴリズム」、RFC2001、1月1997日 以下を通って得ます。 http://www.rfc- editor.org/rfc/rfc2001.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の選択している承認オプション」、RFC2018、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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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、「ネットワーク要素サービス仕様テンプレート」、RFC2216、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パフォーマンス測定基準のための枠組み」、RFC2330、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.ウィス、「微分されたサービスのための構造」、RFC2475、1998年12月。 以下を通って得ます。 http://www.rfc- editor.org/rfc/rfc2475.txt
Mathis, et al. Informational [Page 13] RFC 3148 Framework for Defining Empirical BTC Metrics July 2001
マシス、他 測定基準2001年7月に実証的なBTCを定義するための情報[13ページ]のRFC3148枠組み
[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
1999年1月の[RFC2481]RamakrishnanとK.S.フロイド、「Explicit Congestion Notification(電子証券取引ネットワーク)をIPに追加するProposal」RFC2481。 以下を通って得ます。 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実現問題」、RFC2525、1999年3月。 以下を通って得ます。 http://www.rfc- editor.org/rfc/rfc2525.txt
[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輻輳制御」、RFC2581、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.ヘンダーソン、「TCPの速い回復アルゴリズムへのNewReno変更」、RFC2582、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] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。 以下を通って得ます。 http://www.rfc-editor.org/rfc/rfc2988.txt
[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] オールマンとM.とBalakrishnanとH.とS.フロイド、「株式会社を使用することでTCPの損失回復を機能アップして、伝わってください」、RFC3042、2001年1月。 以下を通って得ます。 http://www.rfc- editor.org/rfc/rfc3042.txt
[Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The
Protocols", Addison-Wesley, 1994.
w.[Ste94]スティーブンス、「TCP/IPは例証して、ボリュームは1です」。 「プロトコル」、アディソン-ウエスリー、1994。
[WS95] Wright, G., Stevens, W., "TCP/IP Illustrated Volume II:
The Implementation", Addison-Wesley, 1995.
[WS95] w.ライト、G.、スティーブンス、「TCP/IPは巻IIを例証しました」。 「実現」、アディソン-ウエスリー、1995。
Mathis, et al. Informational [Page 14] RFC 3148 Framework for Defining Empirical BTC Metrics July 2001
マシス、他 測定基準2001年7月に実証的なBTCを定義するための情報[14ページ]のRFC3148枠組み
Author's Addresses
作者のアドレス
Matt Mathis Pittsburgh Supercomputing Center 4400 Fifth Ave. Pittsburgh PA 15213
マットマシスピッツバーグSupercomputingは4400黙秘権Aveを中心に置きます。 ピッツバーグ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グレンリサーチセンタルイス分野21000Brookpark通り MS54-2クリーブランド、OH 44135
Phone: 216-433-6586 EMail: mallman@bbn.com http://roland.grc.nasa.gov/~mallman
以下に電話をしてください。 216-433-6586 メールしてください: mallman@bbn.com http://roland.grc.nasa.gov/~mallman
Mathis, et al. Informational [Page 15] RFC 3148 Framework for Defining Empirical BTC Metrics July 2001
マシス、他 測定基準2001年7月に実証的なBTCを定義するための情報[15ページ]のRFC3148枠組み
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Mathis, et al. Informational [Page 16]
マシス、他 情報[16ページ]
一覧
スポンサーリンク
