[要約] RFC 7312は、IPパフォーマンスメトリクス(IPPM)のための高度なストリームおよびサンプリングフレームワークに関するものです。このRFCの目的は、ネットワークのパフォーマンス測定におけるストリームとサンプリングの効果的な使用方法を提供することです。

Internet Engineering Task Force (IETF)                         J. Fabini
Request for Comments: 7312               Vienna University of Technology
Updates: 2330                                                  A. Morton
Category: Informational                                        AT&T Labs
ISSN: 2070-1721                                              August 2014
        

Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)

IPパフォーマンスメトリック(IPPM)用の高度なストリームおよびサンプリングフレームワーク

Abstract

概要

To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo updates the IP Performance Metrics (IPPM) Framework, RFC 2330, with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them; otherwise, unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics.

最新のネットワークで再現性のある結果を得るには、テスト記述に、テストパケットのType-Pとして指定された側面も拡張する拡張ストリームパラメーターフレームワークが必要です。このメモは、IPパフォーマンスメトリック(IPPM)フレームワーク、RFC 2330を更新し、測定方法とテストに関する高度な考慮事項を記載しています。既存のフレームワークは主に確定的な接続を想定しており、単一のテストストリームが他のフローと集約されたときにパスの特性を表すことになります。ネットワークは進化しており、テストストリームの説明はネットワークとともに進化する必要があります。そうしないと、予期しないネットワーク機能が測定されたパフォーマンスを支配する可能性があります。このメモは、ネットワークの特性化とIPPMメトリックを使用したアプリケーション設計のサポートの両方のための新しいストリームパラメータについて説明しています。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7312.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7312で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(http://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

目次

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Definition: Reactive Path Behavior  . . . . . . . . . . .   4
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   5
   2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  New or Revised Stream Parameters  . . . . . . . . . . . . . .   5
     3.1.  Test Packet Type-P  . . . . . . . . . . . . . . . . . . .   6
       3.1.1.  Multiple Test Packet Lengths  . . . . . . . . . . . .   7
       3.1.2.  Test Packet Payload Content Optimization  . . . . . .   7
     3.2.  Packet History  . . . . . . . . . . . . . . . . . . . . .   8
     3.3.  Access Technology Change  . . . . . . . . . . . . . . . .   8
     3.4.  Time-Slotted Randomness Cancellation  . . . . . . . . . .   9
   4.  Quality of Metrics and Methodologies  . . . . . . . . . . . .  10
     4.1.  Revised Definition of Repeatability . . . . . . . . . . .  10
     4.2.  Continuity No Longer an Alternative Repeatability
           Criterion . . . . . . . . . . . . . . . . . . . . . . . .  11
     4.3.  Metrics Should Be Actionable  . . . . . . . . . . . . . .  12
     4.4.  It May Not Be Possible To Be Conservative . . . . . . . .  13
     4.5.  Spatial and Temporal Composition Support Unbiased
           Sampling  . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.6.  When to Truncate the Poisson Sampling Distribution  . . .  13
   5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  14
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  16
        
1. Introduction
1. はじめに

The IETF IPPM working group first created a framework for metric development in [RFC2330]. This framework has stood the test of time and enabled development of many fundamental metrics, while only being updated once in a specific area [RFC5835].

IETF IPPMワーキンググループは、最初に[RFC2330]でメトリック開発のフレームワークを作成しました。このフレームワークは時の試練に耐え、多くの基本的なメトリックの開発を可能にしましたが、特定の領域[RFC5835]で一度だけ更新されました。

The IPPM framework [RFC2330] generally relies on several assumptions, one of which is not explicitly stated but assumed: lightly loaded paths conform to the linear "serialization delay = packet size / capacity" equation, and they are state-less or history-less (with some exceptions, e.g., firewalls are mentioned). However, this does not hold true for many modern network technologies, such as reactive paths (those with demand-driven resource allocation) and links with time-slotted operation. Per-flow state can be observed on test packet streams, and such treatment will influence network characterization if it is not taken into account. Flow history will also affect the performance of applications and be perceived by their users.

IPPMフレームワーク[RFC2330]は、一般的にいくつかの仮定に依存しています。その1つは明示的には述べられていませんが、仮定されています。軽負荷のパスは、線形の「シリアル化遅延=パケットサイズ/容量」の方程式に準拠し、状態なしまたは履歴なしです。 (いくつかの例外を除いて、例えば、ファイアウォールが言及されています)。ただし、これは、リアクティブパス(デマンド駆動型のリソース割り当てを使用するパス)やタイムスロット操作のリンクなど、多くの最新のネットワークテクノロジーには当てはまりません。フローごとの状態は、テストパケットストリームで確認できます。このような処理は、考慮されない場合、ネットワークの特性に影響します。フロー履歴もアプリケーションのパフォーマンスに影響し、ユーザーに知覚されます。

Moreover, Sections 4 and 6.2 of [RFC2330] explicitly recommend repeatable measurement metrics and methodologies. Measurements in today's access networks illustrate that methodological guidelines of [RFC2330] must be extended to capture the reactive nature of these networks. There are proposed extensions to allow methodologies to fulfill the continuity requirement stated in Section 6.2 of [RFC2330], but it is impossible to guarantee they can do so. Practical measurements confirm that some link types exhibit distinct responses to repeated measurements with identical stimulus, i.e., identical traffic patterns. If feasible, appropriate fine-tuning of measurement traffic patterns can improve measurement continuity and repeatability for these link types as shown in [IBD].

さらに、[RFC2330]のセクション4および6.2は、繰り返し可能な測定基準と方法論を明示的に推奨しています。今日のアクセスネットワークでの測定は、[RFC2330]の方法論のガイドラインを拡張して、これらのネットワークの反応性を捉える必要があることを示しています。 [RFC2330]のセクション6.2に記載されている継続性の要件を満たす方法を可能にする拡張案が提案されていますが、それらが実現できることを保証することは不可能です。実際の測定では、一部のリンクタイプが、同じ刺激、つまり同じトラフィックパターンで繰り返される測定に対して明確な応答を示すことが確認されています。可能であれば、測定トラフィックパターンを適切に微調整すると、[IBD]に示すように、これらのリンクタイプの測定の連続性と再現性を向上させることができます。

This memo updates the IPPM framework [RFC2330] with advanced considerations for measurement methodology and testing. We note that the scope of IPPM work at the time of the publication of [RFC2330] (and during more than a decade that followed) was limited to active techniques or those that generate packet streams that are dedicated to measurement and do not monitor user traffic. This memo retains that same scope.

このメモは、IPPMフレームワーク[RFC2330]を更新し、測定方法とテストに関する高度な考慮事項を記載しています。 [RFC2330]の発行時(およびその後10年以上)のIPPM作業の範囲は、アクティブな手法、または測定専用でユーザートラフィックを監視しないパケットストリームを生成する手法に限定されていたことに注意します。このメモは同じスコープを保持します。

We stress that this update of [RFC2330] does not invalidate or require changes to the analytic metric definitions prepared in the IPPM working group to date. Rather, it adds considerations for active measurement methodologies and expands the importance of existing conventions and notions in [RFC2330], such as "packets of Type-P".

この[RFC2330]の更新では、IPPMワーキンググループでこれまでに作成された分析メトリック定義を無効にしたり、変更したりする必要はありません。むしろ、アクティブな測定方法に対する考慮事項を追加し、「タイプPのパケット」など、[RFC2330]の既存の規則と概念の重要性を拡張します。

Among the evolutionary networking changes is a phenomenon we call "reactive behavior", as defined below.

進化するネットワークの変化の中には、以下で定義するように、私たちが「反応行動」と呼ぶ現象があります。

1.1. Definition: Reactive Path Behavior
1.1. 定義:リアクティブパスの動作

Reactive path behavior will be observable by the test packet stream as a repeatable phenomenon where packet transfer performance characteristics *change* according to prior observations of the packet flow of interest (at the reactive host or link). Therefore, reactive path behavior is nominally deterministic with respect to the flow of interest. Other flows or traffic load conditions may result in additional performance-affecting reactions, but these are external to the characteristics of the flow of interest.

リアクティブパスの動作は、テストパケットストリームによって、対象のパケットフローの(リアクティブホストまたはリンクでの)以前の観測に応じてパケット転送パフォーマンス特性が*変化*する再現可能な現象として観測できます。したがって、リアクティブパスの動作は、対象のフローに関して名目上決定的です。他のフローまたはトラフィックの負荷状態により、パフォーマンスに影響を与える追加の反応が発生する可能性がありますが、これらは対象のフローの特性の外部にあります。

In practice, a sender may not have absolute control of the ingress packet stream characteristics at a reactive host or link, but this does not change the deterministic reactions present there. If we measure a path, the arrival characteristics at the reactive host/link are determined by the sending characteristics and the transfer characteristics of intervening hosts and links. Identical traffic patterns at the sending host might generate different patterns at the input of the reactive host/link due to impairments in the intermediate subpath. The reactive host/link is expected to provide a deterministic response on identical input patterns (composed of all flows, including the flow of interest).

実際には、送信側は、リアクティブホストまたはリンクでの入力パケットストリーム特性を完全に制御できない場合がありますが、これにより、そこに存在する確定的な反応は変わりません。パスを測定する場合、リアクティブホスト/リンクでの到着特性は、介在するホストとリンクの送信特性と転送特性によって決定されます。送信側ホストでの同一のトラフィックパターンは、中間サブパスの障害により、リアクティブホスト/リンクの入力で異なるパターンを生成する場合があります。リアクティブホスト/リンクは、同一の入力パターン(対象のフローを含むすべてのフローで構成される)で確定的な応答を提供することが期待されています。

Other than the size of the payload at the layer of interest and the header itself, packet content does not influence the measurement. Reactive behavior at the IP layer is not influenced by the TCP ports in use, for example. Therefore, the indication of reactive behavior must include the layer at which measurements are instituted.

対象のレイヤーのペイロードのサイズとヘッダー自体を除いて、パケットの内容は測定に影響しません。たとえば、IP層での反応動作は、使用中のTCPポートの影響を受けません。したがって、反応行動の指標には、測定を開始する層を含める必要があります。

Examples include links with Active/Inactive state detectors, and hosts or links that revise their traffic serving and forwarding rates (up or down) based on packet arrival history.

例には、アクティブ/非アクティブ状態検出機能を備えたリンク、およびパケットの到着履歴に基づいてトラフィックの提供率と転送率(アップまたはダウン)を修正するホストまたはリンクが含まれます。

Although difficult to handle from a measurement point of view, reactive paths' entities are usually designed to improve overall network performance and user experience, for example, by making capacity available to an active user. Reactive behavior may be an artifact of solutions to allocate scarce resources according to the demands of users; thus, it is an important problem to solve for measurement and other disciplines, such as application design.

測定の観点から処理するのは難しいですが、通常、リアクティブパスのエンティティは、たとえばアクティブなユーザーが容量を利用できるようにすることで、全体的なネットワークパフォーマンスとユーザーエクスペリエンスを向上させるように設計されています。反応的な行動は、ユーザーの要求に応じて希少なリソースを割り当てるためのソリューションの成果物かもしれません。したがって、測定やアプリケーション設計などの他の分野で解決することは重要な問題です。

1.2. Requirements Language
1.2. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

2. Scope
2. 範囲

The purpose of this memo is to foster repeatable measurement results in modern networks by highlighting the key aspects of test streams and packets and making them part of the IPPM framework.

このメモの目的は、テストストリームとパケットの主要な側面を強調し、それらをIPPMフレームワークの一部にすることにより、最新のネットワークで繰り返し可能な測定結果を促進することです。

The scope is to update key sections of [RFC2330], adding considerations that will aid the development of new measurement methodologies intended for today's IP networks. Specifically, this memo describes useful stream parameters that complement the parameters discussed in Section 11.1 of [RFC2330] and the parameters described in Section 4.2 of [RFC3432] for periodic streams.

その範囲は、[RFC2330]の主要なセクションを更新し、今日のIPネットワークを対象とした新しい測定方法の開発を支援する考慮事項を追加することです。具体的には、このメモでは、[RFC2330]のセクション11.1で説明されているパラメータと、定期的なストリームの[RFC3432]のセクション4.2で説明されているパラメータを補完する有用なストリームパラメータについて説明します。

The memo also provides new considerations to update the criteria for metrics in Section 4 of [RFC2330], the measurement methodology in Section 6.2 of [RFC2330], and other topics related to the quality of metrics and methods (see Section 4).

このメモには、[RFC2330]のセクション4のメトリックの基準、[RFC2330]のセクション6.2の測定方法、およびメトリックとメソッドの品質に関連するその他のトピックを更新するための新しい考慮事項も記載されています(セクション4を参照)

Other topics in [RFC2330] that might be updated or augmented are deferred to future work. This includes the topics of passive and various forms of hybrid active/passive measurements.

[RFC2330]の他のトピックは、更新または拡張される可能性があるため、将来の作業に委ねられます。これには、パッシブおよびさまざまな形式のハイブリッドアクティブ/パッシブ測定のトピックが含まれます。

3. New or Revised Stream Parameters
3. 新規または改訂されたストリームパラメータ

There are several areas where measurement methodology definition and test result interpretation will benefit from an increased understanding of the stream characteristics and the (possibly unknown) network conditions that influence the measured metrics.

測定方法の定義とテスト結果の解釈が、測定されたメトリックに影響を与えるストリームの特性と(おそらく不明な)ネットワーク条件の理解を深めることで恩恵を受けるいくつかの領域があります。

1. Network treatment depends on the fullest extent on the "packet of Type-P" definition in [RFC2330], and has for some time.

1. ネットワークの扱いは、[RFC2330]の「Type-Pのパケット」の定義に完全に依存し、しばらくの間はそうです。

* State is often maintained on the per-flow basis at various points in the path, where "flows" are determined by IP and other layers. Significant treatment differences occur with the simplest of Type-P parameters: packet length. Use of multiple lengths is RECOMMENDED.

* 多くの場合、状態はパスのさまざまなポイントでフローごとに維持されます。ここで、「フロー」はIPレイヤーと他のレイヤーによって決定されます。 Type-Pの最も単純なパラメーターであるパケット長では、処理に大きな違いが生じます。複数の長さを使用することをお勧めします。

* Payload content optimization (compression or format conversion) in intermediate segments breaks the convention of payload correspondence when correlating measurements are made at different points in a path.

* 中間のセグメントでのペイロードコンテンツの最適化(圧縮またはフォーマット変換)は、パス内の異なるポイントで相関測定が行われるときに、ペイロード対応の規則を破ります。

2. Packet history (instantaneous or recent test rate or inactivity, also for non-test traffic) profoundly influences measured performance, in addition to all the Type-P parameters described in [RFC2330].

2. [RFC2330]で説明されているすべてのType-Pパラメータに加えて、パケット履歴(瞬間的または最近のテストレートまたは非アクティブ、非テストトラフィックも同様)が測定パフォーマンスに大きく影響します。

3. Access technology may change during testing. A range of transfer capacities and access methods may be encountered during a test session. When different interfaces are used, the host seeking access will be aware of the technology change, which differentiates this form of path change from other changes in network state. Section 14 of [RFC2330] addresses the possibility that a host may have more than one attachment to the network, and also that assessment of the measurement path (route) is valid for some length of time (in Sections 5 and 7 of [RFC2330]). Here, we combine these two considerations under the assumption that changes may be more frequent and possibly have greater consequences on performance metrics.

3. テスト中にアクセス技術が変更される場合があります。テストセッション中に、さまざまな転送容量とアクセス方法が発生する場合があります。異なるインターフェイスが使用されている場合、アクセスを求めるホストはテクノロジーの変化を認識します。これにより、この形式のパスの変化がネットワーク状態の他の変化と区別されます。 [RFC2330]のセクション14では、ホストがネットワークに複数のアタッチメントを持つ可能性があり、測定パス(ルート)の評価が一定期間有効である([RFC2330]のセクション5および7) )。ここでは、これらの2つの考慮事項を組み合わせて、変更がより頻繁に行われ、パフォーマンスメトリックにより大きな影響を与える可能性があることを前提としています。

