RFC 8912 - Initial Performance Metrics Registry Entries 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8912.html
タイトル : RFC 8912 - 初期パフォーマンスメトリックレジストリエントリ
翻訳編集 : 自動生成

[要約] RFC 8912は、インターネットパフォーマンス測定のための初期メトリック登録エントリを定義します。この文書の目的は、標準化されたパフォーマンス測定の基準を提供することにあり、ネットワークの診断、管理、および性能改善の場面で利用されます。

Internet Engineering Task Force (IETF)                         A. Morton
Request for Comments: 8912                                     AT&T Labs
Category: Standards Track                                     M. Bagnulo
ISSN: 2070-1721                                                     UC3M
                                                              P. Eardley
                                                                      BT
                                                              K. D'Souza
                                                               AT&T Labs
                                                           November 2021

Initial Performance Metrics Registry Entries

初期パフォーマンスメトリックレジストリエントリ

Abstract

概要

This memo defines the set of initial entries for the IANA Registry of Performance Metrics. The set includes UDP Round-Trip Latency and Loss, Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson One-Way Delay and Loss, UDP Periodic One-Way Delay and Loss, ICMP Round-Trip Latency and Loss, and TCP Round-Trip Delay and Loss.

このメモは、パフォーマンスメトリックのIANAレジストリの初期エントリのセットを定義します。このセットには、UDPラウンドトリップの待ち時間と損失、パケット遅延の変動、DNS応答の待ち時間と損失、UDPポアソンの一方向の遅延、UDP周期的な一方向の遅延、ICMPの往復待ち時間と損失、およびTCPラウンドが含まれます。 - 遅延と損失。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これはインターネット規格のトラック文書です。

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). Further information on Internet Standards is available in Section 2 of RFC 7841.

この文書はインターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それはパブリックレビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。

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

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc8912で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。

Table of Contents

   1.  Introduction
     1.1.  Requirements Language
   2.  Scope
   3.  Registry Categories and Columns
   4.  UDP Round-Trip Latency and Loss Registry Entries
     4.1.  Summary
       4.1.1.  ID (Identifier)
       4.1.2.  Name
       4.1.3.  URI
       4.1.4.  Description
       4.1.5.  Change Controller
       4.1.6.  Version (of Registry Format)
     4.2.  Metric Definition
       4.2.1.  Reference Definition
       4.2.2.  Fixed Parameters
     4.3.  Method of Measurement
       4.3.1.  Reference Methods
       4.3.2.  Packet Stream Generation
       4.3.3.  Traffic Filtering (Observation) Details
       4.3.4.  Sampling Distribution
       4.3.5.  Runtime Parameters and Data Format
       4.3.6.  Roles
     4.4.  Output
       4.4.1.  Type
       4.4.2.  Reference Definition
       4.4.3.  Metric Units
       4.4.4.  Calibration
     4.5.  Administrative Items
       4.5.1.  Status
       4.5.2.  Requester
       4.5.3.  Revision
       4.5.4.  Revision Date
     4.6.  Comments and Remarks
   5.  Packet Delay Variation Registry Entry
     5.1.  Summary
       5.1.1.  ID (Identifier)
       5.1.2.  Name
       5.1.3.  URI
       5.1.4.  Description
       5.1.5.  Change Controller
       5.1.6.  Version (of Registry Format)
     5.2.  Metric Definition
       5.2.1.  Reference Definition
       5.2.2.  Fixed Parameters
     5.3.  Method of Measurement
       5.3.1.  Reference Methods
       5.3.2.  Packet Stream Generation
       5.3.3.  Traffic Filtering (Observation) Details
       5.3.4.  Sampling Distribution
       5.3.5.  Runtime Parameters and Data Format
       5.3.6.  Roles
     5.4.  Output
       5.4.1.  Type
       5.4.2.  Reference Definition
       5.4.3.  Metric Units
       5.4.4.  Calibration
     5.5.  Administrative Items
       5.5.1.  Status
       5.5.2.  Requester
       5.5.3.  Revision
       5.5.4.  Revision Date
     5.6.  Comments and Remarks
   6.  DNS Response Latency and Loss Registry Entries
     6.1.  Summary
       6.1.1.  ID (Identifier)
       6.1.2.  Name
       6.1.3.  URI
       6.1.4.  Description
       6.1.5.  Change Controller
       6.1.6.  Version (of Registry Format)
     6.2.  Metric Definition
       6.2.1.  Reference Definition
       6.2.2.  Fixed Parameters
     6.3.  Method of Measurement
       6.3.1.  Reference Methods
       6.3.2.  Packet Stream Generation
       6.3.3.  Traffic Filtering (Observation) Details
       6.3.4.  Sampling Distribution
       6.3.5.  Runtime Parameters and Data Format
       6.3.6.  Roles
     6.4.  Output
       6.4.1.  Type
       6.4.2.  Reference Definition
       6.4.3.  Metric Units
       6.4.4.  Calibration
     6.5.  Administrative Items
       6.5.1.  Status
       6.5.2.  Requester
       6.5.3.  Revision
       6.5.4.  Revision Date
     6.6.  Comments and Remarks
   7.  UDP Poisson One-Way Delay and Loss Registry Entries
     7.1.  Summary
       7.1.1.  ID (Identifier)
       7.1.2.  Name
       7.1.3.  URI
       7.1.4.  Description
       7.1.5.  Change Controller
       7.1.6.  Version (of Registry Format)
     7.2.  Metric Definition
       7.2.1.  Reference Definition
       7.2.2.  Fixed Parameters
     7.3.  Method of Measurement
       7.3.1.  Reference Methods
       7.3.2.  Packet Stream Generation
       7.3.3.  Traffic Filtering (Observation) Details
       7.3.4.  Sampling Distribution
       7.3.5.  Runtime Parameters and Data Format
       7.3.6.  Roles
     7.4.  Output
       7.4.1.  Type
       7.4.2.  Reference Definition
       7.4.3.  Metric Units
       7.4.4.  Calibration
     7.5.  Administrative Items
       7.5.1.  Status
       7.5.2.  Requester
       7.5.3.  Revision
       7.5.4.  Revision Date
     7.6.  Comments and Remarks
   8.  UDP Periodic One-Way Delay and Loss Registry Entries
     8.1.  Summary
       8.1.1.  ID (Identifier)
       8.1.2.  Name
       8.1.3.  URI
       8.1.4.  Description
       8.1.5.  Change Controller
       8.1.6.  Version (of Registry Format)
     8.2.  Metric Definition
       8.2.1.  Reference Definition
       8.2.2.  Fixed Parameters
     8.3.  Method of Measurement
       8.3.1.  Reference Methods
       8.3.2.  Packet Stream Generation
       8.3.3.  Traffic Filtering (Observation) Details
       8.3.4.  Sampling Distribution
       8.3.5.  Runtime Parameters and Data Format
       8.3.6.  Roles
     8.4.  Output
       8.4.1.  Type
       8.4.2.  Reference Definition
       8.4.3.  Metric Units
       8.4.4.  Calibration
     8.5.  Administrative Items
       8.5.1.  Status
       8.5.2.  Requester
       8.5.3.  Revision
       8.5.4.  Revision Date
     8.6.  Comments and Remarks
   9.  ICMP Round-Trip Latency and Loss Registry Entries
     9.1.  Summary
       9.1.1.  ID (Identifier)
       9.1.2.  Name
       9.1.3.  URI
       9.1.4.  Description
       9.1.5.  Change Controller
       9.1.6.  Version (of Registry Format)
     9.2.  Metric Definition
       9.2.1.  Reference Definition
       9.2.2.  Fixed Parameters
     9.3.  Method of Measurement
       9.3.1.  Reference Methods
       9.3.2.  Packet Stream Generation
       9.3.3.  Traffic Filtering (Observation) Details
       9.3.4.  Sampling Distribution
       9.3.5.  Runtime Parameters and Data Format
       9.3.6.  Roles
     9.4.  Output
       9.4.1.  Type
       9.4.2.  Reference Definition
       9.4.3.  Metric Units
       9.4.4.  Calibration
     9.5.  Administrative Items
       9.5.1.  Status
       9.5.2.  Requester
       9.5.3.  Revision
       9.5.4.  Revision Date
     9.6.  Comments and Remarks
   10. TCP Round-Trip Delay and Loss Registry Entries
     10.1.  Summary
       10.1.1.  ID (Identifier)
       10.1.2.  Name
       10.1.3.  URI
       10.1.4.  Description
       10.1.5.  Change Controller
       10.1.6.  Version (of Registry Format)
     10.2.  Metric Definition
       10.2.1.  Reference Definition
       10.2.2.  Fixed Parameters
     10.3.  Method of Measurement
       10.3.1.  Reference Methods
       10.3.2.  Packet Stream Generation
       10.3.3.  Traffic Filtering (Observation) Details
       10.3.4.  Sampling Distribution
       10.3.5.  Runtime Parameters and Data Format
       10.3.6.  Roles
     10.4.  Output
       10.4.1.  Type
       10.4.2.  Reference Definition
       10.4.3.  Metric Units
       10.4.4.  Calibration
     10.5.  Administrative Items
       10.5.1.  Status
       10.5.2.  Requester
       10.5.3.  Revision
       10.5.4.  Revision Date
     10.6.  Comments and Remarks
   11. Security Considerations
   12. IANA Considerations
   13. References
     13.1.  Normative References
     13.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction

1. はじめに

This memo defines an initial set of entries for the Performance Metrics Registry. It uses terms and definitions from the IP Performance Metrics (IPPM) literature, primarily [RFC2330].

このメモは、Performance Metricsレジストリのエントリの初期セットを定義します。主に[RFC2330]で、IPパフォーマンスメトリック（IPPM）文献から用語と定義を使用しています。

Although there are several standard templates for organizing specifications of Performance Metrics (see [RFC7679] for an example of the traditional IPPM template, based to a large extent on the Benchmarking Methodology Working Group's traditional template in [RFC1242], and see [RFC6390] for a similar template), none of these templates were intended to become the basis for the columns of an IETF-wide Registry of metrics. While examining aspects of metric specifications that need to be registered, it became clear that none of the existing metric templates fully satisfy the particular needs of a Registry.

パフォーマンスメトリックの仕様を整理するための標準テンプレートがいくつかありますが（RFC1242のベンチマーク方法論ワーキンググループの伝統的なテンプレートに大幅に基づいて、RFC1242]の場合は[RFC6390]を参照してください。同様のテンプレート）、これらのテンプレートのどれもメトリックのIETFワイドレジストリの列の基礎となることを意図していませんでした。登録する必要があるメトリック仕様の側面を調べながら、既存のメトリックテンプレートのどれもレジストリの特定のニーズを完全に満たすことが明らかになりました。

Therefore, [RFC8911] defines the overall format for a Performance Metrics Registry. Section 5 of [RFC8911] also gives guidelines for those requesting registration of a Metric -- that is, the creation of one or more entries in the Performance Metrics Registry:

したがって、[RFC8911]は、パフォーマンスメトリックレジストリの全体的なフォーマットを定義します。[RFC8911]のセクション5は、メトリックの登録を要求するもののためのガイドラインを与えます - それでは、パフォーマンスメトリックレジストリ内の1つ以上のエントリの作成です。

   |  In essence, there needs to be evidence that (1) a candidate
   |  Registered Performance Metric has significant industry interest or
   |  has seen deployment and (2) there is agreement that the candidate
   |  Registered Performance Metric serves its intended purpose.

The process defined in [RFC8911] also requires that new entries be administered by IANA through the Specification Required policy [RFC8126], which will ensure that the metrics are tightly defined.

[RFC8911]で定義されているプロセスには、指定されたポリシー[RFC8126]を介してIANAによって新しいエントリが管理される必要があります。これにより、メトリックがしっかりと定義されていることを確認します。

1.1. Requirements Language

1.1. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

2. Scope

2. 範囲

This document defines a set of initial Performance Metrics Registry Entries. Most are Active Performance Metrics, which are based on RFCs prepared in the IPPM Working Group of the IETF, according to their framework [RFC2330] and its updates.

このドキュメントでは、一連の初期パフォーマンスメトリクスレジストリエントリを定義します。ほとんどの能力は、そのフレームワーク[RFC2330]とその更新に従って、IETFのIPPMワーキンググループで作成されたRFCに基づいているアクティブなパフォーマンスメトリックです。

3. Registry Categories and Columns

3. レジストリカテゴリと列

This memo uses the terminology defined in [RFC8911].

このメモは[RFC8911]で定義されている用語を使用しています。

This section provides the categories and columns of the Registry, for easy reference. An entry (row) therefore gives a complete description of a Registered Metric.

このセクションでは、リファレンスを簡単に参照するために、レジストリのカテゴリと列を提供します。したがって、エントリ（行）は登録されたメトリックの完全な説明を与えます。

Registry Categories and Columns are shown below in this format:

レジストリカテゴリと列は、次の形式で以下に示されています。

       Category
       ------------------...
       Column |  Column |...

   Summary
   ---------------------------------------------------------------
   Identifier | Name | URI | Desc. | Reference | Change     | Ver |
              |      |     |       |           | Controller |

   Metric Definition
   -----------------------------------------
   Reference Definition | Fixed Parameters |

   Method of Measurement
   ---------------------------------------------------------------------
   Reference | Packet     | Traffic | Sampling     | Runtime    | Role |
   Method    | Stream     | Filter  | Distribution | Parameters |      |
             | Generation |
   Output
   -----------------------------------------
   Type | Reference  | Units | Calibration |
        | Definition |       |             |

   Administrative Information
   -------------------------------------
   Status |Requester | Rev | Rev. Date |

   Comments and Remarks
   --------------------

4. UDP Round-Trip Latency and Loss Registry Entries

4. UDPラウンドトリップレイテンシとロスレジストリエントリ

This section specifies an initial Registry Entry for UDP Round-Trip Latency and another entry for the UDP Round-Trip Loss Ratio.

このセクションでは、UDPラウンドトリップレイテンシとUDPラウンドトリップ損失率の別のエントリの初期レジストリエントリを指定します。

Note: Each Registry Entry only produces a "raw" output or a statistical summary. To describe both "raw" and one or more statistics efficiently, the Identifier, Name, and Output categories can be split, and a single section can specify two or more closely related metrics. For example, this section specifies two Registry Entries with many common columns. See Section 7 for an example specifying multiple Registry Entries with many common columns.

注：各レジストリエントリは、 "RAW"出力または統計的要約のみを生成します。「RAW」と1つ以上の統計の両方を効率的に説明するために、識別子、名前、および出力カテゴリを分割することができ、単一のセクションは2つ以上の密接に関連したメトリックを指定できます。たとえば、このセクションでは、多くの一般的な列を持つ2つのレジストリエントリを指定します。多くの一般的な列を持つ複数のレジストリエントリを指定する例については、セクション7を参照してください。

All column entries besides the ID, Name, Description, and Output Reference Method categories are the same; thus, this section defines two closely related Registry Entries. As a result, IANA has also assigned a corresponding URL to each of the two Named Metrics.

ID、名前、説明、および出力の参照メソッドのカテゴリ以外のすべての列エントリは同じです。したがって、このセクションでは、2つの密接に関連するレジストリエントリを定義します。その結果、IANAは2つの名前付きメトリックのそれぞれに対応するURLを割り当てました。

4.1. Summary

4.1. 概要

This category includes multiple indexes to the Registry Entries: the element ID and Metric Name.

このカテゴリには、レジストリエントリへの複数のインデックスが含まれています。要素IDとメトリック名。

4.1.1. ID (Identifier)

4.1.1. ID（識別子）

IANA has allocated the numeric Identifiers 1 and 2 for the two Named Metric Entries in Section 4. See Section 4.1.2 for mapping to Names.

IANAはセクション4の2つの名前付きメトリックエントリに対して数値識別子1と2を割り当てました。名前へのマッピングについては、セクション4.1.2を参照してください。

4.1.2. Name

4.1.2. 名前

1: RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile

1：RTDELAY_ACTIVE_IP-UDP-PERIORIC_RFC8912SEC4_SECONDS_95PERCENTILE.

2: RTLoss_Active_IP-UDP-Periodic_RFC8912sec4_Percent_LossRatio

2：rtloss_active_ip-udp-ediametic_rfc8912sec4_percent_lossratio.

4.1.3. URI

4.1.3. u u

   URL: https://www.iana.org/assignments/performance-metrics/
   RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile

   URL: https://www.iana.org/assignments/performance-metrics/
   RTLoss_Active_IP-UDP-Periodic_RFC8912sec4_Percent_LossRatio

4.1.4. Description

4.1.4. 説明

RTDelay: This metric assesses the delay of a stream of packets exchanged between two hosts (which are the two measurement points). The output is the round-trip delay for all successfully exchanged packets expressed as the 95th percentile of their conditional delay distribution.

RTDELAY：このメトリックは、2つのホスト間で交換されたパケットのストリームの遅延を評価します（これは2つの測定点です）。出力は、それらの条件付き遅延分布の95パーセンタイルとして表されるすべての首尾よく交換されたパケットの往復遅延です。

RTLoss: This metric assesses the loss ratio of a stream of packets exchanged between two hosts (which are the two measurement points). The output is the round-trip loss ratio for all transmitted packets expressed as a percentage.

rtloss：このメトリックは、2つのホスト間で交換されたパケットのストリームの損失率を評価します（これは2つの測定点です）。出力は、パーセンテージとして表されるすべての送信パケットの往復損失率です。

4.1.5. Change Controller

4.1.5. コントローラを変更する

IETF

i i

4.1.6. Version (of Registry Format)

4.1.6. バージョン（レジストリフォーマット）

1.0

4.2. Metric Definition

4.2. メートル定義

This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called "Fixed Parameters".

このカテゴリには、 "固定パラメータ"と呼ばれるRFCリファレンスと入力ファクタの値を含む、メトリック定義に関連するすべての必要な詳細のエントリを促す列が含まれています。

4.2.1. Reference Definition

4.2.1. 参照定義

For delay:

遅延の場合：

      Almes, G., Kalidindi, S., and M.  Zekauskas, "A Round-trip Delay
      Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999,
      <https://www.rfc-editor.org/info/rfc2681>.  [RFC2681]

Section 2.4 of [RFC2681] provides the reference definition of the singleton (single value) round-trip delay metric. Section 3.4 of [RFC2681] provides the reference definition expanded to cover a multi-singleton sample. Note that terms such as "singleton" and "sample" are defined in Section 11 of [RFC2330].

[RFC2681]のセクション2.4は、シングルトン（単一値）往復遅延メトリックの参照定義を提供します。[RFC2681]のセクション3.4は、マルチシングルトンサンプルをカバーするように参照定義を拡張します。「シングルトン」や「サンプル」などの用語は[RFC2330]の第11章で定義されています。

Note that although the definition of round-trip delay between the Source (Src) and the Destination (Dst) as provided in Section 2.4 of [RFC2681] is directionally ambiguous in the text, this metric tightens the definition further to recognize that the host in the Src Role will send the first packet to the host in the Dst Role and will ultimately receive the corresponding return packet from the Dst (when neither is lost).

[RFC2681]のセクション2.4のセクション2.4で提供されているソース（SRC）と宛先（DST）の間の往復遅延の定義は、テキストでは指向的にあいまいですが、このメトリックはさらにホストを認識するためにさらに定義を締め付けます。SRCロールはDSTロール内の最初のパケットをホストに送信し、最終的にはDSTからの対応する戻りパケットをDSTから受信します（どちらの失われない場合）。

Finally, note that the variable "dT" is used in [RFC2681] to refer to the value of round-trip delay in metric definitions and methods. The variable "dT" has been reused in other IPPM literature to refer to different quantities and cannot be used as a global variable name.

最後に、metric定義とメソッドの往復遅延の値を指すために、変数 "dt"が[RFC2681]で使用されます。変数「DT」は、さまざまな数量を指すために他のIPPM文献で再利用され、グローバル変数名として使用できません。

For loss:

損失のために：

      Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI
      10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/
      rfc6673>.  [RFC6673]

Both Delay and Loss metrics employ a maximum waiting time for received packets, so the count of lost packets to total packets sent is the basis for the loss ratio calculation as per Section 6.1 of [RFC6673].

遅延と損失の両方のメトリックは、受信したパケットの最大待ち時間を採用しているため、送信された合計パケットへの紛失したパケットの数は、[RFC6673]のセクション6.1に従って損失率計算の基礎となります。

4.2.2. Fixed Parameters

4.2.2. 固定パラメータ

Type-P as defined in Section 13 of [RFC2330]: IPv4 header values: DSCP: Set to 0 TTL: Set to 255 Protocol: Set to 17 (UDP)

[RFC2330]のセクション13で定義されているTYPE-P：IPv4ヘッダー値：DSCP：0 TTLに設定：255プロトコルに設定：17（UDP）に設定

