Internet Engineering Task Force (IETF)                         A. Morton
Request for Comments: 9097                                     AT&T Labs
Category: Standards Track                                        R. Geib
ISSN: 2070-1721                                         Deutsche Telekom
                                                           L. Ciavattone
                                                               AT&T Labs
                                                           November 2021

Metrics and Methods for One-Way IP Capacity




This memo revisits the problem of Network Capacity Metrics first examined in RFC 5136. This memo specifies a more practical Maximum IP-Layer Capacity Metric definition catering to measurement and outlines the corresponding Methods of Measurement.

このメモは、最初にRFC 5136で最初に検査されたネットワーク容量メトリックの問題を再検討します。このメモは、測定に対応するより実用的な最大IP層容量メトリック定義を指定し、対応する測定方法を概説します。

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


Copyright Notice


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

Copyright(C)2021 IETFの信頼と文書著者として識別された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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文書(に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。

Table of Contents


   1.  Introduction
     1.1.  Requirements Language
   2.  Scope, Goals, and Applicability
   3.  Motivation
   4.  General Parameters and Definitions
   5.  IP-Layer Capacity Singleton Metric Definitions
     5.1.  Formal Name
     5.2.  Parameters
     5.3.  Metric Definitions
     5.4.  Related Round-Trip Delay and One-Way Loss Definitions
     5.5.  Discussion
     5.6.  Reporting the Metric
   6.  Maximum IP-Layer Capacity Metric Definitions (Statistics)
     6.1.  Formal Name
     6.2.  Parameters
     6.3.  Metric Definitions
     6.4.  Related Round-Trip Delay and One-Way Loss Definitions
     6.5.  Discussion
     6.6.  Reporting the Metric
   7.  IP-Layer Sender Bit Rate Singleton Metric Definitions
     7.1.  Formal Name
     7.2.  Parameters
     7.3.  Metric Definition
     7.4.  Discussion
     7.5.  Reporting the Metric
   8.  Method of Measurement
     8.1.  Load Rate Adjustment Algorithm
     8.2.  Measurement Qualification or Verification
     8.3.  Measurement Considerations
   9.  Reporting Formats
     9.1.  Configuration and Reporting Data Formats
   10. Security Considerations
   11. IANA Considerations
   12. References
     12.1.  Normative References
     12.2.  Informative References
   Appendix A.  Load Rate Adjustment Pseudocode
   Appendix B.  RFC 8085 UDP Guidelines Check
     B.1.  Assessment of Mandatory Requirements
     B.2.  Assessment of Recommendations
   Authors' Addresses
1. Introduction
1. はじめに

The IETF's efforts to define Network Capacity and Bulk Transport Capacity (BTC) have been chartered and progressed for over twenty years. Over that time, the performance community has seen the development of Informative definitions in [RFC3148] for the Framework for Bulk Transport Capacity, [RFC5136] for Network Capacity and Maximum IP-Layer Capacity, and the Experimental metric definitions and methods in "Model-Based Metrics for Bulk Transport Capacity" [RFC8337].

ネットワーク能力とバルク輸送能力(BTC)を定義するためのIETFの取り組みは、20年以上にわたってチャーターされ、進学されました。その時点で、パフォーマンスコミュニティは、ネットワーク容量と最大IP層容量のためのバルク輸送容量[RFC5136]のフレームワークの[RFC3148]の有益な定義の開発を見てきました。バルクトランスポート容量のためのメトリックベースのメトリック "[RFC8337]。

This memo revisits the problem of Network Capacity Metrics examined first in [RFC3148] and later in [RFC5136]. Maximum IP-Layer Capacity and Bulk Transfer Capacity [RFC3148] (goodput) are different metrics. Maximum IP-Layer Capacity is like the theoretical goal for goodput. There are many metrics in [RFC5136], such as Available Capacity. Measurements depend on the network path under test and the use case. Here, the main use case is to assess the Maximum Capacity of one or more networks where the subscriber receives specific performance assurances, sometimes referred to as Internet access, or where a limit of the technology used on a path is being tested. For example, when a user subscribes to a 1 Gbps service, then the user, the Service Provider, and possibly other parties want to assure that the specified performance level is delivered. When a test confirms the subscribed performance level, a tester can seek the location of a bottleneck elsewhere.

このメモは、[RFC3148]で最初に[RFC5136]で最初に検査したネットワーク容量メトリックの問題を再検討します。最大IP層容量とバルク転送容量[RFC3148](Goodput)は異なるメトリックです。最大IP層容量は、Goodputの理論的目標のようなものです。利用可能な容量などの[RFC5136]には多くの測定基準があります。測定値は、テスト中のネットワークパスとユースケースによって異なります。ここで、主なユースケースは、加入者がインターネットアクセスと呼ばれる特定の性能保証を受信する1つまたは複数のネットワークの最大容量を評価すること、またはパスで使用されているテクノロジの制限がテストされている場所である。例えば、ユーザが1 Gbpsサービスを購読するとき、ユーザ、サービスプロバイダ、および他の当事者は、指定されたパフォーマンスレベルが配信されていることを保証したい。テストが購読したパフォーマンスレベルを確認すると、テスターは他の場所でボトルネックの場所を求めることができます。

This memo recognizes the importance of a definition of a Maximum IP-Layer Capacity Metric at a time when Internet subscription speeds have increased dramatically -- a definition that is both practical and effective for the performance community's needs, including Internet users. The metric definitions are intended to use Active Methods of Measurement [RFC7799], and a Method of Measurement is included for each metric.

このメモは、インターネットの購読速度が劇的に増加した時点での最大IP層容量メトリックの定義の重要性を認識します - インターネットユーザーを含むパフォーマンスコミュニティのニーズに実用的で効果的である定義。メトリック定義は、能動的測定方法[RFC7799]を使用することを目的としており、各メトリックについて測定方法が含まれています。

The most direct Active Measurement of IP-Layer Capacity would use IP packets, but in practice a transport header is needed to traverse address and port translators. UDP offers the most direct assessment possibility, and in the measurement study to investigate whether UDP is viable as a general Internet transport protocol [copycat], the authors found that a high percentage of paths tested support UDP transport. A number of liaison statements have been exchanged on this topic [LS-SG12-A] [LS-SG12-B], discussing the laboratory and field tests that support the UDP-based approach to IP-Layer Capacity measurement.

IP層容量の最も直接的なアクティブな測定はIPパケットを使用しますが、実際にはアドレスとポートトランスレータをトラバースするためにトランスポートヘッダーが必要です。UDPは最も直接評価の可能性を提供し、測定調査でUDPが一般的なインターネットトランスポートプロトコル[CopyCat]として実行可能かどうかを調査するための測定調査で、著者らはテストされた経路の高い割合がUDPトランスポートをサポートすることを見出した。このトピック[LS-SG12-A] [LS-SG12-B]で多くのLiaisonステートメントが交換され、IP層容量測定へのUDPベースのアプローチをサポートする実験室およびフィールドテストについて説明しています。

This memo also recognizes the updates to the IP Performance Metrics (IPPM) Framework [RFC2330] that have been published since 1998. In particular, it makes use of [RFC7312] for the Advanced Stream and Sampling Framework and [RFC8468] for its IPv4, IPv6, and IPv4-IPv6 Coexistence Updates.

このメモは、1998年以降に公開されているIP Performance Metrics(IPPM)フレームワーク[RFC2330]の更新プログラムを認識しています。特に、Advanced StreamとSampling Framework用の[RFC7312]、IPv4の[RFC8468]を使用します。IPv6、およびIPv4-IPv6の共存更新

Appendix A describes the load rate adjustment algorithm, using pseudocode. Appendix B discusses the algorithm's compliance with [RFC8085].


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, Goals, and Applicability
2. 範囲、目標、および適用可能性

The scope of this memo is to define Active Measurement metrics and corresponding methods to unambiguously determine Maximum IP-Layer Capacity and useful secondary metrics.


Another goal is to harmonize the specified Metric and Method across the industry, and this memo is the vehicle that captures IETF consensus, possibly resulting in changes to the specifications of other Standards Development Organizations (SDOs) (through each SDO's normal contribution process or through liaison exchange).


Secondary goals are to add considerations for test procedures and to provide interpretation of the Maximum IP-Layer Capacity results (to identify cases where more testing is warranted, possibly with alternate configurations). Fostering the development of protocol support for this Metric and Method of Measurement is also a goal of this memo (all active testing protocols currently defined by the IPPM WG are UDP based, meeting a key requirement of these methods). The supporting protocol development to measure this metric according to the specified method is a key future contribution to Internet measurement.

セカンダリの目標は、テスト手順のための考慮事項を追加し、最大IP層容量の結果の解釈を提供することです(場合によっては、代替構成では、より多くのテストが保証されている場合を識別するため)。このメトリックのプロトコルサポートの開発を促進すると、測定方法もこのメモの目的です(IPPM WGによって現在定義されているすべてのアクティブなテストプロトコルはUDPベースで、これらのメソッドの重要な要件を満たしています)。指定された方法に従ってこのメトリックを測定するためのサポートプロトコル開発は、インターネット測定への将来の将来の貢献です。

The load rate adjustment algorithm's scope is limited to helping determine the Maximum IP-Layer Capacity in the context of an infrequent, diagnostic, short-term measurement. It is RECOMMENDED to discontinue non-measurement traffic that shares a subscriber's dedicated resources while testing: measurements may not be accurate, and throughput of competing elastic traffic may be greatly reduced.


The primary application of the Metrics and Methods of Measurement described here is the same as what is described in Section 2 of [RFC7497], where:


   |  The access portion of the network is the focus of this problem
   |  statement.  The user typically subscribes to a service with
   |  bidirectional [Internet] access partly described by rates in bits
   |  per second.

In addition, the use of the load rate adjustment algorithm described in Section 8.1 has the following additional applicability limitations:


* It MUST only be used in the application of diagnostic and operations measurements as described in this memo.

* このメモに記載されているように、診断および運用測定の適用にのみ使用する必要があります。

* It MUST only be used in circumstances consistent with Section 10 ("Security Considerations").

* セクション10(「セキュリティ上の考慮事項」)と一致する状況でのみ使用する必要があります。

* If a network operator is certain of the IP-Layer Capacity to be validated, then testing MAY start with a fixed-rate test at the IP-Layer Capacity and avoid activating the load adjustment algorithm. However, the stimulus for a diagnostic test (such as a subscriber request) strongly implies that there is no certainty, and the load adjustment algorithm is RECOMMENDED.

* ネットワークオペレータが検証されるべきIP層容量のうちの確実である場合、テストはIP層容量で固定レートテストで始まり、負荷調整アルゴリズムを起動しないようにしてもよい。しかしながら、診断テスト(加入者要求など)の刺激は、確実性がないことを強く意味し、そして負荷調整アルゴリズムを推奨する。

Further, the Metrics and Methods of Measurement are intended for use where specific exact path information is unknown within a range of possible values:


* The subscriber's exact Maximum IP-Layer Capacity is unknown (which is sometimes the case; service rates can be increased due to upgrades without a subscriber's request or increased to provide a surplus to compensate for possible underestimates of TCP-based testing).

* 加入者の正確な最大IP層容量は不明です(場合によってはケースが発生します。加入者の要求なしのアップグレードまたは増加して、TCPベースのテストの過小評価過誤を補償するための余剰を提供するために)。

* The size of the bottleneck buffer is unknown.

* ボトルネックバッファのサイズは不明です。

Finally, the measurement system's load rate adjustment algorithm SHALL NOT be provided with the exact capacity value to be validated a priori. This restriction fosters a fair result and removes an opportunity for nefarious operation enabled by knowledge of the correct answer.


3. Motivation
3. 動機

As with any problem that has been worked on for many years in various SDOs without any special attempts at coordination, various solutions for Metrics and Methods have emerged.


There are five factors that have changed (or began to change) in the 2013-2019 time frame, and the presence of any one of them on the path requires features in the measurement design to account for the changes:


1. Internet access is no longer the bottleneck for many users (but subscribers expect network providers to honor contracted performance).

1. インターネットアクセスは、多くのユーザーのためのボトルネックではなくなりました(しかし、購読者はネットワークプロバイダーが契約業績を述べるために期待しています)。

2. Both transfer rate and latency are important to a user's satisfaction.

2. 転送速度と待ち時間の両方がユーザーの満足度にとって重要です。

3. UDP's role in transport is growing in areas where TCP once dominated.

3. UDPの輸送中の役割は、TCPが一度支配された地域で成長しています。

4. Content and applications are moving physically closer to users.

4. コンテンツとアプリケーションは、物理的にユーザーに近づくことです。

5. There is less emphasis on ISP gateway measurements, possibly due to less traffic crossing ISP gateways in the future.

5. 将来的にはISPゲートウェイの測定値が低下しています。

4. General Parameters and Definitions
4. 一般的なパラメータと定義

This section lists the REQUIRED input factors to specify a Sender or Receiver metric.


Src: One of the addresses of a host (such as a globally routable IP address).


Dst: One of the addresses of a host (such as a globally routable IP address).


MaxHops: The limit on the number of Hops a specific packet may visit as it traverses from the host at Src to the host at Dst (implemented in the TTL or Hop Limit).


T0: The time at the start of a measurement interval, when packets are first transmitted from the Source.


I: The nominal duration of a measurement interval at the Destination (default 10 sec).


dt: The nominal duration of m equal sub-intervals in I at the Destination (default 1 sec).


dtn: The beginning boundary of a specific sub-interval, n, one of m sub-intervals in I.


FT: The feedback time interval between status feedback messages communicating measurement results, sent from the Receiver to control the Sender. The results are evaluated throughout the test to determine how to adjust the current offered load rate at the Sender (default 50 msec).

FT:ステータスフィードバックメッセージ間のフィードバック時間間隔は、送信者から送信された測定結果を通信します。結果は、テストを通して評価され、送信者の現在の提供された負荷率を調整する方法を決定します(デフォルト50 msec)。

Tmax: A maximum waiting time for test packets to arrive at the Destination, set sufficiently long to disambiguate packets with long delays from packets that are discarded (lost), such that the distribution of one-way delay is not truncated.


F: The number of different flows synthesized by the method (default one flow).


Flow: The stream of packets with the same n-tuple of designated header fields that (when held constant) result in identical treatment in a multipath decision (such as the decision taken in load balancing). Note: The IPv6 flow label SHOULD be included in the flow definition when routers have complied with the guidelines provided in [RFC6438].


Type-P: The complete description of the test packets for which this assessment applies (including the flow-defining fields). Note that the UDP transport layer is one requirement for test packets specified below. Type-P is a concept parallel to "population of interest" as defined in Clause 6.1.1 of [Y.1540].


Payload Content: An aspect of the Type-P Parameter that can help to improve measurement determinism. Specifying packet payload content helps to ensure IPPM Framework-conforming Metrics and Methods. If there is payload compression in the path and tests intend to characterize a possible advantage due to compression, then payload content SHOULD be supplied by a pseudorandom sequence generator, by using part of a compressed file, or by other means. See Section 3.1.2 of [RFC7312].

ペイロードコンテンツ:測定決定論を向上させるのに役立ち得るType-Pパラメータの一側面。Packet Payload Contentの指定IPPMフレームワーク適合メトリックとメソッドを確保するのに役立ちます。パスとテストでペイロード圧縮がある場合、圧縮のために可能な利点を特徴付けるつもりは、圧縮ファイルの一部を使用して、または他の手段によってペイロードコンテンツを疑似ランダムシーケンスジェネレータによって提供する必要があります。[RFC7312]の3.1.2項を参照してください。

PM: A list of fundamental metrics, such as loss, delay, and reordering, and corresponding target performance threshold(s). At least one fundamental metric and target performance threshold MUST be supplied (such as one-way IP packet loss [RFC7680] equal to zero).


A non-Parameter that is required for several metrics is defined below:


T: The host time of the *first* test packet's *arrival* as measured at the Destination Measurement Point, or MP(Dst). There may be other packets sent between Source and Destination hosts that are excluded, so this is the time of arrival of the first packet used for measurement of the metric.


Note that timestamp format and resolution, sequence numbers, etc. will be established by the chosen test protocol standard or implementation.


5. IP-Layer Capacity Singleton Metric Definitions
5. IP層容量シングルトンメトリック定義

This section sets requirements for the Singleton metric that supports the Maximum IP-Layer Capacity Metric definitions in Section 6.


5.1. Formal Name
5.1. 正式名称

"Type-P-One-way-IP-Capacity" is the formal name; it is informally called "IP-Layer Capacity".


Note that Type-P depends on the chosen method.


5.2. Parameters
5.2. パラメーター

This section lists the REQUIRED input factors to specify the metric, beyond those listed in Section 4.


No additional Parameters are needed.


5.3. Metric Definitions
5.3. メトリックの定義

This section defines the REQUIRED aspects of the measurable IP-Layer Capacity Metric (unless otherwise indicated) for measurements between specified Source and Destination hosts:


Define the IP-Layer Capacity, C(T,dt,PM), to be the number of IP-Layer bits (including header and data fields) in packets that can be transmitted from the Src host and correctly received by the Dst host during one contiguous sub-interval, dt in length. The IP-Layer Capacity depends on the Src and Dst hosts, the host addresses, and the path between the hosts.


The number of these IP-Layer bits is designated n0[dtn,dtn+1] for a specific dt.

これらのIP層ビットの数は、特定のDTに対してN0 [DTN、DTN 1]と指定されている。

When the packet size is known and of fixed size, the packet count during a single sub-interval dt multiplied by the total bits in IP header and data fields is equal to n0[dtn,dtn+1].


Anticipating a Sample of Singletons, the number of sub-intervals with duration dt MUST be set to a natural number m, so that T+I = T + m*dt with dtn+1 - dtn = dt for 1 <= n <= m.

シングルトンのサンプルを予測すると、持続時間DTを持つサブ間隔の数は自然数Mに設定されなければならず、その結果、DTN 1 - DTN = DTのT i = T m * dtは1≦n≦mです。

Parameter PM represents other performance metrics (see Section 5.4 below); their measurement results SHALL be collected during measurement of IP-Layer Capacity and associated with the corresponding dtn for further evaluation and reporting. Users SHALL specify the Parameter Tmax as required by each metric's reference definition.


Mathematically, this definition is represented as (for each n):


                                   ( n0[dtn,dtn+1] )
                   C(T,dt,PM) = -------------------------

Figure 1: Equation for IP-Layer Capacity




* n0 is the total number of IP-Layer header and payload bits that can be transmitted in standard-formed packets [RFC8468] from the Src host and correctly received by the Dst host during one contiguous sub-interval, dt in length, during the interval [T,T+I].

* N0は、SRCホストから標準化されたパケット[RFC8468]で送信できるIP層ヘッダとペイロードビットの総数と、間隔中に1つの連続したサブインターバルDTの間にDSTホストによって正しく受信されます。[T、T]。

* C(T,dt,PM), the IP-Layer Capacity, corresponds to the value of n0 measured in any sub-interval beginning at dtn, divided by the length of the sub-interval, dt.

* IP層容量は、DTNからの任意のサブ間隔で測定されたN0の値に対応し、サブインターバルDTの長さで割った値に対応する。

* PM represents other performance metrics (see Section 5.4 below); their measurement results SHALL be collected during measurement of IP-Layer Capacity and associated with the corresponding dtn for further evaluation and reporting.

* PMは他のパフォーマンスメトリックを表します(下記のセクション5.4を参照)。それらの測定結果は、IP層容量の測定中に収集され、さらなる評価および報告のために対応するDTNに関連付けられなければならない。

* All sub-intervals MUST be of equal duration. Choosing dt as non-overlapping consecutive time intervals allows for a simple implementation.

* すべてのサブ間隔は等しい期間でなければなりません。重複しない連続した時間間隔としてDTを選択すると、簡単な実装が可能になります。

* The bit rate of the physical interface of the measurement devices MUST be higher than the smallest of the links on the path whose C(T,I,PM) is to be measured (the bottleneck link).

* 測定装置の物理的インタフェースのビットレートは、C(T、I、PM)を測定する経路上のリンクの最小値よりも高い(ボトルネックリンク)。

Measurements according to this definition SHALL use the UDP transport layer. Standard-formed packets are specified in Section 5 of [RFC8468]. The measurement SHOULD use a randomized Source port or equivalent technique, and SHOULD send responses from the Source address matching the test packet Destination address.


Some effects of compression on measurement are discussed in Section 6 of [RFC8468].


5.4. Related Round-Trip Delay and One-Way Loss Definitions
5.4. 関連往復遅延と一方向損失の定義

RTD[dtn,dtn+1] is defined as a Sample of the Round-Trip Delay [RFC2681] between the Src host and the Dst host during the interval [T,T+I] (that contains equal non-overlapping intervals of dt). The "reasonable period of time" mentioned in [RFC2681] is the Parameter Tmax in this memo. The statistics used to summarize RTD[dtn,dtn+1] MAY include the minimum, maximum, median, mean, and the range = (maximum - minimum). Some of these statistics are needed for load adjustment purposes (Section 8.1), measurement qualification (Section 8.2), and reporting (Section 9).

RTD [DTN、DTN 1]は、インターバル[T、T i]の間のSRCホストとDSTホストの間の往復遅延[RFC2681]のサンプルとして定義されます(それは、重ならないDTを含む)。[RFC2681]に記載されている「妥当な期間」は、このメモのパラメータTmaxです。RTD [DTN、DTN 1]を要約するために使用される統計は、最小、最大、中央値、平均、および範囲=(最大 - 最小)を含み得る。これらの統計の一部は、負荷調整目的(第8.1項)、測定資格(セクション8.2)、および報告(第9章)に必要です。

OWL[dtn,dtn+1] is defined as a Sample of the One-Way Loss [RFC7680] between the Src host and the Dst host during the interval [T,T+I] (that contains equal non-overlapping intervals of dt). The statistics used to summarize OWL[dtn,dtn+1] MAY include the count of lost packets and the ratio of lost packets.

OWL [DTN、DTN 1]は、間隔[T、T i]の間のSRCホストとDSTホストの間の一方向損失[RFC7680]のサンプル(DTの等しい非重複間隔を含む)として定義されています。OWL [DTN、DTN 1]を要約するために使用される統計は、失われたパケットの数および失われたパケットの比率を含み得る。

Other metrics MAY be measured: one-way reordering, duplication, and delay variation.


5.5. Discussion
5.5. 考察

See the corresponding section for Maximum IP-Layer Capacity (Section 6.5).


5.6. Reporting the Metric
5.6. メトリックを報告する

The IP-Layer Capacity SHOULD be reported with at least single-Megabit resolution, in units of Megabits per second (Mbps) (which, to avoid any confusion, is 1,000,000 bits per second).


The related One-Way Loss metric and Round-Trip Delay measurements for the same Singleton SHALL be reported, also with meaningful resolution for the values measured.


Individual Capacity measurements MAY be reported in a manner consistent with the Maximum IP-Layer Capacity; see Section 9.


6. Maximum IP-Layer Capacity Metric Definitions (Statistics)
6. 最大IP層容量メトリック定義(統計)

This section sets requirements for the following components to support the Maximum IP-Layer Capacity Metric.


6.1. Formal Name
6.1. 正式名称

"Type-P-One-way-Max-IP-Capacity" is the formal name; it is informally called "Maximum IP-Layer Capacity".


Note that Type-P depends on the chosen method.


6.2. Parameters
6.2. パラメーター

This section lists the REQUIRED input factors to specify the metric, beyond those listed in Section 4.


No additional Parameters or definitions are needed.


6.3. Metric Definitions
6.3. メトリック定義

This section defines the REQUIRED aspects of the Maximum IP-Layer Capacity Metric (unless otherwise indicated) for measurements between specified Source and Destination hosts:


Define the Maximum IP-Layer Capacity, Maximum_C(T,I,PM), to be the maximum number of IP-Layer bits n0[dtn,dtn+1] divided by dt that can be transmitted in packets from the Src host and correctly received by the Dst host, over all dt-length intervals in [T,T+I] and meeting the PM criteria. An equivalent definition would be the maximum of a Sample of size m of Singletons C(T,I,PM) collected during the interval [T,T+I] and meeting the PM criteria.

最大IP層容量、Maximum_C(T、I、PM)を定義して、SRCホストからパケットで送信できるDTで割ったIP層ビットN0 [DTN 1]の最大数と定義し、正しく受信されます。DSTホストによって、[T、TI]のすべてのDT長間隔でPM基準を満たす。同等の定義は、間隔[T、T i]の間に収集され、PM基準を満たすシングルトンC(T、I、PM)のサイズMの最大値の最大値であろう。

The number of sub-intervals with duration dt MUST be set to a natural number m, so that T+I = T + m*dt with dtn+1 - dtn = dt for 1 <= n <= m.

期間DTを有するサブ間隔の数は自然数Mに設定されなければならず、その結果、DTN 1 - DTN = DTのT i = T m * dtは1≦n≦mである。

Parameter PM represents the other performance metrics (see Section 6.4 below) and their measurement results for the Maximum IP-Layer Capacity. At least one target performance threshold (PM criterion) MUST be defined. If more than one metric and target performance threshold is defined, then the sub-interval with the maximum number of bits transmitted MUST meet all the target performance thresholds. Users SHALL specify the Parameter Tmax as required by each metric's reference definition.


Mathematically, this definition can be represented as:


                                      max  ( n0[dtn,dtn+1] )
                Maximum_C(T,I,PM) = -------------------------



                  T                                      T+I
                  |   |   |   |   |   |   |   |   |   |   |
              dtn=1   2   3   4   5   6   7   8   9  10  n+1

Figure 2: Equation for Maximum Capacity




* n0 is the total number of IP-Layer header and payload bits that can be transmitted in standard-formed packets from the Src host and correctly received by the Dst host during one contiguous sub-interval, dt in length, during the interval [T,T+I].

* N0は、区間[Tの間、1つの連続したサブインターバルDTの間、SRCホストから標準化されたパケットで送信できるIP層ヘッダおよびペイロードビットの総数である。ti]。

* Maximum_C(T,I,PM), the Maximum IP-Layer Capacity, corresponds to the maximum value of n0 measured in any sub-interval beginning at dtn, divided by the constant length of all sub-intervals, dt.

* 最大IP層容量は、DTNからの任意のサブ間隔で測定されたN0の最大値に対応し、すべてのサブ間隔dtの一定長さで割ったn0の最大値に対応します。

* PM represents the other performance metrics (see Section 6.4) and their measurement results for the Maximum IP-Layer Capacity. At least one target performance threshold (PM criterion) MUST be defined.

* PMは他のパフォーマンスメトリック(セクション6.4を参照)、最大IP層容量の測定結果を表します。少なくとも1つの目標性能閾値(PM基準)を定義する必要があります。

* All sub-intervals MUST be of equal duration. Choosing dt as non-overlapping consecutive time intervals allows for a simple implementation.

* すべてのサブ間隔は等しい期間でなければなりません。重複しない連続した時間間隔としてDTを選択すると、簡単な実装が可能になります。

* The bit rate of the physical interface of the measurement systems MUST be higher than the smallest of the links on the path whose Maximum_C(T,I,PM) is to be measured (the bottleneck link).

* 測定システムの物理的インターフェースのビットレートは、最大_c(t、i、pm)を測定する経路上のリンクの最小値(ボトルネックリンク)よりも高くなければなりません。

In this definition, the m sub-intervals can be viewed as trials when the Src host varies the transmitted packet rate, searching for the maximum n0 that meets the PM criteria measured at the Dst host in a test of duration I. When the transmitted packet rate is held constant at the Src host, the m sub-intervals may also be viewed as trials to evaluate the stability of n0 and metric(s) in the PM list over all dt-length intervals in I.


Measurements according to these definitions SHALL use the UDP transport layer.


6.4. Related Round-Trip Delay and One-Way Loss Definitions
6.4. 関連往復遅延と一方向損失の定義

RTD[dtn,dtn+1] and OWL[dtn,dtn+1] are defined in Section 5.4. Here, the test intervals are increased to match the capacity Samples, RTD[T,I] and OWL[T,I].

RTD[1DTNDTN、] [DTN、DTN1]とOWLはセクション5.4で定義されています。ここで、検査間隔はRTD[T、I]とOWL[T、I]、容量サンプルと一致するように増加されます。

The interval dtn,dtn+1 where Maximum_C(T,I,PM) occurs is the reporting sub-interval for RTD[dtn,dtn+1] and OWL[dtn,dtn+1] within RTD[T,I] and OWL[T,I].

最大_C(T、I、PM)が発生する間隔DTN、DTN 1はRTD [T、I]およびOWL [T]内のRTD [DTN、DTN 1]およびOWL [DTN、DTN 1]の報告サブインターバルです。私]。

