RFC2679 日本語訳
2679 A One-way Delay Metric for IPPM. G. Almes, S. Kalidindi, M.Zekauskas. September 1999. (Format: TXT=43542 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Almes
Request for Comments: 2679 S. Kalidindi
Category: Standards Track M. Zekauskas
Advanced Network & Services
September 1999
Almesがコメントのために要求するワーキンググループG.をネットワークでつないでください: 2679秒間Kalidindiカテゴリ: 規格は1999年9月にM.Zekauskas高度なネットワークとサービスを追跡します。
A One-way Delay Metric for IPPM
IPPMにおける、メートル法のA One-道の遅れ
1. Status of this Memo
1. この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
2. Introduction
2. 序論
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.
このメモはパケットの片道遅れにおける、インターネット経路の向こう側のメートル法のaを定義します。 それはIPPM Frameworkドキュメント、RFC2330[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].
このメモが構造でPacket Loss(「IPPMにおける、メートル法のA One-道のパケット損失」)[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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[6]で説明されるように本書では解釈されることであるべきですか? RFC2119は念頭にプロトコルで書かれましたが、キーワードは本書では同様の理由に使用されます。 実現がネットワークを混乱させることができたとき、それらは2つの異なった実現からの測定値の結果が匹敵しているのを保証して、例に注意するのにおいて使用されています。
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.
+A'単独個体'分析的である、メートル法であり、Type-Pの片道遅れと呼ばれて、片道遅れのただ一つの観測を測定するために導入するでしょう。
Almes, et al. Standards Track [Page 1] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[1ページ]RFC2679A One-道の遅れ
+ 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.
+がポアソンが流すこの単独個体のメートル法の、そして、'サンプル'の、そして、呼ばれたType-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 Frameworkドキュメントからの専門用語が最初にこのメモで使用されるときはいつも、それは引きずっているアスタリスクでタグ付けをされるでしょう。 例えば、「用語*」は、「用語」がFrameworkで定義されるのを示します。
2.1. Motivation:
2.1. 動機:
One-way delay of a Type-P* packet from a source host* to a destination host is useful for several reasons:
送信元ホスト*からあて先ホストまでのType-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
今日のインターネットの+、ソースから目的地までの経路は経路と目的地からソース(「非対称の経路」)まで異なるかもしれません、ルータの異なった系列が前進の、そして、逆の経路に使用されるように。 したがって、往復の測定値は実際に2つの異なった経路の性能を一緒に測定します。 独自に各経路を測定すると、横断されるかもしれない2つの経路の性能差は目立ちます。
Almes, et al. Standards Track [Page 2] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[2ページ]RFC2679A One-道の遅れ
different Internet service providers, and even radically different
types of networks (for example, research versus commodity
networks, or ATM versus packet-over-SONET).
異なったインターネット接続サービス業者、さらにおよび根本的に異なったタイプさえのネットワーク、(例えば、商品ネットワーク、またはATMに対して研究してください、パケット過剰Sonet、)
+ 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.
+ アプリケーションのパフォーマンスは一方向でほとんど性能に依存するかもしれません。 例えば、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.
遅れ測定基準が正確にどう特定の問題に適用されるだろうかを言うために、このドキュメントの範囲の外にそれはあります。
2.2. General Issues Regarding Time
2.2. 時間に関する一般答弁
{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.}
{コメント: 以下の用語は、ITU-Tドキュメント(例えば、G.810と「同期ネットワークのための定義と用語」とI.356、「B-ISDN ATM層のセル転送性能」)によって定義されたそれと異なっていますが、IPPM Frameworkドキュメントと一致しています。 一般に、これらの違いが異なったバックグラウンドに由来しています。 ITU-Tドキュメントには、電話の起源が歴史的にあります、このドキュメント(そして、Framework)の作者では、コンピュータ・システムバックグラウンドがありますが。 以下で定義された用語は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:
Frameworkドキュメントで、より完全に説明されるように、時計の不確実性の4つの異なりましたが、関連する概念があります:
Almes, et al. Standards Track [Page 3] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[3ページ]RFC2679A One-道の遅れ
synchronization*
同期*
measures the extent to which two clocks agree on what time it
is. For example, the clock on one host might be 5.4 msec ahead
of the clock on a second host. {Comment: A rough ITU-T
equivalent is "time error".}
2個の時計が何時であるかに同意する範囲を測定します。 例えば、1人のホストの上の時計は5.4が2番目のホストの上の時計の前のmsecであるならそうするでしょうに。 コメント: 荒いITU-T同等物は「時間誤り」です。
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".}
与えられた時計がUTCに同意する範囲を測定します。 例えば、ホストの上の時計は27.1がUTCの後ろのmsecであるならそうするでしょうに。 コメント: 荒いITU-T同等物は「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".}
与えられた時計の精度を測定します。 例えば、年取ったUnixホストの上の時計は、かつてだけのあらゆる10msecのカチカチと音を立てて、その結果、10msecだけの解決を持っているかもしれません。 コメント: 非常に荒いITU-T同等物は「サンプリング周期」です。
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".}
時間がある精度、または同期の変化を測定します。 例えば、与えられたホストの上の時計は、1時間単位で1.3msecを獲得して、その結果、ひところ、UTCの後ろの27.1msecであるかもしれなく、唯一の25.8は1時間後のmsecです。 この場合、私たちは、UTCに比例して与えられたホストの時計には1.3の斜行が毎時のmsecにあると言います。UTCは精度を脅かします。 また、私たちは別の時計に比例して1個の時計の斜行について話すかもしれません。時計は同期を脅かします。 コメント: 荒いITU-T同等物は「時間ドリフト」です。
3. A Singleton Definition for One-way Delay
3. 片道遅れのためのシングルトンDefinition
3.1. Metric Name:
3.1. メートル法の名前:
Type-P-One-way-Delay
P片道遅れをタイプしてください。
3.2. Metric Parameters:
3.2. メートル法のパラメタ:
+ Src, the IP address of a host
+ Src、ホストのIPアドレス
+ Dst, the IP address of a host
+ Dst、ホストのIPアドレス
+ T, a time
+T、時間
Almes, et al. Standards Track [Page 4] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[4ページ]RFC2679A One-道の遅れ
3.3. Metric Units:
3.3. メートル制:
The value of a Type-P-One-way-Delay is either a real number, or an undefined (informally, infinite) number of seconds.
または、Type-Pの片道遅れの値が実数である、未定義である、(非公式である、無限) 秒数。
3.4. Definition:
3.4. 定義:
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の*タイプの>>P片道のSrcからDstまでの遅れ*はSrcがワイヤ時間*TでDstへのType-Pパケットの最初のビットを送ったdT<<手段です、そして、その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片道のSrcからTのDstまでの遅れ*は未定義です。(非公式に、無限) <<は、Srcがワイヤ時間TでType-Pパケットの最初のビットをDstに送って、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に現れます。
3.5. Discussion:
3.5. 議論:
Type-P-One-way-Delay is a relatively simple analytic metric, and one that we believe will afford effective methods of measurement.
タイプのP片道遅れがaである、比較的簡単である、分析的である、メートル法である、そして、私たちが測定の有効な手段を提供すると信じている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.
遅れ値以来の+がしばしば10msec範囲に低く100usecと同じくらいなる、SrcとDstが非常に密接に連動するのは、重要でしょう。 GPSシステムはusecのいくつかの10年代に同期を達成する1つの方法を提供します。 これはそれらのNTPエージェントの中の特性が使用した遅れの安定性と対称によります、そして、NTPの普通のアプリケーションは数個のmsecに同期を許容するかもしれませんが、この遅れは私たちが測定しようとしているものです。 いくつかの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
+ 与えられた方法論は遅れ値が無限であるかどうか、またはそれが単に非常に大きいかどうか(パケットはまだDstに到着していません)決定する方法を含まなければならないでしょう。 有名
Almes, et al. Standards Track [Page 5] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[5ページ]RFC2679A One-道の遅れ
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]、簡単な上限、(255がIPパケット[5])の生涯理論上の上限を後援するとき、そのようなものを使用できましたが、パケット生存期間の理解を含む良い工学が実際には必要でしょう。 {コメント: これらの測定基準、害の多くのアプリケーションによって無限がゼロであるかもしれないので大きい遅れを扱うか、非常に小さくそれに注意してください。 例えば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.
パケットであり、断片化されて、再アセンブリがいかなる理由でも現れないなら、+はそうであり、次に、パケットは無くなると考えられるでしょう。
3.6. Methodologies:
3.6. 方法論:
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).
他のType-P-*測定基準の場合、詳細な方法論はType-Pによるでしょう(例えば、プロトコル番号、UDP/TCPが数を移植します、サイズ、先行)。
Generally, for a given Type-P, the methodology would proceed as follows:
一般に、与えられたType-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アドレス、および用紙のこれらのアドレスがあるType-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ホストでは、準備されたType-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
+はパケットであるなら適正な期間以内に到着して、できるだけ早く、パケットの領収書にタイムスタンプを持っていってください。 2つのタイムスタンプを引き算することによって、片道遅れの見積りを計算できます。 方法の与えられた実現のエラー解析はSrcとDstの間の同期の密接を考慮に入れなければなりません。 そしてSrcのタイムスタンプの間の遅れである。
Almes, et al. Standards Track [Page 6] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[6ページ]RFC2679A One-道の遅れ
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.
パケットの実際の発信を知っています、次に、この量を引き算することによって、見積りを調整できるでしょう。 エラー解析でこの値における不確実性を考慮に入れなければなりません。 同様に、パケットと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.
+がパケットであるならa適正な期間中に到着しないで、未定義になるように片道遅れを取る、(非公式である、無限) '妥当'の敷居が方法論のパラメタであることに注意してください。
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が連動する手段などの問題があります。 : 私たちが、私たち自身のが働いているほかの場所にそのようなより詳細な実現のテクニックについて説明する際に記録するのを計画して、また、他のものを奨励するコメント。
3.7. Errors and Uncertainties:
3.7. 誤りと不明確なこと:
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:
どんな特定の測定方法の記述も誤りか不確実性の様々な源の会計学と分析を含むべきです。 Frameworkドキュメントはこのポイントの上で一般的な指導を提供しますが、私たちは、ここで以下の詳細が遅れ測定基準に関連したことに注意します:
+ 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.
さらに、損失敷居は結果に影響するかもしれません。 これらの誤りと不明確なことのための会計のときにセクション(「較正」)と共にさらに詳細に以下でそれぞれのこれらについて議論します。
3.7.1. Errors or uncertainties related to Clocks
3.7.1. Clocksに関連する誤りか不明確なこと
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
片道遅れの測定における不確実性はSrcとDstホストの時計の不明確なことに一部関係づけられます。 私たちは、以下では、私たちがパケットがいつソース時計としてSrcから送られたかを測定するのに使用される時計について言及して、パケットがソース時計によって送られた観測された時はTsourceとして私たちが、いつパケットが目的地時計としてDstによって受け取られたと言及するかを測定するのに使用される時計を参照して、Tdestとしてパケットが目的地時計によって受け取られた観測された時を参照します。 概念について暗示すること。
Almes, et al. Standards Track [Page 7] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[7ページ]RFC2679A One-道の遅れ
synchronization, accuracy, resolution, and skew mentioned in the Introduction, we note the following:
同期、精度、解決、および斜行がIntroductionで言及されて、私たちは以下に注意します:
+ 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.
+ 時計の解決はそれでいつでもに関して測定された不確実性に加えます。 したがって、ソース時計に10msecの解決があるなら、これはそれで測定されたどんな時間的価値にも不確実性の10msecを加えます。 私たちは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、したがって、私たちが、測定するか、またはバウンドするのを試みるなら、これは定期的にする必要があります。 いくつかの期間にわたって、一次関数といくつかの、より高いオーダー用語としてこの機能に近似できます。 これらの場合では、1つのオプションは時計を修正するのに直線的なコンポーネントに関する知識を使用することです。 この修正を使用して、残りのTsynchは、より小さく作られていますが、説明しなければならない不確実性の源のままで残っています。 私たちは、同期における不確実性で上限を指示するのに機能Esynch(t)を使用します。 このようにして|Tsynch(t)| <= 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.
これらの商品を一緒に取って、私たちは、Tsynch(t)+/-(Rsource+Rdest)でナイーブな計算Tdest- Tsourceがオフになることに注意します。 Esynch(t)の概念を使用して、私たちは、これらの時計関連の問題がEsynch(t)+Rsource+Rdestの総不確実性を導入することに注意します。 総時計関連の不確実性のこの見積りはどんな測定実現の誤り/不確実性分析にも含まれるべきです。
Almes, et al. Standards Track [Page 8] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[8ページ]RFC2679A One-道の遅れ
3.7.2. Errors or uncertainties related to Wire-time vs Host-time
3.7.2. Wire-時間対Host-時間まで関係づけられた誤りか不明確なこと
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に実行されるなら、このソフトウェアはちょうど、テストパケットを送る前、まさしくテストパケットを受けたとき後Dstがタイムスタンプをつかむときに時Srcがタイムスタンプをつかむ時の間で直接時間を測定できるだけです、そして、私たちは「ホスト回」とこれらの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.
しかしながら、範囲に、与えられた測定方法の分析でワイヤ時間とホスト時間の違いが不確実であり、これが不確実性であることを説明しなければなりません。 私たちは、Srcホストの上で不確実性でHsourceでワイヤ時間とホスト時間の違いで上限を指示して、Dstホストのために同様にHdestを定義します。 そして、私たちは、これらの問題がHsource+Hdestの総不確実性を導入することに注意します。 総ワイヤホストの不確実性のこの見積りはどんな測定実現の誤り/不確実性分析にも含まれるべきです。
3.7.3. Calibration
3.7.3. 較正
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
較正の目標は器具自体でできるだけ多くの詳細に発生する系統的で無作為の誤りを決定することです。 最小限では、バウンド(「e」)が見つけられるべきであるので、(真の値+e)には報告された値が範囲(真の値--e)に少なくとも95パーセントの割合であります。 私たちは、「e」を測定値のための校正誤差と呼びます。 度を表す、どれ、値
Almes, et al. Standards Track [Page 9] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[9ページ]RFC2679A One-道の遅れ
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.}
測定で生産されて、器具は反復可能です。 すなわち、30msの実際の遅れは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
前の2つのセクションでの議論から、測定値における誤りは、すべての個々の不明確なことを決定することによってバウンドしていて、形成するためにそれらを合計しているかもしれません。
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つの用語によって得られた時計関連の不確実性と最後の2学期によって得られたホスト関連の不確実性の両方の妥当な領域は、研究室で知られていて、孤立しているネットワークを使用することで慎重な設計技術で可能、そして、器具を較正するべきです。
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
95%の信用に系統誤差、および無作為の誤りを計算する1つの方法は何回も実験を繰り返すことです--少なくとも何百ものテスト。 そして系統誤差はメディアンでしょう。 そして、測定値から系統誤差を取り除くことによって、無作為の誤りを見つけることができるでしょう。 2.5番目の百分順位から真の値からのこれらの逸脱の97.5番目の百分順位まで95%の信頼区間は範囲でしょう。 そして、これらの2つの番号の最も大きい絶対値と、時計関連の不確実性になるように校正誤差「e」を取ることができました。 コメントしてください: 不明確なことが加えられるので、このバウンドは説明されるように比較的ゆるいです、そして、最も大きい逸脱の絶対値は使用されています。Asは結果になると切望します。
Almes, et al. Standards Track [Page 10] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[10ページ]RFC2679A One-道の遅れ
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.}
値が測定値の重要な部分でない、それは合理的なバウンドです。 結果として起こる値が測定値の重要な部分であるなら、より正確な方法が、校正誤差を計算するのに必要でしょう。
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.
無作為の誤りが測定負荷の機能であることに注意してください。 例えば、多くの経路が1個の器具によって測定されるなら、これは中断、過程スケジューリング、およびディスク入出力(例えば、測定値を記録する)を増加させるかもしれません。そのすべてが測定単独個体における無作為の誤りを増加させるかもしれません。 したがって、系統誤差を見つける最小量の負荷測定値に加えて、較正測定は器具がその分野で見るのと同じ測定負荷で実行されるべきです。
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つのチェックをするべきです。 まず最初に、損失のための敷居は確かめられるべきです。 特に、「妥当な」敷居が確実に妥当になるようにしてください: パケットが閾値の後に到着するのが、非常にありそうもなく、したがって、間隔の間に失われたパケットの数が誤りに敏感でないことは測定値で付きました。 2番目に、パケットがネットワーク・インターフェースに到着しますが、混雑のためそのインタフェースの上、または、器具での他のリソース疲労困憊(例えば、バッファ)に失われている可能性を考えてください。
3.8. Reporting the metric:
3.8. メートル法を報告します:
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.
慎重に、メートル法が測定される較正と文脈を考えなければならない、SHOULD、メートル法の結果と共にいつも報告されてください。 私たちは現在、考えるために4つの項目を提示します: テストパケットのType-P、無限の遅れ(もしあれば)の敷居、誤り較正、およびテストパケットによって横断された経路。 このリストは徹底的ではありません。 また、どんな測定基準の応用を解釈する際に役に立つかもしれない追加情報も報告されるべきです。
3.8.1. Type-P
3.8.1. 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.
Frameworkドキュメント[1]に述べられるように、メートル法の値は測定をするのに使用されるIPパケット、または「タイプP」のタイプに頼るかもしれません。 Type-Pの片道遅れの値は、特別な処理のためのプロトコル(UDPかTCP)、ポートナンバー、サイズ、またはアレンジメント(例えば、IP先行かRSVP)が変化するかどうかを変えるかもしれません。 正確に測定をするのに使用される正確なType-Pを報告しなければなりません。
Almes, et al. Standards Track [Page 11] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[11ページ]RFC2679A One-道の遅れ
3.8.2. Loss threshold
3.8.2. 損失敷居
In addition, the threshold (or methodology to distinguish) between a large finite delay and loss MUST be reported.
さらに、大きい有限遅れと損失の間の敷居(または、区別する方法論)を報告しなければなりません。
3.8.3. Calibration results
3.8.3. 較正結果
+ If the systematic error can be determined, it SHOULD be removed
from the measured values.
+は系統誤差であるなら断固とする場合があって、それはSHOULDです。測定値から、取り除きます。
+ 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.)
+ あなた、また、SHOULDは校正誤差を報告します、e、真の値が報告された値のプラスかマイナスeであるように、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.
+ できれば有限であるのがあるテストパケットが延着する状態はそうです。測定器具SHOULDにおけるリソース疲労困憊のため失われているように報告されて、報告されてください。
3.8.4. Path
3.8.4. 経路
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.}
最終的に、経路はパケットでSHOULDを横断しました。可能であるなら、報告されてください。 一般に、与えられたパケットがネットワークを通して取る正確な経路を知るのは非実用的です。 正確な経路は短いか安定した経路のあるType-Pで知られているかもしれません。 Type-PがIPヘッダーに記録的なルート(または、ゆるい送信元経路)オプションを含んで、経路が十分短く、経路のすべてのルータ*が記録的で(自由なソース)のルートを支えると、経路は正確に記録されるでしょう。 または、ルートが十分短くなければならないので、これは非実用的です、ルータが支持しない多く、(構成されない、)、ルートを記録してください。そうすれば、この特徴の使用はしばしば人工的によくある例処理からパケットを取り除くことによって観測された性能を悪化させるでしょう。 しかしながら、部分的な情報はまだ貴重な文脈です。 例えば、ホストが2個のリンク*を選ぶことができるなら(したがって、2はSrcからDstまでルートを切り離します)、使用される初期のリンクは貴重な文脈です。 例えば、MeritのNetNowセットアップ(1のNAPがいくつかの異なった背骨ネットワークについて別のNAPの上のDstに達することができるSrc)で以下について論評してください。
4. A Definition for Samples of One-way Delay
4. 片道遅れのサンプルのための定義
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
単独個体のメートル法のType-P片道遅れを考えて、私たちは現在、そのような単独個体の1個の特定のサンプルを定義します。 サンプルの考えはTの値を定義するための手段がパラメタのSrc、Dst、およびType-Pの特定の結合を選択して、次に、パラメタT.の値のサンプルを定義するためには、時間T0始めを選択することです、次に、Tf、および平均相場λが擬似ランダムを定義する最後の時代にことです。
Almes, et al. Standards Track [Page 12] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[12ページ]RFC2679A One-道の遅れ
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.}
{コメント: ポアソン標本抽出がサンプルを定義することにおいて一方通行であるだけであることに注意してください。 ポアソンには、バイアスを制限する利点がありますが、異なった状況に、標本抽出の他の方法は適切であるかもしれません。 私たちは、そのような適切な場合を見つける他のものがこの一般的な枠組みを使用して、標準化のための自分達の標本抽出方法を提出するよう奨励します。}
4.1. Metric Name:
4.1. メートル法の名前:
Type-P-One-way-Delay-Poisson-Stream
タイプのP片道遅れポアソンの流れ
4.2. Metric Parameters:
4.2. メートル法のパラメタ:
+ 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
+ λ、相互的な秒のレート
4.3. Metric Units:
4.3. メートル制:
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がType-Pの片道遅れへの有効なパラメタであるだろう、dTがType-Pの片道遅れの有効値であることに注意してください。
4.4. Definition:
4.4. 定義:
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
T0、Tf、およびλを考えて、私たちはT0かT0の前で平均到着率λで始まって、TfかTfの後に終わる擬似ランダムポアソンの過程を計算します。 それらの時間的価値、そして、T0と、よりTfは、より選択されます。 この過程によるそれぞれの時に、私たちはこのとき、Type-Pの片道遅れの値を得ます。 遅れ>組、サンプルの値は結果として起こる<現代で作られた系列です。 何かそのような組がなければ
Almes, et al. Standards Track [Page 13] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[13ページ]RFC2679A One-道の遅れ
sequence is of length zero and the sample is said to be empty.
系列は長さゼロのものです、そして、サンプルは空であると言われています。
4.5. Discussion:
4.5. 議論:
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.
読者はFrameworkドキュメント[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.
系列での単独個体Type-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からTfまで動く1個のサンプルを与えて、考えてT0'<=Tf'T0<=<がTfと等しいように、またT0と'Tf'の間の時間的価値秋が有効なType-Pの片道遅れポアソンの流れのサンプルである与えられたサンプルの続き。
4.6. Methodologies:
4.6. 方法論:
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.
+ 単独個体のType-Pの片道遅れのために既にメートル法でされた方法論議論。
Almes, et al. Standards Track [Page 14] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[14ページ]RFC2679A One-道の遅れ
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].
正しくテストパケットの不適切な到着を扱うためにもちろん注意を与えなければなりません。 Srcが1つのテストパケットをTS[i]に送って、次に、2番目の1つに(後で)TS[i+1]に行かせるかもしれないのは、可能です、DstがTR[i+1]で2番目のテストパケットを受けて、次に、TR[i]に(後で)の最初のものを受け取ることができましたが。
4.7. Errors and Uncertainties:
4.7. 誤りと不明確なこと:
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(単独個体遅れにおける不確実性として上にメートル法であることで言及される)の値にポアソン到着の過程を発生させるのに使用される擬似乱数のテクニック、またはジターに関する問題を含んでいて。 Frameworkドキュメントは、小さい時間枠の上でポアソン過程の精度について確かめるのにどのようにアンダーソン-最愛の人テストを使用するかを示します。 コメント: 目標はテストパケットがポアソンスケジュールの「十分近く」という送って、ことであり、周期行動を避けるのを保証することです。
4.8. Reporting the metric:
4.8. メートル法を報告します:
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.)
あなたは流れに伴う基本的な単独個体のための較正と文脈を報告しなければなりません。 (Type-Pの片道遅れに関して「メートル法を報告します」を見てください。)
5. Some Statistics Definitions for One-way Delay
5. 片道遅れのためのいくつかの統計定義
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.
サンプルのメートル法のType-P片道遅れポアソンのストリームを考えて、私たちは現在、そのサンプルのいくつかの統計を提供します。 ほとんどできたことで説明に役立つようにこれらの統計を提供します。
5.1. Type-P-One-way-Delay-Percentile
5.1. 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.
0%と100%(StreamのすべてのdT値のXth百分順位)の間にType-Pの片道遅れポアソンの流れとパーセントXを与えました。 この百分順位を計算する際に、未定義値は無限に大きいとして扱われます。 これが、その結果、百分順位が未定義であるかもしれないことを意味することに注意してください、(非公式である、無限) さらに、サンプルが空であるなら、Type-Pの片道遅れ百分順位は未定義です。
Almes, et al. Standards Track [Page 15] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[15ページ]RFC2679A One-道の遅れ
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と等しく、100msec>が<T2であり、110msec>が<T3であり、未定義の>が<T4であり、90msec>が<T5であり、500msec>は>です。
Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller and 110 msec and 'undefined' are larger.
次に、50番目の百分順位が110msecであるだろう、90以来、msecと100msecは、より小さい、そして、110msecで'未定義'が、より大きいということです。
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番目)が有限の代わりに無限であると報告されるかもしれないことに注意してください。
5.2. Type-P-One-way-Delay-Median
5.2. P片道遅れメディアンをタイプしてください。
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.
StreamでType-Pの片道遅れポアソンの流れ、すべてのdT値のメディアンを与えます。 メディアンを計算する際に、未定義値は無限に大きいとして扱われます。 Type-P片道の遅れ百分順位のように、サンプルが空であるなら、Type-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.
Frameworkドキュメントに述べられるように、サンプルが値の偶数を含む場合にだけ、メディアンは50番目の百分順位と異なっています、その場合、2つの代表値の平均が使用されています。
Example: suppose we take a sample and the results are:
例: 私たちがサンプリングするか、そして、結果は以下の通りです。
Stream2 = <
<T1, 100 msec>
<T2, 110 msec>
<T3, undefined>
<T4, 90 msec>
>
Stream2が<<T1と等しく、100msec>が<T2であり、110msec>が<T3であり、未定義の>が<T4であり、90msec>は>です。
Then the median would be 105 msec, the mean of 100 msec and 110 msec, the two central values.
次に、メディアンが105msecであるだろう、100の平均がmsecであり、110はmsec、2つの代表値です。
5.3. Type-P-One-way-Delay-Minimum
5.3. P片道遅れ最小限をタイプしてください。
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
StreamでType-Pの片道遅れポアソンの流れ、すべてのdT値の最小限を与えます。 これを計算する際に、未定義値は無限に大きいとして扱われます。 これが、その結果、最小限が未定義であるかもしれないことを意味することに注意してください、(非公式である、無限) すべてのdT値が未定義であるなら。 さらに、Type-Pの片道遅れ最小限はそうです。
Almes, et al. Standards Track [Page 16] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[16ページ]RFC2679A One-道の遅れ
undefined if the sample is empty.
未定義である、サンプルが空であるなら。
In the above example, the minimum would be 90 msec.
上記の例では、最小限は90がmsecであるならそうするでしょうに。
5.4. Type-P-One-way-Delay-Inverse-Percentile
5.4. P片道遅れ逆さの百分順位をタイプしてください。
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.
Type-Pの片道遅れポアソンの流れと時間持続時間敷居を考えて、すべてのdTの部分はStreamで、より敷居を評価します。 結果は100%と0同じくらい%(すべてのdT値が敷居を超えているなら)か同じくらい高く同じくらい低いかもしれません。 タイプP片道、-サンプルが空であるなら、遅れの逆さの百分順位は未定義です。
In the above example, the Inverse-Percentile of 103 msec would be 50%.
上記の例では、103のInverse-百分順位msecは50%でしょう。
6. Security Considerations
6. セキュリティ問題
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.
測定交通を異なった優先させるルータは交通の、または、攻撃者のそばで注入している「標準」人工の測定交通より測定自体に害を及ぼすことができました。 ルータが別々に測定交通を認識して、それを扱うことができると、測定値は実施している者交通を反映しないでしょう。 攻撃者が正統であるとして認められる人工の交通を注入すると、損失率は人工的に下げられるでしょう。 したがって、測定方法論SHOULDは、「正常な」交通と測定交通を区別できるという確率を減少させるために適切なテクニックを含んでいます。 デジタル署名などの認証のテクニックは注入された交通攻撃に用心するのが適切であるところで使用されるかもしれません。
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.
ネットワーク測定のプライバシーの問題はこのメモで説明されたアクティブな測定値によって制限されます。 受け身の測定値と異なって、既存の利用者データのリリースが全くあるはずがありません。
Almes, et al. Standards Track [Page 17] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[17ページ]RFC2679A One-道の遅れ
7. Acknowledgements
7. 承認
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.
特別な感謝は時計の不確実性と統計の問題における彼の役に立つコメントのためのローレンスバークレーLabsのバーン・パクソンのためです。 また、いくつかの役に立つ提案をガルリCouch、ウィル・リーランド、Andy Scherrer、ショーン・シャピーラ、およびローランド・ウィッティヒをありがとうございます。
8. References
8. 参照
[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パフォーマンス測定基準のための枠組み」、RFC2330)は1998がそうするかもしれません。
[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における、メートル法のA One-道のパケット損失」、RFC2680、1999年9月。
[3] Mills, D., "Network Time Protocol (v3)", RFC 1305, April 1992.
[3] 工場、D.、「ネットワーク時間プロトコル(v3)」、RFC1305、1992年4月。
[4] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, September 1999.
[4] Mahdavi J.、および「測定の接続性のためのIPPM測定基準」、RFC2678、1999年9月対パクソン
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[5] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[7] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[7] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
Almes, et al. Standards Track [Page 18] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[18ページ]RFC2679A One-道の遅れ
9. Authors' Addresses
9. 作者のアドレス
Guy Almes Advanced Network & Services, Inc. 200 Business Park Drive Armonk, NY 10504 USA
奴のAlmesはネットワークを唱えて、Inc.200ビジネスパークDriveニューヨーク10504アーモンク(米国)にサービスを提供します。
Phone: +1 914 765 1120 EMail: almes@advanced.org
以下に電話をしてください。 +1 1120年の914 765メール: almes@advanced.org
Sunil Kalidindi Advanced Network & Services, Inc. 200 Business Park Drive Armonk, NY 10504 USA
Sunil Kalidindiはネットワークを唱えて、Inc.200ビジネスパークDriveニューヨーク10504アーモンク(米国)にサービスを提供します。
Phone: +1 914 765 1128 EMail: kalidindi@advanced.org
以下に電話をしてください。 +1 1128年の914 765メール: kalidindi@advanced.org
Matthew J. Zekauskas Advanced Network & Services, Inc. 200 Business Park Drive Armonk, NY 10504 USA
マシューJ.Zekauskasはネットワークを唱えて、Inc.200ビジネスパークDriveニューヨーク10504アーモンク(米国)にサービスを提供します。
Phone: +1 914 765 1112 EMail: matt@advanced.org
以下に電話をしてください。 +1 1112年の914 765メール: matt@advanced.org
Almes, et al. Standards Track [Page 19] RFC 2679 A One-way Delay Metric for IPPM September 1999
Almes、他 IPPM1999年9月のメートル法の標準化過程[19ページ]RFC2679A One-道の遅れ
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Almes, et al. Standards Track [Page 20]
Almes、他 標準化過程[20ページ]
一覧
スポンサーリンク