4. Paths including links or nodes with time-slotted service opportunities represent several challenges to measurement (when the service time period is appreciable):

4. タイムスロット化されたサービス機会を持つリンクまたはノードを含むパスは、測定に対するいくつかの課題を表しています(サービス期間がかなり長い場合)。

* Random/unbiased sampling is not possible beyond one such link in the path.

* パス内のそのようなリンクの1つを越えて、ランダム/不偏サンプリングはできません。

* The above encourages a segmented approach to end-to-end measurement, as described in [RFC6049] for Network Characterization (as defined in [RFC6703]), to understand the full range of delay and delay variation on the path. Alternatively, if application performance estimation is the goal (also defined in [RFC6703]), then a stream with unbiased or known-bias properties [RFC3432] may be sufficient.

* 上記は、[RFC6703]で定義されている[RFC6703]で定義されているネットワーク特性評価の[RFC6049]で説明されているように、エンドツーエンド測定へのセグメント化アプローチを推奨し、パスの遅延と遅延変動の全範囲を理解します。あるいは、アプリケーションパフォーマンスの見積もりが目標である場合([RFC6703]でも定義されている)、バイアスのない、または既知のバイアスプロパティ[RFC3432]を持つストリームで十分な場合があります。

* Multi-modal delay variation makes central statistics unimportant; others must be used instead.