IPv6 header values: DSCP: Set to 0 Hop Count: Set to 255 Next Header: Set to 17 (UDP) Flow Label: Set to 0 Extension Headers: None

IPv6ヘッダー値：DSCP：0ホップ数に設定：255次のヘッダーに設定：17（UDP）フローラベル：0に設定します。

UDP header values: Checksum: The checksum MUST be calculated and the non-zero checksum included in the header

UDPヘッダー値：チェックサム：チェックサムを計算し、ヘッダーに含まれていないゼロ以外のチェックサムを必要とします。

UDP Payload: Total of 100 bytes

UDPペイロード：合計100バイト

Other measurement Parameters: Tmax: A loss threshold waiting time with value 3.0, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a resolution of 0.0001 seconds (0.1 ms), with lossless conversion to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905].

その他の測定パラメータ：TMAX：秒単位で表される値3.0を持つ損失しきい値待ち時間、秒単位で表され、分数桁数= 4（[RFC6020]のセクション9.3）および0.0001秒の解像度（[RFC5905]のセクション6に従って、32ビットNTPタイムスタンプへの可逆変換を0.1 ms）。

4.3. Method of Measurement

4.3. 測定方法

This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous method for implementations.

このカテゴリには、RFCの関連セクションへの参照と、実装の明確な方法を確保するために必要な補足情報が含まれています。

4.3.1. Reference Methods

4.3.1. 参照方法

The methodology for this metric (equivalent to Type-P-Round-trip-Delay and Type-P-Round-trip-Delay-Poisson-Stream) is defined as in Section 2.6 of [RFC2681] (for singletons) and Section 3.6 of [RFC2681] (for samples) using the Type-P and Tmax defined in the Fixed Parameters column. However, the Periodic stream will be generated according to [RFC3432].

このメトリックの方法論（タイプ-Pラウンドトリップディレイとタイプ-Pラウンドトリップ遅延 - POISSON-STREAMと同等）は、[RFC2681]（シングルトン用）とセクション3.6のセクション2.6のように定義されています。[RFC2681]（サンプルの場合）[固定パラメーター]列に定義されているTYPE-PとTMAXを使用しています。ただし、定期ストリームは[RFC3432]に従って生成されます。

The reference method distinguishes between long-delayed packets and lost packets by implementing a maximum waiting time for packet arrival. Tmax is the waiting time used as the threshold to declare a packet lost. Lost packets SHALL be designated as having undefined delay and counted for the RTLoss metric [RFC6673].

参照方法は、パケット到着の最大待ち時間を実装することによって、長遅延パケットと紛失したパケットを区別します。TMAXは、パケットが失われた宣言のしきい値として使用される待ち時間です。紛失したパケットは、未定義の遅延を持つと指定され、RTLOSSメトリック[RFC6673]についてカウントされるものとします。

The calculations on the delay (RTT) SHALL be performed on the conditional distribution, conditioned on successful packet arrival within Tmax. Also, when all packet delays are stored, the process that calculates the RTT value MUST enforce the Tmax threshold on stored values before calculations. See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

遅延（RTT）の計算は、TMAX内のパケット到着が成功した状態で調整された条件付き分布で実行されなければならない。また、すべてのパケット遅延が格納されている場合、RTT値を計算するプロセスは、計算前に格納値のTMAXしきい値を強制する必要があります。不定値の遅延値を除外するための条件付き配布の詳細については、[RFC3393]のセクション4.1を参照してください。この分析選択の背景については、[RFC6703]のセクション5を参照してください。

The reference method requires some way to distinguish between different packets in a stream to establish correspondence between sending times and receiving times for each successfully arriving packet. Sequence numbers or other send-order identification MUST be retained at the Src or included with each packet to disambiguate packet reordering if it occurs.

参照方法は、ストリーム内の異なるパケットを区別するために何らかの方法で、送信時間と受信時間との間の対応を確立し、それぞれの到着パケットの間の受信時間との間の対応を確立する必要がある。シーケンス番号または他の送信注文の識別は、SRCに保持されるか、またはそれが発生した場合にパケットの並べ替えを解消するために各パケットに含まれていなければなりません。

If a standard measurement protocol is employed, then the measurement process will determine the sequence numbers or timestamps applied to test packets after the Fixed and Runtime Parameters are passed to that process. The chosen measurement protocol will dictate the format of sequence numbers and timestamps, if they are conveyed in the packet payload.

標準的な測定プロトコルが採用されている場合、測定プロセスは、固定パラメータおよび実行時パラメータがそのプロセスに渡された後に、テストパケットに適用されるシーケンス番号またはタイムスタンプを決定します。選択された測定プロトコルは、パケットペイロードで伝達されている場合、シーケンス番号とタイムスタンプのフォーマットを決定します。

Refer to Section 4.4 of [RFC6673] for an expanded discussion of the instruction to "send a Type-P packet back to the Src as quickly as possible" in Section 2.6 of [RFC2681]. Section 8 of [RFC6673] presents additional requirements that MUST be included in the Method of Measurement for this metric.

[RFC2681]の2.6項の「できるだけ早くType-PパケットをSRCに送り返す」という指示については、「RFC6673」のセクション4.4を参照してください。[RFC6673]のセクション8は、このメトリックの測定方法に含まれなければならない追加の要件を示しています。

4.3.2. Packet Stream Generation

4.3.2. パケットストリームの生成

This section provides details regarding packet traffic, which is used as the basis for measurement. In IPPM Metrics, this is called the "stream"; this stream can easily be described by providing the list of stream Parameters.

このセクションでは、測定の基礎として使用されるパケットトラフィックに関する詳細について説明します。IPPMメトリックでは、これは "stream"と呼ばれます。このストリームは、ストリームパラメータのリストを提供することによって簡単に説明できます。

Section 3 of [RFC3432] prescribes the method for generating Periodic streams using associated Parameters.

[RFC3432]のセクション3は、関連するパラメータを使用して周期的なストリームを生成するための方法を規定しています。

incT: The nominal duration of the inter-packet interval, first bit to first bit, with value 0.0200, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a resolution of 0.0001 seconds (0.1 ms).

INCT：パケット間インターバルの名目期間、最初のビットから1番目のビットまで、値0.0200は、秒単位で表されます.4番目のDecimal64の正の値として、= 4（RFC6020のセクション9.3を参照）0.0001秒（0.1ミリ秒）の解像度で。

dT: The duration of the interval for allowed sample start times, with value 1.0, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a resolution of 0.0001 seconds (0.1 ms).

DT：許可されたサンプル開始時間の間隔の期間（秒単位単位単位で表す）、秒単位で表され、分数桁率が4と入力され、0.0001の解像度で秒単位で表されます。秒数（0.1ミリ秒）。

Note: An initiation process with a number of control exchanges resulting in unpredictable start times (within a time interval) may be sufficient to avoid synchronization of periodic streams and is a valid replacement for selecting a start time at random from a fixed interval.

注：予測不可能な開始時刻（時間間隔内）に起因するいくつかの制御交換を有する開始プロセスは、周期的なストリームの同期を回避するのに十分であり得、そして固定間隔からランダムに開始時間を選択するための有効な置換である。

The T0 Parameter will be reported as a measured Parameter. Parameters incT and dT are Fixed Parameters.

T0パラメーターは測定されたパラメーターとして報告されます。パラメータINCTとDTは固定パラメータです。

4.3.3. Traffic Filtering (Observation) Details

4.3.3. トラフィックフィルタリング（観測）詳細

N/A

めずく

4.3.4. Sampling Distribution

4.3.4. 標本分布

N/A

めずく

4.3.5. Runtime Parameters and Data Format

4.3.5. ランタイムパラメータとデータフォーマット

Runtime Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete.

ランタイムパラメータは、測定システムに構成され、測定システムに構成され、完了するための結果を報告する必要ファクタです。

Src: The IP address of the host in the Src Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

SRC：SRCロール内のホストのIPアドレス（IPv4のIPv4-address-no-zone zone zone zize on-zono zone値は、IPv6の場合はipv6、zone-zone zone値）を参照してください。[RFC6991]のセクション4を参照）。

Dst: The IP address of the host in the Dst Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

DST：DSTロール内のホストのIPアドレス（IPv4のIPv4-address-no-zone zone zone zone zone zone値（IPv6の場合はIPv6 - ゾーン値）。[RFC6991]のセクション4を参照）。

T0: A time, the start of a measurement interval (format "date-time" as specified in Section 5.6 of [RFC3339]; see also "date-and-time" in Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is unspecified and Tf is to be interpreted as the duration of the measurement interval. The start time is controlled through other means.

T0：測定間隔の開始（RFC3339]のセクション5.6で指定されているような「日付 - 時刻」。[RFC6991]のセクション3の「日付と時刻」も参照してください。UTCタイムゾーンは[RFC2330]のセクション6.1によって必要です。T0が「ALL-ZEROS」の場合、開始時刻は指定されていません.TFは測定間隔の持続時間として解釈されます。開始時刻は他の手段によって制御されます。

Tf: A time, the end of a measurement interval (format "date-time" as specified in Section 5.6 of [RFC3339]; see also "date-and-time" in Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", an ending time and date is ignored and Tf is interpreted as the duration of the measurement interval.

TF：測定間隔の終わり、[RFC3339]のセクション5.6で指定されているように、「日付 - 時刻」を参照してください。[RFC6991]のセクション3の「日付と時刻」も参照してください。UTCタイムゾーンは[RFC2330]のセクション6.1によって必要です。T0が "All-Zeros"の場合、終了時間と日付は無視され、TFは測定間隔の期間として解釈されます。

4.3.6. Roles

4.3.6. 役割

Src: Launches each packet and waits for return transmissions from the Dst.

SRC：各パケットを起動し、DSTからの戻りトランスミッションを待ちます。

Dst: Waits for each packet from the Src and sends a return packet to the Src.

DST：SRCから各パケットを待機し、SRCに戻りパケットを送信します。

4.4. Output

4.4. 出力

This category specifies all details of the output of measurements using the metric.

このカテゴリは、メトリックを使用した測定値の出力の詳細を指定します。

4.4.1. Type

4.4.1. タイプ

Percentile: For the conditional distribution of all packets with a valid value of round-trip delay (undefined delays are excluded), this is a single value corresponding to the 95th percentile, as follows:

パーセンタイル：有効な往復遅延の有効な値を持つすべてのパケットの条件付き分布の場合、これは次のように、95パーセンタイルに対応する単一の値です。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

不定値の遅延値を除外するための条件付き配布の詳細については、[RFC3393]のセクション4.1を参照してください。この分析選択の背景については、[RFC6703]のセクション5を参照してください。

The percentile = 95, meaning that the reported delay, "95Percentile", is the smallest value of round-trip delay for which the Empirical Distribution Function, EDF(95Percentile), is greater than or equal to 95% of the singleton round-trip delay values in the conditional distribution. See Section 11.3 of [RFC2330] for the definition of the percentile statistic using the EDF.

パーセンタイル= 95、報告された遅延「95Percentile」は、経験的分布関数EDF（95percentile）がシングルトン往復の95％以上の往復遅延の最小値です。条件分布の遅延値EDFを使用したパーセンタイル統計の定義については、[RFC2330]のセクション11.3を参照してください。

For LossRatio, the count of lost packets to total packets sent is the basis for the loss ratio calculation as per Section 6.1 of [RFC6673].

LOSSRATIOの場合、送信された総パケットへの紛失したパケットの数は、[RFC6673]のセクション6.1の損失比計算の基礎です。

4.4.2. Reference Definition

4.4.2. 参照定義

For all outputs:

すべての出力について：

T0: The start of a measurement interval (format "date-time" as specified in Section 5.6 of [RFC3339]; see also "date-and-time" in Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330].

T0：[RFC3339]のセクション5.6で指定されているように、測定間隔の開始（「日付 - 時刻」。[RFC6991]のセクション3の「日付と時刻」を参照してください。UTCタイムゾーンは[RFC2330]のセクション6.1によって必要です。

TF：測定間隔の終わり（RFC3339]のセクション5.6で指定されているような「日付 - 時刻」。[RFC6991]のセクション3の「日付と時刻」も参照してください。UTCタイムゾーンは[RFC2330]のセクション6.1によって必要です。

TotalPkts: The count of packets sent by the Src to the Dst during the measurement interval.

TotalPkts：測定間隔中にSRCによってDSTに送信されたパケットの数。

95Percentile: The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of 0.000000001 seconds (1.0 ns).

95perCentile：結果の時間値は、0.000000001秒（1.0 ns）の解像度を持つDecimal64型の正の値として、秒単位で表されます（[RFC6020]のセクション9.3）。

Percent_LossRatio: The numeric value of the result is expressed in units of lost packets to total packets times 100%, as a positive value of type decimal64 with fraction digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of 0.0000000001.

percent_lossratio：結果の数値は、0.0000000001の解像度を持つDecimal64の型の正の値100％に、パケットを紛失したパケット単位100％で表されます（[RFC6020]のセクション9.3を参照）。

4.4.3. Metric Units

4.4.3. メートル法単位

The 95th percentile of round-trip delay is expressed in seconds.

往復遅延の95パーセンタイルは秒単位で表されます。

The round-trip loss ratio is expressed as a percentage of lost packets to total packets sent.

往復損失率は、送信された総パケットに対する紛失したパケットの割合として表されます。

4.4.4. Calibration

4.4.4. 較正

Section 3.7.3 of [RFC7679] provides a means to quantify the systematic and random errors of a time measurement. Calibration in-situ could be enabled with an internal loopback at the Source host that includes as much of the measurement system as possible, performs address manipulation as needed, and provides some form of isolation (e.g., deterministic delay) to avoid send-receive interface contention. Some portion of the random and systematic error can be characterized in this way.

[RFC7679]のセクション3.7.3は、時間測定の系統的およびランダムな誤差を定量化するための手段を提供します。キャリブレーションインサイトは、できるだけ多くの測定システムを含むソースホストで内部ループバックを使用して有効にすることができ、送信受信インタフェースを回避するためにアドレスの操作を実行します。競合このようにして、ランダムおよび体系的な誤差のいくつかの部分を特徴付けることができる。

測定コントローラが校正測定を要求すると、ループバックが適用され、結果は通常の測定値と同じ形式で出力され、それが校正結果であることを示します。

Both internal loopback calibration and clock synchronization can be used to estimate the available accuracy of the Output Metric Units. For example, repeated loopback delay measurements will reveal the portion of the output result resolution that is the result of system noise and is thus inaccurate.

内部ループバックキャリブレーションとクロック同期の両方を使用して、出力メトリックユニットの使用可能な精度を推定できます。例えば、繰り返しのループバック遅延測定は、システムノイズの結果であり、したがって不正確である出力結果分解能の部分を明らかにする。

4.5. Administrative Items

4.5. 管理項目

4.5.1. Status

4.5.1. 状態

Current

現在

4.5.2. Requester

4.5.2. 要求者

RFC 8912

4.5.3. Revision

4.5.3. リビジョン

1.0

4.5.4. Revision Date

4.5.4. 改訂日

2021-11-17

4.6. Comments and Remarks

4.6. コメントと備考

None

なし

5. Packet Delay Variation Registry Entry

5. パケット遅延バリエーションレジストリエントリ

This section gives an initial Registry Entry for a Packet Delay Variation (PDV) metric.

このセクションでは、パケット遅延バリエーション（PDV）メトリックの初期レジストリエントリを示します。

5.1. Summary

5.1. 概要

This category includes multiple indexes to the Registry Entry: the element ID and Metric Name.

このカテゴリには、レジストリエントリへの複数のインデックスが含まれています。要素IDとメトリック名。

5.1.1. ID (Identifier)

5.1.1. ID（識別子）

IANA has allocated the numeric Identifier 3 for the Named Metric Entry in Section 5. See Section 5.1.2 for mapping to Name.

IANAはセクション5の名前付きメトリックエントリの数値識別子3を割り当てました。名前へのマッピングについては、セクション5.1.2を参照してください。

5.1.2. Name

5.1.2. 名前

3: OWPDV_Active_IP-UDP-Periodic_RFC8912sec5_Seconds_95Percentile

3：OWPDV_ACTIVE_IP-UDP-PERIDERIC_RFC8912SEC5_SECONDSS_95PERCENTILE.

5.1.3. URI

5.1.3. u u

   URL: https://www.iana.org/assignments/performance-metrics/
   OWPDV_Active_IP-UDP-Periodic_RFC8912sec5_Seconds_95Percentile

5.1.4. Description

5.1.4. 説明

This metric assesses packet delay variation with respect to the minimum delay observed on the periodic stream. The output is expressed as the 95th percentile of the one-way packet delay variation distribution.

このメトリックは、周期的なストリームで観測された最小遅延に関してパケット遅延の変動を評価します。出力は、一方向パケット遅延変動分布の95パーセンタイルとして表されます。

5.1.5. Change Controller

5.1.5. コントローラを変更する

IETF

i i

5.1.6. Version (of Registry Format)

5.1.6. バージョン（レジストリフォーマット）

1.0

5.2. Metric Definition

5.2. メートル定義

This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called "Fixed Parameters".

5.2.1. Reference Definition

5.2.1. 参照定義

   Paxson, V., Almes, G., Mahdavi, J., and M.  Mathis, "Framework for IP
   Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998,
   <https://www.rfc-editor.org/info/rfc2330>.  [RFC2330]

   Demichelis, C. and P.  Chimento, "IP Packet Delay Variation Metric
   for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393,
   November 2002, <https://www.rfc-editor.org/info/rfc3393>.  [RFC3393]

   Morton, A. and B.  Claise, "Packet Delay Variation Applicability
   Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009,
   <https://www.rfc-editor.org/info/rfc5481>.  [RFC5481]

   Mills, D., Martin, J., Ed., Burbank, J., and W.  Kasch, "Network Time
   Protocol Version 4: Protocol and Algorithms Specification", RFC 5905,
   DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/
   rfc5905>.  [RFC5905]

See Sections 2.4 and 3.4 of [RFC3393]. The measured singleton delay differences are referred to by the variable name "ddT" (applicable to all forms of delay variation). However, this Metric Entry specifies the PDV form defined in Section 4.2 of [RFC5481], where the singleton PDV for packet i is referred to by the variable name "PDV(i)".

[RFC3393]のセクション2.4と3.4を参照してください。測定されたシングルトン遅延差は、可変名「DDT」によって呼ばれます（すべての形式の遅延変動に適用されます）。ただし、このメトリックエントリは[RFC5481]のセクション4.2で定義されているPDVフォームを指定します。ここで、パケットiのシングルトンPDVは、変数名 "PDV（i）"によって参照されます。

5.2.2. Fixed Parameters

5.2.2. 固定パラメータ

IPv4 header values: DSCP: Set to 0 TTL: Set to 255 Protocol: Set to 17 (UDP)

IPv4ヘッダー値：DSCP：0 TTLに設定：255プロトコルに設定：17（UDP）に設定

IPv6 header values: DSCP: Set to 0 Hop Count: Set to 255 Next Header: Set to 17 (UDP) Flow Label: Set to 0 Extension Headers: None

IPv6ヘッダー値：DSCP：0ホップ数に設定：255次のヘッダーに設定：17（UDP）フローラベル：0に設定します。

UDP header values: Checksum: The checksum MUST be calculated and the non-zero checksum included in the header

UDPヘッダー値：チェックサム：チェックサムを計算し、ヘッダーに含まれていないゼロ以外のチェックサムを必要とします。

UDP Payload: Total of 200 bytes

UDPペイロード：合計200バイト

F: A selection function unambiguously defining the packets from the stream selected for the metric. See Section 4.2 of [RFC5481] for the PDV form.

f：選択関数は、メトリックのために選択されたストリームからパケットを明確に定義していません。PDVフォームの[RFC5481]のセクション4.2を参照してください。

See the Packet Stream Generation section for two additional Fixed Parameters.

2つの追加の固定パラメータについては、パケットストリーム生成セクションを参照してください。

5.3. Method of Measurement

5.3. 測定方法

This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous method for implementations.

このカテゴリには、RFCの関連セクションへの参照と、実装の明確な方法を確保するために必要な補足情報が含まれています。

5.3.1. Reference Methods

5.3.1. 参照方法

See Sections 2.6 and 3.6 of [RFC3393] for general singleton element calculations. This Metric Entry requires implementation of the PDV form defined in Section 4.2 of [RFC5481]. Also see measurement considerations in Section 8 of [RFC5481].

一般的なシングルトン要素の計算のための[RFC3393]のセクション2.6と3.6を参照してください。このメトリックエントリは[RFC5481]のセクション4.2で定義されているPDV形式の実装を必要とします。[RFC5481]のセクション8の測定に関する考慮事項も参照してください。