Other metrics MAY be measured: one-way reordering, duplication, and delay variation.


6.5. Discussion
6.5. 考察

If traffic conditioning (e.g., shaping, policing) applies along a path for which Maximum_C(T,I,PM) is to be determined, different values for dt SHOULD be picked and measurements executed during multiple intervals [T,T+I]. Each duration dt SHOULD be chosen so that it is an integer multiple of increasing values k times serialization delay of a Path MTU (PMTU) at the physical interface speed where traffic conditioning is expected. This should avoid taking configured burst tolerance Singletons as a valid Maximum_C(T,I,PM) result.

トラフィック調整(例えば、シェーピング、ポリシング)が、最大_C(T、I、PM)を決定する経路に沿って適用される場合、DTのための異なる値を選択し、複数の間隔で実行される測定値[T、T i]。各期間DTは、交通調整が予想される物理的インタフェース速度での経路MTU(PMTU)のシリアル化遅延の整数倍の倍数倍の倍数であるように選択されるべきである。これにより、バーストトレランスシングルトンを有効な最大_C(T、I、PM)の結果として済みます。

A Maximum_C(T,I,PM) without any indication of bottleneck congestion, be that increased latency, packet loss, or Explicit Congestion Notification (ECN) marks during a measurement interval, I, is likely an underestimate of Maximum_C(T,I,PM).


