| < draft-ietf-alto-performance-metrics-27.txt | draft-ietf-alto-performance-metrics-28.txt > | |||
|---|---|---|---|---|
| ALTO Working Group Q. Wu | ALTO Working Group Q. Wu | |||
| Internet-Draft Huawei | Internet-Draft Huawei | |||
| Intended status: Standards Track Y. Yang | Intended status: Standards Track Y. Yang | |||
| Expires: 21 September 2022 Yale University | Expires: 22 September 2022 Yale University | |||
| Y. Lee | Y. Lee | |||
| Samsung | Samsung | |||
| D. Dhody | D. Dhody | |||
| Huawei | Huawei | |||
| S. Randriamasy | S. Randriamasy | |||
| Nokia Bell Labs | Nokia Bell Labs | |||
| L. Contreras | L. Contreras | |||
| Telefonica | Telefonica | |||
| 20 March 2022 | 21 March 2022 | |||
| ALTO Performance Cost Metrics | ALTO Performance Cost Metrics | |||
| draft-ietf-alto-performance-metrics-27 | draft-ietf-alto-performance-metrics-28 | |||
| Abstract | Abstract | |||
| The cost metric is a basic concept in Application-Layer Traffic | The cost metric is a basic concept in Application-Layer Traffic | |||
| Optimization (ALTO), and different applications may use different | Optimization (ALTO), and different applications may use different | |||
| types of cost metrics. Since the ALTO base protocol (RFC 7285) | types of cost metrics. Since the ALTO base protocol (RFC 7285) | |||
| defines only a single cost metric (namely, the generic "routingcost" | defines only a single cost metric (namely, the generic "routingcost" | |||
| metric), if an application wants to issue a cost map or an endpoint | metric), if an application wants to issue a cost map or an endpoint | |||
| cost request in order to identify a resource provider that offers | cost request in order to identify a resource provider that offers | |||
| better performance metrics (e.g., lower delay or loss rate), the base | better performance metrics (e.g., lower delay or loss rate), the base | |||
| skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
| This document addresses this issue by extending the specification to | This document addresses this issue by extending the specification to | |||
| provide a variety of network performance metrics, including network | provide a variety of network performance metrics, including network | |||
| delay, delay variation (a.k.a, jitter), packet loss rate, hop count, | delay, delay variation (a.k.a, jitter), packet loss rate, hop count, | |||
| and bandwidth. | and bandwidth. | |||
| There are multiple sources (e.g., estimation based on measurements or | There are multiple sources (e.g., estimation based on measurements or | |||
| service-level agreement) to derive a performance metric. This | service-level agreement) to derive a performance metric. This | |||
| document introduces an additional "cost-context" field to the ALTO | document introduces an additional "cost-context" field to the ALTO | |||
| "cost-type" field to convey the source of a performance metric. | "cost-type" field to convey the source of a performance metric. | |||
| Requirements Language | ||||
| 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. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 21 September 2022. | This Internet-Draft will expire on 22 September 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Performance Metric Attributes . . . . . . . . . . . . . . . . 6 | 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 | |||
| 2.1. Performance Metric Context: "cost-context" . . . . . . . 7 | 3. Performance Metric Attributes . . . . . . . . . . . . . . . . 6 | |||
| 2.2. Performance Metric Statistics . . . . . . . . . . . . . . 9 | 3.1. Performance Metric Context: "cost-context" . . . . . . . 7 | |||
| 3. Packet Performance Metrics . . . . . . . . . . . . . . . . . 11 | 3.2. Performance Metric Statistics . . . . . . . . . . . . . . 9 | |||
| 3.1. Cost Metric: One-Way Delay (delay-ow) . . . . . . . . . . 11 | 4. Packet Performance Metrics . . . . . . . . . . . . . . . . . 11 | |||
| 3.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 11 | 4.1. Cost Metric: One-Way Delay (delay-ow) . . . . . . . . . . 11 | |||
| 3.1.2. Value Representation . . . . . . . . . . . . . . . . 12 | 4.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 11 | |||
| 3.1.3. Intended Semantics and Use . . . . . . . . . . . . . 12 | 4.1.2. Value Representation . . . . . . . . . . . . . . . . 12 | |||
| 3.1.4. Cost-Context Specification Considerations . . . . . . 14 | 4.1.3. Intended Semantics and Use . . . . . . . . . . . . . 12 | |||
| 3.2. Cost Metric: Round-trip Delay (delay-rt) . . . . . . . . 16 | 4.1.4. Cost-Context Specification Considerations . . . . . . 14 | |||
| 3.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 16 | 4.2. Cost Metric: Round-trip Delay (delay-rt) . . . . . . . . 16 | |||
| 3.2.2. Value Representation . . . . . . . . . . . . . . . . 16 | 4.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 16 | |||
| 3.2.3. Intended Semantics and Use . . . . . . . . . . . . . 16 | 4.2.2. Value Representation . . . . . . . . . . . . . . . . 16 | |||
| 3.2.4. Cost-Context Specification Considerations . . . . . . 17 | 4.2.3. Intended Semantics and Use . . . . . . . . . . . . . 16 | |||
| 4.2.4. Cost-Context Specification Considerations . . . . . . 17 | ||||
| 3.3. Cost Metric: Delay Variation (delay-variation) . . . . . 18 | 4.3. Cost Metric: Delay Variation (delay-variation) . . . . . 18 | |||
| 3.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 18 | 4.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 18 | |||
| 3.3.2. Value Representation . . . . . . . . . . . . . . . . 18 | 4.3.2. Value Representation . . . . . . . . . . . . . . . . 18 | |||
| 3.3.3. Intended Semantics and Use . . . . . . . . . . . . . 18 | 4.3.3. Intended Semantics and Use . . . . . . . . . . . . . 18 | |||
| 3.3.4. Cost-Context Specification Considerations . . . . . . 19 | 4.3.4. Cost-Context Specification Considerations . . . . . . 19 | |||
| 3.4. Cost Metric: Loss Rate (lossrate) . . . . . . . . . . . . 20 | 4.4. Cost Metric: Loss Rate (lossrate) . . . . . . . . . . . . 20 | |||
| 3.4.1. Base Identifier . . . . . . . . . . . . . . . . . . . 20 | 4.4.1. Base Identifier . . . . . . . . . . . . . . . . . . . 20 | |||
| 3.4.2. Value Representation . . . . . . . . . . . . . . . . 20 | 4.4.2. Value Representation . . . . . . . . . . . . . . . . 20 | |||
| 3.4.3. Intended Semantics and Use . . . . . . . . . . . . . 20 | 4.4.3. Intended Semantics and Use . . . . . . . . . . . . . 20 | |||
| 3.4.4. Cost-Context Specification Considerations . . . . . . 21 | 4.4.4. Cost-Context Specification Considerations . . . . . . 21 | |||
| 3.5. Cost Metric: Hop Count (hopcount) . . . . . . . . . . . . 22 | 4.5. Cost Metric: Hop Count (hopcount) . . . . . . . . . . . . 22 | |||
| 3.5.1. Base Identifier . . . . . . . . . . . . . . . . . . . 22 | 4.5.1. Base Identifier . . . . . . . . . . . . . . . . . . . 22 | |||
| 3.5.2. Value Representation . . . . . . . . . . . . . . . . 22 | 4.5.2. Value Representation . . . . . . . . . . . . . . . . 22 | |||
| 3.5.3. Intended Semantics and Use . . . . . . . . . . . . . 22 | 4.5.3. Intended Semantics and Use . . . . . . . . . . . . . 22 | |||
| 3.5.4. Cost-Context Specification Considerations . . . . . . 23 | 4.5.4. Cost-Context Specification Considerations . . . . . . 23 | |||
| 4. Throughput/Bandwidth Performance Metrics . . . . . . . . . . 24 | 5. Throughput/Bandwidth Performance Metrics . . . . . . . . . . 24 | |||
| 4.1. Cost Metric: TCP Throughput (tput) . . . . . . . . . . . 24 | 5.1. Cost Metric: TCP Throughput (tput) . . . . . . . . . . . 24 | |||
| 4.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 24 | 5.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 24 | |||
| 4.1.2. Value Representation . . . . . . . . . . . . . . . . 24 | 5.1.2. Value Representation . . . . . . . . . . . . . . . . 24 | |||
| 4.1.3. Intended Semantics and Use . . . . . . . . . . . . . 24 | 5.1.3. Intended Semantics and Use . . . . . . . . . . . . . 24 | |||
| 4.1.4. Cost-Context Specification Considerations . . . . . . 25 | 5.1.4. Cost-Context Specification Considerations . . . . . . 25 | |||
| 4.2. Cost Metric: Residual Bandwidth (bw-residual) . . . . . . 26 | 5.2. Cost Metric: Residual Bandwidth (bw-residual) . . . . . . 26 | |||
| 4.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 26 | 5.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 26 | |||
| 4.2.2. Value Representation . . . . . . . . . . . . . . . . 26 | 5.2.2. Value Representation . . . . . . . . . . . . . . . . 26 | |||
| 4.2.3. Intended Semantics and Use . . . . . . . . . . . . . 26 | 5.2.3. Intended Semantics and Use . . . . . . . . . . . . . 26 | |||
| 4.2.4. Cost-Context Specification Considerations . . . . . . 28 | 5.2.4. Cost-Context Specification Considerations . . . . . . 28 | |||
| 4.3. Cost Metric: Available Bandwidth (bw-available) . . . . . 28 | 5.3. Cost Metric: Available Bandwidth (bw-available) . . . . . 28 | |||
| 4.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 28 | 5.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 28 | |||
| 4.3.2. Value Representation . . . . . . . . . . . . . . . . 28 | 5.3.2. Value Representation . . . . . . . . . . . . . . . . 28 | |||
| 4.3.3. Intended Semantics and Use . . . . . . . . . . . . . 29 | 5.3.3. Intended Semantics and Use . . . . . . . . . . . . . 29 | |||
| 4.3.4. Cost-Context Specification Considerations . . . . . . 30 | 5.3.4. Cost-Context Specification Considerations . . . . . . 30 | |||
| 5. Operational Considerations . . . . . . . . . . . . . . . . . 30 | 6. Operational Considerations . . . . . . . . . . . . . . . . . 30 | |||
| 5.1. Source Considerations . . . . . . . . . . . . . . . . . . 31 | 6.1. Source Considerations . . . . . . . . . . . . . . . . . . 31 | |||
| 5.2. Metric Timestamp Consideration . . . . . . . . . . . . . 31 | 6.2. Metric Timestamp Consideration . . . . . . . . . . . . . 31 | |||
| 5.3. Backward Compatibility Considerations . . . . . . . . . . 31 | 6.3. Backward Compatibility Considerations . . . . . . . . . . 31 | |||
| 5.4. Computation Considerations . . . . . . . . . . . . . . . 32 | 6.4. Computation Considerations . . . . . . . . . . . . . . . 32 | |||
| 5.4.1. Configuration Parameters Considerations . . . . . . . 32 | 6.4.1. Configuration Parameters Considerations . . . . . . . 32 | |||
| 5.4.2. Aggregation Computation Considerations . . . . . . . 32 | 6.4.2. Aggregation Computation Considerations . . . . . . . 32 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 35 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 37 | 10.2. Informative References . . . . . . . . . . . . . . . . . 37 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
| 1. Introduction | 1. Introduction | |||
| Application-Layer Traffic Optimization (ALTO) provides a means for | Application-Layer Traffic Optimization (ALTO) provides a means for | |||
| network applications to obtain network information so that the | network applications to obtain network information so that the | |||
| applications can identify efficient application-layer traffic | applications can identify efficient application-layer traffic | |||
| patterns using the networks. Cost metrics are used in both the ALTO | 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 | cost map service and the ALTO endpoint cost service in the ALTO base | |||
| protocol [RFC7285]. | protocol [RFC7285]. | |||
| skipping to change at page 4, line 32 ¶ | skipping to change at page 4, line 23 ¶ | |||
| bandwidth related metrics are defined in the base protocol. | bandwidth related metrics are defined in the base protocol. | |||
| This document registers a set of new cost metrics (Table 1) to allow | This document registers a set of new cost metrics (Table 1) to allow | |||
| applications to determine "where" to connect based on network | applications to determine "where" to connect based on network | |||
| performance criteria including delay and bandwidth related metrics. | performance criteria including delay and bandwidth related metrics. | |||
| +--------------------+-------------+--------------------------------+ | +--------------------+-------------+--------------------------------+ | |||
| | Metric | Definition | Semantics Based On | | | Metric | Definition | Semantics Based On | | |||
| | | in this doc | | | | | in this doc | | | |||
| +--------------------+-------------+--------------------------------+ | +--------------------+-------------+--------------------------------+ | |||
| | One-way Delay | Section 3.1 | Base: [RFC7471,8570,8571] | | | One-way Delay | Section 4.1 | Base: [RFC7471,8570,8571] | | |||
| | | | sum Unidirectional Delay | | | | | sum Unidirectional Delay | | |||
| | Round-trip Delay | Section 3.2 | Base: Sum of two directions | | | Round-trip Delay | Section 4.2 | Base: Sum of two directions | | |||
| | | | from above | | | | | from above | | |||
| | Delay Variation | Section 3.3 | Base: [RFC7471,8570,8571] | | | Delay Variation | Section 4.3 | Base: [RFC7471,8570,8571] | | |||
| | | | sum of Unidirectional Delay | | | | | sum of Unidirectional Delay | | |||
| | | | Variation | | | | | Variation | | |||
| | Loss Rate | Section 3.4 | Base: [RFC7471,8570,8571] | | | Loss Rate | Section 4.4 | Base: [RFC7471,8570,8571] | | |||
| | | | aggr Unidirectional Link Loss | | | | | aggr Unidirectional Link Loss | | |||
| | Residual Bandwidth | Section 4.2 | Base: [RFC7471,8570,8571] | | | Residual Bandwidth | Section 5.2 | Base: [RFC7471,8570,8571] | | |||
| | | | min Unidirectional Residual BW| | | | | min Unidirectional Residual BW| | |||
| | Available Bandwidth| Section 4.3 | Base: [RFC7471,8570,8571] | | | Available Bandwidth| Section 5.3 | Base: [RFC7471,8570,8571] | | |||
| | | | min Unidirectional Avail. BW | | | | | min Unidirectional Avail. BW | | |||
| | | | | | | | | | | |||
| | TCP Throughput | Section 4.1 | [I-D.ietf-tcpm-rfc8312bis] | | | TCP Throughput | Section 5.1 | [I-D.ietf-tcpm-rfc8312bis] | | |||
| | | | | | | | | | | |||
| | Hop Count | Section 3.5 | [RFC7285] | | | Hop Count | Section 4.5 | [RFC7285] | | |||
| +--------------------+-------------+--------------------------------+ | +--------------------+-------------+--------------------------------+ | |||
| Table 1. Cost Metrics Defined in this Document. | Table 1. Cost Metrics Defined in this Document. | |||
| The first 6 metrics listed in Table 1 (i.e., One-way Delay, Round- | The first 6 metrics listed in Table 1 (i.e., One-way Delay, Round- | |||
| trip Delay, Delay Variation, Loss Rate, Residual Bandwidth, and | trip Delay, Delay Variation, Loss Rate, Residual Bandwidth, and | |||
| Available Bandwidth) are derived from the set of traffic engineering | Available Bandwidth) are derived from the set of traffic engineering | |||
| performance metrics commonly defined in OSPF [RFC3630], [RFC7471]; | performance metrics commonly defined in OSPF [RFC3630], [RFC7471]; | |||
| IS-IS [RFC5305], [RFC8570]; and BGP-LS [RFC8571]. Deriving ALTO cost | IS-IS [RFC5305], [RFC8570]; and BGP-LS [RFC8571]. Deriving ALTO cost | |||
| performance metrics from existing network-layer traffic engineering | performance metrics from existing network-layer traffic engineering | |||
| performance metrics, to expose to application-layer traffic | performance metrics, to expose to application-layer traffic | |||
| optimization, can be a typical mechanism by network operators to | optimization, can be a typical mechanism by network operators to | |||
| deploy ALTO [RFC7971], [FlowDirector]. This document defines the | deploy ALTO [RFC7971], [FlowDirector]. This document defines the | |||
| base semantics of these metrics by extending them from link metrics | base semantics of these metrics by extending them from link metrics | |||
| to end-to-end metrics for ALTO. The "Semantics Based On" column | to end-to-end metrics for ALTO. The "Semantics Based On" column | |||
| specifies at a high level how the end-to-end metric is computed from | specifies at a high level how the end-to-end metric is computed from | |||
| link metrics; the details will be specified in the following | link metrics; the details will be specified in the following | |||
| sections. | sections. | |||
| The common metrics Min/Max Unidirectional Delay defined in | The common metrics Min/Max Unidirectional Delay defined in | |||
| [RFC7471,RFC8570,RFC8571] and Max Link Bandwidth defined in | [RFC8570][RFC8571] and Max Link Bandwidth defined in | |||
| [RFC3630,RFC5305] are not listed in Table 1 because they can be | [RFC3630,RFC5305] are not listed in Table 1 because they can be | |||
| handled by applying the statistical operators defined in this | handled by applying the statistical operators defined in this | |||
| document. The metrics related with utilized bandwidth and reservable | document. The metrics related with utilized bandwidth and reservable | |||
| bandwidth (i.e., Max Reservable BW and Unreserved BW defined in | bandwidth (i.e., Max Reservable BW and Unreserved BW defined in | |||
| [RFC3630,RFC5305]) are outside the scope of this document. | [RFC3630,RFC5305]) are outside the scope of this document. | |||
| The 7th metric (the estimated TCP-flow throughput metric) provides an | The 7th metric (the estimated TCP-flow throughput metric) provides an | |||
| estimation of the bandwidth of a TCP flow, using TCP throughput | estimation of the bandwidth of a TCP flow, using TCP throughput | |||
| modeling, to support use cases of adaptive applications [Prophet], | modeling, to support use cases of adaptive applications [Prophet], | |||
| [G2]. | [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 to measure such metrics is more | ||||
| mature (e.g., [I-D.corre-quic-throughput-testing]). | ||||
| The 8th metric (the hop count metric) in Table 1 is mentioned in the | The 8th metric (the hop count metric) in Table 1 is mentioned in the | |||
| ALTO base protocol [RFC7285], but not defined, and this document | ALTO base protocol [RFC7285], but not defined, and this document | |||
| defines it to be complete. | defines it to be complete. | |||
| These 8 performance metrics can be classified into two categories: | These 8 performance metrics can be classified into two categories: | |||
| those derived from the performance of individual packets (i.e., One- | those derived from the performance of individual packets (i.e., One- | |||
| way Delay, Round-trip Delay, Delay Variation, Loss Rate, and Hop | way Delay, Round-trip Delay, Delay Variation, Loss Rate, and Hop | |||
| Count), and those related to bandwidth/throughput (Residual | Count), and those related to bandwidth/throughput (Residual | |||
| bandwidth, and Available Bandwidth, and TCP throughput). These two | bandwidth, and Available Bandwidth, and TCP throughput). These two | |||
| categories are defined in Section 3 and Section 4 respectively. Note | categories are defined in Sections 4 and 5 respectively. Note that | |||
| that all metrics except Round-trip Delay are unidirectional. An ALTO | all metrics except Round-trip Delay are unidirectional. An ALTO | |||
| client will need to query both directions if needed. | client will need to query both directions if needed. | |||
| The purpose of this document is to ensure proper usage of these 8 | The purpose of this document is to ensure proper usage of these 8 | |||
| performance metrics in the context of ALTO. This document follows | performance metrics in the context of ALTO. This document follows | |||
| the guideline defined in Section 14.2 of the ALTO base protocol | the guideline defined in Section 14.2 of the ALTO base protocol | |||
| [RFC7285] on registering ALTO cost metrics. Hence, it specifies the | [RFC7285] on registering ALTO cost metrics. Hence, it specifies the | |||
| identifier, the intended semantics, and the security considerations | identifier, the intended semantics, and the security considerations | |||
| of each one of the metrics specified in Table 1. | of each one of the metrics specified in Table 1. | |||
| The definitions of the intended semantics of the metrics tend to be | The definitions of the intended semantics of the metrics tend to be | |||
| coarse-grained, for guidance only, and they may work well for ALTO. | coarse-grained, for guidance only, and they may work well for ALTO. | |||
| On the other hand, a performance measurement framework, such as the | On the other hand, a performance measurement framework, such as the | |||
| IPPM framework, may provide more details in defining a performance | IP Performance Measurement (IPPM) framework, may provide more details | |||
| metric. This document introduces a mechanism called "cost-context" | in defining a performance metric. This document introduces a | |||
| to provide additional details, when they are available; see | mechanism called "cost-context" to provide additional details, when | |||
| Section 2. | they are available; see Section 3. | |||
| Following the ALTO base protocol, this document uses JSON to specify | Following the ALTO base protocol, this document uses JSON to specify | |||
| the value type of each defined metric. See [RFC8259] for JSON data | the value type of each defined metric. See [RFC8259] for JSON data | |||
| type specification. In particular, [RFC7285] specifies that cost | type specification. In particular, [RFC7285] specifies that cost | |||
| values should be assumed by default as JSONNumber. When defining the | values should be assumed by default as JSONNumber. When defining the | |||
| value representation of each metric in Table 1, this document | value representation of each metric in Table 1, this document | |||
| conforms to [RFC7285], but specifies additional, generic constraints | conforms to [RFC7285], but specifies additional, generic constraints | |||
| on valid JSONNumbers for each metric. For example, each new metric | on valid JSONNumbers for each metric. For example, each new metric | |||
| in Table 1 will be specified as non-negative (>= 0); Hop Count is | in Table 1 will be specified as non-negative (>= 0); Hop Count is | |||
| specified to be an integer. | specified to be an integer. | |||
| skipping to change at page 6, line 37 ¶ | skipping to change at page 6, line 29 ¶ | |||
| them need to be exposed to a given application. When an ALTO server | them need to be exposed to a given application. When an ALTO server | |||
| supports a cost metric defined in this document, it announces the | supports a cost metric defined in this document, it announces the | |||
| metric in its information resource directory (IRD) as defined in | metric in its information resource directory (IRD) as defined in | |||
| Section 9.2 of [RFC7285]. | Section 9.2 of [RFC7285]. | |||
| An ALTO server introducing these metrics should consider related | An ALTO server introducing these metrics should consider related | |||
| security issues. As a generic security consideration on the | security issues. As a generic security consideration on the | |||
| reliability and trust in the exposed metric values, applications | reliability and trust in the exposed metric values, applications | |||
| SHOULD rapidly give up using ALTO-based guidance if they detect that | SHOULD rapidly give up using ALTO-based guidance if they detect that | |||
| the exposed information does not preserve their performance level or | the exposed information does not preserve their performance level or | |||
| even degrades it. Section 6 discusses security considerations in | even degrades it. Section 7 discusses security considerations in | |||
| more detail. | more detail. | |||
| 2. Performance Metric Attributes | 2. Requirements Language | |||
| 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. | ||||
| 3. Performance Metric Attributes | ||||
| The definitions of the metrics in this document are coarse-grained, | The definitions of the metrics in this document are coarse-grained, | |||
| based on network-layer traffic engineering performance metrics, for | based on network-layer traffic engineering performance metrics, for | |||
| guidance only. A fine-grained framework specified in [RFC6390] | guidance only. A fine-grained framework specified in [RFC6390] | |||
| requires that the fine-grained specification of a network performance | requires that the fine-grained specification of a network performance | |||
| metric include 6 components: (i) Metric Name, (ii) Metric | metric include 6 components: (i) Metric Name, (ii) Metric | |||
| Description, (iii) Method of Measurement or Calculation, (iv) Units | Description, (iii) Method of Measurement or Calculation, (iv) Units | |||
| of Measurement, (v) Measurement Points, and (vi) Measurement Timing. | of Measurement, (v) Measurement Points, and (vi) Measurement Timing. | |||
| Requiring that an ALTO server provides precise, fine-grained values | Requiring that an ALTO server provides precise, fine-grained values | |||
| for all 6 components for each metric that it exposes may not be | for all 6 components for each metric that it exposes may not be | |||
| skipping to change at page 7, line 22 ¶ | skipping to change at page 7, line 22 ¶ | |||
| services; for example, endpoint cost service is between the two | services; for example, endpoint cost service is between the two | |||
| endpoints. Hence, the ALTO performance metric identifiers provide | endpoints. Hence, the ALTO performance metric identifiers provide | |||
| basic metric attributes. | basic metric attributes. | |||
| To allow the flexibility of allowing an ALTO server to provide fine- | To allow the flexibility of allowing an ALTO server to provide fine- | |||
| grained information such as Method of Measurement or Calculation, | grained information such as Method of Measurement or Calculation, | |||
| according to its policy and use cases, this document introduces | according to its policy and use cases, this document introduces | |||
| context information so that the server can provide these additional | context information so that the server can provide these additional | |||
| details. | details. | |||
| 2.1. Performance Metric Context: "cost-context" | 3.1. Performance Metric Context: "cost-context" | |||
| The core additional details of a performance metric specify "how" the | The core additional details of a performance metric specify "how" the | |||
| metric is obtained. This is referred to as the source of the metric. | metric is obtained. This is referred to as the source of the metric. | |||
| Specifically, this document defines three types of coarse-grained | Specifically, this document defines three types of coarse-grained | |||
| metric information sources: "nominal", and "sla" (service level | metric information sources: "nominal", and "sla" (service level | |||
| agreement), and "estimation". | agreement), and "estimation". | |||
| For a given type of source, precise interpretation of a performance | For a given type of source, precise interpretation of a performance | |||
| metric value can depend on specific measurement and computation | metric value can depend on specific measurement and computation | |||
| parameters. | parameters. | |||
| skipping to change at page 8, line 19 ¶ | skipping to change at page 8, line 19 ¶ | |||
| resources. | resources. | |||
| The "cost-source" field of the "cost-context" field is defined as a | The "cost-source" field of the "cost-context" field is defined as a | |||
| string consisting of only US-ASCII alphanumeric characters | string consisting of only US-ASCII alphanumeric characters | |||
| (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A). The cost-source | (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A). The cost-source | |||
| is used in this document to indicate a string of this format. | is used in this document to indicate a string of this format. | |||
| As mentioned above, this document defines three values for "cost- | As mentioned above, this document defines three values for "cost- | |||
| source": "nominal", "sla", and "estimation". The "cost-source" field | source": "nominal", "sla", and "estimation". The "cost-source" field | |||
| of the "cost-context" field MUST be one registered in "ALTO Cost | of the "cost-context" field MUST be one registered in "ALTO Cost | |||
| Source Registry" (Section 7). | Source" registry (Section 8). | |||
| The "nominal" category indicates that the metric value is statically | The "nominal" category indicates that the metric value is statically | |||
| configured by the underlying devices. Not all metrics have | configured by the underlying devices. Not all metrics have | |||
| reasonable "nominal" values. For example, throughput can have a | reasonable "nominal" values. For example, throughput can have a | |||
| nominal value, which indicates the configured transmission rate of | nominal value, which indicates the configured transmission rate of | |||
| the involved devices; latency typically does not have a nominal | the involved devices; latency typically does not have a nominal | |||
| value. | value. | |||
| The "sla" category indicates that the metric value is derived from | The "sla" category indicates that the metric value is derived from | |||
| some commitment which this document refers to as service-level | some commitment which this document refers to as service-level | |||
| skipping to change at page 8, line 41 ¶ | skipping to change at page 8, line 41 ¶ | |||
| "committed" values. For an "sla" metric, it is RECOMMENDED that the | "committed" values. For an "sla" metric, it is RECOMMENDED that the | |||
| "parameters" field provide a link to the SLA definition. | "parameters" field provide a link to the SLA definition. | |||
| The "estimation" category indicates that the metric value is computed | The "estimation" category indicates that the metric value is computed | |||
| through an estimation process. An ALTO server may compute | through an estimation process. An ALTO server may compute | |||
| "estimation" values by retrieving and/or aggregating information from | "estimation" values by retrieving and/or aggregating information from | |||
| routing protocols (e.g., [RFC7471], [RFC8570], [RFC8571]), traffic | routing protocols (e.g., [RFC7471], [RFC8570], [RFC8571]), traffic | |||
| measurement management tools (e.g., TWAMP [RFC5357]), and measurement | measurement management tools (e.g., TWAMP [RFC5357]), and measurement | |||
| frameworks (e.g., IPPM), with corresponding operational issues. An | frameworks (e.g., IPPM), with corresponding operational issues. An | |||
| illustration of potential information flows used for estimating these | illustration of potential information flows used for estimating these | |||
| metrics is shown in Figure 1 below. Section 5 discusses in more | metrics is shown in Figure 1. Section 6 discusses in more detail the | |||
| detail the operational issues and how a network may address them. | operational issues and how a network may address them. | |||
| +--------+ +--------+ +--------+ | +--------+ +--------+ +--------+ | |||
| | Client | | Client | | Client | | | Client | | Client | | Client | | |||
| +----^---+ +---^----+ +---^----+ | +----^---+ +---^----+ +---^----+ | |||
| | | | | | | | | |||
| +-----------|-----------+ | +-----------|-----------+ | |||
| North-Bound |ALTO protocol | North-Bound |ALTO protocol | |||
| Interface (NBI)| | Interface (NBI)| | |||
| | | | | |||
| +--+-----+ retrieval +-----------+ | +--+-----+ retrieval +-----------+ | |||
| skipping to change at page 9, line 32 ¶ | skipping to change at page 9, line 32 ¶ | |||
| | Tools | | | Tools | | |||
| +------------+ | +------------+ | |||
| Figure 1. A framework to compute estimation to performance metrics | Figure 1. A framework to compute estimation to performance metrics | |||
| There can be multiple choices in deciding the cost-source category. | There can be multiple choices in deciding the cost-source category. | |||
| It is the operator of an ALTO server who chooses the category. If a | It is the operator of an ALTO server who chooses the category. If a | |||
| metric does not include a "cost-source" value, the application MUST | metric does not include a "cost-source" value, the application MUST | |||
| assume that the value of "cost-source" is the most generic source, | assume that the value of "cost-source" is the most generic source, | |||
| i.e., "estimation". | i.e., "estimation". | |||
| 2.2. Performance Metric Statistics | 3.2. Performance Metric Statistics | |||
| The measurement of a performance metric often yields a set of samples | The measurement of a performance metric often yields a set of samples | |||
| from an observation distribution ([Prometheus]), instead of a single | from an observation distribution ([Prometheus]), instead of a single | |||
| value. A statistical operator is applied to the samples to obtain a | value. A statistical operator is applied to the samples to obtain a | |||
| value to be reported to the client. Multiple statistical operators | value to be reported to the client. Multiple statistical operators | |||
| (e.g., min, median, and max) are commonly being used. | (e.g., min, median, and max) are commonly being used. | |||
| Hence, this document extends the general US-ASCII alphanumeric cost | Hence, this document extends the general US-ASCII alphanumeric cost | |||
| metric strings, formally specified as the CostMetric type defined in | metric strings, formally specified as the CostMetric type defined in | |||
| Section 10.6 of [RFC7285], as follows: | Section 10.6 of [RFC7285], as follows: | |||
| skipping to change at page 11, line 26 ¶ | skipping to change at page 11, line 26 ¶ | |||
| Note that RFC 7258 limits the overall cost metric identifier to 32 | Note that RFC 7258 limits the overall cost metric identifier to 32 | |||
| characters. The cost metric variants with statistical operator | characters. The cost metric variants with statistical operator | |||
| suffixes defined by this document are also subject to the same | suffixes defined by this document are also subject to the same | |||
| overall 32-character limit, so certain combinations of (long) base | overall 32-character limit, so certain combinations of (long) base | |||
| metric identifier and statistical operator will not be representable. | metric identifier and statistical operator will not be representable. | |||
| If such a situation arises, it could be addressed by defining a new | 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, | base metric identifier that is an "alias" of the desired base metric, | |||
| with identical semantics and just a shorter name. | with identical semantics and just a shorter name. | |||
| 3. Packet Performance Metrics | 4. Packet Performance Metrics | |||
| This section introduces ALTO network performance metrics on one way | This section introduces ALTO network performance metrics on one way | |||
| delay, round-trip delay, delay variation, packet loss rate, and hop | delay, round-trip delay, delay variation, packet loss rate, and hop | |||
| count. They measure the "quality of experience" of the stream of | count. They measure the "quality of experience" of the stream of | |||
| packets sent from a resource provider to a resource consumer. The | packets sent from a resource provider to a resource consumer. The | |||
| measures of each individual packet (pkt) can include the delay from | measures of each individual packet (pkt) can include the delay from | |||
| the time when the packet enters the network to the time when the | the time when the packet enters the network to the time when the | |||
| packet leaves the network (pkt.delay); whether the packet is dropped | packet leaves the network (pkt.delay); whether the packet is dropped | |||
| before reaching the destination (pkt.dropped); the number of network | before reaching the destination (pkt.dropped); the number of network | |||
| hops that the packet traverses (pkt.hopcount). The semantics of the | hops that the packet traverses (pkt.hopcount). The semantics of the | |||
| performance metrics defined in this section are that they are | performance metrics defined in this section are that they are | |||
| statistics computed from these measures; for example, the | statistics computed from these measures; for example, the | |||
| x-percentile of the one-way delay is the x-percentile of the set of | x-percentile of the one-way delay is the x-percentile of the set of | |||
| delays {pkt.delay} for the packets in the stream. | delays {pkt.delay} for the packets in the stream. | |||
| 3.1. Cost Metric: One-Way Delay (delay-ow) | 4.1. Cost Metric: One-Way Delay (delay-ow) | |||
| 3.1.1. Base Identifier | 4.1.1. Base Identifier | |||
| The base identifier for this performance metric is "delay-ow". | The base identifier for this performance metric is "delay-ow". | |||
| 3.1.2. Value Representation | 4.1.2. Value Representation | |||
| The metric value type is a single 'JSONNumber' type value conforming | The metric value type is a single 'JSONNumber' type value conforming | |||
| to the number specification of Section 6 of [RFC8259]. The unit is | to the number specification of Section 6 of [RFC8259]. The unit is | |||
| expressed in microseconds. Hence, the number can be a floating point | expressed in microseconds. Hence, the number can be a floating point | |||
| number to express delay that is smaller than microseconds. The | number to express delay that is smaller than microseconds. The | |||
| number MUST be non-negative. | number MUST be non-negative. | |||
| 3.1.3. Intended Semantics and Use | 4.1.3. Intended Semantics and Use | |||
| Intended Semantics: To specify the temporal and spatial aggregated | Intended Semantics: To specify the temporal and spatial aggregated | |||
| delay of a stream of packets from the specified source to the | delay of a stream of packets from the specified source to the | |||
| specified destination. The base semantics of the metric is the | specified destination. The base semantics of the metric is the | |||
| Unidirectional Delay metric defined in [RFC8571,RFC8570,RFC7471], but | Unidirectional Delay metric defined in [RFC8571,RFC8570,RFC7471], but | |||
| instead of specifying the delay for a link, it is the (temporal) | instead of specifying the delay for a link, it is the (temporal) | |||
| aggregation of the link delays from the source to the destination. A | aggregation of the link delays from the source to the destination. A | |||
| non-normative reference definition of end-to-end one-way delay is | non-normative reference definition of end-to-end one-way delay is | |||
| [RFC7679]. The spatial aggregation level is specified in the query | [RFC7679]. The spatial aggregation level is specified in the query | |||
| context, e.g., provider-defined identifier (PID) to PID, or endpoint | context, e.g., provider-defined identifier (PID) to PID, or endpoint | |||
| skipping to change at page 14, line 49 ¶ | skipping to change at page 14, line 49 ¶ | |||
| } | } | |||
| }, | }, | |||
| "endpoint-cost-map": { | "endpoint-cost-map": { | |||
| "ipv6:2001:db8:100::1": { | "ipv6:2001:db8:100::1": { | |||
| "ipv6:2001:db8:100::2": 10, | "ipv6:2001:db8:100::2": 10, | |||
| "ipv6:2001:db8:100::3": 20 | "ipv6:2001:db8:100::3": 20 | |||
| } | } | |||
| } | } | |||
| } | } | |||
| 3.1.4. Cost-Context Specification Considerations | 4.1.4. Cost-Context Specification Considerations | |||
| "nominal": Typically network one-way delay does not have a nominal | "nominal": Typically network one-way delay does not have a nominal | |||
| value. | value. | |||
| "sla": Many networks provide delay-related parameters in their | "sla": Many networks provide delay-related parameters in their | |||
| application-level SLAs. It is RECOMMENDED that the "parameters" | application-level SLAs. It is RECOMMENDED that the "parameters" | |||
| field of an "sla" one-way delay metric include a link (i.e., a field | field of an "sla" one-way delay metric include a link (i.e., a field | |||
| named "link") providing an URI to the specification of SLA details, | named "link") providing an URI to the specification of SLA details, | |||
| if available. Such a specification can be either free text for | if available. Such a specification can be either free text for | |||
| possible presentation to the user, or a formal specification. The | possible presentation to the user, or a formal specification. The | |||
| skipping to change at page 16, line 5 ¶ | skipping to change at page 16, line 5 ¶ | |||
| RECOMMEDED that the "parameters" field of an "estimation" one-way | RECOMMEDED that the "parameters" field of an "estimation" one-way | |||
| delay metric includes the following information: the URI to the URI | delay metric includes the following information: the URI to the URI | |||
| field of the IPPM metric defined in the IPPM performance metric | field of the IPPM metric defined in the IPPM performance metric | |||
| [IANA-IPPM] registry (e.g., https://www.iana.org/assignments/ | [IANA-IPPM] registry (e.g., https://www.iana.org/assignments/ | |||
| performance-metrics/OWDelay_Active_IP-UDP-Poisson- | performance-metrics/OWDelay_Active_IP-UDP-Poisson- | |||
| Payload250B_RFC8912sec7_Seconds_95Percentile). The IPPM metric MUST | Payload250B_RFC8912sec7_Seconds_95Percentile). The IPPM metric MUST | |||
| be one-way delay (i.e., IPPM OWDelay* metrics). The statistical | be one-way delay (i.e., IPPM OWDelay* metrics). The statistical | |||
| operator of the ALTO metric MUST be consistent with the IPPM | operator of the ALTO metric MUST be consistent with the IPPM | |||
| statistical property (e.g., 95-th percentile). | statistical property (e.g., 95-th percentile). | |||
| 3.2. Cost Metric: Round-trip Delay (delay-rt) | 4.2. Cost Metric: Round-trip Delay (delay-rt) | |||
| 3.2.1. Base Identifier | 4.2.1. Base Identifier | |||
| The base identifier for this performance metric is "delay-rt". | The base identifier for this performance metric is "delay-rt". | |||
| 3.2.2. Value Representation | 4.2.2. Value Representation | |||
| The metric value type is a single 'JSONNumber' type value conforming | The metric value type is a single 'JSONNumber' type value conforming | |||
| to the number specification of Section 6 of [RFC8259]. The number | to the number specification of Section 6 of [RFC8259]. The number | |||
| MUST be non-negative. The unit is expressed in microseconds. | MUST be non-negative. The unit is expressed in microseconds. | |||
| 3.2.3. Intended Semantics and Use | 4.2.3. Intended Semantics and Use | |||
| Intended Semantics: To specify temporal and spatial aggregated round- | Intended Semantics: To specify temporal and spatial aggregated round- | |||
| trip delay between the specified source and specified destination. | trip delay between the specified source and specified destination. | |||
| The base semantics is that it is the sum of one-way delay from the | The base semantics is that it is the sum of one-way delay from the | |||
| source to the destination and the one-way delay from the destination | source to the destination and the one-way delay from the destination | |||
| back to the source, where the one-way delay is defined in | back to the source, where the one-way delay is defined in | |||
| Section 3.1. A non-normative reference definition of end-to-end | Section 4.1. A non-normative reference definition of end-to-end | |||
| round-trip delay is [RFC2681]. The spatial aggregation level is | round-trip delay is [RFC2681]. The spatial aggregation level is | |||
| specified in the query context (e.g., PID to PID, or endpoint to | specified in the query context (e.g., PID to PID, or endpoint to | |||
| endpoint). | endpoint). | |||
| Note that it is possible for a client to query two one-way delays | Note that it is possible for a client to query two one-way delays | |||
| (delay-ow) and then compute the round-trip delay. The server should | (delay-ow) and then compute the round-trip delay. The server should | |||
| be cognizant of the consistency of values. | be cognizant of the consistency of values. | |||
| Use: This metric could be used either as a cost metric constraint | Use: This metric could be used either as a cost metric constraint | |||
| attribute or as a returned cost metric in the response. | attribute or as a returned cost metric in the response. | |||
| skipping to change at page 17, line 49 ¶ | skipping to change at page 17, line 49 ¶ | |||
| } | } | |||
| }, | }, | |||
| "endpoint-cost-map": { | "endpoint-cost-map": { | |||
| "ipv4:192.0.2.2": { | "ipv4:192.0.2.2": { | |||
| "ipv4:192.0.2.89": 4, | "ipv4:192.0.2.89": 4, | |||
| "ipv4:198.51.100.34": 3 | "ipv4:198.51.100.34": 3 | |||
| } | } | |||
| } | } | |||
| } | } | |||
| 3.2.4. Cost-Context Specification Considerations | 4.2.4. Cost-Context Specification Considerations | |||
| "nominal": Typically network round-trip delay does not have a nominal | "nominal": Typically network round-trip delay does not have a nominal | |||
| value. | value. | |||
| "sla": See the "sla" entry in Section 3.1.4. | "sla": See the "sla" entry in Section 4.1.4. | |||
| "estimation": See the "estimation" entry in Section 3.1.4. For | "estimation": See the "estimation" entry in Section 4.1.4. For | |||
| estimation by aggregation of routing protocol link metrics, the | estimation by aggregation of routing protocol link metrics, the | |||
| aggregation should include all links from the source to the | aggregation should include all links from the source to the | |||
| destination and then back to the source; for estimation using IPPM, | destination and then back to the source; for estimation using IPPM, | |||
| the IPPM metric MUST be round-trip delay (i.e., IPPM RTDelay* | the IPPM metric MUST be round-trip delay (i.e., IPPM RTDelay* | |||
| metrics). The statistical operator of the ALTO metric MUST be | metrics). The statistical operator of the ALTO metric MUST be | |||
| consistent with the IPPM statistical property (e.g., 95-th | consistent with the IPPM statistical property (e.g., 95-th | |||
| percentile). | percentile). | |||
| 3.3. Cost Metric: Delay Variation (delay-variation) | 4.3. Cost Metric: Delay Variation (delay-variation) | |||
| 3.3.1. Base Identifier | 4.3.1. Base Identifier | |||
| The base identifier for this performance metric is "delay-variation". | The base identifier for this performance metric is "delay-variation". | |||
| 3.3.2. Value Representation | 4.3.2. Value Representation | |||
| The metric value type is a single 'JSONNumber' type value conforming | The metric value type is a single 'JSONNumber' type value conforming | |||
| to the number specification of Section 6 of [RFC8259]. The number | to the number specification of Section 6 of [RFC8259]. The number | |||
| MUST be non-negative. The unit is expressed in microseconds. | MUST be non-negative. The unit is expressed in microseconds. | |||
| 3.3.3. Intended Semantics and Use | 4.3.3. Intended Semantics and Use | |||
| Intended Semantics: To specify temporal and spatial aggregated delay | Intended Semantics: To specify temporal and spatial aggregated delay | |||
| variation (also called delay jitter)) with respect to the minimum | variation (also called delay jitter)) with respect to the minimum | |||
| delay observed on the stream over the one-way delay from the | delay observed on the stream over the one-way delay from the | |||
| specified source and destination, where the one-way delay is defined | specified source and destination, where the one-way delay is defined | |||
| in Section 3.1. A non-normative reference definition of end-to-end | in Section 4.1. A non-normative reference definition of end-to-end | |||
| one-way delay variation is [RFC3393]. Note that [RFC3393] allows the | one-way delay variation is [RFC3393]. Note that [RFC3393] allows the | |||
| specification of a generic selection function F to unambiguously | specification of a generic selection function F to unambiguously | |||
| define the two packets selected to compute delay variations. This | define the two packets selected to compute delay variations. This | |||
| document defines the specific case that F selects as the "first" | document defines the specific case that F selects as the "first" | |||
| packet the one with the smallest one-way delay. The spatial | packet the one with the smallest one-way delay. The spatial | |||
| aggregation level is specified in the query context (e.g., PID to | aggregation level is specified in the query context (e.g., PID to | |||
| PID, or endpoint to endpoint). | PID, or endpoint to endpoint). | |||
| Note that in statistics, variations are typically evaluated by the | Note that in statistics, variations are typically evaluated by the | |||
| distance from samples relative to the mean. In networking context, | distance from samples relative to the mean. In networking context, | |||
| skipping to change at page 19, line 49 ¶ | skipping to change at page 19, line 49 ¶ | |||
| } | } | |||
| }, | }, | |||
| "endpoint-cost-map": { | "endpoint-cost-map": { | |||
| "ipv4:192.0.2.2": { | "ipv4:192.0.2.2": { | |||
| "ipv4:192.0.2.89": 0, | "ipv4:192.0.2.89": 0, | |||
| "ipv4:198.51.100.34": 1 | "ipv4:198.51.100.34": 1 | |||
| } | } | |||
| } | } | |||
| } | } | |||
| 3.3.4. Cost-Context Specification Considerations | 4.3.4. Cost-Context Specification Considerations | |||
| "nominal": Typically network delay variation does not have a nominal | "nominal": Typically network delay variation does not have a nominal | |||
| value. | value. | |||
| "sla": See the "sla" entry in Section 3.1.4. | "sla": See the "sla" entry in Section 4.1.4. | |||
| "estimation": See the "estimation" entry in Section 3.1.4. For | "estimation": See the "estimation" entry in Section 4.1.4. For | |||
| estimation by aggregation of routing protocol link metrics, the | estimation by aggregation of routing protocol link metrics, the | |||
| default aggregation of the average of delay variations is the sum of | default aggregation of the average of delay variations is the sum of | |||
| the link delay variations; for estimation using IPPM, the IPPM metric | the link delay variations; for estimation using IPPM, the IPPM metric | |||
| MUST be delay variation (i.e., IPPM OWPDV* metrics). The statistical | MUST be delay variation (i.e., IPPM OWPDV* metrics). The statistical | |||
| operator of the ALTO metric MUST be consistent with the IPPM | operator of the ALTO metric MUST be consistent with the IPPM | |||
| statistical property (e.g., 95-th percentile). | statistical property (e.g., 95-th percentile). | |||
| 3.4. Cost Metric: Loss Rate (lossrate) | 4.4. Cost Metric: Loss Rate (lossrate) | |||
| 3.4.1. Base Identifier | 4.4.1. Base Identifier | |||
| The base identifier for this performance metric is "lossrate". | The base identifier for this performance metric is "lossrate". | |||
| 3.4.2. Value Representation | 4.4.2. Value Representation | |||
| The metric value type is a single 'JSONNumber' type value conforming | The metric value type is a single 'JSONNumber' type value conforming | |||
| to the number specification of Section 6 of [RFC8259]. The number | to the number specification of Section 6 of [RFC8259]. The number | |||
| MUST be non-negative. The value represents the percentage of packet | MUST be non-negative. The value represents the percentage of packet | |||
| losses. | losses. | |||
| 3.4.3. Intended Semantics and Use | 4.4.3. Intended Semantics and Use | |||
| Intended Semantics: To specify temporal and spatial aggregated one- | Intended Semantics: To specify temporal and spatial aggregated one- | |||
| way packet loss rate from the specified source and the specified | way packet loss rate from the specified source and the specified | |||
| destination. The base semantics of the metric is the Unidirectional | destination. The base semantics of the metric is the Unidirectional | |||
| Link Loss metric defined in [RFC8571,RFC8570,RFC7471], but instead of | Link Loss metric defined in [RFC8571,RFC8570,RFC7471], but instead of | |||
| specifying the loss for a link, it is the aggregated loss of all | specifying the loss for a link, it is the aggregated loss of all | |||
| links from the source to the destination. The spatial aggregation | links from the source to the destination. The spatial aggregation | |||
| level is specified in the query context (e.g., PID to PID, or | level is specified in the query context (e.g., PID to PID, or | |||
| endpoint to endpoint). | endpoint to endpoint). | |||
| skipping to change at page 21, line 49 ¶ | skipping to change at page 21, line 49 ¶ | |||
| } | } | |||
| }, | }, | |||
| "endpoint-cost-map": { | "endpoint-cost-map": { | |||
| "ipv4:192.0.2.2": { | "ipv4:192.0.2.2": { | |||
| "ipv4:192.0.2.89": 0, | "ipv4:192.0.2.89": 0, | |||
| "ipv4:198.51.100.34": 0.01 | "ipv4:198.51.100.34": 0.01 | |||
| } | } | |||
| } | } | |||
| } | } | |||
| 3.4.4. Cost-Context Specification Considerations | 4.4.4. Cost-Context Specification Considerations | |||
| "nominal": Typically packet loss rate does not have a nominal value, | "nominal": Typically packet loss rate does not have a nominal value, | |||
| although some networks may specify zero losses. | although some networks may specify zero losses. | |||
| "sla": See the "sla" entry in Section 3.1.4.. | "sla": See the "sla" entry in Section 4.1.4.. | |||
| "estimation": See the "estimation" entry in Section 3.1.4. For | "estimation": See the "estimation" entry in Section 4.1.4. For | |||
| estimation by aggregation of routing protocol link metrics, the | estimation by aggregation of routing protocol link metrics, the | |||
| default aggregation of the average of loss rate is the sum of the | default aggregation of the average of loss rate is the sum of the | |||
| link link loss rates. But this default aggregation is valid only if | link link loss rates. But this default aggregation is valid only if | |||
| two conditions are met: (1) it is valid only when link loss rates are | two conditions are met: (1) it is valid only when link loss rates are | |||
| low, and (2) it assumes that each link's loss events are uncorrelated | low, and (2) it assumes that each link's loss events are uncorrelated | |||
| with every other link's loss events. When loss rates at the links | with every other link's loss events. When loss rates at the links | |||
| are high but independent, the general formula for aggregating loss | are high but independent, the general formula for aggregating loss | |||
| assuming each link is independent is to compute end-to-end loss as | assuming each link is independent is to compute end-to-end loss as | |||
| one minus the product of the success rate for each link. Aggregation | 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 | when losses at links are correlated can be more complex and the ALTO | |||
| server should be cognizant of correlated loss rates. For estimation | server should be cognizant of correlated loss rates. For estimation | |||
| using IPPM, the IPPM metric MUST be packet loss (i.e., IPPM OWLoss* | using IPPM, the IPPM metric MUST be packet loss (i.e., IPPM OWLoss* | |||
| metrics). The statistical operator of the ALTO metric MUST be | metrics). The statistical operator of the ALTO metric MUST be | |||
| consistent with the IPPM statistical property (e.g., 95-th | consistent with the IPPM statistical property (e.g., 95-th | |||
| percentile). | percentile). | |||
| 3.5. Cost Metric: Hop Count (hopcount) | 4.5. Cost Metric: Hop Count (hopcount) | |||
| The hopcount metric is mentioned in [RFC7285] Section 9.2.3 as an | The hopcount metric is mentioned in Section 9.2.3 of [RFC7285] as an | |||
| example. This section further clarifies its properties. | example. This section further clarifies its properties. | |||
| 3.5.1. Base Identifier | 4.5.1. Base Identifier | |||
| The base identifier for this performance metric is "hopcount". | The base identifier for this performance metric is "hopcount". | |||
| 3.5.2. Value Representation | 4.5.2. Value Representation | |||
| The metric value type is a single 'JSONNumber' type value conforming | The metric value type is a single 'JSONNumber' type value conforming | |||
| to the number specification of Section 6 of [RFC8259]. The number | to the number specification of Section 6 of [RFC8259]. The number | |||
| MUST be a non-negative integer (greater than or equal to 0). The | MUST be a non-negative integer (greater than or equal to 0). The | |||
| value represents the number of hops. | value represents the number of hops. | |||
| 3.5.3. Intended Semantics and Use | 4.5.3. Intended Semantics and Use | |||
| Intended Semantics: To specify the number of hops in the path from | Intended Semantics: To specify the number of hops in the path from | |||
| the specified source to the specified destination. The hop count is | the specified source to the specified destination. The hop count is | |||
| a basic measurement of distance in a network and can be exposed as | a basic measurement of distance in a network and can be exposed as | |||
| the number of router hops computed from the routing protocols | the number of router hops computed from the routing protocols | |||
| originating this information. A hop, however, may represent other | originating this information. A hop, however, may represent other | |||
| units. The spatial aggregation level is specified in the query | units. The spatial aggregation level is specified in the query | |||
| context (e.g., PID to PID, or endpoint to endpoint). | context (e.g., PID to PID, or endpoint to endpoint). | |||
| Use: This metric could be used as a cost metric constraint attribute | Use: This metric could be used as a cost metric constraint attribute | |||
| skipping to change at page 23, line 49 ¶ | skipping to change at page 23, line 49 ¶ | |||
| } | } | |||
| }, | }, | |||
| "endpoint-cost-map": { | "endpoint-cost-map": { | |||
| "ipv4:192.0.2.2": { | "ipv4:192.0.2.2": { | |||
| "ipv4:192.0.2.89": 5, | "ipv4:192.0.2.89": 5, | |||
| "ipv4:198.51.100.34": 3 | "ipv4:198.51.100.34": 3 | |||
| } | } | |||
| } | } | |||
| } | } | |||
| 3.5.4. Cost-Context Specification Considerations | 4.5.4. Cost-Context Specification Considerations | |||
| "nominal": Typically hop count does not have a nominal value. | "nominal": Typically hop count does not have a nominal value. | |||
| "sla": Typically hop count does not have an SLA value. | "sla": Typically hop count does not have an SLA value. | |||
| "estimation": The exact estimation method is out of the scope of this | "estimation": The exact estimation method is out of the scope of this | |||
| document. An example of estimating hopcounts is by importing from | document. An example of estimating hopcounts is by importing from | |||
| IGP routing protocols. It is RECOMMENDED that the "parameters" field | IGP routing protocols. It is RECOMMENDED that the "parameters" field | |||
| of an "estimation" hop count define the meaning of a hop. | of an "estimation" hop count define the meaning of a hop. | |||
| 4. Throughput/Bandwidth Performance Metrics | 5. Throughput/Bandwidth Performance Metrics | |||
| This section introduces four throughput/bandwidth related metrics. | This section introduces four throughput/bandwidth related metrics. | |||
| Given a specified source to a specified destination, these metrics | Given a specified source to a specified destination, these metrics | |||
| reflect the volume of traffic that the network can carry from the | reflect the volume of traffic that the network can carry from the | |||
| source to the destination. | source to the destination. | |||
| 4.1. Cost Metric: TCP Throughput (tput) | 5.1. Cost Metric: TCP Throughput (tput) | |||
| 4.1.1. Base Identifier | 5.1.1. Base Identifier | |||
| The base identifier for this performance metric is "tput". | The base identifier for this performance metric is "tput". | |||
| 4.1.2. Value Representation | 5.1.2. Value Representation | |||
| The metric value type is a single 'JSONNumber' type value conforming | The metric value type is a single 'JSONNumber' type value conforming | |||
| to the number specification of Section 6 of [RFC8259]. The number | to the number specification of Section 6 of [RFC8259]. The number | |||
| MUST be non-negative. The unit is bytes per second. | MUST be non-negative. The unit is bytes per second. | |||
| 4.1.3. Intended Semantics and Use | 5.1.3. Intended Semantics and Use | |||
| Intended Semantics: To give the throughput of a TCP congestion- | Intended Semantics: To give the throughput of a TCP congestion- | |||
| control conforming flow from the specified source to the specified | control conforming flow from the specified source to the specified | |||
| destination. The throughput SHOULD be interpreted as only an | destination. The throughput SHOULD be interpreted as only an | |||
| estimation, and the estimation is designed only for bulk flows. | estimation, and the estimation is designed only for bulk flows. | |||
| Use: This metric could be used as a cost metric constraint attribute | Use: This metric could be used as a cost metric constraint attribute | |||
| or as a returned cost metric in the response. | or as a returned cost metric in the response. | |||
| Example 5: TCP throughput value on source-destination endpoint pairs | Example 5: TCP throughput value on source-destination endpoint pairs | |||
| skipping to change at page 25, line 49 ¶ | skipping to change at page 25, line 49 ¶ | |||
| } | } | |||
| }, | }, | |||
| "endpoint-cost-map": { | "endpoint-cost-map": { | |||
| "ipv4:192.0.2.2": { | "ipv4:192.0.2.2": { | |||
| "ipv4:192.0.2.89": 256000, | "ipv4:192.0.2.89": 256000, | |||
| "ipv4:198.51.100.34": 128000 | "ipv4:198.51.100.34": 128000 | |||
| } | } | |||
| } | } | |||
| } | } | |||
| 4.1.4. Cost-Context Specification Considerations | 5.1.4. Cost-Context Specification Considerations | |||
| "nominal": Typically TCP throughput does not have a nominal value, | "nominal": Typically TCP throughput does not have a nominal value, | |||
| and SHOULD NOT be generated. | and SHOULD NOT be generated. | |||
| "sla": Typically TCP throughput does not have an SLA value, and | "sla": Typically TCP throughput does not have an SLA value, and | |||
| SHOULD NOT be generated. | SHOULD NOT be generated. | |||
| "estimation": The exact estimation method is out of the scope of this | "estimation": The exact estimation method is out of the scope of this | |||
| document. It is RECOMMENDED that the "parameters" field of an | document. It is RECOMMENDED that the "parameters" field of an | |||
| "estimation" TCP throughput metric include the following information: | "estimation" TCP throughput metric include the following information: | |||
| skipping to change at page 26, line 28 ¶ | skipping to change at page 26, line 28 ¶ | |||
| [I-D.ietf-tcpm-rfc8312bis]; for an ongoing congestion control | [I-D.ietf-tcpm-rfc8312bis]; for an ongoing congestion control | |||
| algorithm such as BBR, a a link to its specification. To specify | algorithm such as BBR, a a link to its specification. To specify | |||
| (2), the "parameters" includes as many details as possible; for | (2), the "parameters" includes as many details as possible; for | |||
| example, for TCP Cubic throughout estimation, the "parameters" field | example, for TCP Cubic throughout estimation, the "parameters" field | |||
| specifies that the throughput is estimated by setting _C_ to 0.4, and | specifies that the throughput is estimated by setting _C_ to 0.4, and | |||
| the Equation in Figure 8 of [I-D.ietf-tcpm-rfc8312bis] is applied; as | the Equation in Figure 8 of [I-D.ietf-tcpm-rfc8312bis] is applied; as | |||
| an alternative, the methodology may be based on the NUM model | an alternative, the methodology may be based on the NUM model | |||
| [Prophet], or the G2 model [G2]. The exact specification of the | [Prophet], or the G2 model [G2]. The exact specification of the | |||
| parameters field is out of the scope of this document. | parameters field is out of the scope of this document. | |||
| 4.2. Cost Metric: Residual Bandwidth (bw-residual) | 5.2. Cost Metric: Residual Bandwidth (bw-residual) | |||
| 4.2.1. Base Identifier | 5.2.1. Base Identifier | |||
| The base identifier for this performance metric is "bw-residual". | The base identifier for this performance metric is "bw-residual". | |||
| 4.2.2. Value Representation | 5.2.2. Value Representation | |||
| The metric value type is a single 'JSONNumber' type value that is | The metric value type is a single 'JSONNumber' type value that is | |||
| non-negative. The unit of measurement is bytes per second. | non-negative. The unit of measurement is bytes per second. | |||
| 4.2.3. Intended Semantics and Use | 5.2.3. Intended Semantics and Use | |||
| Intended Semantics: To specify temporal and spatial residual | Intended Semantics: To specify temporal and spatial residual | |||
| bandwidth from the specified source and the specified destination. | bandwidth from the specified source and the specified destination. | |||
| The base semantics of the metric is the Unidirectional Residual | The base semantics of the metric is the Unidirectional Residual | |||
| Bandwidth metric defined in [RFC8571,RFC8570,RFC7471], but instead of | Bandwidth metric defined in [RFC8571,RFC8570,RFC7471], but instead of | |||
| specifying the residual bandwidth for a link, it is the residual | specifying the residual bandwidth for a link, it is the residual | |||
| bandwidth of the path from the source to the destination. Hence, it | bandwidth of the path from the source to the destination. Hence, it | |||
| is the minimal residual bandwidth among all links from the source to | is the minimal residual bandwidth among all links from the source to | |||
| the destination. When the max statistical operator is defined for | the destination. When the max statistical operator is defined for | |||
| the metric, it typically provides the minimum of the link capacities | the metric, it typically provides the minimum of the link capacities | |||
| skipping to change at page 28, line 23 ¶ | skipping to change at page 28, line 23 ¶ | |||
| } | } | |||
| }, | }, | |||
| "endpoint-cost-map": { | "endpoint-cost-map": { | |||
| "ipv4:192.0.2.2": { | "ipv4:192.0.2.2": { | |||
| "ipv4:192.0.2.89": 0, | "ipv4:192.0.2.89": 0, | |||
| "ipv4:198.51.100.34": 2000 | "ipv4:198.51.100.34": 2000 | |||
| } | } | |||
| } | } | |||
| } | } | |||
| 4.2.4. Cost-Context Specification Considerations | 5.2.4. Cost-Context Specification Considerations | |||
| "nominal": Typically residual bandwidth does not have a nominal | "nominal": Typically residual bandwidth does not have a nominal | |||
| value. | value. | |||
| "sla": Typically residual bandwidth does not have an "sla" value. | "sla": Typically residual bandwidth does not have an "sla" value. | |||
| "estimation": See the "estimation" entry in Section 3.1.4 on | "estimation": See the "estimation" entry in Section 4.1.4 on | |||
| aggregation of routing protocol link metrics. The current ("cur") | aggregation of routing protocol link metrics. The current ("cur") | |||
| residual bandwidth of a path is the minimal of the residual bandwidth | residual bandwidth of a path is the minimal of the residual bandwidth | |||
| of all links on the path. | of all links on the path. | |||
| 4.3. Cost Metric: Available Bandwidth (bw-available) | 5.3. Cost Metric: Available Bandwidth (bw-available) | |||
| 4.3.1. Base Identifier | 5.3.1. Base Identifier | |||
| The base identifier for this performance metric is "bw-available". | The base identifier for this performance metric is "bw-available". | |||
| 4.3.2. Value Representation | 5.3.2. Value Representation | |||
| The metric value type is a single 'JSONNumber' type value that is | The metric value type is a single 'JSONNumber' type value that is | |||
| non-negative. The unit of measurement is bytes per second. | non-negative. The unit of measurement is bytes per second. | |||
| 4.3.3. Intended Semantics and Use | 5.3.3. Intended Semantics and Use | |||
| Intended Semantics: To specify temporal and spatial available | Intended Semantics: To specify temporal and spatial available | |||
| bandwidth from the specified source to the specified destination. | bandwidth from the specified source to the specified destination. | |||
| The base semantics of the metric is the Unidirectional Available | The base semantics of the metric is the Unidirectional Available | |||
| Bandwidth metric defined in [RFC8571,RFC8570,RFC7471], but instead of | Bandwidth metric defined in [RFC8571,RFC8570,RFC7471], but instead of | |||
| specifying the available bandwidth for a link, it is the available | specifying the available bandwidth for a link, it is the available | |||
| bandwidth of the path from the source to the destination. Hence, it | bandwidth of the path from the source to the destination. Hence, it | |||
| is the minimal available bandwidth among all links from the source to | is the minimal available bandwidth among all links from the source to | |||
| the destination.The spatial aggregation unit is specified in the | the destination.The spatial aggregation unit is specified in the | |||
| query context (e.g., PID to PID, or endpoint to endpoint). | query context (e.g., PID to PID, or endpoint to endpoint). | |||
| skipping to change at page 30, line 23 ¶ | skipping to change at page 30, line 23 ¶ | |||
| } | } | |||
| }, | }, | |||
| "endpoint-cost-map": { | "endpoint-cost-map": { | |||
| "ipv4:192.0.2.2": { | "ipv4:192.0.2.2": { | |||
| "ipv4:192.0.2.89": 0, | "ipv4:192.0.2.89": 0, | |||
| "ipv4:198.51.100.34": 2000 | "ipv4:198.51.100.34": 2000 | |||
| } | } | |||
| } | } | |||
| } | } | |||
| 4.3.4. Cost-Context Specification Considerations | 5.3.4. Cost-Context Specification Considerations | |||
| "nominal": Typically available bandwidth does not have a nominal | "nominal": Typically available bandwidth does not have a nominal | |||
| value. | value. | |||
| "sla": Typically available bandwidth does not have an "sla" value. | "sla": Typically available bandwidth does not have an "sla" value. | |||
| "estimation": See the "estimation" entry in Section 3.1.4 on | "estimation": See the "estimation" entry in Section 4.1.4 on | |||
| aggregation of routing protocol link metrics. The current ("cur") | aggregation of routing protocol link metrics. The current ("cur") | |||
| available bandwidth of a path is the minimum of the available | available bandwidth of a path is the minimum of the available | |||
| bandwidth of all links on the path. | bandwidth of all links on the path. | |||
| 5. Operational Considerations | 6. Operational Considerations | |||
| The exact measurement infrastructure, measurement condition, and | The exact measurement infrastructure, measurement condition, and | |||
| computation algorithms can vary from different networks, and are | computation algorithms can vary from different networks, and are | |||
| outside the scope of this document. Both the ALTO server and the | outside the scope of this document. Both the ALTO server and the | |||
| ALTO clients, however, need to be cognizant of the operational issues | ALTO clients, however, need to be cognizant of the operational issues | |||
| discussed below. | discussed in the following sub-sections. | |||
| Also, the performance metrics specified in this document are similar, | Also, the performance metrics specified in this document are similar, | |||
| in that they may use similar data sources and have similar issues in | in that they may use similar data sources and have similar issues in | |||
| their calculation. Hence, this document specifies common issues | their calculation. Hence, this document specifies common issues | |||
| unless one metric has its unique challenges. | unless one metric has its unique challenges. | |||
| 5.1. Source Considerations | 6.1. Source Considerations | |||
| The addition of the "cost-source" field is to solve a key issue: An | The addition of the "cost-source" field is to solve a key issue: An | |||
| ALTO server needs data sources to compute the cost metrics described | ALTO server needs data sources to compute the cost metrics described | |||
| in this document, and an ALTO client needs to know the data sources | in this document, and an ALTO client needs to know the data sources | |||
| to better interpret the values. | to better interpret the values. | |||
| To avoid too fine-grained information, this document introduces | To avoid too fine-grained information, this document introduces | |||
| "cost-source" to indicate only the high-level type of data sources: | "cost-source" to indicate only the high-level type of data sources: | |||
| "estimation", "nominal" or "lsa", where "estimation" is a type of | "estimation", "nominal" or "lsa", where "estimation" is a type of | |||
| measurement data source, "nominal" is a type of static configuration, | measurement data source, "nominal" is a type of static configuration, | |||
| and "sla" is a type that is more based on policy. | and "sla" is a type that is more based on policy. | |||
| For estimation, for example, the ALTO server may use log servers or | For estimation, for example, the ALTO server may use log servers or | |||
| the OAM system as its data source as recommended by [RFC7971]. In | the OAM system as its data source as recommended by [RFC7971]. In | |||
| particular, the cost metrics defined in this document can be computed | particular, the cost metrics defined in this document can be computed | |||
| using routing systems as the data sources. | using routing systems as the data sources. | |||
| 5.2. Metric Timestamp Consideration | 6.2. Metric Timestamp Consideration | |||
| Despite the introduction of the additional cost-context information, | Despite the introduction of the additional cost-context information, | |||
| the metrics do not have a field to indicate the timestamps of the | the metrics do not have a field to indicate the timestamps of the | |||
| data used to compute the metrics. To indicate this attribute, the | data used to compute the metrics. To indicate this attribute, the | |||
| ALTO server SHOULD return HTTP "Last-Modified", to indicate the | ALTO server SHOULD return HTTP "Last-Modified", to indicate the | |||
| freshness of the data used to compute the performance metrics. | freshness of the data used to compute the performance metrics. | |||
| If the ALTO client obtains updates through an incremental update | If the ALTO client obtains updates through an incremental update | |||
| mechanism [RFC8895], the client SHOULD assume that the metric is | mechanism [RFC8895], the client SHOULD assume that the metric is | |||
| computed using a snapshot at the time that is approximated by the | computed using a snapshot at the time that is approximated by the | |||
| receiving time. | receiving time. | |||
| 5.3. Backward Compatibility Considerations | 6.3. Backward Compatibility Considerations | |||
| One potential issue introduced by the optional "cost-source" field is | One potential issue introduced by the optional "cost-source" field is | |||
| backward compatibility. Consider that an IRD which defines two cost- | backward compatibility. Consider that an IRD which defines two cost- | |||
| types with the same "cost-mode" and "cost-metric", but one with | types with the same "cost-mode" and "cost-metric", but one with | |||
| "cost-source" being "estimation" and the other being "sla". Then an | "cost-source" being "estimation" and the other being "sla". Then an | |||
| ALTO client that is not aware of the extension will not be able to | 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 | distinguish between these two types. A similar issue can arise even | |||
| with a single cost-type, whose "cost-source" is "sla": an ALTO client | 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 | that is not aware of this extension will ignore this field and | |||
| consider the metric estimation. | consider the metric estimation. | |||
| To address the backward-compatibility issue, if a "cost-metric" is | To address the backward-compatibility issue, if a "cost-metric" is | |||
| "routingcost" and the metric contains a "cost-context" field, then it | "routingcost" and the metric contains a "cost-context" field, then it | |||
| MUST be "estimation"; if it is not, the client SHOULD reject the | MUST be "estimation"; if it is not, the client SHOULD reject the | |||
| information as invalid. | information as invalid. | |||
| 5.4. Computation Considerations | 6.4. Computation Considerations | |||
| The metric values exposed by an ALTO server may result from | The metric values exposed by an ALTO server may result from | |||
| additional processing on measurements from data sources to compute | additional processing on measurements from data sources to compute | |||
| exposed metrics. This may involve data processing tasks such as | exposed metrics. This may involve data processing tasks such as | |||
| aggregating the results across multiple systems, removing outliers, | aggregating the results across multiple systems, removing outliers, | |||
| and creating additional statistics. There are two challenges on the | and creating additional statistics. There are two challenges on the | |||
| computation of ALTO performance metrics. | computation of ALTO performance metrics. | |||
| 5.4.1. Configuration Parameters Considerations | 6.4.1. Configuration Parameters Considerations | |||
| Performance metrics often depend on configuration parameters, and | Performance metrics often depend on configuration parameters, and | |||
| exposing such configuration parameters can help an ALTO client to | exposing such configuration parameters can help an ALTO client to | |||
| better understand the exposed metrics. In particular, an ALTO server | better understand the exposed metrics. In particular, an ALTO server | |||
| may be configured to compute a TE metric (e.g., packet loss rate) in | may be configured to compute a TE metric (e.g., packet loss rate) in | |||
| fixed intervals, say every T seconds. To expose this information, | fixed intervals, say every T seconds. To expose this information, | |||
| the ALTO server may provide the client with two pieces of additional | the ALTO server may provide the client with two pieces of additional | |||
| information: (1) when the metrics are last computed, and (2) when the | information: (1) when the metrics are last computed, and (2) when the | |||
| metrics will be updated (i.e., the validity period of the exposed | metrics will be updated (i.e., the validity period of the exposed | |||
| metric values). The ALTO server can expose these two pieces of | metric values). The ALTO server can expose these two pieces of | |||
| information by using the HTTP response headers Last-Modified and | information by using the HTTP response headers Last-Modified and | |||
| Expires. | Expires. | |||
| 5.4.2. Aggregation Computation Considerations | 6.4.2. Aggregation Computation Considerations | |||
| An ALTO server may not be able to measure the performance metrics to | An ALTO server may not be able to measure the performance metrics to | |||
| be exposed. The basic issue is that the "source" information can | be exposed. The basic issue is that the "source" information can | |||
| often be link level. For example, routing protocols often measure | often be link level. For example, routing protocols often measure | |||
| and report only per link loss, not end-to-end loss; similarly, | and report only per link loss, not end-to-end loss; similarly, | |||
| routing protocols report link level available bandwidth, not end-to- | routing protocols report link level available bandwidth, not end-to- | |||
| end available bandwidth. The ALTO server then needs to aggregate | end available bandwidth. The ALTO server then needs to aggregate | |||
| these data to provide an abstract and unified view that can be more | these data to provide an abstract and unified view that can be more | |||
| useful to applications. The server should consider that different | useful to applications. The server should consider that different | |||
| metrics may use different aggregation computation. For example, the | metrics may use different aggregation computation. For example, the | |||
| end-to-end latency of a path is the sum of the latency of the links | end-to-end latency of a path is the sum of the latency of the links | |||
| on the path; the end-to-end available bandwidth of a path is the | 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 | minimum of the available bandwidth of the links on the path; in | |||
| contrast, aggregating loss values is complicated by the potential for | contrast, aggregating loss values is complicated by the potential for | |||
| correlated loss events on different links in the path | correlated loss events on different links in the path | |||
| 6. Security Considerations | 7. Security Considerations | |||
| The properties defined in this document present no security | The properties defined in this document present no security | |||
| considerations beyond those in Section 15 of the base ALTO | considerations beyond those in Section 15 of the base ALTO | |||
| specification [RFC7285]. | specification [RFC7285]. | |||
| However, concerns addressed in Sections "15.1 Authenticity and | However, concerns addressed in Sections 15.1, 15.2, and 15.3 of | |||
| Integrity of ALTO Information", "15.2 Potential Undesirable Guidance | [RFC7285] remain of utmost importance. Indeed, Traffic Engineering | |||
| from Authenticated ALTO Information", and "15.3 Confidentiality of | (TE) performance is highly sensitive ISP information; therefore, | |||
| ALTO Information" remain of utmost importance. Indeed, TE | sharing TE metric values in numerical mode requires full mutual | |||
| performance is highly sensitive ISP information; therefore, sharing | confidence between the entities managing the ALTO server and the ALTO | |||
| TE metric values in numerical mode requires full mutual confidence | client. ALTO servers will most likely distribute numerical TE | |||
| between the entities managing the ALTO server and the ALTO client. | performance to ALTO clients under strict and formal mutual trust | |||
| ALTO servers will most likely distribute numerical TE performance to | agreements. On the other hand, ALTO clients must be cognizant on the | |||
| ALTO clients under strict and formal mutual trust agreements. On the | risks attached to such information that they would have acquired | |||
| other hand, ALTO clients must be cognizant on the risks attached to | outside formal conditions of mutual trust. | |||
| such information that they would have acquired outside formal | ||||
| conditions of mutual trust. | ||||
| To mitigate confidentiality risks during information transport of TE | To mitigate confidentiality risks during information transport of TE | |||
| performance metrics, the operator should address the risk of ALTO | performance metrics, the operator should address the risk of ALTO | |||
| information being leaked to malicious Clients or third parties, | information being leaked to malicious Clients or third parties, | |||
| through attacks such as the person-in-the-middle (PITM) attacks. As | through attacks such as the person-in-the-middle (PITM) attacks. As | |||
| specified in "Protection Strategies" (Section 15.3.2 of [RFC7285]), | specified in "Protection Strategies" (Section 15.3.2 of [RFC7285]), | |||
| the ALTO Server should authenticate ALTO Clients when transmitting an | the ALTO Server should authenticate ALTO Clients when transmitting an | |||
| ALTO information resource containing sensitive TE performance | ALTO information resource containing sensitive TE performance | |||
| metrics. "Authentication and Encryption" (Section 8.3.5 of | metrics. "Authentication and Encryption" (Section 8.3.5 of | |||
| [RFC7285]) specifies that "ALTO Server implementations as well as | [RFC7285]) specifies that "ALTO Server implementations as well as | |||
| ALTO Client implementations MUST support the "https" URI scheme of | ALTO Client implementations MUST support the "https" URI scheme of | |||
| [RFC7230] and Transport Layer Security (TLS) of [RFC8446]". | [RFC7230] and Transport Layer Security (TLS) of [RFC8446]". | |||
| 7. IANA Considerations | 8. IANA Considerations | |||
| IANA has created and now maintains the "ALTO Cost Metric Registry", | IANA has created and now maintains the "ALTO Cost Metric" registry, | |||
| listed in Section 14.2, Table 3 of [RFC7285]. This registry is | listed in Section 14.2, Table 3 of [RFC7285]. This registry is | |||
| located at <https://www.iana.org/assignments/alto-protocol/alto- | located at <https://www.iana.org/assignments/alto-protocol/alto- | |||
| protocol.xhtml#cost-metrics>. This document requests to add the | protocol.xhtml#cost-metrics>. This document requests to add the | |||
| following entries to "ALTO Cost Metric Registry". | following entries to the "ALTO Cost Metric" registry. | |||
| +-----------------+--------------------+ | +-----------------+----------------------------+ | |||
| | Identifier | Intended Semantics | | | Identifier | Intended Semantics | | |||
| +-----------------+--------------------+ | +-----------------+----------------------------+ | |||
| | delay-ow | See Section 3.1 | | | delay-ow | Section 4.1 of [RFCXXX] | | |||
| | delay-rt | See Section 3.2 | | | delay-rt | Section 4.2 of [RFCXXX] | | |||
| | delay-variation | See Section 3.3 | | | delay-variation | Section 4.3 of [RFCXXX] | | |||
| | lossrate | See Section 3.4 | | | lossrate | Section 4.4 of [RFCXXX] | | |||
| | hopcount | See Section 3.5 | | | hopcount | Section 4.5 of [RFCXXX] | | |||
| | tput | See Section 4.1 | | | tput | Section 5.1 of [RFCXXX] | | |||
| | bw-residual | See Section 4.2 | | | bw-residual | Section 5.2 of [RFCXXX] | | |||
| | bw-available | See Section 4.3 | | | bw-available | Section 5.3 of [RFCXXX] | | |||
| +-----------------+--------------------+ | +-----------------+----------------------------+ | |||
| This document requests the creation of the "ALTO Cost Source | ||||
| Registry". This registry serves two purposes. First, it ensures | * [Note to the RFC Editor]: Please replace RFCXXX with the RFC | |||
| number assigned to this document. | ||||
| This document requests the creation of the "ALTO Cost Source" | ||||
| registry. This registry serves two purposes. First, it ensures | ||||
| uniqueness of identifiers referring to ALTO cost source types. | uniqueness of identifiers referring to ALTO cost source types. | |||
| Second, it provides references to particular semantics of allocated | Second, it provides references to particular semantics of allocated | |||
| cost source types to be applied by both ALTO servers and applications | cost source types to be applied by both ALTO servers and applications | |||
| utilizing ALTO clients. | utilizing ALTO clients. | |||
| A new ALTO cost source can be added after IETF Review [RFC8126], to | A new ALTO cost source can be added after IETF Review [RFC8126], to | |||
| ensure that proper documentation regarding the new ALTO cost source | ensure that proper documentation regarding the new ALTO cost source | |||
| and its security considerations have been provided. The RFC(s) | and its security considerations have been provided. The RFC(s) | |||
| documenting the new cost source should be detailed enough to provide | documenting the new cost source should be detailed enough to provide | |||
| guidance to both ALTO service providers and applications utilizing | guidance to both ALTO service providers and applications utilizing | |||
| ALTO clients as to how values of the registered ALTO cost source | ALTO clients as to how values of the registered ALTO cost source | |||
| should be interpreted. Updates and deletions of ALTO cost source | should be interpreted. Updates and deletions of ALTO cost source | |||
| follow the same procedure. | follow the same procedure. | |||
| Registered ALTO address type identifiers MUST conform to the | Registered ALTO address type identifiers MUST conform to the | |||
| syntactical requirements specified in Section 2.1. Identifiers are | syntactical requirements specified in Section 3.1. Identifiers are | |||
| to be recorded and displayed as strings. | to be recorded and displayed as strings. | |||
| Requests to add a new value to the registry MUST include the | Requests to add a new value to the registry MUST include the | |||
| following information: | following information: | |||
| * Identifier: The name of the desired ALTO cost source type. | * Identifier: The name of the desired ALTO cost source type. | |||
| * Intended Semantics: ALTO cost source type carry with them | * Intended Semantics: ALTO cost source type carry with them | |||
| semantics to guide their usage by ALTO clients. Hence, a document | semantics to guide their usage by ALTO clients. Hence, a document | |||
| defining a new type should provide guidance to both ALTO service | defining a new type should provide guidance to both ALTO service | |||
| providers and applications utilizing ALTO clients as to how values | providers and applications utilizing ALTO clients as to how values | |||
| of the registered ALTO endpoint property should be interpreted. | of the registered ALTO endpoint property should be interpreted. | |||
| * Security Considerations: ALTO cost source types expose information | * Security Considerations: ALTO cost source types expose information | |||
| to ALTO clients. ALTO service providers should be made aware of | to ALTO clients. ALTO service providers should be made aware of | |||
| the security ramifications related to the exposure of a cost | the security ramifications related to the exposure of a cost | |||
| source type. | source type. | |||
| This specification requests registration of the identifiers - | This specification requests registration of the identifiers | |||
| "nominal", "sla", and "estimation" listed in the table below. | "nominal", "sla", and "estimation" listed in the table below. | |||
| Semantics for the these are documented in Section 2.1, and security | Semantics for the these are documented in Section 3.1, and security | |||
| considerations are documented in Section 6. | considerations are documented in Section 7. | |||
| +------------+----------------------------------+----------------+ | +------------+----------------------------------+----------------+ | |||
| | Identifier | Intended Semantics | Security | | | Identifier | Intended Semantics | Security | | |||
| | | | Considerations | | | | | Considerations | | |||
| +------------+----------------------------------+----------------+ | +------------+----------------------------------+----------------+ | |||
| | nominal | Values in nominal cases; Sec. 2.1| Sec. 6 | | | nominal | Values in nominal cases; | Section 7 of | | |||
| | sla | Values reflecting service | Sec. 6 | | | | Section 3.1 of [RFCXXX] | [RFCXXX] | | |||
| | | level agreement; Sec. 2.1 | | | | sla | Values reflecting service level | Section 7 of | | |||
| | estimation | Values by estimation; Sec. 2.1 | Sec. 6 | | | | agreement; Section 3.1 of | [RFCXXX] | | |||
| | | [RFCXXXX] | | | ||||
| | estimation | Values by estimation; | Section 7 of | | ||||
| | | Section 3.1 of [RFCXXX] | [RFCXXX] | | ||||
| +------------+----------------------------------+----------------+ | +------------+----------------------------------+----------------+ | |||
| 8. Acknowledgments | 9. Acknowledgments | |||
| The authors of this document would also like to thank Martin Duke for | The authors of this document would also like to thank Martin Duke for | |||
| the highly informative, thorough AD reviews and comments. We thank | the highly informative, thorough AD reviews and comments. We thank | |||
| Christian Amsuess, Elwyn Davies, Haizhou Du, Kai Gao, Geng Li, Lili | Christian Amsuess, Elwyn Davies, Haizhou Du, Kai Gao, Geng Li, Lili | |||
| Liu, Danny Alex Lachos Perez, and Brian Trammell for the reviews and | Liu, Danny Alex Lachos Perez, and Brian Trammell for the reviews and | |||
| comments. We thank Benjamin Kaduk, Eric Kline, Francesca Palombini, | comments. We thank Benjamin Kaduk, Eric Kline, Francesca Palombini, | |||
| Lars Eggert, Martin Vigoureux, Murrary Kucherawy, Roman Danyliw, | Lars Eggert, Martin Vigoureux, Murrary Kucherawy, Roman Danyliw, | |||
| Zaheduzzaman Sarker, Eric Vyncke for discussions and comments that | Zaheduzzaman Sarker, Eric Vyncke for discussions and comments that | |||
| improve this document. | improve this document. | |||
| 9. References | 10. References | |||
| 9.1. Normative References | 10.1. Normative References | |||
| [I-D.ietf-tcpm-rfc8312bis] | [I-D.ietf-tcpm-rfc8312bis] | |||
| Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, "CUBIC | Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, "CUBIC | |||
| for Fast and Long-Distance Networks", Work in Progress, | for Fast and Long-Distance Networks", Work in Progress, | |||
| Internet-Draft, draft-ietf-tcpm-rfc8312bis-07, 4 March | Internet-Draft, draft-ietf-tcpm-rfc8312bis-07, 4 March | |||
| 2022, <https://www.ietf.org/archive/id/draft-ietf-tcpm- | 2022, <https://www.ietf.org/archive/id/draft-ietf-tcpm- | |||
| rfc8312bis-07.txt>. | rfc8312bis-07.txt>. | |||
| [IANA-IPPM] | [IANA-IPPM] | |||
| IANA, "Performance Metrics Registry, | IANA, "Performance Metrics Registry, | |||
| skipping to change at page 37, line 16 ¶ | skipping to change at page 37, line 21 ¶ | |||
| C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of | C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of | |||
| IGP Traffic Engineering Performance Metric Extensions", | IGP Traffic Engineering Performance Metric Extensions", | |||
| RFC 8571, DOI 10.17487/RFC8571, March 2019, | RFC 8571, DOI 10.17487/RFC8571, March 2019, | |||
| <https://www.rfc-editor.org/info/rfc8571>. | <https://www.rfc-editor.org/info/rfc8571>. | |||
| [RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic | [RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic | |||
| Optimization (ALTO) Incremental Updates Using Server-Sent | Optimization (ALTO) Incremental Updates Using Server-Sent | |||
| Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November | Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November | |||
| 2020, <https://www.rfc-editor.org/info/rfc8895>. | 2020, <https://www.rfc-editor.org/info/rfc8895>. | |||
| 9.2. Informative References | 10.2. Informative References | |||
| [FlowDirector] | [FlowDirector] | |||
| Pujol, E., Poese, I., Zerwas, J., Smaragdakis, G., and A. | Pujol, E., Poese, I., Zerwas, J., Smaragdakis, G., and A. | |||
| Feldmann, "Steering Hyper-Giants' Traffic at Scale", ACM | Feldmann, "Steering Hyper-Giants' Traffic at Scale", ACM | |||
| CoNEXT 2020, 2020. | CoNEXT 2020, 2020. | |||
| [G2] Ros-Giralt, J., Bohara, A., Yellamraju, S., and et. al., | [G2] Ros-Giralt, J., Bohara, A., Yellamraju, S., and et. al., | |||
| "On the Bottleneck Structure of Congestion-Controlled | "On the Bottleneck Structure of Congestion-Controlled | |||
| Networks", ACM SIGMETRICS 2019, 2020. | Networks", ACM SIGMETRICS 2019, 2020. | |||
| [I-D.corre-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://www.ietf.org/archive/id/draft-corre-quic- | ||||
| throughput-testing-00.txt>. | ||||
| [Prometheus] | [Prometheus] | |||
| Volz, J. and B. Rabenstein, "Prometheus: A Next-Generation | Volz, J. and B. Rabenstein, "Prometheus: A Next-Generation | |||
| Monitoring System", 2015. | Monitoring System", 2015. | |||
| [Prophet] Gao, K., Zhang, J., and YR. Yang, "Prophet: Fast, Accurate | [Prophet] Gao, K., Zhang, J., and YR. Yang, "Prophet: Fast, Accurate | |||
| Throughput Prediction with Reactive Flows", ACM/IEEE | Throughput Prediction with Reactive Flows", ACM/IEEE | |||
| Transactions on Networking July, 2020. | Transactions on Networking July, 2020. | |||
| [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, | [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, | |||
| "Framework for IP Performance Metrics", RFC 2330, | "Framework for IP Performance Metrics", RFC 2330, | |||
| skipping to change at page 38, line 16 ¶ | skipping to change at page 38, line 30 ¶ | |||
| Ed., "A One-Way Delay Metric for IP Performance Metrics | Ed., "A One-Way Delay Metric for IP Performance Metrics | |||
| (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January | (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January | |||
| 2016, <https://www.rfc-editor.org/info/rfc7679>. | 2016, <https://www.rfc-editor.org/info/rfc7679>. | |||
| [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and | [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and | |||
| S. Previdi, "Application-Layer Traffic Optimization (ALTO) | S. Previdi, "Application-Layer Traffic Optimization (ALTO) | |||
| Deployment Considerations", RFC 7971, | Deployment Considerations", RFC 7971, | |||
| DOI 10.17487/RFC7971, October 2016, | DOI 10.17487/RFC7971, October 2016, | |||
| <https://www.rfc-editor.org/info/rfc7971>. | <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>. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Qin Wu | Qin Wu | |||
| Huawei | Huawei | |||
| 101 Software Avenue, Yuhua District | 101 Software Avenue, Yuhua District | |||
| Nanjing | Nanjing | |||
| Jiangsu, 210012 | Jiangsu, 210012 | |||
| China | China | |||
| Email: bill.wu@huawei.com | Email: bill.wu@huawei.com | |||
| End of changes. 101 change blocks. | ||||
| 198 lines changed or deleted | 218 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||