参照方法は、パケット到着の最大待ち時間を実装することによって、長遅延パケットと紛失したパケットを区別します。TMAXは、パケットが失われた宣言のしきい値として使用される待ち時間です。紛失したパケットは、未定義の遅延を有すると指定されなければならない。

The calculations on the one-way delay SHALL be performed on the conditional distribution, conditioned on successful packet arrival within Tmax. Also, when all packet delays are stored, the process that calculates the one-way delay value MUST enforce the Tmax threshold on stored values before calculations. See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

一方向遅延の計算は、TMAX内の成功したパケット到着で調整された条件付き分布に対して実行されなければならない。また、すべてのパケット遅延が格納されている場合、一方向遅延値を計算するプロセスは、計算前に格納値のTMAXしきい値を強制する必要があります。不定値の遅延値を除外するための条件付き配布の詳細については、[RFC3393]のセクション4.1を参照してください。この分析選択の背景については、[RFC6703]のセクション5を参照してください。

5.3.2. Packet Stream Generation

5.3.2. パケットストリームの生成

Section 3 of [RFC3432] prescribes the method for generating Periodic streams using associated Parameters.

[RFC3432]のセクション3は、関連するパラメータを使用して周期的なストリームを生成するための方法を規定しています。

The T0 Parameter will be reported as a measured Parameter. Parameters incT and dT are Fixed Parameters.

T0パラメーターは測定されたパラメーターとして報告されます。パラメータINCTとDTは固定パラメータです。

5.3.3. Traffic Filtering (Observation) Details

5.3.3. トラフィックフィルタリング（観測）詳細

N/A

めずく

5.3.4. Sampling Distribution

5.3.4. 標本分布

N/A

めずく

5.3.5. Runtime Parameters and Data Format

5.3.5. ランタイムパラメータとデータフォーマット

Src: The IP address of the host in the Src Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

Dst: The IP address of the host in the Dst Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

DST：DSTロール内のホストのIPアドレス（IPv4のIPv4-address-no-zone zone zone zone zone zone値（IPv6の場合はIPv6 - ゾーン値）。[RFC6991]のセクション4を参照）。

5.3.6. Roles

5.3.6. 役割

Src: Launches each packet and waits for return transmissions from the Dst.

SRC：各パケットを起動し、DSTからの戻りトランスミッションを待ちます。

Dst: Waits for each packet from the Src and sends a return packet to the Src (when required by the test protocol).

DST：SRCから各パケットを待機し、SRCに戻りパケットを送信します（テストプロトコルによって必要な場合）。

5.4. Output

5.4. 出力

This category specifies all details of the output of measurements using the metric.

このカテゴリは、メトリックを使用した測定値の出力の詳細を指定します。

5.4.1. Type

5.4.1. タイプ

Percentile: For the conditional distribution of all packets with a valid value of one-way delay (undefined delays are excluded), this is a single value corresponding to the 95th percentile, as follows:

パーセンタイル：有効な一方向遅延の有効な値を持つすべてのパケットの条件付き分布の場合、これは次のように95パーセンタイルに対応する単一の値です。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

The percentile = 95, meaning that the reported delay, "95Percentile", is the smallest value of one-way PDV for which the Empirical Distribution Function, EDF(95Percentile), is greater than or equal to 95% of the singleton one-way PDV values in the conditional distribution. See Section 11.3 of [RFC2330] for the definition of the percentile statistic using the EDF.

パーセンタイル= 95、これは報告された遅延「95Percentile」は、経験的分布関数EDF（95Percentile）がシングルトンの一方向の95％以上の一方向PDVの最小値です。条件分布におけるPDV値。EDFを使用したパーセンタイル統計の定義については、[RFC2330]のセクション11.3を参照してください。

5.4.2. Reference Definition

5.4.2. 参照定義

95perCentile：結果の時間値は、0.000000001秒（1.0 ns）の解像度を持つDecimal64型の正の値として、秒単位で表されます（[RFC6020]のセクション9.3）、0.0000001秒（1.0 ns）、無損失で[RFC5905]のセクション6に従って、64ビットNTPタイムスタンプへの/からの変換。

5.4.3. Metric Units

5.4.3. メートル法単位

The 95th percentile of one-way PDV is expressed in seconds.

一方向PDVの95パーセンタイルは秒単位で表されます。

5.4.4. Calibration

5.4.4. 較正

Section 3.7.3 of [RFC7679] provides a means to quantify the systematic and random errors of a time measurement. Calibration in-situ could be enabled with an internal loopback that includes as much of the measurement system as possible, performs address manipulation as needed, and provides some form of isolation (e.g., deterministic delay) to avoid send-receive interface contention. Some portion of the random and systematic error can be characterized in this way.

[RFC7679]のセクション3.7.3は、時間測定の系統的およびランダムな誤差を定量化するための手段を提供します。較正インサイナは、できるだけ多くの測定システムを含む内部ループバックで有効にすることができ、送信受信インタフェースの競合を回避するためにアドレス操作を行い、ある種の絶縁（例えば、決定論的遅延）を提供することができる。このようにして、ランダムおよび体系的な誤差のいくつかの部分を特徴付けることができる。

For one-way delay measurements, the error calibration must include an assessment of the internal clock synchronization with its external reference (this internal clock is supplying timestamps for measurement). In practice, the time offsets [RFC5905] of clocks at both the Source and Destination are needed to estimate the systematic error due to imperfect clock synchronization (the time offsets are smoothed; thus, the random variation is not usually represented in the results).

一方向の遅延測定のために、エラー校正には、外部リファレンスとの内部クロック同期の評価を含める必要があります（この内部クロックは測定用のタイムスタンプを供給しています）。実際には、電源と宛先の両方のクロックのクロックの時間オフセット[RFC5905]は、不完全なクロック同期のために系統的な誤差を推定するために必要です（時間オフセットは滑らかにします。したがって、ランダムな変動は通常結果には表されません）。

time_offset: The time value of the result is expressed in units of seconds, as a signed value of type decimal64 with fraction digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per Section 6 of [RFC5905].

time_offset：結果の時間値は、0.000000001秒（1.0 ns）の解像度が0.000000001秒（1.0 ns）の解像度を持つDecimal64型の符号付き値として、秒単位で表されます（[RFC6020]のセクション9.3を参照）。[RFC5905]のセクション6に従って、64ビットNTPタイムスタンプへの/からの変換。

When a measurement controller requests a calibration measurement, the loopback is applied and the result is output in the same format as a normal measurement, with an additional indication that it is a calibration result. In any measurement, the measurement function SHOULD report its current estimate of the time offset [RFC5905] as an indicator of the degree of synchronization.

測定コントローラが校正測定を要求すると、ループバックが適用され、結果は通常の測定値と同じ形式で出力され、それが校正結果であることを示します。任意の測定において、測定機能は、同期の程度の指標として、時間オフセット[RFC5905]の現在の見積もりを報告する必要があります。

5.5. Administrative Items

5.5. 管理項目

5.5.1. Status

5.5.1. 状態

Current

現在

5.5.2. Requester

5.5.2. 要求者

RFC 8912

5.5.3. Revision

5.5.3. リビジョン

1.0

5.5.4. Revision Date

5.5.4. 改訂日

2021-11-17

5.6. Comments and Remarks

5.6. コメントと備考

Lost packets represent a challenge for delay variation metrics. See Section 4.1 of [RFC3393] and the delay variation applicability statement [RFC5481] for extensive analysis and comparison of PDV and an alternate metric, IPDV (Inter-Packet Delay Variation).

紛失したパケットは、遅延ばらつき測定基準の課題を表します。[RFC3393]のセクション4.1とPDVと代替メトリックの比較のための遅延変動適用範囲版[RFC5481]を参照してください.iPDV（パケット間遅延バリエーション）。

6. DNS Response Latency and Loss Registry Entries

6. DNS応答待ち時間および損失レジストリエントリ

This section gives initial Registry Entries for DNS Response Latency and Loss from a network user's perspective, for a specific named resource. The metric can be measured repeatedly for different named resources. [RFC2681] defines a round-trip delay metric. We build on that metric by specifying several of the input Parameters to precisely define two metrics for measuring DNS latency and loss.

このセクションでは、特定の名前付きリソースのために、ネットワークユーザーのパースペクティブからのDNS応答の待ち時間と損失の初期レジストリエントリを示します。メトリックは、異なる名前付きリソースに対して繰り返し測定できます。[RFC2681]往復遅延メトリックを定義します。DNSの待ち時間と損失を測定するための2つのメトリックを正確に定義するために、入力パラメータのいくつかを指定することによってそのメトリックを構築します。

All column entries besides the ID, Name, Description, and Output Reference Method categories are the same; thus, this section defines two closely related Registry Entries. As a result, IANA has assigned corresponding URLs to each of the two Named Metrics.

6.1. Summary

6.1. 概要

This category includes multiple indexes to the Registry Entries: the element ID and Metric Name.

このカテゴリには、レジストリエントリへの複数のインデックスが含まれています。要素IDとメトリック名。

6.1.1. ID (Identifier)

6.1.1. ID（識別子）

IANA has allocated the numeric Identifiers 4 and 5 for the two Named Metric Entries in Section 6. See Section 6.1.2 for mapping to Names.

IANAはセクション6の2つの名前付きメトリックエントリに対して数値識別子4と5を割り当てました。名前へのマッピングについては、セクション6.1.2を参照してください。

6.1.2. Name

6.1.2. 名前

4: RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw

4：RTDNS_ACTIVE_IP-UDP-POISSON_RFC8912SEC6_SECONDS_RAW

5: RLDNS_Active_IP-UDP-Poisson_RFC8912sec6_Logical_Raw

5：RLDNS_ACTIVE_IP-UDP-POISSON_RFC8912SEC6_LOGICAL_RAW

6.1.3. URI

6.1.3. u u

   URL: https://www.iana.org/assignments/performance-metrics/
   RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw

   URL: https://www.iana.org/assignments/performance-metrics/
   RLDNS_Active_IP-UDP-Poisson_RFC8912sec6_Logical_Raw

6.1.4. Description

6.1.4. 説明

This is a metric for DNS Response performance from a network user's perspective, for a specific named resource. The metric can be measured repeatedly using different resource names.

これは、特定の名前付きリソースに対する、ネットワークユーザーのパースペクティブからのDNS応答パフォーマンスのメトリックです。メトリックは、さまざまなリソース名を使用して繰り返し測定できます。

RTDNS: This metric assesses the response time, the interval from the query transmission to the response.

RTDNS：このメトリックは応答時間、クエリ送信から応答への間隔を評価します。

RLDNS: This metric indicates that the response was deemed lost. In other words, the response time exceeded the maximum waiting time.

RLDNS：このメトリックは、応答が失われたと見なされたことを示します。つまり、応答時間は最大待ち時間を超えました。

6.1.5. Change Controller

6.1.5. コントローラを変更する

IETF

i i

6.1.6. Version (of Registry Format)

6.1.6. バージョン（レジストリフォーマット）

1.0

6.2. Metric Definition

6.2. メートル定義

This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called "Fixed Parameters".

6.2.1. Reference Definition

6.2.1. 参照定義

For Delay:

遅延の場合：

      Mockapetris, P., "Domain names - implementation and
      specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November
      1987, <https://www.rfc-editor.org/info/rfc1035> (and updates).
      [RFC1035]

      Almes, G., Kalidindi, S., and M.  Zekauskas, "A Round-trip Delay
      Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999,
      <https://www.rfc-editor.org/info/rfc2681>.  [RFC2681]

For DNS Response Latency, the entities in [RFC1035] must be mapped to [RFC2681]. The Local Host with its User Program and Resolver take the Role of "Src", and the Foreign Name Server takes the Role of "Dst".

DNS応答待ち時間の場合、[RFC1035]のエンティティは[RFC2681]にマッピングする必要があります。ユーザープログラムとリゾルバを持つローカルホストは "src"の役割を取り、外部ネームサーバーは "dst"の役割を取ります。

Note that although the definition of round-trip delay between the Source (Src) and the Destination (Dst) at T as provided in Section 2.4 of [RFC2681] is directionally ambiguous in the text, this metric tightens the definition further to recognize that the host in the Src Role will send the first packet to the host in the Dst Role and will ultimately receive the corresponding return packet from the Dst (when neither is lost).

[RFC2681]のセクション2.4のセクション2.4で提供されているように、ソース（SRC）とTEST（DST）の往復遅延の定義はテキスト内で方向性があいまいですが、このメトリックはその定義をさらに締め付けて、SRCロールのホストは、DSTロール内の最初のパケットをホストに送信し、最終的にはDSTから対応する戻りパケットを受信します（どちらも失われない場合）。

For Loss:

損失のために：

      Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI
      10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/
      rfc6673>.  [RFC6673]

For DNS Response Loss, the entities in [RFC1035] must be mapped to [RFC6673]. The Local Host with its User Program and Resolver take the Role of "Src", and the Foreign Name Server takes the Role of "Dst".

DNS応答損失の場合は、[RFC1035]のエンティティを[RFC6673]にマッピングする必要があります。ユーザープログラムとリゾルバを持つローカルホストは "src"の役割を取り、外部ネームサーバーは "dst"の役割を取ります。

Both response time and Loss metrics employ a maximum waiting time for received responses, so the count of lost packets to total packets sent is the basis for the loss determination as per Section 4.3 of [RFC6673].

応答時間と損失メトリックの両方を使用すると、受信した応答の最大待ち時間が採用されているため、送信された合計パケットへの紛失したパケットの数は[RFC6673]のセクション4.3とのような損失決定の基礎となります。

6.2.2. Fixed Parameters

6.2.2. 固定パラメータ

Type-P as defined in Section 13 of [RFC2330]: IPv4 header values: DSCP: Set to 0 TTL: Set to 255 Protocol: Set to 17 (UDP)

[RFC2330]のセクション13で定義されているTYPE-P：IPv4ヘッダー値：DSCP：0 TTLに設定：255プロトコルに設定：17（UDP）に設定

IPv6 header values: DSCP: Set to 0 Hop Count: Set to 255 Next Header: Set to 17 (UDP) Flow Label: Set to 0 Extension Headers: None

IPv6ヘッダー値：DSCP：0ホップ数に設定：255次のヘッダーに設定：17（UDP）フローラベル：0に設定します。

UDP header values: Source port: 53 Destination port: 53 Checksum: The checksum MUST be calculated and the non-zero checksum included in the header

UDPヘッダー値：送信元ポート：53宛先ポート：53チェックサム：チェックサムを計算し、ヘッダーに含まれていないゼロ以外のチェックサムを必要とする必要があります。

Payload: The payload contains a DNS message as defined in [RFC1035] with the following values:

ペイロード：ペイロードには、[RFC1035]で定義されているDNSメッセージが含まれています。

The DNS header section contains: Identification (see the Runtime column) QR: Set to 0 (Query) OPCODE: Set to 0 (standard query) AA: Not set TC: Not set RD: Set to 1 (recursion desired) RA: Not set RCODE: Not set QDCOUNT: Set to 1 (only one entry) ANCOUNT: Not set NSCOUNT: Not set ARCOUNT: Not set

DNSヘッダーセクションには、次のものが含まれています。（実行時列を参照）QR：0（クエリ）opcode：0に設定します（標準照会）aa：set tc：set set rd：not set rd：not to 1に設定します（recursion）rcodeを設定します。

The Question section contains: QNAME: The Fully Qualified Domain Name (FQDN) provided as input for the test; see the Runtime column

質問セクションには、次のものが含まれています。QName：テストの入力として提供されている完全修飾ドメイン名（FQDN）。ランタイム列を参照してください

QTYPE: The query type provided as input for the test; see the Runtime column

QType：テストの入力として提供されているクエリタイプ。ランタイム列を参照してください

QCLASS: Set to 1 for IN

Qclass：INのために1に設定

The other sections do not contain any Resource Records (RRs).

他のセクションにはリソースレコード（RRS）が含まれていません。

Other measurement Parameters: Tmax: A loss threshold waiting time (and to help disambiguate queries). The value is 5.0, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a resolution of 0.0001 seconds (0.1 ms), with lossless conversion to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905].

その他の測定パラメータ：TMAX：損失しきい値待ち時間（およびクエリを曖昧さを曖昧にするのに役立ちます）。値は、秒単位で表されます。秒単位で表され、桁数桁= 4（[RFC6020]のセクション9.3）、および0.0001秒（0.1ミリ秒）の解像度が0.1 ms /からの解像度を持ちます。[RFC5905]のセクション6に従って、32ビットNTPタイムスタンプ。

Observation: Reply packets will contain a DNS Response and may contain RRs.

観測：返信パケットにはDNS応答が含まれ、RRSが含まれている可能性があります。

6.3. Method of Measurement

6.3. 測定方法

This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous method for implementations.

このカテゴリには、RFCの関連セクションへの参照と、実装の明確な方法を確保するために必要な補足情報が含まれています。

6.3.1. Reference Methods

6.3.1. 参照方法

The methodology for this metric (equivalent to Type-P-Round-trip-Delay-Poisson-Stream) is defined as in Section 2.6 of [RFC2681] (for singletons) and Section 3.6 of [RFC2681] (for samples) using the Type-P and Timeout defined in the Fixed Parameters column.

このメトリックの方法論（Type-P-round-rave-delay-poisson-stream）は、[RFC2681]のセクション2.6（シングルトン用）およびTypeを使用した[RFC2681]のセクション3.6の項で定義されています。固定パラメータ列に定義されているタイムアウトとタイムアウト。

The reference method distinguishes between long-delayed packets and lost packets by implementing a maximum waiting time for packet arrival. Tmax is the waiting time used as the threshold to declare a response packet lost. Lost packets SHALL be designated as having undefined delay and counted for the RLDNS metric.

参照方法は、パケット到着の最大待ち時間を実装することによって、長遅延パケットと紛失したパケットを区別します。TMAXは、応答パケットが失われた応答パケットを宣言するためのしきい値として使用される待ち時間です。紛失したパケットは、未定義の遅延を有すると指定され、RLDNSメトリックについてカウントされるものとします。

The reference method requires some way to distinguish between different packets in a stream to establish correspondence between sending times and receiving times for each successfully arriving reply.

参照方法は、ストリーム内の異なるパケットを区別するために何らかの方法で、送信時間と受信回数の間の対応を確立する必要があります。

DNS messages bearing queries provide for random ID Numbers in the Identification header field, so more than one query may be launched while a previous request is outstanding when the ID Number is used. Therefore, the ID Number MUST be retained at the Src and included with each response packet to disambiguate packet reordering if it occurs.

識別ヘッダーフィールドのランダムID番号をベアリングするDNSメッセージは、ID番号が使用されているときに前の要求が未解決である間に複数のクエリが起動される可能性があります。したがって、ID番号はSRCに保持され、それが発生した場合にパケットの並べ替えを解消するために各応答パケットに含まれていなければなりません。

If a DNS Response does not arrive within Tmax, the response time RTDNS is undefined, and RLDNS = 1. The Message ID SHALL be used to disambiguate the successive queries that are otherwise identical.

DNS応答がTMAX内に到着しない場合、応答時間RTDNSは未定義であり、RLDNS = 1の場合、メッセージIDを使用して、そうでなければ同一の連続クエリを曖昧させる必要があります。

Since the ID Number field is only 16 bits in length, it places a limit on the number of simultaneous outstanding DNS queries during a stress test from a single Src address.

ID番号フィールドは16ビットの長さであるため、ストレステスト中に単一のSRCアドレスからの同時優れたDNSクエリの数に制限があります。

Refer to Section 4.4 of [RFC6673] for an expanded discussion of the instruction to "send a Type-P packet back to the Src as quickly as possible" in Section 2.6 of [RFC2681]. However, the DNS server is expected to perform all required functions to prepare and send a response, so the response time will include processing time and network delay. Section 8 of [RFC6673] presents additional requirements that SHALL be included in the Method of Measurement for this metric.

[RFC2681]の2.6項の「できるだけ早くType-PパケットをSRCに送り返す」という指示については、「RFC6673」のセクション4.4を参照してください。ただし、DNSサーバーは、応答を準備して送信するために必要なすべての機能を実行することが期待されているため、応答時間に処理時間とネットワーク遅延が含まれます。[RFC6673]のセクション8は、この測定基準の測定方法に含まれる追加の要件を示しています。

In addition to operations described in [RFC2681], the Src MUST parse the DNS headers of the reply and prepare the query response information for subsequent reporting as a measured result, along with the round-trip delay.

[RFC2681]で説明されている操作に加えて、SRCは返信のDNSヘッダーを解析し、その後のレポートのためのクエリ応答情報を測定結果として、往復遅延とともに準備しなければなりません。

6.3.2. Packet Stream Generation

6.3.2. パケットストリームの生成

