[要約] RFC 2680は、IPPMのための片方向のパケットロスメトリックに関する要約です。その目的は、ネットワークのパフォーマンスを評価するためのパケットロスの測定方法を提供することです。
Network Working Group G. Almes
Request for Comments: 2680 S. Kalidindi
Category: Standards Track M. Zekauskas
Advanced Network & Services
September 1999
A One-way Packet Loss Metric for IPPM
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This memo defines a metric for one-way packet loss across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330 [1]; the reader is assumed to be familiar with that document.
このメモはインターネットパス間で一方向のパケット損失のためのメトリックを定義します。これはIPPMフレームワークドキュメントに導入され論じ概念、RFC 2330 [1]に基づいています。読者は、その文書に精通しているものとします。
This memo is intended to be parallel in structure to a companion document for One-way Delay ("A One-way Delay Metric for IPPM") [2]; the reader is assumed to be familiar with that document.
このメモは、一方向遅延（「一方向IPPMの遅延メトリック」）[2]のための仲間ドキュメントに構造に平行であることを意図しています。読者は、その文書に精通しているものとします。
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 RFC 2119 [5]. Although RFC 2119 was written with protocols in mind, the key words are used in this document for similar reasons. They are used to ensure the results of measurements from two different implementations are comparable, and to note instances when an implementation could perturb the network.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[5]。 RFC 2119を念頭にプロトコルで書かれていたが、キーワードは、同様の理由でこの文書で使用されています。彼らは、二つの異なる実装からの測定の結果を確実にするために同等で使用され、実装がネットワークを乱すことができるときのインスタンスに注意します。
The structure of the memo is as follows:
次のようにメモの構造は次のとおりです。
+ A 'singleton' analytic metric, called Type-P-One-way-Loss, is introduced to measure a single observation of packet transmission or loss.
+ A「シングルトン」解析メトリックと呼ばれるタイプP-ワンウェイ損失、パケットの送信または損失の単一の観察を測定するために導入されます。
+ Using this singleton metric, a 'sample', called Type-P-One-way-Loss-Poisson-Stream, is introduced to measure a sequence of singleton transmissions and/or losses measured at times taken from a Poisson process.
タイプP-ワンウェイ・ロス・ポアソン・ストリームと呼ばれるメトリックこのシングルトン、「サンプル」を、使用して+、シングルトン送信および/またはポアソン過程から取られた時間で測定された損失のシーケンスを測定するために導入されます。
+ Using this sample, several 'statistics' of the sample are defined and discussed.
このサンプルを使用して+、サンプルのいくつかの「統計は、」が定義され、議論されています。
This progression from singleton to sample to statistics, with clear separation among them, is important.
統計にサンプリングするシングルトンからのこの進行は、それらの間に明確な分離で、重要です。
Whenever a technical term from the IPPM Framework document is first used in this memo, it will be tagged with a trailing asterisk. For example, "term*" indicates that "term" is defined in the Framework.
IPPMフレームワークの文書から専門用語が最初にこのメモで使用されるたびに、末尾にアスタリスクでタグ付けされます。たとえば、「用語の*は」「という用語は、」フレームワークで定義されていることを示しています。
Understanding one-way packet loss of Type-P* packets from a source host* to a destination host is useful for several reasons:
宛先ホストに送信元ホスト*からタイプPの*パケットの一方向のパケット損失を理解することは、いくつかの理由のために有用です：
+ Some applications do not perform well (or at all) if end-to-end loss between hosts is large relative to some threshold value.
+ホスト間のエンドツーエンドの損失がある閾値に対して大きい場合、一部のアプリケーションでは、ウェル（またはまったく）行いません。
+ Excessive packet loss may make it difficult to support certain real-time applications (where the precise threshold of "excessive" depends on the application).
+過度のパケット損失は、それが難しい（「過剰」の正確なしきい値は、アプリケーションによって異なります）、特定のリアルタイムアプリケーションをサポートすることがあります。
+ The larger the value of packet loss, the more difficult it is for transport-layer protocols to sustain high bandwidths.
トランスポート層プロトコルは高い帯域幅を維持するために+パケットロスの値が大きいほど、より困難です。
+ The sensitivity of real-time applications and of transport-layer protocols to loss become especially important when very large delay-bandwidth products must be supported.
+非常に大きな遅延帯域幅積がサポートしなければならないときにリアルタイムアプリケーションの、特に重要になっ損失へのトランスポート層プロトコルの感度。
The measurement of one-way loss instead of round-trip loss is motivated by the following factors:
代わりに、往復損失の一方向損失の測定は、以下の要因によって動機付けされます。
+ In today's Internet, the path from a source to a destination may be different than the path from the destination back to the source ("asymmetric paths"), such that different sequences of routers are used for the forward and reverse paths. Therefore round-trip measurements actually measure the performance of two distinct paths together. Measuring each path independently highlights the performance difference between the two paths which may traverse different Internet service providers, and even radically different types of networks (for example, research versus commodity networks, or ATM versus packet-over-SONET).
+今日のインターネットでは、ソースから宛先へのパスは、バックソース（「非対称パス」）にルータの異なる配列をフォワードするために使用されるように目的地から経路とは異なることと経路を逆にしてもよいです。したがって、往復の測定は、実際には2つの別個の経路の性能を測定します。各経路を測定することは独立に異なるインターネットサービスプロバイダを横断し、さらには根本的に異なる（例えば、商品のネットワークに対する研究、またはパケットオーバーSONET対ATM）ネットワークの種類得る2つの経路間の性能差を強調する。
+ Even when the two paths are symmetric, they may have radically different performance characteristics due to asymmetric queueing.
2つのパスが対称である場合に+でも、それらは非対称キューイングによる根本的に異なる性能特性を有することができます。
+ Performance of an application may depend mostly on the performance in one direction. For example, a file transfer using TCP may depend more on the performance in the direction that data flows, rather than the direction in which acknowledgements travel.
+アプリケーションのパフォーマンスは、1つの方向の性能にほとんど依存してもよいです。例えば、TCPを使用してファイル転送は、データが流れる方向の性能ではなく、旅行を肯定応答する方向にもっと依存し得ます。
+ In quality-of-service (QoS) enabled networks, provisioning in one direction may be radically different than provisioning in the reverse direction, and thus the QoS guarantees differ. Measuring the paths independently allows the verification of both guarantees.
+のサービス品質（QoS）対応ネットワークでは、一方向のプロビジョニングは、逆方向にプロビジョニングより根本的に異なっていてもよく、従ってQoS保証が異なります。経路を測定することは、独立して、両方の保証の検証を可能にします。
It is outside the scope of this document to say precisely how loss metrics would be applied to specific problems.
これは、特定の問題に適用される正確にどのように損失メトリクスと言って、このドキュメントの範囲外です。
{Comment: the terminology below differs from that defined by ITU-T documents (e.g., G.810, "Definitions and terminology for synchronization networks" and I.356, "B-ISDN ATM layer cell transfer performance"), but is consistent with the IPPM Framework document. In general, these differences derive from the different backgrounds; the ITU-T documents historically have a telephony origin, while the authors of this document (and the Framework) have a computer systems background. Although the terms defined below have no direct equivalent in the ITU-T definitions, after our definitions we will provide a rough mapping. However, note one potential confusion: our definition of "clock" is the computer operating systems definition denoting a time-of-day clock, while the ITU-T definition of clock denotes a frequency reference.}
{コメント：以下の用語は、（例えば、G.810「の定義及び用語同期ネットワークのために」とI.356、「B-ISDN ATMレイヤセル転送性能」）ITU-T文書によって定義されたものとは異なるが、一致していますIPPMフレームワークドキュメントと。一般的に、これらの違いは、異なる背景から派生します。このドキュメント（およびフレームワーク）の著者は、コンピュータシステムのバックグラウンドを持っていながら、ITU-T文書は歴史的に、電話の起源を持っています。以下に定義する用語は、ITU-Tの定義には直接対応を持っていませんが、私たちの定義の後に我々はラフなマッピングを提供します。しかし、1混乱の点に注意してください。時計のITU-Tの定義は、周波数基準を示しながら、「時計」の私達の定義は、時刻クロックを表すコンピュータのオペレーティングシステムの定義です}。
Whenever a time (i.e., a moment in history) is mentioned here, it is understood to be measured in seconds (and fractions) relative to UTC.
時間（歴史の中で、すなわち、モーメント）がここに記載されているときはいつでも、UTCに対する秒（画分）において測定されていると理解されます。
As described more fully in the Framework document, there are four distinct, but related notions of clock uncertainty:
フレームワークドキュメントで詳しく説明するように、クロックの不確実性の4つの異なる、しかし関連概念があります。
synchronization*
同期*
Synchronization measures the extent to which two clocks agree on
what time it is. For example, the clock on one host might be
5.4 msec ahead of the clock on a second host. {Comment: A rough
ITU-T equivalent is "time error".}
accuracy*
正確さ*
Accuracy measures the extent to which a given clock agrees with
UTC. For example, the clock on a host might be 27.1 msec behind
UTC. {Comment: A rough ITU-T equivalent is "time error from
UTC".}
resolution*
解決*
Resolution measures the precision of a given clock. For
example, the clock on an old Unix host might advance only once
every 10 msec, and thus have a resolution of only 10 msec.
{Comment: A very rough ITU-T equivalent is "sampling period".}
skew*
斜め*
Skew measures the change of accuracy, or of synchronization,
with time. For example, the clock on a given host might gain
1.3 msec per hour and thus be 27.1 msec behind UTC at one time
and only 25.8 msec an hour later. In this case, we say that the
clock of the given host has a skew of 1.3 msec per hour relative
to UTC, which threatens accuracy. We might also speak of the
skew of one clock relative to another clock, which threatens
synchronization. {Comment: A rough ITU-T equivalent is "time
drift".}
Type-P-One-way-Packet-Loss
タイプ-P-ワンウェイパケット損失
+ Src, the IP address of a host
+ SRC、ホストのIPアドレス
+ Dst, the IP address of a host
+ Dstの、ホストのIPアドレス
+ T, a time
+ T、時間
The value of a Type-P-One-way-Packet-Loss is either a zero (signifying successful transmission of the packet) or a one (signifying loss).
タイプP-ワンウェイパケット損失の値がゼロ（パケットの意味送信成功）または1（損失を意味する）のいずれかです。
>>The *Type-P-One-way-Packet-Loss* from Src to Dst at T is 0<< means that Src sent the first bit of a Type-P packet to Dst at wire-time* T and that Dst received that packet.
>> Tにおけるsrcからdstへ*タイプP-ワンウェイパケット損失*が0 << SRCはDstのワイヤ時間* Tで、そのDSTのタイプPのパケットの最初のビットを送信したことを意味していますそのパケットを受信しました。
>>The *Type-P-One-way-Packet-Loss* from Src to Dst at T is 1<< means that Src sent the first bit of a type-P packet to Dst at wire-time T and that Dst did not receive that packet.
>> TでのSrcからDSTの*タイプP-ワンウェイパケット損失*は1 << SRCはワイヤ時間TでDSTのタイプPのパケットの最初のビットを送信し、dstがなかったことを意味そのパケットを受信しません。
Thus, Type-P-One-way-Packet-Loss is 0 exactly when Type-P-One-way-Delay is a finite value, and it is 1 exactly when Type-P-One-way-Delay is undefined.
このように、タイプP-ワンウェイパケット損失は0を正確に入力し-P-ワンウェイ遅延が有限の値である、そしてそれはタイプP-ワンウェイ遅延が未定義の正確とき1です。
The following issues are likely to come up in practice:
次の問題は、実際に出てくる可能性があります。
+ A given methodology will have to include a way to distinguish between a packet loss and a very large (but finite) delay. As noted by Mahdavi and Paxson [3], simple upper bounds (such as the 255 seconds theoretical upper bound on the lifetimes of IP packets [4]) could be used, but good engineering, including an understanding of packet lifetimes, will be needed in practice. {Comment: Note that, for many applications of these metrics, there may be no harm in treating a large delay as packet loss. An audio playback packet, for example, that arrives only after the playback point may as well have been lost.}
与えられた方法論を+は、パケット損失と非常に大きい（しかし有限の）遅延を区別する方法を含むことがあります。 Mahdaviとパクソンで述べたように、[3]、簡単な上限（IPパケットの寿命上に結合した理論上、このような255秒としては、[4]）を使用することができますが、良いエンジニアリング、パケット寿命の理解を含め、必要とされるであろう実際には。 {コメント：なお、これらのメトリックの多くの用途のために、パケットロスなどの大きな遅延を治療するのに害がなくてもよいです。のみ再生ポイントの後に到着した例えばオーディオ再生パケットは、同様に失われた可能性があります。}
+ If the packet arrives, but is corrupted, then it is counted as lost. {Comment: one is tempted to count the packet as received since corruption and packet loss are related but distinct phenomena. If the IP header is corrupted, however, one cannot be sure about the source or destination IP addresses and is thus on shaky grounds about knowing that the corrupted received packet corresponds to a given sent test packet. Similarly, if other parts of the packet needed by the methodology to know that the corrupted received packet corresponds to a given sent test packet, then such a packet would have to be counted as lost. Counting these packets as lost but packet with corruption in other parts of the packet as not lost would be inconsistent.}
+パケットが到着したが、破損している場合に失われたとして、それはカウントされます。 {コメント：つが破損し、パケット損失が関連するが異なる現象であるので、受信したパケットをカウントするために誘惑されます。 IPヘッダが破損している場合、しかし、一方が送信元または宛先IPアドレスについて確認することができず、破損し、受信したパケットが所与の送信テストパケットに対応することを知って約不安定敷地ことです。方法論が必要とするパケットの他の部分が破損し、受信したパケットが所与の送信テストパケットに対応することを知っている場合は同様に、そのようなパケットが失われたとしてカウントされなければなりません。失ったが、パケットとして一貫性のないだろう失われていないパケットの他の部分の破損で、これらのパケットを数えます。}
+ If the packet is duplicated along the path (or paths) so that multiple non-corrupt copies arrive at the destination, then the packet is counted as received.
+複数の非破損コピーが宛先に到着し、パケットを受信したとしてカウントされるように、パケットは経路（又は経路）に沿って複製される場合。
+ If the packet is fragmented and if, for whatever reason, reassembly does not occur, then the packet will be deemed lost.
+パケットが断片化された場合や何らかの理由で、再構築が発生していない、場合、パケットが失わみなされます。
As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, precedence).
他のタイプP- *メトリックと同様に、詳細な方法論は、タイプP（例えば、プロトコル番号、UDP / TCPポート番号、サイズ、優先度）に依存するであろう。
Generally, for a given Type-P, one possible methodology would proceed as follows:
次のように一般的に、与えられたタイプPのために、一つの可能な方法は進行します。
+ Arrange that Src and Dst have clocks that are synchronized with each other. The degree of synchronization is a parameter of the methodology, and depends on the threshold used to determine loss (see below).
+ Srcとdstが互いに同期しているクロックを持っていることを配置します。同期化の程度は、（下記参照）方法のパラメータであり、損失を決定するために使用される閾値に依存します。
+ At the Src host, select Src and Dst IP addresses, and form a test packet of Type-P with these addresses.
+のSrcホストでは、SrcとDstのIPアドレスを選択して、これらのアドレスをタイプPのテストパケットを形成します。
+ At the Dst host, arrange to receive the packet.
+ Dstのホストでは、パケットを受信するためにアレンジ。
+ At the Src host, place a timestamp in the prepared Type-P packet, and send it towards Dst.
+のSrcホストでは、準備されたタイプPパケットにタイムスタンプを置き、Dstの方にそれを送ります。
+ If the packet arrives within a reasonable period of time, the one-way packet-loss is taken to be zero.
+パケットが合理的な期間内に到着した場合、一方向のパケット損失はゼロとします。
+ If the packet fails to arrive within a reasonable period of time, the one-way packet-loss is taken to be one. Note that the threshold of "reasonable" here is a parameter of the methodology.
+パケットが合理的な期間内に到着しなかった場合、一方向のパケット損失は1であると解釈されます。ここでは「合理的」のしきい値は、方法論のパラメータであることに注意してください。
{Comment: The definition of reasonable is intentionally vague, and is intended to indicate a value "Th" so large that any value in the closed interval [Th-delta, Th+delta] is an equivalent threshold for loss. Here, delta encompasses all error in clock synchronization along the measured path. If there is a single value after which the packet must be counted as lost, then we reintroduce the need for a degree of clock synchronization similar to that needed for one-way delay. Therefore, if a measure of packet loss parameterized by a specific non-huge "reasonable" time-out value is needed, one can always measure one-way delay and see what percentage of packets from a given stream exceed a given time-out value.}
{コメント：合理的な定義が意図的曖昧であり、値「Thの」閉区間の任意の値が[TH-δ、TH +δは損失の等価しきい値となるように大きいことを示すことを意図しています。ここでは、デルタは、測定されたパスに沿ってクロック同期のすべてのエラーを含みます。パケットが失われたとしてカウントされなければならない後に単一の値がある場合、我々は一方向の遅延のために必要なものと同様クロック同期の程度の必要性を再導入します。特定非巨大な「合理的な」タイムアウト値によってパラメータパケットロスの測定が必要な場合はそのため、一つは、常に一方向の遅延を測定し、与えられたタイムアウト値を超えて指定されたストリームから何のパケットの割合を見ることができます。}
Issues such as the packet format, the means by which Dst knows when to expect the test packet, and the means by which Src and Dst are synchronized are outside the scope of this document. {Comment: We plan to document elsewhere our own work in describing such more detailed implementation techniques and we encourage others to as well.}
そのようなパケットフォーマットなどの問題、試験パケットを期待する場合にDSTが知っする手段、およびSrcとdstが同期される手段は、この文書の範囲外です。 {コメント：私たちは、このような、より詳細な実装技術を記述する際に他の場所で私たち自身の仕事を文書化することを計画し、我々としてもに他の人を励まします。}
The description of any specific measurement method should include an accounting and analysis of various sources of error or uncertainty. The Framework document provides general guidance on this point.
任意の具体的な測定方法の説明は、会計及びエラーまたは不確定性のさまざまなソースの分析を含むべきです。フレームワークドキュメントは、この点に関する一般的なガイダンスを提供します。
For loss, there are three sources of error:
損失の場合は、エラーの3つの源があります。
+ Synchronization between clocks on Src and Dst.
+ SrcとDstの上のクロック間の同期。
+ The packet-loss threshold (which is related to the synchronization between clocks).
+（クロック間の同期に関連する）、パケット損失閾値。
+ Resource limits in the network interface or software on the receiving instrument.
+受信機器のネットワークインタフェースまたはソフトウェアにおけるリソース制限。
The first two sources are interrelated and could result in a test packet with finite delay being reported as lost. Type-P-One-way-Packet-Loss is 0 if the test packet does not arrive, or if it does arrive and the difference between Src timestamp and Dst timestamp is greater than the "reasonable period of time", or loss threshold. If the clocks are not sufficiently synchronized, the loss threshold may not be "reasonable" - the packet may take much less time to arrive than its Src timestamp indicates. Similarly, if the loss threshold is set too low, then many packets may be counted as lost. The loss threshold must be high enough, and the clocks synchronized well enough so that a packet that arrives is rarely counted as lost. (See the discussions in the previous two sections.)
最初の二つのソースは相互に関連し、失われたと報告されている有限の遅延とテストパケットにつながる可能性があります。試験パケットが到着しない、またはそれが到着しない場合、およびSrcタイムスタンプとdstタイムスタンプの間の差は、「合理的な時間の期間」、または損失閾値よりも大きい場合、タイプP-ワンウェイパケット損失は0です。クロックが十分に同期されていない場合は、損失しきい値は、「合理的」ではないかもしれない - パケットがSrcのタイムスタンプが示すよりも到着するはるかに少ない時間がかかることがあります。損失しきい値の設定が低すぎる場合に失われたと同様に、その後、多くのパケットをカウントすることができます。損失しきい値は十分に高くなければならない、と失われたとして到着パケットはほとんどカウントされないようにクロックが十分同期。 （前の2節での議論を参照してください。）
Since the sensitivity of packet loss measurement to lack of clock synchronization is less than for delay, we refer the reader to the treatment of synchronization errors in the One-way Delay metric [2] for more details.
クロック同期の欠如にパケット損失測定の感度は遅延よりも小さいので、我々は、詳細については片道遅延メトリック[2]における同期エラーの処理を読者に参照します。
The last source of error, resource limits, cause the packet to be dropped by the measurement instrument, and counted as lost when in fact the network delivered the packet in reasonable time.
エラー、リソース制限の最後のソースは、パケットが測定器により滴下し、実際にネットワークが合理的な時間内にパケットを配信する際に失わとしてカウントされる原因。
The measurement instruments should be calibrated such that the loss threshold is reasonable for application of the metrics and the clocks are synchronized enough so the loss threshold remains reasonable.
測定機器は、損失閾値はメトリックの適用のための合理的であり、損失しきい値が妥当なままであるように、クロックが十分に同期されるように較正されなければなりません。
In addition, the instruments should be checked to ensure the that the possibility a packet arrives at the network interface, but is lost due to congestion on the interface or to other resource exhaustion (e.g., buffers) on the instrument is low.
また、器具は、パケットが機器のネットワークインターフェースに到着するが、インターフェイスまたは他のリソースの枯渇（例えば、バッファ）に輻輳のために失われる可能性が低いことを確認するためにチェックされるべきです。
The calibration and context in which the metric is measured MUST be carefully considered, and SHOULD always be reported along with metric results. We now present four items to consider: Type-P of the test packets, the loss threshold, instrument calibration, and the path traversed by the test packets. This list is not exhaustive; any additional information that could be useful in interpreting applications of the metrics should also be reported.
メトリックが測定されるキャリブレーションとコンテキストは慎重に考えなければなりませんし、常にメトリック結果とともに報告すること。私たちは、今現在4つの項目は、考慮すべき：テストパケットの種類-P、損失しきい値、機器の校正、およびテストパケットが通過するパス。このリストは網羅的なものではありません。メトリックの用途を解釈するのに有用である可能性のある追加の情報も報告されるべきです。
As noted in the Framework document [1], the value of the metric may depend on the type of IP packets used to make the measurement, or "Type-P". The value of Type-P-One-way-Delay could change if the protocol (UDP or TCP), port number, size, or arrangement for special treatment (e.g., IP precedence or RSVP) changes. The exact Type-P used to make the measurements MUST be accurately reported.
フレームワーク文書[1]で述べたように、メトリックの値が測定、または「タイプP」を作製するために使用されるIPパケットの種類に依存してもよいです。タイプP-一方向ディレイの値は変更することができ、特別な処置（例えば、IP precedenceまたはRSVP）変更するためのプロトコル（UDPまたはTCP）ポート番号、サイズ、又は構成場合。測定を行うために使用される正確なタイプPを正確に報告しなければなりません。
The threshold (or methodology to distinguish) between a large finite delay and loss MUST be reported.
大きな有限の遅延と損失の間の閾値（又は方法論を区別する）が報告されなければなりません。
The degree of synchronization between the Src and Dst clocks MUST be reported. If possible, possibility that a test packet that arrives at the Dst network interface is reported as lost due to resource exhaustion on Dst SHOULD be reported.
SrcとDstのクロック間の同期の程度は、報告されなければなりません。可能であれば、Dstの上枯渇資源に失われたとしてDstのネットワークインターフェースに到着するテストパケットが報告されている可能性が報告されるべきです。
Finally, the path traversed by the packet SHOULD be reported, if possible. In general it is impractical to know the precise path a given packet takes through the network. The precise path may be known for certain Type-P on short or stable paths. If Type-P includes the record route (or loose-source route) option in the IP header, and the path is short enough, and all routers* on the path support record (or loose-source) route, then the path will be precisely recorded. This is impractical because the route must be short enough, many routers do not support (or are not configured for) record route, and use of this feature would often artificially worsen the performance observed by removing the packet from common-case processing. However, partial information is still valuable context. For example, if a host can choose between two links* (and hence two separate routes from Src to Dst), then the initial link used is valuable context. {Comment: For example, with Merit's NetNow setup, a Src on one NAP can reach a Dst on another NAP by either of several different backbone networks.}
最後に、パケットが通過するパスは、可能な場合、報告する必要があります。一般的には、所与のパケットがネットワークを介してかかる正確なパスを知ることは非現実的です。正確なパスは、短いまたは安定した経路上の特定のタイプPのために知られてもよいです。タイプPは、レコードルート（またはルーズソースルート）IPヘッダ内のオプションを含み、経路が十分に短く、パスサポートレコード（またはルーズソース）経路上のすべてのルータ*、その後パスがなる場合正確に記録します。これは非現実的であるルートが十分に短くなければならないので、多くのルータがサポートしていない（またはのために設定されていない）レコードルート、およびこの機能の使用は、多くの場合、人為的に共通の場合の処理からパケットを除去することにより、観察した性能を悪化させるだろう。しかし、部分的な情報はまだ貴重な文脈です。ホストは、2つの間のリンク*（およびSrcからDSTの、したがって二つの別々の経路）を選択することができる場合、例えば、使用される最初のリンクは、貴重なコンテキストです。 {コメント：例えば、メリットのNetNowセットアップを一のNAP上のSrcは、いくつかの異なるバックボーンネットワークのいずれかによって別のNAP上のDstに達することができます。}
Given the singleton metric Type-P-One-way-Packet-Loss, we now define one particular sample of such singletons. The idea of the sample is to select a particular binding of the parameters Src, Dst, and Type-P, then define a sample of values of parameter T. The means for defining the values of T is to select a beginning time T0, a final time Tf, and an average rate lambda, then define a pseudo-random Poisson process of rate lambda, whose values fall between T0 and Tf. The time interval between successive values of T will then average 1/lambda.
シングルトンメトリックタイプ-P-ワンウェイパケット損失を考えると、我々は今、このようなシングルトンの一つの特定のサンプルを定義します。サンプルのアイデアはパラメータのSrc、Dstの、およびType-Pの特定の結合を選択することで、その後、Tの値を定義するためのパラメータTの値手段のサンプルを定義することは、開始時刻T0を選択することです最終時刻Tfと、平均速度、λは、次いで、値T0とTfとの間に入る率ラムダ、の擬似ランダムポアソン過程を定義します。 Tの連続する値の間の時間間隔は、次いで、平均1 /ラムダをします。
{Comment: Note that Poisson sampling is only one way of defining a sample. Poisson has the advantage of limiting bias, but other methods of sampling might be appropriate for different situations. We encourage others who find such appropriate cases to use this general framework and submit their sampling method for standardization.}
{コメント：ポアソンサンプリング、サンプルを定義する唯一の方法であることに留意されたいです。ポアソンは、バイアスを制限する利点がありますが、サンプリングの他の方法には、さまざまな状況のために適切であるかもしれません。私たちは、この一般的なフレームワークを使用し、標準化のための彼らのサンプリング方法を提出するなど、適切な例を見つける他の人を励まします。}
Type-P-One-way-Packet-Loss-Poisson-Stream
タイプ-P-ワンウェイパケット・ロス・ポアソンストリーム
+ Src, the IP address of a host
+ SRC、ホストのIPアドレス
+ Dst, the IP address of a host
+ Dstの、ホストのIPアドレス
+ T0, a time
+ T0、時間
+ Tf, a time
+ Tfは、時間
+ lambda, a rate in reciprocal seconds
+ラムダ、相反秒率
A sequence of pairs; the elements of each pair are:
ペアの配列;各対の要素は次のとおりです。
+ T, a time, and
+ T、時間、および
+ L, either a zero or a one
+ L、0又は1のいずれか
The values of T in the sequence are monotonic increasing. Note that T would be a valid parameter to Type-P-One-way-Packet-Loss, and that L would be a valid value of Type-P-One-way-Packet-Loss.
配列におけるTの値が増加する単調です。 Tは、TYPE-P-ワンウェイパケット損失への有効なパラメータとなり、そのLは、タイプP-ワンウェイパケット損失の有効な値になることに注意してください。
Given T0, Tf, and lambda, we compute a pseudo-random Poisson process beginning at or before T0, with average arrival rate lambda, and ending at or after Tf. Those time values greater than or equal to T0 and less than or equal to Tf are then selected. At each of the times in this process, we obtain the value of Type-P-One-way-Packet-Loss at this time. The value of the sample is the sequence made up of the resulting <time, loss> pairs. If there are no such pairs, the sequence is of length zero and the sample is said to be empty.
T0、Tfは、ラムダを考えると、我々は、擬似ランダムポアソン過程の平均到着率ラムダを、T0で以前に開始する、とのTfで以降に終了を計算します。これらの時間は、以上T0に等しく、以下のTfに等しいが、選択された値。このプロセスの時間の各々で、我々はこの時点でタイプ-P-ワンウェイパケット損失の値を取得します。サンプルの値が得られた<時間、損失>対から構成される配列です。そのようなペアが存在しない場合、配列の長さはゼロであり、試料は、空であると言われます。
The reader should be familiar with the in-depth discussion of Poisson sampling in the Framework document [1], which includes methods to compute and verify the pseudo-random Poisson process.
リーダは、擬似ランダムポアソン過程を計算し、検証する方法を含むフレームワーク文献[1]におけるポアソンサンプリングの詳細な議論に精通しなければなりません。
We specifically do not constrain the value of lambda, except to note the extremes. If the rate is too large, then the measurement traffic will perturb the network, and itself cause congestion. If the rate is too small, then you might not capture interesting network behavior. {Comment: We expect to document our experiences with, and suggestions for, lambda elsewhere, culminating in a "best current practices" document.}
極端に注意することを除いて私たちは具体的には、ラムダの値を制約しないでください。率が大きすぎると、測定トラフィックがネットワークを混乱させるだろう、と自体が輻輳を起こします。率が小さすぎる場合は、興味深いネットワーク動作をキャプチャしない場合があります。 {コメント：私たちは、と私たちの経験を文書化することを期待、と提案のために、他の場所でラムダ、「現在のベストプラクティス」のドキュメントで最高潮に達します。}
Since a pseudo-random number sequence is employed, the sequence of times, and hence the value of the sample, is not fully specified. Pseudo-random number generators of good quality will be needed to achieve the desired qualities.
擬似乱数列を用いているので、時間の順序、したがってサンプルの値は、完全に指定されていません。良質の擬似乱数生成器は、所望の品質を達成するために必要とされます。
The sample is defined in terms of a Poisson process both to avoid the effects of self-synchronization and also capture a sample that is statistically as unbiased as possible. The Poisson process is used to schedule the delay measurements. The test packets will generally not arrive at Dst according to a Poisson distribution, since they are influenced by the network.
サンプルは、自己同期化の影響を回避し、また、統計学的に可能な限り公平である試料を捕捉するために、両方のポアソン過程に関して定義されます。ポアソン過程は、遅延測定をスケジュールするために使用されます。それらはネットワークによって影響されるので、テストパケットは、一般に、ポアソン分布に従ってDstのに到着しないであろう。
{Comment: there is, of course, no claim that real Internet traffic arrives according to a Poisson arrival process.
{コメント：本当のインターネットトラフィックはポアソン到着過程に応じて到着したという主張は、もちろん、ありません。
It is important to note that, in contrast to this metric, loss rates observed by transport connections do not reflect unbiased samples. For example, TCP transmissions both (1) occur in bursts, which can induce loss due to the burst volume that would not otherwise have been observed, and (2) adapt their transmission rate in an attempt to minimize the loss rate observed by the connection.}
このメトリックとは対照的に、交通機関の接続で観測された損失率は公平なサンプルを反映していない、ということに注意することが重要です。例えば、TCPの送信は、（1）により、そうでなければ観察されていないバーストボリュームに損失を誘発し、そして（2）接続によって観察損失率を最小限にする試みにおいて、それらの送信レートを適応させることができ、バーストで発生します。}
All the singleton Type-P-One-way-Packet-Loss metrics in the sequence will have the same values of Src, Dst, and Type-P.
シーケンスのすべてのシングルトンタイプ-P-ワンウェイパケット損失メトリックは、Src、Dstの、およびType-Pの同じ値を持つことになります。
Note also that, given one sample that runs from T0 to Tf, and given new time values T0' and Tf' such that T0 <= T0' <= Tf' <= Tf, the subsequence of the given sample whose time values fall between T0' and Tf' are also a valid Type-P-One-way-Packet-Loss-Poisson-Stream sample.
メモはまた、T0からTfとを結ぶ一つのサンプル与えられ、与えられた新たな時間は、T0 <= T0' <= Tfと「<= Tfは、時刻の値の間に入る所与のサンプルのサブことT0' 値およびTfの」 T0' とのTf」も有効なタイプ-P-ワンウェイパケット・ロス・ポアソン・ストリームのサンプルです。
The methodologies follow directly from:
方法論は、直接からは、次のとおりです。
+ the selection of specific times, using the specified Poisson arrival process, and
、特定の時間の選択を指定+ポアソン到着プロセスを使用して、そして
+ the methodologies discussion already given for the singleton Type-P-One-way-Packet-Loss metric.
+方法論の議論はすでにメトリックシングルトンタイプ-P-ワンウェイパケット損失のために与えられました。
Care must be given to correctly handle out-of-order arrival of test packets; it is possible that the Src could send one test packet at TS[i], then send a second one (later) at TS[i+1], while the Dst could receive the second test packet at TR[i+1], and then receive the first one (later) at TR[i].
ケアを正しく処理するために与えられなければならないアウトオブオーダーテストパケットの到着。 [I + 1] DSTはTRで第2のテストパケットを受信することができながら、SRCは、[I + 1] TSで第1（後）を送信次いで、[i]はTSに一つのテストパケットを送信することが可能です、そしてその後、TR [I]で最初の（後）を受信します。
In addition to sources of errors and uncertainties associated with methods employed to measure the singleton values that make up the sample, care must be given to analyze the accuracy of the Poisson arrival process of the wire-times of the sending of the test packets. Problems with this process could be caused by several things, including problems with the pseudo-random number techniques used to generate the Poisson arrival process. The Framework document shows how to use the Anderson-Darling test verify the accuracy of the Poisson process over small time frames. {Comment: The goal is to ensure that the test packets are sent "close enough" to a Poisson schedule, and avoid periodic behavior.}
試料を構成するシングルトン値を測定するために使用される方法に関連したエラーおよび不確実性の源に加えて、ケアは、試験パケットの送信のワイヤ倍のポアソン到着プロセスの精度を分析するために与えられなければなりません。このプロセスの問題点は、ポアソン到着プロセスを生成するために使用される擬似乱数技術の問題点を含むいくつかのもの、で発生することができます。フレームワークドキュメントは、小さな時間枠にわたってポアソン過程の正確さを検証アンダーソン・ダーリン検定を使用する方法を示します。 {コメント：目標は、テストパケットはポアソンスケジュールに「十分に近い」、および周期的現象を回避するため送信されることを保証することです。}
The calibration and context for the underlying singletons MUST be reported along with the stream. (See "Reporting the metric" for Type-P-One-way-Packet-Loss.)
基礎となるシングルトンのためのキャリブレーションとコンテキストは、ストリームと一緒に報告しなければなりません。 （タイプP-ワンウェイパケット損失のための「メトリックの報告」を参照してください。）
Given the sample metric Type-P-One-way-Packet-Loss-Poisson-Stream, we now offer several statistics of that sample. These statistics are offered mostly to be illustrative of what could be done.
サンプルメトリックタイプ-P-ワンウェイパケット・ロス・ポアソン・ストリームを考えると、私たちは今、そのサンプルのいくつかの統計情報を提供します。これらの統計は、何ができるかを説明することを主に提供されています。
Given a Type-P-One-way-Packet-Loss-Poisson-Stream, the average of all the L values in the Stream. In addition, the Type-P-One-way-Packet-Loss-Average is undefined if the sample is empty.
タイプP-ワンウェイパケット・ロス・ポアソン・ストリーム、ストリーム内のすべてのL値の平均を考えます。サンプルが空の場合は加えて、タイプP-ワンウェイパケット損失-平均は未定義です。
Example: suppose we take a sample and the results are:
例：私たちはサンプルを取り、結果はと仮定します。
Stream1 = < <T1, 0> <T2, 0> <T3, 1> <T4, 0> <T5, 0> >
STREAM1 = << T1 0> <T2 0> <Tsの1> <Tchの、0> <T5 0 >>
Then the average would be 0.2.
次いで、平均は0.2であろう。
Note that, since healthy Internet paths should be operating at loss rates below 1% (particularly if high delay-bandwidth products are to be sustained), the sample sizes needed might be larger than one would like. Thus, for example, if one wants to discriminate between various fractions of 1% over one-minute periods, then several hundred samples per minute might be needed. This would result in larger values of lambda than one would ordinarily want.
健全なインターネットパスは1％以下の損失レートで動作しなければならないので、（高遅延帯域幅積が維持されるようにしている場合は特に）、なお、必要なサンプルサイズは、1つの希望よりも大きくなる可能性があります。一つは1分にわたって1％の種々の画分を区別したい場合したがって、例えば、次に分あたり数百のサンプルが必要とされるかもしれません。これは、1つは通常望むよりも、ラムダの大きな値になるでしょう。
Note that although the loss threshold should be set such that any errors in loss are not significant, if the possibility that a packet which arrived is counted as lost due to resource exhaustion is significant compared to the loss rate of interest, Type-P-One-way-Packet-Loss-Average will be meaningless.
なお、損失閾値が到着したパケットが失われたリソースに起因する消耗としてカウントされる可能性が大きい場合損失のエラーが、タイプP-一つ関心の損失率に比べ、有意ではないように設定されるべきです-way-パケット損失-平均は無意味になります。
Conducting Internet measurements raises both security and privacy concerns. This memo does not specify an implementation of the metrics, so it does not directly affect the security of the Internet nor of applications which run on the Internet. However, implementations of these metrics must be mindful of security and privacy concerns.
インターネット測定を行うことは、両方のセキュリティとプライバシーの問題を提起します。このメモは、メトリックの実装を指定していないので、直接インターネットのも、インターネット上で動作するアプリケーションのセキュリティに影響を与えません。しかし、これらのメトリックの実装では、セキュリティとプライバシーの問題に留意する必要があります。
There are two types of security concerns: potential harm caused by the measurements, and potential harm to the measurements. The measurements could cause harm because they are active, and inject packets into the network. The measurement parameters MUST be carefully selected so that the measurements inject trivial amounts of additional traffic into the networks they measure. If they inject "too much" traffic, they can skew the results of the measurement, and in extreme cases cause congestion and denial of service.
測定の測定によって引き起こされる潜在的な害、および潜在的な危害：セキュリティ上の問題の2つのタイプがあります。測定は、彼らがアクティブであるため、害を引き起こし、ネットワークにパケットを注入できます。測定は、彼らが測定ネットワークに追加トラフィックの些細な量を注入するように測定パラメータを慎重に選択しなければなりません。彼らは「あまりにも多くの」トラフィックを注入した場合、彼らは測定の結果を歪曲し、極端な場合にはサービスの混雑や拒否を引き起こす可能性があります。
The measurements themselves could be harmed by routers giving measurement traffic a different priority than "normal" traffic, or by an attacker injecting artificial measurement traffic. If routers can recognize measurement traffic and treat it separately, the measurements will not reflect actual user traffic. If an attacker injects artificial traffic that is accepted as legitimate, the loss rate will be artificially lowered. Therefore, the measurement methodologies SHOULD include appropriate techniques to reduce the probability measurement traffic can be distinguished from "normal" traffic. Authentication techniques, such as digital signatures, may be used where appropriate to guard against injected traffic attacks.
測定自体は、測定トラフィックに「正常な」トラフィックとは異なる優先順位を与えルータによる、または人工的な測定トラフィックを注入する攻撃者によって悪影響を受ける可能性があります。ルータは、測定トラフィックを認識し、個別に扱うことができた場合は、測定値は、実際のユーザトラフィックが反映されません。攻撃者は正当なものとして受け入れている人工的なトラフィックを注入した場合、損失率を人為的に低下させることになります。したがって、測定方法は、「正常な」トラフィックと区別することができる確率の測定トラフィックを削減するための適切な技術を含むべきです。そのようなデジタル署名などの認証技術は、注入されたトラフィックの攻撃を防ぐために適切な場合に使用することができます。
The privacy concerns of network measurement are limited by the active measurements described in this memo. Unlike passive measurements, there can be no release of existing user data.
ネットワーク測定のプライバシーの問題は、このメモに記載の活性測定によって制限されています。受動的な測定とは異なり、既存のユーザーデータのない解放はありえません。
Thanks are due to Matt Mathis for encouraging this work and for calling attention on so many occasions to the significance of packet loss.
おかげで、この作業を促進するため、パケットロスの重要性に非常に多くの機会に注意を喚起するためのマット・マティスによるものです。
Thanks are due also to Vern Paxson for his valuable comments on early drafts, and to Garry Couch and Will Leland for several useful suggestions.
おかげで早期ドラフトで彼の貴重なコメントのために、そしてギャリーソファーとウィルリーランドにいくつかの有用な提案をもバーン・パクソンによるものです。
[1] Paxson, V., Almes,G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[1]パクソン、V.、Almes、G。、Mahdavi、J.とM.マティス、RFC 2330、1998年5月 "IPパフォーマンス・メトリックのためのフレームワーク"。
[2] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[2] Almes、G.、Kalidindi、S.及びM. Zekauskas、 "IPPMための一方向遅延メトリック"、RFC 2679、1999年9月。
[3] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999.
[3] Mahdavi、J.およびV.パクソン、 "接続を測定するためのIPPMメトリック"、RFC 2678、1999年9月を。
[4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[4]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[6] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[6]ブラドナー、S.、 "インターネット標準化過程 - リビジョン3"、BCP 9、RFC 2026、1996年10月。
Guy Almes Advanced Network & Services, Inc. 200 Business Park Drive Armonk, NY 10504 USA
ガイAlmes高度なネットワーク＆サービス社200ビジネスパークドライブアーモンク、NY 10504 USA
Phone: +1 914 765 1120 EMail: almes@advanced.org
電話：+1 914 765 1120 Eメール：almes@advanced.org
Sunil Kalidindi Advanced Network & Services, Inc. 200 Business Park Drive Armonk, NY 10504 USA
スニルKalidindi高度なネットワーク＆サービス社200ビジネスパークドライブアーモンク、NY 10504 USA
Phone: +1 914 765 1128 EMail: kalidindi@advanced.org
電話：+1 914 765 1128 Eメール：kalidindi@advanced.org
Matthew J. Zekauskas Advanced Network & Services, Inc. 200 Business Park Drive Armonk, NY 10504 USA
マシューJ. Zekauskas高度なネットワーク＆サービス社200ビジネスパークドライブアーモンク、NY 10504 USA
Phone: +1 914 765 1112 EMail: matt@advanced.org
電話：+1 914 765 1112 Eメール：matt@advanced.org
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。