[要約] RFC 2681は、IPPMのための往復遅延メトリックに関する要約です。その目的は、ネットワークのパフォーマンスを評価するための往復遅延の測定方法を提供することです。
Network Working Group G. Almes
Request for Comments: 2681 S. Kalidindi
Category: Standards Track M. Zekauskas
Advanced Network & Services
September 1999
A Round-trip Delay 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 round-trip delay of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330 [1], and follows closely the corresponding metric for One-way Delay ("A One-way Delay Metric for IPPM") [2]; the reader is assumed to be familiar with those documents.
このメモはインターネットパス間でパケットの往復遅延のメトリックを定義します。これは、[1] RFC 2330、IPPMフレームワーク文書で導入され、論じ概念上に構築され、一方向遅延（「一方向IPPMの遅延メトリック」）のために密接に対応するメトリックを次の[2]。読者は、これらの文書に精通していると想定されます。
The memo was largely written by copying material from the One-way Delay metric. The intention is that, where the two metrics are similar, they will be described with similar or identical text, and that where the two metrics differ, new or modified text will be used.
メモは、主に一方向遅延メトリックから材料をコピーすることによって書かれました。意図は、2つのメトリックが類似している場合、それらは類似または同一のテキストで説明される、こと、および2つの指標が異なる場合、新しいまたは変更されたテキストが使用されることです。
This memo is intended to be parallel in structure to a future companion document for Packet Loss.
このメモは、パケット損失のために未来の仲間ドキュメントの構造で、平行であることを意図しています。
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 [6]. 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に記載されるように解釈される[6]。 RFC 2119を念頭にプロトコルで書かれていたが、キーワードは、同様の理由でこの文書で使用されています。彼らは、二つの異なる実装からの測定の結果を確実にするために同等で使用され、実装がネットワークを乱すことができるときのインスタンスに注意します。
The structure of the memo is as follows:
次のようにメモの構造は次のとおりです。
+ A 'singleton' analytic metric, called Type-P-Round-trip-Delay, will be introduced to measure a single observation of round-trip delay.
+ A「シングルトン」解析メトリックと呼ばれるタイプP-ラウンドトリップ遅延、往復遅延の単一の観察を測定するために導入されます。
+ Using this singleton metric, a 'sample', called Type-P-Round-trip-Delay-Poisson-Stream, will be introduced to measure a sequence of singleton delays measured at times taken from a Poisson process.
タイプP-ラウンドトリップ遅延ポアソンストリームと呼ばれるメトリックこのシングルトン、「サンプル」を、使用して+、ポアソン過程から取られた時点で測定しシングルトン遅延のシーケンスを測定するために導入されます。
+ Using this sample, several 'statistics' of the sample will be 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フレームワークの文書から専門用語が最初にこのメモで使用されるたびに、末尾にアスタリスクでタグ付けされます。たとえば、「用語の*は」「という用語は、」フレームワークで定義されていることを示しています。
Round-trip delay of a Type-P* packet 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 delay between hosts is large relative to some threshold value.
+ホスト間のエンドツーエンド遅延がある閾値に対して大きい場合、一部のアプリケーションでは、ウェル（またはまったく）行いません。
+ Erratic variation in delay makes it difficult (or impossible) to support many interactive real-time applications.
+遅延の不安定な変動は、それが困難（または不可能）多くのインタラクティブなリアルタイムアプリケーションをサポートすることができます。
+ The larger the value of delay, the more difficult it is for transport-layer protocols to sustain high bandwidths.
トランスポート層プロトコルは高い帯域幅を維持するために+遅延の値が大きいほど、より困難です。
+ The minimum value of this metric provides an indication of the delay due only to propagation and transmission delay.
+このメトリックの最小値は、伝播および伝送遅延に起因する遅延の指示を提供します。
+ The minimum value of this metric provides an indication of the delay that will likely be experienced when the path* traversed is lightly loaded.
+このメトリックの最小値が*横断パスの負荷が軽いときにおそらく経験される遅延の指示を提供します。
+ Values of this metric above the minimum provide an indication of the congestion present in the path.
最小上記このメトリックの+値がパスに存在する輻輳の指標を提供します。
The measurement of round-trip delay instead of one-way delay has several weaknesses, summarized here:
代わりに、一方向遅延の往復遅延時間の測定は、ここでまとめ、いくつかの弱点があります。
+ The Internet path from a source to a destination may differ from 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.
+ソースから宛先へのインターネットパスは、ルータの異なる配列が順方向および逆方向経路のために使用されるように、バックソース（「非対称パス」）への宛先からの経路と異なっていてもよいです。したがって、往復の測定は、実際には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.
+アプリケーションのパフォーマンスは、1つの方向の性能にほとんど依存してもよいです。
+ 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.
+のサービス品質（QoS）対応ネットワークでは、一方向のプロビジョニングは、逆方向にプロビジョニングより根本的に異なっていてもよく、従ってQoS保証が異なります。
On the other hand, the measurement of round-trip delay has two specific advantages:
一方、往復遅延の測定は、2つの特定の利点を有します。
+ Ease of deployment: unlike in one-way measurement, it is often possible to perform some form of round-trip delay measurement without installing measurement-specific software at the intended destination. A variety of approaches are well-known, including use of ICMP Echo or of TCP-based methodologies (similar to those outlined in "IPPM Metrics for Measuring Connectivity" [4]). However, some approaches may introduce greater uncertainty in the time for the destination to produce a response (see Section 2.7.3).
+導入のしやすさ：一方向の測定では、それが意図した宛先に計測専用のソフトウェアをインストールせずに往復遅延測定のいくつかのフォームを実行することが可能であることが多いとは異なり。種々のアプローチが、ICMPエコーまたはTCPベースの方法の使用を含む、よく知られている（「接続性を測定するためのIPPMメトリック」で概説したものと同様の[4]）。しかし、いくつかのアプローチが応答を生成するために、目的地のための時間でより大きな不確実性を導入することができる（2.7.3を参照）。
+ Ease of interpretation: in some circumstances, the round-trip time is in fact the quantity of interest. Deducing the round-trip time from matching one-way measurements and an assumption of the destination processing time is less direct and potentially less accurate.
解釈のしやすさを+：いくつかの状況では、ラウンドトリップ時間は、実際に関心の量です。一方向の測定及び先処理時間の仮定と一致するから往復時間を推定することはあまり直接的及び潜在的にあまり正確です。
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: synchronization*
フレームワークドキュメントで詳しく説明するように、クロックの不確実性の4つの異なる、しかし関連概念があります。同期*
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.
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.
resolution*
解決*
measures the precision of a given clock. For example, the clock
on an old Unix host might tick only once every 10 msec, and thus
have a resolution of only 10 msec.
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.
Type-P-Round-trip-Delay
タイプ-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-Round-trip-Delay is either a real number, or an undefined (informally, infinite) number of seconds.
タイプP-ラウンドトリップ遅延の値は実数、または秒の未定義の（非公式に、無限の）番号のいずれかです。
For a real number dT, >>the *Type-P-Round-trip-Delay* from Src to Dst at T is dT<< means that Src sent the first bit of a Type-P packet to Dst at wire-time* T, that Dst received that packet, then immediately sent a Type-P packet back to Src, and that Src received the last bit of that packet at wire-time T+dT.
実数dTを、>> *タイプ-P-ラウンドトリップ遅延をTでのSrcからDstのに*がdTは<< SRCは*ワイヤ時のDstにタイプPパケットの最初のビットを送ったことを意味していますTは、DSTがそのパケットを受信したことを、直ちにバックSRCにタイプPのパケットを送信し、およびSrcは、ワイヤ時間T + dTのでそのパケットの最後のビットを受信したこと。
>>The *Type-P-Round-trip-Delay* from Src to Dst at T is undefined (informally, infinite)<< means that Src sent the first bit of a Type-P packet to Dst at wire-time T and that (either Dst did not receive the packet, Dst did not send a Type-P packet in response, or) Src did not receive that response packet.
>> * TでのSrcからDSTのタイプP-ラウンドトリップ遅延*は（非公式無限の）定義されていない<< SRCはワイヤ時間TでDSTのタイプPのパケットの最初のビットを送信することを意味しその（Dstのパケットを受信しなかった、DSTが応答タイプPパケットを送信しませんでした、またはいずれか）SRCはその応答パケットを受信しませんでした。
>>The *Type-P-Round-trip-Delay between Src and Dst at T<< means either the *Type-P-Round-trip-Delay from Src to Dst at T or the *Type-P-Round-trip-Delay from Dst to Src at T. When this notion is used, it is understood to be specifically ambiguous which host acts as Src and which as Dst. {Comment: This ambiguity will usually be a small price to pay for being able to have one measurement, launched from either Src or Dst, rather than having two measurements.}
TでSrcとDstの間>> *タイプ-P-ラウンドトリップ遅延<< Tまたは*タイプ-P-往復でのSrcからDstのへ*タイプ-P-ラウンドトリップ遅延のいずれかを意味しますこの概念を使用する場合T.でのDstからSRCに-delayは、DstのようなSrcおよびそのような具体的にあいまいなホスト作用であると理解されます。 {コメント：この曖昧さは、通常、むしろ二つの測定を有するよりも、のSrcまたはDstのいずれかから開始し、一回の測定を有することができることを支払うために小さな価格であろう。}
Suggestions for what to report along with metric values appear in Section 3.8 after a discussion of the metric, methodologies for measuring the metric, and error analysis.
メトリック値とともに報告する何のための提案は、メトリック、およびエラー分析を測定するための測定基準、方法論の議論の後、セクション3.8で表示されます。
Type-P-Round-trip-Delay is a relatively simple analytic metric, and one that we believe will afford effective methods of measurement.
タイプ-P-ラウンドトリップ遅延は、比較的単純な分析指標であり、我々は測定の効果的な方法を与えるであろうと考えている1。
The following issues are likely to come up in practice:
次の問題は、実際に出てくる可能性があります。
+ The timestamp values (T) for the time at which delays are measured should be fairly accurate in order to draw meaningful conclusions about the state of the network at a given T. Therefore, Src should have an accurate knowledge of time-of-day. NTP [3] affords one way to achieve time accuracy to within several milliseconds. Depending on the NTP server, higher accuracy may be achieved, for example when NTP servers make use of GPS systems as a time source. Note that NTP will adjust the instrument's clock. If an adjustment is made between the time the initial timestamp is taken and the time the final timestamp is taken the adjustment will affect the uncertainty in the measured delay. This uncertainty must be accounted for in the instrument's calibration.
+遅延が測定された時刻のタイムスタンプ値（T）は、したがって、所与のT.におけるネットワークの状態に関する意味のある結論を引き出すためには、かなり正確でなければならない、Srcは、時刻の正確な知識を有していなければなりません。 NTPは、[3]、数ミリ秒以内に時間精度を実現する1つの方法を提供します。 NTPサーバがタイムソースとしてGPSシステムを利用する際に、NTPサーバによっては、より高精度には、例えば、達成することができます。 NTPは、機器の時計を調整することに注意してください。調整は最初のタイムスタンプが取得され、時間と時間の間でなされた場合、最終的なタイムスタンプが取得され、調整は、測定された遅延の不確実性に影響を与えます。この不確実性は、測定器の校正に計上しなければなりません。
+ A given methodology will have to include a way to determine whether a delay value is infinite or whether it is merely very large (and the packet is yet to arrive at Dst). As noted by Mahdavi and Paxson [4], simple upper bounds (such as the 255 seconds theoretical upper bound on the lifetimes of IP packets [5]) 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, the harm in treating a large delay as infinite might be zero or very small. A TCP data packet, for example, that arrives only after several multiples of the RTT may as well have been lost.}
与えられた方法論を+は遅延値が無限大であるか、またはそれは単に非常に大きいかどうか（およびパケット夏時間に到達するためにまだある）かどうかを決定する方法を含むことがあります。 Mahdaviとパクソンで述べたように、[4]、簡単な上限（IPパケットの寿命上に結合した理論上、このような255秒としては、[5]）を使用することができますが、良いエンジニアリング、パケット寿命の理解を含め、必要とされるであろう実際には。 {コメント：これらのメトリックの多くの用途のために、無限のような大きな遅延を治療するのに害がゼロ又は非常に小さいかもしれないことに留意されたいです。 RTTの数倍の後にのみ到着例えばTCPデータパケットは、同様に失われた可能性があります。}
+ If the packet is duplicated so that multiple non-corrupt instances of the response arrive back at the source, then the packet is counted as received, and the first instance to arrive back at the source determines the packet's round-trip delay.
+応答の複数の非破損インスタンスはバックソースに到着するようにパケットが重複している場合、受信したパケットがカウントされ、バックソースに到着する最初のインスタンスは、パケットの往復遅延を決定します。
+ 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, the methodology would proceed as follows:
次のように一般的に、与えられたタイプ-Pのために、方法論は進行します。
+ At the Src host, select Src and Dst IP addresses, and form a test packet of Type-P with these addresses. Any 'padding' portion of the packet needed only to make the test packet a given size should be filled with randomized bits to avoid a situation in which the measured delay is lower than it would otherwise be due to compression techniques along the path. The test packet must have some identifying information so that the response to it can be identified by Src when Src receives the response; one means to do this is by placing the timestamp generated just before sending the test packet in the packet itself.
+のSrcホストでは、SrcとDstのIPアドレスを選択して、これらのアドレスをタイプPのテストパケットを形成します。のみテストパケット所定の大きさにするために必要なパケットの任意の「パディング」部分は、測定された遅延は、それ以外のパスに沿って圧縮技術によるものであろうよりも低い状況を回避するためにランダム化ビットで満たされるべきです。 SRCは、応答を受信した場合、それに対する応答がSrcによって同定することができるように、テストパケットは、いくつかの識別情報を有していなければなりません。一つは、これを行うには意味だけでパケット自体にテストパケットを送信する前に生成されたタイムスタンプを置くことです。
+ At the Dst host, arrange to receive and respond to the test packet. At the Src host, arrange to receive the corresponding response packet.
+ Dstのホストでは、受信したテストパケットに対応するためにアレンジ。 Srcのホストでは、対応する応答パケットを受信するためにアレンジ。
+ At the Src host, take the initial timestamp and then send the prepared Type-P packet towards Dst. Note that the timestamp could be placed inside the packet, or kept separately as long as the packet contains a suitable identifier so the received timestamp can be compared with the send timestamp.
+のSrcホストでは、最初のタイムスタンプを取り、その後のDstに向けて準備されたタイプPパケットを送信します。タイムスタンプは、パケットの内部に配置され、又は限り受け取ったタイムスタンプが送信タイムスタンプと比較することができるように、パケットは適切な識別子を含むように別々に維持することができることに留意されたいです。
+ If the packet arrives at Dst, send a corresponding response packet back from Dst to Src as soon as possible.
パケットがDstのに到着した場合は+、できるだけ早くバックのDstからSRCに対応する応答パケットを送信します。
+ If the response packet arrives within a reasonable period of time, take the final timestamp as soon as possible upon the receipt of the packet. By subtracting the two timestamps, an estimate of round-trip delay can be computed. If the delay between the initial timestamp and the actual sending of the packet is known, then the estimate could be adjusted by subtracting this amount; uncertainty in this value must be taken into account in error analysis. Similarly, if the delay between the actual receipt of the response packet and final timestamp is known, then the estimate could be adjusted by subtracting this amount; uncertainty in this value must be taken into account in error analysis. See the next section, "Errors and Uncertainties", for a more detailed discussion.
応答パケットは、合理的な期間内に到着した場合+、パケットの受信時に、できるだけ早く最終タイムスタンプを取ります。 2つのタイムスタンプを減算することにより、ラウンドトリップ遅延の推定値を計算することができます。初期タイムスタンプと、パケットの送信実際の間の遅延が既知である場合、推定値は、この量を差し引くことによって調整することができます。この値の不確実性は、エラー解析で考慮されなければなりません。応答パケット及び最終的なタイムスタンプの実際の受信との間の遅延が既知であれば、同様に、その推定値は、この量を差し引くことによって調整することができます。この値の不確実性は、エラー解析で考慮されなければなりません。より詳細な議論については、次のセクション、「エラーおよび不確実性」を参照してください。
+ If the packet fails to arrive within a reasonable period of time, the round-trip delay is taken to be undefined (informally, infinite). Note that the threshold of 'reasonable' is a parameter of the methodology.
+パケットが合理的な期間内に到着しなかった場合、往復遅延は（非公式に、無限の）未定義であると解釈されます。 「合理的な」のしきい値は、方法論のパラメータであることに注意してください。
Issues such as the packet format and the means by which Dst knows when to expect the test packet are outside the scope of this document.
このようなパケットフォーマットとして問題とdstがテストパケットを期待する際に知っれる手段は、この文書の範囲外です。
{Comment: Note that you cannot in general add two Type-P-One-way-Delay values (see [2]) to form a Type-P-Round-trip-Delay value. In order to form a Type-P-Round-trip-Delay value, the return packet must be triggered by the reception of a packet from Src.}
{コメント：あなたは一般的に2種類-P-一方向遅延値を追加することはできません（[2]参照）タイプPラウンドトリップ遅延値を形成します。タイプPラウンドトリップ遅延値を形成するために、返信パケットは、Srcからのパケットの受信によってトリガされなければなりません。}
{Comment: "ping" would qualify as a round-trip measure under this definition, with a Type-P of ICMP echo request/reply with 60-byte packets. However, the uncertainties associated with a typical ping program must be analyzed as in the next section, including the type of reflecting point (a router may not handle an ICMP request in the fast path) and effects of load on the reflecting point.}
{コメント：「pingが」60バイトのパケットで応答/ ICMPエコー要求のタイプPと、この定義の下で往復尺度として適格であろう。しかし、一般的なpingプログラムに関連した不確実性ポイントを反射するタイプ（ルータは、高速パスでICMP要求を処理できない場合があります）と反射点の負荷の影響を含む次のセクションのように分析しなければなりません。}
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, but we note here the following specifics related to delay metrics:
任意の具体的な測定方法の説明は、会計及びエラーまたは不確定性のさまざまなソースの分析を含むべきです。枠組み文書は、この時点で一般的なガイダンスを提供していますが、我々はここでメトリックを遅らせるために関連する以下の仕様に注意してください。
+ Errors or uncertainties due to uncertainty in the clock of the Src host.
+エラーまたはSrcのホストのクロックの不確実性に起因する不確実性。
+ Errors or uncertainties due to the difference between 'wire time' and 'host time'.
+エラーまたは「線時間」と「ホスト時間」との間の差に起因する不確実性。
+ Errors or uncertainties due to time required by the Dst to receive the packet from the Src and send the corresponding response.
+エラーまたはSrcのからのパケットを受信し、対応する応答を送信するようにDstのに要する時間に起因する不確実性。
In addition, the loss threshold may affect the results. Each of these are discussed in more detail below, along with a section ("Calibration") on accounting for these errors and uncertainties.
また、損失しきい値は、結果に影響を与える可能性があります。これらの各々は、これらのエラーおよび不確実性の会計上のセクション（「較正」）とともに、以下でより詳細に議論されます。
The uncertainty in a measurement of round-trip delay is related, in part, to uncertainty in the clock of the Src host. In the following, we refer to the clock used to measure when the packet was sent from Src as the source clock, and we refer to the observed time when the packet was sent by the source as Tinitial, and the observed time when the packet was received by the source as Tfinal. Alluding to the notions of synchronization, accuracy, resolution, and skew mentioned in the Introduction, we note the following:
往復遅延時間の測定における不確実性は、部分的には、Srcのホストのクロックの不確実性には、関連しています。以下では、パケットがソースクロックとしてのSrcから送信されたときに測定するために使用される、我々はパケットがTinitialとしてソースによって送信された観測時刻を参照し、パケットがあった観測時間クロックを参照しますTfinalなどのソースによって受信されました。同期、精度、分解能、冒頭で述べたスキューの概念をほのめかして、我々は次の点に注意してください。
+ While in one-way delay there is an issue of the synchronization of the source clock and the destination clock, in round-trip delay there is an (easier) issue of self-synchronization, as it were, between the source clock at the time the test packet is sent and the (same) source clock at the time the response packet is received. Theoretically a very severe case of skew could threaten this. In practice, the greater threat is anything that would cause a discontinuity in the source clock during the time between the taking of the initial and final timestamp. This might happen, for example, with certain implementations of NTP.
+一方向遅延のソースクロックとデスティネーション・クロックの同期の問題があるが、それはのソースクロックとの間にあったとして、ラウンドトリップ遅延に自己同期（容易）問題があります時間は、試験パケットは、応答パケットを受信した時点で送信され、（同じ）ソースクロックされます。理論的にはスキューの非常に深刻な場合は、これを脅かします。実際には、より大きな脅威は最初と最後のタイムスタンプの撮影の間の時間の間、ソースクロックの不連続を引き起こすものです。これは、NTPの特定の実装で、例えば、起こるかもしれません。
+ The accuracy of a clock is important only in identifying the time at which a given delay was measured. Accuracy, per se, has no importance to the accuracy of the measurement of delay.
クロックの精度は+のみ与えられた遅延が測定された時刻を特定する上で重要です。精度は、それ自体は、遅延の測定の精度に何ら重要性を有していません。
+ The resolution of a clock adds to uncertainty about any time measured with it. Thus, if the source clock has a resolution of 10 msec, then this adds 10 msec of uncertainty to any time value measured with it. We will denote the resolution of the source clock as Rsource.
+クロックの分解能はそれで測定された任意の時間についての不確実性に追加されます。ソースクロックは、10ミリ秒の分解能を有する場合したがって、これは、それを用いて測定し、任意の時間値に不確実性の10ミリ秒を加算します。私たちは、Rsourceで、ソースクロックの分解能を示すだろう。
Taking these items together, we note that naive computation Tfinal-Tinitial will be off by 2*Rsource.
一緒にこれらのアイテムを取ると、我々はナイーブ計算Tfinal-Tinitialは2 * Rsourceででオフになることに注意してください。
As we have defined round-trip delay, we would like to measure the time between when the test packet leaves the network interface of Src and when the corresponding response packet (completely) arrives at the network interface of Src, and we refer to these as "wire times". If the timings are themselves performed by software on Src, however, then this software can only directly measure the time between when Src grabs a timestamp just prior to sending the test packet and when it grabs a timestamp just after having received the response packet, and we refer to these two points as "host times".
我々は往復遅延を定義しているように、我々は、テストパケットがSrcのネットワークインタフェースを離れるときに、対応する応答パケットが（完全に）のSrcのネットワークインターフェースに到着し、我々は、これらを参照するときの間の時間を測定したいです「ワイヤー回」。タイミングは自身がSrcの上のソフトウェアによって実行されている場合は、しかし、このソフトウェアは、唯一の直接のSrcがテストパケットを送信する直前にタイムスタンプをつかむとき、それはちょうど、応答パケットを受信した後のタイムスタンプをつかむときの間の時間を測定することができ、かつ私たちは「ホスト回」ように、これらの2つのポイントを参照してください。
Another contributor to this problem is time spent at Dst between the receipt there of the test packet and the sending of the response packet. Ideally, this time is zero; it is explored further in the next section.
この問題のもう一つの要因は、テストパケットの受信が応答パケットの送信間のDstで過ごした時間です。理想的には、この時間はゼロです。それは次のセクションでさらに探求されます。
To the extent that the difference between wire time and host time is accurately known, this knowledge can be used to correct for host time measurements and the corrected value more accurately estimates the desired (wire time) metric.
ワイヤ時間とホスト時間との差が正確に知られている程度に、この知識は、ホスト時間測定値を補正するために使用することができ、補正値をより正確に所望の（ワイヤ時間）メトリックを推定します。
To the extent, however, that the difference between wire time and host time is uncertain, this uncertainty must be accounted for in an analysis of a given measurement method. We denote by Hinitial an upper bound on the uncertainty in the difference between wire time and host time on the Src host in sending the test packet, and similarly define Hfinal for the difference on the Src host in receiving the response packet. We then note that these problems introduce a total uncertainty of Hinitial + Hfinal. This estimate of total wire-vs-host uncertainty should be included in the error/uncertainty analysis of any measurement implementation.
程度に、しかし、ワイヤ時間とホスト時間差が不確定であることを、この不確実性は、所定の測定方法の分析において考慮されなければなりません。我々はHinitialによってテストパケットを送信におけるSrcホストのワイヤ時間とホスト時間との差の不確かさの上限を示し、同様に、応答パケットを受信におけるSrcホスト上の差をHfinalを定義します。私たちは、その後、これらの問題がHinitial + Hfinalの総不確実性を導入することに注意してください。総ワイヤ対宿主不確実性のこの推定値は、任意の測定実装の誤差/不確実性分析に含まれるべきです。
Any time spent by the destination host in receiving and recognizing the packet from Src, and then producing and sending the corresponding response adds additional error and uncertainty to the round-trip delay measurement. The error equals the difference between the wire time the first bit of the packet is received by Dst and the wire time the first bit of the response is sent by Dst. To the extent that this difference is accurately known, this knowledge can be used to correct the desired metric. To the extent, however, that this difference is uncertain, this uncertainty must be accounted for in the error analysis of a measurement implementation. We denote this uncertainty by Hrefl. This estimate of uncertainty should be included in the error/uncertainty analysis of any measurement implementation.
受信およびSrcからのパケットを認識して、生産とそれに対応する応答を送信する際、宛先ホストで過ごした任意の時間は、往復遅延測定に追加のエラーや不確実性を追加します。エラーは、パケットの最初のビットは、応答の最初のビットはDstのによって送信さDstのワイヤ時間によって受信されたワイヤ時間との差に等しいです。この差が正確に知られている程度に、この知識は、所望のメトリックを修正するために使用することができます。程度に、しかし、この差は不確実であることを、この不確実性は、測定実施の誤差解析で考慮しなければなりません。私たちは、Hreflすることにより、この不確実性を表します。不確実性のこの推定値は、任意の測定実装の誤り/不確実性分析に含まれるべきです。
Generally, the measured values can be decomposed as follows:
次のように一般的には、測定値を分解することができます。
measured value = true value + systematic error + random error
測定値=真値+系統誤差+ランダムエラー
If the systematic error (the constant bias in measured values) can be determined, it can be compensated for in the reported results.
系統誤差（測定値の一定のバイアス）を決定することができる場合には、報告された結果に補償することができます。
reported value = measured value - systematic error
報告された値=測定値 - 系統誤差
therefore
故に
reported value = true value + random error
報告された値=真値+ランダム誤差
The goal of calibration is to determine the systematic and random error generated by the instruments themselves in as much detail as possible. At a minimum, a bound ("e") should be found such that the reported value is in the range (true value - e) to (true value + e) at least 95 percent of the time. We call "e" the calibration error for the measurements. It represents the degree to which the values produced by the measurement instrument are repeatable; that is, how closely an actual delay of 30 ms is reported as 30 ms. {Comment: 95 percent was chosen because (1) some confidence level is desirable to be able to remove outliers, which will be found in measuring any physical property; and (2) a particular confidence level should be specified so that the results of independent implementations can be compared.}
キャリブレーションの目標は、できるだけ詳細に楽器自身によって生成された体系的かつランダム誤差を決定することです。 （真値+ E）時間の少なくとも95パーセントに - （E真値）が最小で、結合した（「E」）が報告された値が範囲内にあるように見出されるべきです。私たちは、測定のためのキャリブレーションエラー「E」と呼びます。これは、測定器によって生成される値が再現されている度合いを表します。すなわち、30ミリ秒の実際の遅延は、30ミリ秒として報告される方法密接にあります。 {コメント：（1）いくつかの信頼レベルは、任意の物理的特性を測定する際に見出される異常値を除去することができることが望ましいため、95パーセントを選択しました。独立した実装の結果を比較することができるようにし、（2）特定の信頼レベルを指定しなければなりません。}
From the discussion in the previous three sections, the error in measurements could be bounded by determining all the individual uncertainties, and adding them together to form
前述の3つのセクションの説明から、測定値の誤差は、すべての個々の不確実性を決定し、一緒にそれらを添加することによって境界され得ます
2*Rsource + Hinitial + Hfinal + Hrefl.
2 *リソース+ +初期決勝+ Hrefの。
However, reasonable bounds on both the clock-related uncertainty captured by the first term and the host-related uncertainty captured by the last three terms should be possible by careful design techniques and calibrating the instruments using a known, isolated, network in a lab.
しかし、第一項と最後の3つの用語で撮影したホストに関連する不確実性によって捕獲両方のクロックに関連した不確実性の妥当な範囲は、慎重な設計技術や研究室で知られ、孤立し、ネットワークを使用して機器を較正することによって可能でなければなりません。
The host-related uncertainties, Hinitial + Hfinal + Hrefl, could be bounded by connecting two instruments back-to-back with a high-speed serial link or isolated LAN segment. In this case, repeated measurements are measuring the same round-trip delay.
ホスト関連の不確実性、Hinitial + Hfinal + Hreflは、バックツーバック高速シリアルリンクまたは単離されたLANセグメントを有する2台の機器を接続することによって境界付けすることができます。この場合、反復測定は、同一のラウンドトリップ遅延を測定しています。
If the test packets are small, such a network connection has a minimal delay that may be approximated by zero. The measured delay therefore contains only systematic and random error in the instrumentation. The "average value" of repeated measurements is the systematic error, and the variation is the random error.
テストパケットが小さい場合には、そのようなネットワーク接続はゼロで近似することができる最小の遅延を有します。測定された遅延は、したがって、計測機器にのみ体系的かつランダム誤差が含まれています。反復測定の「平均値」は、系統的誤差であり、ばらつきがランダム誤差です。
One way to compute the systematic error, and the random error to a 95% confidence is to repeat the experiment many times - at least hundreds of tests. The systematic error would then be the median. The random error could then be found by removing the systematic error from the measured values. The 95% confidence interval would be the range from the 2.5th percentile to the 97.5th percentile of these deviations from the true value. The calibration error "e" could then be taken to be the largest absolute value of these two numbers, plus the clock-related uncertainty. {Comment: as described, this bound is relatively loose since the uncertainties are added, and the absolute value of the largest deviation is used. As long as the resulting value is not a significant fraction of the measured values, it is a reasonable bound. If the resulting value is a significant fraction of the measured values, then more exact methods will be needed to compute the calibration error.}
テストの少なくとも数百 - 95％信頼に系統誤差、ランダム誤差を計算する一つの方法は、実験を何度も繰り返すことです。系統誤差は、中央値になります。ランダム誤差は、測定値から系統誤差を除去することにより、見つけることができます。 95％信頼区間は、第2.5パーセンタイルから真値からの偏差これらの97.5thパーセンタイルの範囲だろう。校正誤差「e」は、これら2つの数の最大絶対値が、プラスクロックに関連した不確実性であると解釈することができます。 {コメント：説明したように、この境界は不確実性が付加されているので、比較的ルーズであり、最大の偏差の絶対値が使用されます。限り、得られた値は、測定値の重要な部分ではないとして、それは合理的結合されます。得られた値は、測定値の重要な部分である場合、より正確な方法は、較正誤差を計算するために必要とされるであろう。}
Note that random error is a function of measurement load. For example, if many paths will be measured by one instrument, this might increase interrupts, process scheduling, and disk I/O (for example, recording the measurements), all of which may increase the random error in measured singletons. Therefore, in addition to minimal load measurements to find the systematic error, calibration measurements should be performed with the same measurement load that the instruments will see in the field.
ランダム誤差は、測定負荷の関数であることに注意してください。例えば、多くのパス一つ器によって測定される場合、これは、（測定値を記録する、例えば）割り込み、プロセススケジューリング、およびディスクI / Oを増加させる可能性があるすべてが測定シングルトンにランダム誤差を増大させることができます。したがって、系統的エラーを見つけるために最小の負荷測定に加えて、較正測定は、機器がフィールドに表示されるのと同じ測定負荷で行われるべきです。
We wish to reiterate that this statistical treatment refers to the calibration of the instrument; it is used to "calibrate the meter stick" and say how well the meter stick reflects reality.
私たちは、この統計的な治療は、機器のキャリブレーションを参照していることをあらためて表明したいです。 「メータースティックのキャリブレーション」とメータースティックが現実を反映してどれだけ言って使用されています。
In addition to calibrating the instruments for finite delay, two checks should be made to ensure that packets reported as losses were really lost. First, the threshold for loss should be verified. In particular, ensure the "reasonable" threshold is reasonable: that it is very unlikely a packet will arrive after the threshold value, and therefore the number of packets lost over an interval is not sensitive to the error bound on measurements. Second, consider the possibility that a packet arrives at the network interface, but is lost due to congestion on that interface or to other resource exhaustion (e.g. buffers) in the instrument.
有限の遅延のための機器の校正に加えて、2つのチェックを損失として計上パケットが実際に失われたことを確認するためになされるべきです。まず、損失のしきい値を確認する必要があります。パケットが閾値の後に到着する非常に低いので、間隔にわたって失われたパケットの数は、測定値に結合したエラーに対して敏感ではないこと。特に、「合理的な」閾値が妥当であることを確認。第二に、パケットがネットワークインタフェースに到着するが、そのインターフェイス上または機器内の他のリソースの枯渇（例えば、バッファ）に輻輳のために失われている可能性を考慮してください。
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: the Type-P of test packets, the threshold of infinite delay (if any), error 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-Round-trip-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を正確に報告しなければなりません。
In addition, the threshold (or methodology to distinguish) between a large finite delay and loss MUST be reported.
加えて、大きな有限の遅延と損失の間の（区別するまたは方法）の閾値は、報告されなければなりません。
+ If the systematic error can be determined, it SHOULD be removed from the measured values.
+系統誤差を決定することができる場合には、測定値から除去されるべきです。
+ You SHOULD also report the calibration error, e, such that the true value is the reported value plus or minus e, with 95% confidence (see the last section.)
+また、真の値が95％の信頼度で、報告された値のプラスまたはマイナス電子であるように、電子、キャリブレーションエラーを報告する必要があります（最後のセクションを参照してください。）
+ If possible, the conditions under which a test packet with finite delay is reported as lost due to resource exhaustion on the measurement instrument SHOULD be reported.
可能であれば+、測定器の枯渇資源に失われたとして、有限の遅延とテストパケットが報告される条件が報告されるべきです。
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. For example, 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, and the Dst host copies the path from Src to Dst into the corresponding reply packet, 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ヘッダ内のオプションを含み、経路が十分に短く、パスサポートレコード（またはルーズソース）上のすべてのルータ*場合ルート、及び対応する応答パケットにdstがホスト・コピーsrcからdstへのパスは、パスが正確に記録されます。これは非現実的であるルートが十分に短くなければならないので、多くのルータがサポートしていない（またはのために設定されていない）レコードルート、およびこの機能の使用は、多くの場合、人為的に共通の場合の処理からパケットを除去することにより、観察した性能を悪化させるだろう。しかし、部分的な情報はまだ貴重な文脈です。ホストは、2つの間のリンク*（およびSrcからDSTの、したがって二つの別々の経路）を選択することができる場合、例えば、使用される最初のリンクは、貴重なコンテキストです。 {コメント：例えば、メリットのNetNowセットアップを一のNAP上のSrcは、いくつかの異なるバックボーンネットワークのいずれかによって別のNAP上のDstに達することができます。}
Given the singleton metric Type-P-Round-trip-Delay, 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-Round-trip-Delay-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、時間、および
+ dT, either a real number or an undefined number of seconds.
+ dTを、実数または秒の未定義番号のいずれか。
The values of T in the sequence are monotonic increasing. Note that T would be a valid parameter to Type-P-Round-trip-Delay, and that dT would be a valid value of Type-P-Round-trip-Delay.
配列におけるTの値が増加する単調です。 Tは-P-ラウンドトリップ遅延を入力するための有効なパラメータであることに注意してください、そしてdTはタイプ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-Round-trip-Delay at this time. The value of the sample is the sequence made up of the resulting <time, delay> 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. {Comment: there is, of course, no claim that real Internet traffic arrives according to a Poisson arrival process.} The Poisson process is used to schedule the delay measurements. The test packets will generally not arrive at Dst according to a Poisson distribution, nor will response packets arrive at Src according to a Poisson distribution, since they are influenced by the network.
サンプルは、自己同期化の影響を回避し、また、統計学的に可能な限り公平である試料を捕捉するために、両方のポアソン過程に関して定義されます。 {コメント：実際のインターネットトラフィックは、ポアソン到着過程に従って到着するという主張は、もちろん、存在しない}ポアソン過程は、遅延測定をスケジュールするために使用されます。テストパケットは、一般的にポアソン分布に従ってDstのに到着しないであろう、また、それらがネットワークによって影響されるので、応答パケットは、ポアソン分布に従うのSrcに到着します。
All the singleton Type-P-Round-trip-Delay 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-Round-trip-Delay-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-Round-trip-Delay metric.
+方法論の議論はすでにシングルトンタイプ-P-往復遅延メトリックのために与えられました。
Care must, of course, be given to correctly handle out-of-order arrival of test or response packets; it is possible that the Src could send one test packet at TS[i], then send a second test packet (later) at TS[i+1], and it could receive the second response packet at TR[i+1], and then receive the first response packet (later) at TR[i].
ケアはもちろん、正しくテストまたは応答パケットのアウトオブオーダー到着を処理するために与えられなければなりません。 SRCはTS [I + 1]で（後）次に、TS [I]に一つのテストパケットを送信する第二のテストパケットを送信することができることが可能であり、それはTR [I + 1]で第2の応答パケットを受信することができ、そしてその後、TR [I]において、第1の応答パケット（後）を受信します。
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 process with respect to 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, or with jitter in the value of Hinitial (mentioned above as uncertainty in the singleton delay metric). The Framework document shows how to use the Anderson-Darling test to verify the accuracy of a Poisson process over small time frames. {Comment: The goal is to ensure that test packets are sent "close enough" to a Poisson schedule, and avoid periodic behavior.}
試料を構成するシングルトン値を測定するために使用される方法に関連したエラーおよび不確実性の源に加えて、ケアは、試験パケットの送信の倍線に対するポアソン過程の精度を分析するために与えられなければなりません。この方法の問題は、ポアソン到着プロセスを生成するために使用される擬似乱数技術の問題を含め、いくつかによって引き起こされる、またはHinitialの値のジッタと（シングルトン遅延メトリックにおける不確実性として、上述）ことができます。フレームワークドキュメントは、小さな時間枠にわたってポアソン過程の精度を検証するためにアンダーソン・ダーリン検定を使用する方法を示します。 {コメント：目標は、テストパケットはポアソンスケジュールに「十分に近い」、および周期的挙動を避ける送信されることを保証することです。}
You MUST report the calibration and context for the underlying singletons along with the stream. (See "Reporting the metric" for Type-P-Round-trip-Delay.)
あなたはストリームと共に基礎となるシングルトンのためのキャリブレーションとコンテキストを報告しなければなりません。 （タイプP-ラウンドトリップ遅延のための「メトリックの報告」を参照してください。）
Given the sample metric Type-P-Round-trip-Delay-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-Round-trip-Delay-Poisson-Stream and a percent X between 0% and 100%, the Xth percentile of all the dT values in the Stream. In computing this percentile, undefined values are treated as infinitely large. Note that this means that the percentile could thus be undefined (informally, infinite). In addition, the Type-P-Round-trip-Delay-Percentile is undefined if the sample is empty.
タイプP-ラウンドトリップ遅延ポアソン・ストリームと0％と100％の間の％X、ストリーム内のすべてのdTの値のX番目のパーセンタイルを考えます。このパーセンタイルを計算する際に、未定義の値は無限大として扱われます。これはパーセンタイルは、このように（非公式に、無限の）未定義することができることを意味することに注意してください。また、タイプP-ラウンドトリップ遅延パーセンタイルは、サンプルが空の場合は未定義です。
Example: suppose we take a sample and the results are:
例：私たちはサンプルを取り、結果はと仮定します。
Stream1 = < <T1, 100 msec> <T2, 110 msec> <T3, undefined> <T4, 90 msec> <T5, 500 msec> >
STREAM1 = <<T1、100ミリ秒> <T2、110ミリ秒> <T3、未定義> <T4、90ミリ秒> <T5、500ミリ秒>>
Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller and 110 msec and 'undefined' are larger.
90ミリ秒と100ミリ秒が小さく、110ミリ秒と「不定」は大きいので、その後50パーセンタイルは、110ミリ秒であろう。
Note that if the possibility that a packet with finite delay is reported as lost is significant, then a high percentile (90th or 95th) might be reported as infinite instead of finite.
失われたとして、有限の遅延とパケットが報告されている可能性が大きい場合には、高いパーセンタイル（第90または第95）は無限の代わりに、有限として報告される場合がありますので注意してください。
Given a Type-P-Round-trip-Delay-Poisson-Stream, the median of all the dT values in the Stream. In computing the median, undefined values are treated as infinitely large. As with Type-P-Round-trip-Delay-Percentile, Type-P-Round-trip-Delay-Median is undefined if the sample is empty.
タイプP-ラウンドトリップ遅延ポアソン・ストリーム、ストリーム内のすべてのdTの値の中央値を考えます。中央値を計算する際に、未定義の値は無限大として扱われます。サンプルが空の場合、タイプP-ラウンドトリップ遅延パーセンタイルと同じように、タイプP-ラウンドトリップ遅延中央値は未定義です。
As noted in the Framework document, the median differs from the 50th percentile only when the sample contains an even number of values, in which case the mean of the two central values is used.
フレームワーク文書で述べたように、サンプルが2つの中央値の平均が使用される場合、値の偶数を、含まれている場合にのみ、中央値は50パーセンタイルとは異なります。
Example: suppose we take a sample and the results are:
例：私たちはサンプルを取り、結果はと仮定します。
Stream2 = < <T1, 100 msec> <T2, 110 msec> <T3, undefined> <T4, 90 msec> >
STREAM2 = <<T1、100ミリ秒> <T2、110ミリ秒> <T3、未定義> <T4、90ミリ秒>>
Then the median would be 105 msec, the mean of 100 msec and 110 msec, the two central values.
次いで、中央値は105ミリ秒、100ミリ秒と110ミリ秒、2つの中央値の平均であろう。
Given a Type-P-Round-trip-Delay-Poisson-Stream, the minimum of all the dT values in the Stream. In computing this, undefined values are treated as infinitely large. Note that this means that the minimum could thus be undefined (informally, infinite) if all the dT values are undefined. In addition, the Type-P-Round-trip-Delay-Minimum is undefined if the sample is empty.
タイプP-ラウンドトリップ遅延ポアソン・ストリーム、ストリーム内のすべてのdTの値の最小値を考えます。この計算では、未定義の値は無限大として扱われます。これは最小のは、このように全てのdT値が未定義である場合（非公式に、無限大）未定義することができることを意味することに留意されたいです。また、タイプP-ラウンドトリップ遅延の最小サンプルが空の場合は未定義です。
In the above example, the minimum would be 90 msec.
上記の例では、最小値は90ミリ秒であろう。
Given a Type-P-Round-trip-Delay-Poisson-Stream and a time duration threshold, the fraction of all the dT values in the Stream less than or equal to the threshold. The result could be as low as 0% (if all the dT values exceed threshold) or as high as 100%. Type-P-Round-trip-Delay-Inverse-Percentile is undefined if the sample is empty.
タイプP-往復遅延ポアソン・ストリームおよび継続時間閾値、閾値以下でストリーム内のすべてのdT値のフラクションを与え。結果は、（すべてのdT値が閾値を超えた場合）は、0％と低いことまたは100％という高い可能性があります。タイプ-P-ラウンドトリップ遅延逆パーセンタイルはサンプルが空の場合は未定義です。
In the above example, the Inverse-Percentile of 103 msec would be 50%.
上記の例では、103ミリ秒の逆パーセンタイルは50％であろう。
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.
ネットワーク測定のプライバシーの問題は、このメモに記載の活性測定によって制限されています。受動的な測定とは異なり、既存のユーザーデータのない解放はありえません。
Special thanks are due to Vern Paxson and to Will Leland for several useful suggestions.
特別な感謝は、いくつかの有用な提案をバーン・パクソンへとウィルリーランドに起因するものです。
[1] Paxson, D., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[1]パクソン、D.、Almes、G.、Mahdavi、J.とM.マティス、 "IPパフォーマンス・メトリックのためのフレームワークを"、RFC 2330、1998年5月。
[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] Mills, D., "Network Time Protocol (v3)", RFC 1305, April 1992.
[3]ミルズ、D.、 "ネットワークタイムプロトコル（V3）"、RFC 1305、1992年4月。
[4] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999.
[4] Mahdavi、J.およびV.パクソン、 "接続を測定するためのIPPMメトリック"、RFC 2678、1999年9月を。
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[5]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
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機能のための基金は現在、インターネット協会によって提供されます。