* マルチモーダル遅延変動により、中央統計が重要ではなくなります。代わりに使用する必要があります。

Each of these topics is treated in detail below.

これらの各トピックについて、以下で詳しく説明します。

3.1. Test Packet Type-P
3.1. テストパケットType-P

We recommend two Type-P parameters to be added to the factors that have impact on path performance measurements, namely packet length and payload type. Carefully choosing these parameters can improve measurement methodologies in their continuity and repeatability when deployed in reactive paths.

パスパフォーマンス測定に影響を与える要素、つまりパケット長とペイロードタイプに2つのType-Pパラメータを追加することをお勧めします。これらのパラメーターを注意深く選択することで、反応経路に配置した場合の連続性と再現性の測定方法を改善できます。

3.1.1. Multiple Test Packet Lengths
3.1.1. 複数のテストパケット長

Many instances of network characterization using IPPM metrics have relied on a single test packet length. When testing to assess application performance or an aggregate of traffic, benchmarking methods have used a range of fixed lengths and frequently augmented fixed-size tests with a mixture of sizes, or Internet Mix (IMIX) as described in [RFC6985].

IPPMメトリックを使用したネットワーク特性評価の多くのインスタンスは、単一のテストパケット長に依存しています。アプリケーションのパフォーマンスやトラフィックの総計を評価するためにテストする場合、ベンチマーク方法は、[RFC6985]で説明されているように、さまざまなサイズの固定長テストと、サイズが混在する固定サイズのテスト、またはインターネットミックス(IMIX)を頻繁に使用してきました。

Test packet length influences delay measurements, in that the IPPM one-way delay metric [RFC2679] includes serialization time in its first-bit to last-bit timestamping requirements. However, different sizes can have a larger influence on link delay and link delay variation than serialization would explain alone. This effect can be non-linear and change the instantaneous network performance when a different size is used, or the performance of packets following the size change.

IPPM一方向遅延メトリック[RFC2679]は、最初のビットから最後のビットのタイムスタンプ要件にシリアル化時間を含めるという点で、テストパケット長は遅延測定に影響します。ただし、異なるサイズは、シリアル化だけで説明するよりも、リンク遅延とリンク遅延の変動に大きな影響を与える可能性があります。この影響は非線形であり、異なるサイズが使用された場合の瞬間的なネットワークパフォーマンス、またはサイズ変更後のパケットのパフォーマンスを変化させる可能性があります。

Repeatability is a main measurement methodology goal as stated in Section 6.2 of [RFC2330]. To eliminate packet length as a potential measurement uncertainty factor, successive measurements must use identical traffic patterns. In practice, a combination of random payload and random start time can yield representative results as illustrated in [IRR].

[RFC2330]のセクション6.2に記載されているように、再現性は測定方法論の主要な目標です。パケット長を潜在的な測定の不確実要素として排除するには、連続する測定で同一のトラフィックパターンを使用する必要があります。実際には、ランダムなペイロードとランダムな開始時間の組み合わせにより、[IRR]に示すような代表的な結果が得られます。

3.1.2. Test Packet Payload Content Optimization
3.1.2. テストパケットペイロードコンテンツの最適化

The aim for efficient network resource use has resulted in deployment of server-only or client-server lossless or lossy payload compression techniques on some links or paths. These optimizers attempt to compress high-volume traffic in order to reduce network load. Files are analyzed by application-layer parsers, and parts (like comments) might be dropped. Although typically acting on HTTP or JPEG files, compression might affect measurement packets, too. In particular, measurement packets are qualified for efficient compression when they use standard plain-text payload. We note that use of transport-layer encryption will counteract the deployment of network-based analysis and may reduce the adoption of payload optimizations, however.