6.6. Reporting the Metric
6.6. メトリックを報告する

The IP-Layer Capacity SHOULD be reported with at least single-Megabit resolution, in units of Megabits per second (Mbps) (which, to avoid any confusion, is 1,000,000 bits per second).


The related One-Way Loss metric and Round-Trip Delay measurements for the same Singleton SHALL be reported, also with meaningful resolution for the values measured.


When there are demonstrated and repeatable Capacity modes in the Sample, the Maximum IP-Layer Capacity SHALL be reported for each mode, along with the relative time from the beginning of the stream that the mode was observed to be present. Bimodal Maximum IP-Layer Capacities have been observed with some services, sometimes called a "turbo mode" intending to deliver short transfers more quickly or reduce the initial buffering time for some video streams. Note that modes lasting less than duration dt will not be detected.


Some transmission technologies have multiple methods of operation that may be activated when channel conditions degrade or improve, and these transmission methods may determine the Maximum IP-Layer Capacity. Examples include line-of-sight microwave modulator constellations, or cellular modem technologies where the changes may be initiated by a user moving from one coverage area to another. Operation in the different transmission methods may be observed over time, but the modes of Maximum IP-Layer Capacity will not be activated deterministically as with the "turbo mode" described in the paragraph above.


7. IP-Layer Sender Bit Rate Singleton Metric Definitions
7. IPレイヤの送信者のビットレートシングルトンメトリックの定義

This section sets requirements for the following components to support the IP-Layer Sender Bit Rate Metric. This metric helps to check that the Sender actually generated the desired rates during a test, and measurement takes place at the interface between the Src host and the network path (or as close as practical within the Src host). It is not a metric for path performance.


7.1. Formal Name
7.1. 正式名称

"Type-P-IP-Sender-Bit-Rate" is the formal name; it is informally called the "IP-Layer Sender Bit Rate".


Note that Type-P depends on the chosen method.


7.2. Parameters
7.2. パラメーター

This section lists the REQUIRED input factors to specify the metric, beyond those listed in Section 4.


S: The duration of the measurement interval at the Source.


st: The nominal duration of N sub-intervals in S (default st = 0.05 seconds).

ST:SのN個の部分間隔の公称期間(デフォルトST = 0.05秒)。

stn: The beginning boundary of a specific sub-interval, n, one of N sub-intervals in S.


S SHALL be longer than I, primarily to account for on-demand activation of the path, or any preamble to testing required, and the delay of the path.


st SHOULD be much smaller than the sub-interval dt and on the same order as FT; otherwise, the rate measurement will include many rate adjustments and include more time smoothing, possibly smoothing the interval that contains the Maximum IP-Layer Capacity (and therefore losing relevance). The st Parameter does not have relevance when the Source is transmitting at a fixed rate throughout S.


7.3. Metric Definition
7.3. メートル定義

This section defines the REQUIRED aspects of the IP-Layer Sender Bit Rate Metric (unless otherwise indicated) for measurements at the specified Source on packets addressed for the intended Destination host and matching the required Type-P:


Define the IP-Layer Sender Bit Rate, B(S,st), to be the number of IP-Layer bits (including header and data fields) that are transmitted from the Source with address pair Src and Dst during one contiguous sub-interval, st, during the test interval S (where S SHALL be longer than I) and where the fixed-size packet count during that single sub-interval st also provides the number of IP-Layer bits in any interval, [stn,stn+1].


Measurements according to this definition SHALL use the UDP transport layer. Any feedback from the Dst host to the Src host received by the Src host during an interval [stn,stn+1] SHOULD NOT result in an adaptation of the Src host traffic conditioning during this interval (rate adjustment occurs on st interval boundaries).

