[要約] RFC 9439 はALTOの性能コストメトリクスに関する拡張であり、異なるネットワーク性能メトリクスを提供することを目的としています。
Internet Engineering Task Force (IETF) Q. Wu
Request for Comments: 9439 Huawei
Category: Standards Track Y. Yang
ISSN: 2070-1721 Yale University
Y. Lee
Samsung
D. Dhody
Huawei
S. Randriamasy
Nokia Networks France
L. Contreras
Telefonica
August 2023
The cost metric is a basic concept in Application-Layer Traffic Optimization (ALTO), and different applications may use different types of cost metrics. Since the ALTO base protocol (RFC 7285) defines only a single cost metric (namely, the generic "routingcost" metric), if an application wants to issue a cost map or an endpoint cost request in order to identify a resource provider that offers better performance metrics (e.g., lower delay or loss rate), the base protocol does not define the cost metric to be used.
コストメトリックは、アプリケーション層トラフィック最適化（ALTO）の基本概念であり、さまざまなアプリケーションがさまざまな種類のコストメトリックを使用する場合があります。ALTOベースプロトコル（RFC 7285）は単一のコストメトリック（すなわち、一般的な「ルーティングコスト」メトリック）のみを定義しているため、アプリケーションがコストマップまたはエンドポイントコスト要求を発行したい場合、より良いリソースプロバイダーを識別するためにエンドポイントコスト要求を希望する場合パフォーマンスメトリック（たとえば、遅延または損失率の低下など）、ベースプロトコルは、使用するコストメトリックを定義しません。
This document addresses this issue by extending the specification to provide a variety of network performance metrics, including network delay, delay variation (a.k.a. jitter), packet loss rate, hop count, and bandwidth.
このドキュメントは、仕様を拡張して、ネットワーク遅延、遅延変動（a.k.a.ジッター）、パケット損失率、ホップカウント、帯域幅など、さまざまなネットワークパフォーマンスメトリックを提供することにより、この問題に対処します。
There are multiple sources (e.g., estimations based on measurements or a Service Level Agreement) available for deriving a performance metric. This document introduces an additional "cost-context" field to the ALTO "cost-type" field to convey the source of a performance metric.
パフォーマンスメトリックを導出するために利用可能な複数のソース（測定またはサービスレベル契約に基づく推定など）があります。このドキュメントでは、パフォーマンスメトリックのソースを伝えるために、ALTO「コストタイプ」フィールドに追加の「コストコンテキスト」フィールドを導入します。
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/rfc9439.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9439で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Requirements Language
3. Performance Metric Attributes
3.1. Performance Metric Context: "cost-context"
3.2. Performance Metric Statistics
4. Packet Performance Metrics
4.1. Cost Metric: One-Way Delay (delay-ow)
4.1.1. Base Identifier
4.1.2. Value Representation
4.1.3. Intended Semantics and Use
4.1.4. Cost-Context Specification Considerations
4.2. Cost Metric: Round-Trip Delay (delay-rt)
4.2.1. Base Identifier
4.2.2. Value Representation
4.2.3. Intended Semantics and Use
4.2.4. Cost-Context Specification Considerations
4.3. Cost Metric: Delay Variation (delay-variation)
4.3.1. Base Identifier
4.3.2. Value Representation
4.3.3. Intended Semantics and Use
4.3.4. Cost-Context Specification Considerations
4.4. Cost Metric: Loss Rate (lossrate)
4.4.1. Base Identifier
4.4.2. Value Representation
4.4.3. Intended Semantics and Use
4.4.4. Cost-Context Specification Considerations
4.5. Cost Metric: Hop Count (hopcount)
4.5.1. Base Identifier
4.5.2. Value Representation
4.5.3. Intended Semantics and Use
4.5.4. Cost-Context Specification Considerations
5. Throughput/Bandwidth Performance Metrics
5.1. Cost Metric: TCP Throughput (tput)
5.1.1. Base Identifier
5.1.2. Value Representation
5.1.3. Intended Semantics and Use
5.1.4. Cost-Context Specification Considerations
5.2. Cost Metric: Residual Bandwidth (bw-residual)
5.2.1. Base Identifier
5.2.2. Value Representation
5.2.3. Intended Semantics and Use
5.2.4. Cost-Context Specification Considerations
5.3. Cost Metric: Available Bandwidth (bw-available)
5.3.1. Base Identifier
5.3.2. Value Representation
5.3.3. Intended Semantics and Use
5.3.4. Cost-Context Specification Considerations
6. Operational Considerations
6.1. Source Considerations
6.2. Metric Timestamp Considerations
6.3. Backward-Compatibility Considerations
6.4. Computation Considerations
6.4.1. Configuration Parameter Considerations
6.4.2. Aggregation Computation Considerations
7. Security Considerations
8. IANA Considerations
8.1. ALTO Cost Metrics Registry
8.2. ALTO Cost Source Types Registry
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Authors' Addresses
Application-Layer Traffic Optimization (ALTO) provides a means for network applications to obtain network information so that the applications can identify efficient application-layer traffic patterns using the networks. Cost metrics are used in both the ALTO cost map service and the ALTO endpoint cost service in the ALTO base protocol [RFC7285].
アプリケーション層トラフィック最適化（ALTO）は、ネットワークを使用して効率的なアプリケーション層トラフィックパターンを識別できるように、ネットワークアプリケーションがネットワーク情報を取得する手段を提供します。コストメトリックは、ALTOコストマップサービスとALTOベースプロトコル[RFC7285]のALTOエンドポイントコストサービスの両方で使用されます。
Since different applications may use different cost metrics, the ALTO base protocol introduced the "ALTO Cost Metrics" registry (Section 14.2 of [RFC7285]) as a systematic mechanism to allow different metrics to be specified. For example, a delay-sensitive application may want to use latency-related metrics, and a bandwidth-sensitive application may want to use bandwidth-related metrics. However, the ALTO base protocol has registered only a single cost metric, i.e., the generic "routingcost" metric (Section 14.2 of [RFC7285]); no latency- or bandwidth-related metrics are defined in the base protocol.
異なるアプリケーションは異なるコストメトリックを使用する可能性があるため、ALTOベースプロトコルは、異なるメトリックを指定できるようにする系統的メカニズムとして、「ALTOコストメトリック」レジストリ（[RFC7285]のセクション14.2）を導入しました。たとえば、遅延に敏感なアプリケーションでは、レイテンシ関連のメトリックを使用する場合があり、帯域幅に敏感なアプリケーションでは、帯域幅関連メトリックを使用する場合があります。ただし、ALTOベースプロトコルは、単一のコストメトリック、つまり汎用「ルーティングコスト」メトリック（[RFC7285]のセクション14.2）のみを登録しています。ベースプロトコルでは、レイテンシまたは帯域幅関連メトリックは定義されていません。
This document registers a set of new cost metrics (Table 1) to allow applications to determine where to connect based on network performance criteria, including delay- and bandwidth-related metrics.
このドキュメントは、一連の新しいコストメトリック（表1）を登録して、アプリケーションが遅延および帯域幅関連メトリックを含むネットワークパフォーマンス基準に基づいて接続する場所を決定できるようにします。
+============+===============+=====================================+
| Metric | Definition in | Semantics Based On |
| | This Document | |
+============+===============+=====================================+
| One-Way | Section 4.1 | Base: [RFC7471] [RFC8570] [RFC8571] |
| Delay | | sum of Unidirectional Delay of |
| | | links along the path |
+------------+---------------+-------------------------------------+
| Round-Trip | Section 4.2 | Base: Sum of two directions of |
| Delay | | Unidirectional Delay |
+------------+---------------+-------------------------------------+
| Delay | Section 4.3 | Base: [RFC7471] [RFC8570] [RFC8571] |
| Variation | | Sum of Unidirectional Delay |
| | | Variation of links along the path |
+------------+---------------+-------------------------------------+
| Loss Rate | Section 4.4 | Base: [RFC7471] [RFC8570] [RFC8571] |
| | | aggr Unidirectional Link Loss |
+------------+---------------+-------------------------------------+
| Residual | Section 5.2 | Base: [RFC7471] [RFC8570] [RFC8571] |
| Bandwidth | | min Unidirectional Residual BW |
+------------+---------------+-------------------------------------+
| Available | Section 5.3 | Base: [RFC7471] [RFC8570] [RFC8571] |
| Bandwidth | | min Unidirectional Available BW |
+------------+---------------+-------------------------------------+
| TCP | Section 5.1 | [RFC9438] |
| Throughput | | |
+------------+---------------+-------------------------------------+
| Hop Count | Section 4.5 | [RFC7285] |
+------------+---------------+-------------------------------------+
Table 1: Cost Metrics Defined in This Document
表1：このドキュメントで定義されているコストメトリック
The first six metrics listed in Table 1 (i.e., one-way delay, round-trip delay, delay variation, loss rate, residual bandwidth, and available bandwidth) are derived from the set of Traffic Engineering (TE) performance metrics commonly defined in OSPF [RFC3630] [RFC7471], IS-IS [RFC5305] [RFC8570], and BGP - Link State (BGP-LS) [RFC8571]. Deriving ALTO cost performance metrics from existing network-layer TE performance metrics, and making it exposed to ALTO, can be a typical mechanism used by network operators to deploy ALTO [RFC7971] [FlowDirector]. This document defines the base semantics of these metrics by extending them from link metrics to end-to-end metrics for ALTO. The "Semantics Based On" column specifies at a high level how the end-to-end metrics are computed from link metrics; details will be specified in the following sections.
表1にリストされている最初の6つのメトリック（つまり、一元配置遅延、往復遅延、遅延変動、損失率、残留帯域幅、および利用可能な帯域幅）は、一般に定義されるトラフィックエンジニアリング（TE）パフォーマンスメトリックのセットから派生しています。OSPF [RFC3630] [RFC7471]、IS-IS [RFC5305] [RFC8570]、およびBGP-LINK-LINK STATE（BGP-LS）[RFC8571]。ALTOは、既存のネットワーク層TEパフォーマンスメトリックからパフォーマンスメトリックをコストで導き、ALTOにさらされることは、ALTO [RFC7971] [FlowDirector]を展開するためにネットワークオペレーターが使用する典型的なメカニズムになります。このドキュメントでは、これらのメトリックのベースセマンティクスを、リンクメトリックからALTOのエンドツーエンドメトリックに拡張することにより、これらのメトリックのベースセマンティクスを定義します。「セマンティクスに基づく」列は、リンクメトリックからエンドツーエンドメトリックがどのように計算されるかを高レベルで指定します。詳細については、次のセクションで指定します。
The Min/Max Unidirectional Link Delay metric as defined in [RFC8570] and [RFC8571], and Maximum (Link) Bandwidth as defined in [RFC3630] and [RFC5305], are not listed in Table 1 because they can be handled by applying the statistical operators defined in this document. The metrics related to utilized bandwidth and reservable bandwidth (i.e., Maximum Reservable (Link) Bandwidth and Unreserved Bandwidth as defined in [RFC3630] and [RFC5305]) are outside the scope of this document.
[rfc8570]および[rfc8571]で定義されているmin/max単方向リンク遅延メトリック、および[rfc3630]および[rfc5305]で定義されている最大（リンク）帯域幅は、表1にリストされていないため、表1にリストされていないため、このドキュメントで定義されている統計演算子。[RFC3630]および[RFC5305]で定義されているように、利用可能な帯域幅と予約可能な帯域幅（つまり、最大予約可能な（リンク）帯域幅と非予約帯域幅）に関連するメトリックは、このドキュメントの範囲外です。
The seventh metric in Table 1 (the estimated TCP-flow throughput metric) provides an estimation of the bandwidth of a TCP flow, using TCP throughput modeling, to support use cases of adaptive applications [Prophet] [G2]. Note that other transport-specific metrics can be defined in the future. For example, QUIC-related metrics [RFC9000] can be considered when the methodology for measuring such metrics is more mature (e.g., see [QUIC-THROUGHPUT-TESTING]).
表1の7番目のメトリック（推定TCPフロースループットメトリック）は、TCPスループットモデリングを使用してTCPフローの帯域幅の推定を提供し、適応アプリケーションのユースケース[Prophet] [G2]をサポートします。他の輸送固有のメトリックは将来定義できることに注意してください。たとえば、そのようなメトリックを測定するための方法論がより成熟している場合、QUIC関連のメトリック[RFC9000]を考慮することができます（たとえば、[Quic-Throughput-Testing]を参照）。
The eighth metric in Table 1 (the hop count metric) is mentioned, but not defined, in the ALTO base protocol [RFC7285]; this document provides a definition for it.
表1の8番目のメトリック（ホップカウントメトリック）が言及されていますが、ALTOベースプロトコル[RFC7285]で定義されていません。このドキュメントは、その定義を提供します。
These eight performance metrics can be classified into two categories: those derived from the performance of individual packets (i.e., one-way delay, round-trip delay, delay variation, loss rate, and hop count) and those related to bandwidth/throughput (residual bandwidth, available bandwidth, and TCP throughput). These two categories are defined in Sections 4 and 5, respectively. Note that all metrics except round-trip delay are unidirectional. An ALTO client will need to query both directions if needed.
これらの8つのパフォーマンスメトリックは、個々のパケットのパフォーマンス（つまり、一元配置遅延、往復遅延、遅延変動、損失率、およびホップカウント）と帯域幅/スループットに関連する2つのカテゴリの2つのカテゴリに分類できます。残留帯域幅、利用可能な帯域幅、およびTCPスループット）。これらの2つのカテゴリは、それぞれセクション4と5で定義されています。往復遅延を除くすべてのメトリックは単方向であることに注意してください。ALTOクライアントは、必要に応じて両方の方向を照会する必要があります。
The purpose of this document is to ensure proper usage of these eight performance metrics in the context of ALTO. This document follows the guidelines defined in Section 14.2 of [RFC7285] on registering ALTO cost metrics. Hence, it specifies the identifier, the intended semantics, and the security considerations of each one of the metrics specified in Table 1.
このドキュメントの目的は、ALTOのコンテキストでこれらの8つのパフォーマンスメトリックを適切に使用することです。このドキュメントは、ALTOコストメトリックの登録に関する[RFC7285]のセクション14.2で定義されているガイドラインに従います。したがって、表1に指定されたメトリックのそれぞれの識別子、意図されたセマンティクス、およびセキュリティ上の考慮事項を指定します。
The definitions of the intended semantics of the metrics tend to be coarse grained and are for guidance only, and they may work well for ALTO. On the other hand, a performance measurement framework, such as the IP Performance Metrics (IPPM) framework, may provide more details for defining a performance metric. This document introduces a mechanism called "cost-context" to provide additional details, when they are available; see Section 3.
メトリックの意図されたセマンティクスの定義は、粗い粒子が粗く、ガイダンスのみであり、アルトにとってうまく機能する可能性があります。一方、IPパフォーマンスメトリック（IPPM）フレームワークなどのパフォーマンス測定フレームワークは、パフォーマンスメトリックを定義するための詳細を提供する場合があります。このドキュメントでは、「Cost-Context」と呼ばれるメカニズムを導入して、利用可能な場合に追加の詳細を提供します。セクション3を参照してください。
Following the ALTO base protocol, this document uses JSON to specify the value type of each defined metric. See [RFC8259] for JSON data type specifications. In particular, [RFC7285] specifies that cost values should be assumed by default to be 'JSONNumber'. When defining the value representation of each metric in Table 1, this document conforms to [RFC7285] but specifies additional, generic constraints on valid JSONNumbers for each metric. For example, each new metric in Table 1 will be specified as non-negative (>= 0); Hop Count is specified to be an integer.
ALTOベースプロトコルに続いて、このドキュメントではJSONを使用して、定義された各メトリックの値タイプを指定します。JSONデータ型の仕様については、[RFC8259]を参照してください。特に、[RFC7285]は、コスト値がデフォルトで「jsonnumber」であると想定する必要があることを指定します。表1の各メトリックの値表現を定義する場合、このドキュメントは[RFC7285]に準拠していますが、各メトリックの有効なJSONNumbersの追加の一般的な制約を指定します。たとえば、表1の新しいメトリックは、非陰性（> = 0）として指定されます。ホップカウントは、整数であるように指定されています。
An ALTO server may provide only a subset of the metrics described in this document. For example, those that are subject to privacy concerns should not be provided to unauthorized ALTO clients. Hence, all cost metrics defined in this document are optional; not all of them need to be exposed to a given application. When an ALTO server supports a cost metric defined in this document, it announces the metric in its information resource directory (IRD) as defined in Section 9.2 of [RFC7285].
ALTOサーバーは、このドキュメントで説明されているメトリックのサブセットのみを提供できます。たとえば、プライバシーの懸念の対象となるものは、不正なALTOクライアントに提供されるべきではありません。したがって、このドキュメントで定義されているすべてのコストメトリックはオプションです。それらのすべてが特定のアプリケーションにさらされる必要はありません。ALTOサーバーがこのドキュメントで定義されているコストメトリックをサポートすると、[RFC7285]のセクション9.2で定義されているように、情報リソースディレクトリ（IRD）のメトリックを発表します。
An ALTO server introducing these metrics should consider related security issues. As a generic security consideration regarding reliability and trust in the exposed metric values, applications SHOULD promptly stop using ALTO-based guidance if they detect that the exposed information does not preserve their performance level or even degrades it. Section 7 discusses security considerations in more detail.
これらのメトリックを導入するALTOサーバーは、関連するセキュリティの問題を考慮する必要があります。露出したメトリック値に対する信頼性と信頼に関する一般的なセキュリティの考慮事項として、アプリケーションは、公開された情報がパフォーマンスレベルを維持しないか、それを低下させないことを検出した場合、ALTOベースのガイダンスの使用を即座に停止する必要があります。セクション7では、セキュリティ上の考慮事項について詳しく説明します。
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 definitions of the metrics in this document are coarse grained, based on network-layer TE performance metrics, and for guidance only. A fine-grained framework as specified in [RFC6390] requires that the fine-grained specification of a network performance metric include six components: (1) Metric Name, (2) Metric Description, (3) Method of Measurement or Calculation, (4) Units of Measurement, (5) Measurement Points, and (6) Measurement Timing. Requiring that an ALTO server provide precise, fine-grained values for all six components for each metric that it exposes may not be feasible or necessary for all ALTO use cases. For example, an ALTO server computing its metrics from network-layer TE performance metrics may not have information about the method of measurement or calculation (e.g., measured traffic patterns).
このドキュメントのメトリックの定義は、ネットワークレイヤーのTEパフォーマンスメトリックに基づいて、ガイダンスのみに基づいて、粗い粒子です。[RFC6390]で指定されている細粒のフレームワークでは、ネットワークパフォーマンスメトリックの微細粒子仕様には6つのコンポーネントが含まれる必要があります。（1）メトリック名、（2）メトリック説明、（3）測定または計算方法（4））測定単位、（5）測定点、および（6）測定タイミング。ALTOサーバーが、それが公開する各メトリックの6つのコンポーネントすべてに対して正確で微細に粒度の値を提供することを要求することは、すべてのALTOユースケースで実行不可または必要ではない場合があります。たとえば、ALTOサーバーは、ネットワーク層TEパフォーマンスメトリックからメトリックを計算すると、測定または計算の方法（測定されたトラフィックパターンなど）に関する情報がない場合があります。
To address the issue and realize ALTO use cases for the metrics listed in Table 1, this document defines performance metric identifiers that can be used in the ALTO Protocol with the following well-defined items: (1) Metric Name, (2) Metric Description, (3) Units of Measurement, and (4) Measurement Points, which are always specified by the specific ALTO services; for example, the endpoint cost service is between the two endpoints. Hence, the ALTO performance metric identifiers provide basic metric attributes.
問題に対処し、表1にリストされているメトリックのALTOユースケースを実現するために、このドキュメントは、次の明確に定義された項目でALTOプロトコルで使用できるパフォーマンスメトリック識別子を定義します。（1）メトリック名、（2）メトリックの説明、（3）測定単位、および（4）特定のALTOサービスによって常に指定されている測定ポイント。たとえば、エンドポイントコストサービスは2つのエンドポイントの間にあります。したがって、ALTOパフォーマンスメトリック識別子は、基本的なメトリック属性を提供します。
To allow the flexibility of allowing an ALTO server to provide fine-grained information such as Method of Measurement or Calculation according to its policy and use cases, this document introduces context information so that the server can provide these additional details.
ALTOサーバーがポリシーとユースケースに従って測定方法や計算方法などの微調整された情報を提供できるようにするために、このドキュメントはコンテキスト情報を導入して、サーバーがこれらの追加の詳細を提供できるようにします。
The core additional details of a performance metric specify how the metric is obtained. This is referred to as the source of the metric. Specifically, this document defines three types of coarse-grained metric information sources: "nominal", "sla", and "estimation".
パフォーマンスメトリックのコア追加の詳細は、メトリックの取得方法を指定します。これはメトリックのソースと呼ばれます。具体的には、このドキュメントでは、「公称」、「SLA」、および「推定」の3種類の粗粒メトリック情報源を定義します。
For a given type of source, precise interpretation of a performance metric value can depend on specific measurement and computation parameters.
特定のタイプのソースの場合、パフォーマンスメトリック値の正確な解釈は、特定の測定パラメーターと計算パラメーターに依存します。
To make it possible to specify the source and the aforementioned parameters, this document introduces an optional "cost-context" field to the "cost-type" field defined by the ALTO base protocol (Section 10.7 of [RFC7285]) as follows:
ソースと前述のパラメーターを指定できるようにするために、このドキュメントでは、次のように、ALTOベースプロトコル（[RFC7285]のセクション10.7）によって定義された「コストタイプ」フィールドにオプションの「コストコンテキスト」フィールドを導入します。
object {
CostMetric cost-metric;
CostMode cost-mode;
[CostContext cost-context;]
[JSONString description;]
} CostType;
object {
JSONString cost-source;
[JSONValue parameters;]
} CostContext;
"cost-context" will not be used as a key to distinguish among performance metrics. Hence, an ALTO information resource MUST NOT announce multiple CostType entries with the same "cost-metric", "cost-mode", and "cost-context". They must be placed into different information resources.
「コストコンテキスト」は、パフォーマンスメトリックを区別するためのキーとして使用されません。したがって、ALTO情報リソースは、同じ「コストメトリック」、「コストモード」、および「コストコンテキスト」を持つ複数のコストタイプエントリを発表してはなりません。それらは異なる情報リソースに配置する必要があります。
The "cost-source" field of the "cost-context" field is defined as a string consisting of only ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A). The "cost-source" field is used in this document to indicate a string of this format.
「コストコンテキスト」フィールドの「コストソース」フィールドは、ASCII英数字のみで構成される文字列として定義されます（U 0030-U 0039、U 0041-U 005A、およびU 0061-U 007A）。このドキュメントでは、この形式の文字列を示すために「コストソース」フィールドが使用されています。
As mentioned above, this document defines three values for "cost-source": "nominal", "sla", and "estimation". The "cost-source" field of the "cost-context" field MUST be one that is registered in the "ALTO Cost Source Types" registry (Section 8).
上記のように、このドキュメントは、「コストソース」の3つの値、「名目」、「SLA」、および「推定」を定義しています。「コストコンテキスト」フィールドの「コストソース」フィールドは、「ALTOコストソースタイプ」レジストリ（セクション8）に登録されているフィールドでなければなりません。
The "nominal" category indicates that the metric value is statically configured by the underlying devices. Not all metrics have reasonable "nominal" values. For example, throughput can have a nominal value, which indicates the configured transmission rate of the involved devices; latency typically does not have a nominal value.
「名目」カテゴリは、メトリック値が基礎となるデバイスによって静的に構成されていることを示しています。すべてのメトリックに合理的な「名目」値があるわけではありません。たとえば、スループットには名目値を持つことができ、関係するデバイスの構成された伝送速度を示します。通常、レイテンシには名目値がありません。
The "sla" category indicates that the metric value is derived from some commitment, which this document refers to as a Service Level Agreement (SLA). Some operators also use terms such as "target" or "committed" values. For an "sla" metric, it is RECOMMENDED that the "parameters" field provide a link to the SLA definition.
「SLA」カテゴリは、メトリック値が何らかのコミットメントから派生していることを示しています。これは、このドキュメントがサービスレベル契約（SLA）と呼んでいます。一部のオペレーターは、「ターゲット」または「コミットされた」値などの用語も使用しています。「SLA」メトリックの場合、「パラメーター」フィールドがSLA定義へのリンクを提供することをお勧めします。
The "estimation" category indicates that the metric value is computed through an estimation process. An ALTO server may compute "estimation" values by retrieving and/or aggregating information from routing protocols (e.g., see [RFC7471], [RFC8570], and [RFC8571]), traffic measurement management tools (e.g., the Two-Way Active Measurement Protocol (TWAMP) [RFC5357]), and measurement frameworks (e.g., IPPM), with corresponding operational issues. An illustration of potential information flows used for estimating these metrics is shown in Figure 1. Section 6 discusses in more detail the operational issues and how a network may address them.
「推定」カテゴリは、メトリック値が推定プロセスを通じて計算されることを示します。ALTOサーバーは、ルーティングプロトコルから情報を取得および/または集約することにより、「推定」値を計算することができます（たとえば、[RFC7471]、[RFC8570]、[RFC8571]）、トラフィック測定管理ツール（例えば、2方向のアクティブ測定値を測定することができます。プロトコル（TWAMP）[RFC5357]）、および測定フレームワーク（IPPMなど）、対応する運用上の問題。これらのメトリックを推定するために使用される潜在的な情報フローの図を図1に示します。セクション6では、運用上の問題とネットワークがそれらにどのように対処するかについて詳しく説明します。
+--------+ +--------+ +--------+
| Client | | Client | | Client |
+----^---+ +---^----+ +---^----+
| | |
+-----------|-----------+
|ALTO Protocol
|
|
+--+-----+ retrieval +-----------+
| ALTO |<----------------| Routing |
| Server | and aggregation| Protocols |
| |<-------------+ | |
+--------+ | +-----------+
|
| +------------+
| |Performance |
---| Monitoring |
| Tools |
+------------+
Figure 1: A Framework to Compute Estimation of Performance Metrics
図1：パフォーマンスメトリックの推定を計算するためのフレームワーク
There can be multiple options available when choosing the "cost-source" category; the operator of an ALTO server will make that choice. If a metric does not include a "cost-source" value, the application MUST assume that the value of "cost-source" is the most generic source, i.e., "estimation".
「コストソース」カテゴリを選択する際には、複数のオプションを使用できます。ALTOサーバーのオペレーターがその選択をします。メトリックに「コストソース」値が含まれていない場合、アプリケーションは「コストソース」の値が最も一般的なソース、つまり「推定」であると想定する必要があります。
The measurement of a performance metric often yields a set of samples from an observation distribution [Prometheus], instead of a single value. A statistical operator is applied to the samples to obtain a value to be reported to the client. Multiple statistical operators (e.g., min, median, and max) are commonly being used.
パフォーマンスメトリックの測定により、多くの場合、単一の値ではなく、観測分布[Prometheus]から一連のサンプルが得られます。統計演算子がサンプルに適用され、クライアントに報告される値を取得します。複数の統計演算子（Min、Median、Maxなど）が一般的に使用されています。
Hence, this document extends the general ASCII alphanumeric cost metric strings, formally specified as the CostMetric type defined in Section 10.6 of [RFC7285], as follows:
したがって、このドキュメントは、次のように、[RFC7285]のセクション10.6で定義されているコストメトリックタイプとして正式に指定された一般的なASCII英数字コストメトリック文字列を拡張します。
A cost metric string consists of a base metric identifier (or base identifier for short) string, followed by an optional statistical operator string, connected by the ASCII colon character (':', U+003A), if the statistical operator string exists. The total length of the cost metric string MUST NOT exceed 32, as required by [RFC7285].
コストメトリック文字列は、統計演算子文字列が存在する場合、ASCIIコロン文字（ '：'、u 003a）で接続されている、ベースメトリック識別子（または略のベース識別子）文字列で構成され、その後にオプションの統計演算子文字列が続きます。[RFC7285]で要求されるように、コストメトリック文字列の合計長さは32を超えてはなりません。
The statistical operator string MUST be one of the following:
統計演算子の文字列は、次のいずれかでなければなりません。
cur:
CUR：
The instantaneous observation value of the metric from the most recent sample (i.e., the current value).
最新のサンプルからのメトリックの瞬間的な観測値（つまり、現在の値）。
percentile, with the letter 'p' followed by a number:
パーセンタイル、文字「P」に続いて数字が続きます。
Gives the percentile specified by the number following the letter 'p'. The number MUST be a non-negative JSON number in the range [0, 100] (i.e., greater than or equal to 0 and less than or equal to 100), followed by an optional decimal part, if higher precision is needed. The decimal part should start with the '.' separator (U+002E) and be followed by a sequence of one or more ASCII numbers between '0' and '9'. Assume that this number is y, and consider the case where the samples are coming from a random variable X. The metric then returns x, such that the probability of X is less than or equal to x, i.e., Prob(X <= x), = y/100. For example, delay-ow:p99 gives the 99th percentile of observed one-way delay; delay-ow:p99.9 gives the 99.9th percentile. Note that some systems use quantile, which is in the range [0, 1]. When there is a more common form for a given percentile, it is RECOMMENDED that the common form be used; that is, instead of p0, use min; instead of p50, use median; instead of p100, use max.
文字「P」に続く番号で指定されたパーセンタイルを与えます。数値は、[0、100]（つまり、0以上、100以下の等）の範囲内の非陰性JSON数でなければなりません。小数部は「。」から始める必要があります。セパレーター（U 002E）に続いて、「0」と「9」の間に1つ以上のASCII番号のシーケンスが続きます。この数値がyであると仮定し、サンプルがランダム変数xから来る場合を考えてみましょう。メトリックはxを返し、xの確率がx、つまりprob（x <= xよりも等しくなります。）、= y/100。たとえば、遅延-OW：P99は、観測された一元配置遅延の99パーセンタイルを与えます。遅延-OW：P99.9は99.9パーセンタイルを与えます。一部のシステムは、範囲内にある分位を使用していることに注意してください[0、1]。特定のパーセンタイルにより一般的なフォームがある場合、共通の形式を使用することをお勧めします。つまり、p0の代わりにminを使用します。P50の代わりに、中央値を使用します。P100の代わりに、Maxを使用します。
min:
分：
The minimal value of the observations.
観測値の最小値。
max:
マックス：
The maximal value of the observations.
観測値の最大値。
median:
中央値：
The midpoint (i.e., p50) of the observations.
観測の中間点（すなわち、p50）。
mean:
平均：
The arithmetic mean value of the observations.
観測値の算術平均値。
stddev:
stddev：
The standard deviation of the observations.
観測の標準偏差。
stdvar:
stdvar：
The standard variance of the observations.
観測の標準的な分散。
Examples of cost metric strings then include "delay-ow", "delay-ow:min", and "delay-ow:p99", where "delay-ow" is the base metric identifier string; "min" and "p99" are example statistical operator strings.
コストメトリック文字列の例には、「遅延-ow」、「遅延-ow：min」、および「遅延-ow：p99」が含まれます。ここで、「遅延ow」はベースメトリック識別子文字列です。「MIN」と「P99」は、統計演算子の例です。
If a cost metric string does not have the optional statistical operator string, the statistical operator SHOULD be interpreted as the default statistical operator in the definition of the base metric. If the definition of the base metric does not provide a definition for the default statistical operator, the metric MUST be considered the median value.
コストメトリック文字列にオプションの統計演算子文字列がない場合、統計演算子は、ベースメトリックの定義でデフォルトの統計演算子として解釈する必要があります。ベースメトリックの定義がデフォルトの統計演算子の定義を提供しない場合、メトリックは中央値と見なされなければなりません。
Note that [RFC7285] limits the overall cost metric identifier to 32 characters. The cost metric variants with statistical operator suffixes defined by this document are also subject to the same overall 32-character limit, so certain combinations of (long) base metric identifiers and statistical operators will not be representable. If such a situation arises, it could be addressed by defining a new base metric identifier that is an "alias" of the desired base metric, with identical semantics and just a shorter name.
[RFC7285]は、全体のコストメトリック識別子を32文字に制限することに注意してください。このドキュメントで定義された統計演算子の接尾辞を備えたコストメトリックバリアントは、同じ全体的な32文字制限の対象であるため、（長い）ベースメトリック識別子と統計演算子の特定の組み合わせも表現できません。このような状況が発生した場合、目的のベースメトリックの「エイリアス」である新しいベースメトリック識別子を定義することで対処できます。
This section introduces ALTO network performance metrics on one-way delay, round-trip delay, delay variation, packet loss rate, and hop count. They measure the "quality of experience" of the stream of packets sent from a resource provider to a resource consumer. The measurements of each individual packet (pkt) can include the delay from the time when the packet enters the network to the time when the packet leaves the network (pkt.delay), whether the packet is dropped before reaching the destination (pkt.dropped), and the number of network hops that the packet traverses (pkt.hopcount). The semantics of the performance metrics defined in this section are that they are statistics computed from these measurements; for example, the x-percentile of the one-way delay is the x-percentile of the set of delays {pkt.delay} for the packets in the stream.
このセクションでは、一元配置遅延、往復遅延、遅延変動、パケット損失率、およびホップカウントに関するALTOネットワークパフォーマンスメトリックを紹介します。リソースプロバイダーからリソース消費者に送信されたパケットのストリームの「経験の質」を測定します。個々のパケット（PKT）の測定には、パケットがネットワークに入る時までの遅延を含めることができます。）、およびネットワークの数は、パケットが横断する（pkt.hopcount）。このセクションで定義されているパフォーマンスメトリックのセマンティクスは、これらの測定から計算された統計であるということです。たとえば、一元配置遅延のx穴は、ストリーム内のパケットの遅延{pkt.delay}のセットのx穴です。
The base identifier for this performance metric is "delay-ow".
このパフォーマンスメトリックのベース識別子は「遅延ow」です。
The metric value type is a single 'JSONNumber' type value conforming to the number specifications provided in Section 6 of [RFC8259]. The unit is expressed in microseconds. Hence, the number can be a floating-point number to express delay that is smaller than microseconds. The number MUST be non-negative.
メトリック値タイプは、[RFC8259]のセクション6に記載されている数値仕様に準拠する単一の「jsonnumber」タイプの値です。ユニットはマイクロ秒で表されます。したがって、数値は、マイクロ秒よりも小さい遅延を表すための浮動小数点数になる可能性があります。数は非陰性でなければなりません。
Intended Semantics:
意図されたセマンティクス：
To specify the temporal and spatial aggregated delay of a stream of packets from the specified source to the specified destination. The base semantics of the metric is the Unidirectional Delay metric as defined in [RFC8571], [RFC8570], and [RFC7471], but instead of specifying the delay for a link, it is the (temporal) aggregation of the link delays from the source to the destination. A non-normative reference definition of the end-to-end one-way delay metric is provided in [RFC7679]. The spatial aggregation level is specified in the query context, e.g., provider-defined identifier (PID) to PID, or endpoint to endpoint, where the PID is as defined in Section 5.1 of [RFC7285].
指定されたソースから指定された宛先までのパケットのストリームの時間的および空間的な集約された遅延を指定します。メトリックの基本セマンティクスは、[RFC8571]、[RFC8570]、および[RFC7471]で定義されている単方向遅延メトリックですが、リンクの遅延を指定する代わりに、リンクの遅延の（時間的）分解であり、目的地へのソース。[RFC7679]には、エンドツーエンドの一方向遅延メトリックの非規範的な参照定義が提供されています。空間集約レベルは、クエリのコンテキストで指定されています。たとえば、プロバイダー定義識別子（PID）からPID、またはエンドポイントからエンドポイントへのエンドポイント。PIDは[RFC7285]のセクション5.1で定義されています。
Use:
使用：
This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.
このメトリックは、コストメトリック制約属性として、または応答の返されたコストメトリックとして使用できます。
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 239
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-ow"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 247
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-ow"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 10,
"ipv4:198.51.100.34": 20
}
}
}
Figure 2: Delay Value on Source-Destination Endpoint Pairs (Example 1)
図2：ソース照明エンドポイントペアの遅延値（例1）
Note that since the "cost-type" does not include the "cost-source" field, the values are based on "estimation". Since the identifier does not include the statistical operator string component, the values will represent median values.
「コストタイプ」には「コストソース」フィールドは含まれていないため、値は「推定」に基づいていることに注意してください。識別子には統計演算子の文字列コンポーネントが含まれていないため、値は中央値を表します。
Figure 3 shows an example that is similar to Example 1 (Figure 2), but for IPv6.
図3は、例1（図2）に似た例を示していますが、IPv6の場合。
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 252
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-ow"
},
"endpoints": {
"srcs": [
"ipv6:2001:db8:100::1"
],
"dsts": [
"ipv6:2001:db8:100::2",
"ipv6:2001:db8:100::3"
]
}
}
HTTP/1.1 200 OK
Content-Length: 257
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-ow"
}
},
"endpoint-cost-map": {
"ipv6:2001:db8:100::1": {
"ipv6:2001:db8:100::2": 10,
"ipv6:2001:db8:100::3": 20
}
}
}
Figure 3: Delay Value on Source-Destination Endpoint Pairs for IPv6 (Example 1a)
図3：IPv6のソース分配エンドポイントペアの遅延値（例1A）
"nominal":
「名目」：
Typically, network one-way delay does not have a nominal value.
通常、ネットワークの一方向遅延には名目値がありません。
"sla":
「SLA」：
Many networks provide delay-related parameters in their application-level SLAs. It is RECOMMENDED that the "parameters" field of an "sla" one-way delay metric include a link (i.e., a field named "link") providing a URI for the specification of SLA details, if available. Such a specification can be either (1) free text for possible presentation to the user or (2) a formal specification. The format of the specification is outside the scope of this document.
多くのネットワークは、アプリケーションレベルのSLAで遅延関連パラメーターを提供します。「SLA」の一元配置遅延メトリックの「パラメーター」フィールドには、利用可能な場合はSLAの詳細を仕様のためにURIを提供するリンク（つまり、「リンク」という名前のフィールド）を含めることをお勧めします。このような仕様は、ユーザーへのプレゼンテーションの可能性のある無料のテキスト、または（2）正式な仕様です。仕様の形式は、このドキュメントの範囲外です。
"estimation":
"推定"：
The exact estimation method is outside the scope of this document. There can be multiple sources for estimating one-way delay. For example, the ALTO server may estimate the end-to-end delay by aggregation of routing protocol link metrics; the server may also estimate the delay using active, end-to-end measurements -- for example, using the IPPM framework [RFC2330].
正確な推定方法は、このドキュメントの範囲外です。一元配置遅延を推定するための複数のソースがある場合があります。たとえば、ALTOサーバーは、ルーティングプロトコルリンクメトリックの集約により、エンドツーエンドの遅延を推定する場合があります。サーバーは、IPPMフレームワーク[RFC2330]を使用して、アクティブなエンドツーエンドの測定値を使用して遅延を推定することもできます。
If the estimation is computed by aggregation of routing protocol link metrics (e.g., Unidirectional Link Delay metrics for OSPF [RFC7471], IS-IS [RFC8570], or BGP-LS [RFC8571]), it is RECOMMENDED that the "parameters" field of an "estimation" one-way delay metric include the following information: (1) the RFC defining the routing protocol metrics (e.g., see [RFC7471] for derived metrics), (2) configurations of the routing link metrics such as configured intervals, and (3) the aggregation method from link metrics to end-to-end metrics. During aggregation from link metrics to end-to-end metrics, the server should be cognizant of potential issues when computing an end-to-end summary statistic from link statistics. The default end-to-end average one-way delay is the sum of average link one-way delays. If an ALTO server provides the min and max statistical operators for the one-way delay metric, the values can be computed directly from the routing link metrics, as [RFC7471], [RFC8570], and [RFC8571] provide Min/Max Unidirectional Link Delay.
推定がルーティングプロトコルリンクメトリックの集約によって計算される場合（たとえば、OSPFの単方向リンク遅延メトリック[RFC7471]、IS-IS [RFC8570]、またはBGP-LS [RFC8571]）、「パラメータ」が「パラメータ」を推奨することをお勧めします。「推定」の一元配置遅延メトリックには、次の情報が含まれます。（1）RFCがルーティングプロトコルメトリックを定義する（例：派生メトリックについては[RFC7471]を参照）、（2）構成された間隔などのルーティングリンクメトリックの構成、および（3）リンクメトリックからエンドツーエンドメトリックへの集約方法。リンクメトリックからエンドツーエンドメトリックへの集約中、リンク統計からエンドツーエンドの要約統計を計算する際に、サーバーは潜在的な問題を認識する必要があります。デフォルトのエンドツーエンドの平均片道遅延は、平均リンクの一方向遅延の合計です。ALTOサーバーが一方向遅延メトリックに最小および最大統計演算子を提供する場合、[RFC7471]、[RFC8570]、および[RFC8571]がMIN/MAX単方向リンクを提供するように、ルーティングリンクメトリックから値を直接計算できます。遅れ。
If the estimation is from the IPPM measurement framework, it is RECOMMENDED that the "parameters" field of an "estimation" one-way delay metric include the URI in the "URI" field of the IPPM metric defined in the IPPM "Performance Metrics" registry [IANA-IPPM] (e.g., <https://www.iana.org/assignments/performance-metrics/ OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_95Percentile>). The IPPM metric MUST be one-way delay (i.e., IPPM OWDelay* metrics). The statistical operator of the ALTO metric MUST be consistent with the IPPM statistical property (e.g., 95th percentile).
推定がIPPM測定フレームワークからのものである場合、「推定」の「推定」の「パラメーター」フィールドには、IPPM「パフォーマンスメトリック」で定義されたIPPMメトリックの「URI」フィールドにURIを含めることが推奨されます。レジストリ[iana-ippm]（例えば、<https://www.iana.org/assignments/performance-metrics/ owdelay_active_ip-udp-poisson-payload250b_rfc8912sec7_seconds_95percentile>）。IPPMメトリックは、一元配置遅延（つまり、IPPM OWDELAY*メトリック）である必要があります。ALTOメトリックの統計演算子は、IPPM統計的特性（例：95パーセンタイル）と一致する必要があります。
The base identifier for this performance metric is "delay-rt".
このパフォーマンスメトリックのベース識別子は「遅延RT」です。
The metric value type is a single 'JSONNumber' type value conforming to the number specifications provided in Section 6 of [RFC8259]. The number MUST be non-negative. The unit is expressed in microseconds.
メトリック値タイプは、[RFC8259]のセクション6に記載されている数値仕様に準拠する単一の「jsonnumber」タイプの値です。数は非陰性でなければなりません。ユニットはマイクロ秒で表されます。
Intended Semantics:
意図されたセマンティクス：
To specify temporal and spatial aggregated round-trip delay between the specified source and specified destination. The base semantics is that it is the sum of the one-way delay from the source to the destination and the one-way delay from the destination back to the source, where the one-way delay is as defined in Section 4.1. A non-normative reference definition of the end-to-end round-trip delay metric is provided in [RFC2681]. The spatial aggregation level is specified in the query context (e.g., PID to PID, or endpoint to endpoint).
指定されたソースと指定された宛先間の時間的および空間的な集約された往復遅延を指定します。基本的なセマンティクスは、ソースから宛先までの一方向遅延の合計であり、宛先からソースへの一方向遅延の合計であるということです。セクション4.1で一方向遅延が定義されているとおりです。[RFC2681]には、エンドツーエンドの往復遅延メトリックの非規範的な参照定義が提供されています。空間集約レベルは、クエリコンテキストで指定されています（たとえば、PIDからPID、またはエンドポイントからエンドポイント）。
Note that it is possible for a client to query two one-way delay (delay-ow) items and then compute the round-trip delay. The server should be cognizant of the consistency of values.
クライアントが2つの片道遅延（遅延-OW）アイテムを照会してから、往復遅延を計算できることに注意してください。サーバーは、値の一貫性を認識する必要があります。
Use:
使用：
This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.
このメトリックは、コストメトリック制約属性として、または応答の返されたコストメトリックとして使用できます。
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-rt"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 245
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-rt"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 4,
"ipv4:198.51.100.34": 3
}
}
}
Figure 4: Round-Trip Delay of Source-Destination Endpoint Pairs (Example 2)
図4：ソース照射エンドポイントペアの往復遅延（例2）
"nominal":
「名目」：
Typically, network round-trip delay does not have a nominal value.
通常、ネットワークの往復遅延には名目値がありません。
"sla":
「SLA」：
See the "sla" entry in Section 4.1.4.
セクション4.1.4の「SLA」エントリを参照してください。
"estimation":
"推定"：
See the "estimation" entry in Section 4.1.4. For estimation by aggregation of routing protocol link metrics, the aggregation should include all links from the source to the destination and then back to the source; for estimation using IPPM, the IPPM metric MUST be round-trip delay (i.e., IPPM RTDelay* metrics). The statistical operator of the ALTO metric MUST be consistent with the IPPM statistical property (e.g., 95th percentile).
セクション4.1.4の「推定」エントリを参照してください。ルーティングプロトコルリンクメトリックの集約による推定のために、集約にはソースから宛先へのすべてのリンクを含める必要があります。IPPMを使用した推定では、IPPMメトリックは往復遅延（つまり、IPPM rtdelay*メトリック）でなければなりません。ALTOメトリックの統計演算子は、IPPM統計的特性（例：95パーセンタイル）と一致する必要があります。
The base identifier for this performance metric is "delay-variation".
このパフォーマンスメトリックのベース識別子は「遅延変動」です。
The metric value type is a single 'JSONNumber' type value conforming to the number specifications provided in Section 6 of [RFC8259]. The number MUST be non-negative. The unit is expressed in microseconds.
メトリック値タイプは、[RFC8259]のセクション6に記載されている数値仕様に準拠する単一の「jsonnumber」タイプの値です。数は非陰性でなければなりません。ユニットはマイクロ秒で表されます。
Intended Semantics:
意図されたセマンティクス：
To specify temporal and spatial aggregated delay variation (also called delay jitter) with respect to the minimum delay observed on the stream over the one-way delay from the specified source and destination, where the one-way delay is as defined in Section 4.1. A non-normative reference definition of the end-to-end one-way delay variation metric is provided in [RFC3393]. Note that [RFC3393] allows the specification of a generic selection function F to unambiguously define the two packets selected to compute delay variations. This document defines the specific case where F selects the packet with the smallest one-way delay as the "first" packet. The spatial aggregation level is specified in the query context (e.g., PID to PID, or endpoint to endpoint).
指定されたソースと宛先からの一方向遅延上のストリームで観察された最小遅延に関して、一元配置遅延上の一方向遅延上で、一方向遅延がセクション4.1で定義されているように、ストリームで観察された最小遅延に関して、時間的および空間的集約された遅延変動（遅延ジッターとも呼ばれます）を指定します。[RFC3393]には、エンドツーエンドの一方向遅延変動メトリックの非規範的な参照定義が提供されています。[RFC3393]により、一般的な選択関数fの仕様により、選択した2つのパケットが遅延変動を計算することを明確に定義できることに注意してください。このドキュメントでは、Fが「最初の」パケットとして最小の一方向遅延でパケットを選択する特定のケースを定義します。空間集約レベルは、クエリコンテキストで指定されています（たとえば、PIDからPID、またはエンドポイントからエンドポイント）。
Note that in statistics, variation is typically evaluated by the distance from samples relative to the mean. In the context of networking, it is more commonly defined from samples relative to the min. This definition follows the networking convention.
統計では、変動は通常、平均に対するサンプルからの距離によって評価されることに注意してください。ネットワーキングのコンテキストでは、MINに対するサンプルからより一般的に定義されています。この定義は、ネットワーキング条約に従います。
Use:
使用：
This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.
このメトリックは、コストメトリック制約属性として、または応答の返されたコストメトリックとして使用できます。
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 245
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-variation"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 252
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-variation"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 0,
"ipv4:198.51.100.34": 1
}
}
}
Figure 5: Delay Variation Value on Source-Destination Endpoint Pairs (Example 3)
図5：ソース照明エンドポイントペアの遅延変動値（例3）
"nominal":
「名目」：
Typically, network delay variation does not have a nominal value.
通常、ネットワーク遅延の変動には名目値はありません。
"sla":
「SLA」：
See the "sla" entry in Section 4.1.4.
セクション4.1.4の「SLA」エントリを参照してください。
"estimation":
"推定"：
See the "estimation" entry in Section 4.1.4. For estimation by aggregation of routing protocol link metrics, the default aggregation of the average of delay variations is the sum of the link delay variations; for estimation using IPPM, the IPPM metric MUST be delay variation (i.e., IPPM OWPDV* metrics). The statistical operator of the ALTO metric MUST be consistent with the IPPM statistical property (e.g., 95th percentile).
セクション4.1.4の「推定」エントリを参照してください。ルーティングプロトコルリンクメトリックの集約による推定では、遅延変動の平均のデフォルトの集約は、リンク遅延変動の合計です。IPPMを使用した推定では、IPPMメトリックは遅延変動（つまり、IPPM OWPDV*メトリック）でなければなりません。ALTOメトリックの統計演算子は、IPPM統計的特性（例：95パーセンタイル）と一致する必要があります。
The base identifier for this performance metric is "lossrate".
このパフォーマンスメトリックのベース識別子は「lossRate」です。
The metric value type is a single 'JSONNumber' type value conforming to the number specifications provided in Section 6 of [RFC8259]. The number MUST be non-negative. The value represents the percentage of packet losses.
メトリック値タイプは、[RFC8259]のセクション6に記載されている数値仕様に準拠する単一の「jsonnumber」タイプの値です。数は非陰性でなければなりません。値は、パケット損失の割合を表します。
Intended Semantics:
意図されたセマンティクス：
To specify the temporal and spatial aggregated one-way packet loss rate from the specified source and the specified destination. The base semantics of the metric is the Unidirectional Link Loss metric as defined in [RFC8571], [RFC8570], and [RFC7471], but instead of specifying the loss for a link, it is the aggregated loss of all links from the source to the destination. The spatial aggregation level is specified in the query context (e.g., PID to PID, or endpoint to endpoint).
指定されたソースと指定された宛先から、時間的および空間的な集約された一方向パケット損失率を指定します。メトリックの基本セマンティクスは、[RFC8571]、[RFC8570]、および[RFC7471]で定義されている単方向リンク損失メトリックです。目的地。空間集約レベルは、クエリコンテキストで指定されています（たとえば、PIDからPID、またはエンドポイントからエンドポイント）。
Use:
使用：
This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.
このメトリックは、コストメトリック制約属性として、または応答の返されたコストメトリックとして使用できます。
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "lossrate"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 248
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "lossrate"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 0,
"ipv4:198.51.100.34": 0.01
}
}
}
Figure 6: Loss Rate Value on Source-Destination Endpoint Pairs (Example 4)
図6：ソース照明エンドポイントペアの損失率値（例4）
"nominal":
「名目」：
Typically, the packet loss rate does not have a nominal value, although some networks may specify zero losses.
通常、パケット損失率には名目上の値はありませんが、一部のネットワークでは損失がゼロを指定する場合があります。
"sla":
「SLA」：
See the "sla" entry in Section 4.1.4.
セクション4.1.4の「SLA」エントリを参照してください。
"estimation":
"推定"：
See the "estimation" entry in Section 4.1.4. For estimation by aggregation of routing protocol link metrics, the default aggregation of the average loss rate is the sum of the link loss rates. But this default aggregation is valid only if two conditions are met: (1) link loss rates are low and (2) one assumes that each link's loss events are uncorrelated with every other link's loss events. When loss rates at the links are high but independent, the general formula for aggregating loss, assuming that each link is independent, is to compute end-to-end loss as one minus the product of the success rate for each link. Aggregation when losses at links are correlated can be more complex, and the ALTO server should be cognizant of correlated loss rates. For estimation using IPPM, the IPPM metric MUST be packet loss (i.e., IPPM OWLoss* metrics). The statistical operator of the ALTO metric MUST be consistent with the IPPM statistical property (e.g., 95th percentile).
セクション4.1.4の「推定」エントリを参照してください。ルーティングプロトコルリンクメトリックの集約による推定では、平均損失率のデフォルト集約はリンク損失率の合計です。ただし、このデフォルトの集約は、2つの条件が満たされている場合にのみ有効です。（1）リンクの損失率が低く、（2）各リンクの損失イベントが他のすべてのリンクの損失イベントと無関係であると仮定します。リンクでの損失率が高いが独立している場合、各リンクが独立していると仮定すると、損失を集約するための一般的な式は、各リンクの成功率の積を差し引いてエンドツーエンド損失を計算することです。リンクでの損失が相関する場合の集約はより複雑になり、ALTOサーバーは相関損失率を認識する必要があります。IPPMを使用した推定では、IPPMメトリックはパケット損失（つまり、IPPM Owloss*メトリック）でなければなりません。ALTOメトリックの統計演算子は、IPPM統計的特性（例：95パーセンタイル）と一致する必要があります。
The hop count (hopcount) metric is mentioned in Section 9.2.3 of [RFC7285] as an example. This section further clarifies its properties.
例として、ホップカウント（HopCount）メトリックは[RFC7285]のセクション9.2.3に記載されています。このセクションでは、そのプロパティをさらに明確にします。
The base identifier for this performance metric is "hopcount".
このパフォーマンスメトリックのベース識別子は「HopCount」です。
The metric value type is a single 'JSONNumber' type value conforming to the number specifications provided in Section 6 of [RFC8259]. The number MUST be a non-negative integer (greater than or equal to 0). The value represents the number of hops.
メトリック値タイプは、[RFC8259]のセクション6に記載されている数値仕様に準拠する単一の「jsonnumber」タイプの値です。数値は非陰性整数でなければなりません（0以上）。値はホップ数を表します。
Intended Semantics:
意図されたセマンティクス：
To specify the number of hops in the path from the specified source to the specified destination. The hop count is a basic measurement of distance in a network and can be exposed as the number of router hops computed from the routing protocols originating this information. A hop, however, may represent other units. The spatial aggregation level is specified in the query context (e.g., PID to PID, or endpoint to endpoint).
指定されたソースから指定された宛先までのパス内のホップ数を指定します。ホップカウントは、ネットワーク内の距離の基本的な測定値であり、この情報を発信するルーティングプロトコルから計算されたルーターホップの数として公開できます。ただし、ホップは他のユニットを表す場合があります。空間集約レベルは、クエリコンテキストで指定されています（たとえば、PIDからPID、またはエンドポイントからエンドポイント）。
Use:
使用：
This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.
このメトリックは、コストメトリック制約属性として、または応答の返されたコストメトリックとして使用できます。
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "hopcount"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 245
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "hopcount"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 5,
"ipv4:198.51.100.34": 3
}
}
}
Figure 7: Hop Count Value on Source-Destination Endpoint Pairs (Example 5)
図7：ホップカウントソース照明エンドポイントペアの値（例5）
"nominal":
「名目」：
Typically, the hop count does not have a nominal value.
通常、ホップカウントには名目値がありません。
"sla":
「SLA」：
Typically, the hop count does not have an SLA value.
通常、ホップカウントにはSLA値がありません。
"estimation":
"推定"：
The exact estimation method is outside the scope of this document. An example of estimating hop count values is by importing from IGP routing protocols. It is RECOMMENDED that the "parameters" field of an "estimation" hop count define the meaning of a hop.
正確な推定方法は、このドキュメントの範囲外です。ホップカウント値を推定する例は、IGPルーティングプロトコルからインポートすることです。「推定」ホップカウントの「パラメーター」フィールドがホップの意味を定義することをお勧めします。
This section introduces three metrics related to throughput and bandwidth. Given a specified source and a specified destination, these metrics reflect the volume of traffic that the network can carry from the source to the destination.
このセクションでは、スループットと帯域幅に関連する3つのメトリックを紹介します。指定されたソースと指定された宛先が与えられた場合、これらのメトリックは、ネットワークがソースから宛先に運ぶことができるトラフィックの量を反映しています。
The base identifier for this performance metric is "tput".
このパフォーマンスメトリックのベース識別子は「tput」です。
The metric value type is a single 'JSONNumber' type value conforming to the number specifications provided in Section 6 of [RFC8259]. The number MUST be non-negative. The unit is bytes per second.
メトリック値タイプは、[RFC8259]のセクション6に記載されている数値仕様に準拠する単一の「jsonnumber」タイプの値です。数は非陰性でなければなりません。ユニットは1秒あたりのバイトです。
Intended Semantics:
意図されたセマンティクス：
To give the throughput of a congestion control conforming TCP flow from the specified source to the specified destination. The throughput SHOULD be interpreted as only an estimation, and the estimation is designed only for bulk flows.
指定されたソースから指定された宛先へのTCPフローに適合する混雑制御のスループットを与える。スループットは推定のみとして解釈される必要があり、推定はバルクフロー用にのみ設計されています。
Use:
使用：
This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.
このメトリックは、コストメトリック制約属性として、または応答の返されたコストメトリックとして使用できます。
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 234
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "tput"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 251
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "tput"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 256000,
"ipv4:198.51.100.34": 128000
}
}
}
Figure 8: TCP Throughput Value on Source-Destination Endpoint Pairs (Example 6)
図8：Source-DestinationエンドポイントペアのTCPスループット値（例6）
"nominal":
「名目」：
Typically, TCP throughput does not have a nominal value and SHOULD NOT be generated.
通常、TCPスループットには名目値がなく、生成されるべきではありません。
"sla":
「SLA」：
Typically, TCP throughput does not have an SLA value and SHOULD NOT be generated.
通常、TCPスループットにはSLA値がなく、生成されるべきではありません。
"estimation":
"推定"：
The exact estimation method is outside the scope of this document. It is RECOMMENDED that the "parameters" field of an "estimation" TCP throughput metric include the following information: (1) the congestion control algorithm and (2) the estimation methodology. To specify (1), it is RECOMMENDED that the "parameters" field (object) include a field named "congestion-control-algorithm", which provides a URI for the specification of the algorithm; for example, for an ALTO server to provide estimation of the throughput of a CUBIC congestion control flow, its "parameters" field includes the "congestion-control-algorithm" field, with value being set to the URI for [RFC9438]; for an ongoing congestion control algorithm such as BBR, a link to its specification can be added. To specify (2), the "parameters" field includes as many details as possible; for example, for the TCP Cubic throughout estimation, the "parameters" field specifies that the throughput is estimated by setting _C_ to 0.4, and the equation in [RFC9438], Section 5.1, Figure 8 is applied; as an alternative, the methodology may be based on the NUM model [Prophet] or the model described in [G2]. The exact specification of the "parameters" field is outside the scope of this document.
正確な推定方法は、このドキュメントの範囲外です。「推定」TCPスループットメトリックの「パラメーター」フィールドには、次の情報が含まれることをお勧めします。（1）輻輳制御アルゴリズムと（2）推定方法論。（1）を指定するには、「パラメーター」フィールド（オブジェクト）には、アルゴリズムの仕様にURIを提供する「渋滞制御アルゴリズム」という名前のフィールドを含めることが推奨されます。たとえば、ALTOサーバーが立方輻輳制御フローのスループットの推定を提供するために、その「パラメーター」フィールドには「渋滞制御アルゴリズム」フィールドが含まれ、値は[RFC9438]のURIに設定されています。BBRなどの継続的な混雑制御アルゴリズムの場合、その仕様へのリンクを追加できます。（2）を指定するには、「パラメーター」フィールドにはできるだけ多くの詳細が含まれます。たとえば、推定全体を通してTCPキュービックの場合、「パラメーター」フィールドは、_C_を0.4に設定することでスループットが推定され、[RFC9438]の方程式がセクション5.1、図8が適用されることを指定します。別の方法として、方法論は[G2]で説明されているNUMモデル[預言者]またはモデルに基づいている場合があります。「パラメーター」フィールドの正確な仕様は、このドキュメントの範囲外です。
The base identifier for this performance metric is "bw-residual".
このパフォーマンスメトリックのベース識別子は「bw-residual」です。
The metric value type is a single 'JSONNumber' type value that is non-negative. The unit of measurement is bytes per second.
メトリック値タイプは、非陰性の単一の「jsonnumber」タイプ値です。測定単位は1秒あたりのバイトです。
Intended Semantics:
意図されたセマンティクス：
To specify temporal and spatial residual bandwidth from the specified source to the specified destination. The base semantics of the metric is the Unidirectional Residual Bandwidth metric as defined in [RFC8571], [RFC8570], and [RFC7471], but instead of specifying the residual bandwidth for a link, it is the residual bandwidth of the path from the source to the destination. Hence, it is the minimal residual bandwidth among all links from the source to the destination. When the max statistical operator is defined for the metric, it typically provides the minimum of the link capacities along the path, as the default value of the residual bandwidth of a link is its link capacity [RFC8571] [RFC8570] [RFC7471]. The spatial aggregation unit is specified in the query context (e.g., PID to PID, or endpoint to endpoint).
指定されたソースから指定された宛先までの時間的および空間的な残留帯域幅を指定します。メトリックの基本セマンティクスは、[rfc8571]、[rfc8570]、および[rfc7471]で定義されている一方向の残留帯域幅メトリックですが、リンクの残留帯域幅を指定する代わりに、ソースからの残りの帯域幅であり、経路の経路の残留帯域幅です。目的地へ。したがって、ソースから宛先へのすべてのリンクの中の最小限の残留帯域幅です。最大統計演算子がメトリックに対して定義される場合、リンクの残差帯域幅のデフォルト値はリンク容量[RFC8571] [RFC8570] [RFC7471]です。空間集約ユニットは、クエリのコンテキストで指定されています（たとえば、PIDからPID、またはエンドポイントからエンドポイント）。
The default statistical operator for residual bandwidth is the current instantaneous sample; that is, the default is assumed to be "cur".
残留帯域幅のデフォルトの統計演算子は、現在の瞬間サンプルです。つまり、デフォルトは「cur」であると想定されます。
Use:
使用：
This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.
このメトリックは、コストメトリック制約属性として、または応答の返されたコストメトリックとして使用できます。
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 241
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "bw-residual"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 255
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "bw-residual"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 0,
"ipv4:198.51.100.34": 2000
}
}
}
Figure 9: Residual Bandwidth Value on Source-Destination Endpoint Pairs (Example 7)
図9：ソース照明エンドポイントペアの残留帯域幅値（例7）
"nominal":
「名目」：
Typically, residual bandwidth does not have a nominal value.
通常、残留帯域幅には名目値はありません。
"sla":
「SLA」：
Typically, residual bandwidth does not have an SLA value.
通常、残留帯域幅にはSLA値がありません。
"estimation":
"推定"：
See the "estimation" entry in Section 4.1.4. The current ("cur") residual bandwidth of a path is the minimal residual bandwidth of all links on the path.
セクション4.1.4の「推定」エントリを参照してください。パスの電流（「cur」）残留帯域幅は、パス上のすべてのリンクの最小限の残留帯域幅です。
The base identifier for this performance metric is "bw-available".
このパフォーマンスメトリックのベース識別子は「BW利用可能」です。
The metric value type is a single 'JSONNumber' type value that is non-negative. The unit of measurement is bytes per second.
メトリック値タイプは、非陰性の単一の「jsonnumber」タイプ値です。測定単位は1秒あたりのバイトです。
Intended Semantics:
意図されたセマンティクス：
To specify temporal and spatial available bandwidth from the specified source to the specified destination. The base semantics of the metric is the Unidirectional Available Bandwidth metric as defined in [RFC8571], [RFC8570], and [RFC7471], but instead of specifying the available bandwidth for a link, it is the available bandwidth of the path from the source to the destination. Hence, it is the minimal available bandwidth among all links from the source to the destination. The spatial aggregation unit is specified in the query context (e.g., PID to PID, or endpoint to endpoint).
指定されたソースから指定された宛先までの時間的および空間的に利用可能な帯域幅を指定します。メトリックの基本セマンティクスは、[RFC8571]、[RFC8570]、および[RFC7471]で定義されている単方向の利用可能な帯域幅メトリックですが、リンクの利用可能な帯域幅を指定する代わりに、ソースから利用可能な帯域幅の帯域幅です。目的地へ。したがって、ソースから宛先へのすべてのリンクの中で、利用可能な最小限の帯域幅です。空間集約ユニットは、クエリのコンテキストで指定されています（たとえば、PIDからPID、またはエンドポイントからエンドポイント）。
The default statistical operator for available bandwidth is the current instantaneous sample; that is, the default is assumed to be "cur".
利用可能な帯域幅のデフォルトの統計演算子は、現在の瞬間サンプルです。つまり、デフォルトは「cur」であると想定されます。
Use:
使用：
This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response.
このメトリックは、コストメトリック制約属性として、または応答の返されたコストメトリックとして使用できます。
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 244
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "bw-available"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 255
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "bw-available"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 0,
"ipv4:198.51.100.34": 2000
}
}
}
Figure 10: Available Bandwidth Value on Source-Destination Endpoint Pairs (Example 8)
図10：ソース照明エンドポイントペアで利用可能な帯域幅値（例8）
"nominal":
「名目」：
Typically, available bandwidth does not have a nominal value.
通常、利用可能な帯域幅には名目値がありません。
"sla":
「SLA」：
Typically, available bandwidth does not have an SLA value.
通常、利用可能な帯域幅にはSLA値がありません。
"estimation":
"推定"：
See the "estimation" entry in Section 4.1.4. The current ("cur") available bandwidth of a path is the minimum of the available bandwidth of all links on the path.
セクション4.1.4の「推定」エントリを参照してください。パスの現在（「cur」）利用可能な帯域幅は、パス上のすべてのリンクの利用可能な帯域幅の最小です。
The exact measurement infrastructure, measurement conditions, and computation algorithms can vary between different networks and are outside the scope of this document. Both the ALTO server and the ALTO clients, however, need to be cognizant of the operational issues discussed in the following subsections.
正確な測定インフラストラクチャ、測定条件、および計算アルゴリズムは、ネットワークが異なり、このドキュメントの範囲外である可能性があります。ただし、ALTOサーバーとALTOのクライアントの両方は、以下のサブセクションで議論されている運用上の問題を認識する必要があります。
Also, the performance metrics specified in this document are similar in that they may use similar data sources and have similar issues in their calculation. Hence, this document specifies issues that the performance metrics might have in common and also discusses challenges regarding the computation of ALTO performance metrics (Section 6.4).
また、このドキュメントで指定されたパフォーマンスメトリックは、同様のデータソースを使用し、計算に同様の問題を抱える可能性があるという点で似ています。したがって、このドキュメントは、パフォーマンスメトリックに共通する可能性のある問題を指定し、ALTOパフォーマンスメトリックの計算に関する課題についても説明します（セクション6.4）。
The addition of the "cost-source" field solves a key issue: an ALTO server needs data sources to compute the cost metrics described in this document, and an ALTO client needs to know the data sources to better interpret the values.
「コストソース」フィールドの追加は重要な問題を解決します。ALTOサーバーは、このドキュメントで説明されているコストメトリックを計算するためにデータソースが必要であり、ALTOクライアントは、値をよりよく解釈するためにデータソースを知る必要があります。
To avoid information that is too fine grained, this document introduces "cost-source" to indicate only the high-level types of data sources: "estimation", "nominal", or "sla", where "estimation" is a type of measurement data source, "nominal" is a type of static configuration, and "sla" is a type that is based more on policy.
細かすぎる情報を回避するために、このドキュメントでは、「コストソース」を導入して、高レベルのタイプのデータソースのみを示します。「推定」、「名目」、または「SLA」、「推定」はタイプのタイプです。測定データソース「名目」は静的構成の一種であり、「SLA」はポリシーに基づいたタイプです。
For example, for "estimation", the ALTO server may use log servers or the Operations, Administration, and Maintenance (OAM) system as its data source, as recommended by [RFC7971]. In particular, the cost metrics defined in this document can be computed using routing systems as the data sources.
たとえば、「推定」の場合、ALTOサーバーは、[RFC7971]が推奨するように、ログサーバーまたは操作、管理、およびメンテナンス（OAM）システムをデータソースとして使用する場合があります。特に、このドキュメントで定義されているコストメトリックは、データソースとしてルーティングシステムを使用して計算できます。
Despite the introduction of the additional "cost-context" information, the metrics do not have a field to indicate the timestamps of the data used to compute the metrics. To indicate this attribute, the ALTO server SHOULD return an HTTP Last-Modified value to indicate the freshness of the data used to compute the performance metrics.
追加の「コストコンテキスト」情報の導入にもかかわらず、メトリックにはメトリックの計算に使用されるデータのタイムスタンプを示すフィールドはありません。この属性を示すために、ALTOサーバーは、パフォーマンスメトリックを計算するために使用されるデータの新鮮さを示すためにHTTPラスト修飾値を返す必要があります。
If the ALTO client obtains updates through an incremental update mechanism [RFC8895], the client SHOULD assume that the metric is computed using a snapshot at the time that is approximated by the receiving time.
ALTOクライアントがインクリメンタル更新メカニズム[RFC8895]を介して更新を取得した場合、クライアントは、受信時に近似される時点でスナップショットを使用してメトリックが計算されると仮定する必要があります。
One potential issue introduced by the optional "cost-source" field is backward compatibility. Consider the case where an IRD defines two "cost-type" entries with the same "cost-mode" and "cost-metric", but one with "cost-source" being "estimation" and the other being "sla". In such a case, an ALTO client that is not aware of the extension will not be able to distinguish between these two types. A similar issue can arise even with a single "cost-type" whose "cost-source" is "sla": an ALTO client that is not aware of this extension will ignore this field and instead consider the metric estimation.
オプションの「コストソース」フィールドによって導入された潜在的な問題の1つは、後方互換性です。IRDが同じ「コストモード」と「コストメトリック」を持つ2つの「コストタイプ」エントリを定義する場合を考えてみましょう。そのような場合、拡張機能を認識していないALTOクライアントは、これら2つのタイプを区別することはできません。同様の問題は、「コストソース」が「SLA」である単一の「コストタイプ」でも発生する可能性があります。この拡張機能を認識していないALTOクライアントは、このフィールドを無視し、代わりにメトリック推定を検討します。
To address the backward-compatibility issue, if a "cost-metric" is "routingcost" and the metric contains a "cost-context" field, then it MUST be "estimation"; if it is not, the client SHOULD reject the information as invalid.
後方互換性の問題に対処するには、「コスト計測」が「ルーティングコスト」であり、メトリックに「コストコンテキスト」フィールドが含まれている場合、「推定」でなければなりません。そうでない場合、クライアントは情報を無効として拒否する必要があります。
The metric values exposed by an ALTO server may result from additional processing of measurements from data sources to compute exposed metrics. This may involve data processing tasks such as aggregating the results across multiple systems, removing outliers, and creating additional statistics. The computation of ALTO performance metrics can present two challenges.
ALTOサーバーによって公開されるメトリック値は、データソースからの測定値の追加処理から生じる可能性があり、露出したメトリックを計算します。これには、複数のシステムにわたって結果を集約し、外れ値を削除し、追加の統計を作成するなどのデータ処理タスクが含まれる場合があります。ALTOパフォーマンスメトリックの計算は、2つの課題を提示できます。
Performance metrics often depend on configuration parameters, and exposing such configuration parameters can help an ALTO client to better understand the exposed metrics. In particular, an ALTO server may be configured to compute a TE metric (e.g., packet loss rate) at fixed intervals, say every T seconds. To expose this information, the ALTO server may provide the client with two pieces of additional information: (1) when the metrics were last computed and (2) when the metrics will be updated (i.e., the validity period of the exposed metric values). The ALTO server can expose these two pieces of information by using the HTTP response headers Last-Modified and Expires.
パフォーマンスメトリックは多くの場合、構成パラメーターに依存し、そのような構成パラメーターを公開すると、ALTOクライアントが露出したメトリックをよりよく理解するのに役立ちます。特に、ALTOサーバーは、固定間隔でTEメトリック（パケット損失率など）を計算するように構成されている場合があります。この情報を公開するために、ALTOサーバーはクライアントに2つの追加情報を提供できます。（1）メトリックが最後に計算されたとき、および（2）メトリックが更新されるとき（つまり、露出したメトリック値の妥当性期間）。ALTOサーバーは、HTTP Response Headersを使用して最後の修正を使用して期限切れにすることにより、これらの2つの情報を公開できます。
An ALTO server may not be able to measure the performance metrics to be exposed. The basic issue is that the "source" information can often be link-level information. For example, routing protocols often measure and report only per-link loss and not end-to-end loss; similarly, routing protocols report link-level available bandwidth and not end-to-end available bandwidth. The ALTO server then needs to aggregate these data to provide an abstract and unified view that can be more useful to applications. The server should be aware that different metrics may use different aggregation computations. For example, the end-to-end latency of a path is the sum of the latencies of the links on the path; the end-to-end available bandwidth of a path is the minimum of the available bandwidth of the links on the path; in contrast, aggregating loss values is complicated by the potential for correlated loss events on different links in the path.
ALTOサーバーは、公開するパフォーマンスメトリックを測定できない場合があります。基本的な問題は、「ソース」情報が多くの場合、リンクレベルの情報になる可能性があることです。たとえば、ルーティングプロトコルは、多くの場合、リンクごとの損失のみを測定および報告し、エンドツーエンドの損失ではありません。同様に、ルーティングプロトコルは、リンクレベルの利用可能な帯域幅を報告し、エンドツーエンドの利用可能な帯域幅ではありません。ALTOサーバーは、これらのデータを集約して、アプリケーションにより便利な抽象的で統一されたビューを提供する必要があります。サーバーは、異なるメトリックが異なる集約計算を使用する可能性があることに注意する必要があります。たとえば、パスのエンドツーエンドのレイテンシは、パス上のリンクのレイテンシの合計です。パスのエンドツーエンドの帯域幅は、パス上のリンクの利用可能な帯域幅の最小値です。対照的に、集約損失値は、パス内のさまざまなリンクで相関する損失イベントの可能性によって複雑になります。
The properties defined in this document present no security considerations beyond those in Section 15 of the base ALTO specification [RFC7285].
このドキュメントで定義されているプロパティは、ベースALTO仕様[RFC7285]のセクション15のセクションを超えたセキュリティ上の考慮事項を提示しません。
However, concerns addressed in Sections 15.1, 15.2, and 15.3 of [RFC7285] remain of utmost importance. Indeed, TE performance is highly sensitive ISP information; therefore, sharing TE metric values in numerical mode requires full mutual confidence between the entities managing the ALTO server and the ALTO client. ALTO servers will most likely distribute numerical TE performance to ALTO clients under strict and formal mutual trust agreements. On the other hand, ALTO clients must be cognizant of the risks attached to such information that they would have acquired outside formal conditions of mutual trust.
ただし、[RFC7285]のセクション15.1、15.2、および15.3で扱われている懸念は、非常に重要です。実際、TEパフォーマンスは非常に敏感なISP情報です。したがって、数値モードでTEメトリック値を共有するには、ALTOサーバーとALTOクライアントを管理するエンティティ間で完全な相互信頼が必要です。Alto Serversは、厳格かつ正式な相互信頼契約の下で、数値のTEパフォーマンスをALTOクライアントに分配する可能性が最も高くなります。一方、ALTOのクライアントは、相互信頼の正式な条件以外で取得したであろうそのような情報に付随するリスクを認識しなければなりません。
To mitigate confidentiality risks during information transport of TE performance metrics, the operator should address the risk of ALTO information being leaked to malicious clients or third parties through such attacks as person-in-the-middle (PITM) attacks. As specified in Section 15.3.2 ("Protection Strategies") of [RFC7285], the ALTO server should authenticate ALTO clients when transmitting an ALTO information resource containing sensitive TE performance metrics. Section 8.3.5 ("Authentication and Encryption") of [RFC7285] specifies that ALTO server implementations as well as ALTO client implementations MUST support the "https" URI scheme [RFC9110] and Transport Layer Security (TLS) [RFC8446].
TEパフォーマンスメトリックの情報輸送中に機密性のリスクを緩和するために、オペレーターは、中間者（PITM）攻撃などの攻撃を通じて、悪意のあるクライアントまたは第三者にALTO情報がリークされるリスクに対処する必要があります。[RFC7285]のセクション15.3.2（「保護戦略」）で指定されているように、ALTOサーバーは、機密性の高いTEパフォーマンスメトリックを含むALTO情報リソースを送信する際にALTOクライアントを認証する必要があります。[RFC7285]のセクション8.3.5（「認証と暗号化」）は、ALTOサーバーの実装とALTOクライアントの実装が「HTTPS」URIスキーム[RFC9110]および輸送層セキュリティ（TLS）[RFC8446]をサポートする必要があることを指定しています。
IANA created and now maintains the "ALTO Cost Metrics" registry, as listed in [RFC7285], Section 14.2, Table 3. This registry is located at <https://www.iana.org/assignments/alto-protocol/>. IANA has added the following entries to the "ALTO Cost Metrics" registry.
IANAは、[RFC7285]、セクション14.2、表3にリストされている「ALTOコストメトリック」レジストリを作成し、維持しています。このレジストリは<https://www.iana.org/assignments/alto-protocol/>にあります。IANAは、「ALTOコストメトリック」レジストリに次のエントリを追加しました。
+=================+====================+===========+
| Identifier | Intended Semantics | Reference |
+=================+====================+===========+
| delay-ow | See Section 4.1 | RFC 9439 |
+-----------------+--------------------+-----------+
| delay-rt | See Section 4.2 | RFC 9439 |
+-----------------+--------------------+-----------+
| delay-variation | See Section 4.3 | RFC 9439 |
+-----------------+--------------------+-----------+
| lossrate | See Section 4.4 | RFC 9439 |
+-----------------+--------------------+-----------+
| hopcount | See Section 4.5 | RFC 9439 |
+-----------------+--------------------+-----------+
| tput | See Section 5.1 | RFC 9439 |
+-----------------+--------------------+-----------+
| bw-residual | See Section 5.2 | RFC 9439 |
+-----------------+--------------------+-----------+
| bw-available | See Section 5.3 | RFC 9439 |
+-----------------+--------------------+-----------+
Table 2: ALTO Cost Metrics Registry
表2：ALTOコストメトリックレジストリ
IANA has created the "ALTO Cost Source Types" registry. This registry serves two purposes. First, it ensures the uniqueness of identifiers referring to ALTO cost source types. Second, it provides references to particular semantics of allocated cost source types to be applied by both ALTO servers and applications utilizing ALTO clients.
IANAは「ALTOコストソースタイプ」レジストリを作成しました。このレジストリは2つの目的を果たします。まず、ALTOコストソースタイプを指す識別子の一意性を保証します。第二に、ALTOサーバーとALTOクライアントを利用してアプリケーションの両方で適用される割り当てられたコストソースタイプの特定のセマンティクスへの参照を提供します。
A new ALTO cost source type can be added after IETF Review [RFC8126], to ensure that proper documentation regarding the new ALTO cost source type and its security considerations has been provided. The RFC(s) documenting the new cost source type should be detailed enough to provide guidance to both ALTO service providers and applications utilizing ALTO clients as to how values of the registered ALTO cost source type should be interpreted. Updates and deletions of ALTO cost source types follow the same procedure.
IETFレビュー[RFC8126]の後に新しいALTOコストソースタイプを追加することができ、新しいALTOコストソースタイプとそのセキュリティに関する考慮事項に関する適切なドキュメントが提供されるようにします。新しいコスト源タイプを文書化するRFCは、ALTOサービスプロバイダーとALTOのクライアントを利用して、登録されたALTOコスト源タイプの値をどのように解釈するかについてのアプリケーションの両方にガイダンスを提供するのに十分な詳細を確認する必要があります。ALTOコストソースタイプの更新と削除は、同じ手順に従います。
Registered ALTO address type identifiers MUST conform to the syntactical requirements specified in Section 3.1. Identifiers are to be recorded and displayed as strings.
登録されたALTOアドレスタイプ識別子は、セクション3.1で指定された構文要件に準拠する必要があります。識別子は、文字列として記録および表示されます。
Requests to add a new value to the registry MUST include the following information:
レジストリに新しい値を追加するリクエストには、次の情報を含める必要があります。
Identifier:
識別子：
The name of the desired ALTO cost source type.
目的のALTOコストソースタイプの名前。
Intended Semantics:
意図されたセマンティクス：
ALTO cost source types carry with them semantics to guide their usage by ALTO clients. Hence, a document defining a new type should provide guidance to both ALTO service providers and applications utilizing ALTO clients as to how values of the registered ALTO endpoint property should be interpreted.
ALTOコストソースタイプには、ALTOクライアントによる使用法を導くためのセマンティクスが含まれます。したがって、新しいタイプを定義するドキュメントは、ALTOサービスプロバイダーとALTOのクライアントを利用して、登録されたALTOエンドポイントプロパティの価値をどのように解釈するかについてのアプリケーションの両方にガイダンスを提供する必要があります。
Security Considerations:
セキュリティ上の考慮事項：
ALTO cost source types expose information to ALTO clients. ALTO service providers should be made aware of the security ramifications related to the exposure of a cost source type.
ALTOコストソースタイプは、情報をALTOクライアントに公開します。ALTOサービスプロバイダーは、コスト源タイプの露出に関連するセキュリティの影響を認識する必要があります。
IANA has registered the identifiers "nominal", "sla", and "estimation" as listed in the table below.
IANAは、下の表にリストされているように、識別子「名目」、「SLA」、および「推定」を登録しています。
+============+=========================+================+===========+
| Identifier | Intended | Security | Reference |
| | Semantics | Considerations | |
+============+=========================+================+===========+
| nominal | Values in nominal | Section 7 | RFC 9439 |
| | cases | | |
| | (Section 3.1) | | |
+------------+-------------------------+----------------+-----------+
| sla | Values reflecting | Section 7 | RFC 9439 |
| | Service Level | | |
| | Agreement | | |
| | (Section 3.1) | | |
+------------+-------------------------+----------------+-----------+
| estimation | Values by | Section 7 | RFC 9439 |
| | estimation | | |
| | (Section 3.1) | | |
+------------+-------------------------+----------------+-----------+
Table 3: ALTO Cost Source Types Registry
表3：ALTOコストソースタイプレジストリ
[IANA-IPPM]
IANA, "Performance Metrics",
<https://www.iana.org/assignments/performance-metrics/>.
[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>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390,
DOI 10.17487/RFC6390, October 2011,
<https://www.rfc-editor.org/info/rfc6390>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
IGP Traffic Engineering Performance Metric Extensions",
RFC 8571, DOI 10.17487/RFC8571, March 2019,
<https://www.rfc-editor.org/info/rfc8571>.
[RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic
Optimization (ALTO) Incremental Updates Using Server-Sent
Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November
2020, <https://www.rfc-editor.org/info/rfc8895>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9438] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed.,
"CUBIC for Fast and Long-Distance Networks", RFC 9438,
DOI 10.17487/RFC9438, August 2023,
<https://www.rfc-editor.org/info/rfc9438>.
[FlowDirector]
Pujol, E., Poese, I., Zerwas, J., Smaragdakis, G., and A.
Feldmann, "Steering Hyper-Giants' Traffic at Scale", ACM
CoNEXT '19, December 2019.
[G2] Ros-Giralt, J., Bohara, A., Yellamraju, S., Harper
Langston, M., Lethin, R., Jiang, Y., Tassiulas, L., Li,
J., Tan, Y., and M. Veeraraghavan, "On the Bottleneck
Structure of Congestion-Controlled Networks", Proceedings
of the ACM on Measurement and Analysis of Computing
Systems, Vol. 3, No. 3, Article No. 59, pp. 1-31,
DOI 10.1145/3366707, December 2019,
<https://dl.acm.org/doi/10.1145/3366707>.
[Prometheus]
Volz, J. and B. Rabenstein, "Prometheus: A Next-Generation
Monitoring System (Talk)", SREcon15 Europe, May 2015.
[Prophet] Zhang, J., Gao, K., Yang, YR., and J. Bi, "Prophet: Toward
Fast, Error-Tolerant Model-Based Throughput Prediction for
Reactive Flows in DC Networks", IEEE/ACM Transactions on
Networking, Volume 28, Issue 601, pp. 2475-2488, December
2020, <https://dl.acm.org/doi/10.1109/TNET.2020.3016838>.
[QUIC-THROUGHPUT-TESTING]
Corre, K., "Framework for QUIC Throughput Testing", Work
in Progress, Internet-Draft, draft-corre-quic-throughput-
testing-00, 17 September 2021,
<https://datatracker.ietf.org/doc/html/draft-corre-quic-
throughput-testing-00>.
[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>.
[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>.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002,
<https://www.rfc-editor.org/info/rfc3393>.
[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>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and
S. Previdi, "Application-Layer Traffic Optimization (ALTO)
Deployment Considerations", RFC 7971,
DOI 10.17487/RFC7971, October 2016,
<https://www.rfc-editor.org/info/rfc7971>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
The authors of this document would like to thank Martin Duke for the highly informative, thorough AD reviews and comments. We thank Christian Amsüss, Elwyn Davies, Haizhou Du, Kai Gao, Geng Li, Lili Liu, Danny Alex Lachos Perez, and Brian Trammell for their reviews and comments. We thank Benjamin Kaduk, Erik Kline, Francesca Palombini, Lars Eggert, Martin Vigoureux, Murray Kucherawy, Roman Danyliw, Zaheduzzaman Sarker, and Éric Vyncke for discussions and comments that improved this document.
この文書の著者は、非常に有益で徹底的な広告レビューとコメントについて、マーティンデュークに感謝したいと思います。ChristianAmsüss、Elwyn Davies、Haizhou Du、Kai Gao、Geng Li、Lili Liu、Danny Alex Lachos Perez、およびBrian Trammellのレビューとコメントに感謝します。ベンジャミン・カドゥク、エリック・クライン、フランチェスカ・パロビニ、ラース・エガート、マーティン・ヴィゴレックス、マレー・クチェラウィ、ローマン・ダニリウ、ザヘダッツァマン・サルカー、エリック・ヴィンケに、この文書を改善した議論とコメントに感謝します。
Qin Wu
Huawei
Yuhua District
101 Software Avenue
Nanjing
Jiangsu, 210012
China
Email: bill.wu@huawei.com
Y. Richard Yang
Yale University
51 Prospect St.
New Haven, CT 06520
United States of America
Email: yry@cs.yale.edu
Young Lee
Samsung
Email: younglee.tx@gmail.com
Dhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.com
Sabine Randriamasy
Nokia Networks France
France
Email: sabine.randriamasy@nokia-bell-labs.com
Luis Miguel Contreras Murillo
Telefonica
Madrid
Spain
Email: luismiguel.contrerasmurillo@telefonica.com