ネットワークリソースを効率的に使用することを目的として、一部のリンクまたはパスにサーバーのみまたはクライアントサーバーのロスレスまたはロスのあるペイロード圧縮技術を導入しています。これらのオプティマイザは、ネットワークの負荷を軽減するために、大量のトラフィックを圧縮しようとします。ファイルはアプリケーション層のパーサーによって分析され、一部(コメントなど)が削除される可能性があります。通常はHTTPまたはJPEGファイルで動作しますが、圧縮は測定パケットにも影響を与える可能性があります。特に、測定パケットは、標準のプレーンテキストペイロードを使用する場合、効率的な圧縮に適しています。ただし、トランスポート層暗号化を使用すると、ネットワークベースの分析の展開が妨げられ、ペイロードの最適化の採用が減る可能性があることに注意してください。

IPPM-conforming measurements should add packet payload content as a Type-P parameter, which can help to improve measurement determinism. Some packet payloads are more susceptible to compression than others, but optimizers in the measurement path can be out ruled by using incompressible packet payload. This payload content could be supplied by a pseudo-random sequence generator or by using part of a compressed file (e.g., a part of a ZIP compressed archive).

IPPM準拠の測定では、パケットペイロードのコンテンツをType-Pパラメーターとして追加する必要があります。これは、測定の確定性の向上に役立ちます。一部のパケットペイロードは他のパケットペイロードよりも圧縮の影響を受けやすくなっていますが、非圧縮性パケットペイロードを使用することにより、測定パスのオプティマイザを除外できます。このペイロードコンテンツは、疑似ランダムシーケンスジェネレーターによって、または圧縮ファイルの一部(ZIP圧縮アーカイブの一部など)を使用して提供できます。

Optimization can go beyond the scope of one single data or measurement stream. Many more client- or network-centric optimization technologies have been proposed or standardized so far, including Robust Header Compression (ROHC) and Voice over IP aggregation as presented, for instance, in [EEAW]. Where optimization is feasible and valuable, many more of these technologies may follow. As a general observation, the more concurrent flows an intermediate host treats and the longer the paths shared by flows are, the higher becomes the incentive of hosts to aggregate flows belonging to distinct sources. Measurements should consider this potential additional source of uncertainty with respect to repeatability. Aggregation of flows in networking devices can, for instance, result in reciprocal timing and performance influence of these flows, which may exceed typical reciprocal queueing effects by orders of magnitude.

最適化は、単一のデータまたは測定ストリームの範囲を超える可能性があります。たとえば[EEAW]で提示されているように、Robust Header Compression(ROHC)やVoice over IP集約など、これまでにさらに多くのクライアント中心またはネットワーク中心の最適化技術が提案または標準化されています。最適化が実行可能で価値がある場合、これらのテクノロジーの多くが従う可能性があります。一般的な観察として、中間ホストが処理する並行フローが多いほど、フローが共有するパスが長いほど、ホストが個別のソースに属するフローを集約するインセンティブが高くなります。測定では、再現性に関してこの潜在的な追加の不確実性の原因を考慮する必要があります。ネットワーキングデバイスでのフローの集約は、たとえば、これらのフローの相互タイミングとパフォーマンスに影響を与える可能性があり、通常の相互キューイング効果を桁違いに超える可能性があります。

3.2. Packet History
3.2. パケット履歴

Recent packet history and instantaneous data rate influence measurement results for reactive links supporting on-demand capacity allocation. Measurement uncertainty may be reduced by knowledge of measurement packet history and total host load. Additionally, small changes in history, e.g., because of lost packets along the path, can be the cause of large performance variations.

最近のパケット履歴と瞬間データレートは、オンデマンドの容量割り当てをサポートするリアクティブリンクの測定結果に影響を与えます。測定の不確かさは、測定パケットの履歴と合計ホスト負荷の知識によって減少する可能性があります。さらに、履歴の小さな変更(たとえば、パスに沿ったパケットの損失など)は、大きなパフォーマンス変動の原因となる可能性があります。

For instance, delay in reactive 3G networks like High Speed Packet Access (HSPA) depends to a large extent on the test traffic data rate. The reactive resource allocation strategy in these networks affects the uplink direction in particular. Small changes in data rate can be the reason of more than a 200% increase in delay, depending on the specific packet size. A detailed theoretical and practical analysis of Radio Resource Control (RRC) link transitions, which can cause such behavior in Universal Mobile Terrestrial System (UMTS) networks, is presented, e.g., in [RRC].

たとえば、高速パケットアクセス(HSPA)などのリアクティブ3Gネットワ​​ークの遅延は、テストトラフィックのデータレートに大きく依存します。これらのネットワークにおけるリアクティブなリソース割り当て戦略は、特にアップリンクの方向に影響します。データレートの小さな変化は、特定のパケットサイズによっては、遅延が200%以上増加する原因になる場合があります。 Universal Mobile Terrestrial System(UMTS)ネットワークでそのような動作を引き起こす可能性があるRadio Resource Control(RRC)リンク遷移の詳細な理論的および実用的な分析は、たとえば[RRC]に示されています。

3.3. Access Technology Change
3.3. アクセス技術の変化

[RFC2330] discussed the scenario of multi-homed hosts. If hosts become aware of access technology changes (e.g., because of IP address changes or lower-layer information) and make this information available, measurement methodologies can use this information to improve measurement representativeness and relevance.

[RFC2330]は、マルチホームホストのシナリオについて議論しました。ホストがアクセステクノロジーの変更(IPアドレスの変更や下位層の情報など)に気づき、この情報を利用できるようになった場合、測定方法はこの情報を使用して測定の代表性と関連性を改善できます。

However, today's various access network technologies can present the same physical interface to the host. A host may or may not become aware when its access technology changes on such an interface. Measurements for paths that support on-demand capacity allocation are, therefore, challenging in that it is difficult to differentiate between access technology changes (e.g., because of mobility) and reactive path behavior (e.g., because of data rate change).

ただし、今日のさまざまなアクセスネットワークテクノロジーは、ホストに同じ物理インターフェイスを提供できます。このようなインターフェイスでホストのアクセステクノロジーが変更されると、ホストが認識される場合と認識されない場合があります。したがって、オンデマンドの容量割り当てをサポートするパスの測定は、アクセステクノロジーの変化(モビリティなど)とリアクティブパスの動作(データレートの変化など)を区別することが難しいという点で困難です。

3.4. Time-Slotted Randomness Cancellation
3.4. タイムスロットランダムネスキャンセル

Time-slotted operation of path entities -- interfaces, routers, or links -- in a network path is a particular challenge for measurements, especially if the time-slot period is substantial. The central observation as an extension to Poisson stream sampling in [RFC2330] is that the first such time-slotted component cancels unbiased measurement stream sampling. In the worst case, time-slotted operation converts an unbiased, random measurement packet stream into a periodic packet stream. Being heavily biased, these packets may interact with periodic behavior of subsequent time-slotted network entities [TSRC].

ネットワークパスでのパスエンティティ(インターフェイス、ルーター、またはリンク)のタイムスロット操作は、特にタイムスロット期間が長い場合、測定にとって特に困難です。 [RFC2330]でのポアソンストリームサンプリングの拡張としての中心的な観察は、最初のそのようなタイムスロットコンポーネントが不偏測定ストリームサンプリングをキャンセルすることです。最悪の場合、タイムスロット操作により、不偏でランダムな測定パケットストリームが周期的なパケットストリームに変換されます。これらのパケットは、偏りが大きいため、後続のタイムスロットネットワークエンティティ[TSRC]の定期的な動作と相互作用する可能性があります。