この定義による測定値はUDPトランスポート層を使用しなければならない。区間[STN、STN 1]中にSRCホストが受信したSRCホストへのDSTホストからのフィードバックは、この間隔中のSRCホストトラフィック調整の適応をもたらすものではありません(ST間隔境界でのレート調整が行われます)。

7.4. Discussion
7.4. 考察

Both the Sender and Receiver (or Source and Destination) bit rates SHOULD be assessed as part of an IP-Layer Capacity measurement. Otherwise, an unexpected sending rate limitation could produce an erroneous Maximum IP-Layer Capacity measurement.


7.5. Reporting the Metric
7.5. メトリックを報告する

The IP-Layer Sender Bit Rate SHALL be reported with meaningful resolution, in units of Megabits per second (which, to avoid any confusion, is 1,000,000 bits per second).


Individual IP-Layer Sender Bit Rate measurements are discussed further in Section 9.


8. Method of Measurement
8. 測定方法

It is REQUIRED per the architecture of the method that two cooperating hosts operate in the roles of Src (test packet Sender) and Dst (Receiver) with a measured path and return path between them.


The duration of a test, Parameter I, MUST be constrained in a production network, since this is an active test method and it will likely cause congestion on the path from the Src host to the Dst host during a test.


8.1. Load Rate Adjustment Algorithm
8.1. ロードレート調整アルゴリズム

The algorithm described in this section MUST NOT be used as a general Congestion Control Algorithm (CCA). As stated in Section 2 ("Scope, Goals, and Applicability"), the load rate adjustment algorithm's goal is to help determine the Maximum IP-Layer Capacity in the context of an infrequent, diagnostic, short-term measurement. There is a trade-off between test duration (also the test data volume) and algorithm aggressiveness (speed of ramp-up and ramp-down to the Maximum IP-Layer Capacity). The Parameter values chosen below strike a well-tested balance among these factors.


A table SHALL be pre-built (by the test administrator), defining all the offered load rates that will be supported (R1 through Rn, in ascending order, corresponding to indexed rows in the table). It is RECOMMENDED that rates begin with 0.5 Mbps at index zero, use 1 Mbps at index one, and then continue in 1 Mbps increments to 1 Gbps. Above 1 Gbps, and up to 10 Gbps, it is RECOMMENDED that 100 Mbps increments be used. Above 10 Gbps, increments of 1 Gbps are RECOMMENDED. A higher initial IP-Layer Sender Bit Rate might be configured when the test operator is certain that the Maximum IP-Layer Capacity is well above the initial IP-Layer Sender Bit Rate and factors such as test duration and total test traffic play an important role. The sending rate table SHOULD bracket the Maximum Capacity where it will make measurements, including constrained rates less than 500 kbps if applicable.

テーブルは(テスト管理者によって)事前に構築され、サポートされるすべての提供されたロードレート(R1からRNが昇順で、テーブル内のインデックス付き行に対応)を定義します。レートはインデックスゼロで0.5 Mbpsで始まり、インデックス1で1 Mbpsを使用してから、1 Gbpsに1 Mbpsの刻みを継続します。1 Gbps以上、最大10 Gbps、100 Mbpsの増分を使用することをお勧めします。10 Gbpsを超えると、1 Gbpsの増分が推奨されます。テストオペレータが最大のIP層の容量が初期のIP層の送信側ビットレートとテスト期間やテスト期間やトータルテストトラフィックが重要な役割を果たすような要素を確実にすると、最初のIP層の送信側のビットレートがより高いIP層の送信側ビットレートが設定されます。。送信レートテーブルには、該当する場合は500 kbps未満の制約レートなど、測定を行う最大容量を括弧で囲む必要があります。

Each rate is defined as datagrams of size ss, sent as a burst of count cc, each time interval tt (the default for tt is 100 microsec, a likely system tick interval). While it is advantageous to use datagrams of as large a size as possible, it may be prudent to use a slightly smaller maximum that allows for secondary protocol headers and/or tunneling without resulting in IP-Layer fragmentation. Selection of a new rate is indicated by a calculation on the current row, Rx. For example:


"Rx+1": The Sender uses the next-higher rate in the table.

"Rx 1":送信者はテーブル内の次の高速レートを使用します。

"Rx-10": The Sender uses the rate 10 rows lower in the table.


At the beginning of a test, the Sender begins sending at rate R1 and the Receiver starts a feedback timer of duration FT (while awaiting inbound datagrams). As datagrams are received, they are checked for sequence number anomalies (loss, out-of-order, duplication, etc.) and the delay range is measured (one-way or round-trip). This information is accumulated until the feedback timer FT expires and a status feedback message is sent from the Receiver back to the Sender, to communicate this information. The accumulated statistics are then reset by the Receiver for the next feedback interval. As feedback messages are received back at the Sender, they are evaluated to determine how to adjust the current offered load rate (Rx).


If the feedback indicates that no sequence number anomalies were detected AND the delay range was below the lower threshold, the offered load rate is increased. If congestion has not been confirmed up to this point (see below for the method for declaring congestion), the offered load rate is increased by more than one rate setting (e.g., Rx+10). This allows the offered load to quickly reach a near-maximum rate. Conversely, if congestion has been previously confirmed, the offered load rate is only increased by one (Rx+1). However, if a rate threshold above a high sending rate (such as 1 Gbps) is exceeded, the offered load rate is only increased by one (Rx+1) in any congestion state.

フィードバックがシーケンス番号異常が検出されず、遅延範囲が下限しきい値を下回っていないことを示す場合、提供された負荷率は増加します。輻輳がこの点まで確認されていない場合(輻輳を宣言する方法については下記参照)、提供されている負荷率は、複数のレート設定(例えば、RX 10)によって増加します。これにより、提供された負荷はすぐに最大最大レートに達することができます。逆に、輻輳が以前に確認された場合、提供された負荷率は1つだけ増加します(Rx 1)。ただし、高送受信速度(1Gbpsなど)を超えるレート閾値を超えると、提供された負荷率は輻輳状態で1つずつ増加します(RX 1)。

If the feedback indicates that sequence number anomalies were detected OR the delay range was above the upper threshold, the offered load rate is decreased. The RECOMMENDED threshold values are 10 for sequence number gaps and 30 msec for lower and 90 msec for upper delay thresholds, respectively. Also, if congestion is now confirmed for the first time by the current feedback message being processed, then the offered load rate is decreased by more than one rate setting (e.g., Rx-30). This one-time reduction is intended to compensate for the fast initial ramp-up. In all other cases, the offered load rate is only decreased by one (Rx-1).

フィードバックがシーケンス番号異常が検出されたか遅延範囲が上限しきい値を超えていることを示す場合、提供された負荷率は減少します。推奨さゆりの閾値は、それぞれ上限遅延しきい値については、それぞれシーケンス番号のギャップと下位および90 msecの場合は30 msecです。また、現在のフィードバックメッセージによって初めて輻輳が確認された場合、提供された負荷率は、複数のレート設定(例えば、RX-30)によって減少する。このワンタイム短縮は、高速初期ランプアップを補償することを目的としています。他のすべての場合において、提供された負荷率は1つだけ減少します(RX-1)。

If the feedback indicates that there were no sequence number anomalies AND the delay range was above the lower threshold but below the upper threshold, the offered load rate is not changed. This allows time for recent changes in the offered load rate to stabilize and for the feedback to represent current conditions more accurately.


Lastly, the method for inferring congestion is that there were sequence number anomalies AND/OR the delay range was above the upper threshold for three consecutive feedback intervals. The algorithm described above is also illustrated in Annex B of ITU-T Recommendation Y.1540, 2020 version [Y.1540] and is implemented in Appendix A ("Load Rate Adjustment Pseudocode") in this memo.


The load rate adjustment algorithm MUST include timers that stop the test when received packet streams cease unexpectedly. The timeout thresholds are provided in Table 1, along with values for all other Parameters and variables described in this section. Operations of non-obvious Parameters appear below:


load packet timeout: The load packet timeout SHALL be reset to the configured value each time a load packet is received. If the timeout expires, the Receiver SHALL be closed and no further feedback sent.


feedback message timeout: The feedback message timeout SHALL be reset to the configured value each time a feedback message is received. If the timeout expires, the Sender SHALL be closed and no further load packets sent.


     | Parameter   | Default  | Tested    | Expected Safe Range     |
     |             |          | Range or  | (not entirely tested,   |
     |             |          | Values    | other values NOT        |
     |             |          |           | RECOMMENDED)            |
     | FT,         | 50 msec  | 20 msec,  | 20 msec <= FT <= 250    |
     | feedback    |          | 50 msec,  | msec; larger values may |
     | time        |          | 100 msec  | slow the rate increase  |
     | interval    |          |           | and fail to find the    |
     |             |          |           | max                     |
     | Feedback    | L*FT,    | L=100     | 0.5 sec <= L*FT <= 30   |
     | message     | L=20 (1  | with      | sec; upper limit for    |
     | timeout     | sec with | FT=50     | very unreliable test    |
     | (stop test) | FT=50    | msec (5   | paths only              |
     |             | msec)    | sec)      |                         |
     | Load packet | 1 sec    | 5 sec     | 0.250-30 sec; upper     |
     | timeout     |          |           | limit for very          |
     | (stop test) |          |           | unreliable test paths   |
     |             |          |           | only                    |
     | Table index | 0.5 Mbps | 0.5 Mbps  | When testing <= 10 Gbps |
     | 0           |          |           |                         |
     | Table index | 1 Mbps   | 1 Mbps    | When testing <= 10 Gbps |
     | 1           |          |           |                         |
     | Table index | 1 Mbps   | 1 Mbps <= | Same as tested          |
     | (step) size |          | rate <= 1 |                         |
     |             |          | Gbps      |                         |
     | Table index | 100 Mbps | 1 Gbps <= | Same as tested          |
     | (step)      |          | rate <=   |                         |
     | size, rate  |          | 10 Gbps   |                         |
     | > 1 Gbps    |          |           |                         |
     | Table index | 1 Gbps   | Untested  | >10 Gbps                |
     | (step)      |          |           |                         |
     | size, rate  |          |           |                         |
     | > 10 Gbps   |          |           |                         |
     | ss, UDP     | None     | <=1222    | Recommend max at        |
     | payload     |          |           | largest value that      |
     | size, bytes |          |           | avoids fragmentation;   |
     |             |          |           | using a payload size    |
     |             |          |           | that is too small might |
     |             |          |           | result in unexpected    |
     |             |          |           | Sender limitations      |
     | cc, burst   | None     | 1 <= cc   | Same as tested.  Vary   |
     | count       |          | <= 100    | cc as needed to create  |
     |             |          |           | the desired maximum     |
     |             |          |           | sending rate.  Sender   |
     |             |          |           | buffer size may limit   |
     |             |          |           | cc in the               |
     |             |          |           | implementation          |
     | tt, burst   | 100      | 100       | Available range of      |
     | interval    | microsec | microsec, | "tick" values (HZ       |
     |             |          | 1 msec    | param)                  |
     | Low delay   | 30 msec  | 5 msec,   | Same as tested          |
     | range       |          | 30 msec   |                         |
     | threshold   |          |           |                         |
     | High delay  | 90 msec  | 10 msec,  | Same as tested          |
     | range       |          | 90 msec   |                         |
     | threshold   |          |           |                         |
     | Sequence    | 10       | 0, 1, 5,  | Same as tested          |
     | error       |          | 10, 100   |                         |
     | threshold   |          |           |                         |
     | Consecutive | 3        | 2, 3, 4,  | Use values >1 to avoid  |
     | errored     |          | 5         | misinterpreting         |
     | status      |          |           | transient loss          |
     | report      |          |           |                         |
     | threshold   |          |           |                         |
     | Fast mode   | 10       | 10        | 2 <= steps <= 30        |
     | increase,   |          |           |                         |
     | in table    |          |           |                         |
     | index steps |          |           |                         |
     | Fast mode   | 3 * Fast | 3 * Fast  | Same as tested          |
     | decrease,   | mode     | mode      |                         |
     | in table    | increase | increase  |                         |
     | index steps |          |           |                         |