Section 11.1.3 of [RFC2330] provides three methods to generate Poisson sampling intervals. The reciprocal of lambda is the average packet spacing; thus, the Runtime Parameter is Reciprocal_lambda = 1/lambda, in seconds.

[RFC2330]のセクション11.1.3は、ポアソンサンプリング間隔を生成するための3つの方法を提供します。ラムダの逆数は平均パケット間隔です。したがって、ランタイムパラメータはincrocal_lambda = 1 / lambda、秒単位でです。

Method 3 SHALL be used. Where given a start time (Runtime Parameter), the subsequent send times are all computed prior to measurement by computing the pseudorandom distribution of inter-packet send times (truncating the distribution as specified in the Parameter Trunc), and the Src sends each packet at the computed times.

方法3を使用する。開始時間（ランタイムパラメータ）が与えられた場合、後続の送信時間はすべて、パケット間送信時間の疑似ランダム分布を計算する前に測定前（パラメータTRUNCで指定されている配信を切り捨てて）、SRCは各パケットを送信することによって計算されます。計算された時間

Note that Trunc is the upper limit on inter-packet times in the Poisson distribution. A random value greater than Trunc is set equal to Trunc instead.

TRUNCは、ポアソン分布におけるパケット間時間の上限であることに注意してください。TRUNCより大きいランダム値は、代わりにTRUNCに等しく設定されています。

6.3.3. Traffic Filtering (Observation) Details

6.3.3. トラフィックフィルタリング（観測）詳細

N/A

めずく

6.3.4. Sampling Distribution

6.3.4. 標本分布

N/A

めずく

6.3.5. Runtime Parameters and Data Format

6.3.5. ランタイムパラメータとデータフォーマット

Runtime Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete.

ランタイムパラメータは、測定システムに構成され、測定システムに構成され、完了するための結果を報告する必要ファクタです。

Src: The IP address of the host in the Src Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

Dst: The IP address of the host in the Dst Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

DST：DSTロール内のホストのIPアドレス（IPv4のIPv4-address-no-zone zone zone zone zone zone値（IPv6の場合はIPv6 - ゾーン値）。[RFC6991]のセクション4を参照）。

Reciprocal_lambda: Average packet interval for Poisson streams, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020]) with a resolution of 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905].

replorcal_lambda：秒単位で表されるPoisson Streamの平均パケット間隔は、分数桁= 4と入力され、0.0001秒（0.1ミリ秒）の解像度で、そして無損失で[RFC5905]のセクション6に従って、32ビットNTPタイムスタンプへの変換。

Trunc: Upper limit on Poisson distribution, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020]) with a resolution of 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905] (values above this limit will be clipped and set to the limit value).

TRUNC：秒単位で表されるPoisson Distributionの上限、0.0001秒（0.1ミリ秒）の解像度を持つDECIMAL64型の正の値として表しています（[RFC6020]）、無損失変換[RFC5905]のセクション6に従って、32ビットNTPタイムスタンプの間（この制限より上の値は切り取られ、制限値に設定されます）。

ID: The 16-bit Identifier assigned by the program that generates the query. The ID value must vary in successive queries (a list of IDs is needed); see Section 4.1.1 of [RFC1035]. This Identifier is copied into the corresponding reply and can be used by the requester (Src) to match replies with any outstanding queries.

ID：クエリを生成するプログラムによって割り当てられた16ビット識別子。ID値は連続したクエリで変化しなければなりません（IDのリストが必要です）。[RFC1035]のセクション4.1.1を参照してください。この識別子は対応する返信にコピーされ、要求者（SRC）がrepliseを抜群のクエリと一致させることができます。

QNAME: The domain name of the query, formatted as specified in Section 4 of [RFC6991].

qname：[RFC6991]のセクション4で指定されているようにフォーマットされたクエリのドメイン名。

QTYPE: The query type, which will correspond to the IP address family of the query (decimal 1 for IPv4 or 28 for IPv6), formatted as a uint16, as per Section 9.2 of [RFC6020].

QTYPE：クエリのIPアドレスファミリ（IPv4またはIPv6の場合は10進数1）に対応します（IPv4またはIPv6の場合は10進数1）、uint16としてフォーマットされています。

6.3.6. Roles

6.3.6. 役割

Src: Launches each packet and waits for return transmissions from the Dst.

SRC：各パケットを起動し、DSTからの戻りトランスミッションを待ちます。

Dst: Waits for each packet from the Src and sends a return packet to the Src.

DST：SRCから各パケットを待機し、SRCに戻りパケットを送信します。

6.4. Output

6.4. 出力

This category specifies all details of the output of measurements using the metric.

このカテゴリは、メトリックを使用した測定値の出力の詳細を指定します。

6.4.1. Type

6.4.1. タイプ

Raw: For each DNS query packet sent, sets of values as defined in the next column, including the status of the response, only assigning delay values to successful query-response pairs.

RAW：送信された各DNSクエリパケットの場合、応答のステータスを含む次の列に定義されている値のセットは、クエリ応答ペアに遅延値を割り当てるだけです。

6.4.2. Reference Definition

6.4.2. 参照定義

For all outputs:

すべての出力について：

T: The time the DNS query was sent during the measurement interval (format "date-time" as specified in Section 5.6 of [RFC3339]; see also "date-and-time" in Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330].

T：測定間隔中にDNSクエリが送信された時間（RFC3339]のセクション5.6で指定されているように、「日付 - 時刻」を参照してください。[RFC6991]のセクション3の「日付と時刻」も参照してください。UTCタイムゾーンは[RFC2330]のセクション6.1によって必要です。

dT: The time value of the round-trip delay to receive the DNS Response, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per Section 6 of [RFC5905]. This value is undefined when the response packet is not received at the Src within a waiting time of Tmax seconds.

DT：秒単位で表されるDNS応答を受信するための往復遅延の時間値は、分数桁= 9を有するDECIMAL64の正の値として表される（RFC6020のセクション9.3参照）0.000000001秒の解像度（1.0 NS）、および[RFC5905]のセクション6に従って、64ビットNTPタイムスタンプへの/非可逆変換。この値は、応答パケットがTMAX秒の待ち時間内にSRCで受信されない場合は未定義です。

RCODE: The value of the RCODE field in the DNS Response header, expressed as a uint64 as specified in Section 9.2 of [RFC6020]. Non-zero values convey errors in the response, and such replies must be analyzed separately from successful requests.

RCODE：[RFC6020]のセクション9.2で指定されているUINT64として表される、DNS応答ヘッダーのRCODEフィールドの値。ゼロ以外の値は応答のエラーを伝え、そのような返信は正常な要求とは別に分析されなければなりません。

Logical: The numeric value of the result is expressed as a Logical value, where 1 = Lost and 0 = Received, as a positive value of type uint8 (represents integer values between 0 and 255, inclusively (see Section 9.2 of [RFC6020]). Note that for queries with outcome 1 = Lost, dT and RCODE will be set to the maximum for decimal64 and uint64, respectively.

論理：結果の数値は論理値として表されます。ここで、1 = uint8型の正の値として、1 = LOSTと0 =受信したものです（0から255の間の整数値を表します（RFC6020のセクション9.2を参照）。。結果1 =失われたクエリの場合、DTとRCODEはそれぞれDECIMAL64とUINT64の最大値に設定されます。

6.4.3. Metric Units

6.4.3. メートル法単位

RTDNS: Round-trip delay, dT, is expressed in seconds.

RTDNS：往復遅延DTは秒単位で表されます。

RLDNS: The Logical value, where 1 = Lost and 0 = Received.

RLDNS：論理値.1 = LOSTと0 =受信しました。

6.4.4. Calibration

6.4.4. 較正

Section 3.7.3 of [RFC7679] provides a means to quantify the systematic and random errors of a time measurement. Calibration in-situ could be enabled with an internal loopback at the Source host that includes as much of the measurement system as possible, performs address and payload manipulation as needed, and provides some form of isolation (e.g., deterministic delay) to avoid send-receive interface contention. Some portion of the random and systematic error can be characterized in this way.

[RFC7679]のセクション3.7.3は、時間測定の系統的およびランダムな誤差を定量化するための手段を提供します。校正インサイトは、できるだけ多くの測定システムを含むソースホストで内部ループバックを使用して有効にすることができ、必要に応じてアドレスおよびペイロードの操作を実行し、送信を避けるためにある種の分離（例えば、決定論的遅延）を提供します。インタフェースの競合を受信します。このようにして、ランダムおよび体系的な誤差のいくつかの部分を特徴付けることができる。

6.5. Administrative Items

6.5. 管理項目

6.5.1. Status

6.5.1. 状態

Current

現在

6.5.2. Requester

6.5.2. 要求者

RFC 8912

6.5.3. Revision

6.5.3. リビジョン

1.0

6.5.4. Revision Date

6.5.4. 改訂日

2021-11-17

6.6. Comments and Remarks

6.6. コメントと備考

None

なし

7. UDP Poisson One-Way Delay and Loss Registry Entries

7. UDPポアソン一方向遅延と損失レジストリエントリ

This section specifies five initial Registry Entries for UDP Poisson One-Way Delay and one entry for UDP Poisson One-Way Loss.

このセクションでは、UDPポアソン一方向遅延の5つの初期レジストリエントリとUDPポアソンの一方向損失の1つのエントリを指定します。

All column entries besides the ID, Name, Description, and Output Reference Method categories are the same; thus, this section defines six closely related Registry Entries. As a result, IANA has assigned corresponding URLs to each of the Named Metrics.

ID、名前、説明、および出力の参照メソッドのカテゴリ以外のすべての列エントリは同じです。したがって、このセクションは6つの密接に関連するレジストリエントリを定義します。その結果、IANAは名前付きメトリックのそれぞれに対応するURLを割り当てました。

7.1. Summary

7.1. 概要

This category includes multiple indexes to the Registry Entries: the element ID and Metric Name.

このカテゴリには、レジストリエントリへの複数のインデックスが含まれています。要素IDとメトリック名。

7.1.1. ID (Identifier)

7.1.1. ID（識別子）

IANA has allocated the numeric Identifiers 6-11 for the six Named Metric Entries in Section 7. See Section 7.1.2 for mapping to Names.

IANAはセクション7の6つの名前付きメトリックエントリについて数値識別子6-11を割り当てました。名前へのマッピングについては、セクション7.1.2を参照してください。

7.1.2. Name

7.1.2. 名前

6: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_95Percentile

6：OWDELAY_ACTIVE_IP-UDP-POISSON-PAYLOAD250B_RFC8912SEC7_SECONDS_95PERCENTILE.

7: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Mean

7：OWDELAY_ACTIVE_IP-UDP-POISSON-PAYLOAD250B_RFC8912SEC7_SECONDS_MEAN.

8: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Min

8：OWDELAY_ACTIVE_IP-UDP-POISSON-PAYLOAD250B_RFC8912SEC7_SECONDS_MIN

9: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Max

9：OWDELAY_ACTIVE_IP-UDP-POISSON-PAYLOAD250B_RFC8912SEC7_SECONDS_MAX

10: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_StdDev

10：OWDELAY_ACTIVE_IP-UDP-POISSON-PAYLOAD250B_RFC8912SEC7_SECONDS_STDDEV.

11: OWLoss_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Percent_LossRatio

11：OWLOSS_ACTIVE_IP-UDP-POISSON-PAYLOAD250B_RFC8912SEC7_PERCENT_LOSSRATIO.

7.1.3. URI

7.1.3. u u

   URL: https://www.iana.org/assignments/performance-metrics/
   OWDelay_Active_IP-UDP-Poisson-
   Payload250B_RFC8912sec7_Seconds_95Percentile

   URL: https://www.iana.org/assignments/performance-metrics/
   OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Mean

   URL: https://www.iana.org/assignments/performance-metrics/
   OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Min

   URL: https://www.iana.org/assignments/performance-metrics/
   OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Max

   URL: https://www.iana.org/assignments/performance-metrics/
   OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_StdDev

   URL: https://www.iana.org/assignments/performance-metrics/
   OWLoss_Active_IP-UDP-Poisson-
   Payload250B_RFC8912sec7_Percent_LossRatio

7.1.4. Description

7.1.4. 説明

OWDelay: This metric assesses the delay of a stream of packets exchanged between two hosts (or measurement points) and reports the <statistic> of one-way delay for all successfully exchanged packets based on their conditional delay distribution.

OWDELAY：このメトリックは、2つのホスト（または測定点）の間で交換されたパケットのストリームの遅延を評価し、条件付き遅延分布に基づいてすべての首尾よく交換されたパケットに対して一方向遅延の<統計>を報告します。

where <statistic> is one of:

<統計>は次のいずれかです。

* 95Percentile

* 95パーセンタイル

* Mean

* 平均

* Min

* min

* Max

* max

* StdDev

* Stddev.

OWLoss: This metric assesses the loss ratio of a stream of packets exchanged between two hosts (which are the two measurement points). The output is the one-way loss ratio for all transmitted packets expressed as a percentage.

OWLOSS：このメトリックは、2つのホスト間で交換されたパケットのストリームの損失率を評価します（これは2つの測定点です）。出力は、パーセンテージとして表されるすべての送信パケットの一方向損失比率です。

7.1.5. Change Controller

7.1.5. コントローラを変更する

IETF

i i

7.1.6. Version (of Registry Format)

7.1.6. バージョン（レジストリフォーマット）

1.0

7.2. Metric Definition

7.2. メートル定義

This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called "Fixed Parameters".

7.2.1. Reference Definition

7.2.1. 参照定義

For delay:

遅延の場合：

      Almes, G., Kalidindi, S., Zekauskas, M., and A.  Morton, Ed., "A
      One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81,
      RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-
      editor.org/info/rfc7679>.  [RFC7679]

      Morton, A. and E.  Stephan, "Spatial Composition of Metrics", RFC
      6049, DOI 10.17487/RFC6049, January 2011, <https://www.rfc-
      editor.org/info/rfc6049>.  [RFC6049]

Section 3.4 of [RFC7679] provides the reference definition of the singleton (single value) one-way delay metric. Section 4.4 of [RFC7679] provides the reference definition expanded to cover a multi-value sample. Note that terms such as "singleton" and "sample" are defined in Section 11 of [RFC2330].

[RFC7679]のセクション3.4は、シングルトン（単一値）一方向遅延メトリックの参照定義を提供します。[RFC7679]のセクション4.4は、多値サンプルをカバーするように参照定義を拡張します。「シングルトン」や「サンプル」などの用語は[RFC2330]の第11章で定義されています。

Only successful packet transfers with finite delay are included in the sample, as prescribed in Section 4.1.2 of [RFC6049].

[RFC6049]のセクション4.1.2で規定されているように、サンプルには有限遅延を持つ成功したパケット転送のみが含まれています。

For loss:

損失のために：

      Almes, G., Kalidindi, S., Zekauskas, M., and A.  Morton, Ed., "A
      One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82,
      RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc-
      editor.org/info/rfc7680>.  [RFC7680]

Section 2.4 of [RFC7680] provides the reference definition of the singleton (single value) one-way Loss metric. Section 3.4 of [RFC7680] provides the reference definition expanded to cover a multi-singleton sample. Note that terms such as "singleton" and "sample" are defined in Section 11 of [RFC2330].

[RFC7680]のセクション2.4は、シングルトン（単一値）一方向損失メトリックの参照定義を提供します。[RFC7680]のセクション3.4は、マルチシングルトンサンプルをカバーするように参照定義を拡張します。「シングルトン」や「サンプル」などの用語は[RFC2330]の第11章で定義されています。

7.2.2. Fixed Parameters

7.2.2. 固定パラメータ

Type-P: IPv4 header values: DSCP: Set to 0 TTL: Set to 255 Protocol: Set to 17 (UDP)

TYPE-P：IPv4ヘッダー値：DSCP：0 TTLに設定：255プロトコルに設定：17（UDP）に設定

IPv6 header values: DSCP: Set to 0 Hop Count: Set to 255 Next Header: Set to 17 (UDP) Flow Label: Set to 0 Extension Headers: None

IPv6ヘッダー値：DSCP：0ホップ数に設定：255次のヘッダーに設定：17（UDP）フローラベル：0に設定します。

UDP header values: Checksum: The checksum MUST be calculated and the non-zero checksum included in the header

UDPヘッダー値：チェックサム：チェックサムを計算し、ヘッダーに含まれていないゼロ以外のチェックサムを必要とします。

UDP Payload: TWAMP-Test packet formats (Section 4.1.2 of [RFC5357])

UDPペイロード：TWAMPテストパケットフォーマット（[RFC5357]のセクション4.1.2）

Security features in use influence the number of Padding octets

使用中のセキュリティ機能はパディングオクテットの数に影響を与えます

250 octets total, including the TWAMP format type, which MUST be reported

報告されなければならないTWAMP形式のタイプを含む250オクテットの合計

See the Packet Stream Generation section for two additional Fixed Parameters.

2つの追加の固定パラメータについては、パケットストリーム生成セクションを参照してください。

7.3. Method of Measurement

7.3. 測定方法

This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous method for implementations.

このカテゴリには、RFCの関連セクションへの参照と、実装の明確な方法を確保するために必要な補足情報が含まれています。

7.3.1. Reference Methods

7.3.1. 参照方法

The methodology for this metric (equivalent to Type-P-One-way-Delay-Poisson-Stream) is defined as in Section 3.6 of [RFC7679] (for singletons) and Section 4.6 of [RFC7679] (for samples) using the Type-P and Tmax defined in the Fixed Parameters column.

このメトリックの方法論（Type-P-One Way-Poisson-Stream）は、[RFC7679]のセクション3.6（シングルトン用）およびTypeを使用した[RFC7679]のセクション4.6の項で定義されています。固定パラメータ列に定義されている-pとtmax。

参照方法は、パケット到着の最大待ち時間を実装することによって、長遅延パケットと紛失したパケットを区別します。TMAXは、パケットが失われた宣言のしきい値として使用される待ち時間です。失われたパケットは、未定義の遅延を持つと指定され、OWLOSSメトリックについてカウントされなければならない。

参照方法は、ストリーム内の異なるパケットを区別するために何らかの方法で、送信時間と受信時間との間の対応を確立し、それぞれの到着パケットの間の受信時間との間の対応を確立する必要がある。

Since a standard measurement protocol is employed [RFC5357], the measurement process will determine the sequence numbers or timestamps applied to test packets after the Fixed and Runtime Parameters are passed to that process. The measurement protocol dictates the format of sequence numbers and timestamps conveyed in the TWAMP-Test packet payload.

標準測定プロトコルが採用されているので、測定プロセスは、固定パラメータおよび実行時パラメータがそのプロセスに渡された後に、テストパケットに適用されるシーケンス番号またはタイムスタンプを決定します。測定プロトコルは、TWAMPテストパケットペイロードで伝達されたシーケンス番号とタイムスタンプのフォーマットを決定します。

7.3.2. Packet Stream Generation

7.3.2. パケットストリームの生成

Note that Trunc is the upper limit on inter-packet times in the Poisson distribution. A random value greater than Trunc is set equal to Trunc instead.

replorcal_lambda：秒単位で表されるPoisson Streamの平均パケット間隔は、分数桁= 4と入力され、0.0001秒（0.1ミリ秒）の解像度で、そして無損失で[RFC5905]のセクション6に従って、32ビットNTPタイムスタンプへの変換。riprocal_lambda = 1秒。

7.3.3. Traffic Filtering (Observation) Details

7.3.3. トラフィックフィルタリング（観測）詳細

N/A

めずく

7.3.4. Sampling Distribution

7.3.4. 標本分布

N/A

めずく

7.3.5. Runtime Parameters and Data Format

7.3.5. ランタイムパラメータとデータフォーマット

Runtime Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete.

ランタイムパラメータは、測定システムに構成され、測定システムに構成され、完了するための結果を報告する必要ファクタです。

Src: The IP address of the host in the Src Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

Dst: The IP address of the host in the Dst Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

DST：DSTロール内のホストのIPアドレス（IPv4のIPv4-address-no-zone zone zone zone zone zone値（IPv6の場合はIPv6 - ゾーン値）。[RFC6991]のセクション4を参照）。

7.3.6. Roles

7.3.6. 役割

Src: Launches each packet and waits for return transmissions from the Dst. An example is the TWAMP Session-Sender.

SRC：各パケットを起動し、DSTからの戻りトランスミッションを待ちます。例はTWAMPセッション送信者です。

Dst: Waits for each packet from the Src and sends a return packet to the Src. An example is the TWAMP Session-Reflector.

DST：SRCから各パケットを待機し、SRCに戻りパケットを送信します。例はTWAMPセッションリフレクタです。

7.4. Output

7.4. 出力

This category specifies all details of the output of measurements using the metric.

このカテゴリは、メトリックを使用した測定値の出力の詳細を指定します。

7.4.1. Type

7.4.1. タイプ

Types are discussed in the subsections below.

以下の小節ではタイプについて説明します。

7.4.2. Reference Definition

7.4.2. 参照定義

For all output types:

すべての出力タイプの場合

For LossRatio, the count of lost packets to total packets sent is the basis for the loss ratio calculation as per Section 4.1 of [RFC7680].

LoxRatioの場合、送信された総パケットへの失われたパケットの数は、[RFC7680]のセクション4.1の損失比計算の基礎です。

For each <statistic> or Percent_LossRatio, one of the following subsections applies.

<統計>またはPercent_lossratioごとに、以下のいずれかのサブセクションが適用されます。

7.4.2.1. Percentile95

7.4.2.1. パーセンタイル95

The 95th percentile SHALL be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:

95番目のパーセンタイルは、一方向遅延の有限値（未定義の遅延は除外されます） - 単一の値であるすべてのパケットの条件付き分布を使用して計算されます。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 4.3 of [RFC3393] for details on the percentile statistic (where round-trip delay should be substituted for "ipdv").

パーセンタイル統計の詳細については、[RFC3393]のセクション4.3を参照してください（往復遅延は「IPDV」の代わりにする必要があります）。

The percentile = 95, meaning that the reported delay, "95Percentile", is the smallest value of one-way delay for which the Empirical Distribution Function, EDF(95Percentile), is greater than or equal to 95% of the singleton one-way delay values in the conditional distribution. See Section 11.3 of [RFC2330] for the definition of the percentile statistic using the EDF.

パーセンタイル= 95、報告された遅延「95Percentile」は、経験的分布関数EDF（95Percentile）がシングルトンの一方向の95％以上の一方向遅延の最小値です。条件分布の遅延値EDFを使用したパーセンタイル統計の定義については、[RFC2330]のセクション11.3を参照してください。

7.4.2.2. Mean

7.4.2.2. 平均

The mean SHALL be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:

平均は、一方向遅延の有限値（未定義の遅延が除外されています）ですべてのパケットの条件分布を使用して計算されます。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 4.2.2 of [RFC6049] for details on calculating this statistic; see also Section 4.2.3 of [RFC6049].

この統計の計算については、[RFC6049]の4.2.2項を参照してください。[RFC6049]のセクション4.2.3も参照してください。

Mean: The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per Section 6 of [RFC5905].

平均値：結果の時間値は、0.000000001秒（1.0ns）の解像度で、0.000000001秒（1.0ns）の解像度を持つDECIMAL64型の正の値として、秒単位で表されます（[RFC6020]のセクション9.3を参照）。[RFC5905]のセクション6に従って、64ビットNTPタイムスタンプへの/からの変換。

7.4.2.3. Min

7.4.2.3. min

The minimum SHALL be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:

最小値は、一方向遅延の有限値（未定義の遅延が除外されている） - 単一の値を持つすべてのパケットの条件分布を使用して計算されます。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 4.3.2 of [RFC6049] for details on calculating this statistic; see also Section 4.3.3 of [RFC6049].

この統計量の計算については、[RFC6049]の4.3.2項を参照してください。[RFC6049]のセクション4.3.3も参照してください。

Min: The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per Section 6 of [RFC5905].

MIN：結果の時間値は、0.000000001秒（1.0ns）の解像度が0.0000001秒（1.0ns）の解像度を持つDECIMAL64型の正の値として、秒単位で表されます（[RFC6020]のセクション9.3を参照）。[RFC5905]のセクション6に従って、64ビットNTPタイムスタンプへの/からの変換。

7.4.2.4. Max

7.4.2.4. max

The maximum SHALL be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:

最大値は、一方向遅延の有限値（未定義の遅延が除外されている） - 単一の値を持つすべてのパケットの条件付き分布を使用して計算されます。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 4.3.2 of [RFC6049] for a closely related method for calculating this statistic; see also Section 4.3.3 of [RFC6049]. The formula is as follows:

この統計量を計算するための密接に関連した方法については、セクション4.3.2の[RFC6049]を参照してください。[RFC6049]のセクション4.3.3も参照してください。式は次のとおりです。

      Max = (FiniteDelay[j])

      such that for some index, j, where 1 <= j <= N
      FiniteDelay[j] >= FiniteDelay[n] for all n

Max: The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per Section 6 of [RFC5905].

MAX：結果の時間値は、0.000000001秒（1.0ns）の解像度が0.000000001秒（1.0 ns）の解像度でDecimal64型の正の値として、秒単位で表されます（[RFC6020]のセクション9.3を参照）。[RFC5905]のセクション6に従って、64ビットNTPタイムスタンプへの/からの変換。

7.4.2.5. Std_Dev

7.4.2.5. std_dev.

The standard deviation (Std_Dev) SHALL be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:

標準偏差（STD_DEV）は、一方向遅延の有限値（未定義の遅延は除外されます）ですべてのパケットの条件付き分布を使用して計算されます。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 6.1.4 of [RFC6049] for a closely related method for calculating this statistic. The formula is the classic calculation for the standard deviation of a population.

この統計量を計算するための密接に関連する方法については、[RFC6049]のセクション6.1.4を参照してください。式は、人口の標準偏差のための古典的な計算です。

Define Population Std_Dev_Delay as follows:

次のように母集団STD_DEV_DELAYを定義します。

                        _                                       _
                       |            N                            |
                       |           ---                           |
                       |     1     \                          2  |
       Std_Dev = SQRT  |  -------   >   (Delay[n] - MeanDelay)   |
                       |    (N)    /                             |
                       |           ---                           |
                       |          n = 1                          |
                       |_                                       _|

where all packets n = 1 through N have a value for Delay[n], MeanDelay is calculated per Section 7.4.2.2, and SQRT[] is the Square Root function:

すべてのパケットn = 1からNが遅延[n]の値を持つ場合、セクション7.4.2.2では、SQRT []は平方根関数である。

Std_Dev: The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see Section 9.3 of [RFC6020]) with a resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per Section 6 of [RFC5905].