Time-slotted randomness cancellation (TSRC) sources can be found in virtually any system, network component or path, their impact on measurements being a matter of the order of magnitude when compared to the metric under observation. Examples of TSRC sources include, but are not limited to, system clock resolution, operating system ticks, time-slotted component or network operation, etc. The amount of measurement bias is determined by the particular measurement stream, relative offset between allocated time slots in subsequent path entities, delay variation in these paths, and other sources of variation. Measurement results might change over time, depending on how accurately the sending host, receiving host, and time-slotted components in the measurement path are synchronized to each other and to global time. If path segments maintain flow state, flow parameter change or flow reallocations can cause substantial variation in measurement results.

タイムスロットランダムネスキャンセレーション(TSRC)ソースは、事実上すべてのシステム、ネットワークコンポーネント、またはパスで見つかります。測定への影響は、観測中のメトリックと比較すると、桁違いです。 TSRCソースの例には、システムクロック解像度、オペレーティングシステムのティック、タイムスロットコンポーネントまたはネットワーク操作などが含まれますが、これらに限定されません。測定バイアスの量は、特定の測定ストリーム、割り当てられたタイムスロット間の相対オフセットによって決定されます。後続のパスエンティティ、これらのパスの遅延変動、およびその他の変動の原因。測定結果は、測定ホストの送信ホスト、受信ホスト、およびタイムスロットコンポーネントがどれだけ正確に相互に同期され、グローバル時間に同期されるかに応じて、時間とともに変化する可能性があります。パスセグメントがフロー状態を維持する場合、フローパラメータの変更またはフローの再割り当てにより、測定結果に大きな変動が生じる可能性があります。

Practical measurements confirm that such interference limits delay measurement variation to a subset of theoretical value range. Measurement samples for such cases can aggregate on artificial limits, generating multi-modal distributions as demonstrated in [IRR]. In this context, the desirable measurement sample statistics differentiate between multi-modal delay distributions caused by reactive path behavior and the ones due to time-slotted interference.

実際の測定では、このような干渉によって遅延測定の変動が理論値の範囲のサブセットに制限されることが確認されています。このような場合の測定サンプルは、[IRR]で示されているように、人為的な限界で集約してマルチモーダル分布を生成できます。このコンテキストでは、望ましい測定サンプル統計は、反応経路の動作によって引き起こされるマルチモーダル遅延分布と、タイムスロット化された干渉によるものとを区別します。

Measurement methodology selection for time-slotted paths depends to a large extent on the respective viewpoint. End-to-end metrics can provide accurate measurement results for short-term sessions and low likelihood of flow state modifications. Applications or services that aim at approximating path performance for a short time interval (in the order of minutes) and expect stable path conditions should, therefore, prefer end-to-end metrics. Here, stable path conditions refer to any kind of global knowledge concerning measurement path flow state and flow parameters.

タイムスロットパスの測定方法の選択は、それぞれの視点に大きく依存します。エンドツーエンドのメトリックは、短期間のセッションで正確な測定結果を提供し、フロー状態の変更の可能性を低くすることができます。したがって、短い時間間隔(分単位)でパスのパフォーマンスを概算することを目的とし、安定したパスの状態を期待するアプリケーションまたはサービスでは、エンドツーエンドのメトリックを優先する必要があります。ここで、安定したパス条件とは、測定パスのフロー状態とフローパラメータに関するあらゆる種類のグローバルな知識を指します。

However, if long-term forecast of time-slotted path performance is the main measurement goal, a segmented approach relying on measurement of subpath metrics is preferred. Regenerating unbiased measurement traffic at any hop can help to reveal the true range of path performance for all path segments.

ただし、タイムスロットパスパフォーマンスの長期予測が主な測定目標である場合、サブパスメトリックの測定に依存するセグメント化されたアプローチが推奨されます。任意のホップで公平な測定トラフィックを再生成すると、すべてのパスセグメントのパスパフォーマンスの真の範囲を明らかにするのに役立ちます。

4. Quality of Metrics and Methodologies
4. 指標の品質と方法論

[RFC6808] proposes repeatability and continuity as one of the metric and methodology properties to infer on measurement quality. Depending mainly on the set of controlled measurement parameters, measurements repeated for a specific network path using a specific methodology may or may not yield repeatable results. Challenging measurement scenarios for adequate parameter control include wireless, reactive, or time-slotted networks as discussed earlier in this document. This section presents an expanded definition of "repeatability" beyond the definition in [RFC2330] and an expanded examination of the concept of "continuity" in [RFC2330] and its limited applicability.

[RFC6808]は、測定品質を推測するためのメトリックと方法論のプロパティの1つとして、再現性と連続性を提案しています。主に制御された測定パラメータのセットに応じて、特定の方法を使用して特定のネットワークパスに対して繰り返される測定は、再現可能な結果を​​もたらす場合と得ない場合があります。適切なパラメータ制御のための困難な測定シナリオには、このドキュメントで前述したワイヤレス、リアクティブ、またはタイムスロットネットワークが含まれます。このセクションでは、[RFC2330]の定義を超えた「再現性」の拡張された定義と、[RFC2330]の「連続性」の概念とその限られた適用性の拡張された検証を示します。

4.1. Revised Definition of Repeatability
4.1. 再現性の改訂された定義

[RFC2330] defines repeatability in a general way:

[RFC2330]は、一般的な方法で再現性を定義します。

"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 challenge is to develop this definition further, such that it becomes an objective measurable criterion (and does not depend on the concept of continuity discussed below). Fortunately, this topic has been treated in other IPPM work. In BCP 176 [RFC6576], the criteria of equivalent results was agreed as the surrogate for interoperability when assessing metric RFCs for Standards Track advancement. The criteria of equivalence were expressed as objective statistical requirements for comparison across the same implementations and independent implementations in the test plans specific to each RFC evaluated ([RFC2679] in the test plan of [RFC6808]).

課題は、この定義をさらに発展させて、それが客観的な測定可能な基準になるようにすることです(以下で説明する継続性の概念には依存しません)。幸い、このトピックは他のIPPM作業でも扱われています。 BCP 176 [RFC6576]では、標準トラックの進歩に関するメトリックRFCを評価する際に、同等の結果の基準が相互運用性の代理として合意されました。同等性の基準は、評価された各RFCに固有のテスト計画([RFC6808]のテスト計画の[RFC2679])で同じ実装と独立した実装を比較するための客観的な統計要件として表現されました。

The tests of [RFC6808] rely on nearly identical conditions to be present for analysis and accept that these conditions cannot be exactly identical in the production network paths used. The test plans allow some correction factors to be applied (some statistical tests are hyper-sensitive to differences in the mean of distributions) and recognize the original findings of [RFC2330] regarding excess sample sizes.

[RFC6808]のテストは、分析のために存在するほとんど同一の条件に依存し、これらの条件は、使用される実稼働ネットワークパスで正確に同一にすることはできないことを受け入れます。テスト計画では、いくつかの補正係数を適用でき(一部の統計テストは分布の平均値の違いに非常に敏感です)、過剰なサンプルサイズに関する[RFC2330]の元の結果を認識します。

