[要約] RFC 9097は、一方向IP容量の測定に関する指標と方法を定義します。この文書の目的は、ネットワークの性能評価と診断を改善するための標準化された手法を提供することです。主に、ネットワーク計画、トラフィック管理、品質保証の場面で利用されます。
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
一方向IP容量のための測定基準と方法
Abstract
概要
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 https://www.rfc-editor.org/info/rfc9097.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9097で入手できます。
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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. Scope, 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
Acknowledgments
Authors' Addresses
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].
付録Aは、擬似コードを使用した負荷率調整アルゴリズムを説明しています。付録Bは、[RFC8085]のアルゴリズムの準拠を説明しています。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
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.
このメモの範囲は、最大IP層容量と有用なセカンダリメトリクスと有用なセカンダリメトリックを明確に決定するための能動的測定メトリックと対応する方法を定義することです。
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).
もう1つの目標は、業界全体で指定されたメトリックと方法を調和させることであり、このメモはIETFコンセンサスをキャプチャする車であり、他の規格開発組織（SDO）の仕様（各SDOの通常の貢献プロセスを通じて、または連絡を通じて）の変更を引き起こす車両です。両替）。
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.
負荷率調整アルゴリズムの範囲は、頻度のない、診断的、短期間の測定値の中で最大IP層容量を決定するのに役立ちます。テスト中に加入者の専用リソースを共有する非測定トラフィックを中止することをお勧めします。測定は正確ではない可能性があり、競合する弾性トラフィックのスループットを大幅に削減することができます。
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:
ここに記載されている測定基準の主な適用および測定方法は、[RFC7497]のセクション2で説明されているものと同じです。
| 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:
さらに、セクション8.1に記載されている負荷速度調整アルゴリズムの使用には、以下の追加の適用の制限があります。
* 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.
最後に、測定システムの負荷速度調整アルゴリズムは、検証される正確な容量値を前提としていなければならない。この制限は、公正な結果を担保し、正しい答えの知識によって不安定な操作の機会を削除します。
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.
調整時の特別な試みなしにさまざまなSDOで長年にわたって取り組んでいた問題と同様に、測定基準および方法のためのさまざまな解決策が浮上しています。
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:
2013年から2019年のタイムフレームで変更された（または変更し始めた）5つの要因があり、そのパス上のいずれかの存在は、変更を考慮した測定設計の機能を必要とします。
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ゲートウェイの測定値が低下しています。
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).
SRC：ホストのアドレスの1つ（グローバルにルーティング可能なIPアドレスなど）。
Dst: One of the addresses of a host (such as a globally routable IP address).
DST：ホストのアドレスの一つ（たとえば、グローバルにルーティング可能なIPアドレスなど）。
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).
MAXHOPS：ホップ数の制限特定のパケットがSRCのホストからホストへのホストからホスト（TTLまたはホップの制限で実装されている）として訪問することがあります。
T0: The time at the start of a measurement interval, when packets are first transmitted from the Source.
T0：パケットが最初にソースから送信されるときの測定間隔の開始時の時間。
I: The nominal duration of a measurement interval at the Destination (default 10 sec).
I：先（デフォルト10秒）で測定間隔の公称持続時間。
dt: The nominal duration of m equal sub-intervals in I at the Destination (default 1 sec).
DT：宛先のIのM等の部分間隔の名目期間（デフォルトは1秒）。
dtn: The beginning boundary of a specific sub-interval, n, one of m sub-intervals in I.
DTN：IのM個のサブ間隔の1つの特定のサブインターバルの開始境界N。
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.
TMAX：テストパケットが宛先に到着する最大待ち時間は、廃棄されたパケットからの長い遅延を持つ十分に長い間、一方向の遅延の分布が切り捨てられないようにします。
F: The number of different flows synthesized by the method (default one flow).
f：メソッドによって合成されたさまざまなフローの数（デフォルトの1フロー）。
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].
フロー:(定数が定数が保持されたとき）と同じN-タプルを持つパケットのストリームは、マルチパス決定（負荷分散での決定など）で同じ扱いをもたらす。注：ルーターが[RFC6438]で提供されているガイドラインに準拠している場合、IPv6フローラベルはフロー定義に含める必要があります。
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].
TYPE-P：この評価が適用されるテストパケットの完全な説明（フロー定義フィールドを含む）。UDPトランスポート層は、下記のテストパケットの1つの要件です。TYPE-Pは、[Y.1540]の6.1.1項に定義されているように、「関心のある人口」と並行して概念です。
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).
PM：損失、遅延、並べ替えなどの基本的な測定基準のリスト、および対応する目標パフォーマンススレッショルド。少なくとも1つの基本的なメトリックと目標パフォーマンスのしきい値を指定する必要があります（一方向IPパケット損失[RFC7680]など）。
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.
T：宛先測定点またはMP（DST）で測定された*最初の*テストパケットの*到着*のホームタイム。除外されているソースホストと宛先ホストの間で送信された他のパケットがあるかもしれませんので、メトリックの測定に使用される最初のパケットの到着時です。
Note that timestamp format and resolution, sequence numbers, etc. will be established by the chosen test protocol standard or implementation.
タイムスタンプのフォーマットと解像度、シーケンス番号などは、選択されたテストプロトコルの標準または実装によって確立されます。
This section sets requirements for the Singleton metric that supports the Maximum IP-Layer Capacity Metric definitions in Section 6.
このセクションでは、セクション6の最大IP層容量メトリック定義をサポートするシングルトンメトリックの要件を設定します。
"Type-P-One-way-IP-Capacity" is the formal name; it is informally called "IP-Layer Capacity".
「タイプ-P-one-ip-capacity」は正式な名前です。非公式に「IP層容量」と呼ばれています。
Note that Type-P depends on the chosen method.
TYPE-Pは選択された方法によって異なります。
This section lists the REQUIRED input factors to specify the metric, beyond those listed in Section 4.
このセクションでは、セクション4にリストされているもの以外のメトリックを指定するために必要な入力ファクタを示します。
No additional Parameters are needed.
追加のパラメータは必要ありません。
This section defines the REQUIRED aspects of the measurable IP-Layer Capacity Metric (unless otherwise indicated) for measurements between specified Source and Destination hosts:
このセクションでは、指定された送信元ホストと宛先ホスト間の測定のために、測定可能なIP層容量メトリック（特に指定のない限り）の必要な側面を定義します。
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.
SRCホストから送信できるパケット内のIP層容量C（T、DT、PM）を定義し、SRCホストから送信できるパケットのIP層ビット（ヘッダーフィールドとデータフィールドを含む）と定義します。1つの連続したサブインターバル、DTの長さ。IP層容量は、SRCおよびDSTホスト、ホストアドレス、およびホスト間のパスによって異なります。
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].
パケットサイズが既知で固定サイズの場合、単一のサブインターバルDTの間のパケットカウントは、IPヘッダおよびデータフィールドの総ビットとデータフィールドとを乗算している。
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.
パラメータPMは他のパフォーマンスメトリックを表します（下記のセクション5.4を参照）。それらの測定結果は、IP層容量の測定中に収集され、さらなる評価および報告のために対応するDTNに関連付けられなければならない。ユーザーは、各メトリックの参照定義によって必要に応じてパラメータTmaxを指定します。
Mathematically, this definition is represented as (for each n):
数学的には、この定義は（各nの場合）として表されます。
( n0[dtn,dtn+1] )
C(T,dt,PM) = -------------------------
dt
Figure 1: Equation for IP-Layer Capacity
図1：IP-重層容量のための方程式
and:
と：
* 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.
この定義による測定値はUDPトランスポート層を使用しなければならない。標準化されたパケットは[RFC8468]のセクション5に規定されています。測定は、無作為化された送信元ポートまたは同等の技術を使用し、テストパケット宛先アドレスと一致する送信元アドレスから応答を送信する必要があります。
Some effects of compression on measurement are discussed in Section 6 of [RFC8468].
測定に対する圧縮の影響については、[RFC8468]の第6章で説明します。
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.
一方向の並べ替え、重複、および遅延変動を測定することができる。
See the corresponding section for Maximum IP-Layer Capacity (Section 6.5).
最大IP層容量の対応するセクションを参照してください（6.5項）。
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).
IP層容量は、少なくとも単一のメガビット解像度で、1秒あたりのメガビット単位（MBP）の単位（混乱を回避するために、毎秒1,000,000ビット）で報告されるべきです。
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.
個々の能力の測定は、最大IP-重層容量と一致する形で報告することができます。第9章を参照してください。
This section sets requirements for the following components to support the Maximum IP-Layer Capacity Metric.
このセクションでは、最大IP層容量メトリックをサポートするために、次のコンポーネントの要件を設定します。
"Type-P-One-way-Max-IP-Capacity" is the formal name; it is informally called "Maximum IP-Layer Capacity".
「タイプ-P-one-ipe-max-capacity」は正式な名前です。非公式に「最大IP層容量」と呼ばれています。
Note that Type-P depends on the chosen method.
TYPE-Pは選択された方法によって異なります。
This section lists the REQUIRED input factors to specify the metric, beyond those listed in Section 4.
このセクションでは、セクション4にリストされているもの以外のメトリックを指定するために必要な入力ファクタを示します。
No additional Parameters or definitions are needed.
追加のパラメータや定義は必要ありません。
This section defines the REQUIRED aspects of the Maximum IP-Layer Capacity Metric (unless otherwise indicated) for measurements between specified Source and Destination hosts:
このセクションでは、指定された送信元ホストと宛先ホスト間の測定に対して、最大IP層容量メトリック（特に指定のない限り）の必要な側面を定義します。
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.
パラメータPMは他のパフォーマンスメトリック（以下のセクション6.4を参照）および最大IP層容量の測定結果を表します。少なくとも1つの目標性能閾値（PM基準）を定義する必要があります。複数のメトリックおよびターゲットのパフォーマンススレッショルドが定義されている場合、送信される最大ビット数のサブ間隔はすべての目標パフォーマンススレッショルドを満たす必要があります。ユーザーは、各メトリックの参照定義によって必要に応じてパラメータTmaxを指定します。
Mathematically, this definition can be represented as:
数学的には、この定義は次のように表すことができます。
max ( n0[dtn,dtn+1] )
[T,T+I]
Maximum_C(T,I,PM) = -------------------------
dt
where:
ただし：
T T+I
_________________________________________
| | | | | | | | | | |
dtn=1 2 3 4 5 6 7 8 9 10 n+1
n=m
Figure 2: Equation for Maximum Capacity
図2：最大容量の方程式
and:
と：
* 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.
この定義では、SRCホストが送信されたパケットレートを変化させたときにM個のサブインターバルを試行として見ることができ、送信パケットのテストでDSTホストで測定されたPM基準を満たす最大N0を検索する。レートはSRCホストで一定に保持され、M個のサブインターバルはまた、IのすべてのDT長間隔にわたるPMリスト内のN0およびメトリックの安定性を評価するための試行と見なすこともできます。
Measurements according to these definitions SHALL use the UDP transport layer.
これらの定義による測定値はUDPトランスポート層を使用しなければならない。
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.
一方向の並べ替え、重複、および遅延変動を測定することができる。
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).
ボトルネックの輻輳を示していない最大_C（T、I、PM）は、測定間隔の間の待ち時間、パケット損失、または明示的な輻輳通知（ECN）マークの増加であるため、Maximum_C（T、I、PM）。
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).
IP層容量は、少なくとも単一のメガビット解像度で、1秒あたりのメガビット単位（MBP）の単位（混乱を回避するために、毎秒1,000,000ビット）で報告されるべきです。
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.
実証及び反復容量モードが試料中に存在する場合、最大IP-重層容量は、モードが存在することが観察されたことをストリームの先頭からの相対時間と共に、各モードのために報告されなければなりません。バイモーダル最大IPレイヤの容量は時々、より迅速に短い転送を実現したり、いくつかのビデオ・ストリームの初期バッファリング時間を短縮しようとする「ターボモード」と呼ばれる、いくつかのサービスで観察されています。少ない期間DTより持続的なモードが検出されないことに注意してください。
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.
いくつかの送信技術は、チャネル条件が劣化または改善したときに起動され得る複数の動作方法を有し、これらの送信方法は最大IP層容量を決定することができる。例としては、視線マイクロ波変調器コンステレーション、または変更が1つのカバレッジエリアから別のカバレッジエリアに移動することによって開始され得るセルラモデム技術が挙げられる。異なる伝送方法における動作は経時的に観察されてもよいが、上記の段落で説明されている「ターボモード」と同様に、最大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.
このセクションでは、IPレイヤの送信者のビットレートメトリックをサポートするために、次のコンポーネントの要件を設定します。このメトリックは、送信者が実際にテスト中に所望の速度を発生することを確認するのに役立ち、そして測定は、Srcホストとネットワークパス（またはSrcのホスト内実用近くなど）との間の界面で起こります。これは、パスのパフォーマンスのメトリックではありません。
"Type-P-IP-Sender-Bit-Rate" is the formal name; it is informally called the "IP-Layer Sender Bit Rate".
「Type-P-IP-Sender-Bit-Rate」は正式な名前です。非公式に「IP層の送信者のビットレート」と呼びます。
Note that Type-P depends on the chosen method.
TYPE-Pは選択された方法によって異なります。
This section lists the REQUIRED input factors to specify the metric, beyond those listed in Section 4.
このセクションでは、セクション4にリストされているもの以外のメトリックを指定するために必要な入力ファクタを示します。
S: The duration of the measurement interval at the Source.
S：ソースの測定間隔の期間。
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.
STN：S内のN個のサブ間隔の1つの特定のサブインターバルの開始境界N。
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.
Sは、オンデマンド経路の活性化、または必要なテストのいずれかのプリアンブル、及びパスの遅延を主アカウントに、Iよりも長くなければなりません。
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.
STは、サブ間隔dtよりもはるかに小さく、ftと同じ順序であるべきです。そうでなければ、レート測定値は多くのレート調整を含み、より多くの時間平滑化を含み、おそらく最大IP層容量を含む間隔を平滑化する（したがって関連性を失う）。STパラメータは、ソースがS全体の固定レートで送信されているときに関連性を持たない。
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:
このセクションでは、指定された宛先ホスト宛てのパケット上の指定されたソースでの測定のためのIP層の送信側ビットレートメトリック（特に指定のない限り）を定義し、必要な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].
IP層の送信側ビットレートB（S、ST）を定義して、1つの連続したサブインターバルの間にアドレスペアSRCおよびDSTを使用してソースから送信されたIP層ビット（ヘッダーフィールドおよびデータフィールドを含む）の数になるように定義します。、ST、ST間隔S（ここで、SはIよりも長くする）、およびその単一のサブインターバルSTの間の固定サイズのパケット数も任意の間隔でIP層ビットの数を提供する、[STN、STN1）]。
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間隔境界でのレート調整が行われます）。
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.
送信者と受信機（または送信元と宛先）の両方のビットレートは、IP層容量測定の一部として評価されるべきです。それ以外の場合、予期しない送信レートの制限は、誤った最大IP層容量測定を生成する可能性があります。
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).
IPレイヤセンダビットレートは毎秒メガビット単位で、意味のある解像度で報告されなければならない（混乱を避けるために、毎秒1,000,000ビットです）。
Individual IP-Layer Sender Bit Rate measurements are discussed further in Section 9.
個々のIP層の送信者ビットレート測定値については、セクション9でさらに説明します。
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.
2つの協調ホストが測定された経路とそれらの間の戻り経路を用いて、2つの協調ホストがSRC（テストパケット送信者）およびDST（受信機）の役割で動作することが必要である。
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.
テストパラメータiは、これがアクティブなテスト方法であり、テスト中にSRCホストからDSTホストへのパスに対して輻輳を引き起こす可能性があります。
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.
このセクションに記載されているアルゴリズムは、一般的な輻輳制御アルゴリズム（CCA）として使用してはいけません。セクション2（「範囲、目標」、および適用性」）に記載されているように、荷重率調整アルゴリズムの目標は、めった診断、診断、短期間の測定値の中で最大のIP層容量を決定するのを助けることです。テスト期間（テストデータの量）とアルゴリズムの攻撃性（ランプアップ速度と最大IP層容量まで）との間にトレードオフがあります。以下に選択されたパラメータ値は、これらの要因のうち、テストされたバランスを取ります。
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:
各レートは、カウントCCのバーストとして送信されたサイズSSのデータグラムとして定義され、各時間間隔TT（TTのデフォルトは100マイクロ秒、おそらくシステムティックインターバル）です。できるだけ大きなサイズのデータグラムを使用することは有利であるが、IP層の断片化をもたらさずに二次プロトコルヘッダおよび/またはトンネリングを可能にすることができるわずかに小さい最大値を使用することが賢明であり得る。新しいレートの選択は、現在の行RXの計算によって示されます。例えば：
"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.
"Rx-10"：送信者はテーブル内のレート10行を使用します。
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).
テストの開始時に、送信者はレートR1で送信を開始し、受信機は（インバウンドデータグラムを待っている間）FTのフィードバックタイマを開始します。データグラムが受信されると、それらはシーケンス番号の異常（損失、損失、重複、複製など）についてチェックされ、遅延範囲が測定される（一方向または往復）。この情報は、フィードバックタイマFTが期限切れになるまで累積され、ステータスフィードバックメッセージが受信側から送信者に送信され、この情報を伝達されます。次に、次のフィードバック間隔のために累積統計が受信機によってリセットされます。フィードバックメッセージが送信者に返送されると、現在の提供された負荷率（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.
最後に、輻輳を推論するための方法は、シーケンス番号の異常があり、および/または遅延範囲が3つの連続したフィードバック間隔の上限しきい値を超えていたことである。上記のアルゴリズムはまた、ITU-T勧告Y.1540、2020バージョン[Y.1540]の附属書Bにも示されており、このメモの付録A（「ロードレート調整疑似コード」）に実装されている。
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:
負荷率調整アルゴリズムは、受信したパケットストリームが突然中止されたときにテストを停止するタイマーを含める必要があります。タイムアウトしきい値は、このセクションで説明されている他のすべてのパラメータおよび変数の値とともに、表1に示されています。未明白なパラメータの操作は以下のとおりです。
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
表1：負荷率調整アルゴリズムのパラメータ
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.
ネットワーク状態への関連送信者バックオフ応答は、1つ以上のステータスフィードバックメッセージが送信者に到着できない場合に発生します。
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
where:
ただし：
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.
次いで、フィードバックが1つまたは複数のシーケンス番号異常の存在または遅延範囲が（上述のように）上方のしきい値を超えているのと同じプロセスに従って、提供された負荷を減少させるものとする。彼らの現在の状態これは、ステータスフィードバックメッセージまたはシーケンスエラーまたは遅延の変動を失うことが、レートの削減と輻輳確認をもたらす可能性があります。
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).
また、失われたステータスバックオフタイムアウトで初めて輻輳が確認された場合、提供された負荷率は1つ以上のレート設定（例えば、RX-30）によって減少します。このワンタイム短縮は、高速初期ランプアップを補償することを目的としています。他のすべての場合において、提供された負荷率は1つだけ減少します（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.
付録Bでは、このセクションで説明されている負荷率調整アルゴリズムを含む、IP層容量メトリックの目標と一致して、[RFC8085]の適用される必須要件への準拠を説明します。
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.
もちろん、IP層容量測定を行う機器を校正することができ、予想される容量を正確に測定することができ、機器の選択（処理速度、インタフェース帯域幅など）が測定範囲に適切に整合されるようにする必要があります。
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.
メトリックが指定されると最大レートを評価するとき、経路上のいくつかのバッファが埋められるまで、人為的に高い（楽観的）値が測定される可能性があります。他の原因には、測定間隔（DT）が小さく、バーストと整列している間に、パスによって配信されたアイドル間隔を持つバックツーバックパケットのバーストが含まれます。人工値は、測定方法が最大の検索であり、そうしない場合には、有害な最大容量をもたらす可能性があります。この状況は、マルチ秒の期間（測定されたRTTよりもはるかに長い）と再現可能な動作によって特徴付けられるバイモーダルサービス率とは異なります。
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.
もう1つのアプローチは[RFC2544]のセクション24から、検索の一部として実施された比較的短い試験が続いて最終的な決定を下すためにより長い試験を続ける。生産ネットワークでは、シングルトンとサンプルの測定値（実験室ベンチマークの試験および試験のための用語）は、サービスに影響を与える可能性があるため、期間が制限されなければなりません。しかし、最大のIP層容量を前の検索で決定された固定送信レートを持つサンプルを繰り返すのに十分な値があります。
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]で議論された方法は生産ネットワーク上で緩和され、代わりに執筆者がこのメモに記載されているようなメトリックや方法を開発するために標準コミュニティに挑戦しました。
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.
一般に、このメモが促進する広範囲の測定値は、広範な行動に遭遇するでしょう。セクション6.6ですでに議論されているバイモーダルIP容量動作は良い例です。
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.
[RFC7312]で予想されるように、さまざまな種類のトラフィックシェーパーやオンデマンド通信アクセス技術が発生し、測定結果に重要な役割を果たします。オンデマンド通信アクセスを有効にし、その後のテスト結果からプリアンブルを廃棄するための短いプリアンブル送信を提供するためにメソッドを準備する必要があります。
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).
上記のセクション8.1に記載されている負荷率調整アルゴリズムの柔軟性を使用してこれらの条件を軽減することが可能です。
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.
単一経路上の最大値*容量を測定しようとしている（テストストリーム内のフロー数に関係なく）複数の独立した同時テストを実行することは明らかに対抗的です。経路の同時独立したテストの数は1に制限されなければならない。
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.
テストが続くにつれて、実装者はその方法が進化すると期待されるべきです。ITU-Tは、YシリーズのITU-T勧告に補足（補足60）を発表しました。メトリックによるテスト。これらの結果は、ここで説明されている方法を改善しました。
The Singleton IP-Layer Capacity results SHOULD be accompanied by the context under which they were measured.
シングルトンIP層容量の結果は、それらが測定された文脈を伴うべきである。
* 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.
最大IP層容量の結果は表形式で報告する必要があります。テストフェーズを識別する列があるはずです。その段階で使用されるフローの数をリストする列があるはずです。残りの列は、最大IP層容量、損失率、RTT最小、RTT最大、およびその他のメトリックを含むすべてのフローの集計について、次の結果を報告する必要があります。
As mentioned in Section 6.6, bimodal (or multi-modal) maxima SHALL be reported for each mode separately.
6.6節で述べたように、二峰性（またはマルチモーダル）最大値は各モードについて別々に報告されなければならない。
+========+==========+==================+========+=========+=========+
| 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
表2：最大IP層容量結果
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").
サブインターバル時間DTは、最大IP層容量の結果の報告、およびセクション4からの残りのパラメータ（「一般的なパラメータと定義」）を添付しなければなりません。
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.
最大容量が発生したサブ間隔に対応するPMリストメトリックは、各テストフェーズに対して最大のIP層容量の結果の報告書を添付しなければなりません。
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.
IP層の送信者のビットレートの結果は表形式で報告されるべきです。テストフェーズを識別する列があるはずです。その位相で使用されている各個々の（番号付き）フロー、またはその位相のフローの集計をリストした列がある必要があります。対応する列は、各フローおよび集約に対して、特定の送信レートサブインターバルSTNを識別する必要があります。最後の列は、使用されるフロー、またはすべてのフローの集計に対してIP層の送信側ビットレートの結果を報告する必要があります。
+========+==========================+===========+=============+
| 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.
サブインターバル期間STは、送信者IP層ビットレートの結果の報告書を添付しなければなりません。
Also, the values of the remaining Parameters from Section 4 ("General Parameters and Definitions") MUST be reported.
また、セクション4からの残りのパラメータの値（「一般的なパラメータと定義」）を報告する必要があります。
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].
このメトリックのマルチスタンダード開発組織（SDO）調和の一環として、ブロードバンドフォーラム（BBF）がその専門知識が寄与した地域の1つは、情報モデルの定義と構成のためのデータモデルの定義でした。報告。これらのモデルは、このメモのリストとして指定されたメトリックパラメータとデフォルト値と一致しています。[TR-471]は、関連するBBF作業で全データモデルを準備するために使用された情報モデルを提供します。BBFはまた、インターネットアクセスアーキテクチャ内の測定システムの配置など、そのPURVIEW内のトピックを慎重に検討しています。たとえば、テストプロトコルの選択に影響するタイムスタンプ解像度の要件を[TR-471]の表2に示します。
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].
アクティブメトリックとアクティブ測定はセキュリティ上の考慮事項の長い歴史を持ちます。ライブパスの能動的な測定に適用されるセキュリティ上の考慮事項はここで関連しています。[RFC4656]と[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.
測定に関与するもののプライバシーを考慮すると、トラフィックが測定されているもの、この作業範囲内にある能動的な技術を使用すると、潜在的な観察者に利用可能な機密情報が大幅に削減されます。測定目的のためのユーザートラフィックの受動的な観察は、多くのプライバシー問題を引き上げます。リーダーは、アクティブおよびパッシブ技術をカバーするブロードバンドパフォーマンス（LMAP）フレームワーク[RFC7594]の大規模測定に記載されているプライバシーに関する考慮事項を参照しています。
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.
これらの機能の正確な仕様は将来のプロトコル開発のために残されています。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.
[RFC2330] Paxson、V.、Almes、G.、MAHDAVI、J.、およびM Mathis、「IPパフォーマンスメトリックのためのフレームワーク」、RFC 2330、DOI 10.17487 / RFC2330、1998年5月、<https：//www.rfc-editor.org/info/rfc2330>。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>.
[RFC2681] Almes、G.、KalidIndi、S.、およびM.Zekauskas、「IPPMの往復遅延測定基準」、RFC 2681、DOI 10.17487 / RFC2681、1999年9月、<https：//www.rfc-編集者.ORG / INFO / RFC2681>。
[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, <https://www.rfc-editor.org/info/rfc4656>.
[RFC4656] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J.、およびM.Zekauskas、「一方向アクティブ測定プロトコル（OWAMP）」、RFC 4656、DOI 10.17487 / RFC4656、9月2006年、<https://www.rfc-editor.org/info/rfc4656>。
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 10.17487/RFC4737, November 2006, <https://www.rfc-editor.org/info/rfc4737>.
[RFC4737]モートン、A。、CIAVATTONE、L.、Ramachandran、G.、Shalunov、S.、およびJ. Perser、「パケット並べ替えメトリック」、RFC 4737、DOI 10.17487 / RFC4737、2006年11月、<https：//www.rfc-editor.org/info/rfc4737>。
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.
[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K.、およびJ.Babiarz、「双方向アクティブ測定プロトコル（Twamp）」、RFC 5357、DOI 10.17487 / RFC5357、10月2008年、<https://www.rfc-editor.org/info/rfc5357>。
[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, <https://www.rfc-editor.org/info/rfc6438>.
[RFC6438] Carpenter、B.およびS. Amante、「トンネルの等価マルチパスルーティングのためのIPv6フローラベルの使用」、RFC 6438、DOI 10.17487 / RFC6438、2011年11月、<https：//www.rfc-editor.org/info/rfc6438>。
[RFC7497] Morton, A., "Rate Measurement Test Protocol Problem Statement and Requirements", RFC 7497, DOI 10.17487/RFC7497, April 2015, <https://www.rfc-editor.org/info/rfc7497>.
[RFC7497]モートン、A。、「レート測定テストプロトコル問題ステートメントおよび要件」、RFC 7497、DOI 10.17487 / RFC7497、2015年4月、<https：//www.rfc-editor.org/info/rfc7497>。
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc-editor.org/info/rfc7680>.
[RFC7680] Almes、G.、Kiristindi、S.、Zekauskas、M.、およびA.モートン、「IPパフォーマンス測定基準（IPPM）の一方向損失メトリック（IPPM）」、STD 82、RFC 7680、DOI 10.17487/ RFC7680、2016年1月、<https：//www.rfc-editor.org/info/rfc7680>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[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, <https://www.rfc-editor.org/info/rfc8468>.
[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月、<https：//www.rfc-editor.org/info/rfc8468>。
[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, <https://irtf.org/anrw/2017/anrw17-final5.pdf>.
[CopyCat] Edeline、K.、Kühlewind、M.、Trammell、B.、およびB. Donnet、「Copycat：野生の新輸送プロトコルの鑑別治療のテスト」、ANRW '17、DOI 10.1145 / 3106328.3106330、2017年7月、<https://irtf.org/anrw/2017/anrw17-final5.pdf>。
[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, <https://datatracker.ietf.org/liaison/1632/>.
[LS-SG12-A] "LIAISONステートメント：IP容量と待ち時間の調和：ドラフトRECのリビジョン。ITU-T SGから、IPパケット転送性能パラメータと新たな附属書AのY.15402019年3月12日、<https://datatracker.ietf.org/liaison/1632/>。
[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, <https://datatracker.ietf.org/liaison/1645/>.
[LS-SG12-B] "Liaisonステートメント：IP容量と待ち時間の調和のためのLS描画録画の同意：ITUからのIPパケット転送性能パラメータと新たな附属書AのY.1540T-SG-12、2019年5月、<https：//datatracker.ietf.org/liaison/1645/>。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, <https://www.rfc-editor.org/info/rfc2544>.
[RFC2544] Bradner、S.およびJ.Cquaid、「ネットワークインターコネクトデバイスのベンチマーク方法」、RFC 2544、DOI 10.17487 / RFC2544、1999年3月、<https：//www.rfc-editor.org/info/rfc2544>。
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, DOI 10.17487/RFC3148, July 2001, <https://www.rfc-editor.org/info/rfc3148>.
[RFC3148] Mathis、M.およびM. Allman、「経験的なバルク転送容量メトリックを定義するためのフレームワーク」、RFC 3148、DOI 10.17487 / RFC3148、2001年7月、<https://www.rfc-editor.org/info/RFC3148>。
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, DOI 10.17487/RFC5136, February 2008, <https://www.rfc-editor.org/info/rfc5136>.
[RFC5136] Chimento、P.およびJ.ISHAC、「ネットワーク容量の定義」、RFC 5136、DOI 10.17487 / RFC5136、2008年2月、<https：//www.rfc-editor.org/info/rfc5136>。
[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, <https://www.rfc-editor.org/info/rfc6815>.
[RFC6815] Bradner、S.、Dubray、K.、McQuaid、J.、およびA. Morton、「RFC 2544の適用性声明：有害な生産ネットワークの使用」、RFC 6815、DOI 10.17487 / RFC6815、2012年11月、<https://www.rfc-editor.org/info/rfc6815>。
[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, DOI 10.17487/RFC7312, August 2014, <https://www.rfc-editor.org/info/rfc7312>.
[RFC7312] Fabini、J.およびA.モートン、「IPパフォーマンス測定基準（IPPM）」、RFC 7312、DOI 10.17487 / RFC7312、2014年8月、<https://ww.rfc-editor.org/ 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, <https://www.rfc-editor.org/info/rfc7594>.
[RFC7594]イヤーディリー、P.、Morton、A。、Bagnulo、M.、Burbridge、T.、Aitken、P.、A. AKHTER、「ブロードバンド性能の大規模測定のためのフレームワーク（LMAP）」、RFC7594、DOI 10.17487 / RFC7594、2015年9月、<https：//www.rfc-editor.org/info/rfc7594>。
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC7799]モートン、A。、「能動的および受動的な測定基準と方法（インス間のハイブリッド型（ハイブリッドタイプおよびメソッド）、RFC 7799、DOI 10.17487 / RFC7799、2016年5月、<https：//www.rfc-editor.org/info/ RFC7799>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] eggert、L.、Fairhurst、G.、G.Shepherd、 "UDP使用ガイドライン"、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<https：//www.rfc-editor.org/ info / rfc8085>。
[RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March 2018, <https://www.rfc-editor.org/info/rfc8337>.
[RFC8337] Mathis、M.およびA.モートン、「バルク輸送能力のためのモデルベースの測定基準」、RFC 8337、DOI 10.17487 / RFC8337、2018年3月、<https：//www.rfc-editor.org/info/rfc8337>。
[TR-471] Morton, A., "Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements", Broadband Forum TR-471, July 2020, <https://www.broadband-forum.org/technical/download/ TR-471.pdf>.
[TR-471]モートン、A。、「最大IP層容量メトリック、関連メトリック、および測定」、ブロードバンドフォーラムTR-471、<https://www.broadband-forum.org/technical/download/ 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, <https://www.itu.int/rec/T-REC-Y.1540-201912-I/en>.
[Y.1540] ITU-T、「インターネットプロトコルデータ通信サービス - IPパケット転送と可用性性能パラメータ」、ITU-T勧告Y.1540、2019年12月、<https：//www.itu.int/rec/t-rec-y.1540-201912-I / E>。
[Y.Sup60] ITU-T, "Interpreting ITU-T Y.1540 maximum IP-layer capacity measurements", ITU-T Recommendation Y.Sup60, October 2021, <https://www.itu.int/rec/T-REC-Y.Sup60/en>.
[Y SOU 6] ITU-T、「ITU-T Y.1540の最大IP層容量測定」、ITU-T勧告Y SUU60、2021年10月、<https://www.itu.int/rec/t-rec-y S60 / en>。
This appendix provides a pseudocode implementation of the algorithm described in Section 8.1.
この付録では、セクション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
LOWTHRESH = 30＃LOWしきい値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 )
Rx++;
}
} else if ( seqErr > seqErrThresh || delay > upperThresh ) {
slowAdjCount++;
if ( Rx < hSpeedThresh && slowAdjCount == slowAdjThresh ) {
if ( Rx > highSpeedDelta * 3 )
Rx -= highSpeedDelta * 3;
else
Rx = 0;
} else {
if ( Rx > 0 )
Rx--;
}
}
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は、主に輻輳制御に焦点を当てています。ガイドラインは必須（必須）と推奨（必要とされている）カテゴリに表示されます。
The mandatory requirements in Section 3 of [RFC8085] include the following:
[RFC8085]のセクション3の必須要件には、次のものがあります。
| 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).
セクション8.1に記載されている負荷率調整アルゴリズムの目的は、ネットワークを探索し、最大のIP層容量測定値を可能な限り少なく、セクション2に記載されているアプリケーションの範囲内で最大のIP層容量測定を可能にすることです。テスト専用のトラフィック（特にギガビットレート測定値）とテストの期間の両方の保守主義と最小化の目標（これは、アルゴリズムの公平性の1つの貢献要因です）。
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:
[RFC8085]のセクション3.1.1プロトコルタイマーのガイドラインについて説明します。
| 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).
このメモは、明示的な輻輳通知（ECN）を使用することの特別な利点を予測しません。
Section 3.2 of [RFC8085] discusses message size guidelines:
[RFC8085]のセクション3.2では、メッセージサイズのガイドラインについて説明します。
| 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.
このメソッドは、最大のUDPペイロードサイズを持つ送信レートテーブルを使用して、大きなヘッダーのオーバーヘッドを予測し、断片化を回避します。
Section 3.3 of [RFC8085] provides reliability guidelines:
[RFC8085]のセクション3.3は信頼性のガイドラインを提供します。
| 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.
IP層容量メトリックとメソッドは信頼できる配信を必要としません。
| 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].
IP層容量メトリックとメソッドは、パケット順序を再確立する必要はありません。RFC4737が発生した場合は、パケットの並べ替えを測定することが好ましい。
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.
負荷率調整アルゴリズムの目標は、頻度のない診断、短期間の測定のコンテキストにおける最大IP層容量を決定することです。この目標は、[RFC8085]に記載されているように、多くのSHOP-LEVELの要件に対するグローバルな例外です。そのうち、多かれ少なかれ公正な方法で他のトラフィックと共存しなければならない長寿命のフローを対象としています。ただし、アルゴリズム（上記のセクション8.1および付録Aで指定されているように）は、明確に定義された方法で輻輳の兆候に反応します。
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:
例として具体的な推奨事項を提供しています。[RFC8085]のセクション3.1.5（RTTの影響と輻輳制御の損失測定の影響について）は次のように述べています。
| 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:
[RFC8085]のセクション3.1.5は次のように指定します。
| 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)):
[RFC8085]からの要件の簡単なレビューが続きます（このメモが準拠している場合は「はい」とマークされています。または「NA」（該当なし））：
+======+============================================+=========+
| 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からの主なガイドラインの概要
Acknowledgments
謝辞
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
Email: acm@research.att.com
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
Email: Ruediger.Geib@telekom.de
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
Email: lencia@att.com