STD_DEV：結果の時間値は、0.000000001秒（1.0ns）の解像度でDecimal64型の正の値として、秒単位で表されます（[RFC6020]のセクション9.3）、0.0000001秒（1.0 ns）、無損失で[RFC5905]のセクション6に従って、64ビットNTPタイムスタンプへの/からの変換。

7.4.2.6. Percent_LossRatio

7.4.2.6. パーセンテージドラチオ

7.4.3. Metric Units

7.4.3. メートル法単位

The <statistic> of one-way delay is expressed in seconds, where <statistic> is one of:

一方向遅延の<統計>は秒単位で表されます。<statistic>は次のいずれかです。

* 95Percentile

* 95パーセンタイル

* Mean

* 平均

* Min

* min

* Max

* max

* StdDev

* Stddev.

The one-way loss ratio is expressed as a percentage of lost packets to total packets sent.

一方向損失比は、送信された総パケットに対する失われたパケットのパーセンテージとして表されます。

7.4.4. Calibration

7.4.4. 較正

For one-way delay measurements, the error calibration must include an assessment of the internal clock synchronization with its external reference (this internal clock is supplying timestamps for measurement). In practice, the time offsets [RFC5905] of clocks at both the Source and Destination are needed to estimate the systematic error due to imperfect clock synchronization (the time offsets [RFC5905] are smoothed; thus, the random variation is not usually represented in the results).

一方向の遅延測定のために、エラー校正には、外部リファレンスとの内部クロック同期の評価を含める必要があります（この内部クロックは測定用のタイムスタンプを供給しています）。実際には、電源と宛先の両方の時計の時計の時間オフセット[RFC5905]は、不完全なクロック同期（時間オフセット[RFC5905]が平滑化されているためです。したがって、ランダムな変動は通常は表現されません。結果）。

7.5. Administrative Items

7.5. 管理項目

7.5.1. Status

7.5.1. 状態

Current

現在

7.5.2. Requester

7.5.2. 要求者

RFC 8912

7.5.3. Revision

7.5.3. リビジョン

1.0

7.5.4. Revision Date

7.5.4. 改訂日

2021-11-17

7.6. Comments and Remarks

7.6. コメントと備考

None

なし

8. UDP Periodic One-Way Delay and Loss Registry Entries

8. UDP周期的な一方向遅延と損失レジストリエントリ

This section specifies five initial Registry Entries for UDP Periodic One-Way Delay and one entry for UDP Periodic One-Way Loss.

このセクションでは、UDP周期的な一方向遅延の5つの初期レジストリエントリとUDP周期的な一方向損失に対する1つのエントリを指定します。

ID、名前、説明、および出力の参照メソッドのカテゴリ以外のすべての列エントリは同じです。したがって、このセクションは6つの密接に関連するレジストリエントリを定義します。その結果、IANAは対応するURLを6つの名前付きメトリックのそれぞれに割り当てました。

8.1. Summary

8.1. 概要

This category includes multiple indexes to the Registry Entries: the element ID and Metric Name.

このカテゴリには、レジストリエントリへの複数のインデックスが含まれています。要素IDとメトリック名。

8.1.1. ID (Identifier)

8.1.1. ID（識別子）

IANA has allocated the numeric Identifiers 12-17 for the six Named Metric Entries in Section 8. See Section 8.1.2 for mapping to Names.

IANAは、セクション8の6つの名前付きメトリックエントリについて数値識別子12-17を割り当てました。名前へのマッピングについては、セクション8.1.2を参照してください。

8.1.2. Name

8.1.2. 名前

12: OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_95Percentile

12：OWDELAY_ACTIVE_IP-UDP-PERIORIC20M-PAYLOAD142B_RFC8912SEC8_SECONDS_95PERCENTILE.

13: OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Mean

13：OWDELAY_ACTIVE_IP-UDP-PERIORIC20M-PAYLOAD142B_RFC8912SEC8_SECONDS_MEAN

14: OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Min

14：OWDELAY_ACTIVE_IP-UDP-Periodic20M-PayLoad142B_RFC8912SEC8_SECONDS_MIN

15: OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Max

15：OWDELAY_ACTIVE_IP-UDP-Periodic20M-PayLoad142B_RFC8912SEC8_SECONDS_MAX

16: OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_StdDev

16：OWDELAY_ACTIVE_IP-UDP-PERIORIC20M-PAYLOAD142B_RFC8912SEC8_SECONDS_STDDEV.

17: OWLoss_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Percent_LossRatio

17：owloss_active_ip-udp-ediamic20m-payload142b_rfc8912sec8_percent_lossratio.

8.1.3. URI

8.1.3. u u

   URL: https://www.iana.org/assignments/performance-metrics/
   OWDelay_Active_IP-UDP-Periodic20m-
   Payload142B_RFC8912sec8_Seconds_95Percentile

   URL: https://www.iana.org/assignments/performance-metrics/
   OWDelay_Active_IP-UDP-Periodic20m-
   Payload142B_RFC8912sec8_Seconds_Mean

   URL: https://www.iana.org/assignments/performance-metrics/
   OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Min

   URL: https://www.iana.org/assignments/performance-metrics/
   OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Max

   URL: https://www.iana.org/assignments/performance-metrics/
   OWDelay_Active_IP-UDP-Periodic20m-
   Payload142B_RFC8912sec8_Seconds_StdDev

   URL: https://www.iana.org/assignments/performance-metrics/
   OWLoss_Active_IP-UDP-Periodic20m-
   Payload142B_RFC8912sec8_Percent_LossRatio

8.1.4. Description

8.1.4. 説明

where <statistic> is one of:

<統計>は次のいずれかです。

* 95Percentile

* 95パーセンタイル

* Mean

* 平均

* Min

* min

* Max

* max

* StdDev

* Stddev.

8.1.5. Change Controller

8.1.5. コントローラを変更する

IETF

i i

8.1.6. Version (of Registry Format)

8.1.6. バージョン（レジストリフォーマット）

1.0

8.2. Metric Definition

8.2. メートル定義

This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called "Fixed Parameters".

8.2.1. Reference Definition

8.2.1. 参照定義

For delay:

遅延の場合：

      Almes, G., Kalidindi, S., Zekauskas, M., and A.  Morton, Ed., "A
      One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81,
      RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-
      editor.org/info/rfc7679>.  [RFC7679]

      Morton, A. and E.  Stephan, "Spatial Composition of Metrics", RFC
      6049, DOI 10.17487/RFC6049, January 2011, <https://www.rfc-
      editor.org/info/rfc6049>.  [RFC6049]

Only successful packet transfers with finite delay are included in the sample, as prescribed in Section 4.1.2 of [RFC6049].

[RFC6049]のセクション4.1.2で規定されているように、サンプルには有限遅延を持つ成功したパケット転送のみが含まれています。

For loss:

損失のために：

      Almes, G., Kalidindi, S., Zekauskas, M., and A.  Morton, Ed., "A
      One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82,
      RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc-
      editor.org/info/rfc7680>.  [RFC7680]

8.2.2. Fixed Parameters

8.2.2. 固定パラメータ

Type-P: IPv4 header values: DSCP: Set to 0 TTL: Set to 255 Protocol: Set to 17 (UDP)

TYPE-P：IPv4ヘッダー値：DSCP：0 TTLに設定：255プロトコルに設定：17（UDP）に設定

IPv6 header values: DSCP: Set to 0 Hop Count: Set to 255 Next Header: Set to 17 (UDP) Flow Label: Set to 0 Extension Headers: None

IPv6ヘッダー値：DSCP：0ホップ数に設定：255次のヘッダーに設定：17（UDP）フローラベル：0に設定します。

UDP header values: Checksum: The checksum MUST be calculated and the non-zero checksum included in the header

UDPヘッダー値：チェックサム：チェックサムを計算し、ヘッダーに含まれていないゼロ以外のチェックサムを必要とします。

UDP Payload: TWAMP-Test packet formats (Section 4.1.2 of [RFC5357])

UDPペイロード：TWAMPテストパケットフォーマット（[RFC5357]のセクション4.1.2）

Security features in use influence the number of Padding octets

使用中のセキュリティ機能はパディングオクテットの数に影響を与えます

142 octets total, including the TWAMP format (and format type MUST be reported, if used)

TWAMP形式を含む142オクテット（および使用されている場合はフォーマットタイプを報告する必要があります）

See the Packet Stream Generation section for three additional Fixed Parameters.

3つの追加の固定パラメータについては、パケットストリーム生成セクションを参照してください。

8.3. Method of Measurement

8.3. 測定方法

This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous method for implementations.

このカテゴリには、RFCの関連セクションへの参照と、実装の明確な方法を確保するために必要な補足情報が含まれています。

8.3.1. Reference Methods

8.3.1. 参照方法

このメトリックの方法論（Type-P-One Way-Poisson-Stream）は、[RFC7679]のセクション3.6（シングルトン用）およびTypeを使用した[RFC7679]のセクション4.6の項で定義されています。固定パラメータ列に定義されている-pとtmax。ただし、[RFC3432]で定義されているように、周期的なストリームが使用されています。

8.3.2. Packet Stream Generation

8.3.2. パケットストリームの生成

Section 3 of [RFC3432] prescribes the method for generating Periodic streams using associated Parameters.

[RFC3432]のセクション3は、関連するパラメータを使用して周期的なストリームを生成するための方法を規定しています。

INCT：パケット間インターバルの名目期間、最初のビットから1番目のビットまで、値0.0200は、秒単位で表されます.4番目のDecimal64の正の値として、= 4（RFC6020のセクション9.3を参照）[RFC5905]のセクション6による32ビットNTPタイムスタンプへの可逆的な変換が0.0001秒（0.1ミリ秒）の解像度で。

dT: The duration of the interval for allowed sample start times, with value 1.0000, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a resolution of 0.0001 seconds (0.1 ms), with lossless conversion to/from the 32-bit NTP timestamp as per Section 6 of [RFC5905].

DT：許可されたサンプル開始時間の間隔の期間（秒単位単位で表す）、秒単位で表され、秒単位で表され、分数桁率が4と入力されています（[RFC6020]のセクション9.3）、および0.0001の解像度があります。[RFC5905]のセクション6に従って、32ビットNTPタイムスタンプへの可逆的な変換を伴う秒数（0.1ミリ秒）。

T0: The actual start time of the periodic stream, determined from T0 and dT.

T0：T0とDTから決定された周期的なストリームの実際の開始時刻。

These stream Parameters will be specified as Runtime Parameters.

これらのストリームパラメータはランタイムパラメータとして指定されます。

8.3.3. Traffic Filtering (Observation) Details

8.3.3. トラフィックフィルタリング（観測）詳細

N/A

めずく

8.3.4. Sampling Distribution

8.3.4. 標本分布

N/A

めずく

8.3.5. Runtime Parameters and Data Format

8.3.5. ランタイムパラメータとデータフォーマット

Runtime Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete.

ランタイムパラメータは、測定システムに構成され、測定システムに構成され、完了するための結果を報告する必要ファクタです。

Src: The IP address of the host in the Src Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

Dst: The IP address of the host in the Dst Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

DST：DSTロール内のホストのIPアドレス（IPv4のIPv4-address-no-zone zone zone zone zone zone値（IPv6の場合はIPv6 - ゾーン値）。[RFC6991]のセクション4を参照）。

8.3.6. Roles

8.3.6. 役割

Src: Launches each packet and waits for return transmissions from the Dst. An example is the TWAMP Session-Sender.

SRC：各パケットを起動し、DSTからの戻りトランスミッションを待ちます。例はTWAMPセッション送信者です。

Dst: Waits for each packet from the Src and sends a return packet to the Src. An example is the TWAMP Session-Reflector.

DST：SRCから各パケットを待機し、SRCに戻りパケットを送信します。例はTWAMPセッションリフレクタです。

8.4. Output

8.4. 出力

This category specifies all details of the output of measurements using the metric.

このカテゴリは、メトリックを使用した測定値の出力の詳細を指定します。

8.4.1. Type

8.4.1. タイプ

Latency and Loss Types are discussed in the subsections below.

待ち時間と損失の種類については、以下の小節で説明します。

8.4.2. Reference Definition

8.4.2. 参照定義

For all output types:

すべての出力タイプの場合

For LossRatio, the count of lost packets to total packets sent is the basis for the loss ratio calculation as per Section 4.1 of [RFC7680].

LoxRatioの場合、送信された総パケットへの失われたパケットの数は、[RFC7680]のセクション4.1の損失比計算の基礎です。

For each <statistic> or Percent_LossRatio, one of the following subsections applies.

<統計>またはPercent_lossratioごとに、以下のいずれかのサブセクションが適用されます。

8.4.2.1. Percentile95

8.4.2.1. パーセンタイル95

The 95th percentile SHALL be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 4.3 of [RFC3393] for details on the percentile statistic (where round-trip delay should be substituted for "ipdv").

パーセンタイル統計の詳細については、[RFC3393]のセクション4.3を参照してください（往復遅延は「IPDV」の代わりにする必要があります）。

8.4.2.2. Mean

8.4.2.2. 平均

The mean SHALL be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:

平均は、一方向遅延の有限値（未定義の遅延が除外されています）ですべてのパケットの条件分布を使用して計算されます。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 4.2.2 of [RFC6049] for details on calculating this statistic; see also Section 4.2.3 of [RFC6049].

この統計の計算については、[RFC6049]の4.2.2項を参照してください。[RFC6049]のセクション4.2.3も参照してください。

8.4.2.3. Min

8.4.2.3. min

The minimum SHALL be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:

最小値は、一方向遅延の有限値（未定義の遅延が除外されている） - 単一の値を持つすべてのパケットの条件分布を使用して計算されます。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 4.3.2 of [RFC6049] for details on calculating this statistic; see also Section 4.3.3 of [RFC6049].

この統計量の計算については、[RFC6049]の4.3.2項を参照してください。[RFC6049]のセクション4.3.3も参照してください。

8.4.2.4. Max

8.4.2.4. max

The maximum SHALL be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:

最大値は、一方向遅延の有限値（未定義の遅延が除外されている） - 単一の値を持つすべてのパケットの条件付き分布を使用して計算されます。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 4.3.2 of [RFC6049] for a closely related method for calculating this statistic; see also Section 4.3.3 of [RFC6049]. The formula is as follows:

      Max = (FiniteDelay[j])

      such that for some index, j, where 1 <= j <= N
      FiniteDelay[j] >= FiniteDelay[n] for all n

8.4.2.5. Std_Dev

8.4.2.5. std_dev.

Std_Dev SHALL be calculated using the conditional distribution of all packets with a finite value of one-way delay (undefined delays are excluded) -- a single value, as follows:

STD_DEVは、一方向遅延の有限値を持つすべてのパケットの条件付き分布を使用して計算されます（未定義の遅延は除く） - 単一の値（次のように）

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 6.1.4 of [RFC6049] for a closely related method for calculating this statistic. The formula is the classic calculation for the standard deviation of a population.

Define Population Std_Dev_Delay as follows:

次のように母集団STD_DEV_DELAYを定義します。

                        _                                       _
                       |            N                            |
                       |           ---                           |
                       |     1     \                          2  |
       Std_Dev = SQRT  |  -------   >   (Delay[n] - MeanDelay)   |
                       |    (N)    /                             |
                       |           ---                           |
                       |          n = 1                          |
                       |_                                       _|

where all packets n = 1 through N have a value for Delay[n], MeanDelay is calculated per Section 8.4.2.2, and SQRT[] is the Square Root function:

すべてのパケットn = 1からnの値は遅延[n]の値を持つ場合、セクション8.4.2.2は8.4.2.2で計算され、SQRT []は平方根関数です。

8.4.2.6. Percent_LossRatio

8.4.2.6. パーセンテージドラチオ

percent_lossratio：結果の数値は、損失したパケットの単位で、分数桁率を持つDecimal64の型の正の値として表されます（[RFC6020]のセクション9.0.0000000001のセクション9.3を参照）。

8.4.3. Metric Units

8.4.3. メートル法単位

The <statistic> of one-way delay is expressed in seconds, where <statistic> is one of:

一方向遅延の<統計>は秒単位で表されます。<statistic>は次のいずれかです。

* 95Percentile

* 95パーセンタイル

* Mean

* 平均

* Min

* min

* Max

* max

* StdDev

* Stddev.

The one-way loss ratio is expressed as a percentage of lost packets to total packets sent.

一方向損失比は、送信された総パケットに対する失われたパケットのパーセンテージとして表されます。

8.4.4. Calibration

8.4.4. 較正

For one-way delay measurements, the error calibration must include an assessment of the internal clock synchronization with its external reference (this internal clock is supplying timestamps for measurement). In practice, the time offsets [RFC5905] of clocks at both the Source and Destination are needed to estimate the systematic error due to imperfect clock synchronization (the time offsets [RFC5905] are smoothed; thus, the random variation is not usually represented in the results).

8.5. Administrative Items

8.5. 管理項目

8.5.1. Status

8.5.1. 状態

Current

現在

8.5.2. Requester

8.5.2. 要求者

RFC 8912

8.5.3. Revision

8.5.3. リビジョン

1.0

8.5.4. Revision Date

8.5.4. 改訂日

2021-11-17

8.6. Comments and Remarks

8.6. コメントと備考

None

なし

9. ICMP Round-Trip Latency and Loss Registry Entries

9. ICMPラウンドトリップレイテンシとロスレジストリエントリ

This section specifies three initial Registry Entries for ICMP Round-Trip Latency and another entry for the ICMP Round-Trip Loss Ratio.

このセクションでは、ICMPラウンドトリップレイテンシとICMPラウンドトリップ損失率の別のエントリの3つの初期レジストリエントリを指定します。

All column entries besides the ID, Name, Description, and Output Reference Method categories are the same; thus, this section defines four closely related Registry Entries. As a result, IANA has assigned corresponding URLs to each of the four Named Metrics.

ID、名前、説明、および出力の参照メソッドのカテゴリ以外のすべての列エントリは同じです。したがって、このセクションでは4つの厳密なレジストリエントリを定義します。その結果、IANAは4つの名前付きメトリックのそれぞれに対応するURLを割り当てました。

9.1. Summary

9.1. 概要

This category includes multiple indexes to the Registry Entries: the element ID and Metric Name.

このカテゴリには、レジストリエントリへの複数のインデックスが含まれています。要素IDとメトリック名。

9.1.1. ID (Identifier)

9.1.1. ID（識別子）

IANA has allocated the numeric Identifiers 18-21 for the four Named Metric Entries in Section 9. See Section 9.1.2 for mapping to Names.

IANAは、セクション9の4つの名前付きメトリックエントリについて数値識別子18-21を割り当てました。名前へのマッピングについては、セクション9.1.2を参照してください。

9.1.2. Name

9.1.2. 名前

18: RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Mean

18：RTDELAY_ACTIVE_IP-ICMP-SENDONRCV_RFC8912SEC9_SECONDSS_MEAN.

19: RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Min

19：RTDELAY_ACTIVE_IP-ICMP-SENDONRCV_RFC8912SEC9_SECONDSS_MIN

20: RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Max

20：RTDELAY_ACTIVE_IP-ICMP-SENDONRCV_RFC8912SEC9_SECONDS_MAX

21: RTLoss_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Percent_LossRatio

21：rtloss_active_ip-icmp-sendonrcv_rfc8912sec9_percent_lossratio.

9.1.3. URI

9.1.3. u u

   URL: https://www.iana.org/assignments/performance-metrics/
   RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Mean

   URL: https://www.iana.org/assignments/performance-metrics/
   RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Min

   URL: https://www.iana.org/assignments/performance-metrics/
   RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Max

   URL: https://www.iana.org/assignments/performance-metrics/
   RTLoss_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Percent_LossRatio

9.1.4. Description

9.1.4. 説明

RTDelay: This metric assesses the delay of a stream of ICMP packets exchanged between two hosts (which are the two measurement points). The output is the round-trip delay for all successfully exchanged packets expressed as the <statistic> of their conditional delay distribution, where <statistic> is one of:

RTDelay：このメトリックは、2つのホスト間で交換されたICMPパケットのストリームの遅延を評価します（これは2つの測定点です）。出力は、それらの条件付き遅延分布の<statistic>として表されるすべての首尾よく交換されたパケットの往復遅延です。ここで、<statistic>は次のいずれかです。

* Mean

* 平均

* Min

* min

* Max

* max

RTLoss: This metric assesses the loss ratio of a stream of ICMP packets exchanged between two hosts (which are the two measurement points). The output is the round-trip loss ratio for all transmitted packets expressed as a percentage.

rtloss：このメトリックは、2つのホスト間で交換されたICMPパケットのストリームの損失率（2つの測定点です）を評価します。出力は、パーセンテージとして表されるすべての送信パケットの往復損失率です。

9.1.5. Change Controller

9.1.5. コントローラを変更する

IETF

i i

9.1.6. Version (of Registry Format)

9.1.6. バージョン（レジストリフォーマット）

1.0

9.2. Metric Definition

9.2. メートル定義

This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called "Fixed Parameters".

9.2.1. Reference Definition

9.2.1. 参照定義

For delay:

遅延の場合：

      Almes, G., Kalidindi, S., and M.  Zekauskas, "A Round-trip Delay
      Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999,
      <https://www.rfc-editor.org/info/rfc2681>.  [RFC2681]

For loss:

損失のために：

      Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI
      10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/
      rfc6673>.  [RFC6673]

9.2.2. Fixed Parameters

9.2.2. 固定パラメータ

Type-P as defined in Section 13 of [RFC2330]: IPv4 header values: DSCP: Set to 0 TTL: Set to 255 Protocol: Set to 01 (ICMP)

TYPE-P [RFC2330]：IPv4ヘッダー値：DSCP：0 TTLに設定：255プロトコルに設定：01に設定（ICMP）

IPv6 header values: DSCP: Set to 0 Hop Count: Set to 255 Next Header: Set to 128 decimal (ICMP) Flow Label: Set to 0 Extension Headers: None

IPv6ヘッダー値：DSCP：0ホップ数に設定：255次のヘッダーに設定：128 decimal（ICMP）フローラベル：0に設定します。

ICMP header values: Type: 8 (Echo Request) Code: 0 Checksum: The checksum MUST be calculated and the non-zero checksum included in the header (Identifier and sequence number set at runtime)

ICMPヘッダーの値：タイプ：8（エコー要求）コード：0チェックサム：チェックサムを計算し、ヘッダーに含まれていないゼロ以外のチェックサム（実行時に設定されている識別子とシーケンス番号）

ICMP Payload: Total of 32 bytes of random information, constant per test

ICMPペイロード：テストごとに一定のランダム情報の合計32バイト

9.3. Method of Measurement

9.3. 測定方法

This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous method for implementations.

このカテゴリには、RFCの関連セクションへの参照と、実装の明確な方法を確保するために必要な補足情報が含まれています。

9.3.1. Reference Methods

9.3.1. 参照方法

このメトリックの方法論（Type-P-round-rave-delay-poisson-stream）は、[RFC2681]のセクション2.6（シングルトン用）およびTypeを使用した[RFC2681]のセクション3.6の項で定義されています。固定パラメータ列に定義されている-pとtmax。

参照方法は、パケット到着の最大待ち時間を実装することによって、長遅延パケットと紛失したパケットを区別します。TMAXは、パケットが失われた宣言のしきい値として使用される待ち時間です。紛失したパケットは、未定義の遅延を持つと指定され、RTLOSの測定基準のために数えられなければならない。

The calculations on the delay (RTD) SHALL be performed on the conditional distribution, conditioned on successful packet arrival within Tmax. Also, when all packet delays are stored, the process that calculates the RTD value MUST enforce the Tmax threshold on stored values before calculations. See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

遅延（RTD）の計算は、TMAX内の成功したパケット到着に成功した状態で調整された条件付き分布に対して実行されなければならない。また、すべてのパケット遅延が格納されている場合、RTD値を計算するプロセスは、計算前に格納値のTMAXしきい値を強制する必要があります。不定値の遅延値を除外するための条件付き配布の詳細については、[RFC3393]のセクション4.1を参照してください。この分析選択の背景については、[RFC6703]のセクション5を参照してください。

The measurement process will determine the sequence numbers applied to test packets after the Fixed and Runtime Parameters are passed to that process. The ICMP measurement process and protocol will dictate the format of sequence numbers and other Identifiers.

測定プロセスは、固定パラメータおよび実行時パラメータがそのプロセスに渡された後にテストパケットに適用されるシーケンス番号を決定します。ICMP測定プロセスとプロトコルは、シーケンス番号および他の識別子のフォーマットを決定します。

9.3.2. Packet Stream Generation

9.3.2. パケットストリームの生成

The ICMP metrics use a sending discipline called "SendOnRcv" or Send On Receive. This is a modification of Section 3 of [RFC3432], which prescribes the method for generating Periodic streams using associated Parameters as defined below for this description:

ICMPメトリックは、 "SendOnRCV"という送信のDCIPLINEを使用するか、受信を送信します。これは[RFC3432]のセクション3の修正で、この説明については以下のような関連パラメータを使用して周期的なストリームを生成する方法を規定しています。

incT: The nominal duration of the inter-packet interval, first bit to first bit.

INCT：パケット間間隔の公称期間、最初のビットから1ビット

dT: The duration of the interval for allowed sample start times.

DT：許可されたサンプル開始時間の間隔の持続時間。

The incT stream Parameter will be specified as a Runtime Parameter, and dT is not used in SendOnRcv.

INCT STREAMパラメータはランタイムパラメータとして指定され、DTはSendOnRCVでは使用されません。

A SendOnRcv sender behaves exactly like a Periodic stream generator while all reply packets arrive with RTD < incT, and the inter-packet interval will be constant.

SendOnRCV送信者は、すべての返信パケットがRTD <INCTで到着し、パケット間間隔が一定になる間、周期的なストリームジェネレータとまったく動作します。

If a reply packet arrives with RTD >= incT, then the inter-packet interval for the next sending time is nominally RTD.

返信パケットがRTD> = INCTで到着すると、次の送信時間のパケット間間隔は名目上RTDです。

If a reply packet fails to arrive within Tmax, then the inter-packet interval for the next sending time is nominally Tmax.

返信パケットがTmax内に到着しない場合、次の送信時間のパケット間間隔は名目上Tmaxです。

If an immediate Send On Reply arrival is desired, then set incT = 0.

返信到着時の即時の送信が望まれる場合は、inct = 0に設定してください。

9.3.3. Traffic Filtering (Observation) Details

9.3.3. トラフィックフィルタリング（観測）詳細

N/A

めずく

9.3.4. Sampling Distribution

9.3.4. 標本分布

N/A

めずく

9.3.5. Runtime Parameters and Data Format

9.3.5. ランタイムパラメータとデータフォーマット

Runtime Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete.

ランタイムパラメータは、測定システムに構成され、測定システムに構成され、完了するための結果を報告する必要ファクタです。

Src: The IP address of the host in the Src Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

Dst: The IP address of the host in the Dst Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

DST：DSTロール内のホストのIPアドレス（IPv4のIPv4-address-no-zone zone zone zone zone zone値（IPv6の場合はIPv6 - ゾーン値）。[RFC6991]のセクション4を参照）。

incT: The nominal duration of the inter-packet interval, first bit to first bit, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see Section 9.3 of [RFC6020]) and with a resolution of 0.0001 seconds (0.1 ms).

INCT：パケット間間隔の公称期間、秒単位で表される最初のビットから、秒単位で表され、分数桁数= 4のDECIMAL64の正の値として（[RFC6020]のセクション9.3）および解像度があります。0.0001秒（0.1ミリ秒）。

Count: The total count of ICMP Echo Requests to send, formatted as a uint16, as per Section 9.2 of [RFC6020].

Count：[RFC6020]のセクション9.2のセクション9.2に従って、ICMPエコーの総数を送信する、UINT16としてフォーマットされた要求の合計数。

See the Packet Stream Generation section for additional Runtime Parameters.

追加の実行時パラメータについては、パケットストリーム生成セクションを参照してください。

9.3.6. Roles

9.3.6. 役割

Src: Launches each packet and waits for return transmissions from the Dst.

SRC：各パケットを起動し、DSTからの戻りトランスミッションを待ちます。

Dst: Waits for each packet from the Src and sends a return packet to the Src (ICMP Echo Reply, Type 0).

DST：SRCからの各パケットを待機し、SRC（ICMPエコー応答、タイプ0）に戻りパケットを送信します。

9.4. Output

9.4. 出力

This category specifies all details of the output of measurements using the metric.

このカテゴリは、メトリックを使用した測定値の出力の詳細を指定します。

9.4.1. Type

9.4.1. タイプ

Latency and Loss Types are discussed in the subsections below.

待ち時間と損失の種類については、以下の小節で説明します。

9.4.2. Reference Definition

9.4.2. 参照定義

For all output types:

すべての出力タイプの場合

TotalCount: The count of packets actually sent by the Src to the Dst during the measurement interval.

TotalCount：測定間隔中にSRCによって実際にSRCによって送信されたパケットの数。

For each <statistic> or Percent_LossRatio, one of the following subsections applies.

<統計>またはPercent_lossratioごとに、以下のいずれかのサブセクションが適用されます。

9.4.2.1. Mean

9.4.2.1. 平均

The mean SHALL be calculated using the conditional distribution of all packets with a finite value of round-trip delay (undefined delays are excluded) -- a single value, as follows:

平均は、往復遅延の有限値を持つすべてのパケットの条件分布を使用して計算されます（未定義の遅延は除く） - 単一の値です。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 4.2.2 of [RFC6049] for details on calculating this statistic; see also Section 4.2.3 of [RFC6049].

この統計の計算については、[RFC6049]の4.2.2項を参照してください。[RFC6049]のセクション4.2.3も参照してください。

9.4.2.2. Min

9.4.2.2. min

The minimum SHALL be calculated using the conditional distribution of all packets with a finite value of round-trip delay (undefined delays are excluded) -- a single value, as follows:

最小値は、往復遅延の有限値を持つすべてのパケットの条件分布を使用して計算されます（未定義の遅延は除く） - 単一の値です。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 4.3.2 of [RFC6049] for details on calculating this statistic; see also Section 4.3.3 of [RFC6049].

この統計量の計算については、[RFC6049]の4.3.2項を参照してください。[RFC6049]のセクション4.3.3も参照してください。

9.4.2.3. Max

9.4.2.3. max

The maximum SHALL be calculated using the conditional distribution of all packets with a finite value of round-trip delay (undefined delays are excluded) -- a single value, as follows:

最大値は、往復遅延の有限値を持つすべてのパケットの条件付き分布を使用して計算されます（未定義の遅延は除く） - 次のように単一の値です。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 4.3.2 of [RFC6049] for a closely related method for calculating this statistic; see also Section 4.3.3 of [RFC6049]. The formula is as follows:

      Max = (FiniteDelay[j])

      such that for some index, j, where 1 <= j <= N
      FiniteDelay[j] >= FiniteDelay[n] for all n

9.4.2.4. Percent_LossRatio

9.4.2.4. パーセンテージドラチオ

For LossRatio, the count of lost packets to total packets sent is the basis for the loss ratio calculation as per Section 4.1 of [RFC7680].

LoxRatioの場合、送信された総パケットへの失われたパケットの数は、[RFC7680]のセクション4.1の損失比計算の基礎です。

9.4.3. Metric Units

9.4.3. メートル法単位

The <statistic> of round-trip delay is expressed in seconds, where <statistic> is one of:

往復遅延の<統計>は秒単位で表されます。ここで、<statistic>は次のいずれかです。

* Mean

* 平均

* Min

* min

* Max

* max

The round-trip loss ratio is expressed as a percentage of lost packets to total packets sent.

往復損失率は、送信された総パケットに対する紛失したパケットの割合として表されます。

9.4.4. Calibration

9.4.4. 較正

9.5. Administrative Items

9.5. 管理項目

9.5.1. Status

9.5.1. 状態

Current

現在

9.5.2. Requester

9.5.2. 要求者

RFC 8912

9.5.3. Revision

9.5.3. リビジョン

1.0

9.5.4. Revision Date

9.5.4. 改訂日

2021-11-17

9.6. Comments and Remarks

9.6. コメントと備考

None

なし

10. TCP Round-Trip Delay and Loss Registry Entries

10. TCPラウンドトリップ遅延と損失レジストリエントリ

This section specifies four initial Registry Entries for the Passive assessment of TCP Round-Trip Delay (RTD) and another entry for the TCP Round-Trip Loss Count.

このセクションでは、TCPラウンドトリップディレイ（RTD）とTCPラウンドトリップロス数の別のエントリのパッシブアセスメントの4つの初期レジストリエントリを指定します。

10.1. Summary

10.1. 概要

This category includes multiple indexes to the Registry Entries: the element ID and Metric Name.

このカテゴリには、レジストリエントリへの複数のインデックスが含まれています。要素IDとメトリック名。

10.1.1. ID (Identifier)

10.1.1. ID（識別子）

IANA has allocated the numeric Identifiers 22-26 for the five Named Metric Entries in Section 10. See Section 10.1.2 for mapping to Names.

IANAは、セクション10の5つの名前付きメトリックエントリについて数値識別子22-26を割り当てました。名前へのマッピングについては、セクション10.1.2を参照してください。

10.1.2. Name

10.1.2. 名前

22: RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Mean

22：rtdelay_passive_ip-tcp_rfc8912sec10_seconds_mean.

23: RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Min

23：rtdelay_passive_ip-tcp_rfc8912sec10_seconds_min.

24: RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Max

24：RTDELAY_PASSIVE_IP-TCP_RFC8912SEC10_SECONDS_MAX

25: RTDelay_Passive_IP-TCP-HS_RFC8912sec10_Seconds_Singleton

25：RTDELAY_PASSIVE_IP-TCP-HS_RFC8912SEC10_SECONDS_SINGLETON.

Note that a midpoint observer only has the opportunity to compose a single RTDelay on the TCP handshake.

MIDPOINTオブザーバは、TCPハンドシェイクの単一のRTDELAYを構成する機会だけを持っていることに注意してください。

26: RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count

26：rtloss_passive_ip-tcp_rfc8912sec10_packet_count.

10.1.3. URI

10.1.3. u u

   URL: https://www.iana.org/assignments/performance-metrics/
   RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Mean

   URL: https://www.iana.org/assignments/performance-metrics/
   RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Min

   URL: https://www.iana.org/assignments/performance-metrics/
   RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Max

   URL: https://www.iana.org/assignments/performance-metrics/
   RTDelay_Passive_IP-TCP-HS_RFC8912sec10_Seconds_Singleton

   URL: https://www.iana.org/assignments/performance-metrics/
   RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count

10.1.4. Description

10.1.4. 説明

RTDelay: This metric assesses the round-trip delay of TCP packets constituting a single connection, exchanged between two hosts. We consider the measurement of round-trip delay based on a single Observation Point (OP) [RFC7011] somewhere in the network. The output is the round-trip delay for all successfully exchanged packets expressed as the <statistic> of their conditional delay distribution, where <statistic> is one of:

RTDELAY：このメトリックは、2つのホスト間で交換された単一の接続を構成するTCPパケットの往復遅延を評価します。ネットワーク内のどこかにある単一の観測点（rop）[RFC7011]に基づく往復遅延の測定を検討します。出力は、それらの条件付き遅延分布の<statistic>として表されるすべての首尾よく交換されたパケットの往復遅延です。ここで、<statistic>は次のいずれかです。

* Mean

* 平均

* Min

* min

* Max

* max