One way to view the reliance on identical conditions is to view it as a challenge: How few parameters and path conditions need to be controlled and still produce repeatable methods/measurements?

同一の条件への依存を確認する1つの方法は、それを課題と見なすことです。制御する必要のあるパラメーターとパス条件の数が少なくても、再現可能な方法/測定を生成できるか

Although the test plan in [RFC6808] documented numerical criteria for equivalence, we cannot specify the exact numerical criteria for repeatability *in general*. The process in the BCP [RFC6576] and statistics in [RFC6808] have been used successfully, and the numerical criteria to declare a metric repeatable should be agreed by all interested parties prior to measurement.

[RFC6808]のテスト計画は同等性の数値基準を文書化しましたが、再現性の正確な数値基準を*一般的に*指定することはできません。 BCPのプロセス[RFC6576]と[RFC6808]の統計は正常に使用されており、反復可能なメトリックを宣言するための数値基準は、測定の前にすべての関係者が同意する必要があります。

We revise the definition slightly, as follows:

次のように、定義を少し修正します。

A methodology for a metric should have the property that it is repeatable: if the methodology is used multiple times under identical conditions, the methods should produce equivalent measurement results.

メトリックの方法論は、それが再現可能であるという特性を備えている必要があります。方法論が同じ条件下で複数回使用される場合、メソッドは同等の測定結果を生成する必要があります。

4.2. Continuity No Longer an Alternative Repeatability Criterion
4.2. 連続性はもはや代替の再現性基準ではありません

In the original framework [RFC2330], the concept of continuity was introduced to provide a relaxed criteria for judging repeatability and was described in Section 6.2 of [RFC2330] as follows:

元のフレームワーク[RFC2330]では、再現性を判断するための緩和された基準を提供するために継続性の概念が導入され、[RFC2330]のセクション6.2で次のように説明されていました。

"...a methodology for a given metric exhibits continuity if, for small variations in conditions, it results in small variations in the resulting measurements."

「...特定のメトリクスの方法論は、条件の小さな変動に対して、結果として得られる測定値の小さな変動をもたらす場合、連続性を示します。」

Although there are conditions where metrics may exhibit continuity, there are others where this criteria would fail for both user traffic and active measurement traffic. Consider link fragmentation and the non-linear increase in delay when we increase packet size just beyond the limit of a single fragment. An active measurement packet would see the same delay increase when exceeding the fragment size.

メトリックが連続性を示す可能性がある条件もありますが、この基準がユーザートラフィックとアクティブな測定トラフィックの両方で失敗する場合もあります。単一のフラグメントの制限を超えてパケットサイズを大きくする場合は、リンクの断片化と遅延の非線形増加を考慮してください。アクティブな測定パケットでは、フラグメントサイズを超えると、同じ遅延が増加します。

The Bulk Transfer Capacity (BTC) [RFC3148] gives another example in Section 1, bottom of page 2:

バルク転送容量(BTC)[RFC3148]は、ページ2の下部のセクション1に別の例を示しています。

There is also evidence that most TCP implementations exhibit non-linear performance over some portion of their operating region. It is possible to construct simple simulation examples where incremental improvements to a path (such as raising the link data rate) results in lower overall TCP throughput (or BTC) [Mat98].

また、ほとんどのTCP実装が、動作領域の一部で非線形のパフォーマンスを示すという証拠もあります。パスの漸進的な改善(リンクデータレートの引き上げなど)により、全体的なTCPスループット(またはBTC)が低下する単純なシミュレーションの例を構築することが可能です[Mat98]。

Clearly, the time-slotted network elements described in Section 3.4 of this document also qualify as a new exception to the ideal of continuity.

明らかに、このドキュメントのセクション3.4で説明されているタイムスロット化されたネットワーク要素も、連続性の理想に対する新しい例外として認められます。

Therefore, we deprecate continuity as an alternate criterion on metrics and prefer the more exact evaluation of repeatability instead.

したがって、メトリックの代替基準として連続性を廃止し、代わりに再現性のより正確な評価を優先します。

4.3. Metrics Should Be Actionable
4.3. 指標は実用的でなければならない

The IP Performance Metrics Framework [RFC2330] includes usefulness as a metric criterion:

IPパフォーマンスメトリックフレームワーク[RFC2330]には、メトリック基準としての有用性が含まれています。

"...The metrics must be useful to users and providers in understanding the performance they experience or provide...".

「...メトリックは、ユーザーまたはプロバイダーが経験または提供するパフォーマンスを理解する上で役立つ必要があります...」。

When considering measurements as part of a maintenance process, evaluation of measurement results for a path under observation can draw attention to potential performance problems "somewhere" on the path. Anomaly detection is, therefore, an important phase and first step that already satisfies the usefulness criterion for many metrics.

メンテナンスプロセスの一部として測定を検討する場合、監視中のパスの測定結果を評価すると、パスの「どこかに」ある潜在的なパフォーマンスの問題に注意を向けることができます。したがって、異常検出は重要なフェーズであり、多くのメトリックの有用性基準をすでに満たしている最初のステップです。

This concept of usefulness can be extended, becoming a subset of what we refer to as "actionable" criterion in the following. We note that this is not the term from law.

この有用性の概念は拡張でき、以下で「実行可能な」基準と呼ぶもののサブセットになります。これは法律の用語ではないことに注意してください。

Central to maintenance is the isolation of the root cause of reported anomalies down to a specific subpath, link or host, and metrics should support this second step as well. While detection of path anomaly may be the result of an on-going monitoring process, the second step of cause isolation consists of specific, directed on-demand measurements on components and subpaths. Metrics must support users in this directed search, becoming actionable:

メンテナンスの中心となるのは、報告された異常の根本原因を特定のサブパス、リンク、またはホストに分離することであり、メトリックはこの2番目のステップもサポートする必要があります。パスの異常の検出は継続的な監視プロセスの結果である可能性がありますが、原因を特定するための2番目のステップは、コンポーネントとサブパスに関する特定の指示されたオンデマンド測定で構成されます。指標はこの指示された検索でユーザーをサポートし、実行可能になる必要があります。

Metrics must enable users and operators to understand path performance and SHOULD help to direct corrective actions when warranted, based on the measurement results.

メトリックは、ユーザーとオペレーターがパスのパフォーマンスを理解できるようにする必要があり、測定結果に基づいて、必要に応じて是正措置を指示できるようにする必要があります(SHOULD)。

Besides characterizing metrics, usefulness and actionable properties are also applicable to methodologies and measurements.

指標の特徴付けに加えて、有用性と実用的なプロパティは、方法論と測定にも適用できます。

4.4. It May Not Be Possible To Be Conservative
4.4. 保守的になることは不可能かもしれない

[RFC2330] adopts the term "conservative" for measurement methodologies for which:

[RFC2330]は、次のような測定方法について「保守的」という用語を採用しています。

"... the act of measurement does not modify, or only slightly modifies, the value of the performance metric the methodology attempts to measure."

「...測定の行為は、方法論が測定しようとするパフォーマンスメトリックの値を変更しないか、わずかに変更するだけです。」

