RFC2330 日本語訳
2330 Framework for IP Performance Metrics. V. Paxson, G. Almes, J.Mahdavi, M. Mathis. May 1998. (Format: TXT=94387 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group V. Paxson
Request for Comments: 2330 Lawrence Berkeley National Lab
Category: Informational G. Almes
Advanced Network & Services
J. Mahdavi
M. Mathis
Pittsburgh Supercomputer Center
May 1998
コメントを求めるワーキンググループV.パクソンの要求をネットワークでつないでください: 2330年のローレンス・バークレー国家の研究室カテゴリ: 情報のG.Almes高度なネットワークとサービスJ.Mahdavi M.マシスピッツバーグスーパーコンピュータは1998年5月を中心に置きます。
Framework for IP Performance Metrics
IPパフォーマンス測定基準のための枠組み
1. Status of this Memo
1. このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
2. Copyright Notice
2. 版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Table of Contents
目次
1. STATUS OF THIS MEMO.............................................1
2. COPYRIGHT NOTICE................................................1
3. INTRODUCTION....................................................2
4. CRITERIA FOR IP PERFORMANCE METRICS.............................3
5. TERMINOLOGY FOR PATHS AND CLOUDS................................4
6. FUNDAMENTAL CONCEPTS............................................5
6.1 Metrics......................................................5
6.2 Measurement Methodology......................................6
6.3 Measurements, Uncertainties, and Errors......................7
7. METRICS AND THE ANALYTICAL FRAMEWORK............................8
8. EMPIRICALLY SPECIFIED METRICS..................................11
9. TWO FORMS OF COMPOSITION.......................................12
9.1 Spatial Composition of Metrics..............................12
9.2 Temporal Composition of Formal Models and Empirical Metrics.13
10. ISSUES RELATED TO TIME........................................14
10.1 Clock Issues...............................................14
10.2 The Notion of "Wire Time"..................................17
11. SINGLETONS, SAMPLES, AND STATISTICS............................19
11.1 Methods of Collecting Samples..............................20
11.1.1 Poisson Sampling........................................21
11.1.2 Geometric Sampling......................................22
11.1.3 Generating Poisson Sampling Intervals...................22
1. このメモの状態…1 2. 版権情報…1 3. 序論…2 4. IP性能測定基準の評価基準…3 5. 経路ANDのための用語は曇ります…4 6. 基本概念…5 6.1の測定基準…5 6.2 測定方法論…6 6.3の測定値、不明確なこと、および誤り…7 7. 測定基準と分析枠組み…8 8. 測定基準を経験して指定します…11 9. 2つの形式の構成…12 9.1 測定基準の空間的な構成…12 9.2 形式モデルと実証的な測定基準.13 10の時の構成。 問題はタイム誌に関連しました…14 10.1 問題の時間を計ってください…14 10.2 「ワイヤ時間」の概念…17 11. 単独個体、サンプル、AND統計…サンプルを集める19 11.1の方法…20 11.1.1 ポアソンSampling…21 11.1.2 幾何学上標本抽出…22 11.1.3 ポアソン標本抽出間隔を発生させます…22
Paxson, et. al. Informational [Page 1] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[1ページ]のRFC2330枠組み
11.2 Self-Consistency...........................................24
11.3 Defining Statistical Distributions.........................25
11.4 Testing For Goodness-of-Fit................................27
12. AVOIDING STOCHASTIC METRICS....................................28
13. PACKETS OF TYPE P..............................................29
14. INTERNET ADDRESSES VS. HOSTS...................................30
15. STANDARD-FORMED PACKETS........................................30
16. ACKNOWLEDGEMENTS...............................................31
17. SECURITY CONSIDERATIONS........................................31
18. APPENDIX.......................................................32
19. REFERENCES.....................................................38
20. AUTHORS' ADDRESSES.............................................39
21. FULL COPYRIGHT STATEMENT.......................................40
11.2自己一貫性…24 11.3 統計的な配を定義します…25 11.4 適合度がないかどうかテストします…27 12. 推計的な測定基準を避けます…28 13. タイプP.のパケット…29 14. インターネットは記述します。 ホスト…30 15. パケットを規格で形成します…30 16. 承認…31 17. セキュリティ問題…31 18. 付録…32 19. 参照…38 20. 作者のアドレス…39 21. 完全な著作権宣言文…40
3. Introduction
3. 序論
The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort, begun by the Benchmarking Methodology Working Group (BMWG) of the Operational Requirements Area, and being continued by the IP Performance Metrics Working Group (IPPM) of the Transport Area.
このメモの目的は特定の測定基準がIETFのIPパフォーマンスMetricsの努力で開発されるために一般的な枠組みを定義することです、Operational Requirements AreaのBenchmarking Methodology作業部会(BMWG)によって始められて、Transport AreaのIPパフォーマンスMetrics作業部会(IPPM)によって続けられていて。
We begin by laying out several criteria for the metrics that we adopt. These criteria are designed to promote an IPPM effort that will maximize an accurate common understanding by Internet users and Internet providers of the performance and reliability both of end- to-end paths through the Internet and of specific 'IP clouds' that comprise portions of those paths.
私たちは、私たちが採用する測定基準のいくつかの評価基準を広げることによって、始めます。 これらの評価基準は、性能のインターネットユーザとプロバイダとインターネットを通した終わりまでの端の経路とそれらの経路の部分を包括する特定の'IP雲'の信頼性で正確な一般的な理解を最大にするIPPMの努力を促進するように設計されています。
We next define some Internet vocabulary that will allow us to speak clearly about Internet components such as routers, paths, and clouds.
私たち、次は私たちが明確にルータや、経路や、雲などのインターネット成分について話すことができる何らかのインターネットボキャブラリーを定義します。
We then define the fundamental concepts of 'metric' and 'measurement methodology', which allow us to speak clearly about measurement issues. Given these concepts, we proceed to discuss the important issue of measurement uncertainties and errors, and develop a key, somewhat subtle notion of how they relate to the analytical framework shared by many aspects of the Internet engineering discipline. We then introduce the notion of empirically defined metrics, and finish this part of the document with a general discussion of how metrics can be 'composed'.
そして、私たちは私たちが明確に測定問題について話すことができる'メートル法'と'測定方法論'に関する基本概念を定義します。 これらの概念を考えて、私たちは、測定不明確なことと誤りの切迫した課題について議論して、キー、それらがどうインターネット工学規律の多くの局面によって共有された分析枠組みに関連するかに関するいくらか微妙な概念を発生しかけます。 私たちは、どう測定基準を'構成できるか'に関する一般的な議論で次に、経験して定義された測定基準の概念を紹介して、ドキュメントのこの部分を終えます。
The remainder of the document deals with a variety of issues related to defining sound metrics and methodologies: how to deal with imperfect clocks; the notion of 'wire time' as distinct from 'host time'; how to aggregate sets of singleton metrics into samples and
ドキュメントの残りは音の測定基準と方法論を定義すると関連するさまざまな問題に対処します: どう不完全な時計に対処するか。 'ホスト時間'と異なるとしての'ワイヤ時間'の概念。 そしてどうサンプルへの単独個体測定基準のセットに集合であるか。
Paxson, et. al. Informational [Page 2] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[2ページ]のRFC2330枠組み
derive sound statistics from those samples; why it is recommended to avoid thinking about Internet properties in probabilistic terms (such as the probability that a packet is dropped), since these terms often include implicit assumptions about how the network behaves; the utility of defining metrics in terms of packets of a generic type; the benefits of preferring IP addresses to DNS host names; and the notion of 'standard-formed' packets. An appendix discusses the Anderson-Darling test for gauging whether a set of values matches a given statistical distribution, and gives C code for an implementation of the test.
それらのサンプルから音の統計を得てください。 確率的な用語(パケットが落とされるという確率などの)でインターネットの特性について考えるのを避けるのがお勧めである理由、これらの用語がしばしばどのようにに関する暗黙の仮定を含んでいるかので、ネットワークは振る舞います。 ジェネリックのパケットに関する測定基準がタイプする定義に関するユーティリティ。 IPを好む利益はDNSにホスト名を記述します。 そして、'規格で形成された'パケットの概念。 付録は1セットの値が与えられた統計的分布に合って、テストの実現のためにCコードを与えるかどうかを測るためのアンダーソン-最愛の人テストについて議論します。
In some sections of the memo, we will surround some commentary text
with the brackets {Comment: ... }. We stress that this commentary is
only commentary, and is not itself part of the framework document or
a proposal of particular metrics. In some cases this commentary will
discuss some of the properties of metrics that might be envisioned,
but the reader should assume that any such discussion is intended
only to shed light on points made in the framework document, and not
to suggest any specific metrics.
数人のセクションに関するメモでは、私たちは何らかの論評テキストを括弧に取り巻くつもりです。コメント: … 私たちはこの論評がそれ自体で論評だけであり、枠組みのドキュメントの一部か特定の測定基準の提案でないと強調します。 いくつかの場合、この論評は思い描かれるかもしれない測定基準のいくつかの特性について議論するでしょうが、読者は、どんなそのような議論も単に枠組みのドキュメントで指摘されたポイントを解明して、どんな特定の測定基準も示さないことを意図すると仮定するべきです。
4. Criteria for IP Performance Metrics
4. IPパフォーマンス測定基準の評価基準
The overarching goal of the IP Performance Metrics effort is to achieve a situation in which users and providers of Internet transport service have an accurate common understanding of the performance and reliability of the Internet component 'clouds' that they use/provide.
IPパフォーマンスMetricsの努力のアーチをかける目標はインターネット輸送サービスのユーザとプロバイダーが性能の正確な一般的な理解とそれらが使用するか、または提供するインターネットコンポーネント'雲'の信頼性を持っている状況を獲得することです。
To achieve this, performance and reliability metrics for paths through the Internet must be developed. In several IETF meetings criteria for these metrics have been specified:
インターネットを通してこれ、性能、および信頼性の測定基準を経路に達成するのは開発していなければなりません。 いくつかのIETFミーティングでは、これらの測定基準の評価基準は指定されました:
+ The metrics must be concrete and well-defined,
+ A methodology for a metric should have the property that it is
repeatable: if the methodology is used multiple times under
identical conditions, the same measurements should result in the
same measurements.
+ The metrics must exhibit no bias for IP clouds implemented with
identical technology,
+ The metrics must exhibit understood and fair bias for IP clouds
implemented with non-identical technology,
+ The metrics must be useful to users and providers in understanding
the performance they experience or provide,
+ 測定基準は具体的であって、明確であるに違いありません、特性がaにおける、メートル法の方法論で反復可能するべきである+: 方法論が複数の回同じ条件のもとで使用されるなら、同じ測定値は同じ測定値をもたらすべきです。 + 測定基準が同じ技術で実行されたIP雲、理解されていて、測定基準が示さなければならない+のために偏見を全く示してはいけなくて、IPが+ 非同じ技術、測定基準で実行されていた状態で曇るので、公正なバイアスは、それらが経験する性能を理解する際にユーザとプロバイダーの役に立つか、または提供されなければなりません。
Paxson, et. al. Informational [Page 3] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[3ページ]のRFC2330枠組み
+ The metrics must avoid inducing artificial performance goals.
+ 測定基準は、人工の性能目標を引き起こすのを避けなければなりません。
5. Terminology for Paths and Clouds
5. 経路と雲のための用語
The following list defines terms that need to be precise in the development of path metrics. We begin with low-level notions of 'host', 'router', and 'link', then proceed to define the notions of 'path', 'IP cloud', and 'exchange' that allow us to segment a path into relevant pieces.
以下のリストは経路測定基準の開発で正確である必要がある用語を定義します。 私たちは'ホスト'の低レベルである概念で始めて、次に、'ルータ'、および'リンク'はセグメントへの経路を私たちに許容する'経路'、'IP雲'、および'交換'の概念を関連断片と定義しかけます。
host A computer capable of communicating using the Internet
protocols; includes "routers".
インターネットプロトコルを使用することで交信できるAコンピュータを接待してください。 「ルータ」を含んでいます。
link A single link-level connection between two (or more) hosts;
includes leased lines, ethernets, frame relay clouds, etc.
2人(さらに)のホストの間のA単独のリンク・レベル接続をリンクしてください。 専用線、イーサネット、フレームリレー雲などを含んでいます。
routerA host which facilitates network-level communication between
hosts by forwarding IP packets.
routerAは推進IPパケットでホストのネットワークレベルコミュニケーションを容易にするものを接待します。
path A sequence of the form < h0, l1, h1, ..., ln, hn >, where n >=
0, each hi is a host, each li is a link between hi-1 and hi,
each h1...hn-1 is a router. A pair <li, hi> is termed a 'hop'.
In an appropriate operational configuration, the links and
routers in the path facilitate network-layer communication of
packets from h0 to hn. Note that path is a unidirectional
concept.
フォーム<h0、l1、h1の経路A系列…, それぞれln、hn>、どこn>=0、こんにちは、ホストであり、各liがこんにちは、hi-1と各h1との…リンクであるということであるか。hn-1はルータです。 こんにちは、組<li、>は'ホップ'と呼ばれます。 適切な操作上の構成では、経路のリンクとルータはパケットに関するネットワーク層コミュニケーションをh0からhnまで容易にします。 経路が単方向の概念であることに注意してください。
subpath
Given a path, a subpath is any subsequence of the given path
which is itself a path. (Thus, the first and last element of a
subpath is a host.)
subpath Given a経路、aはsubpathにそれ自体で経路である当然のことの経路のあらゆる続きです。 (その結果、「副-経路」の1番目と最後の要素はホストです。)
cloudAn undirected (possibly cyclic) graph whose vertices are routers
and whose edges are links that connect pairs of routers.
Formally, ethernets, frame relay clouds, and other links that
connect more than two routers are modelled as fully-connected
meshes of graph edges. Note that to connect to a cloud means to
connect to a router of the cloud over a link; this link is not
itself part of the cloud.
頭頂がルータであり、縁が組のルータを接続するリンクであるcloudAn undirected(ことによると周期的な)はグラフ化します。 正式に、2つ以上のルータを接続するイーサネット、フレームリレー雲、および他のリンクがグラフ縁の完全に接続されたメッシュとしてモデル化されます。 リンクの上の雲のルータに接続する雲の手段に接続するためにそれに注意してください。 このリンクはそれ自体で雲の一部ではありません。
exchange
A special case of a link, an exchange directly connects either a
host to a cloud and/or one cloud to another cloud.
リンクに関する交換A特別番組ケース、交換は直接別の雲への雲、そして/または、1つの雲にホストに接します。
cloud subpath
A subpath of a given path, all of whose hosts are routers of a
given cloud.
与えられた経路の「副-経路」A「副-経路」を曇らせてください。(経路のホストは皆、与えられた雲のルータです)。
Paxson, et. al. Informational [Page 4] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[4ページ]のRFC2330枠組み
path digest
A sequence of the form < h0, e1, C1, ..., en, hn >, where n >=
0, h0 and hn are hosts, each e1 ... en is an exchange, and each
C1 ... Cn-1 is a cloud subpath.
フォーム<h0、e1、C1の経路ダイジェストA系列…, アン、hn>、それぞれのe1…アンは、交換と、各C1です…(そこでは、0、h0、およびn>=hnがホストです)。 Cn-1は雲の「副-経路」です。
6. Fundamental Concepts
6. 基本概念
6.1. Metrics
6.1. 測定基準
In the operational Internet, there are several quantities related to the performance and reliability of the Internet that we'd like to know the value of. When such a quantity is carefully specified, we term the quantity a metric. We anticipate that there will be separate RFCs for each metric (or for each closely related group of metrics).
操作上のインターネットに、値を知りたいと思うインターネットの性能と信頼性に関連するいくつかの量があります。 そのような量が慎重に指定されて、私たちが用語である、量、aメートル法です。 私たちが、それぞれにおける、メートル法の別々のRFCsがあると予期する、(それぞれ、密接である、測定基準の関係団体)
In some cases, there might be no obvious means to effectively measure the metric; this is allowed, and even understood to be very useful in some cases. It is required, however, that the specification of the metric be as clear as possible about what quantity is being specified. Thus, difficulty in practical measurement is sometimes allowed, but ambiguity in meaning is not.
いくつかの場合、事実上、メートル法を測定するどんな明白な手段もないかもしれません。 これは、いくつかの場合、非常に役に立つのが許容されていて、理解されてさえいます。 しかしながら、どんな量が指定されるかに関してメートル法の仕様ができるだけ明確であることが必要です。 したがって、実用的な測定における困難は時々許容されていますが、意味におけるあいまいさは許容されるというわけではありません。
Each metric will be defined in terms of standard units of measurement. The international metric system will be used, with the following points specifically noted:
それぞれメートル法、標準のユニットの測定で、定義されるでしょう。 国際的なメートル法は明確に注意される以下のポイントと共に使用されるでしょう:
+ When a unit is expressed in simple meters (for distance/length) or
seconds (for duration), appropriate related units based on
thousands or thousandths of acceptable units are acceptable.
Thus, distances expressed in kilometers (km), durations expressed
in milliseconds (ms), or microseconds (us) are allowed, but not
centimeters (because the prefix is not in terms of thousands or
thousandths).
+ When a unit is expressed in a combination of units, appropriate
related units based on thousands or thousandths of acceptable
units are acceptable, but all such thousands/thousandths must be
grouped at the beginning. Thus, kilo-meters per second (km/s) is
allowed, but meters per millisecond is not.
+ The unit of information is the bit.
+ When metric prefixes are used with bits or with combinations
including bits, those prefixes will have their metric meaning
(related to decimal 1000), and not the meaning conventional with
computer storage (related to decimal 1024). In any RFC that
defines a metric whose units include bits, this convention will be
followed and will be repeated to ensure clarity for the reader.
ユニットが簡単なメーター(距離/長さのための)か秒(持続時間のための)に言い表される+、許容できるユニットについて数千か1000第年代に基づく適切な関連するユニットは許容できます。 キロメートル(km)で距離は、したがって、持続時間がミリセカンドで(ms)を言い表したか、またはマイクロセカンド(私たち)が許容されているのではなく、センチメートルにいずれ許容されていると言い表しました(数千か1000第年代に関して接頭語がないので)。 ユニットがユニットの組み合わせで言い表される+、許容できるユニットについて数千か1000第年代に基づく適切な関連するユニットは許容できますが、始めにそのようなすべての1000数千/第年代を分類しなければなりません。 したがって、2番目の(km/s)あたりのキロメートルは許容されていますが、1ミリセカンドあたりのメーターは許容されるというわけではありません。 + 情報のユニットはビットです。 + いつ、メートル法の接頭語がビットと共に使用されるか、またはそれらの接頭語には組み合わせがビットを含んでいて、それらのメートル法の意味(10進1000に関連する)があるでしょうか、そして、コンピュータ・ストレージ(10進1024に関連する)による従来の意味でない。 メートル法でaを定義するどんなRFCでも、インクルードビット、このコンベンションがだれのユニットになるかは、読者のために明快を確実にするために続かれていて、繰り返されるでしょう。
Paxson, et. al. Informational [Page 5] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[5ページ]のRFC2330枠組み
+ When a time is given, it will be expressed in UTC.
時間を与えて、UTCでそれを言い表す+。
Note that these points apply to the specifications for metrics and not, for example, to packet formats where octets will likely be used in preference/addition to bits.
八重奏がビットへの好み/添加におそらく使用されるところでこれらのポイントが例えばパケット・フォーマットではなく、測定基準のための仕様に適用されることに注意してください。
Finally, we note that some metrics may be defined purely in terms of other metrics; such metrics are call 'derived metrics'.
最終的に、私たちは、いくつかの測定基準が他の測定基準で純粋に定義されるかもしれないことに注意します。 そのような測定基準は呼び出しを'測定基準を引き出させた'ということです。
6.2. Measurement Methodology
6.2. 測定方法論
For a given set of well-defined metrics, a number of distinct measurement methodologies may exist. A partial list includes:
与えられたセットの明確な測定基準のために、多くの異なった測定方法論が存在するかもしれません。 部分的なリストは:
+ Direct measurement of a performance metric using injected test
traffic. Example: measurement of the round-trip delay of an IP
packet of a given size over a given route at a given time.
+ Projection of a metric from lower-level measurements. Example:
given accurate measurements of propagation delay and bandwidth for
each step along a path, projection of the complete delay for the
path for an IP packet of a given size.
+ Estimation of a constituent metric from a set of more aggregated
measurements. Example: given accurate measurements of delay for a
given one-hop path for IP packets of different sizes, estimation
of propagation delay for the link of that one-hop path.
+ Estimation of a given metric at one time from a set of related
metrics at other times. Example: given an accurate measurement of
flow capacity at a past time, together with a set of accurate
delay measurements for that past time and the current time, and
given a model of flow dynamics, estimate the flow capacity that
would be observed at the current time.
+ 性能のメートル法の使用の直接測定はテスト交通を注入しました。 例: 与えられた時間の与えられたルートの上の与えられたサイズのIPパケットの往復の遅れの測定。 + 低レベル測定値からのメートル法のaの映像。 例: それぞれのための伝播遅延と帯域幅の与えられた正確な寸法は経路(与えられたサイズのIPパケットのための経路への完全な遅れの映像)に沿って踏まれます。 + 1セットの以上からのメートル法の成分に関する見積りは測定値に集められました。 例: 異なったサイズのIPパケット、伝播に関する見積りのための与えられたワンバウンドの経路への遅れの正確な寸法を考えて、そのワンバウンドの経路のリンクに延着してください。 + 他の時にひところ1セットの関連する測定基準からメートル法で与えられたaに関する見積り。 例: 時間のそれのための1セットの正確な遅れ測定値に伴う過去の1時間と現在の時間の生産能力の正確な寸法を考えて、流れ力学のモデルを考えて、流れが現在の時間に観測される容量であると見積もってください。
This list is by no means exhaustive. The purpose is to point out the variety of measurement techniques.
このリストは決して徹底的ではありません。 目的は測定技術のバラエティーを指摘することです。
When a given metric is specified, a given measurement approach might be noted and discussed. That approach, however, is not formally part of the specification.
メートル法で与えられたaが指定されるとき、当然のことの測定アプローチについて、注意されて、議論するかもしれません。 しかしながら、そのアプローチは仕様を正式に離れさせないことです。
A methodology for a metric should have the property that it is repeatable: if the methodology is used multiple times under identical conditions, it should result in consistent measurements.
aにおける、メートル法の方法論で、特性は反復可能されるべきです: 方法論が複数の回同じ条件のもとで使用されるなら、それは一貫した測定値をもたらすべきです。
Backing off a little from the word 'identical' in the previous paragraph, we could more accurately use the word 'continuity' to describe a property of a given methodology: a methodology for a given metric exhibits continuity if, for small variations in conditions, it
前のパラグラフが'同じ'単語から少し戻して、私たちは与えられた方法論の特性について説明するのにより正確に'連続'という単語を使用できました: メートル法で与えられたaのための方法論が連続を示す、状態の小さい変化のためにそれ
Paxson, et. al. Informational [Page 6] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[6ページ]のRFC2330枠組み
results in small variations in the resulting measurements. Slightly more precisely, for every positive epsilon, there exists a positive delta, such that if two sets of conditions are within delta of each other, then the resulting measurements will be within epsilon of each other. At this point, this should be taken as a heuristic driving our intuition about one kind of robustness property rather than as a precise notion.
結果として起こる測定値の小さい変化における結果。 あらゆる積極的なεのために、積極的なデルタは、より正確にわずかに存在しています、互いのデルタの中に2セットの状態があると互いのεの中に結果として起こる測定値があるように。 ここに、これは正確な概念としてというよりむしろ1種類の丈夫さ所有地の周りで私たちの直観を追い立てるヒューリスティックとしてみなされるべきです。
A metric that has at least one methodology that exhibits continuity is said itself to exhibit continuity.
Aメートル法、それには、展示品の連続がある連続を示すためにそれ自体で言われた少なくとも1つの方法論があります。
Note that some metrics, such as hop-count along a path, are integer- valued and therefore cannot exhibit continuity in quite the sense given above.
経路に沿ったホップカウントなどのいくつかの測定基準が整数であるというメモは、上に与えられたかなりの意味における連続を評価して、したがって、示すことができません。
Note further that, in practice, it may not be practical to know (or be able to quantify) the conditions relevant to a measurement at a given time. For example, since the instantaneous load (in packets to be served) at a given router in a high-speed wide-area network can vary widely over relatively brief periods and will be very hard for an external observer to quantify, various statistics of a given metric may be more repeatable, or may better exhibit continuity. In that case those particular statistics should be specified when the metric is specified.
または、知るのが実際には実用的でないかもしれないことにさらに注意してください、(定量化できる、)、与えられた時に測定に関連している状態。 例えば、高速広域ネットワークにおける当然のことのルータにおける瞬時に起こっている負荷(役立たれるパケットの)が比較的簡潔な期間、ばらつきが大きいことができ、外部の観察者が非常に定量化しにくいようになるので、メートル法で与えられたaの様々な統計は、より反復可能であるかもしれないか、または連続を示すほうがよいです。 その場合、メートル法が指定されるそれらの特定の統計は指定されるべきです。
Finally, some measurement methodologies may be 'conservative' in the
sense that the act of measurement does not modify, or only slightly
modifies, the value of the performance metric the methodology
attempts to measure. {Comment: for example, in a wide-are high-speed
network under modest load, a test using several small 'ping' packets
to measure delay would likely not interfere (much) with the delay
properties of that network as observed by others. The corresponding
statement about tests using a large flow to measure flow capacity
would likely fail.}
最終的に、いくつかの測定方法論は意味における測定の行為がする'保守的な人'がメートル法で性能の値を変更するだけではないか、またはわずかに変更するだけではないということであるかもしれません。方法論は、測定するのを試みます。 {コメント: 例えばa、広さ、-、穏やかな負荷の下における高速ネットワーク、遅れを測定するのにいくつかの小さい'ピング'パケットを使用するテストはおそらく他のものによって観測されるようにその特性がネットワークでつなぐ遅れを(多く)妨げないでしょう。 生産能力を測定するのに大きい流れを使用するテストに関する対応する声明はおそらく失敗するでしょう。}
6.3. Measurements, Uncertainties, and Errors
6.3. 測定値、不明確なこと、および誤り
Even the very best measurement methodologies for the very most well behaved metrics will exhibit errors. Those who develop such measurement methodologies, however, should strive to:
非常によく最も振る舞っている測定基準のための最も良い測定方法論さえ誤りを示すでしょう。 しかしながら、そのような測定方法論を開発する人は、以下のことように努力するべきです。
Paxson, et. al. Informational [Page 7] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[7ページ]のRFC2330枠組み
+ minimize their uncertainties/errors, + understand and document the sources of uncertainty/error, and + quantify the amounts of uncertainty/error.
+は彼らの不明確なこと/誤りを最小にします、そして、+は、不確実性/誤りの源を理解して、記録します、そして、+は不確実性/誤りの量を定量化します。
For example, when developing a method for measuring delay, understand how any errors in your clocks introduce errors into your delay measurement, and quantify this effect as well as you can. In some cases, this will result in a requirement that a clock be at least up to a certain quality if it is to be used to make a certain measurement.
例えば、測定遅れのために方法を開発するときには何かあなたの時計の誤りがどのように遅れ測定に誤りを取り入れるか理解してください、そして、この効果をできるだけよく定量化してください。 いくつかの場合、それが、ある測定をするのに使用されるつもりであると、これは時計が、ある品質に少なくとも上がっているという要件をもたらすでしょう。
As a second example, consider the timing error due to measurement overheads within the computer making the measurement, as opposed to delays due to the Internet component being measured. The former is a measurement error, while the latter reflects the metric of interest. Note that one technique that can help avoid this overhead is the use of a packet filter/sniffer, running on a separate computer that records network packets and timestamps them accurately (see the discussion of 'wire time' below). The resulting trace can then be analyzed to assess the test traffic, minimizing the effect of measurement host delays, or at least allowing those delays to be accounted for. We note that this technique may prove beneficial even if the packet filter/sniffer runs on the same machine, because such measurements generally provide 'kernel-level' timestamping as opposed to less-accurate 'application-level' timestamping.
2番目の例と、測定をしながら、コンピュータの中に測定オーバーヘッドによるタイミング誤りを考えてください、測定されるインターネットコンポーネントによる遅れと対照的に。 前者は測定誤差ですが、後者は興味があるメートル法を反映します。 このオーバーヘッドを避けるのを助けることができる1つのテクニックがパケットフィルタ/麻薬を吸う人の使用であることに注意してください、ネットワークパケットを記録する別々のコンピュータとタイムスタンプでそれらを正確に走らせて(以下の'ワイヤ時間'の議論を見てください)。 次に、テスト交通を評価するために結果として起こる跡を分析できます、測定ホスト遅れの効果を最小にするか、またはそれらの遅れが説明されるのを少なくとも許容して。 私たちは、パケットフィルタ/麻薬を吸う人が同じマシンで動いてもこのテクニックが有益であると判明するかもしれないことに注意します、そのような測定値がそれほど正確でない'アプリケーションレベル'timestampingと対照的にtimestampingしながら一般に'カーネルレベル'を提供するので。
Finally, we note that derived metrics (defined above) or metrics that exhibit spatial or temporal composition (defined below) offer particular occasion for the analysis of measurement uncertainties, namely how the uncertainties propagate (conceptually) due to the derivation or composition.
最終的に、私たちは、それが測定基準(上では、定義される)を引き出したことに注意するか、または空間的であるか時の構成(以下では、定義される)を示す測定基準が不明確なことが派生か構成のため測定不明確なこと、すなわち、どう伝播されるかに関する(概念的に)分析のために特定の時を申し出ます。
7. Metrics and the Analytical Framework
7. 測定基準と分析枠組み
As the Internet has evolved from the early packet-switching studies of the 1960s, the Internet engineering community has evolved a common analytical framework of concepts. This analytical framework, or A- frame, used by designers and implementers of protocols, by those involved in measurement, and by those who study computer network performance using the tools of simulation and analysis, has great advantage to our work. A major objective here is to generate network characterizations that are consistent in both analytical and practical settings, since this will maximize the chances that non- empirical network study can be better correlated with, and used to further our understanding of, real network behavior.
インターネットが1960年代の早めのパケット交換研究から発展するのに従って、インターネット工学共同体は概念の一般的な分析枠組みを発展しました。 この分析枠組み、またはAフレーム、プロトコルのデザイナーとimplementers、測定における関係者によって使用されて、コンピュータネットワーク性能を研究する人でシミュレーションと分析のツールを使用するのにおいて、私たちの仕事のかなりの利点があります。 ここの主要な目的は分析ものと同様に実用的な設定で一貫したネットワーク特殊化を発生させることです、これが非実証的なネットワーク研究と互いに関連するほうがよくて、使用できるという私たちの理解を促進する可能性を最大にするので、本当のネットワークの振舞い。
Paxson, et. al. Informational [Page 8] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[8ページ]のRFC2330枠組み
Whenever possible, therefore, we would like to develop and leverage off of the A-frame. Thus, whenever a metric to be specified is understood to be closely related to concepts within the A-frame, we will attempt to specify the metric in the A-frame's terms. In such a specification we will develop the A-frame by precisely defining the concepts needed for the metric, then leverage off of the A-frame by defining the metric in terms of those concepts.
可能であるときはいつも、したがって、A-フレームから展開して、力を入れたいと思います。 したがって、指定されているためにはメートル法のaによって密接にA-フレームの中の概念に関連されるのが理解されているときはいつも、私たちは、A-フレームの用語によるメートル法を指定するのを試みるつもりです。そのような仕様では、私たちは、正確にメートル法に必要である概念を定義することによってA-フレームを開発して、次に、A-フレームからそれらの概念に関するメートル法を定義することによって、力を入れるつもりです。
Such a metric will be called an 'analytically specified metric' or, more simply, an analytical metric.
または、あれほどaメートル法、'メートル法で分析的に指定されています'と呼ばれる、 より簡単である、分析、メートル法です。
{Comment: Examples of such analytical metrics might include:
コメント: そのような分析測定基準に関する例は以下を含むかもしれません。
propagation time of a link
The time, in seconds, required by a single bit to travel from the
output port on one Internet host across a single link to another
Internet host.
1ビットに従って時間が秒に別のインターネット・ホストへの単一のリンクの向こう側に1人のインターネット・ホストの上の出力ポートから旅するのを必要としたリンクの伝播時間。
bandwidth of a link for packets of size k
The capacity, in bits/second, where only those bits of the IP
packet are counted, for packets of size k bytes.
aの帯域幅はサイズkのパケットのために容量をリンクします、ビット/秒で、サイズキロバイトのパケットのために。(そこでは、IPパケットのそれらのビットだけが数えられます)。
routeThe path, as defined in Section 5, from A to B at a given time.
一時にセクション5でAからBまで定義されるようなrouteThe経路。
hop count of a route
The value 'n' of the route path.
}
'aのホップカウントが値を発送する、'ルート経路について。 }
Note that we make no a priori list of just what A-frame concepts
will emerge in these specifications, but we do encourage their use
and urge that they be carefully specified so that, as our set of
metrics develops, so will a specified set of A-frame concepts
technically consistent with each other and consonant with the
common understanding of those concepts within the general Internet
community.
まさしくどんなA-フレーム概念がこれらの仕様に現れるかに関する先験的なリストを全く作りませんが、私たちが彼らの使用を奨励することに注意してください、そして、したがって、私たちの測定基準のセットが発展するときそれはそれらの概念の一般的な理解への一般的なインターネットコミュニティの中の互いと技術的に一致して子音のA-フレーム概念の指定されたセットを促すためにそれらが慎重に指定されるよう促してください。
These A-frame concepts will be intended to abstract from actual
Internet components in such a way that:
これらのA-フレーム概念は以下のことのような方法で実際のインターネットコンポーネントからの要約に意図するでしょう。
+ the essential function of the component is retained,
+ properties of the component relevant to the metrics we aim to
create are retained,
+ a subset of these component properties are potentially defined as
analytical metrics, and
そして+ コンポーネントの不可欠の関数が保有されて、+ 私たちが作成することを目指す測定基準に関連しているコンポーネントの特性が保有されて、+ これらのコンポーネントの特性の部分集合が潜在的に分析測定基準と定義される。
Paxson, et. al. Informational [Page 9] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[9ページ]のRFC2330枠組み
+ those properties of actual Internet components not relevant to
defining the metrics we aim to create are dropped.
+ 私たちが作成することを目指す測定基準を定義すると関連していない実際のインターネットコンポーネントのそれらの特性は落とされます。
For example, when considering a router in the context of packet forwarding, we might model the router as a component that receives packets on an input link, queues them on a FIFO packet queue of finite size, employs tail-drop when the packet queue is full, and forwards them on an output link. The transmission speed (in bits/second) of the input and output links, the latency in the router (in seconds), and the maximum size of the packet queue (in bits) are relevant analytical metrics.
パケット推進の文脈のルータを考えるとき、例えば、私たちは入力リンクの上にパケットを受けて、有限サイズの先入れ先出し法パケット待ち行列のときにそれらを列に並ばせて、パケット待ち行列が完全であるときに、テール低下を使って、出力リンクの上にそれらを進めるコンポーネントとしてルータをモデル化するかもしれません。 入出力リンクの伝送速度(ビット/秒の)、ルータにおける潜在(秒の)、およびパケット待ち行列の最大サイズ(ビットの)は関連分析測定基準です。
In some cases, such analytical metrics used in relation to a router will be very closely related to specific metrics of the performance of Internet paths. For example, an obvious formula (L + P/B) involving the latency in the router (L), the packet size (in bits) (P), and the transmission speed of the output link (B) might closely approximate the increase in packet delay due to the insertion of a given router along a path.
いくつかの場合、ルータと関連して使用されるそのような分析測定基準は非常に密接にインターネット経路の性能の特定の測定基準に関連するでしょう。 例えば、ルータ(L)に潜在にかかわる明白な公式(L+P/B)、パケットサイズ(ビットの)(P)、および出力リンク(B)の伝送速度は与えられたルータの挿入のため経路に沿って密接にパケット遅れの増加に近似するかもしれません。
We stress, however, that well-chosen and well-specified A-frame concepts and their analytical metrics will support more general metric creation efforts in less obvious ways.
しかしながら、私たちは、適切でよく指定されたA-フレーム概念とそれらの分析測定基準が、より少ない当たり前の方法的により一般的なメートル法の創造の努力を支持すると強調します。
{Comment: for example, when considering the flow capacity of a path,
it may be of real value to be able to model each of the routers along
the path as packet forwarders as above. Techniques for estimating
the flow capacity of a path might use the maximum packet queue size
as a parameter in decidedly non-obvious ways. For example, as the
maximum queue size increases, so will the ability of the router to
continuously move traffic along an output link despite fluctuations
in traffic from an input link. Estimating this increase, however,
remains a research topic.}
{コメント: 流れが経路の容量であると考えるとき、例えば、パケット混載業者としての上の経路に沿ってそれぞれのルータをモデル化できるように、それには実価があるかもしれません。 流れが経路の容量であると見積もるためのテクニックはパラメタとして明らかに非当たり前の方法的に最大のパケット待ち行列サイズを使用するかもしれません。 例えば、最大の待ち行列サイズが増加するのに従って、交通における変動にもかかわらず、ルータが出力リンクに沿って入力リンクから交通を絶え間なく動かす能力もそうするでしょう。 しかしながら、この増加を見積もっているのは研究話題のままで残っています。}
Note that, when we specify A-frame concepts and analytical metrics, we will inevitably make simplifying assumptions. The key role of these concepts is to abstract the properties of the Internet components relevant to given metrics. Judgement is required to avoid making assumptions that bias the modeling and metric effort toward one kind of design.
A-フレーム概念と分析測定基準を指定するとき、私たちが必然的に簡素化仮定をするつもりであることに注意してください。 これらの概念の重要な役割は当然のことの測定基準に関連しているインターネットコンポーネントの特性を抜き取ることです。 判断が、仮定を1のためのモデルとメートル法の努力がちょっと設計するその偏見にするのを避けるのに必要です。
{Comment: for example, routers might not use tail-drop, even though
tail-drop might be easier to model analytically.}
コメントしてください: 例えばテール低下は分析的にモデル化するのが、より簡単であるかもしれませんが、どんな使用もテールで落とさないルータ力
Finally, note that different elements of the A-frame might well make different simplifying assumptions. For example, the abstraction of a router used to further the definition of path delay might treat the router's packet queue as a single FIFO queue, but the abstraction of
最終的に、A-フレームの異なった要素がたぶん異なった簡素化仮定をするだろうことに注意してください。 例えば、ルータの抽象化は以前はよく遅れがしかし、ただ一つの先入れ先出し待ち行列、抽象化としてのルータのパケット待ち行列を扱うかもしれない経路の定義を促進していました。
Paxson, et. al. Informational [Page 10] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[10ページ]のRFC2330枠組み
a router used to further the definition of the handling of an RSVP- enabled packet might treat the router's packet queue as supporting bounded delay -- a contradictory assumption. This is not to say that we make contradictory assumptions at the same time, but that two different parts of our work might refine the simpler base concept in two divergent ways for different purposes.
RSVPの可能にされたパケットの取り扱いの定義を促進するのに使用されるルータは境界がある遅れを支持するとしてルータのパケット待ち行列を扱うかもしれません--相容れない仮定。 これは、私たちが同時に、相容れない仮定をしますが、私たちの仕事の2つの異なった部品が異なる役割のための2つの分岐している方法で、より簡単なベース概念を洗練するかもしれないと言わないためのものです。
{Comment: in more mathematical terms, we would say that the A-frame
taken as a whole need not be consistent; but the set of particular
A-frame elements used to define a particular metric must be.}
コメントしてください: たとえば、より数学の期間、私たちがそうする全体で取られたA-フレームは一貫している必要はありません; しかしメートル法で事項を定義するのに使用される特定のA-フレーム要素のセットがそうであるに違いないコネ
8. Empirically Specified Metrics
8. 経験して指定された測定基準
There are useful performance and reliability metrics that do not fit so neatly into the A-frame, usually because the A-frame lacks the detail or power for dealing with them. For example, "the best flow capacity achievable along a path using an RFC-2001-compliant TCP" would be good to be able to measure, but we have no analytical framework of sufficient richness to allow us to cast that flow capacity as an analytical metric.
A-フレームにあまりにきちんと収まらない役に立つ性能と信頼性の測定基準があります、通常、A-フレームがそれらに対処するための詳細かパワーを欠いているので。 例えば、「経路使用に沿って達成可能な最も良い生産能力、RFC2001対応する、TCP、」、測定できるように良いでしょうが、私たちが私たちがその生産能力を投じるのを許容できるくらいの豊かどんな分析枠組みも持っていない、分析、メートル法です。
These notions can still be well specified by instead describing a reference methodology for measuring them.
それらを測定するために代わりに参照方法論について説明することによって、まだこれらの概念をよく指定できます。
Such a metric will be called an 'empirically specified metric', or more simply, an empirical metric.
あれほどaメートル法、 より単に'メートル法で経験して指定されています'と呼ばれる、実証的である、メートル法です。
Such empirical metrics should have three properties:
そのような実証的な測定基準には、3つの特性があるべきです:
+ we should have a clear definition for each in terms of Internet
components,
+ we should have at least one effective means to measure them, and
+ to the extent possible, we should have an (necessarily incomplete)
understanding of the metric in terms of the A-frame so that we can
use our measurements to reason about the performance and
reliability of A-frame components and of aggregations of A-frame
components.
+ 私たちには、インターネットコンポーネントに関してそれぞれのための明確な定義があるべきであり、+ 私たちでは、可能な範囲内でそれら、および+を測定する少なくとも1つの効果的な手段があるべきであり、私たちは、A-フレームの部品とA-フレームの部品の集合の性能と信頼性に関して推論するのに私たちの測定を使用できるようにA-フレームに関するメートル法の(必ず不完全)の理解を持つべきです。
Paxson, et. al. Informational [Page 11] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[11ページ]のRFC2330枠組み
9. Two Forms of Composition
9. 2つの形式の構成
9.1. Spatial Composition of Metrics
9.1. 測定基準の空間的な構成
In some cases, it may be realistic and useful to define metrics in such a fashion that they exhibit spatial composition.
いくつかの場合、空間的な構成を示すくらいのファッションで測定基準を定義するのは、現実的であって、役に立つかもしれません。
By spatial composition, we mean a characteristic of some path metrics, in which the metric as applied to a (complete) path can also be defined for various subpaths, and in which the appropriate A-frame concepts for the metric suggest useful relationships between the metric applied to these various subpaths (including the complete path, the various cloud subpaths of a given path digest, and even single routers along the path). The effectiveness of spatial composition depends:
空間的な構成で、私たちはいくつかの経路測定基準の特性を言っています(完全な経路、与えられた経路ダイジェストの様々な雲の「副-経路」、および経路に沿ったただ一つのルータさえ含んでいて)。(また様々な「副-経路」のために(完全)の経路への適用されるとしてのメートル法を定義できて、メートル法のための適切なA-フレーム概念は、メートル法の間の役に立つ関係がこれらの様々な「副-経路」に適用されたと測定基準で示唆します)。 空間的な構成の有効性を依存します:
+ on the usefulness in analysis of these relationships as applied to
the relevant A-frame components, and
+ on the practical use of the corresponding relationships as applied
to metrics and to measurement methodologies.
関連A-フレームの部品への適用されるとしてのこれらの関係の分析、および測定基準と、そして、測定方法論への適用されるとしての対応する関係の実用の+の有用性の+。
{Comment: for example, consider some metric for delay of a 100-byte
packet across a path P, and consider further a path digest <h0, e1,
C1, ..., en, hn> of P. The definition of such a metric might include
a conjecture that the delay across P is very nearly the sum of the
corresponding metric across the exchanges (ei) and clouds (Ci) of the
given path digest. The definition would further include a note on
how a corresponding relation applies to relevant A-frame components,
both for the path P and for the exchanges and clouds of the path
digest.}
{コメント: 例えば、100バイトのパケットの遅れにおいて、何かが経路Pの向こう側にメートル法であると考えてください、そして、経路ダイジェストが<h0であるとさらに考えてください、e1、C1…, アン、P. そのようなPの向こう側の遅れが交換(ei)の向こう側のメートル法の対応の合計であることでメートル法の力のインクルードa推測の定義のhn>と当然のことの経路の雲(Ci)は読みこなされます。 定義はさらに対応する関係が経路ダイジェストの関連A-フレームの部品、経路P、交換、および雲のためにどう申し込まれるかに関する注を含んでいるでしょう。}
When the definition of a metric includes a conjecture that the metric across the path is related to the metric across the subpaths of the path, that conjecture constitutes a claim that the metric exhibits spatial composition. The definition should then include:
aメートル法の定義が経路の向こう側のメートル法が経路の「副-経路」の向こう側のメートル法に関連するという推測を含んでいると、その推測はメートル法が空間的な構成を示すというクレームを構成します。 そして、定義は以下を含むべきです。
Paxson, et. al. Informational [Page 12] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[12ページ]のRFC2330枠組み
+ the specific conjecture applied to the metric,
+ a justification of the practical utility of the composition in
terms of making accurate measurements of the metric on the path,
+ a justification of the usefulness of the composition in terms of
making analysis of the path using A-frame concepts more effective,
and
+ an analysis of how the conjecture could be incorrect.
+ メートル法に適用された、特定の推測、+ 経路におけるメートル法の正確な寸法をすることに関する構成の実際的なユーティリティの正当化、+ A-フレーム概念を使用する経路の分析をより効果的にすることに関する構成の有用性の正当化、および+ 推測がどう不正確であるかもしれないかに関する分析。
9.2. Temporal Composition of Formal Models and Empirical Metrics
9.2. 形式モデルと実証的な測定基準の時の構成
In some cases, it may be realistic and useful to define metrics in such a fashion that they exhibit temporal composition.
いくつかの場合、時の構成を示すくらいのファッションで測定基準を定義するのは、現実的であって、役に立つかもしれません。
By temporal composition, we mean a characteristic of some path metric, in which the metric as applied to a path at a given time T is also defined for various times t0 < t1 < ... < tn < T, and in which the appropriate A-frame concepts for the metric suggests useful relationships between the metric applied at times t0, ..., tn and the metric applied at time T. The effectiveness of temporal composition depends:
時の構成で、私たちはメートル法の、そして、また、様々な回のt0<t1<のために与えられた時間Tの経路への適用されるとしてのメートル法がどれであるかで定義された何らかの経路の特性を言っています… 時には、<tn<Tと適切がどれのために概念をAで縁どっているかでメートル法がメートル法の間の役に立つ関係を示すかt0を適用しました…, tnでメートル法は時の構成の有効性を依存する時代T.に適用されました:
+ on the usefulness in analysis of these relationships as applied to
the relevant A-frame components, and
+ on the practical use of the corresponding relationships as applied
to metrics and to measurement methodologies.
関連A-フレームの部品への適用されるとしてのこれらの関係の分析、および測定基準と、そして、測定方法論への適用されるとしての対応する関係の実用の+の有用性の+。
{Comment: for example, consider a metric for the expected flow
capacity across a path P during the five-minute period surrounding
the time T, and suppose further that we have the corresponding values
for each of the four previous five-minute periods t0, t1, t2, and t3.
The definition of such a metric might include a conjecture that the
flow capacity at time T can be estimated from a certain kind of
extrapolation from the values of t0, ..., t3. The definition would
further include a note on how a corresponding relation applies to
relevant A-frame components.
コメントしてください; 例えば、時間Tを囲みながら、期待している生産能力において、aが5分の期間、経路Pの向こう側にメートル法であると考えてください、そして、それぞれの前の4 5分の授業時間のt0、t1、t2、およびt3の間私たちには換算値があるとさらに仮定してください; … ある種類の推定からt0の値から時間Tの生産能力を見積もることができるくらいのメートル法の力のインクルードa推測の定義、t3定義はさらに対応する関係がどう関連A-フレームの部品に適用されるかに関する注を含んでいるでしょう。
Note: any (spatial or temporal) compositions involving flow capacity are likely to be subtle, and temporal compositions are generally more subtle than spatial compositions, so the reader should understand that the foregoing example is intentionally naive.}
以下に注意してください。 生産能力にかかわるどんな(空間的であるか時)の構成も微妙である傾向があり、時の構成が空間的な構成より一般に微妙であるので、読者は、以上の例が故意にナイーブであることを理解するべきです。
When the definition of a metric includes a conjecture that the metric across the path at a given time T is related to the metric across the path for a set of other times, that conjecture constitutes a claim that the metric exhibits temporal composition. The definition should then include:
aメートル法の定義が当然のことの時Tの経路の向こう側のメートル法が他の回の1セットのための経路の向こう側のメートル法に関連するという推測を含んでいると、その推測はメートル法が時の構成を示すというクレームを構成します。 そして、定義は以下を含むべきです。
Paxson, et. al. Informational [Page 13] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[13ページ]のRFC2330枠組み
+ the specific conjecture applied to the metric,
+ a justification of the practical utility of the composition in
terms of making accurate measurements of the metric on the path,
and
+ a justification of the usefulness of the composition in terms of
making analysis of the path using A-frame concepts more effective.
+ メートル法に適用された、特定の推測、+ 経路におけるメートル法の正確な寸法をすることに関する構成の実際的なユーティリティの正当化、および+ A-フレーム概念を使用する経路の分析をより効果的にすることに関する構成の有用性の正当化。
10. Issues related to Time
10. Timeに関連する問題
10.1. Clock Issues
10.1. 時計問題
Measurements of time lie at the heart of many Internet metrics. Because of this, it will often be crucial when designing a methodology for measuring a metric to understand the different types of errors and uncertainties introduced by imperfect clocks. In this section we define terminology for discussing the characteristics of clocks and touch upon related measurement issues which need to be addressed by any sound methodology.
時間の測定値が多くのインターネット測定基準の心にあります。 これのために、不完全な時計によって導入された異なったタイプの誤りと不明確なことを理解するためにはメートル法のaを測定するように方法論を設計するとき、それはしばしば重要になるでしょう。 このセクションで、私たちは、どんな音の方法論によっても記述される必要がある関連する測定問題で時計と接触の特性について議論するために用語を定義します。
The Network Time Protocol (NTP; RFC 1305) defines a nomenclature for discussing clock characteristics, which we will also use when appropriate [Mi92]. The main goal of NTP is to provide accurate timekeeping over fairly long time scales, such as minutes to days, while for measurement purposes often what is more important is short-term accuracy, between the beginning of the measurement and the end, or over the course of gathering a body of measurements (a sample). This difference in goals sometimes leads to different definitions of terminology as well, as discussed below.
Network Timeプロトコル(NTP; RFC1305)はまた、適切であるときに私たちが使用するつもりである時計の特性[Mi92]について議論するための用語体系を定義します。 NTPの第一目的は正確な時間保持をかなり長いタイムスケールの上提供することになっています、数分から何日なども、しばしばより重要なことが測定目的のための測定の始まりと終わりか、測定値のボディーを集める過程の上の短期的な精度(サンプル)ですが。 目標のこの違いは以下で議論するとして時々また、用語の異なった定義につながります。
To begin, we define a clock's "offset" at a particular moment as the difference between the time reported by the clock and the "true" time as defined by UTC. If the clock reports a time Tc and the true time is Tt, then the clock's offset is Tc - Tt.
始まるように、私たちは特定の瞬間に時計によって報告された時間とUTCによって定義される「本当」の時間の違いと時計の「オフセット」を定義します。 時計がTcと真時がTtである時に報告するなら、時計のオフセットはTcです--Tt。
We will refer to a clock as "accurate" at a particular moment if the clock's offset is zero, and more generally a clock's "accuracy" is how close the absolute value of the offset is to zero. For NTP, accuracy also includes a notion of the frequency of the clock; for our purposes, we instead incorporate this notion into that of "skew", because we define accuracy in terms of a single moment in time rather than over an interval of time.
私たちは時計のオフセットがゼロであるなら特定の瞬間「正確である」と時計を呼ぶつもりです、そして、より一般に時計の「精度」はゼロにはオフセットの絶対値がどれくらい近くにあるかということです。 また、NTPに関しては、精度は時計の頻度の概念を含んでいます。 目的のために、私たちは代わりに「斜行」のものにこの概念を組み入れます、私たちが時間の間隔の間というよりむしろ時間内にの単一の瞬間に関して精度を定義するので。
A clock's "skew" at a particular moment is the frequency difference (first derivative of its offset with respect to true time) between the clock and true time.
時計の特定の瞬間での「斜行」は時計と真時の頻度差(真時に関するオフセットの一次導関数)です。
Paxson, et. al. Informational [Page 14] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[14ページ]のRFC2330枠組み
As noted in RFC 1305, real clocks exhibit some variation in skew. That is, the second derivative of the clock's offset with respect to true time is generally non-zero. In keeping with RFC 1305, we define this quantity as the clock's "drift".
RFC1305に述べられるように、実際の時計は斜行の何らかの変化を示します。 一般に、すなわち、真時に関して相殺された時計の二次導関数は非ゼロに合わせます。 RFC1305と共に保つ際に、私たちは時計の「ドリフト」とこの量を定義します。
A clock's "resolution" is the smallest unit by which the clock's time is updated. It gives a lower bound on the clock's uncertainty. (Note that clocks can have very fine resolutions and yet be wildly inaccurate.) Resolution is defined in terms of seconds. However, resolution is relative to the clock's reported time and not to true time, so for example a resolution of 10 ms only means that the clock updates its notion of time in 0.01 second increments, not that this is the true amount of time between updates.
時計の「解決」は時計の時間がアップデートされる最小単位です。 それは時計の不確実性で下界を与えます。 (時計が非常によい解決を持っていますが、むやみやたらに不正確である場合があることに注意してください。) 解決は秒で定義されます。 しかしながら、解決は真時の間、あるのではなく、時計の報告された時間に比例していて、したがって、例えば、10msの決議は、時計が0.01の2番目の増分で時間の概念をアップデートすることを意味するだけであり、これはアップデートの間の本当の時間であるというわけではありません。
{Comment: Systems differ on how an application interface to the clock
reports the time on subsequent calls during which the clock has not
advanced. Some systems simply return the same unchanged time as
given for previous calls. Others may add a small increment to the
reported time to maintain monotone-increasing timestamps. For
systems that do the latter, we do *not* consider these small
increments when defining the clock's resolution. They are instead an
impediment to assessing the clock's resolution, since a natural
method for doing so is to repeatedly query the clock to determine the
smallest non-zero difference in reported times.}
{コメント: システムは時計へのアプリケーション・インターフェースがどう時計が進んでいないその後の呼び出しの時間を報告するかについて異なる意見をもちます。 いくつかのシステムが同変わりのない時に前の呼び出しのために与えるように単に戻ります。 他のものは単調増加タイムスタンプを維持する報告された時間にわずかな増分を加えるかもしれません。 後者をするシステムのために、私たちは時計の解決を定義するとき*でないのがこれらのわずかな増分であると考える*をします。 それらは代わりに時計の解決を評価する障害です、そうするための自然な方法が報告された回の最も小さい非ゼロ差を決定するために繰り返して時計について質問することであるので。}
It is expected that a clock's resolution changes only rarely (for example, due to a hardware upgrade).
時計の解決がめったに(例えばハードウェアアップグレードのため)だけ変化しないと予想されます。
There are a number of interesting metrics for which some natural measurement methodologies involve comparing times reported by two different clocks. An example is one-way packet delay [AK97]. Here, the time required for a packet to travel through the network is measured by comparing the time reported by a clock at one end of the packet's path, corresponding to when the packet first entered the network, with the time reported by a clock at the other end of the path, corresponding to when the packet finished traversing the network.
いくつかの自然な測定方法論が2個の異なった時計によって報告された回を比較することを伴う多くのおもしろい測定基準があります。 例は片道パケット遅れ[AK97]です。 ここで、パケットがネットワークを通って移動するのに必要である時間はパケットの経路の片端の時計で報告された時間を比較することによって、測定されます、パケットが最初にネットワークに入った時に対応しています、経路のもう一方の時計で報告される時間端で、パケットがネットワークを横断し終えた時に対応しています。
We are thus also interested in terminology for describing how two clocks C1 and C2 compare. To do so, we introduce terms related to those above in which the notion of "true time" is replaced by the time as reported by clock C1. For example, clock C2's offset relative to C1 at a particular moment is Tc2 - Tc1, the instantaneous difference in time reported by C2 and C1. To disambiguate between the use of the terms to compare two clocks versus the use of the terms to compare to true time, we will in the former case use the phrase "relative". So the offset defined earlier in this paragraph is the "relative offset" between C2 and C1.
また、私たちはこのようにして2がC1の時間を計って、C2がどう比較するかを説明するための用語に興味を持っています。 そうするために、私たちは時計C1によって報告されるように「真時」の概念が取り替えられる上であることのそれらに関連する用語を紹介します。 例えば、特定の瞬間のC1に比例した時計C2のオフセットはTc2です--Tc1(時間内にC2とC1によって報告された瞬時に起こっている違い)。 間に真時にたとえる用語の使用に対して2個の時計を比較するために用語の使用のあいまいさを除くために、私たちは前のケース使用で「親類」という句を望んでいます。 それで、このパラグラフで、より早く定義されたオフセットはC2とC1の間の「相対的なオフセット」です。
Paxson, et. al. Informational [Page 15] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[15ページ]のRFC2330枠組み
When comparing clocks, the analog of "resolution" is not "relative resolution", but instead "joint resolution", which is the sum of the resolutions of C1 and C2. The joint resolution then indicates a conservative lower bound on the accuracy of any time intervals computed by subtracting timestamps generated by one clock from those generated by the other.
時計を比較するとき、「解決」のアナログは「相対的な解決」ではなく代わりにC1とC2の解決の合計である「共同決議」です。 そして、共同決議は1個の時計でもう片方で発生するものから発生するタイムスタンプを引き算することによって計算されたどんな時間間隔の精度でも保守的な下界を示します。
If two clocks are "accurate" with respect to one another (their relative offset is zero), we will refer to the pair of clocks as "synchronized". Note that clocks can be highly synchronized yet arbitrarily inaccurate in terms of how well they tell true time. This point is important because for many Internet measurements, synchronization between two clocks is more important than the accuracy of the clocks. The is somewhat true of skew, too: as long as the absolute skew is not too great, then minimal relative skew is more important, as it can induce systematic trends in packet transit times measured by comparing timestamps produced by the two clocks.
2個の時計がお互いに関して「正確である」なら(彼らの相対的なオフセットはゼロです)、私たちは「連動する」ように時計の組を参照するつもりです。 時計が彼らが真時をどれくらいよく言うかに任意にまだ不正確な状態で非常に連動できることに注意してください。 2個の時計の間の同期が時計の精度より多くのインターネット測定値に関して重要であるので、このポイントは重要です。 また、斜行に関していくらか本当です: それほど大きくない限り、次に、最小量の相対的な斜行は、より重要です、2個の時計によって作り出されたタイムスタンプを比較することによって測定されたパケットトランジット回数のときに系統的な傾向を引き起こすことができるとき。
These distinctions arise because for Internet measurement what is often most important are differences in time as computed by comparing the output of two clocks. The process of computing the difference removes any error due to clock inaccuracies with respect to true time; but it is crucial that the differences themselves accurately reflect differences in true time.
しばしば最も重要なことがインターネット測定のための時間内に2個の時計の出力を比較することによって計算されるように違いであるのでこれらの区別は起こります。 違いを計算する過程は真時に関して時計誤りによるどんな誤りも取り除きます。 しかし、違い自体が正しい調子で正確に違いを反映するのは、重要です。
Measurement methodologies will often begin with the step of assuring
that two clocks are synchronized and have minimal skew and drift.
{Comment: An effective way to assure these conditions (and also clock
accuracy) is by using clocks that derive their notion of time from an
external source, rather than only the host computer's clock. (These
latter are often subject to large errors.) It is further preferable
that the clocks directly derive their time, for example by having
immediate access to a GPS (Global Positioning System) unit.}
測定方法論は、2個の時計が連動することを保証するステップでしばしば始まって、最小量の斜行とドリフトを持つでしょう。 {コメント: これらの条件(また、精度の時間を計る)を保証する効果的な方法は時間に関する彼らの概念にホストコンピュータの時計だけよりむしろ外部電源に由来している時計を使用することです。 (これらの後者はしばしば大きい誤りを被りやすいです。) 時計が直接彼らの時間を引き出すのは、さらに望ましいです、例えば、GPS(全地球測位システム)ユニットに即座のアクセスを持っていることによって。}
Two important concerns arise if the clocks indirectly derive their time using a network time synchronization protocol such as NTP:
時計がNTPなどのネットワーク時間同期化プロトコルを使用することで間接的に彼らの時間を引き出すなら、2回の重要な関心が起こります:
+ First, NTP's accuracy depends in part on the properties
(particularly delay) of the Internet paths used by the NTP peers,
and these might be exactly the properties that we wish to measure,
so it would be unsound to use NTP to calibrate such measurements.
+ Second, NTP focuses on clock accuracy, which can come at the
expense of short-term clock skew and drift. For example, when a
host's clock is indirectly synchronized to a time source, if the
synchronization intervals occur infrequently, then the host will
sometimes be faced with the problem of how to adjust its current,
incorrect time, Ti, with a considerably different, more accurate
time it has just learned, Ta. Two general ways in which this is
+ 最初に、NTPの精度はインターネット経路の(特に遅れ)がまさに較正するのにNTPを使用するのが不健全であるように測定したいと思う特性がそのような測定値であったならNTP同輩、およびこれらの力で使用した所有地に一部依存します。 2番目に、NTPが短期的な時計斜行とドリフトを犠牲にして来ることができる時計精度に焦点を合わせる+。 ホストの時計が間接的に時間ソースに連動するとき、例えば、同期間隔がまれに生じると、ホストは時々どう現在の、そして、不正確な時間を調整するかに関する問題に直面するでしょう、Ti、それがちょうど学んだかなり異なって、より正確な時間で、Ta。 これがそうである2つの一般的な方法
Paxson, et. al. Informational [Page 16] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[16ページ]のRFC2330枠組み
done are to either immediately set the current time to Ta, or to
adjust the local clock's update frequency (hence, its skew) so
that at some point in the future the local time Ti' will agree
with the more accurate time Ta'. The first mechanism introduces
discontinuities and can also violate common assumptions that
timestamps are monotone increasing. If the host's clock is set
backward in time, sometimes this can be easily detected. If the
clock is set forward in time, this can be harder to detect. The
skew induced by the second mechanism can lead to considerable
inaccuracies when computing differences in time, as discussed
above.
'する、現地時間Tiが未来の何らかのポイントで'より正確な時間Taに同意する'ように、すぐに、現在の時間をTaに設定することになっているか、または地方の時計のアップデート頻度(したがって、斜行)を調整することになっています。 最初のメカニズムは、不連続を導入して、また、タイムスタンプが単調増加であるという一般的な想定に違反できます。 ホストの時計が時間内に後方に設定されるなら、時々、容易にこれを検出できます。 時計が時間内に前方に設定されるなら、これは検出するのが、より困難である場合があります。 時間内に違いを計算するとき、2番目のメカニズムによって引き起こされた斜行は上で議論するようにかなりの誤りにつながることができます。
To illustrate why skew is a crucial concern, consider samples of one-way delays between two Internet hosts made at one minute intervals. The true transmission delay between the hosts might plausibly be on the order of 50 ms for a transcontinental path. If the skew between the two clocks is 0.01%, that is, 1 part in 10,000, then after 10 minutes of observation the error introduced into the measurement is 60 ms. Unless corrected, this error is enough to completely wipe out any accuracy in the transmission delay measurement. Finally, we note that assessing skew errors between unsynchronized network clocks is an open research area. (See [Pa97] for a discussion of detecting and compensating for these sorts of errors.) This shortcoming makes use of a solid, independent clock source such as GPS especially desirable.
斜行がなぜ重要な関心であるかを例証するには、1分の間隔を置いて作られた2人のインターネット・ホストの間の片道遅れのサンプルを考えてください。 大陸横断の経路への50msの注文にはホストの間の本当のトランスミッション遅れがもっともらしくあるかもしれません。 2個の時計の間の斜行が0.01%、すなわち、1万で1つの部分であるなら、誤りが測定に取り入れた観測の10分が60になったとき、原稿Unlessが修正した後この誤りは、トランスミッション遅れ測定でどんな精度も完全に破壊するために十分です。 最終的に、私たちは、非連動しているネットワーク時計の間の斜行誤りを評価するのが、開いている研究領域であることに注意します。 (これらの種類の誤りを検出して、補う議論に関して[Pa97]を見てください。) この短所で、GPSなどの固体の、そして、独立している時計源の使用は特に望ましくなります。
10.2. The Notion of "Wire Time"
10.2. 「ワイヤ時間」の概念
Internet measurement is often complicated by the use of Internet hosts themselves to perform the measurement. These hosts can introduce delays, bottlenecks, and the like that are due to hardware or operating system effects and have nothing to do with the network behavior we would like to measure. This problem is particularly acute when timestamping of network events occurs at the application level.
インターネット測定は、測定を実行するためにインターネット・ホストの使用で自分たちでしばしば複雑にされます。 これらのホストは、ハードウェアかオペレーティングシステム効果のためである遅れ、ボトルネック、および同様のものを導入して、測定したいと思うネットワークの振舞いと関係ないことができます。 ネットワークイベントのtimestampingがアプリケーションレベルで起こるとき、この問題は特に鋭いです。
In order to provide a general way of talking about these effects, we introduce two notions of "wire time". These notions are only defined in terms of an Internet host H observing an Internet link L at a particular location:
これらの効果に関して話す一般的な方法を提供するために、私たちは「ワイヤ時間」の2つの概念を紹介します。 インターネットが特定の位置でLをリンクするのを観測しながら、これらの概念はインターネット・ホストHに関して定義されるだけです:
+ For a given packet P, the 'wire arrival time' of P at H on L is
the first time T at which any bit of P has appeared at H's
observational position on L.
与えられたパケットPのための+、LのHのPの'ワイヤ到着時間'はPのどんなビットもLにHの観察の位置に現れた初めてのTです。
Paxson, et. al. Informational [Page 17] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[17ページ]のRFC2330枠組み
+ For a given packet P, the 'wire exit time' of P at H on L is the
first time T at which all the bits of P have appeared at H's
observational position on L.
与えられたパケットPのための+、LのHのPの'ワイヤエキジット時間'はPのすべてのビットがLにHの観察の位置に現れた初めてのTです。
Note that intrinsic to the definition is the notion of where on the link we are observing. This distinction is important because for large-latency links, we may obtain very different times depending on exactly where we are observing the link. We could allow the observational position to be an arbitrary location along the link; however, we define it to be in terms of an Internet host because we anticipate in practice that, for IPPM metrics, all such timing will be constrained to be performed by Internet hosts, rather than specialized hardware devices that might be able to monitor a link at locations where a host cannot. This definition also takes care of the problem of links that are comprised of multiple physical channels. Because these multiple channels are not visible at the IP layer, they cannot be individually observed in terms of the above definitions.
定義へのそんなに本質的な注意はリンクの上では、私たちが見ているところに関する概念です。 私たちがちょうど私たちがリンクを観測しているところによる非常にいろいろな時間を大きい潜在リンクに得るかもしれないので、この区別は重要です。 私たちはリンクに沿って任意の位置である観察の立場を許すことができました。 しかしながら、私たちは、私たちが、そのようなすべてのタイミングがホストがそうすることができない位置でリンクをモニターできるかもしれないハードウェアデバイスを専門にするよりインターネット・ホストによってむしろ実行されるのがIPPM測定基準において抑制されると実際には予期するのでインターネット・ホストに関しているようにそれを定義します。 また、この定義は複数の物理的なチャンネルから成るリンクの問題の世話をします。 これらの複数のチャンネルがIP層で目に見えないので、上の定義で個別に彼らを観測できません。
It is possible, though one hopes uncommon, that a packet P might make multiple trips over a particular link L, due to a forwarding loop. These trips might even overlap, depending on the link technology. Whenever this occurs, we define a separate wire time associated with each instance of P seen at H's position on the link. This definition is worth making because it serves as a reminder that notions like *the* unique time a packet passes a point in the Internet are inherently slippery.
人は珍しい状態で望んでいますが、パケットPが特定のリンクの上の複数の旅行をLにするのは、可能です、推進輪のため。 リンク技術によって、これらの旅行は重なりさえするかもしれません。 これが起こるときはいつも、私たちはリンクの上のHの位置で見られるPの各例に関連している別々のワイヤ時間を定義します。 *パケットがインターネットでポイントを通過する*ユニークな時が本来滑りやすいように思い出させるものとしてその概念に役立つので、この定義は作る価値があります。
The term wire time has historically been used to loosely denote the time at which a packet appeared on a link, without exactly specifying whether this refers to the first bit, the last bit, or some other consideration. This informal definition is generally already very useful, as it is usually used to make a distinction between when the packet's propagation delays begin and cease to be due to the network rather than the endpoint hosts.
ワイヤ時間用語は緩く、パケットがリンクの上に現れた時を指示するのに歴史的に使用されました、これが最初のビット、最後のビット、またはある他の考慮を示すかどうかまさに指定しない。 一般に、この非公式な定義は既に非常に役に立ちます、パケットの伝播遅延が始まる時の区別をして、終点ホストよりむしろネットワークのためであることをやめるのが通常使用されているとき。
When appropriate, metrics should be defined in terms of wire times rather than host endpoint times, so that the metric's definition highlights the issue of separating delays due to the host from those due to the network.
適切であるときに、測定基準はホスト終点回数よりむしろワイヤ回に関して定義されるべきです、メートル法によるネットワークによる分離の問題がホストのためそれらから遅らせる定義ハイライトになるように。
We note that one potential difficulty when dealing with wire times concerns IP fragments. It may be the case that, due to fragmentation, only a portion of a particular packet passes by H's location. Such fragments are themselves legitimate packets and have well-defined wire times associated with them; but the larger IP packet corresponding to their aggregate may not.
私たちは、ワイヤ回に対処するとき、1つの潜在的困難がIP断片に関係があることに注意します。 特定のパケットの一部だけが断片化のためHの位置のそばで終わるのは、事実であるかもしれません。 そのような断片は、自分たちで正統のパケットであり、それらに関連している明確なワイヤ時を過します。 しかし、それらの集合に対応するより大きいIPパケットはそうしないかもしれません。
Paxson, et. al. Informational [Page 18] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[18ページ]のRFC2330枠組み
We also note that these notions have not, to our knowledge, been previously defined in exact terms for Internet traffic. Consequently, we may find with experience that these definitions require some adjustment in the future.
また、私たちは、私たちが知っている限り、これらの概念が以前にインターネットトラフィックのための正確な用語で定義されていないことに注意します。 その結果、私たちは、経験でこれらの定義が将来何らかの調整を必要とするのがわかったかもしれません。
{Comment: It can sometimes be difficult to measure wire times. One
technique is to use a packet filter to monitor traffic on a link.
The architecture of these filters often attempts to associate with
each packet a timestamp as close to the wire time as possible. We
note however that one common source of error is to run the packet
filter on one of the endpoint hosts. In this case, it has been
observed that some packet filters receive for some packets timestamps
corresponding to when the packet was *scheduled* to be injected into
the network, rather than when it actually was *sent* out onto the
network (wire time). There can be a substantial difference between
these two times. A technique for dealing with this problem is to run
the packet filter on a separate host that passively monitors the
given link. This can be problematic however for some link
technologies. See [Pa97] for a discussion of the sorts of errors
packet filters can exhibit. Finally, we note that packet filters
will often only capture the first fragment of a fragmented IP packet,
due to the use of filtering on fields in the IP and transport
protocol headers. As we generally desire our measurement
methodologies to avoid the complexity of creating fragmented traffic,
one strategy for dealing with their presence as detected by a packet
filter is to flag that the measured traffic has an unusual form and
abandon further analysis of the packet timing.}
{コメント: ワイヤ回を測定するのは時々難しい場合があります。 1つのテクニックはリンクにおける交通をモニターするのにパケットフィルタを使用することです。 これらのフィルタの構造は、しばしば可能であるとしてのワイヤ時間の近くように各パケットにタイムスタンプを関連づけるのを試みます。 しかしながら、私たちは、誤りの1つの共通ソースが終点ホストのひとりでパケットフィルタを動かすことであることに注意します。 この場合、フィルタがパケットが*であった時に対応するいくつかのパケットタイムスタンプのために受けるあるパケットが、*がそれが実際に*ネットワーク(ワイヤ時間)への外に送られた*であった時よりむしろネットワークに注がれる計画をしたのが観測されました。 これらの2回の間には、かなりの違いがあることができます。 この問題に対処するためのテクニックは与えられたリンクを受け身にモニターする別々のホストの上でパケットフィルタを動かすことです。 しかしながら、いくつかのリンク技術に、これは問題が多い場合があります。 パケットフィルタが示すことができる誤りの種類の議論に関して[Pa97]を見てください。 最終的に、私たちは、パケットフィルタがしばしば断片化しているIPパケットの最初の断片を得るだけであることに注意します、フィールドでIPとトランスポート・プロトコルでヘッダーをフィルターにかけることの使用のため。 私たちが、私たちの測定方法論が断片化している交通を引き起こす複雑さを避けることを一般に望んでいるとき、パケットフィルタによって検出されるようにそれらの存在に対処するための1つの戦略はそれに旗を揚げさせるために、珍しいフォームと放棄が測定交通でパケットタイミングの分析を促進するということです。}
11. Singletons, Samples, and Statistics
11. 単独個体、サンプル、および統計
With experience we have found it useful to introduce a separation between three distinct -- yet related -- notions:
経験で、私たちは、3つの異なりましたが、関連する概念に分離を取り入れるのが役に立つのがわかりました:
+ By a 'singleton' metric, we refer to metrics that are, in a sense,
atomic. For example, a single instance of "bulk throughput
capacity" from one host to another might be defined as a singleton
metric, even though the instance involves measuring the timing of
a number of Internet packets.
+ By a 'sample' metric, we refer to metrics derived from a given
singleton metric by taking a number of distinct instances
together. For example, we might define a sample metric of one-way
delays from one host to another as an hour's worth of
measurements, each made at Poisson intervals with a mean spacing
of one second.
+、'単独個体'で、メートル法であり、私たちはある意味で原子である測定基準を示します。 例えば、1人のホストから別のホストまでの「大量の処理能力」のただ一つの例は単独個体とメートル法で定義されるかもしれません、例が、多くのインターネットパケットのタイミングを測定することを伴いますが。 a'サンプル'メートル法による+、私たちは多くの異なった例を一緒に取るのによるメートル法の当然のことの単独個体から得られた測定基準を示します。 例えば、私たちは1時間の測定値(1秒の意地悪なスペースでポアソン間隔を置いて作られたそれぞれ)の価値と片道遅れにおける1人のホストから別のホストまでのメートル法のサンプルを定義するかもしれません。
Paxson, et. al. Informational [Page 19] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[19ページ]のRFC2330枠組み
+ By a 'statistical' metric, we refer to metrics derived from a
given sample metric by computing some statistic of the values
defined by the singleton metric on the sample. For example, the
mean of all the one-way delay values on the sample given above
might be defined as a statistical metric.
a'統計的'メートル法による+、私たちはサンプルのメートル法の単独個体によって定義された値の何らかの統計値を計算するのによるメートル法の当然のことのサンプルから得られた測定基準を示します。 例えば、上に与えられたサンプルにおけるすべての片道遅れ値の平均はa統計的であるとメートル法で定義されるかもしれません。
By applying these notions of singleton, sample, and statistic in a consistent way, we will be able to reuse lessons learned about how to define samples and statistics on various metrics. The orthogonality among these three notions will thus make all our work more effective and more intelligible by the community.
一貫した方法で単独個体、サンプル、および統計値のこれらの概念を適用することによって、私たちはどう様々な測定基準におけるサンプルと統計を定義するかに関して学習されたレッスンを再利用できるでしょう。 これらの3つの概念の中の直交性で、その結果、私たちのすべての仕事が共同体で、より効果的でより明瞭になるでしょう。
In the remainder of this section, we will cover some topics in sampling and statistics that we believe will be important to a variety of metric definitions and measurement efforts.
このセクションの残りで、私たちは標本抽出、私たちがさまざまなメートル法の定義に重要になると信じている統計、および測定の努力におけるいくつかの話題をカバーするつもりです。
11.1. Methods of Collecting Samples
11.1. サンプルを集める方法
The main reason for collecting samples is to see what sort of variations and consistencies are present in the metric being measured. These variations might be with respect to different points in the Internet, or different measurement times. When assessing variations based on a sample, one generally makes an assumption that the sample is "unbiased", meaning that the process of collecting the measurements in the sample did not skew the sample so that it no longer accurately reflects the metric's variations and consistencies.
サンプルを集める主な理由はどういう変化と一貫性が測定されたメートル法の存在で存在しているかわかることです。 インターネット、またはいろいろな測定時間に、異なったポイントに関してこれらの変化があるかもしれません。 サンプルでの測定を集める過程がサンプルを歪曲しなかったのでもう正確にメートル法を反映しないことを意味するのは、サンプルに基づく変化を評価するとき、一般に、1つがサンプルが「不遍である」という仮定をして、変化と一貫性です。
One common way of collecting samples is to make measurements separated by fixed amounts of time: periodic sampling. Periodic sampling is particularly attractive because of its simplicity, but it suffers from two potential problems:
サンプルを集める1つの一般的な方法は時間の定額によって切り離された測定をすることです: 周期的な標本抽出。 周期的な標本抽出は簡単さのために特に魅力的ですが、2つの潜在的な問題に苦しみます:
+ If the metric being measured itself exhibits periodic behavior,
then there is a possibility that the sampling will observe only
part of the periodic behavior if the periods happen to agree
(either directly, or if one is a multiple of the other). Related
to this problem is the notion that periodic sampling can be easily
anticipated. Predictable sampling is susceptible to manipulation
if there are mechanisms by which a network component's behavior
can be temporarily changed such that the sampling only sees the
modified behavior.
+ The act of measurement can perturb what is being measured (for
example, injecting measurement traffic into a network alters the
congestion level of the network), and repeated periodic
perturbations can drive a network into a state of synchronization
(cf. [FJ94]), greatly magnifying what might individually be minor
effects.
+がそれ自体で測定されて、標本抽出が望んでいる可能性は周期行動を示して、次に、あるということであるメートル法であるなら期間がたまたま同意するなら周期行動の一部だけを観測する、(どちらか、直接、または1つがもう片方の倍数である、) この問題に関連されるのは、容易に周期的な標本抽出を予期できるという概念です。 標本抽出が一時ネットワーク要素の振舞いを変えることができるので変更された振舞いを見るだけであるメカニズムがあれば、予測できる標本抽出は操作に影響されやすいです。 + 測定の行為は測定されているものを混乱させることができます、そして、(例えば、測定交通をネットワークに注ぐと、ネットワークの混雑レベルは変更されます)繰り返された周期的な摂動は同期の状態にネットワークを追い込むことができます。(Cf。 [FJ94]), 個別に小さい方の効果であるかもしれないことを大いに拡大します。
Paxson, et. al. Informational [Page 20] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[20ページ]のRFC2330枠組み
A more sound approach is based on "random additive sampling": samples are separated by independent, randomly generated intervals that have a common statistical distribution G(t) [BM92]. The quality of this sampling depends on the distribution G(t). For example, if G(t) generates a constant value g with probability one, then the sampling reduces to periodic sampling with a period of g.
より健全なアプローチは「無作為の付加的な標本抽出」に基づいています: サンプルは一般的な統計的分布G(t)[BM92]を持っている独立していて、手当たりしだいに発生している間隔で切り離されます。 この標本抽出の品質は分配G(t)に依存します。 例えば、G(t)が確率1で恒常価値gを発生させるなら、標本抽出はgの期間がある周期的な標本抽出に減少します。
Random additive sampling gains significant advantages. In general, it avoids synchronization effects and yields an unbiased estimate of the property being sampled. The only significant drawbacks with it are:
無作為の付加的な標本抽出は重要な利点を獲得します。 一般に、それは抽出される特性の不偏推定値的に同期効果と利回りを避けます。 それがある唯一の重要な欠点は以下の通りです。
+ it complicates frequency-domain analysis, because the samples do
not occur at fixed intervals such as assumed by Fourier-transform
techniques; and
+ unless G(t) is the exponential distribution (see below), sampling
still remains somewhat predictable, as discussed for periodic
sampling above.
定期的にフーリエ変換のテクニックによって想定されるようにサンプルが現れないので、周波数領域分析を複雑にします。 そして、+、G(t)が指数分布(以下を見る)でないなら、標本抽出はまだいくらか予測できたままで残っています、周期的な標本抽出上と議論するように。
11.1.1. Poisson Sampling
11.1.1. ポアソンSampling
It can be proved that if G(t) is an exponential distribution with rate lambda, that is
それがG(t)がレートλがある指数分布であるなら、指数分布であると立証できます。
G(t) = 1 - exp(-lambda * t)
G(t)=1--exp(λ*t)
then the arrival of new samples *cannot* be predicted (and, again, the sampling is unbiased). Furthermore, the sampling is asymptotically unbiased even if the act of sampling affects the network's state. Such sampling is referred to as "Poisson sampling". It is not prone to inducing synchronization, it can be used to accurately collect measurements of periodic behavior, and it is not prone to manipulation by anticipating when new samples will occur.
次に、新規見本*の到着は予測できません。*予測されてください(一方、標本抽出は不遍です)。 その上、標本抽出の行為がネットワークの状態に影響しても、標本抽出は漸近的に不遍です。 そのような標本抽出は「ポアソン標本抽出」と呼ばれます。 それは同期を引き起こすことの傾向がありません、そして、周期行動の正確に料金先方払いの測定値にそれを使用できます、そして、操作に、新規見本が現れると予期することによって、傾向がありません。
Because of these valuable properties, we in general prefer that
samples of Internet measurements are gathered using Poisson sampling.
{Comment: We note, however, that there may be circumstances that
favor use of a different G(t). For example, the exponential
distribution is unbounded, so its use will on occasion generate
lengthy spaces between sampling times. We might instead desire to
bound the longest such interval to a maximum value dT, to speed the
convergence of the estimation derived from the sampling. This could
be done by using
これらの高価な財産のために、一般に、私たちは、インターネット測定値のサンプルがポアソン標本抽出を使用することで集められるのを好みます。 異なったG(t)の使用を支持してください。使用は時々、事情があるかもしれないという例えば、指数分布が限りないというしかしながら、: 私たちが注意するコメントによって標本抽出回の間の長い空間を発生させるでしょう。私たちは、標本抽出によって引き出している見積りの集合を促進するために代わりに最大の値のdTへのそのような最も長い間隔をバウンドに望むかもしれません。使用することによって、これができるでしょう。
G(t) = Unif(0, dT)
G(t)はUnifと等しいです。(0、dT)
Paxson, et. al. Informational [Page 21] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[21ページ]のRFC2330枠組み
that is, the uniform distribution between 0 and dT. This sampling, of course, becomes highly predictable if an interval of nearly length dT has elapsed without a sample occurring.}
すなわち、0とdTの間の一様分布。 ほとんど長さのdTの間隔がサンプル発生なしで経過したなら、この標本抽出はもちろん非常に予測できるようになります。
In its purest form, Poisson sampling is done by generating independent, exponentially distributed intervals and gathering a single measurement after each interval has elapsed. It can be shown that if starting at time T one performs Poisson sampling over an interval dT, during which a total of N measurements happen to be made, then those measurements will be uniformly distributed over the interval [T, T+dT]. So another way of conducting Poisson sampling is to pick dT and N and generate N random sampling times uniformly over the interval [T, T+dT]. The two approaches are equivalent, except if N and dT are externally known. In that case, the property of not being able to predict measurement times is weakened (the other properties still hold). The N/dT approach has an advantage that dealing with fixed values of N and dT can be simpler than dealing with a fixed lambda but variable numbers of measurements over variably-sized intervals.
最も純粋なフォームでは、独立していて、指数関数的に分配された間隔を発生させて、各間隔が経過した後にただ一つの測定を集めることによって、ポアソン標本抽出をします。 合計N測定値がたまたま得られるT1が間隔の間にdTを抽出しているポアソンを実行する時代に始まるとそれらの測定値が間隔[T、T+dT]の間一様に分配されるのを示すことができます。 それで、ポアソン標本抽出を行う別の方法は、間隔[T、T+dT]の間、dTとNを選んで、N無作為抽出法回を一様に発生させることです。 Nであるのを除いて、2つのアプローチが同等です、そして、dTは外部的に知られています。 その場合、測定時間を予測できない特性は弱められます(他の特性はまだ持ちこたえています)。 N/dTアプローチには、NとdTの一定の価値に対処して、変化しやすくサイズの間隔にわたって固定λにもかかわらず、可変数の測定に対処するより簡単である場合がある利点があります。
11.1.2. Geometric Sampling
11.1.2. 幾何学上標本抽出
Closely related to Poisson sampling is "geometric sampling", in which external events are measured with a fixed probability p. For example, one might capture all the packets over a link but only record the packet to a trace file if a randomly generated number uniformly distributed between 0 and 1 is less than a given p. Geometric sampling has the same properties of being unbiased and not predictable in advance as Poisson sampling, so if it fits a particular Internet measurement task, it too is sound. See [CPB93] for more discussion.
密接にポアソン標本抽出に関連されるのは、「幾何学上標本抽出」(外部の出来事は固定確率pで測定される)です。 例えば、人は、リンクの上にすべてのパケットを捕らえますが、pを考えて、一様に分配された0〜1の手当たりしだいに発生している数が1未満である場合にだけ跡のファイルにパケットを記録するかもしれません。 あらかじめ、幾何学上標本抽出にはポアソン標本抽出として不遍であって予測できないことの同じ特性があるので、特定のインターネット測定タスクに合うなら、も健全です。 より多くの議論に関して[CPB93]を見てください。
11.1.3. Generating Poisson Sampling Intervals
11.1.3. ポアソン標本抽出間隔を発生させます。
To generate Poisson sampling intervals, one first determines the rate lambda at which the singleton measurements will on average be made (e.g., for an average sampling interval of 30 seconds, we have lambda = 1/30, if the units of time are seconds). One then generates a series of exponentially-distributed (pseudo) random numbers E1, E2, ..., En. The first measurement is made at time E1, the next at time E1+E2, and so on.
ポアソンを発生させるように、間隔を抽出する1/1が単独個体測定が平均的にされるレートλを決定します(私たちは例えば、30秒の平均した標本抽出間隔の間、λが1/30との等しさにします、時間の単位が秒であるなら)。 次に、1つは一連の指数関数的に分配された(疑似な)乱数を1ユーロと、2ユーロ発生させます…, アン。 時間E1、時間の次で2 1+E E、などに最初の測定をします。
One technique for generating exponentially-distributed (pseudo) random numbers is based on the ability to generate U1, U2, ..., Un, (pseudo) random numbers that are uniformly distributed between 0 and 1. Many computers provide libraries that can do this. Given such
指数関数的に分配された(疑似な)乱数を発生させるための1つのテクニックがU1、U2を発生させる能力に基づいています…, 不-、一様に0と1の間に分配される(疑似な)乱数 多くのコンピュータがこれができるライブラリを提供します。 与えられたそのようなもの
Paxson, et. al. Informational [Page 22] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[22ページ]のRFC2330枠組み
Ui, to generate Ei one uses:
ウイ、穎娃1を発生させるのは以下を使用します。
Ei = -log(Ui) / lambda
穎娃はログ(ウイ)/λと等しいです。
where log(Ui) is the natural logarithm of Ui. {Comment: This
technique is an instance of the more general "inverse transform"
method for generating random numbers with a given distribution.}
ログ(ウイ)がウイの自然対数であるところ。 コメント: このテクニックは与えられた分配で乱数を発生させるための、より一般的な「逆さの変換」方法の例です。
Implementation details:
実現の詳細:
There are at least three different methods for approximating Poisson sampling, which we describe here as Methods 1 through 3. Method 1 is the easiest to implement and has the most error, and method 3 is the most difficult to implement and has the least error (potentially none).
ポアソン標本抽出に近似するための少なくとも3つの異なった方法があります。(私たちはここで方法をMethods1〜3と説明します)。 方法1が実行するのが最も簡単であり、最も多くの誤りを持っていて、方法3は、実行するのが最も難しく、最少の誤り(潜在的になにも)を持っています。
Method 1 is to proceed as follows:
方法1は以下の通り続くことになっています:
1. Generate E1 and wait that long. 2. Perform a measurement. 3. Generate E2 and wait that long. 4. Perform a measurement. 5. Generate E3 and wait that long. 6. Perform a measurement ...
1. 1Eを発生させてください、そして、そんなに長い間、待ってください。 2. 測定を実行してください。 3. 2Eを発生させてください、そして、そんなに長い間、待ってください。 4. 測定を実行してください。 5. 3Eを発生させてください、そして、そんなに長い間、待ってください。 6. 測定を実行してください…
The problem with this approach is that the "Perform a measurement" steps themselves take time, so the sampling is not done at times E1, E1+E2, etc., but rather at E1, E1+M1+E2, etc., where Mi is the amount of time required for the i'th measurement. If Mi is very small compared to 1/lambda then the potential error introduced by this technique is likewise small. As Mi becomes a non-negligible fraction of 1/lambda, the potential error increases.
このアプローチに関する問題がそのステップ自体が取る「測定を実行してください」時間であるので回1E、2 1+E Eなどにもかかわらず、1E、むしろ2 1+M1+E Eなどにおいて抽出しません、Miがi'th測定のための所要時間であるところで。 1/λと比べて、Miが非常に小さいなら、このテクニックで導入された潜在的誤りは同様に小さいです。 Miが1/λの非取るにたらない部分になるのに従って、潜在的誤りは増加します。
Method 2 attempts to correct this error by taking into account the amount of time required by the measurements (i.e., the Mi's) and adjusting the waiting intervals accordingly:
方法2は、測定値(すなわち、Miのもの)で所要時間を考慮に入れて、それに従って、待ち間隔を調整することによってこの誤りを修正するのを試みます:
1. Generate E1 and wait that long. 2. Perform a measurement and measure M1, the time it took to do so. 3. Generate E2 and wait for a time E2-M1. 4. Perform a measurement and measure M2 ..
1. 1Eを発生させてください、そして、そんなに長い間、待ってください。 2. 測定を実行してください、そして、M1、わざわざそれがそうした測定してください。 3. E2-M1を2E発生して、時間、待ってください。 4. 測定を実行してください、そして、M2を測定してください。
This approach works fine as long as E{i+1} >= Mi. But if E{i+1} < Mi
then it is impossible to wait the proper amount of time. (Note that
this case corresponds to needing to perform two measurements
simultaneously.)
E i+1>がマイルと等しい限り、このアプローチはきめ細かに働いています。 しかし、E i+1<Miであるなら、適切な時間を待つのは不可能です。 (同時に2つの測定を実行するのが必要に本件が対応することに注意してください。)
Paxson, et. al. Informational [Page 23] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[23ページ]のRFC2330枠組み
Method 3 is generating a schedule of measurement times E1, E1+E2, etc., and then sticking to it:
方法3は、それに測定時間のスケジュールを1ユーロと、2 1+Eユーロ発生させて、などと、次に、刺さることです:
1. Generate E1, E2, ..., En. 2. Compute measurement times T1, T2, ..., Tn, as Ti = E1 + ... + Ei. 3. Arrange that at times T1, T2, ..., Tn, a measurement is made.
1. 2E、1Eを発生させてください…, アン。 2. 測定回のT1、T2を計算してください…, Tiが1Eの+と等しいのでTn + 穎娃。 3. 回のT1、T2にそれを配置してください…, Tn、測定をします。
By allowing simultaneous measurements, Method 3 avoids the shortcomings of Methods 1 and 2. If, however, simultaneous measurements interfere with one another, then Method 3 does not gain any benefit and may actually prove worse than Methods 1 or 2.
同時の測定値を許容することによって、Method3はMethods1と2の短所を避けます。 しかしながら、同時の測定値がお互いを妨げるなら、Method3は、少しの利益も獲得しないで、実際にMethods1か2より悪いと判明するかもしれません。
For Internet phenomena, it is not known to what degree the inaccuracies of these methods are significant. If the Mi's are much less than 1/lambda, then any of the three should suffice. If the Mi's are less than 1/lambda but perhaps not greatly less, then Method 2 is preferred to Method 1. If simultaneous measurements do not interfere with one another, then Method 3 is preferred, though it can be considerably harder to implement.
インターネット現象に関しては、これらの方法の誤りが重要であることがどの程度に知られていないか。 Miのものがはるかに1未満/λであるなら、3つのもののいずれも十分であるべきです。 Miが1/λよりそれほど、しかし、恐らく大いにない少ないなら、Method2はMethod1より好まれます。 同時の測定値がお互いを妨げないなら、Method3は好まれます、実行するのがかなり困難である場合がありますが。
11.2. Self-Consistency
11.2. 自己一貫性
A fundamental requirement for a sound measurement methodology is that measurement be made using as few unconfirmed assumptions as possible. Experience has painfully shown how easy it is to make an (often implicit) assumption that turns out to be incorrect. An example is incorporating into a measurement the reading of a clock synchronized to a highly accurate source. It is easy to assume that the clock is therefore accurate; but due to software bugs, a loss of power in the source, or a loss of communication between the source and the clock, the clock could actually be quite inaccurate.
音響測定方法論のための基本的な要件はできるだけわずかな未確認の仮定しか使用しないことで測定をするということです。 経験は、判明する(しばしば暗黙)の仮定をするのが不正確であるのでどれくらい簡単であるかを痛々しいほど示しました。 例は高精度なソースに連動する時計の読書を測定に組み入れています。 したがって、時計が正確であると仮定するのは簡単です。 しかし、ソフトウェアのバグのために、ソースのパワーの損失、またはソースと時計、時計の間のコミュニケーションの損失が実際にかなり不正確であるかもしれません。
This is not to argue that one must not make *any* assumptions when measuring, but rather that, to the extent which is practical, assumptions should be tested. One powerful way for doing so involves checking for self-consistency. Such checking applies both to the observed value(s) of the measurement *and the values used by the measurement process itself*. A simple example of the former is that when computing a round trip time, one should check to see if it is negative. Since negative time intervals are non-physical, if it ever is negative that finding immediately flags an error. *These sorts of errors should then be investigated!* It is crucial to determine where the error lies, because only by doing so diligently can we build up faith in a methodology's fundamental soundness. For example, it could be that the round trip time is negative because during the measurement the clock was set backward in the process of synchronizing it with another source. But it could also be that the
これは*をしかし、測定するときのどんな*仮定、むしろそれにもしてはいけないと主張しないためのものです、実用的な範囲に仮定はテストされるべきです。 そうするための1つの強力な方法が、自己一貫性がないかどうかチェックすることを伴います。 そのような照合は測定*の観測値に両方を適用します、そして、測定で使用される値自体は*を処理します。前者の簡単な例は周遊旅行時間を計算するとき、それが否定的であるかどうか確認するためにチェックするべきであるということです。 否定的時間間隔が非物理的であるので、それが否定的であるなら、その調査結果はすぐに、誤りに旗を揚げさせます。 *次に、これらの種類の誤りは調査されるべきです!*唯一ので誤りがどこに私たちが方法論の基本的な健全さへの信頼を確立できるようにそれほどまめにすることによってあるかを決定するのは重要です。 例えば、別のソースにそれを連動させることの途中に時計が測定の間、後方に設定されたので周遊旅行時間が負であるということであるかもしれません。 しかし、また、それはそれであるかもしれません。
Paxson, et. al. Informational [Page 24] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[24ページ]のRFC2330枠組み
measurement program accesses uninitialized memory in one of its computations and, only very rarely, that leads to a bogus computation. This second error is more serious, if the same program is used by others to perform the same measurement, since then they too will suffer from incorrect results. Furthermore, once uncovered it can be completely fixed.
測定プログラムは計算の1つにおける非初期化しているメモリにアクセスします、そして、めったにだけ、それはにせの計算に通じません。 この2番目の誤りは、より重大です、同じプログラムが同じ測定を実行するのに他のものによって使用されるなら、それ以来、彼らがも不正確な結果が欠点でしょう。 その上、いったんむき出しであると、それを完全に修理できます。
A more subtle example of testing for self-consistency comes from gathering samples of one-way Internet delays. If one has a large sample of such delays, it may well be highly telling to, for example, fit a line to the pairs of (time of measurement, measured delay), to see if the resulting line has a clearly non-zero slope. If so, a possible interpretation is that one of the clocks used in the measurements is skewed relative to the other. Another interpretation is that the slope is actually due to genuine network effects. Determining which is indeed the case will often be highly illuminating. (See [Pa97] for a discussion of distinguishing between relative clock skew and genuine network effects.) Furthermore, if making this check is part of the methodology, then a finding that the long-term slope is very near zero is positive evidence that the measurements are probably not biased by a difference in skew.
自己一貫性がないかどうかテストするより微妙な例は片道インターネット遅れの集会のサンプルから来ます。 それは、例えば、(測定の時間、測定遅れ)の組に線に似合うと1つにそのような遅れに関する大標本があるなら結果として起こる線が明確に非ゼロに合わせるのにaを持っているかどうか確認するために、坂になるように非常にたぶん言っているでしょう。 そうだとすれば、可能な解釈は測定値で使用される時計の1つがもう片方に比例して歪曲されているということです。 別の解釈はスロープが実際に本物のネットワーク効果のためであるということです。 本当に、どれがケースであるかを決定するのがしばしば非常に啓発的になるでしょう。 (相対的な時計斜行と本物のネットワーク効果を見分ける議論に関して[Pa97]を見てください。) その上、このチェックをするのが、方法論の一部であるなら、長期のスロープが非常に近いゼロであるという調査結果は測定値がたぶん斜行の違いによって偏られないという肯定的証拠です。
A final example illustrates checking the measurement process itself for self-consistency. Above we outline Poisson sampling techniques, based on generating exponentially-distributed intervals. A sound measurement methodology would include testing the generated intervals to see whether they are indeed exponentially distributed (and also to see if they suffer from correlation). In the appendix we discuss and give C code for one such technique, a general-purpose, well-regarded goodness-of-fit test called the Anderson-Darling test.
最終的な例は、自己一貫性がないかどうか測定の過程自体をチェックしながら、例証します。 上では、指数関数的に分配された間隔を発生させることに基づいて私たちがポアソンサンプリング技法を概説します。 音響測定方法論は、本当に、それらが指数関数的に分配されるかどうか(また、それらが相関関係が欠点であるかどうか確認するために)確認するために発生している間隔をテストするのを含んでいるでしょう。 私たちがそのようなテクニックの1つのためにCコードについて議論して、与える付録では、汎用の、そして、よく見なされた適合度検定はアンダーソン-最愛の人テストを呼びました。
Finally, we note that what is truly relevant for Poisson sampling of Internet metrics is often not when the measurements began but the wire times corresponding to the measurement process. These could well be different, due to complications on the hosts used to perform the measurement. Thus, even those with complete faith in their pseudo-random number generators and subsequent algorithms are encouraged to consider how they might test the assumptions of each measurement procedure as much as possible.
測定が始まりましたが、測定に対応するワイヤ回が処理されないとき、最終的に、私たちは、インターネット測定基準のポアソン標本抽出において、本当に、関連していることがしばしばそうであることに注意します。 これらは複雑さでたぶん測定を実行するのに使用されるホストで異なっているでしょう。 それらの疑似乱数生成器とその後のアルゴリズムへの完全な信頼があるものさえ、それらがどのようにそれぞれの測定手順の仮定をできるだけテストするかもしれないかを考えるよう奨励されます。
11.3. Defining Statistical Distributions
11.3. 統計的な配を定義します。
One way of describing a collection of measurements (a sample) is as a statistical distribution -- informally, as percentiles. There are several slightly different ways of doing so. In this section we define a standard definition to give uniformity to these descriptions.
統計的分布として(サンプル)が非公式にあるという百分順位としての測定値の収集について説明する1つの方法。 そうするいくつかのわずかに異なった方法があります。 このセクションで、私たちは、これらの記述に一様性を与えるために標準定義を定義します。
Paxson, et. al. Informational [Page 25] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[25ページ]のRFC2330枠組み
The "empirical distribution function" (EDF) of a set of scalar measurements is a function F(x) which for any x gives the fractional proportion of the total measurements that were <= x. If x is less than the minimum value observed, then F(x) is 0. If it is greater or equal to the maximum value observed, then F(x) is 1.
1セットのスカラの測定値の「経験分布関数」(EDF)はどんなxのためにも<=xであった総測定値の断片的な割合を与える機能F(x)です。 xが最小値が観測した以下であるなら、F(x)は0です。 それが最大と、より優れているか、または等しいなら、値は見ました、そして、F(x)は1です。
For example, given the 6 measurements:
例えば、6つの測定値を与えます:
-2, 7, 7, 4, 18, -5
-2, 7, 7, 4, 18, -5
Then F(-8) = 0, F(-5) = 1/6, F(-5.0001) = 0, F(-4.999) = 1/6, F(7) = 5/6, F(18) = 1, F(239) = 1.
次に、F(-8)=0、F(-5)=1/6、F(-5.0001)=0、F(-4.999)=1/6、F(7)=5/6、F(18)は1、F(239)=1と等しいです。
Note that we can recover the different measured values and how many times each occurred from F(x) -- no information regarding the range in values is lost. Summarizing measurements using histograms, on the other hand, in general loses information about the different values observed, so the EDF is preferred.
私たちが異なるのを回復できるというメモは、値とそれぞれが何回F(x)から起こったかを測定しました--値における範囲のどんな情報も無くなっていません。 他方では、ヒストグラムを使用することで測定をまとめると観測された異価の情報が一般に失われるので、EDFは好まれます。
Using either the EDF or a histogram, however, we do lose information regarding the order in which the values were observed. Whether this loss is potentially significant will depend on the metric being measured.
しかしながら、EDFかヒストグラムのどちらかを使用して、私たちは値が観測されたオーダーの情報を失います。 この損失が潜在的に重要であるかどうかが測定されたメートル法の存在によるでしょう。
We will use the term "percentile" to refer to the smallest value of x for which F(x) >= a given percentage. So the 50th percentile of the example above is 4, since F(4) = 3/6 = 50%; the 25th percentile is -2, since F(-5) = 1/6 < 25%, and F(-2) = 2/6 >= 25%; the 100th percentile is 18; and the 0th percentile is -infinity, as is the 15th percentile.
私たちは、F(x)>が与えられた割合と等しいxの最も小さい値について言及するのに「百分順位」という用語を使用するつもりです。 それで、F(4)=3/6 = 50%以来上記の例の50番目の百分順位は4です。 F(-5)が1/6<と25%等しいので、25番目の百分順位は-2です、そして、F(-2)は2/6>と= 25%等しいです。 100番目の百分順位は18です。 そして、0番目の百分順位は15番目の百分順位のように無限です。
Care must be taken when using percentiles to summarize a sample, because they can lend an unwarranted appearance of more precision than is really available. Any such summary must include the sample size N, because any percentile difference finer than 1/N is below the resolution of the sample.
サンプルをまとめるのに百分順位を使用するとき、注意しなければなりません、本当に利用可能であるより多くの精度の保証のない外観を貸すことができるので。 どんなそのような概要もサンプルサイズNを含まなければなりません、1/Nよりすばらしいどんな百分順位差もサンプルの解決の下にあるので。
See [DS86] for more details regarding EDF's.
EDFのものに関するその他の詳細に関して[DS86]を見てください。
We close with a note on the common (and important!) notion of median. In statistics, the median of a distribution is defined to be the point X for which the probability of observing a value <= X is equal to the probability of observing a value > X. When estimating the median of a set of observations, the estimate depends on whether the number of observations, N, is odd or even:
私たちはメディアンの一般的で(重要な!)の概念に関する注で閉じます。 統計では、分配のメディアンは値の<がXと等しいのを観測するという確率が値の>X.Whenが1セットの観測のメディアンを見積もっているのを観測するという確率と等しいポイントXになるように定義されて、見積りはよりさえします:
Paxson, et. al. Informational [Page 26] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[26ページ]のRFC2330枠組み
+ If N is odd, then the 50th percentile as defined above is used as
the estimated median.
+ If N is even, then the estimated median is the average of the
central two observations; that is, if the observations are sorted
in ascending order and numbered from 1 to N, where N = 2*K, then
the estimated median is the average of the (K)'th and (K+1)'th
observations.
+がNであるなら変である、そして、上で定義される50番目の百分順位はおよそメディアンとして使用されます。 +がNであるなら同等である、次に、およそメディアンは主要な2つの観測の平均です。 どこが観測が昇順に分類されて、1〜Nまで付番されるならN=2*Kであるか、次に、およそメディアンは(K)の平均です'、第(K+1)、'、第観測。
Usually the term "estimated" is dropped from the phrase "estimated median" and this value is simply referred to as the "median".
通常、「推計」という用語は「メディアンであると見積もられていた」句から落とされます、そして、この値は単に「メディアン」と呼ばれます。
11.4. Testing For Goodness-of-Fit
11.4. 適合度がないかどうかテストすること。
For some forms of measurement calibration we need to test whether a set of numbers is consistent with those numbers having been drawn from a particular distribution. An example is that to apply a self- consistency check to measurements made using a Poisson process, one test is to see whether the spacing between the sampling times does indeed reflect an exponential distribution; or if the dT/N approach discussed above was used, whether the times are uniformly distributed across [T, dT].
いくつかの形式の測定較正のために、私たちは、一連の数字が特定の分配から得たそれらの数と一致しているか否かに関係なく、テストする必要があります。 例はポアソン過程を使用することでされた測定に自己一貫性チェックを適用するそれです、と本当に、標本抽出回の間のスペースが指数分布を反映するか否かに関係なく、1つのテストが見ることになっています。 または、dT/Nであるなら、回が[T、dT]の向こう側に一様に分配されるか否かに関係なく、上で議論したアプローチは使用されました。
{Comment: There are at least three possible sets of values we could
test: the scheduled packet transmission times, as determined by use
of a pseudo-random number generator; user-level timestamps made just
before or after the system call for transmitting the packet; and wire
times for the packets as recorded using a packet filter. All three
of these are potentially informative: failures for the scheduled
times to match an exponential distribution indicate inaccuracies in
the random number generation; failures for the user-level times
indicate inaccuracies in the timers used to schedule transmission;
and failures for the wire times indicate inaccuracies in actually
transmitting the packets, perhaps due to contention for a shared
resource.}
{コメント: 私たちがテストできた値の可能な少なくとも3セットがあります: 回の、そして、疑似乱数生成器の使用で決定している予定されているパケット伝送。 パケットを伝えるためのシステムコールのすぐ前または後に作られたユーザレベルタイムスタンプ。 そして、パケットのために記録されるとしてパケットフィルタを使用することで回を配線してください。 これらのすべての3が潜在的に有益です: 予定されている回が指数分布に合っていない場合、乱数発生で誤りを示します。 ユーザレベル倍で失敗は、タイマの誤りが以前はよくトランスミッションの計画をしていたのを示します。 そして、ワイヤ倍で失敗は実際にパケットを伝える際に誤りを示します、共用資源のための恐らく主張のため。}
There are a large number of statistical goodness-of-fit techniques for performing such tests. See [DS86] for a thorough discussion. That reference recommends the Anderson-Darling EDF test as being a good all-purpose test, as well as one that is especially good at detecting deviations from a given distribution in the lower and upper tails of the EDF.
そのようなテストを実行するための多くの統計的な適合度のテクニックがあります。 徹底的な議論に関して[DS86]を見てください。 その参照は良い万能のテストであるとしてアンダーソン-最愛の人EDFテストを推薦します、EDFの下側の、そして、上側のテールにおける与えられた分配からの逸脱を検出するのが特に上手なものと同様に。
It is important to understand that the nature of goodness-of-fit tests is that one first selects a "significance level", which is the probability that the test will erroneously declare that the EDF of a given set of measurements fails to match a particular distribution when in fact the measurements do indeed reflect that distribution.
適合度検定の本質がそれであることを理解しているのが1/1にテストが、事実上、測定値が本当にその分配を反映するとき、与えられたセットの測定値のEDFが特定の分配に合っていないと誤って宣言するという確率である「有意水準」を選択するのは、重要です。
Paxson, et. al. Informational [Page 27] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[27ページ]のRFC2330枠組み
Unless otherwise stated, IPPM goodness-of-fit tests are done using 5% significance. This means that if the test is applied to 100 samples and 5 of those samples are deemed to have failed the test, then the samples are all consistent with the distribution being tested. If significantly more of the samples fail the test, then the assumption that the samples are consistent with the distribution being tested must be rejected. If significantly fewer of the samples fail the test, then the samples have potentially been doctored too well to fit the distribution. Similarly, some goodness-of-fit tests (including Anderson-Darling) can detect whether it is likely that a given sample was doctored. We also use a significance of 5% for this case; that is, the test will report that a given honest sample is "too good to be true" 5% of the time, so if the test reports this finding significantly more often than one time out of twenty, it is an indication that something unusual is occurring.
別の方法で述べられない場合、IPPM適合度検定は5%の意味を使用し終わっています。 これは、テストが100個のサンプルに適用されて、それらの5個のサンプルがテストに失敗したと考えられるならサンプルがテストされる分配とすべて一致していることを意味します。 一層のサンプルがテストにかなり失敗するなら、サンプルがテストされる分配と一致しているという仮定を拒絶しなければなりません。 かなり少ないなら、サンプルでは、テストに失敗してください、そして、次に、サンプルは潜在的にあまり分配に合うのにおいてよく治療されました。 同様に、いくつかの適合度検定(アンダーソン-ダーリングを含んでいる)が、与えられたサンプルが治療されそうだったかどうか検出できます。 また、私たちはこのような場合5%の意味を使用します。 すなわち、テストが、与えられた正直なサンプルが5%の割合で「話がうますぎると思うくらいである」と報告するので、テストが20回のうちの1よりかなりしばしばこの調査結果を報告するなら、それはその何か珍しいものが起こっているという証拠です。
The appendix gives sample C code for implementing the Anderson- Darling test, as well as further discussing its use.
付録は、さらに使用について議論することと同様にアンダーソンの最愛のテストを実行するためにサンプルCコードを与えます。
See [Pa94] for a discussion of goodness-of-fit and closeness-of-fit tests in the context of network measurement.
ネットワーク測定の文脈における、適合度の議論とフィットテストの密接に関して[Pa94]を見てください。
12. Avoiding Stochastic Metrics
12. 推計的な測定基準を避けます。
When defining metrics applying to a path, subpath, cloud, or other network element, we in general do not define them in stochastic terms (probabilities). We instead prefer a deterministic definition. So, for example, rather than defining a metric about a "packet loss probability between A and B", we would define a metric about a "packet loss rate between A and B". (A measurement given by the first definition might be "0.73", and by the second "73 packets out of 100".)
経路、「副-経路」、雲、または他のネットワーク要素に適用される測定基準を定義するとき、推計的な用語(確率)で一般に、私たちはそれらを定義しません。 私たちは代わりに決定論的な定義を好みます。 そのように、例えば、「AとBの間のパケット紛失率」に関するメートル法のaを定義するよりむしろ、私たちは「AとBの間のパケット損失率」に関するメートル法のaを定義するでしょう。 (最初の定義で与えられた測定がそうである、「0.73インチ、および2番目「100のパケットのうちの73」で)、」
We emphasize that the above distinction concerns the *definitions* of *metrics*. It is not intended to apply to what sort of techniques we might use to analyze the results of measurements.
私たちは、上の区別は*測定基準*の*定義*に関係があると強調します。私たちが測定値の結果を分析するのに使用するかもしれないどういうテクニックに適用しないつもりであるか。
The reason for this distinction is as follows. When definitions are made in terms of probabilities, there are often hidden assumptions in the definition about a stochastic model of the behavior being measured. The fundamental goal with avoiding probabilities in our metric definitions is to avoid biasing our definitions by these hidden assumptions.
この区別の理由は以下の通りです。 確率で定義をするとき、測定される振舞いの確率的模型に関して定義におけるしばしば隠された仮定があります。 私たちのメートル法の定義における確率を避ける基本的な目標はこれらの隠された仮定で私たちの定義に偏るのを避けることです。
Paxson, et. al. Informational [Page 28] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[28ページ]のRFC2330枠組み
For example, an easy hidden assumption to make is that packet loss in a network component due to queueing overflows can be described as something that happens to any given packet with a particular probability. In today's Internet, however, queueing drops are actually usually *deterministic*, and assuming that they should be described probabilistically can obscure crucial correlations between queueing drops among a set of packets. So it's better to explicitly note stochastic assumptions, rather than have them sneak into our definitions implicitly.
例えば、しやすい隠された仮定は特定の確率でどんな与えられたパケットにも起こる何かとして待ち行列オーバーフローによるネットワーク要素におけるパケット損失を記述できるということです。 しかしながら、今日のインターネットでは、待ち行列低下は実際に通常*決定論的な*です、そして、それらが説明されるべきであると仮定するのがprobabilisticallyに1セットのパケットの中の待ち行列低下の間の重要な相関関係をあいまいにすることができます。 それで、それとなく私たちの定義に潜入させるより明らかにむしろ推計的な仮定に注意しているほうがよいです。
This does *not* mean that we abandon stochastic models for *understanding* network performance! It only means that when defining IP metrics we avoid terms such as "probability" for terms like "proportion" or "rate". We will still use, for example, random sampling in order to estimate probabilities used by stochastic models related to the IP metrics. We also do not rule out the possibility of stochastic metrics when they are truly appropriate (for example, perhaps to model transmission errors caused by certain types of line noise).
これは、*のために*ネットワーク性能を理解しながら、私たちが捨てる*平均ではなく、*に確率的模型をします! それは、私たちが避けるIP測定基準を定義するとき、用語の「確率」などの用語が「割合」が好きである、または「評価すること」を意味するだけです。 それでも、私たちは、IP測定基準に関連する確率的模型によって使用される確率を見積もるのに例えば無作為抽出法を使用するつもりです。 また、それらが本当に適切であるときに(例えば恐らくあるタイプの回線雑音によって引き起こされたモデル伝送エラーに)、私たちは推計的な測定基準の可能性を除外しません。
13. Packets of Type P
13. タイプPのパケット
A fundamental property of many Internet metrics is that the value of the metric depends on the type of IP packet(s) used to make the measurement. Consider an IP-connectivity metric: one obtains different results depending on whether one is interested in connectivity for packets destined for well-known TCP ports or unreserved UDP ports, or those with invalid IP checksums, or those with TTL's of 16, for example. In some circumstances these distinctions will be highly interesting (for example, in the presence of firewalls, or RSVP reservations).
多くのインターネット測定基準の基本財産はメートル法の値を測定をするのに使用されるIPパケットのタイプに頼っているということです。 IP-接続性がメートル法であると考えてください: 1つは例えば、周知のTCPポートか予約していないUDPポートに運命づけられたパケット、無効のIPチェックサムがあるそれら、またはTTLの16のものがあるそれらのために1つが接続性に興味を持っているかどうかに依存する異なった結果を得ます。 いくつかの事情では、これらの区別は非常におもしろくなるでしょう(例えばファイアウォール、またはRSVPの予約があるとき)。
Because of this distinction, we introduce the generic notion of a "packet of type P", where in some contexts P will be explicitly defined (i.e., exactly what type of packet we mean), partially defined (e.g., "with a payload of B octets"), or left generic. Thus we may talk about generic IP-type-P-connectivity or more specific IP-port-HTTP-connectivity. Some metrics and methodologies may be fruitfully defined using generic type P definitions which are then made specific when performing actual measurements.
この区別のために、私たちはいくつかの文脈では、Pが明らかに定義される(すなわち、私たちはちょうどどんなタイプのパケットを言っていますか)ところで部分的に定義されるか(例えば、「B八重奏のペイロード」で)、または一般的な状態で残っている「タイプPのパケット」の一般的な概念を紹介します。 したがって、私たちは一般的なIPタイプPの接続性か、より特定のIPポートHTTPの接続性に関して話すかもしれません。 いくつかの測定基準と方法論が、次に実測を実行するとき特定にされる一般的なタイプP定義を使用することで実り多く定義されるかもしれません。
Whenever a metric's value depends on the type of the packets involved in the metric, the metric's name will include either a specific type or a phrase such as "type-P". Thus we will not define an "IP-
いつ、aメートル法であることは、値をメートル法にかかわるパケットのタイプに頼っていて、メートル法による名前が「タイプP」などの特定のタイプか句のどちらかを含むということであるということであるか。 したがって、私たちは「IP」を定義するつもりではありません。
Paxson, et. al. Informational [Page 29] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[29ページ]のRFC2330枠組み
connectivity" metric but instead an "IP-type-P-connectivity" metric and/or perhaps an "IP-port-HTTP-connectivity" metric. This naming convention serves as an important reminder that one must be conscious of the exact type of traffic being measured.
「接続性」メートル法、代わりに「IPタイプPの接続性」、メートル法、恐らく「IPポートHTTPの接続性」、メートル法です。 この命名規則は測定される正確なタイプの交通を意識しているに違いないという重要な注意点として機能します。
A closely related note: it would be very useful to know if a given Internet component treats equally a class C of different types of packets. If so, then any one of those types of packets can be used for subsequent measurement of the component. This suggests we devise a metric or suite of metrics that attempt to determine C.
密接に関係づけられた注意: 与えられたインターネットコンポーネントが等しく異なったタイプのパケットのクラスCを扱うかどうかを知るのは非常に役に立つでしょう。 そうだとすれば、そして、コンポーネントの事後測定にパケットのそういったタイプの人のいずれも使用できます。 これが、私たちがメートル法でaについて工夫するのを示すか、または試みる測定基準のスイートはCを決定します。
14. Internet Addresses vs. Hosts
14. インターネットアドレス対ホスト
When considering a metric for some path through the Internet, it is often natural to think about it as being for the path from Internet host H1 to host H2. A definition in these terms, though, can be ambiguous, because Internet hosts can be attached to more than one network. In this case, the result of the metric will depend on which of these networks is actually used.
何らかの経路において、aがインターネットを通してメートル法であると考えるとき、インターネット・ホストH1からホストH2まで経路にはあるとそれについて考えるのはしばしば当然です。 もっとも、1つ以上のネットワークにインターネット・ホストを配属されることができるので、これらの用語による定義はあいまいである場合があります。 この場合、メートル法の結果はこれらのネットワークのどれが実際に使用されるかに依存するでしょう。
Because of this ambiguity, usually such definitions should instead be defined in terms of Internet IP addresses. For the common case of a unidirectional path through the Internet, we will use the term "Src" to denote the IP address of the beginning of the path, and "Dst" to denote the IP address of the end.
このあいまいさのために、通常、そのような定義は代わりにインターネットIPアドレスで定義されるべきです。 インターネットを通した単方向の経路のよくある例のために、私たちは経路の始まりのIPアドレスを指示する"Src"、および終わりのIPアドレスを指示する"Dst"という用語を使用するつもりです。
15. Standard-Formed Packets
15. 規格で形成されたパケット
Unless otherwise stated, all metric definitions that concern IP packets include an implicit assumption that the packet is *standard formed*. A packet is standard formed if it meets all of the following criteria:
別の方法で述べられない場合、パケットがパケットが*規格であるという暗黙の仮定を含んでいるのをIPに関するすべてのメートル法の定義が*を形成しました。以下の評価基準のすべてに会うなら形成されて、パケットは標準です:
+ Its length as given in the IP header corresponds to the size of
the IP header plus the size of the payload.
+ It includes a valid IP header: the version field is 4 (later, we
will expand this to include 6); the header length is >= 5; the
checksum is correct.
+ It is not an IP fragment.
+ The source and destination addresses correspond to the hosts in
question.
+ IPヘッダーで与えられている長さはIPヘッダーのサイズとペイロードのサイズに対応しています。 有効なIPヘッダーを含んでいます: バージョン分野は4(後で、私たちは6を含むようにこれを広げるつもりである)です。 ヘッダ長は>=5です。 チェックサムは正しいです。 + それはIP断片ではありません。 + ソースと送付先アドレスは問題のホストに文通されます。
Paxson, et. al. Informational [Page 30] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[30ページ]のRFC2330枠組み
+ Either the packet possesses sufficient TTL to travel from the
source to the destination if the TTL is decremented by one at each
hop, or it possesses the maximum TTL of 255.
+ It does not contain IP options unless explicitly noted.
+ If a transport header is present, it too contains a valid checksum
and other valid fields.
TTLが各ホップの1つ減少するなら、+ パケットがソースから目的地まで旅行できるくらいのTTLを所有しているか、またはそれは255の最大のTTLを所有しています。 明らかに注意されない場合、+ それはIPオプションを含んでいません。 +が輸送ヘッダーであるなら存在している、それも有効なチェックサムと他の有効な分野を含んでいます。
We further require that if a packet is described as having a "length of B octets", then 0 <= B <= 65535; and if B is the payload length in octets, then B <= (65535-IP header size in octets).
私たちは、パケットが「B八重奏の長さ」を持っているとして記述されるなら0<がB<=65535と等しいのをさらに必要とします。 そして、Bが八重奏でペイロード長であるなら、B<は(八重奏における65535IPのヘッダーサイズ)と等しいです。
So, for example, one might imagine defining an IP connectivity metric as "IP-type-P-connectivity for standard-formed packets with the IP TOS field set to 0", or, more succinctly, "IP-type-P-connectivity with the IP TOS field set to 0", since standard-formed is already implied by convention.
そのように、例えば、人が、IPの接続性を定義するとメートル法で想像するかもしれない、「IP TOS分野がある規格で形成されたパケットのためのIPタイプPの接続性が0インチにセットしたか、または、より簡潔に、「IP TOS分野が規格によって形成されているので0インチにセットした状態で、IPタイプPの接続性はコンベンションによって既に含意されます」。
A particular type of standard-formed packet often useful to consider is the "minimal IP packet from A to B" - this is an IP packet with the following properties:
考えるためにしばしば役に立つ規格で形成されたパケットの特定のタイプは「AからBまでの最小量のIPパケット」です--これは以下の特性があるIPパケットです:
+ It is standard-formed. + Its data payload is 0 octets. + It contains no options.
+ それは規格によって形成されています。 + データペイロードは0つの八重奏です。 + それはオプションを全く含んでいません。
(Note that we do not define its protocol field, as different values may lead to different treatment by the network.)
(異価がネットワークによる異なった処理につながるかもしれなくて、私たちがプロトコル分野を定義しないことに注意してください。)
When defining IP metrics we keep in mind that no packet smaller or simpler than this can be transmitted over a correctly operating IP network.
IP測定基準を定義するとき、私たちは、念頭にそれが正しく稼働しているIPネットワークの上にこれを伝えることができるよりさらに小さいか簡単なパケットでないことを保ちます。
16. Acknowledgements
16. 承認
The comments of Brian Carpenter, Bill Cerveny, Padma Krishnaswamy Jeff Sedayao and Howard Stanislevic are appreciated.
ブライアンCarpenter、ビル・チェルベニ、Padma KrishnaswamyジェフSedayao、およびハワードStanislevicのコメントに感謝します。
17. Security Considerations
17. セキュリティ問題
This document concerns definitions and concepts related to Internet measurement. We discuss measurement procedures only in high-level terms, regarding principles that lend themselves to sound measurement. As such, the topics discussed do not affect the security of the Internet or of applications which run on it.
このドキュメントはインターネット測定に関連する定義と概念に関係があります。 私たちは単に自分たちを音響測定に与える原則に関するハイレベルの用語で測定手順について議論します。 そういうものとして、議論した話題はそれで走るインターネットかアプリケーションのセキュリティに影響しません。
Paxson, et. al. Informational [Page 31] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[31ページ]のRFC2330枠組み
That said, it should be recognized that conducting Internet measurements can raise both security and privacy concerns. Active techniques, in which traffic is injected into the network, can be abused for denial-of-service attacks disguised as legitimate measurement activity. Passive techniques, in which existing traffic is recorded and analyzed, can expose the contents of Internet traffic to unintended recipients. Consequently, the definition of each metric and methodology must include a corresponding discussion of security considerations.
それは言って、伝導するインターネット測定値がセキュリティとプライバシーの問題の両方を提起できると認められるべきです。 正統の測定活動に変装するサービス不能攻撃のために、アクティブなテクニック(交通はネットワークに注がれる)を乱用できます。 受け身のテクニック(既存の交通は、記録されて、分析される)はインターネットトラフィックのコンテンツを故意でない受取人に露出できます。 その結果、それぞれメートル法の定義と方法論はセキュリティ問題の対応する議論を含まなければなりません。
18. Appendix
18. 付録
Below we give routines written in C for computing the Anderson- Darling test statistic (A2) for determining whether a set of values is consistent with a given statistical distribution. Externally, the two main routines of interest are:
以下に、私たちは1セットの値が与えられた統計的分布と一致しているかどうか決定するために、アンダーソンの最愛の検定統計量(A2)を計算するためのCに書かれたルーチンを与えます。 外部的に、興味がある2つのメインルーチンは以下の通りです。
double exp_A2_known_mean(double x[], int n, double mean)
double unif_A2_known_range(double x[], int n,
double min_val, double max_val)
知られているexp_A2の_の知られている_平均(二重x[]、int nは平均を倍にする)二重unif_A2_を倍にしてください、_及んでください。(二重x[]、int n、二重分_val、二重最大_val)
Both take as their first argument, x, the array of n values to be tested. (Upon return, the elements of x are sorted.) The remaining parameters characterize the distribution to be used: either the mean (1/lambda), for an exponential distribution, or the lower and upper bounds, for a uniform distribution. The names of the routines stress that these values must be known in advance, and *not* estimated from the data (for example, by computing its sample mean). Estimating the parameters from the data *changes* the significance level of the test statistic. While [DS86] gives alternate significance tables for some instances in which the parameters are estimated from the data, for our purposes we expect that we should indeed know the parameters in advance, since what we will be testing are generally values such as packet sending times that we wish to verify follow a known distribution.
両方が、テストされるために彼らの最初の議論、xとしてn値の勢ぞろいをみなします。 (リターンのときに、xの要素は分類されます。) 残っているパラメタは使用されるために分配を特徴付けます: 指数分布、または下側のための平均(1/λ)と一様分布のための上限。 **データ(例えば試料平均を計算することによって)から見積もられていなくて、ルーチンの名前は、あらかじめこれらの値を知っていなければならないと強調します。 データ*変化*からのパラメタが検定統計量の有意水準であると見積もっています。 [DS86]があらかじめパラメタが私たちが予想する私たちの目的のためのデータから見積もられているいくつかの例のための本当に、私たちが知るべきである交互の意味テーブルにパラメタを与えている間、私たちがテストしていることが一般に、確かめたいと思うパケット送付回数などの値であるので、知られている分配に続いてください。
Both routines return a significance level, as described earlier. This is a value between 0 and 1. The correct use of the routines is to pick in advance the threshold for the significance level to test; generally, this will be 0.05, corresponding to 5%, as also described above. Subsequently, if the routines return a value strictly less than this threshold, then the data are deemed to be inconsistent with the presumed distribution, *subject to an error corresponding to the significance level*. That is, for a significance level of 5%, 5% of the time data that is indeed drawn from the presumed distribution will be erroneously deemed inconsistent.
両方のルーチンは、より早く説明されるように有意水準を返します。 これは0と1の間の値です。 ルーチンの正しい使用はあらかじめ有意水準がテストする敷居を選ぶことです。 一般に、これはまた、上で説明されているとして5%に対応する0.05になるでしょう。 次に、ルーチンがこの敷居より厳密に値を返さないなら、データが推定された分配に矛盾していると考えられます、有意水準*に対応する誤りを条件とした*。すなわち、5%の有意水準において、本当に、推定された分配から得られる時間データの5%は矛盾していると誤って考えられるでしょう。
Paxson, et. al. Informational [Page 32] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[32ページ]のRFC2330枠組み
Thus, it is important to bear in mind that if these routines are used frequently, then one will indeed encounter occasional failures, even if the data is unblemished.
したがって、これらのルーチンが頻繁に使用されると本当に、1つが時々の失敗に遭遇するのを覚えておくのは重要です、データが潔白であっても。
Another important point concerning significance levels is that it is unsound to compare them in order to determine which of two sets of values is a "better" fit to a presumed distribution. Such testing should instead be done using "closeness-of-fit metrics" such as the lambda^2 metric described in [Pa94].
有意水準に関する重要なもう1ポイントは2セットの値についてどれを決定するかためにそれらを比較するためには不健全であるのが、推定された分配への「より良い」発作であるということであるということです。 λ^2などのようなメートル法の「発作の密接測定基準」は代わりにそのようなテストに使用されるべきです[Pa94]で説明される。
While the routines provided are for exponential and uniform
distributions with known parameters, it is generally straight-forward
to write comparable routines for any distribution with known
parameters. The heart of the A2 tests lies in a statistic computed
for testing whether a set of values is consistent with a uniform
distribution between 0 and 1, which we term Unif(0, 1). If we wish
to test whether a set of values, X, is consistent with a given
distribution G(x), we first compute
Y = G_inverse(X)
If X is indeed distributed according to G(x), then Y will be
distributed according to Unif(0, 1); so by testing Y for consistency
with Unif(0, 1), we also test X for consistency with G(x).
提供されたルーチンは知られているパラメタがある指数の、そして、一定の配のためのものですが、一般に、知られているパラメタでどんな分配のための匹敵するルーチンも書くのは簡単です。 1セットの値が0と1の間の一様分布と一致しているか否かに関係なく、テストするために計算された統計値にはA2テストの心がある、どれ、私たち、用語Unif(0、1)。 1セットの値(X)が与えられた分配G(x)と一致しているか否かに関係なく、テストしたいと思うなら、G(x)によると、Xが本当に分配されるなら、私たちは最初にY=G_逆(X)を計算します、次に、Unif(0、1)によると、Yは分配されるでしょう。 それで、また、Unif(0、1)と共に一貫性のためのYをテストすることによって、私たちはG(x)と共に一貫性のためのXをテストします。
We note, however, that the process of computing Y above might yield values of Y outside the range (0..1). Such values should not occur if X is indeed distributed according to G(x), but easily can occur if it is not. In the latter case, we need to avoid computing the central A2 statistic, since floating-point exceptions may occur if any of the values lie outside (0..1). Accordingly, the routines check for this possibility, and if encountered, return a raw A2 statistic of -1. The routine that converts the raw A2 statistic to a significance level likewise propagates this value, returning a significance level of -1. So, any use of these routines must be prepared for a possible negative significance level.
しかしながら、私たちは、Yを計算する上の過程が範囲(0 .1)の外でYの値をもたらすかもしれないことに注意します。 そのような値は、G(x)によると、Xが本当に分配されるなら起こるべきではありませんが、それが起こらないなら、容易に起こることができます。 後者の場合では、私たちは、中央のA2統計値を計算するのを避ける必要があります、(0 .1)の外で値のどれかがあるなら浮動小数点の例外が起こるかもしれないので。 それに従って、この可能性がないかどうかルーチンをチェックします、そして、遭遇するなら、-1の生のA2統計値を返してください。 生のA2統計値を有意水準に変換するルーチンは同様にこの値を伝播します、-1の有意水準を返して。 それで、可能な否定的有意水準のためにこれらのルーチンのどんな使用も準備しなければなりません。
The last important point regarding use of A2 statistic concerns n, the number of values being tested. If n < 5 then the test is not meaningful, and in this case a significance level of -1 is returned.
値の数がテストされて、A2統計値の使用に関する最後の重要なポイントはnに関係があります。 n<5であるなら、テストは重要ではありません、そして、この場合、-1の有意水準を返します。
On the other hand, for "real" data the test *gains* power as n becomes larger. It is well known in the statistics community that real data almost never exactly matches a theoretical distribution, even in cases such as rolling dice a great many times (see [Pa94] for a brief discussion and references). The A2 test is sensitive enough that, for sufficiently large sets of real data, the test will almost always fail, because it will manage to detect slight imperfections in the fit of the data to the distribution.
他方では、「本当」のデータに関して、nが、より大きくなるのに応じて、テスト*は*パワーを獲得します。 本当のデータがまさにほとんど理論分布に合っていないのは、統計共同体でよく知られています、サイコロを何回も回転などにさせることなどの場合でさえ(簡潔な議論と参照に関して[Pa94]を見てください)。 A2テストはテストがほとんどいつも十分大きい本当のデータに関して失敗するほど敏感です、データの発作でわずかな欠点を何とか分配に検出するので。
Paxson, et. al. Informational [Page 33] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[33ページ]のRFC2330枠組み
For example, we have found that when testing 8,192 measured wire times for packets sent at Poisson intervals, the measurements almost always fail the A2 test. On the other hand, testing 128 measurements failed at 5% significance only about 5% of the time, as expected. Thus, in general, when the test fails, care must be taken to understand why it failed.
例えば、私たちは、8,192をテストするとワイヤ回がポアソン間隔を置いて送られたパケットのために測定したとき、測定値がほとんどいつもA2テストに失敗するのがわかりました。 他方では、128の測定をテストするのは予想されるようにおよそ5%だけの割合で5%の意味で失敗しました。 このようにして、一般に、テストが失敗すると、それがなぜ失敗したかを理解するために注意しなければなりません。
The remainder of this appendix gives C code for the routines mentioned above.
この付録の残りは前記のようにルーチンのためにCコードを与えます。
/* Routines for computing the Anderson-Darling A2 test statistic.
*
* Implemented based on the description in "Goodness-of-Fit
* Techniques," R. D'Agostino and M. Stephens, editors,
* Marcel Dekker, Inc., 1986.
*/
アンダーソンDarlingのA2を計算するための/*ルーチンは統計値をテストします。 * * 「適合度*テクニック」、R.ダゴスティーノ、およびM.スティーブンズの記述、エディタ、*マルセルデッカーInc.、1986に基づいて、実行されます。 */
#include <stdio.h> #include <stdlib.h> #include <math.h>
#<stdio.h>#インクルード<stdlib.h>#インクルード<math.h>を含めてください。
/* Returns the raw A^2 test statistic for n sorted samples
* z[0] .. z[n-1], for z ~ Unif(0,1).
*/
extern double compute_A2(double z[], int n);
/*はサンプル*z[0]z~Unif(0、1)のためのz[n-1]をnのための2検定統計量が分類した生のA^に返します。 *通いの人が倍にする/は_A2(二重z[]、int n)を計算します。
/* Returns the significance level associated with a A^2 test
* statistic value of A2, assuming no parameters of the tested
* distribution were estimated from the data.
*/
extern double A2_significance(double A2);
/*はA2のA^2テスト*統計値価値に関連している有意水準を返します、テストされた*分配のパラメタが全くデータから見積もられていなかったと仮定して。 */通いの人二重A2_意味(二重A2)。
/* Returns the A^2 significance level for testing n observations
* x[0] .. x[n-1] against an exponential distribution with the
* given mean.
*
* SIDE EFFECT: the x[0..n-1] are sorted upon return.
*/
extern double exp_A2_known_mean(double x[], int n, double mean);
/*は、指数分布に対して平均を与える*でn観測*のx[0]x[n-1]をテストするために^2有意水準をAに返します。 * * 副作用: x[0..n-1]はリターンのときに分類されます。 *知られている_が意味する(二重x[]、int nは平均を倍にします)/通いの人の二重exp_A2_。
/* Returns the A^2 significance level for testing n observations
* x[0] .. x[n-1] against the uniform distribution [min_val, max_val].
*
* SIDE EFFECT: the x[0..n-1] are sorted upon return.
*/
extern double unif_A2_known_range(double x[], int n,
double min_val, double max_val);
/*は、一様分布[分_val、最大_val]に対してn観測*のx[0]x[n-1]をテストするために^2有意水準をAに返します。 * * 副作用: x[0..n-1]はリターンのときに分類されます。 */通いの人は知られているunif_A2_を倍にします。_及んでください(二重x[](int n)は分_val、二重最大_valを倍にします)。
Paxson, et. al. Informational [Page 34] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[34ページ]のRFC2330枠組み
/* Returns a pseudo-random number distributed according to an
* exponential distribution with the given mean.
*/
extern double random_exponential(double mean);
/*は*指数分布によると、与えられた平均で分配された擬似乱数を返します。 */通いの人の二重無作為の_指数(二重平均)。
/* Helper function used by qsort() to sort double-precision
* floating-point values.
*/
static int
compare_double(const void *v1, const void *v2)
{
double d1 = *(double *) v1;
double d2 = *(double *) v2;
倍精度*浮動小数点の値を分類するのにqsort()によって使用された/*ヘルパー機能。 */静的なintが_二重に比較される、(*v1をconstに欠如させてください、const空間*v2)二重d1は*(二重*)v1と等しいです; 二重d2は*(二重*)v2と等しいです。
if (d1 < d2)
return -1;
else if (d1 > d2)
return 1;
else
return 0;
}
(d1<d2)であるなら、-1を返してください。 ほかに、(d1>d2)であるなら1を返してください。 ほかのリターン0。 }
double
compute_A2(double z[], int n)
{
int i;
double sum = 0.0;
ダブルが_A2(二重z[]、int n)を計算する、int i; 合計=0.0を倍にしてください。
if ( n < 5 )
/* Too few values. */
return -1.0;
(わずか過ぎるしか評価しないn<5)/*。 */リターン-1.0。
/* If any of the values are outside the range (0, 1) then
* fail immediately (and avoid a possible floating point
* exception in the code below).
*/
for (i = 0; i < n; ++i)
if ( z[i] <= 0.0 || z[i] >= 1.0 )
return -1.0;
*範囲(0、1)の外に*もしあれば値の/があって、次に、すぐに、失敗してください(以下のコードの可能な浮動小数点*例外を避けてください)。 *(i=0; i<n; + + i)のための/は(z[i]<は0.0と等しいです| | z[i]>=1.0)なら-1.0を返します。
/* Page 101 of D'Agostino and Stephens. */
for (i = 1; i <= n; ++i) {
sum += (2 * i - 1) * log(z[i-1]);
sum += (2 * n + 1 - 2 * i) * log(1.0 - z[i-1]);
}
return -n - (1.0 / n) * sum;
}
ダゴスティーノと101人の/*スティーブンズページ。 *合計..ログ..合計..ログ..リターン..合計 }
Paxson, et. al. Informational [Page 35] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[35ページ]のRFC2330枠組み
double
A2_significance(double A2)
{
/* Page 105 of D'Agostino and Stephens. */
if (A2 < 0.0)
return A2; /* Bogus A2 value - propagate it. */
A2_意味(二重A2)を倍にしてください、(A2<0.0)がA2(/*にせのA2価値)を返すならスティーブンズダゴスティーノと105/**/がパージュそれを伝播する、*/
/* Check for possibly doctored values. */
if (A2 <= 0.201)
return 0.99;
else if (A2 <= 0.240)
return 0.975;
else if (A2 <= 0.283)
return 0.95;
else if (A2 <= 0.346)
return 0.90;
else if (A2 <= 0.399)
return 0.85;
ことによると治療された値のための/*チェック。 *(A2<=0.201)であるなら、/は0.99を返します。 (A2<=0.240)であるなら、ほかに、0.975を返してください。 (A2<=0.283)であるなら、ほかに、0.95を返してください。 (A2<=0.346)であるなら、ほかに、0.90を返してください。 (A2<=0.399)であるなら、ほかに、0.85を返してください。
/* Now check for possible inconsistency. */
if (A2 <= 1.248)
return 0.25;
else if (A2 <= 1.610)
return 0.15;
else if (A2 <= 1.933)
return 0.10;
else if (A2 <= 2.492)
return 0.05;
else if (A2 <= 3.070)
return 0.025;
else if (A2 <= 3.880)
return 0.01;
else if (A2 <= 4.500)
return 0.005;
else if (A2 <= 6.000)
return 0.001;
else
return 0.0;
}
/*は現在、可能な矛盾がないかどうかチェックします。 *(A2<=1.248)であるなら、/は0.25を返します。 (A2<=1.610)であるなら、ほかに、0.15を返してください。 (A2<=1.933)であるなら、ほかに、0.10を返してください。 (A2<=2.492)であるなら、ほかに、0.05を返してください。 (A2<=3.070)であるなら、ほかに、0.025を返してください。 (A2<=3.880)であるなら、ほかに、0.01を返してください。 (A2<=4.500)であるなら、ほかに、0.005を返してください。 (A2<=6.000)であるなら、ほかに、0.001を返してください。 ほかのリターン0.0。 }
double
exp_A2_known_mean(double x[], int n, double mean)
{
int i;
double A2;
知られている_意地悪な状態で(二重x[]、int nは平均を倍にします)exp_A2_を倍にしてください、int i; A2を倍にしてください。
/* Sort the first n values. */
qsort(x, n, sizeof(x[0]), compare_double);
最初のnが評価する/*種類。 */はqsortされます。(x、nはsizeofされます(x[0])、_二重に比較してください)。
Paxson, et. al. Informational [Page 36] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[36ページ]のRFC2330枠組み
/* Assuming they match an exponential distribution, transform
* them to Unif(0,1).
*/
for (i = 0; i < n; ++i) {
x[i] = 1.0 - exp(-x[i] / mean);
}
/*仮定している彼らは指数分布に合って、変換*はUnif(0、1)へのそれらです。 *(i=0; i<n; + + i)のための/x[i]は1.0と等しいです--exp(-x[i]/平均)
/* Now make the A^2 test to see if they're truly uniform. */
A2 = compute_A2(x, n);
return A2_significance(A2);
}
/*は、今、本当に、それらが一定であるかどうか確認するためにA^を2テストにします。 */A2=は_A2(x、n)を計算します。 A2_意味(A2)を返してください。 }
double
unif_A2_known_range(double x[], int n, double min_val, double max_val)
{
int i;
double A2;
double range = max_val - min_val;
unif_A2を倍にしてください、_の知られている_範囲(二重x[]、int nは分_val、二重最大_valを倍にする)、int i; 二重A2; 範囲=最大_valを倍にしてください--分_val
/* Sort the first n values. */
qsort(x, n, sizeof(x[0]), compare_double);
最初のnが評価する/*種類。 */はqsortされます。(x、nはsizeofされます(x[0])、_二重に比較してください)。
/* Transform Unif(min_val, max_val) to Unif(0,1). */
for (i = 0; i < n; ++i)
x[i] = (x[i] - min_val) / range;
Unif(0、1)への/*変換Unif(分_val、最大_val)。 *(i=0; i<n; + + i)x[i]のための/は/範囲と等しいです(x[i]--分_val)。
/* Now make the A^2 test to see if they're truly uniform. */
A2 = compute_A2(x, n);
return A2_significance(A2);
}
/*は、今、本当に、それらが一定であるかどうか確認するためにA^を2テストにします。 */A2=は_A2(x、n)を計算します。 A2_意味(A2)を返してください。 }
double
random_exponential(double mean)
{
return -mean * log1p(-drand48());
}
指数で(二重平均)無作為の_を倍にしてください。平均*log1pを返してください、(-drand48())。
Paxson, et. al. Informational [Page 37] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[37ページ]のRFC2330枠組み
19. References
19. 参照
[AK97] G. Almes and S. Kalidindi, "A One-way Delay Metric for IPPM", Work in Progress, November 1997.
[AK97] 「IPPMにおける、メートル法のA One-道の遅れ」というG.AlmesとS.Kalidindiは進歩、1997年11月に働いています。
[BM92] I. Bilinskis and A. Mikelsons, Randomized Signal Processing, Prentice Hall International, 1992.
[BM92] I.BilinskisとA.Mikelsons、ランダマイズされた信号処理、国際新米のホール、1992。
[DS86] R. D'Agostino and M. Stephens, editors, Goodness-of-Fit Techniques, Marcel Dekker, Inc., 1986.
[DS86] R.ダゴスティーノとM.スティーブンズ、エディタマルセルデッカーInc.、1986(発作のGoodness Techniques)
[CPB93] K. Claffy, G. Polyzos, and H-W. Braun, "Application of Sampling Methodologies to Network Traffic Characterization," Proc. SIGCOMM '93, pp. 194-203, San Francisco, September 1993.
[CPB93] K.Claffy、G.Polyzos、およびH-W。 ブラウン、「ネットワークトラフィック特殊化へのサンプリング法のアプリケーション」、Proc。 SIGCOMM93年、ページ 194-203 1993年9月のサンフランシスコ。
[FJ94] S. Floyd and V. Jacobson, "The Synchronization of Periodic Routing Messages," IEEE/ACM Transactions on Networking, 2(2), pp. 122-136, April 1994.
[FJ94] S.フロイドとV.ジェーコブソン、「周期的なルーティング・メッセージの同期」、Networking、2(2)、ページのIEEE/ACM Transactions 122-136と、1994年4月。
[Mi92] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[Mi92] 工場、D.、「ネットワーク時間は仕様、実現、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
[Pa94] V. Paxson, "Empirically-Derived Analytic Models of Wide-Area TCP Connections," IEEE/ACM Transactions on Networking, 2(4), pp. 316-336, August 1994.
[Pa94]V.パクソン、「広い領域TCPコネクションズの経験して派生している分析的なモデル」、Networking、2(4)、ページのIEEE/ACM Transactions 316-336と、1994年8月。
[Pa96] V. Paxson, "Towards a Framework for Defining Internet Performance Metrics," Proceedings of INET '96, ftp://ftp.ee.lbl.gov/papers/metrics-framework-INET96.ps.Z
[Pa96]V.パクソン、「インターネットパフォーマンス測定基準を定義するための枠組み」、INET96年、 ftp://ftp.ee.lbl.gov/papers/metrics-framework-INET96.ps.Z の議事
[Pa97] V. Paxson, "Measurements and Analysis of End-to-End Internet Dynamics," Ph.D. dissertation, U.C. Berkeley, 1997, ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz.
[Pa97]V.パクソンと、「終わりから終わりへのインターネット力学の測定値と分析」、博士号論文、U.C.バークレー、1997、 ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz 。
Paxson, et. al. Informational [Page 38] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[38ページ]のRFC2330枠組み
20. Authors' Addresses
20. 作者のアドレス
Vern Paxson MS 50B/2239 Lawrence Berkeley National Laboratory University of California Berkeley, CA 94720 USA
バーン・パクソン・MS50B/2239ローレンス・カリフォルニア大学バークレー、国家の研究所カリフォルニア94720米国バークレー
Phone: +1 510/486-7504 EMail: vern@ee.lbl.gov
以下に電話をしてください。 +1 510/486-7504 メールしてください: vern@ee.lbl.gov
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 914/765-1120 メールしてください: almes@advanced.org
Jamshid Mahdavi Pittsburgh Supercomputing Center 4400 5th Avenue Pittsburgh, PA 15213 USA
第5Jamshid Mahdaviピッツバーグスーパーコンピューティングセンター4400Avenue PA15213ピッツバーグ(米国)
Phone: +1 412/268-6282 EMail: mahdavi@psc.edu
以下に電話をしてください。 +1 412/268-6282 メールしてください: mahdavi@psc.edu
Matt Mathis Pittsburgh Supercomputing Center 4400 5th Avenue Pittsburgh, PA 15213 USA
第5マットマシスピッツバーグスーパーコンピューティングセンター4400Avenue PA15213ピッツバーグ(米国)
Phone: +1 412/268-3319 EMail: mathis@psc.edu
以下に電話をしてください。 +1 412/268-3319 メールしてください: mathis@psc.edu
Paxson, et. al. Informational [Page 39] RFC 2330 Framework for IP Performance Metrics May 1998
etパクソン、アル。 IPパフォーマンス測定基準1998年5月のための情報[39ページ]のRFC2330枠組み
21. Full Copyright Statement
21. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Paxson, et. al. Informational [Page 40]
etパクソン、アル。 情報[40ページ]
一覧
スポンサーリンク