RTDelay Singleton: This metric assesses the round-trip delay of TCP packets initiating a single connection (or 3-way handshake), exchanged between two hosts. We consider the measurement of round-trip delay based on a single Observation Point (OP) [RFC7011] somewhere in the network. The output is the single measurement of Round-trip delay, or Singleton.

RTDelay Singleton：このメトリックは、2つのホスト間で交換された単一の接続（または3方向ハンドシェイク）を開始するTCPパケットの往復遅延を評価します。ネットワーク内のどこかにある単一の観測点（rop）[RFC7011]に基づく往復遅延の測定を検討します。出力は往復遅延、またはシングルトンの単一の測定です。

RTLoss: This metric assesses the estimated loss count for TCP packets constituting a single connection, exchanged between two hosts. We consider the measurement of round-trip delay based on a single OP [RFC7011] somewhere in the network. The output is the estimated loss count for the measurement interval.

rtloss：このメトリックは、2つのホスト間で交換された単一の接続を構成するTCPパケットの推定損失数を評価します。ネットワーク内のどこかにある単一のOP [RFC7011]に基づく往復遅延の測定を検討します。出力は測定間隔の推定損失数です。

10.1.5. Change Controller

10.1.5. コントローラを変更する

IETF

i i

10.1.6. Version (of Registry Format)

10.1.6. バージョン（レジストリフォーマット）

1.0

10.2. Metric Definition

10.2. メートル定義

This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called "Fixed Parameters".

10.2.1. Reference Definition

10.2.1. 参照定義

   Almes, G., Kalidindi, S., and M.  Zekauskas, "A Round-trip Delay
   Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999,
   <https://www.rfc-editor.org/info/rfc2681>.  [RFC2681]

Although there is no RFC that describes Passive Measurement of round-trip delay, the parallel definition for Active Measurement is provided in [RFC2681].

往復遅延の受動的測定を説明するRFCはありませんが、[RFC2681]にアクティブ測定のための並列定義が提供されています。

This metric definition uses the term "wire time" as defined in Section 10.2 of [RFC2330], and the terms "singleton" and "sample" as defined in Section 11 of [RFC2330]. (Section 2.4 of [RFC2681] provides the reference definition of the singleton (single value) round-trip delay metric. Section 3.4 of [RFC2681] provides the reference definition expanded to cover a multi-singleton sample.)

このメトリック定義は、[RFC2330]のセクション10.2で定義されている「Wire Time」と「RFC2330」のセクション11で定義されている「Singleton」と「サンプル」という用語を使用しています。（[RFC2681]のセクション2.4は、シングルトンの参照定義（単一値）往復遅延メトリックを提供します。[RFC2681]のセクション3.4は、マルチシングルトンサンプルをカバーするように参照定義を拡張します。）

With the OP [RFC7011] typically located between the hosts participating in the TCP connection, the round-trip delay metric requires two individual measurements between the OP and each host, such that the Spatial Composition [RFC6049] of the measurements yields a round-trip delay singleton (we are extending the composition of one-way subpath delays to subpath round-trip delay).

rop [RFC7011]が通常TCP接続に参加しているホスト間に位置すると、往復遅延メトリックは、測定の空間的構成[RFC6049]が往復であるように、OPと各ホストとの間の2つの個々の測定を必要とします。遅延シングルトン（我々は片道サブパス遅延の構成をサブパス往復遅延に拡張しています）。

Using the direction of TCP SYN transmission to anchor the nomenclature, host A sends the SYN, and host B replies with SYN-ACK during connection establishment. The direction of SYN transfer is considered the Forward direction of transmission, from A through the OP to B (the Reverse direction is B through the OP to A).

TCP SYN送信の方向を使用して、命名法をアンカーする、ホストAはSYNを送信し、接続確立中にホストBはSYN-ACKに応答します。SYN転送の方向は、AからOPへの順方向の送信方向と見なされる（逆方向は、aはaからaまでbである）。

Traffic Filters reduce the packet streams at the OP to a Qualified bidirectional flow of packets.

トラフィックフィルタは、OPでパケットストリームをパケットの適格な双方向フローに削減します。

In the definitions below, Corresponding Packets are transferred in different directions and convey a common value in a TCP header field that establishes correspondence (to the extent possible). Examples may be found in the TCP timestamp fields.

以下の定義では、対応するパケットは異なる方向に転送され、対応関係を確立するTCPヘッダフィールドにおいて共通の値を伝達する（可能な限り）。例はTCPタイムスタンプフィールドにあります。

For a real number, RTD_fwd, >> the round-trip delay in the Forward direction from the OP to host B at time T' is RTD_fwd << it is REQUIRED that the OP observed a Qualified Packet to host B at wire time T', that host B received that packet and sent a Corresponding Packet back to host A, and the OP observed the Corresponding Packet at wire time T' + RTD_fwd.

実数RTD_FWDの場合は、時刻t 'でのOPからホストBへの往復遅延がRTD_FWD << OPが有式なパケットをワイヤタイムT'でホストBに観測されたことが必要です。そのホストBはそのパケットを受信し、対応するパケットをホストAに戻し、OPはワイヤ時間T 'RTD_FWDで対応するパケットを観察した。

For a real number, RTD_rev, >> the round-trip delay in the Reverse direction from the OP to host A at time T'' is RTD_rev << it is REQUIRED that the OP observed a Qualified Packet to host A at wire time T'', that host A received that packet and sent a Corresponding Packet back to host B, and that the OP observed the Corresponding Packet at wire time T'' + RTD_rev.

実数RTD_REV、>>時刻t ''からホストAへの逆方向の往復遅延はRTD_REV << OPが有効なパケットを有効にして、ワイヤタイムTでホストすることが必要です。「そのパケットを受信し、対応するパケットをホストBに戻し、オペがワイヤ時間T '' RTD_REVで対応するパケットを観察した。

Ideally, the packet sent from host B to host A in both definitions above SHOULD be the same packet (or, when measuring RTD_rev first, the packet from host A to host B in both definitions should be the same).

理想的には、上記の両方の定義でホストBからホストAに送信されたパケットは同じパケットであるべきである（または、最初にRTD_REVを測定するときに、ホストAからホストBへの両方の定義のパケットは同じ）。