It should be noted that this definition of "conservative" in the sense of [RFC2330] depends to a large extent on the measurement path's technology and characteristics. In particular, when deployed on reactive paths, subpaths, links or hosts conforming to the definition in Section 1.1 of this document, measurement packets can originate capacity (re)allocations. In addition, small measurement flow variations can result in other users on the same path perceiving significant variations in measurement results. Therefore:

[RFC2330]の意味でのこの「保守的」の定義は、測定パスの技術と特性に大きく依存することに注意してください。特に、このドキュメントのセクション1.1の定義に準拠するリアクティブパス、サブパス、リンク、またはホストに展開すると、測定パケットは容量(再)割り当てを開始できます。さらに、測定フローの変動が小さいと、同じパス上の他のユーザーが測定結果に大きな変動を感じる可能性があります。したがって:

It is not always possible for the method to be conservative.

メソッドが保守的であるとは限りません。

4.5. Spatial and Temporal Composition Support Unbiased Sampling
4.5. 時空間構成は偏りのないサンプリングをサポート

Concepts related to temporal and spatial composition of metrics in Section 9 of [RFC2330] have been extended in [RFC5835]. [RFC5835] defines multiple new types of metrics, including Spatial Composition, Temporal Aggregation, and Spatial Aggregation. So far, only the metrics for Spatial Composition have been standardized [RFC6049], providing the ability to estimate the performance of a complete path from subpath metrics. Spatial Composition aligns with the finding of [TSRC] that unbiased sampling is not possible beyond the first time-slotted link within a measurement path.

[RFC2330]のセクション9のメトリックの時間的および空間的構成に関連する概念が[RFC5835]で拡張されました。 [RFC5835]は、空間構成、時間集約、空間集約など、複数の新しいタイプのメトリックを定義しています。これまでのところ、空間構成のメトリックのみが標準化されており[RFC6049]、サブパスメトリックから完全なパスのパフォーマンスを推定する機能を提供します。空間構成は、測定パス内の最初のタイムスロット付きリンクを超えて不偏サンプリングが不可能であるという[TSRC]の発見と一致しています。

In cases where unbiased measurement for all segments of a path is not feasible due to the presence of a time-slotted link, restoring randomness of measurement samples when necessary is recommended as presented in [TSRC], in combination with Spatial Composition [RFC6049].

タイムスロットリンクが存在するためにパスのすべてのセグメントの不偏測定が実行できない場合、空間構成[RFC6049]と組み合わせて、[TSRC]で示されているように、必要に応じて測定サンプルのランダム性を復元することが推奨されます。

4.6. When to Truncate the Poisson Sampling Distribution
4.6. ポアソン標本分布を切り捨てるタイミング

Section 11.1.1 of [RFC2330] describes Poisson sampling, where the inter-packet send times have a Poisson distribution. A path element with reactive behavior sensitive to flow inactivity could change state if the random inter-packet time is too long.

[RFC2330]のセクション11.1.1は、パケット間送信時間がポアソン分布を持つポアソンサンプリングについて説明しています。ランダムなパケット間時間が長すぎると、フローの非アクティブ状態に反応する反応動作を持つパス要素の状態が変わる可能性があります。

It is recommended to truncate the tail of Poisson distribution when needed to avoid reactive element state changes.

反応性要素の状態変化を回避する必要がある場合は、ポアソン分布の裾を切り捨てることをお勧めします。

Tail truncation has been used without issue to ensure that minimum sample sizes can be attained in a fixed-test interval.

固定のテスト間隔で最小サンプルサイズを確実に達成できるように、テールトランケーションが問題なく使用されています。

5. Conclusions
5. 結論

Safeguarding repeatability as a key property of measurement methodologies is highly challenging and sometimes impossible in reactive paths. Measurements in paths with demand-driven allocation strategies must use a prototypical application packet stream to infer a specific application's performance. Measurement repetition with unbiased network and flow states (e.g., by rebooting measurement hosts) can help to avoid interference with periodic network behavior, with randomness being a mandatory feature for avoiding correlation with network timing.

測定方法論の重要な特性としての再現性の保護は非常に困難であり、反応経路では不可能である場合があります。デマンド駆動型の割り当て戦略を使用するパスの測定では、典型的なアプリケーションパケットストリームを使用して、特定のアプリケーションのパフォーマンスを推測する必要があります。公平なネットワークとフローの状態を使用した測定の繰り返し(測定ホストの再起動など)は、ネットワークのタイミングとの相関を回避するために必須の機能であるランダム性により、定期的なネットワーク動作の干渉を回避するのに役立ちます。

Inferring the path performance between one measurement session or packet stream and other sessions/streams with alternate characteristics is generally discouraged with reactive paths because of the huge set of global parameters that have influence on instantaneous path performance.

1つの測定セッションまたはパケットストリームと代替特性を持つ他のセッション/ストリームの間のパスパフォーマンスを推測することは、瞬間的なパスパフォーマンスに影響を与えるグローバルパラメータの巨大なセットのため、通常、リアクティブパスでは推奨されません。

6. Security Considerations
6. セキュリティに関する考慮事項

The security considerations that apply to any active measurement of live paths are relevant here as well. See [RFC4656] and [RFC5357].

ライブパスのアクティブな測定に適用されるセキュリティの考慮事項は、ここでも関係があります。 [RFC4656]と[RFC5357]を参照してください。

When considering privacy of those involved in measurement or those whose traffic is measured, the sensitive information available to potential observers is greatly reduced when using active techniques that are within this scope of work. Passive observations of user traffic for measurement purposes raise many privacy issues. We refer the reader to the privacy considerations described in the Large Scale Measurement of Broadband Performance (LMAP) Framework [LMAP], which covers active and passive techniques.

測定に関与する人々またはトラフィックが測定される人々のプライバシーを考慮する場合、この作業範囲内にあるアクティブな手法を使用すると、潜在的なオブザーバーが入手できる機密情報が大幅に減少します。測定目的でのユーザートラフィックの受動的な観察は、多くのプライバシー問題を引き起こします。アクティブおよびパッシブ技術をカバーするブロードバンドパフォーマンスの大規模測定(LMAP)フレームワーク[LMAP]で説明されているプラ​​イバシーに関する考慮事項を読者に紹介します。

7. Acknowledgements
7. 謝辞

The authors thank Rudiger Geib, Matt Mathis, Konstantinos Pentikousis, and Robert Sparks for their helpful comments on this memo, Alissa Cooper and Kathleen Moriarty for suggesting ways to "update the update" for heightened privacy awareness and its consequences, and Ann Cerveny for her editorial review and comments that helped to improve readability overall.

著者は、このメモに関する有益なコメントを提供してくれたRudiger Geib、Matt Mathis、Konstantinos Pentikousis、およびRobert Sparksに、プライバシー意識の高まりとその結果のために「更新を更新する」方法を提案してくれたこと、および彼女のためにAnn Cervenyに感謝します。全体的な読みやすさの向上に役立つ編集レビューとコメント。

8. References
8. 参考文献
8.1. Normative References
8.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.

[RFC2330] Paxson、V.、Almes、G.、Madhavi、J。、およびM. Mathis、「Framework for IP Performance Metrics」、RFC 2330、1998年5月。

