< 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/