Table 1: Parameters for Load Rate Adjustment Algorithm


As a consequence of default parameterization, the Number of table steps in total for rates less than 10 Gbps is 1090 (excluding index 0).

デフォルトのパラメータ化の結果として、10 Gbps未満のレートの合計のテーブルステップ数は1090(インデックス0を除く)です。

A related Sender backoff response to network conditions occurs when one or more status feedback messages fail to arrive at the Sender.


If no status feedback messages arrive at the Sender for the interval greater than the Lost Status Backoff timeout:


              UDRT + (2+w)*FT = Lost Status Backoff timeout



      UDRT = upper delay range threshold (default 90 msec)
      FT   = feedback time interval (default 50 msec)
      w    = number of repeated timeouts (w=0 initially, w++ on each
             timeout, and reset to 0 when a message is received)

Beginning when the last message (of any type) was successfully received at the Sender:


The offered load SHALL then be decreased, following the same process as when the feedback indicates the presence of one or more sequence number anomalies OR the delay range was above the upper threshold (as described above), with the same load rate adjustment algorithm variables in their current state. This means that lost status feedback messages OR sequence errors OR delay variation can result in rate reduction and congestion confirmation.


The RECOMMENDED initial value for w is 0, taking a Round-Trip Time (RTT) of less than FT into account. A test with an RTT longer than FT is a valid reason to increase the initial value of w appropriately. Variable w SHALL be incremented by one whenever the Lost Status Backoff timeout is exceeded. So, with FT = 50 msec and UDRT = 90 msec, a status feedback message loss would be declared at 190 msec following a successful message, again at 50 msec after that (240 msec total), and so on.

Wの推奨初期値は0で、FTよりも小さい往復時間(RTT)を考慮しています。FTよりも長いRTTのテストは、Wの初期値を適切に増やす有効な理由です。変数Wは、失われたステータスバックオフタイムアウトを超えたときに1つずつ増加させるものとします。そのため、FT = 50 MSECとUDRT = 90 msecでは、その後、メッセージが成功した後、メッセージが成功した後の190ミリ秒で、その後50ミリ秒で宣言されます(合計240ミリ秒)。

Also, if congestion is now confirmed for the first time by a Lost Status Backoff timeout, then the offered load rate is decreased by more than one rate setting (e.g., Rx-30). This one-time reduction is intended to compensate for the fast initial ramp-up. In all other cases, the offered load rate is only decreased by one (Rx-1).


Appendix B discusses compliance with the applicable mandatory requirements of [RFC8085], consistent with the goals of the IP-Layer Capacity Metric and Method, including the load rate adjustment algorithm described in this section.


8.2. Measurement Qualification or Verification
8.2. 測定資格または検証

It is of course necessary to calibrate the equipment performing the IP-Layer Capacity measurement, to ensure that the expected capacity can be measured accurately and that equipment choices (processing speed, interface bandwidth, etc.) are suitably matched to the measurement range.


When assessing a maximum rate as the metric specifies, artificially high (optimistic) values might be measured until some buffer on the path is filled. Other causes include bursts of back-to-back packets with idle intervals delivered by a path, while the measurement interval (dt) is small and aligned with the bursts. The artificial values might result in an unsustainable Maximum Capacity observed when the Method of Measurement is searching for the maximum, and that would not do. This situation is different from the bimodal service rates (discussed in "Reporting the Metric", Section 6.6), which are characterized by a multi-second duration (much longer than the measured RTT) and repeatable behavior.


There are many ways that the Method of Measurement could handle this false-max issue. The default value for measurement of Singletons (dt = 1 second) has proven to be of practical value during tests of this method, allows the bimodal service rates to be characterized, and has an obvious alignment with the reporting units (Mbps).

測定方法がこの偽の最大の問題を処理できる方法はたくさんあります。シングルトンの測定値(DT = 1秒)は、この方法の試験中に実用的な値であることが証明されており、二峰性のサービス率を特徴付けることができ、報告単位(MBP)と明らかな整列を有する。

Another approach comes from Section 24 of [RFC2544] and its discussion of trial duration, where relatively short trials conducted as part of the search are followed by longer trials to make the final determination. In the production network, measurements of Singletons and Samples (the terms for trials and tests of Lab Benchmarking) must be limited in duration because they may affect service. But there is sufficient value in repeating a Sample with a fixed sending rate determined by the previous search for the Maximum IP-Layer Capacity, to qualify the result in terms of the other performance metrics measured at the same time.


A Qualification measurement for the search result is a subsequent measurement, sending at a fixed 99.x percent of the Maximum IP-Layer Capacity for I, or an indefinite period. The same Maximum Capacity Metric is applied, and the Qualification for the result is a Sample without supra-threshold packet losses or a growing minimum delay trend in subsequent Singletons (or each dt of the measurement interval, I). Samples exhibiting supra-threshold packet losses or increasing queue occupation require a repeated search and/or test at a reduced fixed Sender rate for Qualification.

検索結果の認定測定はその後の測定値であり、iの最大IP層容量の固定99 xパーセント、または不定期間で送信する。同じ最大容量メトリックが適用され、結果の認定は上記のパケット損失なしのサンプルまたはその後のシングルトン(または測定間隔の各DT)における最小遅延傾向の増大を示している。上記しきい値パケット損失を示すサンプルまたは待ち行列職業の増加には、修正のために修正された送信者率の低下での繰り返し検索および/またはテストが必要である。

Here, as with any Active Capacity test, the test duration must be kept short. Ten-second tests for each direction of transmission are common today. The default measurement interval specified here is I = 10 seconds. The combination of a fast and congestion-aware search method and user-network coordination makes a unique contribution to production testing. The Maximum IP Capacity Metric and Method for assessing performance is very different from the classic Throughput Metric and Methods provided in [RFC2544]: it uses near-real-time load adjustments that are sensitive to loss and delay, similar to other congestion control algorithms used on the Internet every day, along with limited duration. On the other hand, Throughput measurements [RFC2544] can produce sustained overload conditions for extended periods of time. Individual trials in a test governed by a binary search can last 60 seconds for each step, and the final confirmation trial may be even longer. This is very different from "normal" traffic levels, but overload conditions are not a concern in the isolated test environment. The concerns raised in [RFC6815] were that the methods discussed in [RFC2544] would be let loose on production networks, and instead the authors challenged the standards community to develop Metrics and Methods like those described in this memo.

ここで、任意の能動容量テストと同様に、テスト期間を短く保つ必要があります。今日の伝送方向のテスト10秒のテストは一般的です。ここで指定されているデフォルトの測定間隔は、i = 10秒です。迅速かつ輻輳対応検索方法とユーザーネットワーク調整の組み合わせは、生産テストに独自の貢献をします。パフォーマンスを評価するための最大IP容量メトリックとメソッドは、[RFC2544]で提供されている古典的なスループットメトリックとメソッドとは非常に異なります。使用されている他の輻輳制御アルゴリズムと同様に、損失と遅延に敏感なほぼリアルタイム負荷調整を使用します。毎日インターネット上で、限られた期間とともに。一方、スループット測定[RFC2544]は、長期間にわたって持続的な過負荷条件を生成することができる。バイナリ検索によって支配されたテストにおける個々の試験は各ステップに対して60秒続くことができ、最終確認試験はさらに長くなる可能性があります。これは「通常の」トラフィックレベルとは非常に異なりますが、過負荷状態は絶縁テスト環境では懸念されません。 [RFC6815]で提起された懸念は、[RFC2544]で議論された方法は生産ネットワーク上で緩和され、代わりに執筆者がこのメモに記載されているようなメトリックや方法を開発するために標準コミュニティに挑戦しました。

8.3. Measurement Considerations
8.3. 測定に関する考慮事項

In general, the widespread measurements that this memo encourages will encounter widespread behaviors. The bimodal IP Capacity behaviors already discussed in Section 6.6 are good examples.


In general, it is RECOMMENDED to locate test endpoints as close to the intended measured link(s) as practical (for reasons of scale, this is not always possible; there is a limit on the number of test endpoints coming from many perspectives -- for example, management and measurement traffic). The testing operator MUST set a value for the MaxHops Parameter, based on the expected path length. This Parameter can keep measurement traffic from straying too far beyond the intended path.