[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.

[RFC2679] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「A IP-way Delay Metric for IPPM」、RFC 2679、1999年9月。

[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002.

[RFC3432] Raisanen、V.、Grotefeld、G。、およびA. Morton、「定期的なストリームによるネットワークパフォーマンス測定」、RFC 3432、2002年11月。

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006.

[RFC4656] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J。、およびM. Zekauskas、「A One-way Active Measurement Protocol(OWAMP)」、RFC 4656、2006年9月。

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008.

[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K。、およびJ. Babiarz、「A Two-Way Active Measurement Protocol(TWAMP)」、RFC 5357、2008年10月。

[RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric Composition", RFC 5835, April 2010.

[RFC5835] Morton、A.およびS. Van den Berghe、「Framework for Metric Composition」、RFC 5835、2010年4月。

[RFC6049] Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC 6049, January 2011.

[RFC6049] Morton、A。およびE. Stephan、「メトリックの空間構成」、RFC 6049、2011年1月。

[RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP Performance Metrics (IPPM) Standard Advancement Testing", BCP 176, RFC 6576, March 2012.

[RFC6576] Geib、R.、Morton、A.、Fardid、R。、およびA. Steinmitz、「IP Performance Metrics(IPPM)Standard Advancement Testing」、BCP 176、RFC 6576、2012年3月。

[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting IP Network Performance Metrics: Different Points of View", RFC 6703, August 2012.

[RFC6703] Morton、A.、Ramachandran、G。、およびG. Maguluri、「Reporting IP Network Performance Metrics:Different Points of View」、RFC 6703、2012年8月。

8.2. Informative References
8.2. 参考引用

[EEAW] Pentikousis, K., Piri, E., Pinola, J., Fitzek, F., Nissilae, T., and I. Harjula, "Empirical Evaluation of VoIP Aggregation over a Fixed WiMAX Testbed", Proceedings of the 4th International Conference on Testbeds and research infrastructures for the development of networks and communities (TridentCom '08), Article No. 19, March 2008, <http://dl.acm.org/citation.cfm?id=139059>.

[EEAW] Pentikousis、K.、Piri、E.、Pinola、J.、Fitzek、F.、Nissilae、T.、I。Harjula、「固定WiMAXテストベッドでのVoIP集約の経験的評価」、第4回の議事録ネットワークとコミュニティの開発のためのテストベッドと研究インフラストラクチャに関する国際会議(TridentCom '08)、第19条、2008年3月、<http://dl.acm.org/citation.cfm?id=139059>。

[IBD] Fabini, J., Karner, W., Wallentin, L., and T. Baumgartner, "The Illusion of Being Deterministic - Application-Level Considerations on Delay in 3G HSPA Networks", Lecture Notes in Computer Science, Volume 5550, pp. 301-312 , May 2009.

[IBD] Fabini、J.、Karner、W.、Walletin、L。、およびT. Baumgartner、「決定論的であるという幻想-3G HSPAネットワークの遅延に関するアプリケーションレベルの考慮事項」、コンピュータサイエンスの講義ノート、5550巻、pp.301-312、2009年5月。

[IRR] Fabini, J., Wallentin, L., and P. Reichl, "The Importance of Being Really Random: Methodological Aspects of IP-Layer 2G and 3G Network Delay Assessment", ICC'09 Proceedings of the 2009 IEEE International Conference on Communications, doi: 10.1109/ICC.2009.5199514, June 2009.

[IRR] Fabini、J.、Wallentin、L。、およびP. Reichl、「本当にランダムであることが重要:IPレイヤー2Gおよび3Gネットワ​​ーク遅延評価の方法論的側面」、ICC'09 Proceedings of the 2009 IEEE International Conference通信、doi:10.1109 / ICC.2009.5199514、2009年6月。

[LMAP] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A framework for large-scale measurement platforms (LMAP)", Work in Progress, June 2014.

[LMAP] Eardley、P.、Morton、A.、Bagnulo、M.、Burbridge、T.、Aitken、P。、およびA. Akhter、「大規模測定プラットフォーム(LMAP)のフレームワーク」、Work in Progress 、2014年6月。

[Mat98] Mathis, M., "Empirical Bulk Transfer Capacity", IP Performance Metrics Working Group report in Proceedings of the Forty-Third Internet Engineering Task Force, Orlando, FL, December 1998, <http://www.ietf.org/proceedings/43/slides/ ippm-mathis-98dec.pdf>.

[Mat98] Mathis、M。、「Empirical Bulk Transfer Capacity」、IP Performance Metrics Working Group Report in Proceedings of the Forty-Third Internet Engineering Task Force、Orlando、FL、1998年12月、<http://www.ietf.org / proceedings / 43 / slides / ippm-mathis-98dec.pdf>。

[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001.

[RFC3148] Mathis、M。、およびM. Allman、「経験的バルク転送容量メトリックを定義するためのフレームワーク」、RFC 3148、2001年7月。

[RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track", RFC 6808, December 2012.

[RFC6808] Ciavattone、L.、Geib、R.、Morton、A。、およびM. Wieser、「Test Plan and Results Supporting RFC 2679 on the Standards Track」、RFC 6808、2012年12月。

[RFC6985] Morton, A., "IMIX Genome: Specification of Variable Packet Sizes for Additional Testing", RFC 6985, July 2013.

[RFC6985] Morton、A。、「IMIX Genome:Specification of Variable Packet Sizes for Additional Testing」、RFC 6985、2013年7月。

[RRC] Peraelae, P., Barbuzzi, A., Boggia, G., and K. Pentikousis, "Theory and Practice of RRC State Transitions in UMTS Networks", IEEE Globecom 2009 Workshops, doi: 10.1109/GLOCOMW.2009.5360763, November 2009.

[RRC] Peraelae、P.、Barbuzzi、A.、Boggia、G。、およびK. Pentikousis、「UMTSネットワークにおけるRRC状態遷移の理論と実践」、IEEE Globecom 2009ワークショップ、doi:10.1109 / GLOCOMW.2009.5360763、11月2009。

[TSRC] Fabini, J. and M. Abmayer, "Delay Measurement Methodology Revisited: Time-slotted Randomness Cancellation", IEEE Transactions on Instrumentation and Measurement, Volume 62, Issue 10, doi:10.1109/TIM.2013.2263914, October 2013.

[TSRC] Fabini、J。およびM. Abmayer、「Delay Measurement Methodology Revisited:Time-slotted Randomness Cancellation」、IEEE Transactions on Instrumentation and Measurement、Volume 62、Issue 10、doi:10.1109 / TIM.2013.2263914、2013年10月。

Authors' Addresses

著者のアドレス

Joachim Fabini Vienna University of Technology Gusshausstrasse 25/E389 Vienna 1040 Austria

Joachim Fabiniウィーン工科大学Gusshausstrasse 25 / E389ウィーン1040オーストリア

   Phone: +43 1 58801 38813
   Fax:   +43 1 58801 38898
   EMail: Joachim.Fabini@tuwien.ac.at
   URI:   http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/
        

Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA

Al Morton AT&T Labs 200 Laurel Avenue South Middletown、NJ 07748 USA

   Phone: +1 732 420 1571
   Fax:   +1 732 368 1192
   EMail: acmorton@att.com
   URI:   http://home.comcast.net/~acmacm/