[要約] RFC 2330は、IPパフォーマンスメトリクスのためのフレームワークを提供しており、ネットワークのパフォーマンス評価と改善を支援することを目的としています。
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
Framework for IP Performance Metrics
IPパフォーマンスメトリックのフレームワーク
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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
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
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.
このメモの目的は、運用要件領域のベンチマーク方法論ワーキンググループ（BMWG）によって開始され、IPパフォーマンスメトリックの作業によって継続される、IETFのIPパフォーマンスメトリックの取り組みによって開発される特定のメトリックの一般的なフレームワークを定義することです輸送エリアのグループ（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 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.
このドキュメントの残りの部分では、適切なメトリックと方法論の定義に関連するさまざまな問題を扱います。不完全なクロックに対処する方法。 「ホストタイム」とは異なる「ワイヤータイム」の概念。シングルトンメトリックのセットをサンプルに集約し、それらのサンプルから健全な統計を導き出す方法。これらの用語にはネットワークの動作に関する暗黙の仮定が含まれることが多いため、確率論的な用語（パケットがドロップされる確率など）でインターネットのプロパティについて考えることを避けることが推奨される理由。一般的なタイプのパケットに関してメトリックを定義するユーティリティ。 DNSホスト名よりもIPアドレスを優先する利点。 「標準形式」パケットの概念。付録では、値のセットが特定の統計分布と一致するかどうかを測定するためのアンダーソンダーリング検定について説明し、検定の実装のための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.
メモの一部のセクションでは、コメントテキストを角かっこ{コメント：...}で囲みます。この解説は単なる解説であり、それ自体はフレームワークドキュメントまたは特定のメトリックの提案の一部ではありません。場合によっては、この解説では想定される可能性のあるメトリックのいくつかのプロパティについて説明しますが、そのような説明は、フレームワークドキュメントで行われたポイントを明らかにすることのみを目的としており、特定のメトリックを示唆するものではないと想定する必要があります。
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パフォーマンスメトリックの取り組みの最も重要な目標は、インターネットトランスポートサービスのユーザーとプロバイダーが、使用または提供するインターネットコンポーネントの「クラウド」のパフォーマンスと信頼性について、共通の正確な理解を持っている状況を実現することです。
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,
+ メトリックは具体的かつ明確に定義されている必要があります。+メトリックの方法論には、反復可能なプロパティが必要です。同一の条件下で方法論が複数回使用される場合、同じ測定は同じ測定になります。 +メトリックは、同一のテクノロジーで実装されたIPクラウドにバイアスをかけないようにする必要があります。+メトリックは、同一でないテクノロジーで実装されたIPクラウドに理解された公平なバイアスを示す必要があります。または提供する、
+ The metrics must avoid inducing artificial performance goals.
+ メトリックは、人為的なパフォーマンス目標の誘導を回避する必要があります。
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".
ホストインターネットプロトコルを使用して通信できるコンピュータ。 「ルーター」を含みます。
link A single link-level connection between two (or more) hosts; includes leased lines, ethernets, frame relay clouds, etc.
link 2つ（またはそれ以上）のホスト間の単一のリンクレベルの接続。専用線、イーサネット、フレームリレークラウドなどが含まれます。
routerA host which facilitates network-level communication between hosts by forwarding IP packets.
routerIPパケットを転送することにより、ホスト間のネットワークレベルの通信を容易にするホスト。
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、...、ln、hn>形式のシーケンス。n> = 0、各hiはホスト、各liはhi-1とhiの間のリンク、各h1 .. .hn-1はルーターです。ペア<li、hi>は「ホップ」と呼ばれます。適切な運用構成では、パス内のリンクとルーターにより、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.)
サブパス与えられたパスで、サブパスは与えられたパスのサブシーケンスであり、それ自体がパスです。 （したがって、サブパスの最初と最後の要素はホストです。）
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.
雲その頂点がルーターであり、そのエッジがルーターのペアを接続するリンクである無向（おそらく循環）グラフ。正式には、イーサネット、フレームリレークラウド、および3つ以上のルーターを接続するその他のリンクは、完全に接続されたグラフエッジのメッシュとしてモデル化されます。クラウドに接続するとは、リンクを介してクラウドのルーターに接続することを意味することに注意してください。このリンク自体はクラウドの一部ではありません。
exchange A special case of a link, an exchange directly connects either a host to a cloud and/or one cloud to another cloud.
エクスチェンジリンクの特殊なケースであるエクスチェンジは、ホストをクラウドに直接、または1つのクラウドを別のクラウドに直接接続します。
cloud subpath A subpath of a given path, all of whose hosts are routers of a given cloud.
クラウドサブパス特定のパスのサブパス。そのすべてのホストが特定のクラウドのルーターです。
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、...、en、hn>のシーケンス。n> = 0、h0およびhnはホスト、各e1 ... enは交換、各C1はホストです。 。Cn-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).
運用中のインターネットには、インターネットのパフォーマンスと信頼性に関連するいくつかの数値があり、その価値を知りたいと考えています。そのような数量が慎重に指定されている場合、その数量をメトリックと呼びます。各メトリック（または密接に関連する各メトリックのグループ）ごとに個別のRFCが存在すると予想されます。
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.
+ 単位が単純なメートル（距離/長さの場合）または秒（期間の場合）で表される場合、許容可能な単位の千または千分の1に基づく適切な関連単位が許容されます。したがって、キロメートル（km）、ミリ秒（ms）、またはマイクロ秒（us）で表される距離は許可されますが、センチメートルは許可されません（接頭辞が数千または1000分の1ではないため）。 +ユニットがユニットの組み合わせで表現される場合、許容可能なユニットの数千または数千に基づく適切な関連ユニットは許容されますが、そのような数千/数千はすべて最初にグループ化する必要があります。したがって、キロメートル/秒（km / s）は許可されますが、ミリ秒/メートルは許可されません。 +情報の単位はビットです。 +メトリックプレフィックスがビットまたはビットを含む組み合わせで使用される場合、それらのプレフィックスにはメトリックの意味（10進数の1000に関連）があり、コンピューターストレージでの従来の意味（10進数の1024に関連）はありません。単位がビットを含むメトリックを定義するすべてのRFCでは、この規則に従い、読者にわかりやすくするために繰り返されます。
+ 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'.
最後に、一部のメトリックは純粋に他のメトリックに関して定義される場合があることに注意してください。このようなメトリックは「派生メトリック」と呼ばれます。
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パケットの往復遅延の測定。 +下位レベルの測定からのメトリックの投影。例：パスに沿った各ステップの伝播遅延と帯域幅の正確な測定値が与えられ、特定のサイズのIPパケットのパスの完全な遅延の予測。 +より集約された測定値のセットからの構成メトリックの推定。例：異なるサイズのIPパケットの特定の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 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.
メトリックの方法論には、それが再現可能であるという特性が必要です。方法論が同じ条件下で複数回使用された場合、一貫した測定結果が得られるはずです。
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 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.
連続性を示す少なくとも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.
さらに、実際には、特定の時間の測定に関連する条件を知る（または定量化できる）ことが実際的でない場合があることに注意してください。たとえば、高速広域ネットワークの特定のルーターでの（処理されるパケットの）瞬間的な負荷は、比較的短期間で大きく変動する可能性があり、外部の観測者が定量化することは非常に困難です。与えられたメトリックは、より再現性が高いか、連続性をよりよく示す場合があります。その場合、メトリックを指定するときに、それらの特定の統計を指定する必要があります。
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.}
最後に、いくつかの測定方法論は、測定の行為が測定しようとするパフォーマンスメトリックの値を変更しないか、わずかに変更するという意味で「保守的」である場合があります。 {コメント：たとえば、中程度の負荷がかかる広域の高速ネットワークでは、いくつかの小さな「ping」パケットを使用して遅延を測定するテストは、他の人が観察するそのネットワークの遅延特性に（それほど）干渉しない可能性があります。大きなフローを使用してフロー容量を測定するテストに関する対応するステートメントは、おそらく失敗します。}
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:
非常に適切に動作するメトリックの非常に優れた測定方法でも、エラーが発生します。ただし、このような測定方法を開発する場合は、次のことに努める必要があります。
+ 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つの手法は、ネットワークパケットを記録して正確にタイムスタンプを付ける別のコンピューターで実行されるパケットフィルター/スニファーを使用することです（以下の「ワイヤタイム」の説明を参照）。結果のトレースを分析して、テストトラフィックを評価し、測定ホストの遅延の影響を最小限に抑えるか、少なくともこれらの遅延を考慮することができます。パケットフィルター/スニファーが同じマシンで実行されている場合でも、この手法は有益である可能性があることに注意してください。そのような測定は一般に、精度の低い「アプリケーションレベル」のタイムスタンプではなく「カーネルレベル」のタイムスタンプを提供するためです。
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.
最後に、導出されたメトリック（上記で定義）または空間的または時間的構成（以下で定義）を示すメトリックは、測定の不確実性の分析に特定の機会を提供することに注意してください。
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フレームは、私たちの仕事に大きな利点をもたらします。ここでの主な目的は、分析的設定と実際的な設定の両方で一貫したネットワーク特性を生成することです。これにより、非経験的ネットワーク研究が実際のネットワーク動作とよりよく相関し、理解を深める可能性が最大化されます。
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フレームを活用します。
Such a metric will be called an 'analytically specified metric' or, more simply, an analytical metric.
このようなメトリックは、「分析的に指定されたメトリック」またはより簡単に分析メトリックと呼ばれます。
{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つのリンクを介して別のインターネットホストに移動するために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.
サイズkのパケットのリンクの帯域幅サイズkバイトのパケットの場合、IPパケットのそれらのビットのみがカウントされるビット/秒単位の容量。
routeThe path, as defined in Section 5, from A to B at a given time.
routeセクション5で定義されている、ある時点でのAからBへのパス。
hop count of a route The value 'n' of the route path. }
ルートのホップカウントルートパスの値「n」。 }
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
+ コンポーネントの基本的な機能が保持されます。+作成するメトリックに関連するコンポーネントのプロパティが保持されます。+これらのコンポーネントプロパティのサブセットが分析メトリックとして定義される可能性があります。
+ 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.
たとえば、パケット転送のコンテキストでルーターを検討する場合、入力リンクでパケットを受信し、有限サイズのFIFOパケットキューにキューイングするコンポーネントとしてルーターをモデル化し、パケットキューがいっぱいになり、それらを出力リンクに転送します。入力リンクと出力リンクの伝送速度（ビット/秒）、ルーターの待ち時間（秒）、およびパケットキューの最大サイズ（ビット）は、関連する分析メトリックです。
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）、パケットサイズ（ビット単位）（P）、および出力リンクの伝送速度（B）を含む明白な式（L + 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 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.
最後に、Aフレームの要素によって、単純化の仮定が異なる場合があることに注意してください。たとえば、パス遅延の定義をさらに進めるために使用されるルーターの抽象化は、ルーターのパケットキューを単一のFIFOキューとして扱うかもしれませんが、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フレーム要素のセットは必須である。}
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フレームにあまりうまく収まらない有用なパフォーマンスおよび信頼性メトリックがあります。たとえば、「RFC-2001準拠の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.
このような測定基準は、「経験的に指定された測定基準」またはより単純に、経験的測定基準と呼ばれます。
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フレーム。
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.}
{コメント：たとえば、パスPを通過する100バイトのパケットの遅延に関するメトリックを検討し、さらにPのパスダイジェスト<h0、e1、C1、...、en、hn>を検討します。そのような定義メトリックには、P全体の遅延が、所定のパスダイジェストの交換（ei）とクラウド（Ci）全体の対応するメトリックの合計に非常に近いという推測が含まれる場合があります。定義にはさらに、パスPとパスダイジェストのエクスチェンジとクラウドの両方に対して、対応する関係が関連するAフレームコンポーネントにどのように適用されるかについての注記が含まれます。}
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:
メトリックの定義に、パス全体のメトリックがパスのサブパス全体のメトリックに関連しているという推測が含まれている場合、その推測は、メトリックが空間構成を示しているという主張を構成します。定義には次のものが含まれます。
+ 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を使用してパスの分析を行うことに関する構成の有用性の正当化+フレームの概念がより効果的であり、+予想がどのように誤っているかについての分析。
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:
時間的構成とは、あるパスメトリックの特性を意味します。特定の時間Tにパスに適用されるメトリックは、さまざまな時間t0 <t1 <... <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を取り巻く5分間に経路Pを通過する予想流量容量のメトリックを検討し、さらに、前の4つの5分間t0のそれぞれに対応する値があるとします。 t1、t2、およびt3。このようなメトリックの定義には、時間Tのフロー容量が、t0、...、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:
メトリックの定義に、特定の時間Tのパス全体のメトリックが他の一連の時間のパス全体のメトリックに関連しているという推測が含まれている場合、その推測は、メトリックが時間的構成を示すという主張を構成します。定義には次のものが含まれます。
+ 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.
+ メトリックに適用される特定の推測、+パス上のメトリックの正確な測定を行うことに関する構成の実用的な有用性の正当化、および+を使用したパスの分析を行うことに関する構成の有用性の正当化フレームの概念がより効果的です。
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.
時間の測定は、多くのインターネット測定基準の中心にあります。このため、メトリックを測定するための方法論を設計する場合、不完全なクロックによって発生するさまざまなタイプのエラーと不確実性を理解することがしばしば重要になります。このセクションでは、クロックの特性を説明するための用語を定義し、適切な方法で対処する必要がある関連する測定の問題に触れます。
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.
ネットワークタイムプロトコル（NTP; RFC 1305）は、クロック特性を説明するための用語を定義します。これは、適切な場合に使用します[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.
特定の瞬間におけるクロックの「スキュー」は、クロックと実際の時間の間の周波数差（実際の時間に関するオフセットの1次導関数）です。
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".
RFC 1305に記載されているように、実際のクロックはスキューに多少の変動があります。つまり、真の時間に対するクロックのオフセットの2次導関数は、一般にゼロではありません。 RFC 1305に準拠して、この量をクロックの「ドリフト」として定義します。
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.
時計の「解像度」は、時計の時刻が更新される最小単位です。それは時計の不確実性に下限を与えます。 （時計は非常に細かい解像度である場合がありますが、非常に不正確である場合があります。）解像度は秒単位で定義されます。ただし、解像度は実際の時間ではなく、クロックの報告された時間に相対的です。たとえば、10 msの解像度は、クロックが0.01秒刻みで時間の概念を更新することを意味するだけであり、これは更新間の実際の時間ではありません。
{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の間の「相対オフセット」です。
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の解像度の合計である「結合解像度」です。ジョイント解像度は、一方のクロックで生成されたタイムスタンプを他方のクロックで生成されたタイムスタンプから差し引くことによって計算される時間間隔の精度の控えめな下限を示します。
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 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.
+まず、NTPの精度は、一部はNTPピアが使用するインターネットパスのプロパティ（特に遅延）に依存し、これらは正確に測定したいプロパティである可能性があるため、NTPを使用してそのような測定値を調整するのは適切ではありません。 + 2番目に、NTPはクロックの精度に焦点を当てていますが、短期的なクロックスキューとドリフトを犠牲にする可能性があります。たとえば、ホストのクロックがタイムソースに間接的に同期されている場合、同期間隔が頻繁に発生しないと、ホストは現在の正しくない時間Tiを調整する方法の問題に直面することがあります。学んだばかりの正確な時間、Ta。これを行う2つの一般的な方法は、現在の時刻をすぐにTaに設定するか、ローカルクロックの更新頻度（したがって、そのスキュー）を調整して、将来のある時点でローカル時刻Ti 'がより正確な時間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つのインターネットホスト間の一方向の遅延のサンプルを検討してください。ホスト間の実際の伝送遅延は、大陸横断パスの場合、おそらく50ミリ秒程度になる可能性があります。 2つのクロック間のスキューが0.01％、つまり10,000分の1の場合、10分の観測後、測定に導入されるエラーは60 msになります。修正しない限り、このエラーは伝送遅延測定の精度を完全に一掃するのに十分です。最後に、非同期のネットワーククロック間のスキューエラーを評価することは、未解決の研究分野であることに注意してください。 （これらの種類のエラーの検出と補正の説明については、[Pa97]を参照してください。）この欠点は、特に望ましい、GPSなどの堅固で独立したクロックソースを利用することです。
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.
多くの場合、インターネット測定は、測定を実行するためにインターネットホスト自体を使用することによって複雑になります。これらのホストは、ハードウェアまたはオペレーティングシステムの影響による遅延やボトルネックなどを引き起こす可能性があり、測定するネットワークの動作とは何の関係もありません。この問題は、ネットワークイベントのタイムスタンプがアプリケーションレベルで発生する場合に特に深刻です。
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です。
+ 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パケットはそうではないかもしれません。
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つは、エンドポイントホストの1つでパケットフィルターを実行することです。この場合、一部のパケットフィルターは、実際にネットワークに送信されたとき（ワイヤ時間）ではなく、パケットがネットワークに注入されるように「スケジュールされた」ときに対応するいくつかのパケットのタイムスタンプを受信することが確認されています。これらの2つの時間の間にはかなりの違いがある可能性があります。この問題に対処する手法は、特定のリンクを受動的に監視する別のホストでパケットフィルターを実行することです。ただし、これは一部のリンクテクノロジーでは問題になる可能性があります。パケットフィルタが示す可能性のあるエラーの種類については、[Pa97]を参照してください。最後に、IPおよびトランスポートプロトコルヘッダーのフィールドでフィルタリングを使用するため、パケットフィルターは断片化されたIPパケットの最初のフラグメントのみをキャプチャすることが多いことに注意してください。一般に、測定方法が断片化されたトラフィックの作成の複雑さを回避することを望んでいるため、パケットフィルターによって検出された存在を処理するための1つの戦略は、測定されたトラフィックが異常な形式であることを示し、パケットタイミングのさらなる分析を中止することです。}
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つのホストから別のホストへの「バルクスループット容量」の単一のインスタンスは、インスタンスが多数のインターネットパケットのタイミングの測定を含む場合でも、シングルトンメトリックとして定義される場合があります。 +「サンプル」メトリクスとは、特定のシングルトンメトリクスから、複数の異なるインスタンスをまとめて導き出したメトリクスを指します。たとえば、あるホストから別のホストへの一方向の遅延のサンプルメトリックを、1時間の測定として定義することができます。各測定は、平均間隔が1秒のポアソン間隔で行われます。
+ 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.
+ 「統計」メトリックとは、サンプルのシングルトンメトリックによって定義された値の統計を計算することにより、特定のサンプルメトリックから派生したメトリックを指します。たとえば、上記のサンプルのすべての一方向の遅延値の平均は、統計メトリックとして定義される場合があります。
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.
このセクションの残りの部分では、サンプリングと統計のいくつかのトピックを取り上げます。これらのトピックは、さまざまなメトリックの定義と測定の取り組みにとって重要になると考えています。
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.
サンプルを収集する主な理由は、測定されているメトリックにどのような種類の変動と一貫性があるかを確認することです。これらの変動は、インターネットのさまざまなポイント、またはさまざまな測定時間に関連している可能性があります。サンプルに基づいて変動を評価する場合、一般に、サンプルに「偏りがない」と仮定します。これは、サンプルの測定値を収集するプロセスがサンプルを歪めなかったため、メトリックの変動と一貫性を正確に反映しなくなったことを意味します。
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.
+ 測定対象のメトリック自体が周期的な動作を示す場合、周期が一致した場合（直接または一方が他方の倍数である場合）にサンプリングが周期的な動作の一部のみを観察する可能性があります。この問題に関連するのは、定期的なサンプリングが容易に予測できるという考えです。予測可能なサンプリングは、ネットワークコンポーネントの動作を一時的に変更して、サンプリングが変更された動作のみを確認できるメカニズムがある場合、操作の影響を受けやすくなります。 +測定行為は測定対象を混乱させる可能性があり（たとえば、ネットワークに測定トラフィックを注入すると、ネットワークの輻輳レベルが変化します）、繰り返される定期的な摂動により、ネットワークが同期状態になる可能性があります（[FJ94]を参照）。 、個々に小さな影響である可能性があるものを大幅に拡大します。
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）が指数分布（下記参照）でない限り、上記の定期的なサンプリングで説明したように、サンプリングは依然としてある程度予測可能です。
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)
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)
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.
最も純粋な形式では、ポアソンサンプリングは、独立した指数分布の間隔を生成し、各間隔が経過した後に1つの測定値を収集することによって行われます。時間Tから開始して、間隔dTでポアソンサンプリングを実行し、その間に合計N回の測定が行われる場合、これらの測定は間隔[T、T + dT]に均一に分散されることが示されます。したがって、ポアソンサンプリングを実行する別の方法は、dTとNを選択し、間隔[T、T + dT]にわたってN個のランダムサンプリング時間を均一に生成することです。 NとdTが外部で既知である場合を除いて、2つのアプローチは同等です。その場合、測定時間を予測できないという特性が弱められます（他の特性はそのままです）。 N / dTアプローチの利点は、NとdTの固定値を扱うことは、可変サイズの間隔で固定ラムダを測定する可変数を扱うよりも簡単であるということです。
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で測定される「幾何学的サンプリング」です。たとえば、リンクを介してすべてのパケットをキャプチャし、ランダムに生成された0と1の間に均一に分布する数が特定のpより小さい場合にのみ、パケットをトレースファイルに記録します。幾何学的サンプリングには、ポアソンサンプリングと同じように事前にバイアスがなく予測できないという特性があるため、特定のインターネット測定タスクに適合すれば、それも適切です。詳細については、[CPB93]を参照してください。
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.
ポアソンサンプリング間隔を生成するには、最初にシングルトン測定が平均的に行われる速度ラムダを決定します（たとえば、30秒の平均サンプリング間隔の場合、時間の単位が秒の場合、ラムダ= 1/30になります）。 。次に、一連の指数分布（疑似）乱数E1、E2、...、Enを生成します。最初の測定は時間E1で行われ、次の測定は時間E1 + E2で行われます。
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 Ui, to generate Ei one uses:
指数分布（疑似）乱数を生成する1つの手法は、0と1の間で均一に分布するU1、U2、...、Un、（疑似）乱数を生成する機能に基づいています。多くのコンピューターは、この。このようなUiが与えられた場合、Eiを生成するには次のようにします。
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.}
ここで、log（Ui）はUiの自然対数です。 {コメント：この手法は、特定の分布で乱数を生成するためのより一般的な「逆変換」メソッドのインスタンスです。}
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つの異なる方法があり、ここでは方法1〜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. E1を生成し、その間待機します。 2.測定を実行します。 3. E2を生成し、その間待機します。 4.測定を実行します。 5. E3を生成し、その間待機します。 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.
このアプローチの問題は、「測定を実行する」ステップ自体に時間がかかるため、サンプリングが時間E1、E1 + E2などではなく、E1、E1 + M1 + E2などで行われることです。 Miは、i番目の測定に必要な時間です。 Miが1 / lambdaと比較して非常に小さい場合、この手法によって導入される潜在的なエラーも同様に小さくなります。 Miが1 / lambdaの無視できない割合になると、潜在的なエラーが増加します。
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. E1を生成し、その間待機します。 2.測定を実行し、M1の測定にかかった時間を測定します。 3. E2を生成し、E2-M1時間待機します。 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.) Method 3 is generating a schedule of measurement times E1, E1+E2, etc., and then sticking to it:
このアプローチは、E {i + 1}> = Miである限り問題なく機能します。しかし、E {i + 1} <Miの場合、適切な時間待機することは不可能です。 （このケースは、2つの測定を同時に実行する必要があることに注意してください。）方法3は、測定時間E1、E1 + E2などのスケジュールを生成し、それに固執します。
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. E1、E2、...、Enを生成します。 2. Ti = E1 + ... + Eiとして、測定時間T1、T2、...、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.
方法3は、同時測定を可能にすることで、方法1と2の欠点を回避します。ただし、同時測定が相互に干渉する場合、方法3は何の利点も得ず、実際には方法1または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 / lambdaをはるかに下回っている場合は、3つのいずれでも十分です。 Miが1 / lambda未満の場合、それほど大きくない場合は、方法2が方法1よりも推奨されます。同時測定が相互に干渉しない場合は、方法3が推奨されますが、実装がかなり困難になる場合があります。
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 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つは、自己整合性をチェックすることです。このようなチェックは、測定の観測値と測定プロセス自体が使用する値の両方に適用されます。前者の簡単な例は、往復時間を計算するときに、それが負かどうかを確認する必要があることです。負の時間間隔は物理的ではないので、それが負の場合は、検出によりエラーが直ちにフラグされます。 *次に、この種のエラーを調査する必要があります！*エラーがどこにあるのかを特定することは非常に重要です。たとえば、測定中にクロックが別のソースと同期するプロセスで逆に設定されたため、往復時間が負の値である可能性があります。しかし、測定プログラムがその計算の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つが他のクロックに対して相対的に歪んでいるというものです。別の解釈は、傾きは実際には本物のネットワーク効果によるものであるというものです。どちらが実際にそうであるかを決定することは、多くの場合非常に明るいでしょう。 （相対クロックスキューと本物のネットワーク効果の区別については、[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.
最後に、インターネットメトリックのポアソンサンプリングに本当に関連するのは、多くの場合、測定の開始時ではなく、測定プロセスに対応する通信時間です。これらは、測定を実行するために使用されるホストの複雑さのために、異なる可能性があります。したがって、疑似乱数ジェネレータとそれに続くアルゴリズムに完全に信頼している人でも、各測定手順の仮定を可能な限りテストする方法を検討することをお勧めします。
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つの方法は、統計的分布として（非公式にはパーセンタイルとして）です。これを行うには、いくつかのわずかに異なる方法があります。このセクションでは、これらの説明を統一するために標準定義を定義します。
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.
スカラー測定値のセットの「経験的分布関数」（EDF）は関数F（x）であり、任意のxに対して、<= xであった合計測定値の分数の割合を示します。 xが観測された最小値より小さい場合、F（x）は0です。観測された最大値以上の場合、F（x）は1です。
For example, given the 6 measurements:
たとえば、6つの測定値があるとします。
-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％、およびF（-2）= 2/6> = 25％であるため、25パーセンタイルは-2です。 100パーセンタイルは18です。 15パーセンタイルと同様に、0パーセンタイルは無限大です。
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値を観測する確率と等しい点Xとして定義されます。一連の観測値の中央値を推定する場合、推定値は観測数Nが奇数か偶数かによって異なります。
+ 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".
通常、「推定された」という用語は「推定された中央値」という句から削除され、この値は単に「中央値」と呼ばれます。
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.}
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]を参照してください。そのリファレンスは、Anderson-Darling 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.
適合度テストの性質は、最初に「有意水準」を選択することであることを理解することが重要です。これは、特定の測定セットのEDFが特定の値と一致しないことをテストが誤って宣言する確率です実際に測定が実際にその分布を反映している場合の分布。
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個のサンプルが検定に不合格であると見なされた場合、それらのサンプルはすべて、検定されている分布と一致しています。かなり多くのサンプルが検定に失敗した場合は、サンプルが検定対象の分布と一致しているという仮定を拒否する必要があります。テストに失敗するサンプルの数が大幅に少ない場合、そのサンプルは、分布に適合しないように細かく設定されている可能性があります。同様に、いくつかの適合度テスト（Anderson-Darlingを含む）は、特定のサンプルがドクター処理された可能性が高いかどうかを検出できます。この場合も5％の有意性を使用します。つまり、テストは、与えられた正直なサンプルが5％の確率で「真実であるには良すぎる」ことを報告するので、テストがこの発見を20回のうちの1回よりも大幅に頻繁に報告する場合、異常なことを示しています。発生しています。
The appendix gives sample C code for implementing the Anderson-Darling test, as well as further discussing its use.
付録では、Anderson-Darlingテストを実装するためのサンプルCコードと、その使用についてさらに説明します。
See [Pa94] for a discussion of goodness-of-fit and closeness-of-fit tests in the context of network measurement.
ネットワーク測定のコンテキストでの適合度テストと適合度テストの説明については、[Pa94]を参照してください。
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とB間のパケット損失率」に関するメトリックを定義します。 （最初の定義で得られる測定値は「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.
この区別の理由は次のとおりです。確率の観点から定義が行われる場合、測定される行動の確率モデルに関する定義には、多くの場合、隠れた仮定があります。メトリック定義で確率を回避する基本的な目標は、これらの隠された仮定によって定義にバイアスをかけることを回避することです。
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.
たとえば、簡単に隠された仮定は、キューイングオーバーフローによるネットワークコンポーネントでのパケット損失は、特定の確率で特定のパケットに発生するものとして説明できるということです。ただし、今日のインターネットでは、キューイングドロップは実際には通常*決定論的*であり、確率論的に記述する必要があると仮定すると、一連のパケット間のキューイングドロップ間の重要な相関関係が不明瞭になる可能性があります。したがって、確率的な仮定を暗黙的に定義に潜入させるよりも、確率的な仮定に明示的に注意する方が適切です。
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メトリックに関連する確率モデルによって使用される確率を推定するために、たとえば、ランダムサンプリングを引き続き使用します。また、確率的なメトリックが本当に適切である場合（たとえば、特定のタイプのラインノイズによって引き起こされる伝送エラーをモデル化する場合など）の可能性も除外しません。
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接続性メトリックを検討してください。たとえば、既知のTCPポートまたは予約されていないUDPポート宛てのパケット、無効なIPチェックサムを持つパケット、またはTTLが16のパケットの接続に関心があるかどうかによって、異なる結果が得られます。状況によっては、これらの区別が非常に興味深いものになります（たとえば、ファイアウォールが存在する場合、または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のパケット」という一般的な概念を導入します。この場合、一部のコンテキストではPが明示的に定義され（つまり、正確にどのタイプのパケットを意味するか）、部分的に定義されます（たとえば、「ペイロードはBオクテット」）、または左ジェネリック。したがって、一般的な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- 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.
メトリックの値がメトリックに含まれるパケットのタイプに依存する場合は常に、メトリックの名前には特定のタイプまたは「type-P」などのフレーズが含まれます。したがって、「IP-接続」メトリックを定義するのではなく、「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を同等に扱うかどうかを知ることは非常に有用です。その場合、これらのタイプのパケットのいずれかを使用して、コンポーネントの後続の測定を行うことができます。これは、Cを決定しようとするメトリックまたはメトリックのスイートを考案することを示唆しています。
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.
インターネットを経由するパスのメトリックを検討する場合、多くの場合、それをインターネットホストH1からホストH2へのパスと見なすのが自然です。ただし、インターネットホストは複数のネットワークに接続できるため、これらの用語の定義はあいまいになる可能性があります。この場合、メトリックの結果は、これらのネットワークのどれが実際に使用されているかによって異なります。
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アドレスに関して定義する必要があります。インターネットを介した単方向パスの一般的なケースでは、「Src」という用語を使用してパスの開始のIPアドレスを示し、「Dst」を使用して終了のIPアドレスを示します。
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フラグメントではありません。 +送信元アドレスと宛先アドレスは、問題のホストに対応しています。
+ 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を持っているか、最大TTLが255です。+特に明記されていない限り、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).
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フィールドが0に設定された標準形式のパケットのIPタイプP接続性、またはより簡潔に言えば、「IPタイプP接続性」として定義することを想像するかもしれません。標準形式は慣例によりすでに暗示されているため、IP TOSフィールドを0に設定します。
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ネットワークを介して送信できないことに注意してください。
The comments of Brian Carpenter, Bill Cerveny, Padma Krishnaswamy Jeff Sedayao and Howard Stanislevic are appreciated.
ブライアンカーペンター、ビルサーヴェニー、パドマクリシュナスワミージェフセダヤオ、ハワードスタニスレヴィックのコメントを歓迎します。
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.
このドキュメントは、インターネット測定に関連する定義と概念に関するものです。測定手順については、健全な測定に役立つ原則について、大まかにのみ説明します。そのため、説明されているトピックは、インターネットまたはその上で実行されるアプリケーションのセキュリティには影響しません。
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.
とはいえ、インターネット測定を実施すると、セキュリティとプライバシーの両方の問題が発生する可能性があることを認識しておく必要があります。トラフィックがネットワークに注入されるアクティブな手法は、正当な測定アクティビティを装ったサービス拒否攻撃に悪用される可能性があります。既存のトラフィックが記録および分析されるパッシブ技術は、インターネットトラフィックのコンテンツを意図しない受信者に公開する可能性があります。したがって、各メトリックと方法論の定義には、セキュリティに関する考慮事項の対応する説明を含める必要があります。
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:
以下では、一連の値が特定の統計分布と一致するかどうかを判断するためのアンダーソンダーリング検定統計（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)
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）
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.
どちらも最初の引数として、テストするn個の値の配列xを取ります。 （戻り時に、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の間の値です。ルーチンを正しく使用することは、テストする有意水準のしきい値を事前に選択することです。一般的に、これも0.05であり、これも上記のように5％に対応します。その後、ルーチンがこのしきい値よりも厳密に小さい値を返した場合、データは、推定された分布と矛盾していると見なされ、*有意水準に対応するエラーが発生します*。つまり、有意水準5％の場合、推定分布から実際に抽出された時間データの5％は誤って不整合と見なされます。
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.
したがって、これらのルーチンが頻繁に使用される場合、データが破損していない場合でも、実際に時々障害が発生することを覚えておくことが重要です。
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つの値のセットのどちらが推定分布に「よりよく」適合するかを判断するためにそれらを比較することは不確実であるということです。そのようなテストは、[Pa94]で説明されているラムダ^ 2メトリックなどの「近似度メトリック」を使用して行う必要があります。
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).
提供されているルーチンは、既知のパラメーターを持つ指数分布および一様分布用ですが、一般に、既知のパラメーターを持つ任意の分布に対応するルーチンを作成するのは簡単です。 A2テストの中心は、一連の値が0と1の間の均一分布と一致するかどうかをテストするために計算された統計にあります。これは、Unif（0、1）と呼ばれます。値のセットXが特定の分布G（x）と一致するかどうかをテストする場合、最初にY = G_inverse（X）を計算します。XがG（x）に従って実際に分布している場合、Yは分布しますUnif（0、1）によると、したがって、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の値が生成される可能性があることに注意してください。このような値は、XがG（x）に従って実際に分布している場合は発生しませんが、そうでない場合は簡単に発生します。後者の場合、いずれかの値が（0..1）の外側にあると浮動小数点例外が発生する可能性があるため、中央のA2統計の計算を回避する必要があります。したがって、ルーチンはこの可能性をチェックし、遭遇した場合は-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テストは十分に敏感なので、実際のデータのセットが十分に大きい場合、データの分布への適合におけるわずかな欠陥を検出できるため、テストはほとんど常に失敗します。
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.
*/
#include <stdio.h>
#include <stdlib.h>
#include <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);
/* 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);
/* 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);
/* 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);
/* 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;
if (d1 < d2)
return -1;
else if (d1 > d2)
return 1;
else
return 0;
}
double
compute_A2(double z[], int n)
{
int i;
double sum = 0.0;
if ( n < 5 )
/* Too few values. */
return -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;
/* 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;
}
double
A2_significance(double A2)
{
/* Page 105 of D'Agostino and Stephens. */
if (A2 < 0.0)
return A2; /* Bogus A2 value - propagate it. */
/* 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;
/* 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;
}
double
exp_A2_known_mean(double x[], int n, double mean)
{
int i;
double A2;
/* Sort the first n values. */
qsort(x, n, sizeof(x[0]), compare_double);
/* 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);
}
/* Now make the A^2 test to see if they're truly uniform. */
A2 = compute_A2(x, n);
return A2_significance(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;
/* Sort the first n values. */
qsort(x, n, sizeof(x[0]), compare_double);
/* Transform Unif(min_val, max_val) to Unif(0,1). */
for (i = 0; i < n; ++i)
x[i] = (x[i] - min_val) / range;
/* Now make the A^2 test to see if they're truly uniform. */
A2 = compute_A2(x, n);
return A2_significance(A2);
}
double
random_exponential(double mean)
{
return -mean * log1p(-drand48());
}
[AK97] G. Almes and S. Kalidindi, "A One-way Delay Metric for IPPM", Work in Progress, November 1997.
[AK97] G.アルメスとS.カリディンディ、「IPPMの一方向遅延メトリック」、作業中、1997年11月。
[BM92] I. Bilinskis and A. Mikelsons, Randomized Signal Processing, Prentice Hall International, 1992.
[BM92] I. BilinskisおよびA. Mikelsons、ランダム化信号処理、Prentice Hall International、1992年。
[DS86] R. D'Agostino and M. Stephens, editors, Goodness-of-Fit Techniques, Marcel Dekker, Inc., 1986.
[DS86] R. D'AgostinoとM. Stephens、編集者、Goodness-of-Fitテクニック、Marcel Dekker、Inc.、1986。
[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.クラフィー、G。ポリゾス、H-W。ブラウン、「サンプリング手法のネットワークトラフィック特性評価への応用」、Proc。 SIGCOMM '93、pp。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.ジェイコブソン、「定期的なルーティングメッセージの同期」、IEEE / ACM Transactions on Networking、2（2）、pp。122-136、1994年4月。
[Mi92] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[Mi92] Mills、D。、「Network Time Protocol（Version 3）Specification、Implementation and Analysis」、RFC 1305、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. Paxson、「経験的に導出された広域TCP接続の分析モデル」、IEEE / ACM Transactions on Networking、2（4）、pp。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
[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.パクソン、「エンドツーエンドインターネットダイナミクスの測定と分析」、Ph.D。論文、米国バークレー、1997、ftp：//ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz。
Vern Paxson MS 50B/2239 Lawrence Berkeley National Laboratory University of California Berkeley, CA 94720 USA
Vern Paxson MS 50B / 2239ローレンスバークレー国立研究所カリフォルニア大学バークレー、カリフォルニア94720米国
Phone: +1 510/486-7504
EMail: vern@ee.lbl.gov
Guy Almes Advanced Network & Services, Inc. 200 Business Park Drive Armonk, NY 10504 USA
Guy Almes Advanced Network＆Services、Inc. 200 Business Park Drive Armonk、NY 10504 USA
Phone: +1 914/765-1120
EMail: almes@advanced.org
Jamshid Mahdavi Pittsburgh Supercomputing Center 4400 5th Avenue Pittsburgh, PA 15213 USA
Jamshid Mahdaviピッツバーグスーパーコンピューティングセンター4400 5th Avenueピッツバーグ、ペンシルバニア州15213米国
Phone: +1 412/268-6282
EMail: mahdavi@psc.edu
Matt Mathis Pittsburgh Supercomputing Center 4400 5th Avenue Pittsburgh, PA 15213 USA
Matt Mathis Pittsburgh Supercomputing Center 4400 5th Avenue Pittsburgh、PA 15213 USA
Phone: +1 412/268-3319
EMail: mathis@psc.edu
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。