The REQUIRED Composition Function for a singleton of round-trip delay at time T (where T is the earliest of T' and T'' above) is:

時間tにおける往復遅延のシングルトンのための要求された構成関数（ここで、tは、上記のt '' '' '' '' '' '' '' '

RTDelay = RTD_fwd + RTD_rev

RTDelay = RTD_FWD RTD_REV.

Note that when the OP is located at host A or host B, one of the terms composing RTDelay will be zero or negligible.

OPがホストAまたはホストBにあるとき、RTDELAYを構成する用語の1つはゼロまたは無視できることに注意してください。

Using the abbreviation HS to refer to the TCP handshake: when the Qualified and Corresponding Packets are a TCP-SYN and a TCP-SYN-ACK, RTD_fwd == RTD_HS_fwd.

略語HSを使用してTCPハンドシェイクを参照してください。修飾および対応するパケットがTCP-SYNとTCP-SYN-ACK、RTD_FWD == RTD_HS_FWDです。

When the Qualified and Corresponding Packets are a TCP-SYN-ACK and a TCP-ACK, RTD_rev == RTD_HS_rev.

修飾パケットと対応するパケットがTCP-SYN-ACKとTCP-ACK、RTD_REV == RTD_HS_REVです。

The REQUIRED Composition Function for a singleton of round-trip delay for the connection handshake is:

接続ハンドシェイクの往復遅延のシングルトンのための必要な構成関数は次のとおりです。

RTDelay_HS = RTD_HS_fwd + RTD_HS_rev

RTDELAY_HS = RTD_HS_FWD RTD_HS_REV.

The definition of round-trip loss count uses the nomenclature developed above, based on observation of the TCP header sequence numbers and storing the sequence number gaps observed. Packet losses can be inferred from:

往復損失数の定義は、TCPヘッダシーケンス番号の観測と観察されたシーケンス番号のギャップを記憶することに基づいて、上記で開発された命名法を使用しています。パケット損失は次のものから推測できます。

Out-of-order segments: TCP segments are transmitted with monotonically increasing sequence numbers, but these segments may be received out of order. Section 3 of [RFC4737] describes the notion of "next expected" sequence numbers, which can be adapted to TCP segments (for the purpose of detecting reordered packets). Observation of out-of-order segments indicates loss on the path prior to the OP and creates a gap.

順序外のセグメント：TCPセグメントは単調に増加するシーケンス番号で送信されますが、これらのセグメントは順序から受信されます。[RFC4737]のセクション3は、「次の予想される」シーケンス番号の概念を示しており、これはTCPセグメントに適合させることができます（並べ替えパケットを検出する目的で）。順序外セグメントの観測は、OPの前の経路の損失を示し、ギャップを作成します。

Duplicate segments: Section 2 of [RFC5560] defines identical packets and is suitable for evaluation of TCP packets to detect duplication. Observation of a segment duplicates a segment previously observed (and thus no corresponding observed segment gap) indicates loss on the path following the OP (e.g., the segment overlaps part of the octet stream already observed at the OP).

重複セグメント：[RFC5560]のセクション2は同一のパケットを定義し、重複を検出するためのTCPパケットの評価に適しています。セグメントの観察は、以前に観察されたセグメントを複製する（したがって、対応する観察されたセグメントギャップはない）経路上の損失を示す（例えば、セグメントは、既にOPで観察されたオクテットストリームの一部と重なっている）。

Each observation of an out-of-order or duplicate segment infers a singleton of loss, but the composition of round-trip loss counts will be conducted over a measurement interval that is synonymous with a single TCP connection.

順序外または重複するセグメントの各観測値は損失のシングルトンを扱いますが、往復損失数の構成は単一のTCP接続と同義である測定間隔にわたって行われます。

With the above observations in the Forward direction over a measurement interval, the count of out-of-order and duplicate segments is defined as RTL_fwd. Comparable observations in the Reverse direction are defined as RTL_rev.

上記の観測値は測定間隔にわたって順方向に順方向に、順序外および重複セグメントのカウントをRTL_FWDと定義します。逆方向の同等の観測値はRTL_REVとして定義されています。

For a measurement interval (corresponding to a single TCP connection) T0 to Tf, the REQUIRED Composition Function for the two single-direction counts of inferred loss is:

測定間隔（単一のTCP接続に対応）T0~TFの場合、推定損失の2つの方向カウントのための必要な構成関数は次のとおりです。

RTLoss = RTL_fwd + RTL_rev

RTLOSS = RTL_FWD RTL_REV.

10.2.2. Fixed Parameters

10.2.2. 固定パラメータ

Traffic Filters: IPv4 header values: DSCP: Set to 0 Protocol: Set to 06 (TCP)

トラフィックフィルタ：IPv4ヘッダー値：DSCP：0プロトコルに設定：06（TCP）に設定

IPv6 header values: DSCP: Set to 0 Hop Count: Set to 255 Next Header: Set to 6 (TCP) Flow Label: Set to 0 Extension Headers: None

IPv6ヘッダー値：DSCP：0ホップ数に設定：255次のヘッダー：6（TCP）フローラベル：0に設定します。

TCP header values: Flags: ACK, SYN, FIN, set as required Timestamps Option (TSopt): Set. See Section 3.2 of [RFC7323]

TCPヘッダー値：フラグ：ACK、SYN、FIN、必要なタイムスタンプオプション（TSOPT）：設定。[RFC7323]のセクション3.2を参照してください。

10.3. Method of Measurement

10.3. 測定方法

This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous method for implementations.

このカテゴリには、RFCの関連セクションへの参照と、実装の明確な方法を確保するために必要な補足情報が含まれています。

10.3.1. Reference Methods

10.3.1. 参照方法

The foundational methodology for this metric is defined in Section 4 of [RFC7323] using the Timestamps option with modifications that allow application at a mid-path OP [RFC7011]. Further details and applicable heuristics were derived from [Strowes] and [Trammell-14].

このメトリックの基本的な方法論は、mid-path op [RFC7011]でアプリケーションを許可する変更を使用して、TIMESTAMPSオプションを使用して[RFC7323]のセクション4で定義されています。さらなる詳細と適用可能なヒューリスティックは[紙幣]と[Trammell-14]から派生しました。

The Traffic Filter at the OP is configured to observe a single TCP connection. When the SYN/SYN-ACK/ACK handshake occurs, it offers the first opportunity to measure both RTD_fwd (on the SYN to SYN-ACK pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this singleton of RTDelay as RTDelay_HS (composed using the Forward and Reverse measurement pair). RTDelay_HS SHALL be treated separately from other RTDelays on data-bearing packets and their ACKs. The RTDelay_HS value MAY be used as a consistency check on the composed values of RTDelay for payload-bearing packets.

OPのトラフィックフィルタは、単一のTCP接続を観察するように構成されています。SYN / SYN-ACK / ACKハンドシェイクが発生すると、RTD_FWD（SYN-ACKペア）とRTD_REVの両方を測定する最初の機会があります（SYN-ACKのACKペア）。RTDelayのこのシングルトンをRTDelay_HSとしてラベルを付けます（前方と逆測定ペアを使用して構成されています）。RTDELAY_HSは、データベースパケットとそのACKの他のRTDERAYとは別に処理されます。RTDELAY_HS値は、ペイロードベアリングパケットのRTDELAYの構成値に関する一貫性チェックとして使用できます。

For payload-bearing packets, the OP measures the time interval between observation of a packet with sequence number "s" and the corresponding ACK with the same sequence number. When the payload is transferred from host A to host B, the observed interval is RTD_fwd.

ペイロードベアリングパケットの場合、OPは、シーケンス番号「S」のパケットの観測と対応するACKとの間の時間間隔を同じシーケンス番号と測定する。ペイロードがホストAからホストBに転送されると、観測された間隔はRTD_FWDです。

For payload-bearing packets, each observation of an out-of-order or duplicate segment infers a loss count, but the composition of round-trip loss counts will be conducted over a measurement interval that is synonymous with a single TCP connection.

ペイロードベアリングパケットの場合、各順序または重複セグメントの各観測値は損失数を短縮しますが、往復損失回数の構成は単一のTCP接続と同義である測定間隔にわたって行われます。

Because many data transfers are unidirectional (say, in the Forward direction from host A to host B), it is necessary to use pure ACK packets with Timestamp (TSval) and packets with the Timestamp value echo to perform a RTD_rev measurement. The time interval between observation of the ACK from B to A, and the Corresponding Packet with a Timestamp Echo Reply (TSecr) field [RFC7323], is the RTD_rev.

多くのデータ転送は単方向（例えばホストAからホストBへの順方向に）であるため、TimesTamp値エコーを備えたタイムスタンプ（TSVAL）とパケットを使用して純粋なACKパケットを使用してRTD_REV測定を実行する必要があります。BからAへのACKの観測の間隔、およびタイムスタンプエコー応答（TSECR）フィールド[RFC7323]の対応するパケットは、RTD_REVです。

Delay Measurement Filtering Heuristics:

遅延測定フィルタリングヒューリスティック：

* If data payloads were transferred in both Forward and Reverse directions, then the Round-Trip Time Measurement rule in Section 4.1 of [RFC7323] could be applied. This rule essentially excludes any measurement using a packet unless it makes progress in the transfer (advances the left edge of the send window, consistent with [Strowes]).

* データペイロードが順方向と逆方向の両方で転送された場合、[RFC7323]のセクション4.1の往復時間測定規則を適用することができます。この規則は、それが転送に進行していない限り、パケットを使用して測定を除外します（[Storowes]と一致して）パケットを使用して測定を除外します（送信ウィンドウの左端を前進させます）。

* A different heuristic from [Trammell-14] is to exclude any RTD_rev that is larger than previously observed values. This would tend to exclude Reverse measurements taken when the application has no data ready to send, because considerable time could be added to RTD_rev from this source of error.

* [Trammell-14]からの異なるヒューリスティックは、以前に観察された値よりも大きいRTD_REVを除外することです。これは、このエラーの原因からrtd_revにかなりの時間を追加することができるので、アプリケーションにデータが送信される準備ができていないときに行われた逆の測定値を除外する傾向があります。

* Note that the above heuristic assumes that host A is sending data. Host A expecting a download would mean that this heuristic should be applied to RTD_fwd.

* 上記のヒューリスティックは、ホストAがデータを送信していると仮定していることに注意してください。ダウンロードを期待するホストダウンロードは、このヒューリスティックをRTD_FWDに適用する必要があることを意味します。

* The statistic calculations to summarize the delay (RTDelay) SHALL be performed on the conditional distribution, conditioned on successful Forward and Reverse measurements that follow the heuristics.

* 遅延（RTDELAY）を要約するための統計計算は、発見的に続く正常な前方および逆方向測定で調整された条件付き分布に対して実行されなければならない。

Method for Inferring Loss:

損失を推論するための方法：

* The OP tracks sequence numbers and stores gaps for each direction of transmission, as well as the next expected sequence number as discussed in [Trammell-14] and [RFC4737]. Loss is inferred from out-of-order segments and duplicate segments.

* OPはシーケンス番号を追跡し、[Trammell-14]と[RFC4737]で説明した次の予想されるシーケンス番号と同様に、各送信方向のギャップを格納します。損失は順序外のセグメントと重複するセグメントから推測されます。

Loss Measurement Filtering Heuristics:

損失測定フィルタリングヒューリスティック：

* [Trammell-14] adds a window of evaluation based on the RTDelay.

* [Trammell-14] RTDELAYに基づいて評価のウィンドウを追加します。

* Distinguish reordered packets from out-of-order segments due to loss, because the sequence number gap is filled during the same RTDelay window. Segments detected as reordered according to [RFC4737] MUST reduce the loss count inferred from out-of-order segments.

* 同じRTDELAYウィンドウの間にシーケンス番号のギャップが埋められているため、損失のため、並べ替えされたパケットを損失のために区別します。[RFC4737]に従って並べ替えられたセグメントは、順序外のセグメントから推定される損失数を減らす必要があります。

* Spurious (unneeded) retransmissions (observed as duplicates) can also be reduced in this way, as described in [Trammell-14].

* [Trammell-14]に記載されているように、スプリアス（不要）再送信（重複として観察された）もこのように減らすことができます。

Sources of Error:

エラーの原因：

* The principal source of RTDelay error is the host processing time to return a packet that defines the termination of a time interval. The heuristics above intend to mitigate these errors by excluding measurements where host processing time is a significant part of RTD_fwd or RTD_rev.

* RTDELAYエラーの主な原因は、時間間隔の終了を定義するパケットを返すホスト処理時間です。上記のヒューリスティックは、ホスト処理時間がRTD_FWDまたはRTD_REVの重要な部分である測定値を除外することによってこれらのエラーを軽減するつもりです。

* A key source of RTLoss error is observation loss, as described in Section 3 of [Trammell-14].

* [Trammell-14]のセクション3に記載されているように、RTlossエラーの重要な源は観測損失です。

10.3.2. Packet Stream Generation

10.3.2. パケットストリームの生成

N/A

めずく

10.3.3. Traffic Filtering (Observation) Details

10.3.3. トラフィックフィルタリング（観測）詳細

The Fixed Parameters above give a portion of the Traffic Filter. Other aspects will be supplied as Runtime Parameters (below).

上記の固定パラメータは、トラフィックフィルタの一部を与える。他の態様はランタイムパラメータ（下記）として提供されます。

10.3.4. Sampling Distribution

10.3.4. 標本分布

This metric requires a complete sample of all packets that qualify according to the Traffic Filter criteria.

このメトリックでは、トラフィックフィルタ基準に従って適格なすべてのパケットの完全なサンプルが必要です。

10.3.5. Runtime Parameters and Data Format

10.3.5. ランタイムパラメータとデータフォーマット

Runtime Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete.

ランタイムパラメータは、測定システムに構成され、測定システムに構成され、完了するための結果を報告する必要ファクタです。

Src: The IP address of the host in the host A Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

SRC：ホストAロールのホストのIPアドレス（IPv4のIPv4-address-no-zone zone zize on-ゾーン値は、IPv6の場合はIPv6のゾーン値を指定します。[RFC6991]のセクション4を参照）。

Dst: The IP address of the host in the host B Role (format ipv4-address-no-zone value for IPv4 or ipv6-address-no-zone value for IPv6; see Section 4 of [RFC6991]).

DST：ホストBロール内のホストのIPアドレス（IPv4のipv4-address-no-zone zone zize on-zono zone値ipv6のipv4-address-no-zone値。[RFC6991]のセクション4を参照）。

Tf: Optionally, the end of a measurement interval (format "date-time" as specified in Section 5.6 of [RFC3339]; see also "date-and-time" in Section 3 of [RFC6991]), or the duration (see T0). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Alternatively, the end of the measurement interval MAY be controlled by the measured connection, where the second pair of FIN and ACK packets exchanged between host A and host B effectively ends the interval.

TF：必要に応じて、測定間隔の終わり（RFC3339のセクション5.6で指定されている "日付 - 時刻"を参照してください。「RFC6991」のセクション3の「日付と時刻」、または期間も参照してください。T0）。UTCタイムゾーンは[RFC2330]のセクション6.1によって必要です。あるいは、測定間隔の終わりは測定された接続によって制御されてもよく、そこでホストAとホストBとの間で交換される第2のフィンおよびACKパケットは間隔を効果的に終了する。

TTL or Hop Limit: Set at desired value.

TTLまたはホップの制限：所望の値に設定します。

10.3.6. Roles

10.3.6. 役割

host A: Launches the SYN packet to open the connection. The Role of "host A" is synonymous with the IP address used at host A.

ホストA：接続を開くためにSYNパケットを起動します。「ホストA」の役割は、ホストAで使用されるIPアドレスと同義です。

host B: Replies with the SYN-ACK packet to open the connection. The Role of "host B" is synonymous with the IP address used at host B.

ホストB：接続を開くためにSYN-ACKパケットに応答します。「ホストB」の役割は、ホストBで使用されるIPアドレスと同義です。

10.4. Output

10.4. 出力

This category specifies all details of the output of measurements using the metric.

このカテゴリは、メトリックを使用した測定値の出力の詳細を指定します。

10.4.1. Type

10.4.1. タイプ

RTDelay Types are discussed in the subsections below.

RTDELAYの種類については、以下の小節で説明します。

For RTLoss: The count of lost packets.

rtlossの場合：失われたパケットの数。

10.4.2. Reference Definition

10.4.2. 参照定義

For all output types:

すべての出力タイプの場合

Tf: The end of a measurement interval (format "date-time" as specified in Section 5.6 of [RFC3339]; see also "date-and-time" in Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. The end of the measurement interval MAY be controlled by the measured connection, where the second pair of FIN and ACK packets exchanged between host A and host B effectively ends the interval.

TF：測定間隔の終わり（RFC3339]のセクション5.6で指定されているような「日付 - 時刻」。[RFC6991]のセクション3の「日付と時刻」も参照してください。UTCタイムゾーンは[RFC2330]のセクション6.1によって必要です。測定間隔の終わりは測定された接続によって制御されてもよく、そこでホストAとホストBとの間で交換される第2のフィンおよびACKパケットは、間隔を効果的に終了する。

RTDelay_Passive_IP-TCP-HS: The round-trip delay of the handshake is a Singleton.

RTDELAY_PASSIVE_IP-TCP-HS：ハンドシェイクの往復遅延はシングルトンです。

RTLoss: The count of lost packets.

rtloss：失われたパケットの数。

For each <statistic>, Singleton, or Loss Count, one of the following subsections applies.

<統計>、シングルトン、または損失数ごとに、以下のいずれかのサブセクションが適用されます。

10.4.2.1. Mean

10.4.2.1. 平均

The mean SHALL be calculated using the conditional distribution of all packets with a finite value of round-trip delay (undefined delays are excluded) -- a single value, as follows:

平均は、往復遅延の有限値を持つすべてのパケットの条件分布を使用して計算されます（未定義の遅延は除く） - 単一の値です。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 4.2.2 of [RFC6049] for details on calculating this statistic; see also Section 4.2.3 of [RFC6049].

この統計の計算については、[RFC6049]の4.2.2項を参照してください。[RFC6049]のセクション4.2.3も参照してください。

10.4.2.2. Min

10.4.2.2. min

The minimum SHALL be calculated using the conditional distribution of all packets with a finite value of round-trip delay (undefined delays are excluded) -- a single value, as follows:

最小値は、往復遅延の有限値を持つすべてのパケットの条件分布を使用して計算されます（未定義の遅延は除く） - 単一の値です。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 4.3.2 of [RFC6049] for details on calculating this statistic; see also Section 4.3.3 of [RFC6049].

この統計量の計算については、[RFC6049]の4.3.2項を参照してください。[RFC6049]のセクション4.3.3も参照してください。

10.4.2.3. Max

10.4.2.3. max

The maximum SHALL be calculated using the conditional distribution of all packets with a finite value of round-trip delay (undefined delays are excluded) -- a single value, as follows:

最大値は、往復遅延の有限値を持つすべてのパケットの条件付き分布を使用して計算されます（未定義の遅延は除く） - 次のように単一の値です。

See Section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and see Section 5 of [RFC6703] for background on this analysis choice.

See Section 4.3.2 of [RFC6049] for a closely related method for calculating this statistic; see also Section 4.3.3 of [RFC6049]. The formula is as follows:

      Max = (FiniteDelay[j])

      such that for some index, j, where 1 <= j <= N
      FiniteDelay[j] >= FiniteDelay[n] for all n

10.4.2.4. Singleton

10.4.2.4. シングルトン

The singleton SHALL be calculated using the successful RTD_fwd (on the SYN to SYN-ACK pair) and RTD_rev (on the SYN-ACK to ACK pair), see Section 10.3.1.

シングルトンは、RTD_FWDが成功した（SYN-ACKペア）とRTD_REV（SYN-ACKのACKペアの場合）を使用して計算されます。セクション10.3.1を参照してください。

The singleton time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see Section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per Section 6 of [RFC5905].

結果のシングルトン時間値は、0.000000001秒（1.0ns）の解像度0.000000001秒（1.0 ns）で、0.000000001秒（1.0 ns）であるDecimal64型の正の値として、秒単位で表されます（[RFC6020]のセクション9.3）。[RFC5905]のセクション6に従って、64ビットNTPタイムスタンプから。

10.4.2.5. Loss Counts

10.4.2.5. 損失額

RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count: The count of lost packets.

rtloss_passive_ip-tcp_rfc8912sec10_packet_count：紛失したパケットの数。

Observation of an out-of-order segment or duplicate segment infers a loss count, after application of the Definitions of Section 10.2.1 and the Loss Measurement Filtering Heuristics of Section 10.3.1. The composition of round-trip loss counts will be conducted over a measurement interval that is synonymous with a single TCP connection.

セクション10.2.1の定義と損失測定フィルタリングヒューリスティックの適用後、注文内セグメントまたは重複セグメントの観測とセクション10.3.1の損失測定フィルタリングヒューリスティック。往復損失数の構成は、単一のTCP接続と同義の測定間隔にわたって行われます。

For a measurement interval (corresponding to a single TCP connection) T0 to Tf, the REQUIRED Composition Function for the two single-direction counts of inferred loss is:

測定間隔（単一のTCP接続に対応）T0~TFの場合、推定損失の2つの方向カウントのための必要な構成関数は次のとおりです。

RTLoss = RTL_fwd + RTL_rev

RTLOSS = RTL_FWD RTL_REV.

Packet count: The numeric value of the result is expressed in units of lost packets, as a positive value of type uint64 (represents integer values between 0 and 18446744073709551615, inclusively (see Section 9.2 of [RFC6020]).

パケット数：結果の数値は、uint64の正の値として、紛失したパケット単位で表されます（0から18446744073709555555615の整数値を表す（RFC6020のセクション9.2参照）。

10.4.3. Metric Units

10.4.3. メートル法単位

The <statistic> of round-trip delay is expressed in seconds, where <statistic> is one of:

往復遅延の<統計>は秒単位で表されます。ここで、<statistic>は次のいずれかです。

* Mean

* 平均

* Min

* min

* Max

* max

The round-trip delay of the TCP handshake singleton is expressed in seconds.

TCPハンドシェイクシングルトンの往復遅延は秒単位で表されます。

The round-trip loss count is expressed as a number of packets.

往復損失数は、数のパケットとして表されます。

10.4.4. Calibration

10.4.4. 較正

Passive Measurements at an OP could be calibrated against an Active Measurement (with loss emulation) at host A or host B, where the Active Measurement represents the ground truth.

OPでの受動的測定値は、能動測定（損失エミュレーションを伴う）に対して積極的な測定に対して較正され、能動測定は地下真理を表す。

10.5. Administrative Items

10.5. 管理項目

10.5.1. Status

10.5.1. 状態

Current

現在

10.5.2. Requester

10.5.2. 要求者

RFC 8912

10.5.3. Revision

10.5.3. リビジョン

1.0

10.5.4. Revision Date

10.5.4. 改訂日

2021-11-17

10.6. Comments and Remarks

10.6. コメントと備考

None

なし

11. Security Considerations

11. セキュリティに関する考慮事項

These Registry Entries represent no known implications for Internet security. With the exception of [RFC1035], each RFC referenced above contains a Security Considerations section. Further, the Large-scale Measurement of Broadband Performance (LMAP) framework [RFC7594] provides both security and privacy considerations for measurements.

これらのレジストリエントリは、インターネットセキュリティに関する既知の意味を表していません。[RFC1035]を除いて、上記の各RFCにはセキュリティ上の考慮事項が含まれています。また、ブロードバンド性能（LMAP）フレームワークの大規模測定[RFC7594]は、セキュリティとプライバシーの考慮事項の両方を提供します。

There are potential privacy considerations for observed traffic, particularly for Passive Metrics as discussed in Section 10. An attacker that knows that its TCP connection is being measured can modify its behavior to skew the measurement results.

特にセクション。

12. IANA Considerations

12. IANAの考慮事項

IANA has populated the Performance Metrics Registry defined in [RFC8911] with the values defined in Sections 4 through 10.

IANAは、[RFC8911]で定義されているパフォーマンスメトリクスレジストリをセクション4から10で定義されています。

See the IANA Considerations section of [RFC8911] for additional considerations.

追加の考慮事項については、[RFC8911]のIANAの考慮事項セクションを参照してください。

13. References

13. 参考文献

13.1. Normative References

13.1. 引用文献

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC1035] Mockapetris、P.、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https：//www.rfc-editor.org/info/rfc1035>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.

[RFC2330] Paxson、V.、Almes、G.、MAHDAVI、J.、およびM Mathis、「IPパフォーマンスメトリックのためのフレームワーク」、RFC 2330、DOI 10.17487 / RFC2330、1998年5月、<https：//www.rfc-editor.org/info/rfc2330>。

[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>.

[RFC2681] Almes、G.、KalidIndi、S.、およびM.Zekauskas、「IPPMの往復遅延測定基準」、RFC 2681、DOI 10.17487 / RFC2681、1999年9月、<https：//www.rfc-編集者.ORG / INFO / RFC2681>。

[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.

[RFC3339] Klyne、G.およびC. Newman、「インターネット上の日時：Timestamps」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<https：//www.rfc-editor.org/info/rfc3339>。

[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393, November 2002, <https://www.rfc-editor.org/info/rfc3393>.

[RFC3393] Demichelis、C.およびP. Chiento、「IPパフォーマンスメトリックのIPパケット遅延変動測定基準（IPPM）」、RFC 3393、DOI 10.17487 / RFC3393、2002年11月、<https：//www.rfc-editor.org/ info / rfc3393>。

[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, DOI 10.17487/RFC3432, November 2002, <https://www.rfc-editor.org/info/rfc3432>.

[RFC3432] Raisanen、V.、GroteFeld、G.、およびA.モートン、「定期的なストリームによるネットワーク性能測定」、RFC 3432、DOI 10.17487 / RFC3432、2002年11月、<https：//www.rfc-editor.org/ info / rfc3432>。

[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 10.17487/RFC4737, November 2006, <https://www.rfc-editor.org/info/rfc4737>.

[RFC4737]モートン、A。、CIAVATTONE、L.、Ramachandran、G.、Shalunov、S.、およびJ. Perser、「パケット並べ替えメトリック」、RFC 4737、DOI 10.17487 / RFC4737、2006年11月、<https：//www.rfc-editor.org/info/rfc4737>。

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.

[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K.、およびJ.Babiarz、「双方向アクティブ測定プロトコル（Twamp）」、RFC 5357、DOI 10.17487 / RFC5357、10月2008年、<https://www.rfc-editor.org/info/rfc5357>。

[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009, <https://www.rfc-editor.org/info/rfc5481>.

[RFC5481]モートン、A.およびB.Claise、「パケット遅延変動適用声明」、RFC 5481、DOI 10.17487 / RFC5481、2009年3月、<https：//www.rfc-editor.org/info/rfc5481>。

[RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, DOI 10.17487/RFC5560, May 2009, <https://www.rfc-editor.org/info/rfc5560>.

[RFC5560] Uijterwaal、H.、 "Andeou Packet Duplication Metric"、RFC 5560、DOI 10.17487 / RFC5560、2009年5月、<https://www.rfc-editor.org/info/rfc5560>。

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.

[RFC5905]ミルズ、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルおよびアルゴリズム仕様」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月<https://www.rfc-editor.org/info/rfc5905>。

[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6020] Bjorklund、M.、Ed。、 "Yang - ネットワーク構成プロトコルのデータモデリング言語（NetConf）"、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<https：//www.rfc-編集者。org / info / rfc6020>。

[RFC6049] Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, <https://www.rfc-editor.org/info/rfc6049>.

[RFC6049]モートン、A.およびE.Stethan、「メトリックの空間構成」、RFC 6049、DOI 10.17487 / RFC6049、2011年1月、<https：//www.rfc-editor.org/info/rfc6049>。

[RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI 10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/rfc6673>.

[RFC6673]モートン、A。、「往復パケット損失メトリック」、RFC 6673、DOI 10.17487 / RFC6673、2012年8月、<https：//www.rfc-editor.org/info/rfc6673>。

[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC6991] Schoenwaelder、J.、Ed。、「共通ヤンデータ型」、RFC 6991、DOI 10.17487 / RFC6991、2013年7月、<https：//www.rfc-editor.org/info/rfc6991>。

[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.

[RFC7011] Claise、B.、ED。、Trammell、B.、ED。、「フロー情報交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、DOI 10.17487 / RFC7011、2013年9月、<https：//www.rfc-editor.org/info/rfc7011>。

[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.

[RFC7323] Borman、D.、Braden、B.、Jacobson、V.、およびR.Scheffenegger、ED。、「高性能のためのTCP拡張」、RFC 7323、DOI 10.17487 / RFC7323、2014年9月、<https：//www.rfc-editor.org/info/rfc7323>。

[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-editor.org/info/rfc7679>.

[RFC7679] Almes、G.、Kiristindi、S.、Zekauskas、M.、およびA.モートン、「IP性能メトリックの一方向遅延メトリック（IPPM）」、STD 81、RFC 7679、DOI 10.17487/ RFC7679、2016年1月、<https：//www.rfc-editor.org/info/rfc7679>。

[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc-editor.org/info/rfc7680>.

[RFC7680] Almes、G.、Kiristindi、S.、Zekauskas、M.、およびA.モートン、「IPパフォーマンス測定基準（IPPM）の一方向損失メトリック（IPPM）」、STD 82、RFC 7680、DOI 10.17487/ RFC7680、2016年1月、<https：//www.rfc-editor.org/info/rfc7680>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。

[RFC8911] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. Akhter, "Registry for Performance Metrics", RFC 8911, DOI 10.17487/RFC8911, November 2021, <https://www.rfc-editor.org/info/rfc8911>.

[RFC8911] Bagnulo、M.、Claise、B.、Eardley、P.、Morton、A.、A.Akhter、「パフォーマンスメトリックのレジストリ」、RFC 8911、DOI 10.17487 / RFC8911、2021年11月、<https：//www.rfc-editor.org/info/rfc8911>。

[Strowes] Strowes, S., "Passively Measuring TCP Round-Trip Times", Communications of the ACM, Vol. 56 No. 10, Pages 57-64, DOI 10.1145/2507771.2507781, October 2013, <https://dl.acm.org/doi/10.1145/2507771.2507781>.

[紙幣]、「TCP往復時間を受動的に測定」、ACMの通信、Vol。56 No. 10、Doi 10.1145 / 2507771.2507781、<https：//dl.acm.org/doi/10.1145/2507777-2507781>。

[Trammell-14] Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data Integrity Signals for Passive Measurement", In: Dainotti A., Mahanti A., Uhlig S. (eds) Traffic Monitoring and Analysis. TMA 2014. Lecture Notes in Computer Science, vol 8406. Springer, Berlin, Heidelberg, DOI 10.1007/978-3-642-54999-1_2, March 2014, <https://link.springer.com/ chapter/10.1007/978-3-642-54999-1_2>.

[Trammell-14] Trammell、B.、Gugelmann、D.、およびN.Brownlee、「受動測定のためのインラインデータ完全性信号」、Dainotti A.、Mahanti A.、UHLIG S.（EDS）交通監視と分析。TMA 2014.コンピュータサイエンス、Vol 8406の講義ノート.Springer、Berlin、Heidelberg、Doi 10.1007 / 978-3-642-54999-1_2、2014年3月、<https：//link.springer.com/章/章/ 10.1007 / 978-3-642-54999-1_2>。

13.2. Informative References

13.2. 参考引用

[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, <https://www.rfc-editor.org/info/rfc1242>.

[RFC1242] Bradner、S。、「ネットワーク相互接続装置のベンチマーク用語」、RFC 1242、DOI 10.17487 / RFC1242、1991年7月、<https：//www.rfc-editor.org/info/rfc1242>。

[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <https://www.rfc-editor.org/info/rfc6390>.

[RFC6390] Clark、A.およびB.Claise、「新しいパフォーマンスメトリック開発を検討するためのガイドライン」、BCP 170、RFC 6390、DOI 10.17487 / RFC6390、2011年10月、<https：//www.rfc-editor.org/info/ RFC6390>。

[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting IP Network Performance Metrics: Different Points of View", RFC 6703, DOI 10.17487/RFC6703, August 2012, <https://www.rfc-editor.org/info/rfc6703>.

[RFC6703]モートン、A。、Ramachandran、G.、G. Magulri、「IPネットワークパフォーマンス測定基準の報告：さまざまな観点」、RFC 6703、DOI 10.17487 / RFC6703、<https：//www.rfc-editor.org/info/rfc6703>。

[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, <https://www.rfc-editor.org/info/rfc7594>.

[RFC7594]イヤーディリー、P.、Morton、A。、Bagnulo、M.、Burbridge、T.、Aitken、P.、A. AKHTER、「ブロードバンド性能の大規模測定のためのフレームワーク（LMAP）」、RFC7594、DOI 10.17487 / RFC7594、2015年9月、<https://www.rfc-editor.org/info/rfc7594>。

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8126]コットン、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www.rfc-editor.org / info / rfc8126>。

Acknowledgments

謝辞

The authors thank Brian Trammell for suggesting the term "Runtime Parameters", which led to the distinction between Runtime and Fixed Parameters implemented in this memo, for identifying the IP Flow Information Export (IPFIX) metric with Flow Key as an example, for suggesting the Passive TCP RTD Metric and supporting references, and for many other productive suggestions. Thanks to Peter Koch, who provided several useful suggestions for disambiguating successive DNS queries in the DNS Response time metric.

著者らはBrian Tramellに「ランタイムパラメータ」という用語を提案しています。パッシブTCP RTDメトリックとサポートリファレンス、および他の多くの生産的な提案について。Peter Kochのおかげで、DNS応答時間メトリックで連続したDNSクエリを曖昧させるためのいくつかの便利な提案を提供しました。

The authors also acknowledge the constructive reviews and helpful suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, Yaakov Stein, and participants in the LMAP Working Group. Thanks to Michelle Cotton for her early IANA reviews, and to Amanda Baber for answering questions related to the presentation of the Registry and accessibility of the complete template via URL.

著者らはまた、Barbara Stark、Juergen Schoenwaelder、TIMキャリー、Yaakov Stein、およびLMAPワーキンググループの参加者からの建設的なレビューと役立つ提案を認めます。URLを介して完全なテンプレートのプレゼンテーションに関連した質問に関連した質問に答えるためのマッシェルコットンのおかげで、Michelle Cotton Reviewsのおかげで、アマンダベーバに。

Authors' Addresses

著者の住所

Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States of America

Al Morton At＆T Labs 200 Laurel Avenue南Middletown、NJ 07748アメリカ合衆国

   Phone: +1 732 420 1571
   Email: acmorton@att.com

Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 28911 Leganes Madrid Spain

Marcelo Bagnulo Universidad Carlos Iii de Madrid AV。ユニバースID 30 28911 Leganes Madridスペイン

   Phone: 34 91 6249500
   Email: marcelo@it.uc3m.es
   URI:   http://www.it.uc3m.es

Philip Eardley BT Adastral Park, Martlesham Heath Ipswich United Kingdom

Philip Eardley BT Adastral Park、Martlesham Heath Ipswichイギリス

   Email: philip.eardley@bt.com

Kevin D'Souza AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States of America

Kevin D'Souza AT＆T Labs 200 Laurel Avenue Southletown、NJ 07748アメリカ合衆国

   Phone: +1 732 420 2514
   Email: kld@att.com