[要約] RFC 2679は、IPPMのための片方向遅延メトリックに関する規格であり、ネットワークの遅延を測定するための方法を提供しています。このRFCの目的は、ネットワークのパフォーマンスを評価し、問題を特定するための一貫した方法を提供することです。
Network Working Group G. Almes
Request for Comments: 2679 S. Kalidindi
Category: Standards Track M. Zekauskas
Advanced Network & Services
September 1999
A One-way Delay Metric for IPPM
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 delay of packets 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 Packet Loss ("A One-way Packet Loss Metric for IPPM") [2].
このメモは、パケット損失の仲間ドキュメントに構造に平行であることが意図されている（「一方向パケット損失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 [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-One-way-Delay, will be introduced to measure a single observation of one-way delay.
タイプP-一方向ディレイと呼ばれる+ A「シングルトン」分析メトリックは、一方向遅延の単一の観察を測定するために導入されます。
+ Using this singleton metric, a 'sample', called Type-P-One-way-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フレームワークの文書から専門用語が最初にこのメモで使用されるたびに、末尾にアスタリスクでタグ付けされます。たとえば、「用語の*は」「という用語は、」フレームワークで定義されていることを示しています。
One-way 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 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 one-way delay instead of round-trip delay 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 delay 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: 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. {Comment: A rough ITU-T
equivalent is "time error".}
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*
解決*
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. {Comment: A very
rough ITU-T equivalent is "sampling period".}
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-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-One-way-Delay is either a real number, or an undefined (informally, infinite) number of seconds.
タイプP-ワンウェイ遅延の値は実数、または秒の未定義の（非公式に、無限の）番号のいずれかです。
For a real number dT, >>the *Type-P-One-way-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 and that Dst received the last bit of that packet at wire-time T+dT.
実数dTを、>>用* TでのSrcからDSTのタイプP-ワンウェイ遅延*はdTの<<であるSRCはワイヤ時DSTのタイプPのパケットの最初のビットを送信したことを意味します* TそのDSTはワイヤ時間T + dTのでそのパケットの最後のビットを受信しました。
>>The *Type-P-One-way-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 Dst did not receive that packet.
>> *タイプP-ワンウェイ遅延TでのSrcからDSTの*が未定義<< SRCはワイヤ時間TでDSTのタイプPのパケットの最初のビットを送信したことを意味する（非公式に、無限大）をと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-One-way-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:
次の問題は、実際に出てくる可能性があります。
+ Real delay values will be positive. Therefore, it does not make sense to report a negative value as a real delay. However, an individual zero or negative delay value might be useful as part of a stream when trying to discover a distribution of a stream of delay values.
+実遅延値が正となります。したがって、それは本当の遅延と負の値を報告しても意味がありません。遅延値の流れの分布を発見しようとするが、個々のゼロまたは負の遅延値は、ストリームの一部として有用であるかもしれません。
+ Since delay values will often be as low as the 100 usec to 10 msec range, it will be important for Src and Dst to synchronize very closely. GPS systems afford one way to achieve synchronization to within several 10s of usec. Ordinary application of NTP may allow synchronization to within several msec, but this depends on the stability and symmetry of delay properties among those NTP agents used, and this delay is what we are trying to measure. A combination of some GPS-based NTP servers and a conservatively designed and deployed set of other NTP servers should yield good results, but this is yet to be tested.
遅延値は、多くの場合、10ミリ秒の範囲に100マイクロ秒ほど低くなるので+、非常に密接に同期させるためにSrcとDstのために重要であろう。 GPSシステムは、マイクロ秒の数十の中に同期を達成する1つの方法を与えます。 NTPの通常のアプリケーションは、数ミリ秒以内の同期を可能にすることができるが、これは使用されている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とパクソン（IPパケットの寿命の理論的な上限など255秒など[5]）[4]、シンプルな上限を使用することができますが、良い技術は、実際に必要とされるであろう。 {コメント：これらのメトリックの多くの用途のために、無限のような大きな遅延を治療するのに害がゼロ又は非常に小さいかもしれないことに留意されたいです。 RTTの数倍の後にのみ到着例えばTCPデータパケットは、同様に失われた可能性があります。}
+ 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, and the first copy to arrive determines the packet's one-way 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のために、方法論は進行します。
+ Arrange that Src and Dst are synchronized; that is, that they have clocks that are very closely synchronized with each other and each fairly close to the actual time.
+ SrcとDstのが同期していることを整理。それは、彼らは非常に密接に相互に同期して実際の時間にそれぞれかなり近いされている時計を持っていること、です。
+ 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.
+の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, take a timestamp as soon as possible upon the receipt of the packet. By subtracting the two timestamps, an estimate of one-way delay can be computed. Error analysis of a given implementation of the method must take into account the closeness of synchronization between Src and Dst. If the delay between Src's 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 packet and Dst's 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つのタイムスタンプを減算することにより、一方向遅延の推定値を計算することができます。この方法の特定の実装のエラー分析を考慮にSrcとDstの間の同期の近さを取る必要があります。 Srcのタイムスタンプと、パケットの送信実際の間の遅延が既知である場合、推定値は、この量を差し引くことによって調整することができます。この値の不確実性は、エラー解析で考慮されなければなりません。実際のパケットの受信とdstのタイムスタンプとの間の遅延が既知であれば、同様に、その推定値は、この量を差し引くことによって調整することができます。この値の不確実性は、エラー解析で考慮されなければなりません。より詳細な議論については、次のセクション、「エラーおよび不確実性」を参照してください。
+ If the packet fails to arrive within a reasonable period of time, the one-way 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, 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, but we note here the following specifics related to delay metrics:
任意の具体的な測定方法の説明は、会計及びエラーまたは不確定性のさまざまなソースの分析を含むべきです。枠組み文書は、この時点で一般的なガイダンスを提供していますが、我々はここでメトリックを遅らせるために関連する以下の仕様に注意してください。
+ Errors or uncertainties due to uncertainties in the clocks of the Src and Dst hosts.
+エラー又はSrcとDstのホストのクロックの不確実性に起因する不確実性。
+ Errors or uncertainties due to the difference between 'wire time' and 'host time'.
+エラーまたは「線時間」と「ホスト時間」との間の差に起因する不確実性。
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 one-way delay is related, in part, to uncertainties in the clocks of the Src and Dst hosts. In the following, we refer to the clock used to measure when the packet was sent from Src as the source clock, we refer to the clock used to measure when the packet was received by Dst as the destination clock, we refer to the observed time when the packet was sent by the source clock as Tsource, and the observed time when the packet was received by the destination clock as Tdest. Alluding to the notions of synchronization, accuracy, resolution, and skew mentioned in the Introduction, we note the following:
一方向遅延の測定における不確実性は、部分的に、SrcとDstのホストのクロックの不確実性に、関連しています。以下では、クロックを参照し、パケットがソースクロックとしてのSrcから送信されたときに測定するために使用される、我々は、クロックを参照して、パケットが宛先クロックとしてのDstによって受信されたときに測定するために使用される、我々は、観測時間を参照パケットがTSOURCEとしてソースクロック、及びパケットがTdestとして先クロックによって受信された観測時間によって送信されたとき。同期、精度、分解能、冒頭で述べたスキューの概念をほのめかして、我々は次の点に注意してください。
+ Any error in the synchronization between the source clock and the destination clock will contribute to error in the delay measurement. We say that the source clock and the destination clock have a synchronization error of Tsynch if the source clock is Tsynch ahead of the destination clock. Thus, if we know the value of Tsynch exactly, we could correct for clock synchronization by adding Tsynch to the uncorrected value of Tdest-Tsource.
+ソースクロックとデスティネーション・クロック間の同期の誤差は、遅延測定の誤差に寄与する。私たちは、ソースクロックはTsynch先デスティネーションクロックのであれば、ソースクロックとデスティネーションクロックがTsynchの同期誤差を持っていることを言います。我々は正確にTsynchの価値を知っていればこのように、我々はTdest-TSOURCEの未補正値にTsynchを追加することにより、クロック同期を修正することができます。
+ 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. When computing delays, we are interested only in the differences between clock values, not the values themselves.
クロックの精度は+のみ与えられた遅延が測定された時刻を特定する上で重要です。精度は、それ自体は、遅延の測定の精度に何ら重要性を有していません。遅延を計算するとき、我々は唯一のクロック値ではなく、値そのものとの違いに興味を持っています。
+ 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 and the destination clock as Rsource and Rdest, respectively.
+クロックの分解能はそれで測定された任意の時間についての不確実性に追加されます。ソースクロックは、10ミリ秒の分解能を有する場合したがって、これは、それを用いて測定し、任意の時間値に不確実性の10ミリ秒を加算します。我々は、それぞれ、RsourceでとをRdestように、ソースクロックの分解能と宛先クロックを示します。
+ The skew of a clock is not so much an additional issue as it is a realization of the fact that Tsynch is itself a function of time. Thus, if we attempt to measure or to bound Tsynch, this needs to be done periodically. Over some periods of time, this function can be approximated as a linear function plus some higher order terms; in these cases, one option is to use knowledge of the linear component to correct the clock. Using this correction, the residual Tsynch is made smaller, but remains a source of uncertainty that must be accounted for. We use the function Esynch(t) to denote an upper bound on the uncertainty in synchronization. Thus, |Tsynch(t)| <= Esynch(t).
それはTsynch自体が時間の関数であることを事実の実現であるとして+クロックのスキューはあまり追加の問題ではありません。我々は測定または結合Tsynchにしようとするとこのように、これは定期的に行う必要があります。時間のいくつかの期間にわたって、この関数は、線形関数に加え、いくつかの高次の項のように近似することができます。これらのケースでは、一つの選択肢は、クロックを修正するために、線形成分の知識を使用することです。この補正を使用して、残留Tsynchは小さく、しかし、考慮しなければならない不確実性の源のままです。私たちは、同期の不確実性の上限を示すために機能Esynch（t）を使用します。したがって、| Tsynch（トン）| <= Esynch（T）。
Taking these items together, we note that naive computation Tdest-Tsource will be off by Tsynch(t) +/- (Rsource + Rdest). Using the notion of Esynch(t), we note that these clock-related problems introduce a total uncertainty of Esynch(t)+ Rsource + Rdest. This estimate of total clock-related uncertainty should be included in the error/uncertainty analysis of any measurement implementation.
一緒にこれらのアイテムを取ると、我々はナイーブ計算Tdest-TSOURCEはTsynch（T）+/-（Rsourceで+をRdest）でオフになることに注意してください。 Esynch（t）の概念を使用して、我々はこれらのクロックに関連した問題がEsynch（T）+ Rsourceで+をRdestの総不確実性を導入することに注意してください。総クロックに関連する不確実性のこの推定値は、任意の測定実装の誤差/不確実性分析に含まれるべきです。
As we have defined one-way delay, we would like to measure the time between when the test packet leaves the network interface of Src and when it (completely) arrives at the network interface of Dst, and we refer to these as "wire times." If the timings are themselves performed by software on Src and Dst, 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 Dst grabs a timestamp just after having received the test packet, and we refer to these two points as "host times".
我々は一方向の遅延を定義したように、我々はテストパケットは、Srcののネットワークインターフェイスを離れるとき、それは（完全）のDstのネットワークインタフェースに到着し、我々はワイヤー回」としてこれらを参照するときの間の時間を測定したいと思います。」タイミングは自身がSrcとDstの上のソフトウェアによって実行されている場合は、しかし、このソフトウェアは、唯一の直接のSrcがテストパケットを送信する直前にタイムスタンプをつかむときとdstがちょうどテストパケットを受信した後のタイムスタンプをつかむときの間の時間を測定することができます、と私たちは「ホスト回」ように、これらの2つのポイントを参照してください。
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 Hsource an upper bound on the uncertainty in the difference between wire time and host time on the Src host, and similarly define Hdest for the Dst host. We then note that these problems introduce a total uncertainty of Hsource+Hdest. This estimate of total wire-vs-host uncertainty should be included in the error/uncertainty analysis of any measurement implementation.
程度に、しかし、ワイヤ時間とホスト時間差が不確定であることを、この不確実性は、所定の測定方法の分析において考慮されなければなりません。我々はHsourceでSrcホストのワイヤ時間とホスト時間との差の不確かさの上限を示し、同様のDstホストのHdestを定義します。私たちは、その後、これらの問題がHsource + Hdestの総不確実性を導入することに注意してください。総ワイヤ対宿主不確実性のこの推定値は、任意の測定実装の誤差/不確実性分析に含まれるべきです。
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; (2) a particular confidence level should be specified so that the results of independent implementations can be compared; and (3) even with a prototype user-level implementation, 95% was loose enough to exclude outliers.}
キャリブレーションの目標は、できるだけ詳細に楽器自身によって生成された体系的かつランダム誤差を決定することです。 （真値+ E）時間の少なくとも95パーセントに - （E真値）が最小で、結合した（「E」）が報告された値が範囲内にあるように見出されるべきです。私たちは、測定のためのキャリブレーションエラー「E」と呼びます。これは、測定器によって生成される値が再現されている度合いを表します。すなわち、30ミリ秒の実際の遅延は、30ミリ秒として報告される方法密接にあります。 {コメント：（1）いくつかの信頼レベルは、任意の物理的特性を測定する際に見出される異常値を除去することができることが望ましいため、95パーセントを選択しました。独立した実装の結果を比較することができるように、（2）特定の信頼レベルを指定しなければなりません。及び（3）であってもプロトタイプユーザーレベルの実装で、95％が外れ値を除外するのに十分緩いました。}
From the discussion in the previous two sections, the error in measurements could be bounded by determining all the individual uncertainties, and adding them together to form
前の二つのセクションの説明から、測定値の誤差は、すべての個々の不確実性を決定し、一緒にそれらを添加することによって境界され得ます
Esynch(t) + Rsource + Rdest + Hsource + Hdest.
Esynch（T）+ Rsourceで+をRdest + Hsource + Hdest。
However, reasonable bounds on both the clock-related uncertainty captured by the first three terms and the host-related uncertainty captured by the last two terms should be possible by careful design techniques and calibrating the instruments using a known, isolated, network in a lab.
しかし、最初の3つの項と最後の二つの用語によって捕捉ホスト関連の不確実性によって捕捉両方のクロック関連の不確実性に合理的な範囲は、慎重な設計技術によって可能とすべきである実験室で知られている、単離された、ネットワークを使用して機器を較正します。
For example, the clock-related uncertainties are greatly reduced through the use of a GPS time source. The sum of Esynch(t) + Rsource + Rdest is small, and is also bounded for the duration of the measurement because of the global time source.
例えば、クロック関連の不確実性が大幅にGPS時刻源を使用することによって低減されます。 Esynch（T）+ Rsourceで+をRdestの和が小さく、またためにグローバルタイムソースの計測の期間制限されます。
The host-related uncertainties, Hsource + Hdest, 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 one-way delay.
ホスト関連の不確実性、Hsource + Hdestは、バックツーバック高速シリアルリンクまたは単離された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 one-way 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-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を正確に報告しなければなりません。
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. 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-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
シングルトンメトリックタイプ-P-ワンウェイ遅延を考えると、我々は今、このようなシングルトンの一つの特定のサンプルを定義します。サンプルのアイデアはパラメータのSrc、Dstの、およびType-Pの特定の結合を選択することで、その後、Tの値を定義するためのパラメータTの値手段のサンプルを定義することは、開始時刻T0を選択することです最終的な時間Tf、および平均速度ラムダ、その後、擬似ランダムを定義します
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.
値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-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-One-way-Delay, and that dT would be a valid value of Type-P-One-way-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-One-way-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, since they are influenced by the network.
サンプルは、自己同期化の影響を回避し、また、統計学的に可能な限り公平である試料を捕捉するために、両方のポアソン過程に関して定義されます。 {コメント：実際のインターネットトラフィックは、ポアソン到着過程に従って到着するという主張は、もちろん、存在しない}ポアソン過程は、遅延測定をスケジュールするために使用されます。それらはネットワークによって影響されるので、テストパケットは、一般に、ポアソン分布に従ってDstのに到着しないであろう。
All the singleton Type-P-One-way-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-One-way-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-One-way-Delay metric.
+方法論の議論はすでにシングルトンタイプ-P-一方向遅延メトリックのために与えられました。
Care must, of course, 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 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 Hsource (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.}
試料を構成するシングルトン値を測定するために使用される方法に関連したエラーおよび不確実性の源に加えて、ケアは、試験パケットの送信の倍線に対するポアソン過程の精度を分析するために与えられなければなりません。この方法の問題は、ポアソン到着プロセスを生成するために使用される擬似乱数技術の問題を含め、いくつかによって引き起こされる、またはHsourceの値のジッタと（シングルトン遅延メトリックにおける不確実性として、上述）ことができます。フレームワークドキュメントは、小さな時間枠にわたってポアソン過程の精度を検証するためにアンダーソン・ダーリン検定を使用する方法を示します。 {コメント：目標は、テストパケットはポアソンスケジュールに「十分に近い」、および周期的挙動を避ける送信されることを保証することです。}
You MUST report the calibration and context for the underlying singletons along with the stream. (See "Reporting the metric" for Type-P-One-way-Delay.)
あなたはストリームと共に基礎となるシングルトンのためのキャリブレーションとコンテキストを報告しなければなりません。 （タイプP-ワンウェイ遅延の「メトリックの報告」を参照してください。）
Given the sample metric Type-P-One-way-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-One-way-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-One-way-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-One-way-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-One-way-Delay-Percentile, Type-P-One-way-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-One-way-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-One-way-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-One-way-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-One-way-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 of Lawrence Berkeley Labs for his helpful comments on issues of clock uncertainty and statistics. Thanks also to Garry Couch, Will Leland, Andy Scherrer, Sean Shapira, and Roland Wittig for several useful suggestions.
特別な感謝は、クロックの不確実性と統計の問題に関する彼の役に立つコメントをローレンスバークレー研究所のバーン・パクソンによるものです。いくつかの有用な提案のためにもギャリーソファー、ウィルリーランド、アンディ・シェラー、ショーンShapira、およびローランドウィッティヒに感謝します。
[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.マティス、 "IPパフォーマンス・メトリックのためのフレームワークを"、RFC 2330、1998年5月。
[2] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[2] Almes、G.、Kalidindi、S.及びM. Zekauskas、 "一方向パケット損失IPPMためのメトリック"、RFC 2680、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における使用のためのレベルを示すために"。
[7] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[7]ブラドナーの、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機能のための基金は現在、インターネット協会によって提供されます。