一般に、テストエンドポイントを実用的なものとして(スケールの理由から、必ずしも可能ではありません。多くの観点からのテストエンドポイント数に制限があります。 - たとえば、管理と測定トラフィックなどです。テスト演算子は、予想されるパス長に基づいてmaxhopsパラメータの値を設定する必要があります。このパラメータは、測定トラフィックが意図された経路を超えて迷い過ぎるのを防ぐことができます。

The measured path may be stateful based on many factors, and the Parameter "Time of day" when a test starts may not be enough information. Repeatable testing may require knowledge of the time from the beginning of a measured flow -- and how the flow is constructed, including how much traffic has already been sent on that flow when a state change is observed -- because the state change may be based on time, bytes sent, or both. Both load packets and status feedback messages MUST contain sequence numbers; this helps with measurements based on those packets.


Many different types of traffic shapers and on-demand communications access technologies may be encountered, as anticipated in [RFC7312], and play a key role in measurement results. Methods MUST be prepared to provide a short preamble transmission to activate on-demand communications access and to discard the preamble from subsequent test results.


The following conditions might be encountered during measurement, where packet losses may occur independently of the measurement sending rate:


1. Congestion of an interconnection or backbone interface may appear as packet losses distributed over time in the test stream, due to much-higher-rate interfaces in the backbone.

1. 相互接続またはバックボーンインタフェースの輻輳は、バックボーン内のより高いレートのインターフェイスのために、テストストリーム内で経時的に分散されたパケット損失として現れることがあります。

2. Packet loss due to the use of Random Early Detection (RED) or other active queue management may or may not affect the measurement flow if competing background traffic (other flows) is simultaneously present.

2. ランダム早期検出(RED)または他のアクティブなキュー管理の使用によるパケット損失競合するバックグラウンドトラフィック(他のフロー)が同時に存在する場合、測定フローに影響しない場合があります。

3. There may be only a small delay variation independent of the sending rate under these conditions as well.

3. これらの条件下での送信レートとは無関係にわずかな遅延変動しかないかもしれません。

4. Persistent competing traffic on measurement paths that include shared transmission media may cause random packet losses in the test stream.

4. 共有伝送媒体を含む測定経路上の永続的な競合トラフィックは、テストストリーム内でランダムなパケット損失を引き起こす可能性があります。

It is possible to mitigate these conditions using the flexibility of the load rate adjustment algorithm described in Section 8.1 above (tuning specific Parameters).


If the measurement flow burst duration happens to be on the order of or smaller than the burst size of a shaper or a policer in the path, then the line rate might be measured rather than the bandwidth limit imposed by the shaper or policer. If this condition is suspected, alternate configurations SHOULD be used.


In general, results depend on the sending stream's characteristics; the measurement community has known this for a long time and needs to keep it foremost in mind. Although the default is a single flow (F=1) for testing, the use of multiple flows may be advantageous for the following reasons:

一般に、結果は送信ストリームの特性によって異なります。測定コミュニティは長い間これを知っており、それを最も重要に保つ必要があります。デフォルトはテストのための単一のフロー(f = 1)ですが、複数のフローを使用すると、次のような理由で有利であり得る。

1. The test hosts may be able to create a higher load than with a single flow, or parallel test hosts may be used to generate one flow each.

1. テストホストは、単一のフローよりも高い負荷を生み出すことができ、または並列テストホストを使用してそれぞれ1つのフローを生成することができる。

2. Link aggregation may be present (flow-based load balancing), and multiple flows are needed to occupy each member of the aggregate.

2. リンクアグリゲーションが存在してもよい(フローベースの負荷分散)、集計の各メンバーを占有するために複数のフローが必要です。

3. Internet access policies may limit the IP-Layer Capacity depending on the Type-P of the packets, possibly reserving capacity for various stream types.

3. インターネットアクセスポリシーは、パケットのType-Pに応じてIP層容量を制限することができます。

Each flow would be controlled using its own implementation of the load rate adjustment (search) algorithm.


It is obviously counterproductive to run more than one independent and concurrent test (regardless of the number of flows in the test stream) attempting to measure the *maximum* capacity on a single path. The number of concurrent, independent tests of a path SHALL be limited to one.


Tests of a v4-v6 transition mechanism might well be the intended subject of a capacity test. As long as both IPv4 packets and IPv6 packets sent/received are standard-formed, this should be allowed (and the change in header size easily accounted for on a per-packet basis).

V4 - V6遷移機構の試験は、容量試験の意図された主題であるかもしれない。送信送受信されたIPv4パケットとIPv6パケットの両方が標準的に形成されている限り、これは許可されるべきです(そして、ヘッダーサイズの変更はパケットごとに会計処理されやすい)。

As testing continues, implementers should expect the methods to evolve. The ITU-T has published a supplement (Supplement 60) to the Y-series of ITU-T Recommendations, "Interpreting ITU-T Y.1540 maximum IP-layer capacity measurements" [Y.Sup60], which is the result of continued testing with the metric. Those results have improved the methods described here.


9. Reporting Formats
9. レポートフォーマット

The Singleton IP-Layer Capacity results SHOULD be accompanied by the context under which they were measured.


* Timestamp (especially the time when the maximum was observed in dtn).

* タイムスタンプ(特に最大値がDTNで観察された時期)。

* Source and Destination (by IP or other meaningful ID).

* 送信元と宛先(IPまたはその他の意味のあるIDによって)。

* Other inner Parameters of the test case (Section 4).

* テストケースの他の内部パラメータ(セクション4)。

* Outer Parameters, such as "test conducted in motion" or other factors belonging to the context of the measurement.

* 「動きで行われた試験」や測定の文脈に属するその他の要因などの外部パラメータ。

* Result validity (indicating cases where the process was somehow interrupted or the attempt failed).

* 結果の有効性(プロセスがどういうわけか中断された場合、または失敗した場合を示す)。

* A field where unusual circumstances could be documented, and another one for "ignore / mask out" purposes in further processing.

* 異常な状況が文書化されているフィールド、さらには別の処理で「無視/マスク」のためのもの。

The Maximum IP-Layer Capacity results SHOULD be reported in tabular format. There SHOULD be a column that identifies the test Phase. There SHOULD be a column listing the number of flows used in that Phase. The remaining columns SHOULD report the following results for the aggregate of all flows, including the Maximum IP-Layer Capacity, the Loss Ratio, the RTT minimum, RTT maximum, and other metrics tested having similar relevance.


As mentioned in Section 6.6, bimodal (or multi-modal) maxima SHALL be reported for each mode separately.


   | Phase  | Number   | Maximum IP-Layer | Loss   | RTT min | RTT     |
   |        | of Flows | Capacity (Mbps)  | Ratio  | (msec)  | max     |
   |        |          |                  |        |         | (msec)  |
   | Search | 1        | 967.31           | 0.0002 | 30      | 58      |
   | Verify | 1        | 966.00           | 0.0000 | 30      | 38      |

Table 2: Maximum IP-Layer Capacity Results


Static and configuration Parameters:


The sub-interval time, dt, MUST accompany a report of Maximum IP-Layer Capacity results, as well as the remaining Parameters from Section 4 ("General Parameters and Definitions").


The PM list metrics corresponding to the sub-interval where the Maximum Capacity occurred MUST accompany a report of Maximum IP-Layer Capacity results, for each test Phase.


The IP-Layer Sender Bit Rate results SHOULD be reported in tabular format. There SHOULD be a column that identifies the test Phase. There SHOULD be a column listing each individual (numbered) flow used in that Phase, or the aggregate of flows in that Phase. A corresponding column SHOULD identify the specific sending rate sub-interval, stn, for each flow and aggregate. A final column SHOULD report the IP-Layer Sender Bit Rate results for each flow used, or the aggregate of all flows.


      | Phase  | Flow Number or Aggregate | stn (sec) | Sender Bit  |
      |        |                          |           | Rate (Mbps) |
      | Search | 1                        | 0.00      | 345         |
      | Search | 2                        | 0.00      | 289         |
      | Search | Agg                      | 0.00      | 634         |
      | Search | 1                        | 0.05      | 499         |
      | Search | ...                      | 0.05      | ...         |

Table 3: IP-Layer Sender Bit Rate Results (Example with Two Flows and st = 0.05 (sec))

表3:IP層の送信者のビットレートの結果(2つのフローを持つ例とST = 0.05(秒))

Static and configuration Parameters:


The sub-interval duration, st, MUST accompany a report of Sender IP-Layer Bit Rate results.


Also, the values of the remaining Parameters from Section 4 ("General Parameters and Definitions") MUST be reported.


9.1. Configuration and Reporting Data Formats
9.1. 構成とレポートデータフォーマット

As a part of the multi-Standards Development Organization (SDO) harmonization of this Metric and Method of Measurement, one of the areas where the Broadband Forum (BBF) contributed its expertise was in the definition of an information model and data model for configuration and reporting. These models are consistent with the metric Parameters and default values specified as lists in this memo. [TR-471] provides the information model that was used to prepare a full data model in related BBF work. The BBF has also carefully considered topics within its purview, such as the placement of measurement systems within the Internet access architecture. For example, timestamp resolution requirements that influence the choice of the test protocol are provided in Table 2 of [TR-471].


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

Active Metrics and Active Measurements have a long history of security considerations. The security considerations that apply to any Active Measurement of live paths are relevant here. See [RFC4656] and [RFC5357].


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


There are some new considerations for Capacity measurement as described in this memo.


1. Cooperating Source and Destination hosts and agreements to test the path between the hosts are REQUIRED. Hosts perform in either the Src role or the Dst role.

1. ホスト間の経路をテストするための協力したソースおよび宛先のホストおよび契約が必要です。ホストはSRCロールまたはDSTロールのいずれかで実行します。

2. It is REQUIRED to have a user client-initiated setup handshake between cooperating hosts that allows firewalls to control inbound unsolicited UDP traffic that goes to either a control port (expected and with authentication) or ephemeral ports that are only created as needed. Firewalls protecting each host can both continue to do their job normally.

2. ファイアウォールがコントロールポート(予想され、認証と認証とともに)または必要に応じて作成されるエフェメラルポートのどちらにもかかわらず、協力していないホスト間でユーザークライアント開始されたセットアップハンドシェイクを使用する必要があります。各ホストを保護するファイアウォールは、どちらも正常に仕事をし続けることができます。

3. Client-server authentication and integrity protection for feedback messages conveying measurements are RECOMMENDED.

3. フィードバックメッセージのクライアント - サーバ認証と整合性保護測定を推奨します。

4. Hosts MUST limit the number of simultaneous tests to avoid resource exhaustion and inaccurate results.

4. ホストは、資源の枯渇や不正確な結果を回避するために同時テストの数を制限する必要があります。

5. Senders MUST be rate limited. This can be accomplished using a pre-built table defining all the offered load rates that will be supported (Section 8.1). The recommended load control search algorithm results in "ramp-up" from the lowest rate in the table.

5. 送信者はRate Limitedでなければなりません。これは、サポートされるすべての提供されたロードレートを定義する事前構築テーブルを使用して実行できます(セクション8.1)。推奨されるロードコントロール検索アルゴリズムは、テーブル内の最低レートから「ランプアップ」をもたらします。

6. Service subscribers with limited data volumes who conduct extensive capacity testing might experience the effects of Service Provider controls on their service. Testing with the Service Provider's measurement hosts SHOULD be limited in frequency and/or overall volume of test traffic (for example, the range of duration values, I, SHOULD be limited).

6. 広範囲の容量テストを実施する限られたデータボリュームを持つサービス加入者は、サービスプロバイダコントロールの影響を自分のサービスに発生する可能性があります。サービスプロバイダの測定ホストを使用したテストは、テストトラフィックの周波数および/または全体的なボリュームで制限されるべきです(たとえば、持続時間値の範囲は制限されるべきです)。

The exact specification of these features is left for future protocol development.


11. IANA Considerations
11. IANAの考慮事項

This document has no IANA actions.


12. References
12. 参考文献
12.1. Normative References
12.1. 引用文献

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

[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<>。

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

[RFC2330] Paxson、V.、Almes、G.、MAHDAVI、J.、およびM Mathis、「IPパフォーマンスメトリックのためのフレームワーク」、RFC 2330、DOI 10.17487 / RFC2330、1998年5月、<>。

[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, <>.

[RFC2681] Almes、G.、KalidIndi、S.、およびM.Zekauskas、「IPPMの往復遅延測定基準」、RFC 2681、DOI 10.17487 / RFC2681、1999年9月、<https://www.rfc-編集者.ORG / INFO / RFC2681>。

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

[RFC4656] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J.、およびM.Zekauskas、「一方向アクティブ測定プロトコル(OWAMP)」、RFC 4656、DOI 10.17487 / RFC4656、9月2006年、<>。

[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 10.17487/RFC4737, November 2006, <>.

[RFC4737]モートン、A。、CIAVATTONE、L.、Ramachandran、G.、Shalunov、S.、およびJ. Perser、「パケット並べ替えメトリック」、RFC 4737、DOI 10.17487 / RFC4737、2006年11月、<>。

[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, <>.

[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K.、およびJ.Babiarz、「双方向アクティブ測定プロトコル(Twamp)」、RFC 5357、DOI 10.17487 / RFC5357、10月2008年、<>。

[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, <>.

[RFC6438] Carpenter、B.およびS. Amante、「トンネルの等価マルチパスルーティングのためのIPv6フローラベルの使用」、RFC 6438、DOI 10.17487 / RFC6438、2011年11月、<>。

[RFC7497] Morton, A., "Rate Measurement Test Protocol Problem Statement and Requirements", RFC 7497, DOI 10.17487/RFC7497, April 2015, <>.

[RFC7497]モートン、A。、「レート測定テストプロトコル問題ステートメントおよび要件」、RFC 7497、DOI 10.17487 / RFC7497、2015年4月、<>。

[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, <>.

[RFC7680] Almes、G.、Kiristindi、S.、Zekauskas、M.、およびA.モートン、「IPパフォーマンス測定基準(IPPM)の一方向損失メトリック(IPPM)」、STD 82、RFC 7680、DOI 10.17487/ RFC7680、2016年1月、<>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <>.

[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<>。

[RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework", RFC 8468, DOI 10.17487/RFC8468, November 2018, <>.

[RFC8468]モートン、A.、Fabini、J.、Elkins、N.、Ackermann、M.、V.HEGDE、「IPv4、IPv6、およびIPv4-IPv6共存:IP Performance Metrics(IPPM)フレームワークの更新」、RFC 8468、DOI 10.17487 / RFC8468、2018年11月、<>。

12.2. Informative References
12.2. 参考引用

[copycat] Edeline, K., Kühlewind, M., Trammell, B., and B. Donnet, "copycat: Testing Differential Treatment of New Transport Protocols in the Wild", ANRW '17, DOI 10.1145/3106328.3106330, July 2017, <>.

[CopyCat] Edeline、K.、Kühlewind、M.、Trammell、B.、およびB. Donnet、「Copycat:野生の新輸送プロトコルの鑑別治療のテスト」、ANRW '17、DOI 10.1145 / 3106328.3106330、2017年7月、<>。

[LS-SG12-A] "Liaison statement: LS - Harmonization of IP Capacity and Latency Parameters: Revision of Draft Rec. Y.1540 on IP packet transfer performance parameters and New Annex A with Lab Evaluation Plan", From ITU-T SG 12, March 2019, <>.

[LS-SG12-A] "LIAISONステートメント:IP容量と待ち時間の調和:ドラフトRECのリビジョン。ITU-T SGから、IPパケット転送性能パラメータと新たな附属書AのY.15402019年3月12日、<>。

[LS-SG12-B] "Liaison statement: LS on harmonization of IP Capacity and Latency Parameters: Consent of Draft Rec. Y.1540 on IP packet transfer performance parameters and New Annex A with Lab & Field Evaluation Plans", From ITU-T-SG-12, May 2019, <>.

[LS-SG12-B] "Liaisonステートメント:IP容量と待ち時間の調和のためのLS描画録画の同意:ITUからのIPパケット転送性能パラメータと新たな附属書AのY.1540T-SG-12、2019年5月、<>。

[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, <>.

[RFC2544] Bradner、S.およびJ.Cquaid、「ネットワークインターコネクトデバイスのベンチマーク方法」、RFC 2544、DOI 10.17487 / RFC2544、1999年3月、<>。

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

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

[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, DOI 10.17487/RFC5136, February 2008, <>.

[RFC5136] Chimento、P.およびJ.ISHAC、「ネットワーク容量の定義」、RFC 5136、DOI 10.17487 / RFC5136、2008年2月、<>。

[RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton, "Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful", RFC 6815, DOI 10.17487/RFC6815, November 2012, <>.

[RFC6815] Bradner、S.、Dubray、K.、McQuaid、J.、およびA. Morton、「RFC 2544の適用性声明:有害な生産ネットワークの使用」、RFC 6815、DOI 10.17487 / RFC6815、2012年11月、<>。

[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, DOI 10.17487/RFC7312, August 2014, <>.

[RFC7312] Fabini、J.およびA.モートン、「IPパフォーマンス測定基準(IPPM)」、RFC 7312、DOI 10.17487 / RFC7312、2014年8月、< Info / RFC7312>。

[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, <>.

[RFC7594]イヤーディリー、P.、Morton、A。、Bagnulo、M.、Burbridge、T.、Aitken、P.、A. AKHTER、「ブロードバンド性能の大規模測定のためのフレームワーク(LMAP)」、RFC7594、DOI 10.17487 / RFC7594、2015年9月、<>。

[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <>.

[RFC7799]モートン、A。、「能動的および受動的な測定基準と方法(インス間のハイブリッド型(ハイブリッドタイプおよびメソッド)、RFC 7799、DOI 10.17487 / RFC7799、2016年5月、< RFC7799>。

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <>.

[RFC8085] eggert、L.、Fairhurst、G.、G.Shepherd、 "UDP使用ガイドライン"、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、< info / rfc8085>。

[RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March 2018, <>.

[RFC8337] Mathis、M.およびA.モートン、「バルク輸送能力のためのモデルベースの測定基準」、RFC 8337、DOI 10.17487 / RFC8337、2018年3月、<>。

[TR-471] Morton, A., "Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements", Broadband Forum TR-471, July 2020, < TR-471.pdf>.

[TR-471]モートン、A。、「最大IP層容量メトリック、関連メトリック、および測定」、ブロードバンドフォーラムTR-471、< TR-471.pdf>。

[Y.1540] ITU-T, "Internet protocol data communication service - IP packet transfer and availability performance parameters", ITU-T Recommendation Y.1540, December 2019, <>.

[Y.1540] ITU-T、「インターネットプロトコルデータ通信サービス - IPパケット転送と可用性性能パラメータ」、ITU-T勧告Y.1540、2019年12月、< / E>。

[Y.Sup60] ITU-T, "Interpreting ITU-T Y.1540 maximum IP-layer capacity measurements", ITU-T Recommendation Y.Sup60, October 2021, <>.

[Y SOU 6] ITU-T、「ITU-T Y.1540の最大IP層容量測定」、ITU-T勧告Y SUU60、2021年10月、< S60 / en>。

Appendix A. Load Rate Adjustment Pseudocode

This appendix provides a pseudocode implementation of the algorithm described in Section 8.1.


Rx = 0 # The current sending rate (equivalent to a row # of the table)

Rx = 0#現在の送信レート(表の行番号に相当)

seqErr = 0 # Measured count that includes Loss or Reordering # or Duplication impairments (all appear # initially as errors in the packet sequence # numbering)

seqerr = 0#測定された数、または並べ替え障害または重複障害を含む測定数(全ては、最初はパケットシーケンス#番号付けのエラーとして)

seqErrThresh = 10 # Threshold on seqErr count that includes Loss or # Reordering or Duplication impairments (all # appear initially as errors in the packet # sequence numbering)

Seqerrthresh = 10#しきい値の損失または並べ替えまたは重複障害を含むSEQERR数のスレッショルド(ALL#が最初にパケット#シーケンス番号付けのエラーとして現れる)

delay = 0 # Measured Range of Round Trip Delay (RTD), msec

DELAY = 0#測定範囲の往復遅延(RTD)、MSEC

lowThresh = 30 # Low threshold on the Range of RTD, msec


upperThresh = 90 # Upper threshold on the Range of RTD, msec

RTD、MSECの範囲のUSPTHRESH = 90#上限しきい値

hSpeedThresh = 1 # Threshold for transition between sending rate # step sizes (such as 1 Mbps and 100 Mbps), Gbps

HSPEEDTHRESH = 1#送信速度#ステップサイズ(1 Mbps、100 Mbpsなど)の遷移のしきい値、Gbps

   slowAdjCount = 0    # Measured Number of consecutive status reports
                       # indicating loss and/or delay variation above
                       # upperThresh

slowAdjThresh = 3 # Threshold on slowAdjCount used to infer # congestion. Use values > 1 to avoid # misinterpreting transient loss.

SlowAdjthresh = 3#しきい値#輻輳を推測するために使用されるSlowAdjcountのしきい値。値を避けるために値> 1を使用して過渡損失を解釈します。

highSpeedDelta = 10 # The number of rows to move in a single # adjustment when initially increasing offered # load (to ramp up quickly)

HighSpeedDelta = 10#最初に提供された#負荷(素早く立ち上げるために)

maxLoadRates = 2000 # Maximum table index (rows)

MAXLOADRATES = 2000#最大テーブルインデックス(行)

   if ( seqErr <= seqErrThresh && delay < lowThresh ) {
           if ( Rx < hSpeedThresh && slowAdjCount < slowAdjThresh ) {
                           Rx += highSpeedDelta;
                           slowAdjCount = 0;
           } else {
                           if ( Rx < maxLoadRates - 1 )
   } else if ( seqErr > seqErrThresh || delay > upperThresh ) {
           if ( Rx < hSpeedThresh && slowAdjCount == slowAdjThresh ) {
                           if ( Rx > highSpeedDelta * 3 )
                                           Rx -= highSpeedDelta * 3;
                                           Rx = 0;
           } else {
                           if ( Rx > 0 )
Appendix B. RFC 8085 UDP Guidelines Check
付録B. RFC 8085 UDPガイドラインチェック

Section 3.1 of [RFC8085] (BCP 145), which provides UDP usage guidelines, focuses primarily on congestion control. The guidelines appear in mandatory (MUST) and recommendation (SHOULD) categories.

UDP使用上のガイドラインを提供する[RFC8085](BCP 145)のセクション3.1は、主に輻輳制御に焦点を当てています。ガイドラインは必須(必須)と推奨(必要とされている)カテゴリに表示されます。

B.1. Assessment of Mandatory Requirements
B.1. 必須要件の評価

The mandatory requirements in Section 3 of [RFC8085] include the following:


   |  Internet paths can have widely varying characteristics, ...
   |  Consequently, applications that may be used on the Internet MUST
   |  NOT make assumptions about specific path characteristics.  They
   |  MUST instead use mechanisms that let them operate safely under
   |  very different path conditions.  Typically, this requires
   |  conservatively probing the current conditions of the Internet path
   |  they communicate over to establish a transmission behavior that it
   |  can sustain and that is reasonably fair to other traffic sharing
   |  the path.

The purpose of the load rate adjustment algorithm described in Section 8.1 is to probe the network and enable Maximum IP-Layer Capacity measurements with as few assumptions about the measured path as possible and within the range of applications described in Section 2. There is tension between the goals of probing conservatism and minimization of both the traffic dedicated to testing (especially with Gigabit rate measurements) and the duration of the test (which is one contributing factor to the overall algorithm fairness).


The text of Section 3 of [RFC8085] goes on to recommend alternatives to UDP to meet the mandatory requirements, but none are suitable for the scope and purpose of the Metrics and Methods in this memo. In fact, ad hoc TCP-based methods fail to achieve the measurement accuracy repeatedly proven in comparison measurements with the running code [LS-SG12-A] [LS-SG12-B] [Y.Sup60]. Also, the UDP aspect of these methods is present primarily to support modern Internet transmission where a transport protocol is required [copycat]; the metric is based on the IP Layer, and UDP allows simple correlation to the IP Layer.

[RFC8085]のセクション3のテキストは、必須要件を満たすためにUDPに代替案を推奨しますが、このメモのメトリックとメソッドの目的には適していません。実際、AD HOC TCPベースの方法は、実行コード[LS-SG12-A] [LS-SG12-B] [Y 60]を用いて比較測定で繰り返し実証された測定精度を達成できない。また、これらの方法のUDPの側面は、主にトランスポートプロトコルが必要な現代のインターネット伝送をサポートするためのものです[CopyCat];メトリックはIP層に基づいており、UDPはIP層への単純な相関を許可します。

Section 3.1.1 of [RFC8085] discusses protocol timer guidelines:


   |  Latency samples MUST NOT be derived from ambiguous transactions.
   |  The canonical example is in a protocol that retransmits data, but
   |  subsequently cannot determine which copy is being acknowledged.

Both load packets and status feedback messages MUST contain sequence numbers; this helps with measurements based on those packets, and there are no retransmissions needed.


   |  When a latency estimate is used to arm a timer that provides loss
   |  detection -- with or without retransmission -- expiry of the timer
   |  MUST be interpreted as an indication of congestion in the network,
   |  causing the sending rate to be adapted to a safe conservative rate
   |  ...

The methods described in this memo use timers for sending rate backoff when status feedback messages are lost (Lost Status Backoff timeout) and for stopping a test when connectivity is lost for a longer interval (feedback message or load packet timeouts).


This memo does not foresee any specific benefit of using Explicit Congestion Notification (ECN).


Section 3.2 of [RFC8085] discusses message size guidelines:


   |  To determine an appropriate UDP payload size, applications MUST
   |  subtract the size of the IP header (which includes any IPv4
   |  optional headers or IPv6 extension headers) as well as the length
   |  of the UDP header (8 bytes) from the PMTU size.

The method uses a sending rate table with a maximum UDP payload size that anticipates significant header overhead and avoids fragmentation.


Section 3.3 of [RFC8085] provides reliability guidelines:


| Applications that do require reliable message delivery MUST | implement an appropriate mechanism themselves.

| ..信頼できるメッセージ配信を必要とするアプリケーション|適切なメカニズムを自分自身に実装します。

The IP-Layer Capacity Metrics and Methods do not require reliable delivery.


| Applications that require ordered delivery MUST reestablish | datagram ordering themselves.

| ..注文配信を必要とするアプリケーション| .. |データグラムは自分自身を並べる。

The IP-Layer Capacity Metrics and Methods do not need to reestablish packet order; it is preferable to measure packet reordering if it occurs [RFC4737].


B.2. Assessment of Recommendations
B.2. 勧告の評価

The load rate adjustment algorithm's goal is to determine the Maximum IP-Layer Capacity in the context of an infrequent, diagnostic, short-term measurement. This goal is a global exception to many SHOULD-level requirements as listed in [RFC8085], of which many are intended for long-lived flows that must coexist with other traffic in a more or less fair way. However, the algorithm (as specified in Section 8.1 and Appendix A above) reacts to indications of congestion in clearly defined ways.


A specific recommendation is provided as an example. Section 3.1.5 of [RFC8085] (regarding the implications of RTT and loss measurements on congestion control) says:


   |  A congestion control [algorithm] designed for UDP SHOULD respond
   |  as quickly as possible when it experiences congestion, and it
   |  SHOULD take into account both the loss rate and the response time
   |  when choosing a new rate.

The load rate adjustment algorithm responds to loss and RTT measurements with a clear and concise rate reduction when warranted, and the response makes use of direct measurements (more exact than can be inferred from TCP ACKs).

負荷率調整アルゴリズムは、保証されたときに明確かつ簡潔なレートの減少をもつ損失およびRTT測定に応答し、応答は直接測定を利用する(より正確にはTCP ACKから推測できる)。

Section 3.1.5 of [RFC8085] goes on to specify the following:


   |  The implemented congestion control scheme SHOULD result in
   |  bandwidth (capacity) use that is comparable to that of TCP within
   |  an order of magnitude, so that it does not starve other flows
   |  sharing a common bottleneck.

This is a requirement for coexistent streams, and not for diagnostic and infrequent measurements using short durations. The rate oscillations during short tests allow other packets to pass and don't starve other flows.


Ironically, ad hoc TCP-based measurements of "Internet Speed" are also designed to work around this SHOULD-level requirement, by launching many flows (9, for example) to increase the outstanding data dedicated to testing.

皮肉なことに、「インターネット速度」のAD HOC TCPベースの測定値はまた、テスト専用の未処理のデータを増やすために、多くのフローを起動することによって、このレベルの要件を回避するように設計されています。

The load rate adjustment algorithm cannot become a TCP-like congestion control, or it will have the same weaknesses of TCP when trying to make a Maximum IP-Layer Capacity measurement and will not achieve the goal. The results of the referenced testing [LS-SG12-A] [LS-SG12-B] [Y.Sup60] supported this statement hundreds of times, with comparisons to multi-connection TCP-based measurements.

負荷率調整アルゴリズムはTCPのような輻輳制御になることができないか、最大IP層容量測定を行おうとし、目標を達成しない場合はTCPの同じ弱点を持ちます。参照されたテスト[LS-SG12-A] [LS-SG12-B] [Y S-SG12-B] [Y SG 60]の結果は、マルチコネクトTCPベースの測定と比較して、このステートメントを数百回サポートしました。

A brief review of requirements from [RFC8085] follows (marked "Yes" when this memo is compliant, or "NA" (Not Applicable)):


      | Yes? | Recommendation in RFC 8085                 | Section |
      | Yes  | MUST tolerate a wide range of Internet     | 3       |
      |      | path conditions                            |         |
      | NA   | SHOULD use a full-featured transport       |         |
      |      | (e.g., TCP)                                |         |
      | Yes  | SHOULD control rate of transmission        | 3.1     |
      | NA   | SHOULD perform congestion control over all |         |
      |      | traffic                                    |         |
      |      | For bulk transfers,                        | 3.1.2   |
      | NA   | SHOULD consider implementing TFRC          |         |
      | NA   | else, SHOULD in other ways use bandwidth   |         |
      |      | similar to TCP                             |         |
      |      | For non-bulk transfers,                    | 3.1.3   |
      | NA   | SHOULD measure RTT and transmit max. 1     | 3.1.1   |
      |      | datagram/RTT                               |         |
      | NA   | else, SHOULD send at most 1 datagram every |         |
      |      | 3 seconds                                  |         |
      | NA   | SHOULD back-off retransmission timers      |         |
      |      | following loss                             |         |
      | Yes  | SHOULD provide mechanisms to regulate the  | 3.1.6   |
      |      | bursts of transmission                     |         |
      | NA   | MAY implement ECN; a specific set of       | 3.1.7   |
      |      | application mechanisms are REQUIRED if ECN |         |
      |      | is used                                    |         |
      | Yes  | For DiffServ, SHOULD NOT rely on           | 3.1.8   |
      |      | implementation of PHBs                     |         |
      | Yes  | For QoS-enabled paths, MAY choose not to   | 3.1.9   |
      |      | use CC                                     |         |
      | Yes  | SHOULD NOT rely solely on QoS for their    | 3.1.10  |
      |      | capacity                                   |         |
      | NA   | non-CC controlled flows SHOULD implement a |         |
      |      | transport circuit breaker                  |         |
      | Yes  | MAY implement a circuit breaker for other  |         |
      |      | applications                               |         |
      |      | For tunnels carrying IP traffic,           | 3.1.11  |
      | NA   | SHOULD NOT perform congestion control      |         |
      | NA   | MUST correctly process the IP ECN field    |         |
      |      | For non-IP tunnels or rate not determined  | 3.1.11  |
      |      | by traffic,                                |         |
      | NA   | SHOULD perform CC or use circuit breaker   |         |
      | NA   | SHOULD restrict types of traffic           |         |
      |      | transported by the tunnel                  |         |
      | Yes  | SHOULD NOT send datagrams that exceed the  | 3.2     |
      |      | PMTU, i.e.,                                |         |
      | Yes  | SHOULD discover PMTU or send datagrams <   |         |
      |      | minimum PMTU                               |         |
      | NA   | Specific application mechanisms are        |         |
      |      | REQUIRED if PLPMTUD is used                |         |
      | Yes  | SHOULD handle datagram loss, duplication,  | 3.3     |
      |      | reordering                                 |         |
      | NA   | SHOULD be robust to delivery delays up to  |         |
      |      | 2 minutes                                  |         |
      | Yes  | SHOULD enable IPv4 UDP checksum            | 3.4     |
      | Yes  | SHOULD enable IPv6 UDP checksum; specific  | 3.4.1   |
      |      | application mechanisms are REQUIRED if a   |         |
      |      | zero IPv6 UDP checksum is used             |         |
      | NA   | SHOULD provide protection from off-path    | 5.1     |
      |      | attacks                                    |         |
      |      | else, MAY use UDP-Lite with suitable       | 3.4.2   |
      |      | checksum coverage                          |         |
      | NA   | SHOULD NOT always send middlebox keep-     | 3.5     |
      |      | alive messages                             |         |
      | NA   | MAY use keep-alives when needed (min.      |         |
      |      | interval 15 sec)                           |         |
      | Yes  | Applications specified for use in limited  | 3.6     |
      |      | use (or controlled environments) SHOULD    |         |
      |      | identify equivalent mechanisms and         |         |
      |      | describe their use case                    |         |
      | NA   | Bulk-multicast apps SHOULD implement       | 4.1.1   |
      |      | congestion control                         |         |
      | NA   | Low volume multicast apps SHOULD implement | 4.1.2   |
      |      | congestion control                         |         |
      | NA   | Multicast apps SHOULD use a safe PMTU      | 4.2     |
      | Yes  | SHOULD avoid using multiple ports          | 5.1.2   |
      | Yes  | MUST check received IP source address      |         |
      | NA   | SHOULD validate payload in ICMP messages   | 5.2     |
      | Yes  | SHOULD use a randomized Source port or     | 6       |
      |      | equivalent technique, and, for client/     |         |
      |      | server applications, SHOULD send responses |         |
      |      | from source address matching request       |         |
      | NA   | SHOULD use standard IETF security          | 6       |
      |      | protocols when needed                      |         |

Table 4: Summary of Key Guidelines from RFC 8085

表4:RFC 8085からの主なガイドラインの概要



Thanks to Joachim Fabini, Matt Mathis, J. Ignacio Alvarez-Hamelin, Wolfgang Balzer, Frank Brockners, Greg Mirsky, Martin Duke, Murray Kucherawy, and Benjamin Kaduk for their extensive comments on this memo and related topics. In a second round of reviews, we acknowledge Magnus Westerlund, Lars Eggert, and Zaheduzzaman Sarker.

Joachim Fabini、Matt Mathis、J.Igracio Alvarez-Hamelin、Wolfgang Balzer、Frank Brocknes、Greg Mirsky、Martin Duke、Murray Kucherawy、およびBenjamin Kaduk、およびその他のメモとその関連トピックについては、Benjamin Kaduk。2番目のレビューで、マグヌスウェレンタルンド、ラーズナッテル、ザヘディュッサマンサルダーをご了承ください。

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

Rüdiger Geib Deutsche Telekom Heinrich Hertz Str. 3-7 64295 Darmstadt Germany

RüdigerGeib Deutsche Telekom Heinrich Hertz Str。3-7 64295ドイツDarmstadt.

   Phone: +49 6151 5812747

Len Ciavattone AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States of America

Len Ciavattone AT&T Labs 200 Laurel Avenue南Middletown、NJ 07748アメリカ

   Phone: +1 732 420 1239