rfc9439.original   rfc9439.txt 
ALTO Working Group Q. Wu Internet Engineering Task Force (IETF) Q. Wu
Internet-Draft Huawei Request for Comments: 9439 Huawei
Intended status: Standards Track Y. Yang Category: Standards Track Y. Yang
Expires: 22 September 2022 Yale University ISSN: 2070-1721 Yale University
Y. Lee Y. Lee
Samsung Samsung
D. Dhody D. Dhody
Huawei Huawei
S. Randriamasy S. Randriamasy
Nokia Bell Labs Nokia Networks France
L. Contreras L. Contreras
Telefonica Telefonica
21 March 2022 August 2023
ALTO Performance Cost Metrics Application-Layer Traffic Optimization (ALTO) Performance Cost Metrics
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
protocol does not define the cost metric to be used. protocol does not define the cost metric to be used.
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., estimations based on measurements
service-level agreement) to derive a performance metric. This or a Service Level Agreement) available for deriving a performance
document introduces an additional "cost-context" field to the ALTO metric. This document introduces an additional "cost-context" field
"cost-type" field to convey the source of a performance metric. to the ALTO "cost-type" field to convey the source of a performance
metric.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 22 September 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9439.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 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
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 2. Requirements Language
3. Performance Metric Attributes . . . . . . . . . . . . . . . . 6 3. Performance Metric Attributes
3.1. Performance Metric Context: "cost-context" . . . . . . . 7 3.1. Performance Metric Context: "cost-context"
3.2. Performance Metric Statistics . . . . . . . . . . . . . . 9 3.2. Performance Metric Statistics
4. Packet Performance Metrics . . . . . . . . . . . . . . . . . 11 4. Packet Performance Metrics
4.1. Cost Metric: One-Way Delay (delay-ow) . . . . . . . . . . 11 4.1. Cost Metric: One-Way Delay (delay-ow)
4.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 11 4.1.1. Base Identifier
4.1.2. Value Representation . . . . . . . . . . . . . . . . 12 4.1.2. Value Representation
4.1.3. Intended Semantics and Use . . . . . . . . . . . . . 12 4.1.3. Intended Semantics and Use
4.1.4. Cost-Context Specification Considerations . . . . . . 14 4.1.4. Cost-Context Specification Considerations
4.2. Cost Metric: Round-trip Delay (delay-rt) . . . . . . . . 16 4.2. Cost Metric: Round-Trip Delay (delay-rt)
4.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 16 4.2.1. Base Identifier
4.2.2. Value Representation . . . . . . . . . . . . . . . . 16 4.2.2. Value Representation
4.2.3. Intended Semantics and Use . . . . . . . . . . . . . 16 4.2.3. Intended Semantics and Use
4.2.4. Cost-Context Specification Considerations . . . . . . 17 4.2.4. Cost-Context Specification Considerations
4.3. Cost Metric: Delay Variation (delay-variation) . . . . . 18 4.3. Cost Metric: Delay Variation (delay-variation)
4.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 18 4.3.1. Base Identifier
4.3.2. Value Representation . . . . . . . . . . . . . . . . 18 4.3.2. Value Representation
4.3.3. Intended Semantics and Use . . . . . . . . . . . . . 18 4.3.3. Intended Semantics and Use
4.3.4. Cost-Context Specification Considerations . . . . . . 19 4.3.4. Cost-Context Specification Considerations
4.4. Cost Metric: Loss Rate (lossrate) . . . . . . . . . . . . 20 4.4. Cost Metric: Loss Rate (lossrate)
4.4.1. Base Identifier . . . . . . . . . . . . . . . . . . . 20 4.4.1. Base Identifier
4.4.2. Value Representation . . . . . . . . . . . . . . . . 20 4.4.2. Value Representation
4.4.3. Intended Semantics and Use . . . . . . . . . . . . . 20 4.4.3. Intended Semantics and Use
4.4.4. Cost-Context Specification Considerations . . . . . . 21 4.4.4. Cost-Context Specification Considerations
4.5. Cost Metric: Hop Count (hopcount) . . . . . . . . . . . . 22 4.5. Cost Metric: Hop Count (hopcount)
4.5.1. Base Identifier . . . . . . . . . . . . . . . . . . . 22 4.5.1. Base Identifier
4.5.2. Value Representation . . . . . . . . . . . . . . . . 22 4.5.2. Value Representation
4.5.3. Intended Semantics and Use . . . . . . . . . . . . . 22 4.5.3. Intended Semantics and Use
4.5.4. Cost-Context Specification Considerations . . . . . . 23 4.5.4. Cost-Context Specification Considerations
5. Throughput/Bandwidth Performance Metrics . . . . . . . . . . 24 5. Throughput/Bandwidth Performance Metrics
5.1. Cost Metric: TCP Throughput (tput) . . . . . . . . . . . 24 5.1. Cost Metric: TCP Throughput (tput)
5.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 24 5.1.1. Base Identifier
5.1.2. Value Representation . . . . . . . . . . . . . . . . 24 5.1.2. Value Representation
5.1.3. Intended Semantics and Use . . . . . . . . . . . . . 24 5.1.3. Intended Semantics and Use
5.1.4. Cost-Context Specification Considerations . . . . . . 25 5.1.4. Cost-Context Specification Considerations
5.2. Cost Metric: Residual Bandwidth (bw-residual) . . . . . . 26 5.2. Cost Metric: Residual Bandwidth (bw-residual)
5.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 26 5.2.1. Base Identifier
5.2.2. Value Representation . . . . . . . . . . . . . . . . 26 5.2.2. Value Representation
5.2.3. Intended Semantics and Use . . . . . . . . . . . . . 26 5.2.3. Intended Semantics and Use
5.2.4. Cost-Context Specification Considerations . . . . . . 28 5.2.4. Cost-Context Specification Considerations
5.3. Cost Metric: Available Bandwidth (bw-available) . . . . . 28 5.3. Cost Metric: Available Bandwidth (bw-available)
5.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 28 5.3.1. Base Identifier
5.3.2. Value Representation . . . . . . . . . . . . . . . . 28 5.3.2. Value Representation
5.3.3. Intended Semantics and Use . . . . . . . . . . . . . 29 5.3.3. Intended Semantics and Use
5.3.4. Cost-Context Specification Considerations . . . . . . 30 5.3.4. Cost-Context Specification Considerations
6. Operational Considerations . . . . . . . . . . . . . . . . . 30 6. Operational Considerations
6.1. Source Considerations . . . . . . . . . . . . . . . . . . 31 6.1. Source Considerations
6.2. Metric Timestamp Consideration . . . . . . . . . . . . . 31 6.2. Metric Timestamp Considerations
6.3. Backward Compatibility Considerations . . . . . . . . . . 31 6.3. Backward-Compatibility Considerations
6.4. Computation Considerations . . . . . . . . . . . . . . . 32 6.4. Computation Considerations
6.4.1. Configuration Parameters Considerations . . . . . . . 32 6.4.1. Configuration Parameter Considerations
6.4.2. Aggregation Computation Considerations . . . . . . . 32 6.4.2. Aggregation Computation Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 8.1. ALTO Cost Metrics Registry
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.2. ALTO Cost Source Types Registry
10.1. Normative References . . . . . . . . . . . . . . . . . . 35 9. References
10.2. Informative References . . . . . . . . . . . . . . . . . 37 9.1. Normative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 9.2. Informative References
Acknowledgments
Authors' Addresses
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].
Since different applications may use different cost metrics, the ALTO Since different applications may use different cost metrics, the ALTO
base protocol introduces an ALTO Cost Metric Registry (Section 14.2 base protocol introduced the "ALTO Cost Metrics" registry
of [RFC7285]) as a systematic mechanism to allow different metrics to (Section 14.2 of [RFC7285]) as a systematic mechanism to allow
be specified. For example, a delay-sensitive application may want to different metrics to be specified. For example, a delay-sensitive
use latency related metrics, and a bandwidth-sensitive application application may want to use latency-related metrics, and a bandwidth-
may want to use bandwidth related metrics. However, the ALTO base sensitive application may want to use bandwidth-related metrics.
protocol has registered only a single cost metric, i.e., the generic However, the ALTO base protocol has registered only a single cost
"routingcost" metric (Section 14.2 of [RFC7285]); no latency or metric, i.e., the generic "routingcost" metric (Section 14.2 of
bandwidth related metrics are defined in the base protocol. [RFC7285]); no latency- or 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 in | Semantics Based On |
| | in this doc | | | | This Document | |
+--------------------+-------------+--------------------------------+ +============+===============+=====================================+
| One-way Delay | Section 4.1 | Base: [RFC7471,8570,8571] | | One-Way | Section 4.1 | Base: [RFC7471] [RFC8570] [RFC8571] |
| | | sum Unidirectional Delay | | Delay | | sum of Unidirectional Delay of |
| Round-trip Delay | Section 4.2 | Base: Sum of two directions | | | | links along the path |
| | | from above | +------------+---------------+-------------------------------------+
| Delay Variation | Section 4.3 | Base: [RFC7471,8570,8571] | | Round-Trip | Section 4.2 | Base: Sum of two directions of |
| | | sum of Unidirectional Delay | | Delay | | Unidirectional Delay |
| | | Variation | +------------+---------------+-------------------------------------+
| Loss Rate | Section 4.4 | Base: [RFC7471,8570,8571] | | Delay | Section 4.3 | Base: [RFC7471] [RFC8570] [RFC8571] |
| | | aggr Unidirectional Link Loss | | Variation | | Sum of Unidirectional Delay |
| Residual Bandwidth | Section 5.2 | Base: [RFC7471,8570,8571] | | | | Variation of links along the path |
| | | min Unidirectional Residual BW| +------------+---------------+-------------------------------------+
| Available Bandwidth| Section 5.3 | Base: [RFC7471,8570,8571] | | Loss Rate | Section 4.4 | Base: [RFC7471] [RFC8570] [RFC8571] |
| | | min Unidirectional Avail. BW | | | | aggr Unidirectional Link Loss |
| | | | +------------+---------------+-------------------------------------+
| TCP Throughput | Section 5.1 | [I-D.ietf-tcpm-rfc8312bis] | | Residual | Section 5.2 | Base: [RFC7471] [RFC8570] [RFC8571] |
| | | | | Bandwidth | | min Unidirectional Residual BW |
| Hop Count | Section 4.5 | [RFC7285] | +------------+---------------+-------------------------------------+
+--------------------+-------------+--------------------------------+ | Available | Section 5.3 | Base: [RFC7471] [RFC8570] [RFC8571] |
Table 1. Cost Metrics Defined in this Document. | Bandwidth | | min Unidirectional Available BW |
+------------+---------------+-------------------------------------+
| TCP | Section 5.1 | [RFC9438] |
| Throughput | | |
+------------+---------------+-------------------------------------+
| Hop Count | Section 4.5 | [RFC7285] |
+------------+---------------+-------------------------------------+
The first 6 metrics listed in Table 1 (i.e., One-way Delay, Round- Table 1: Cost Metrics Defined in This Document
trip Delay, Delay Variation, Loss Rate, Residual Bandwidth, and
Available Bandwidth) are derived from the set of traffic engineering
performance metrics commonly defined in OSPF [RFC3630], [RFC7471];
IS-IS [RFC5305], [RFC8570]; and BGP-LS [RFC8571]. Deriving ALTO cost
performance metrics from existing network-layer traffic engineering
performance metrics, to expose to application-layer traffic
optimization, can be a typical mechanism by network operators to
deploy ALTO [RFC7971], [FlowDirector]. This document defines the
base semantics of these metrics by extending them from link metrics
to end-to-end metrics for ALTO. The "Semantics Based On" column
specifies at a high level how the end-to-end metric is computed from
link metrics; the details will be specified in the following
sections.
The common metrics Min/Max Unidirectional Delay defined in The first six metrics listed in Table 1 (i.e., one-way delay, round-
[RFC8570][RFC8571] and Max Link Bandwidth defined in trip delay, delay variation, loss rate, residual bandwidth, and
[RFC3630,RFC5305] are not listed in Table 1 because they can be available bandwidth) are derived from the set of Traffic Engineering
handled by applying the statistical operators defined in this (TE) performance metrics commonly defined in OSPF [RFC3630]
document. The metrics related with utilized bandwidth and reservable [RFC7471], IS-IS [RFC5305] [RFC8570], and BGP - Link State (BGP-LS)
bandwidth (i.e., Max Reservable BW and Unreserved BW defined in [RFC8571]. Deriving ALTO cost performance metrics from existing
[RFC3630,RFC5305]) are outside the scope of this document. network-layer TE performance metrics, and making it exposed to ALTO,
can be a typical mechanism used by network operators to deploy ALTO
[RFC7971] [FlowDirector]. This document defines the base semantics
of these metrics by extending them from link metrics to end-to-end
metrics for ALTO. The "Semantics Based On" column specifies at a
high level how the end-to-end metrics are computed from link metrics;
details will be specified in the following sections.
The 7th metric (the estimated TCP-flow throughput metric) provides an The Min/Max Unidirectional Link Delay metric as defined in [RFC8570]
estimation of the bandwidth of a TCP flow, using TCP throughput and [RFC8571], and Maximum (Link) Bandwidth as defined in [RFC3630]
modeling, to support use cases of adaptive applications [Prophet], and [RFC5305], are not listed in Table 1 because they can be handled
[G2]. Note that other transport-specific metrics can be defined in by applying the statistical operators defined in this document. The
the future. For example, QUIC-related metrics [RFC9000] can be metrics related to utilized bandwidth and reservable bandwidth (i.e.,
considered when the methodology to measure such metrics is more Maximum Reservable (Link) Bandwidth and Unreserved Bandwidth as
mature (e.g., [I-D.corre-quic-throughput-testing]). defined in [RFC3630] and [RFC5305]) are outside the scope of this
document.
The 8th metric (the hop count metric) in Table 1 is mentioned in the The seventh metric in Table 1 (the estimated TCP-flow throughput
ALTO base protocol [RFC7285], but not defined, and this document metric) provides an estimation of the bandwidth of a TCP flow, using
defines it to be complete. TCP throughput modeling, to support use cases of adaptive
applications [Prophet] [G2]. Note that other transport-specific
metrics can be defined in the future. For example, QUIC-related
metrics [RFC9000] can be considered when the methodology for
measuring such metrics is more mature (e.g., see
[QUIC-THROUGHPUT-TESTING]).
These 8 performance metrics can be classified into two categories: The eighth metric in Table 1 (the hop count metric) is mentioned, but
those derived from the performance of individual packets (i.e., One- not defined, in the ALTO base protocol [RFC7285]; this document
way Delay, Round-trip Delay, Delay Variation, Loss Rate, and Hop provides a definition for it.
Count), and those related to bandwidth/throughput (Residual
bandwidth, and Available Bandwidth, and TCP throughput). These two These eight performance metrics can be classified into two
categories are defined in Sections 4 and 5 respectively. Note that categories: those derived from the performance of individual packets
all metrics except Round-trip Delay are unidirectional. An ALTO (i.e., one-way delay, round-trip delay, delay variation, loss rate,
and hop count) and those related to bandwidth/throughput (residual
bandwidth, available bandwidth, and TCP throughput). These two
categories are defined in Sections 4 and 5, respectively. Note that
all metrics except round-trip delay are unidirectional. An ALTO
client will need to query both directions if needed. 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 eight
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 guidelines defined in Section 14.2 of [RFC7285] on registering
[RFC7285] on registering ALTO cost metrics. Hence, it specifies the ALTO cost metrics. Hence, it specifies the identifier, the intended
identifier, the intended semantics, and the security considerations semantics, and the security considerations of each one of the metrics
of each one of the metrics specified in Table 1. 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 and are for guidance only, and they may work well for
On the other hand, a performance measurement framework, such as the ALTO. On the other hand, a performance measurement framework, such
IP Performance Measurement (IPPM) framework, may provide more details as the IP Performance Metrics (IPPM) framework, may provide more
in defining a performance metric. This document introduces a details for defining a performance metric. This document introduces
mechanism called "cost-context" to provide additional details, when a mechanism called "cost-context" to provide additional details, when
they are available; see Section 3. 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 specifications. In particular, [RFC7285] specifies that cost
values should be assumed by default as JSONNumber. When defining the values should be assumed by default to be 'JSONNumber'. When
value representation of each metric in Table 1, this document defining the value representation of each metric in Table 1, this
conforms to [RFC7285], but specifies additional, generic constraints document conforms to [RFC7285] but specifies additional, generic
on valid JSONNumbers for each metric. For example, each new metric constraints on valid JSONNumbers for each metric. For example, each
in Table 1 will be specified as non-negative (>= 0); Hop Count is new metric in Table 1 will be specified as non-negative (>= 0); Hop
specified to be an integer. Count is specified to be an integer.
An ALTO server may provide only a subset of the metrics described in An ALTO server may provide only a subset of the metrics described in
this document. For example, those that are subject to privacy this document. For example, those that are subject to privacy
concerns should not be provided to unauthorized ALTO clients. Hence, concerns should not be provided to unauthorized ALTO clients. Hence,
all cost metrics defined in this document are optional; not all of all cost metrics defined in this document are optional; not all of
them need to be exposed to a given application. When an ALTO server 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 regarding
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 promptly stop 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 7 discusses security considerations in even degrades it. Section 7 discusses security considerations in
more detail. more detail.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119][RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Performance Metric Attributes 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 TE performance metrics, and for guidance only.
guidance only. A fine-grained framework specified in [RFC6390] A fine-grained framework as specified in [RFC6390] requires that the
requires that the fine-grained specification of a network performance fine-grained specification of a network performance metric include
metric include 6 components: (i) Metric Name, (ii) Metric six components: (1) Metric Name, (2) Metric Description, (3) Method
Description, (iii) Method of Measurement or Calculation, (iv) Units of Measurement or Calculation, (4) Units of Measurement, (5)
of Measurement, (v) Measurement Points, and (vi) Measurement Timing. Measurement Points, and (6) Measurement Timing. Requiring that an
Requiring that an ALTO server provides precise, fine-grained values ALTO server provide precise, fine-grained values for all six
for all 6 components for each metric that it exposes may not be components for each metric that it exposes may not be feasible or
feasible or necessary for all ALTO use cases. For example, an ALTO necessary for all ALTO use cases. For example, an ALTO server
server computing its metrics from network-layer traffic-engineering computing its metrics from network-layer TE performance metrics may
performance metrics may not have information about the method of not have information about the method of measurement or calculation
measurement or calculation (e.g., measured traffic patterns). (e.g., measured traffic patterns).
To address the issue and realize ALTO use cases, for metrics in To address the issue and realize ALTO use cases for the metrics
Table 1, this document defines performance metric identifiers which listed in Table 1, this document defines performance metric
can be used in the ALTO protocol with well-defined (i) Metric Name, identifiers that can be used in the ALTO Protocol with the following
(ii) Metric Description, (iv) Units of Measurement, and (v) well-defined items: (1) Metric Name, (2) Metric Description, (3)
Measurement Points, which are always specified by the specific ALTO Units of Measurement, and (4) Measurement Points, which are always
services; for example, endpoint cost service is between the two specified by the specific ALTO services; for example, the endpoint
endpoints. Hence, the ALTO performance metric identifiers provide cost service is between the two endpoints. Hence, the ALTO
basic metric attributes. performance metric identifiers provide 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.
3.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", "sla", 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.
To make it possible to specify the source and the aforementioned To make it possible to specify the source and the aforementioned
parameters, this document introduces an optional "cost-context" field parameters, this document introduces an optional "cost-context" field
to the "cost-type" field defined by the ALTO base protocol to the "cost-type" field defined by the ALTO base protocol
(Section 10.7 of [RFC7285]) as the following: (Section 10.7 of [RFC7285]) as follows:
object { object {
CostMetric cost-metric; CostMetric cost-metric;
CostMode cost-mode; CostMode cost-mode;
[CostContext cost-context;] [CostContext cost-context;]
[JSONString description;] [JSONString description;]
} CostType; } CostType;
object { object {
JSONString cost-source; JSONString cost-source;
[JSONValue parameters;] [JSONValue parameters;]
} CostContext; } CostContext;
"cost-context" will not be used as a key to distinguish among "cost-context" will not be used as a key to distinguish among
performance metrics. Hence, an ALTO information resource MUST NOT performance metrics. Hence, an ALTO information resource MUST NOT
announce multiple CostType with the same "cost-metric", "cost-mode" announce multiple CostType entries with the same "cost-metric",
and "cost-context". They must be placed into different information "cost-mode", and "cost-context". They must be placed into different
resources. information 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 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. field 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 that is registered in the
Source" registry (Section 8). "ALTO Cost Source Types" 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 a Service Level
agreement (SLA). Some operators also use terms such as "target" or Agreement (SLA). Some operators also use terms such as "target" or
"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., see [RFC7471], [RFC8570], and [RFC8571]),
measurement management tools (e.g., TWAMP [RFC5357]), and measurement traffic measurement management tools (e.g., the Two-Way Active
frameworks (e.g., IPPM), with corresponding operational issues. An Measurement Protocol (TWAMP) [RFC5357]), and measurement frameworks
illustration of potential information flows used for estimating these (e.g., IPPM), with corresponding operational issues. An illustration
metrics is shown in Figure 1. Section 6 discusses in more detail the of potential information flows used for estimating these metrics is
shown in Figure 1. Section 6 discusses in more detail the
operational issues and how a network may address them. operational issues and how a network may address them.
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| Client | | Client | | Client | | Client | | Client | | Client |
+----^---+ +---^----+ +---^----+ +----^---+ +---^----+ +---^----+
| | | | | |
+-----------|-----------+ +-----------|-----------+
North-Bound |ALTO protocol |ALTO Protocol
Interface (NBI)| |
| |
+--+-----+ retrieval +-----------+ +--+-----+ retrieval +-----------+
| ALTO |<----------------| Routing | | ALTO |<----------------| Routing |
| Server | and aggregation| | | Server | and aggregation| Protocols |
| |<-------------+ | Protocols | | |<-------------+ | |
+--------+ | +-----------+ +--------+ | +-----------+
| |
| +------------+ | +------------+
| |Performance | | |Performance |
---| Monitoring | ---| Monitoring |
| Tools | | Tools |
+------------+ +------------+
Figure 1. A framework to compute estimation to performance metrics
There can be multiple choices in deciding the cost-source category. Figure 1: A Framework to Compute Estimation of Performance Metrics
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 There can be multiple options available when choosing the "cost-
assume that the value of "cost-source" is the most generic source, source" category; the operator of an ALTO server will make that
i.e., "estimation". choice. If a metric does not include a "cost-source" value, the
application MUST assume that the value of "cost-source" is the most
generic source, i.e., "estimation".
3.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 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:
A cost metric string consists of a base metric identifier (or base A cost metric string consists of a base metric identifier (or base
identifier for short) string, followed by an optional statistical identifier for short) string, followed by an optional statistical
operator string, connected by the ASCII character colon (':', operator string, connected by the ASCII colon character (':',
U+003A), if the statistical operator string exists. The total U+003A), if the statistical operator string exists. The total
length of the cost metric string MUST NOT exceed 32, as required length of the cost metric string MUST NOT exceed 32, as required
by [RFC7285]. by [RFC7285].
The statistical operator string MUST be one of the following: The statistical operator string MUST be one of the following:
cur: cur: The instantaneous observation value of the metric from the most
the instantaneous observation value of the metric from the most
recent sample (i.e., the current value). recent sample (i.e., the current value).
percentile, with letter 'p' followed by a number: percentile, with the letter 'p' followed by a number: Gives the
gives the percentile specified by the number following the letter percentile specified by the number following the letter 'p'. The
'p'. The number MUST be a non-negative JSON number in the range number MUST be a non-negative JSON number in the range [0, 100]
[0, 100] (i.e., greater than or equal to 0 and less than or equal (i.e., greater than or equal to 0 and less than or equal to 100),
to 100), followed by an optional decimal part, if a higher followed by an optional decimal part, if higher precision is
precision is needed. The decimal part should start with the '.' needed. The decimal part should start with the '.' separator
separator (U+002E), and followed by a sequence of one or more (U+002E) and be followed by a sequence of one or more ASCII
ASCII numbers between '0' and '9'. Assume this number is y and numbers between '0' and '9'. Assume that this number is y, and
consider the samples coming from a random variable X. Then the consider the case where the samples are coming from a random
metric returns x, such that the probability of X is less than or variable X. The metric then returns x, such that the probability
equal to x, i.e., Prob(X <= x), = y/100. For example, delay- of X is less than or equal to x, i.e., Prob(X <= x), = y/100. For
ow:p99 gives the 99% percentile of observed one-way delay; delay- example, delay-ow:p99 gives the 99th percentile of observed one-
ow:p99.9 gives the 99.9% percentile. Note that some systems use way delay; delay-ow:p99.9 gives the 99.9th percentile. Note that
quantile, which is in the range [0, 1]. When there is a more some systems use quantile, which is in the range [0, 1]. When
common form for a given percentile, it is RECOMMENDED that the there is a more common form for a given percentile, it is
common form be used; that is, instead of p0, use min; instead of RECOMMENDED that the common form be used; that is, instead of p0,
p50, use median; instead of p100, use max. use min; instead of p50, use median; instead of p100, use max.
min: min: The minimal value of the observations.
the minimal value of the observations.
max: max: The maximal value of the observations.
the maximal value of the observations.
median: median: The midpoint (i.e., p50) of the observations.
the mid-point (i.e., p50) of the observations.
mean: mean: The arithmetic mean value of the observations.
the arithmetic mean value of the observations.
stddev: stddev: The standard deviation of the observations.
the standard deviation of the observations.
stdvar: stdvar: The standard variance of the observations.
the standard variance of the observations.
Examples of cost metric strings then include "delay-ow", "delay- Examples of cost metric strings then include "delay-ow", "delay-
ow:min", "delay-ow:p99", where "delay-ow" is the base metric ow:min", and "delay-ow:p99", where "delay-ow" is the base metric
identifier string; "min" and "p99" are example statistical operator identifier string; "min" and "p99" are example statistical operator
strings. strings.
If a cost metric string does not have the optional statistical If a cost metric string does not have the optional statistical
operator string, the statistical operator SHOULD be interpreted as operator string, the statistical operator SHOULD be interpreted as
the default statistical operator in the definition of the base the default statistical operator in the definition of the base
metric. If the definition of the base metric does not provide a metric. If the definition of the base metric does not provide a
definition for the default statistical operator, the metric MUST be definition for the default statistical operator, the metric MUST be
considered as the median value. considered the median value.
Note that RFC 7258 limits the overall cost metric identifier to 32 Note that [RFC7285] 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 identifiers and statistical operators will not be
If such a situation arises, it could be addressed by defining a new representable. If such a situation arises, it could be addressed by
base metric identifier that is an "alias" of the desired base metric, defining a new base metric identifier that is an "alias" of the
with identical semantics and just a shorter name. desired base metric, with identical semantics and just a shorter
name.
4. 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 measurements of each individual packet (pkt) can include the delay
the time when the packet enters the network to the time when the from the time when the packet enters the network to the time when the
packet leaves the network (pkt.delay); whether the packet is dropped 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), and the number of
hops that the packet traverses (pkt.hopcount). The semantics of the network hops that the packet traverses (pkt.hopcount). The semantics
performance metrics defined in this section are that they are of the performance metrics defined in this section are that they are
statistics computed from these measures; for example, the statistics computed from these measurements; 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.
4.1. Cost Metric: One-Way Delay (delay-ow) 4.1. Cost Metric: One-Way Delay (delay-ow)
4.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".
4.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 specifications provided in Section 6 of [RFC8259]. The
expressed in microseconds. Hence, the number can be a floating point unit is expressed in microseconds. Hence, the number can be a
number to express delay that is smaller than microseconds. The floating-point number to express delay that is smaller than
number MUST be non-negative. microseconds. The number MUST be non-negative.
4.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 as defined in [RFC8571], [RFC8570],
instead of specifying the delay for a link, it is the (temporal) and [RFC7471], but instead of specifying the delay for a link, it
aggregation of the link delays from the source to the destination. A is the (temporal) aggregation of the link delays from the source
non-normative reference definition of end-to-end one-way delay is to the destination. A non-normative reference definition of the
[RFC7679]. The spatial aggregation level is specified in the query end-to-end one-way delay metric is provided in [RFC7679]. The
context, e.g., provider-defined identifier (PID) to PID, or endpoint spatial aggregation level is specified in the query context, e.g.,
to endpoint, where PID is defined in Section 5.1 of [RFC7285]. provider-defined identifier (PID) to PID, or endpoint to endpoint,
where the PID is as defined in Section 5.1 of [RFC7285].
Use: This metric could be used as a cost metric constraint attribute
or as a returned cost metric in the response.
Example 1: Delay value on source-destination endpoint pairs Use: This metric could be used as a cost metric constraint attribute
or as a returned cost metric in the response.
POST /endpointcost/lookup HTTP/1.1 POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com Host: alto.example.com
Content-Length: 239 Content-Length: 239
Content-Type: application/alto-endpointcostparams+json Content-Type: application/alto-endpointcostparams+json
Accept: Accept:
application/alto-endpointcost+json,application/alto-error+json application/alto-endpointcost+json,application/alto-error+json
{ {
"cost-type": { "cost-type": {
skipping to change at page 13, line 4 skipping to change at line 558
"endpoints": { "endpoints": {
"srcs": [ "srcs": [
"ipv4:192.0.2.2" "ipv4:192.0.2.2"
], ],
"dsts": [ "dsts": [
"ipv4:192.0.2.89", "ipv4:192.0.2.89",
"ipv4:198.51.100.34" "ipv4:198.51.100.34"
] ]
} }
} }
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 247 Content-Length: 247
Content-Type: application/alto-endpointcost+json Content-Type: application/alto-endpointcost+json
{ {
"meta": { "meta": {
"cost-type": { "cost-type": {
"cost-mode": "numerical", "cost-mode": "numerical",
"cost-metric": "delay-ow" "cost-metric": "delay-ow"
} }
}, },
"endpoint-cost-map": { "endpoint-cost-map": {
"ipv4:192.0.2.2": { "ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 10, "ipv4:192.0.2.89": 10,
"ipv4:198.51.100.34": 20 "ipv4:198.51.100.34": 20
} }
} }
} }
Figure 2: Delay Value on Source-Destination Endpoint Pairs
(Example 1)
Note that since the "cost-type" does not include the "cost-source" Note that since the "cost-type" does not include the "cost-source"
field, the values are based on "estimation". Since the identifier field, the values are based on "estimation". Since the identifier
does not include the statistical operator string component, the does not include the statistical operator string component, the
values will represent median values. values will represent median values.
Example 1a below shows an example that is similar to Example 1, but Figure 3 shows an example that is similar to Example 1 (Figure 2),
for IPv6. but for IPv6.
Example 1a: Delay value on source-destination endpoint pairs for IPv6
POST /endpointcost/lookup HTTP/1.1 POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com Host: alto.example.com
Content-Length: 252 Content-Length: 252
Content-Type: application/alto-endpointcostparams+json Content-Type: application/alto-endpointcostparams+json
Accept: Accept:
application/alto-endpointcost+json,application/alto-error+json application/alto-endpointcost+json,application/alto-error+json
{ {
"cost-type": { "cost-type": {
skipping to change at page 14, line 49 skipping to change at line 631
} }
}, },
"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
} }
} }
} }
Figure 3: Delay Value on Source-Destination Endpoint Pairs for
IPv6 (Example 1a)
4.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
named "link") providing an URI to the specification of SLA details, field named "link") providing a URI for the specification of SLA
if available. Such a specification can be either free text for details, if available. Such a specification can be either
possible presentation to the user, or a formal specification. The (1) free text for possible presentation to the user or (2) a
format of the specification is out of the scope of this document. formal specification. The format of the specification is outside
the scope of this document.
"estimation": The exact estimation method is out of the scope of this "estimation": The exact estimation method is outside the scope of
document. There can be multiple sources to estimate one-way delay. this document. There can be multiple sources for estimating one-
For example, the ALTO server may estimate the end-to-end delay by way delay. For example, the ALTO server may estimate the end-to-
aggregation of routing protocol link metrics; the server may also end delay by aggregation of routing protocol link metrics; the
estimate the delay using active, end-to-end measurements, for server may also estimate the delay using active, end-to-end
example, using the IPPM framework [RFC2330]. measurements -- for example, using the IPPM framework [RFC2330].
If the estimation is computed by aggregation of routing protocol link If the estimation is computed by aggregation of routing protocol link
metrics (e.g., OSPF [RFC7471], IS-IS [RFC8570], or BGP-LS [RFC8571]) metrics (e.g., Unidirectional Link Delay metrics for OSPF [RFC7471],
Unidirectional Delay link metrics, it is RECOMMENDED that the IS-IS [RFC8570], or BGP-LS [RFC8571]), it is RECOMMENDED that the
"parameters" field of an "estimation" one-way delay metric include "parameters" field of an "estimation" one-way delay metric include
the following information: (1) the RFC defining the routing protocol the following information: (1) the RFC defining the routing protocol
metrics (e.g., https://www.rfc-editor.org/info/rfc7471 for RFC7471 metrics (e.g., see [RFC7471] for derived metrics), (2) configurations
derived metrics); (2) configurations of the routing link metrics such of the routing link metrics such as configured intervals, and (3) the
as configured intervals; and (3) the aggregation method from link aggregation method from link metrics to end-to-end metrics. During
metrics to end-to-end metrics. During aggregation from link metrics aggregation from link metrics to end-to-end metrics, the server
to the end-to-end metric, the server should be cognizant of potential should be cognizant of potential issues when computing an end-to-end
issues when computing an end-to-end summary statistic from link summary statistic from link statistics. The default end-to-end
statistics. The default end-to-end average one-way delay is the sum average one-way delay is the sum of average link one-way delays. If
of average link one-way delays. If an ALTO server provides the min an ALTO server provides the min and max statistical operators for the
and max statistical operators for the one-way delay metric, the one-way delay metric, the values can be computed directly from the
values can be computed directly from the routing link metrics, as routing link metrics, as [RFC7471], [RFC8570], and [RFC8571] provide
[RFC7471,RFC8570,RFC8571] provide Min/Max Unidirectional Link Delay. Min/Max Unidirectional Link Delay.
If the estimation is from the IPPM measurement framework, it is If the estimation is from the IPPM measurement framework, it is
RECOMMEDED that the "parameters" field of an "estimation" one-way RECOMMENDED that the "parameters" field of an "estimation" one-way
delay metric includes the following information: the URI to the URI delay metric include the URI in the "URI" field of the IPPM metric
field of the IPPM metric defined in the IPPM performance metric defined in the IPPM "Performance Metrics" registry [IANA-IPPM] (e.g.,
[IANA-IPPM] registry (e.g., https://www.iana.org/assignments/ <https://www.iana.org/assignments/performance-metrics/
performance-metrics/OWDelay_Active_IP-UDP-Poisson- 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., 95th percentile).
4.2. Cost Metric: Round-trip Delay (delay-rt) 4.2. Cost Metric: Round-Trip Delay (delay-rt)
4.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".
4.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 specifications provided in Section 6 of [RFC8259]. The
MUST be non-negative. The unit is expressed in microseconds. number MUST be non-negative. The unit is expressed in microseconds.
4.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
trip delay between the specified source and specified destination. round-trip delay between the specified source and specified
The base semantics is that it is the sum of one-way delay from the destination. The base semantics is that it is the sum of the one-
source to the destination and the one-way delay from the destination way delay from the source to the destination and the one-way delay
back to the source, where the one-way delay is defined in from the destination back to the source, where the one-way delay
Section 4.1. A non-normative reference definition of end-to-end is as defined in Section 4.1. A non-normative reference
round-trip delay is [RFC2681]. The spatial aggregation level is definition of the end-to-end round-trip delay metric is provided
specified in the query context (e.g., PID to PID, or endpoint to in [RFC2681]. The spatial aggregation level is specified in the
endpoint). query context (e.g., PID to PID, or endpoint to endpoint).
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
be cognizant of the consistency of values.
Use: This metric could be used either as a cost metric constraint Note that it is possible for a client to query two one-way delay
attribute or as a returned cost metric in the response. (delay-ow) items and then compute the round-trip delay. The
server should be cognizant of the consistency of values.
Example 2: Round-trip Delay of source-destination endpoint pairs Use: This metric could be used as a cost metric constraint attribute
or as a returned cost metric in the response.
POST /endpointcost/lookup HTTP/1.1 POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com Host: alto.example.com
Content-Length: 238 Content-Length: 238
Content-Type: application/alto-endpointcostparams+json Content-Type: application/alto-endpointcostparams+json
Accept: Accept:
application/alto-endpointcost+json,application/alto-error+json application/alto-endpointcost+json,application/alto-error+json
{ {
"cost-type": { "cost-type": {
skipping to change at page 17, line 49 skipping to change at line 756
} }
}, },
"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
} }
} }
} }
Figure 4: Round-Trip Delay of Source-Destination Endpoint Pairs
(Example 2)
4.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
value. nominal value.
"sla": See the "sla" entry in Section 4.1.4. "sla": See the "sla" entry in Section 4.1.4.
"estimation": See the "estimation" entry in Section 4.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
the IPPM metric MUST be round-trip delay (i.e., IPPM RTDelay* IPPM, the IPPM metric MUST be round-trip delay (i.e., IPPM
metrics). The statistical operator of the ALTO metric MUST be RTDelay* metrics). The statistical operator of the ALTO metric
consistent with the IPPM statistical property (e.g., 95-th MUST be consistent with the IPPM statistical property (e.g., 95th
percentile). percentile).
4.3. Cost Metric: Delay Variation (delay-variation) 4.3. Cost Metric: Delay Variation (delay-variation)
4.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".
4.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 specifications provided in Section 6 of [RFC8259]. The
MUST be non-negative. The unit is expressed in microseconds. number MUST be non-negative. The unit is expressed in microseconds.
4.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 as
in Section 4.1. A non-normative reference definition of end-to-end defined in Section 4.1. A non-normative reference definition of
one-way delay variation is [RFC3393]. Note that [RFC3393] allows the the end-to-end one-way delay variation metric is provided in
specification of a generic selection function F to unambiguously [RFC3393]. Note that [RFC3393] allows the specification of a
define the two packets selected to compute delay variations. This generic selection function F to unambiguously define the two
document defines the specific case that F selects as the "first" packets selected to compute delay variations. This document
packet the one with the smallest one-way delay. The spatial defines the specific case where F selects the packet with the
aggregation level is specified in the query context (e.g., PID to smallest one-way delay as the "first" packet. The spatial
PID, or endpoint to endpoint). aggregation level is specified in the query context (e.g., PID to
PID, or endpoint to endpoint).
Note that in statistics, variations are typically evaluated by the
distance from samples relative to the mean. In networking context,
it is more commonly defined from samples relative to the min. This
definition follows the networking convention.
Use: This metric could be used either as a cost metric constraint Note that in statistics, variation is typically evaluated by the
attribute or as a returned cost metric in the response. distance from samples relative to the mean. In the context of
networking, it is more commonly defined from samples relative to
the min. This definition follows the networking convention.
Example 3: Delay variation value on source-destination endpoint pairs Use: This metric could be used as a cost metric constraint attribute
or as a returned cost metric in the response.
POST /endpointcost/lookup HTTP/1.1 POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com Host: alto.example.com
Content-Length: 245 Content-Length: 245
Content-Type: application/alto-endpointcostparams+json Content-Type: application/alto-endpointcostparams+json
Accept: Accept:
application/alto-endpointcost+json,application/alto-error+json application/alto-endpointcost+json,application/alto-error+json
{ {
"cost-type": { "cost-type": {
skipping to change at page 19, line 49 skipping to change at line 853
} }
}, },
"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
} }
} }
} }
Figure 5: Delay Variation Value on Source-Destination Endpoint
Pairs (Example 3)
4.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
value. nominal value.
"sla": See the "sla" entry in Section 4.1.4. "sla": See the "sla" entry in Section 4.1.4.
"estimation": See the "estimation" entry in Section 4.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
the link delay variations; for estimation using IPPM, the IPPM metric of the link delay variations; for estimation using IPPM, the IPPM
MUST be delay variation (i.e., IPPM OWPDV* metrics). The statistical metric MUST be delay variation (i.e., IPPM OWPDV* metrics). The
operator of the ALTO metric MUST be consistent with the IPPM statistical operator of the ALTO metric MUST be consistent with
statistical property (e.g., 95-th percentile). the IPPM statistical property (e.g., 95th percentile).
4.4. Cost Metric: Loss Rate (lossrate) 4.4. Cost Metric: Loss Rate (lossrate)
4.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".
4.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 specifications provided in Section 6 of [RFC8259]. The
MUST be non-negative. The value represents the percentage of packet number MUST be non-negative. The value represents the percentage of
losses. packet losses.
4.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 the temporal and spatial aggregated
way packet loss rate from the specified source and the specified one-way packet loss rate from the specified source and the
destination. The base semantics of the metric is the Unidirectional specified destination. The base semantics of the metric is the
Link Loss metric defined in [RFC8571,RFC8570,RFC7471], but instead of Unidirectional Link Loss metric as defined in [RFC8571],
specifying the loss for a link, it is the aggregated loss of all [RFC8570], and [RFC7471], but instead of specifying the loss for a
links from the source to the destination. The spatial aggregation link, it is the aggregated loss of all links from the source to
level is specified in the query context (e.g., PID to PID, or the destination. The spatial aggregation level is specified in
endpoint to endpoint). the query context (e.g., PID to PID, or endpoint to endpoint).
Use: This metric could be used as a cost metric constraint attribute
or as a returned cost metric in the response.
Example 5: Loss rate value on source-destination endpoint pairs Use: This metric could be used as a cost metric constraint attribute
or as a returned cost metric in the response.
POST /endpointcost/lookup HTTP/1.1 POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com Host: alto.example.com
Content-Length: 238 Content-Length: 238
Content-Type: application/alto-endpointcostparams+json Content-Type: application/alto-endpointcostparams+json
Accept: Accept:
application/alto-endpointcost+json,application/alto-error+json application/alto-endpointcost+json,application/alto-error+json
{ {
"cost-type": { "cost-type": {
skipping to change at page 21, line 49 skipping to change at line 940
} }
}, },
"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
} }
} }
} }
Figure 6: Loss Rate Value on Source-Destination Endpoint Pairs
(Example 4)
4.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, the packet loss rate does not have a nominal
although some networks may specify zero losses. value, although some networks may specify zero losses.
"sla": See the "sla" entry in Section 4.1.4.. "sla": See the "sla" entry in Section 4.1.4.
"estimation": See the "estimation" entry in Section 4.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 loss rate is the sum of the
link link loss rates. But this default aggregation is valid only if 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) link loss rates are low and (2) one
low, and (2) it assumes that each link's loss events are uncorrelated assumes that each link's loss events are uncorrelated with every
with every other link's loss events. When loss rates at the links other link's loss events. When loss rates at the links are high
are high but independent, the general formula for aggregating loss but independent, the general formula for aggregating loss,
assuming each link is independent is to compute end-to-end loss as assuming that each link is independent, is to compute end-to-end
one minus the product of the success rate for each link. Aggregation loss as one minus the product of the success rate for each link.
when losses at links are correlated can be more complex and the ALTO Aggregation when losses at links are correlated can be more
server should be cognizant of correlated loss rates. For estimation complex, and the ALTO server should be cognizant of correlated
using IPPM, the IPPM metric MUST be packet loss (i.e., IPPM OWLoss* loss rates. For estimation using IPPM, the IPPM metric MUST be
metrics). The statistical operator of the ALTO metric MUST be packet loss (i.e., IPPM OWLoss* metrics). The statistical
consistent with the IPPM statistical property (e.g., 95-th operator of the ALTO metric MUST be consistent with the IPPM
percentile). statistical property (e.g., 95th percentile).
4.5. Cost Metric: Hop Count (hopcount) 4.5. Cost Metric: Hop Count (hopcount)
The hopcount metric is mentioned in Section 9.2.3 of [RFC7285] as an The hop count (hopcount) metric is mentioned in Section 9.2.3 of
example. This section further clarifies its properties. [RFC7285] as an example. This section further clarifies its
properties.
4.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".
4.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 specifications provided in Section 6 of [RFC8259]. The
MUST be a non-negative integer (greater than or equal to 0). The number MUST be a non-negative integer (greater than or equal to 0).
value represents the number of hops. The value represents the number of hops.
4.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
a basic measurement of distance in a network and can be exposed as is a basic measurement of distance in a network and can be exposed
the number of router hops computed from the routing protocols as 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
or as a returned cost metric in the response.
Example 4: hopcount value on source-destination endpoint pairs Use: This metric could be used as a cost metric constraint attribute
or as a returned cost metric in the response.
POST /endpointcost/lookup HTTP/1.1 POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com Host: alto.example.com
Content-Length: 238 Content-Length: 238
Content-Type: application/alto-endpointcostparams+json Content-Type: application/alto-endpointcostparams+json
Accept: Accept:
application/alto-endpointcost+json,application/alto-error+json application/alto-endpointcost+json,application/alto-error+json
{ {
"cost-type": { "cost-type": {
skipping to change at page 23, line 49 skipping to change at line 1039
} }
}, },
"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
} }
} }
} }
Figure 7: Hop Count Value on Source-Destination Endpoint Pairs
(Example 5)
4.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, the hop count does not have a nominal value.
"sla": Typically hop count does not have an SLA value. "sla": Typically, the 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 outside the scope of
document. An example of estimating hopcounts is by importing from this document. An example of estimating hop count values is by
IGP routing protocols. It is RECOMMENDED that the "parameters" field importing from IGP routing protocols. It is RECOMMENDED that the
of an "estimation" hop count define the meaning of a hop. "parameters" field of an "estimation" hop count define the meaning
of a hop.
5. Throughput/Bandwidth Performance Metrics 5. Throughput/Bandwidth Performance Metrics
This section introduces four throughput/bandwidth related metrics. This section introduces three metrics related to throughput and
Given a specified source to a specified destination, these metrics bandwidth. Given a specified source and a specified destination,
reflect the volume of traffic that the network can carry from the these metrics reflect the volume of traffic that the network can
source to the destination. carry from the source to the destination.
5.1. Cost Metric: TCP Throughput (tput) 5.1. Cost Metric: TCP Throughput (tput)
5.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".
5.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 specifications provided in Section 6 of [RFC8259]. The
MUST be non-negative. The unit is bytes per second. number MUST be non-negative. The unit is bytes per second.
5.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 congestion control
control conforming flow from the specified source to the specified conforming TCP 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
or as a returned cost metric in the response.
Example 5: TCP throughput value on source-destination endpoint pairs Use: This metric could be used as a cost metric constraint attribute
or as a returned cost metric in the response.
POST /endpointcost/lookup HTTP/1.1 POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com Host: alto.example.com
Content-Length: 234 Content-Length: 234
Content-Type: application/alto-endpointcostparams+json Content-Type: application/alto-endpointcostparams+json
Accept: Accept:
application/alto-endpointcost+json,application/alto-error+json application/alto-endpointcost+json,application/alto-error+json
{ {
"cost-type": { "cost-type": {
skipping to change at page 25, line 49 skipping to change at line 1125
} }
}, },
"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
} }
} }
} }
Figure 8: TCP Throughput Value on Source-Destination Endpoint
Pairs (Example 6)
5.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 outside the scope of
document. It is RECOMMENDED that the "parameters" field of an this document. It is RECOMMENDED that the "parameters" field of
"estimation" TCP throughput metric include the following information: an "estimation" TCP throughput metric include the following
(1) the congestion-control algorithm; and (2) the estimation information: (1) the congestion control algorithm and (2) the
methodology. To specify (1), it is RECOMMENDED that the "parameters" estimation methodology. To specify (1), it is RECOMMENDED that
field (object) include a field named "congestion-control-algorithm", the "parameters" field (object) include a field named "congestion-
which provides a URI for the specification of the algorithm; for control-algorithm", which provides a URI for the specification of
example, for an ALTO server to provide estimation to the throughput the algorithm; for example, for an ALTO server to provide
of a Cubic Congestion control flow, its "parameters" includes a field estimation of the throughput of a CUBIC congestion control flow,
"congestion-control-algorithm", with value being set to its "parameters" field includes the "congestion-control-algorithm"
[I-D.ietf-tcpm-rfc8312bis]; for an ongoing congestion control field, with value being set to the URI for [RFC9438]; for an
algorithm such as BBR, a a link to its specification. To specify ongoing congestion control algorithm such as BBR, a link to its
(2), the "parameters" includes as many details as possible; for specification can be added. To specify (2), the "parameters"
example, for TCP Cubic throughout estimation, the "parameters" field field includes as many details as possible; for example, for the
specifies that the throughput is estimated by setting _C_ to 0.4, and TCP Cubic throughout estimation, the "parameters" field specifies
the Equation in Figure 8 of [I-D.ietf-tcpm-rfc8312bis] is applied; as that the throughput is estimated by setting _C_ to 0.4, and the
an alternative, the methodology may be based on the NUM model equation in [RFC9438], Section 5.1, Figure 8 is applied; as an
[Prophet], or the G2 model [G2]. The exact specification of the alternative, the methodology may be based on the NUM model
parameters field is out of the scope of this document. [Prophet] or the model described in [G2]. The exact specification
of the "parameters" field is outside the scope of this document.
5.2. Cost Metric: Residual Bandwidth (bw-residual) 5.2. Cost Metric: Residual Bandwidth (bw-residual)
5.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".
5.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.
5.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 to 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 as defined in [RFC8571], [RFC8570], and
specifying the residual bandwidth for a link, it is the residual [RFC7471], but instead of specifying the residual bandwidth for a
bandwidth of the path from the source to the destination. Hence, it link, it is the residual bandwidth of the path from the source to
is the minimal residual bandwidth among all links from the source to the destination. Hence, it is the minimal residual bandwidth
the destination. When the max statistical operator is defined for among all links from the source to the destination. When the max
the metric, it typically provides the minimum of the link capacities statistical operator is defined for the metric, it typically
along the path, as the default value of the residual bandwidth of a provides the minimum of the link capacities along the path, as the
link is its link capacity [RFC8571,8570,7471]. The spatial default value of the residual bandwidth of a link is its link
aggregation unit is specified in the query context (e.g., PID to PID, capacity [RFC8571] [RFC8570] [RFC7471]. The spatial aggregation
or endpoint to endpoint). unit is specified in the query context (e.g., PID to PID, or
endpoint to endpoint).
The default statistical operator for residual bandwidth is the
current instantaneous sample; that is, the default is assumed to be
"cur".
Use: This metric could be used either as a cost metric constraint The default statistical operator for residual bandwidth is the
attribute or as a returned cost metric in the response. current instantaneous sample; that is, the default is assumed to
be "cur".
Example 7: bw-residual value on source-destination endpoint pairs Use: This metric could be used as a cost metric constraint attribute
or as a returned cost metric in the response.
POST /endpointcost/lookup HTTP/1.1 POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com Host: alto.example.com
Content-Length: 241 Content-Length: 241
Content-Type: application/alto-endpointcostparams+json Content-Type: application/alto-endpointcostparams+json
Accept: Accept:
application/alto-endpointcost+json,application/alto-error+json application/alto-endpointcost+json,application/alto-error+json
{ {
"cost-type": { "cost-type": {
skipping to change at page 28, line 4 skipping to change at line 1214
"endpoints": { "endpoints": {
"srcs": [ "srcs": [
"ipv4:192.0.2.2" "ipv4:192.0.2.2"
], ],
"dsts": [ "dsts": [
"ipv4:192.0.2.89", "ipv4:192.0.2.89",
"ipv4:198.51.100.34" "ipv4:198.51.100.34"
] ]
} }
} }
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 255 Content-Length: 255
Content-Type: application/alto-endpointcost+json Content-Type: application/alto-endpointcost+json
{ {
"meta": { "meta": {
"cost-type": { "cost-type": {
"cost-mode": "numerical", "cost-mode": "numerical",
"cost-metric": "bw-residual" "cost-metric": "bw-residual"
} }
}, },
"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
} }
} }
} }
Figure 9: Residual Bandwidth Value on Source-Destination Endpoint
Pairs (Example 7)
5.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 4.1.4 on "estimation": See the "estimation" entry in Section 4.1.4. The
aggregation of routing protocol link metrics. The current ("cur") current ("cur") residual bandwidth of a path is the minimal
residual bandwidth of a path is the minimal of the residual bandwidth residual bandwidth of all links on the path.
of all links on the path.
5.3. Cost Metric: Available Bandwidth (bw-available) 5.3. Cost Metric: Available Bandwidth (bw-available)
5.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".
5.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.
5.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 as defined in [RFC8571], [RFC8570], and
specifying the available bandwidth for a link, it is the available [RFC7471], but instead of specifying the available bandwidth for a
bandwidth of the path from the source to the destination. Hence, it link, it is the available bandwidth of the path from the source to
is the minimal available bandwidth among all links from the source to the destination. Hence, it is the minimal available bandwidth
the destination.The spatial aggregation unit is specified in the among all links from the source to the destination. The spatial
query context (e.g., PID to PID, or endpoint to endpoint). aggregation unit is specified in the query context (e.g., PID to
PID, or endpoint to endpoint).
The default statistical operator for available bandwidth is the
current instantaneous sample; that is, the default is assumed to be
"cur".
Use: This metric could be used either as a cost metric constraint The default statistical operator for available bandwidth is the
attribute or as a returned cost metric in the response. current instantaneous sample; that is, the default is assumed to
be "cur".
Example 8: bw-available value on source-destination endpoint pairs Use: This metric could be used as a cost metric constraint attribute
or as a returned cost metric in the response.
POST /endpointcost/lookup HTTP/1.1 POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com Host: alto.example.com
Content-Length: 244 Content-Length: 244
Content-Type: application/alto-endpointcostparams+json Content-Type: application/alto-endpointcostparams+json
Accept: Accept:
application/alto-endpointcost+json,application/alto-error+json application/alto-endpointcost+json,application/alto-error+json
{ {
"cost-type": { "cost-type": {
skipping to change at page 30, line 4 skipping to change at line 1301
"endpoints": { "endpoints": {
"srcs": [ "srcs": [
"ipv4:192.0.2.2" "ipv4:192.0.2.2"
], ],
"dsts": [ "dsts": [
"ipv4:192.0.2.89", "ipv4:192.0.2.89",
"ipv4:198.51.100.34" "ipv4:198.51.100.34"
] ]
} }
} }
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 255 Content-Length: 255
Content-Type: application/alto-endpointcost+json Content-Type: application/alto-endpointcost+json
{ {
"meta": { "meta": {
"cost-type": { "cost-type": {
"cost-mode": "numerical", "cost-mode": "numerical",
"cost-metric": "bw-available" "cost-metric": "bw-available"
} }
}, },
"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
} }
} }
} }
Figure 10: Available Bandwidth Value on Source-Destination
Endpoint Pairs (Example 8)
5.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 4.1.4 on "estimation": See the "estimation" entry in Section 4.1.4. The
aggregation of routing protocol link metrics. The current ("cur") current ("cur") available bandwidth of a path is the minimum of
available bandwidth of a path is the minimum of the available the available bandwidth of all links on the path.
bandwidth of all links on the path.
6. Operational Considerations 6. Operational Considerations
The exact measurement infrastructure, measurement condition, and The exact measurement infrastructure, measurement conditions, and
computation algorithms can vary from different networks, and are computation algorithms can vary between 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 in the following sub-sections. discussed in the following subsections.
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 issues that the
unless one metric has its unique challenges. performance metrics might have in common and also discusses
challenges regarding the computation of ALTO performance metrics
(Section 6.4).
6.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 solves a key issue: an ALTO
ALTO server needs data sources to compute the cost metrics described server needs data sources to compute the cost metrics described in
in this document, and an ALTO client needs to know the data sources this document, and an ALTO client needs to know the data sources to
to better interpret the values. better interpret the values.
To avoid too fine-grained information, this document introduces To avoid information that is too fine grained, this document
"cost-source" to indicate only the high-level type of data sources: introduces "cost-source" to indicate only the high-level types of
"estimation", "nominal" or "lsa", where "estimation" is a type of data sources: "estimation", "nominal", or "sla", where "estimation"
measurement data source, "nominal" is a type of static configuration, is a type of measurement data source, "nominal" is a type of static
and "sla" is a type that is more based on policy. configuration, and "sla" is a type that is based more on policy.
For estimation, for example, the ALTO server may use log servers or For example, for "estimation", the ALTO server may use log servers or
the OAM system as its data source as recommended by [RFC7971]. In the Operations, Administration, and Maintenance (OAM) system as its
particular, the cost metrics defined in this document can be computed data source, as recommended by [RFC7971]. In particular, the cost
using routing systems as the data sources. metrics defined in this document can be computed using routing
systems as the data sources.
6.2. Metric Timestamp Consideration 6.2. Metric Timestamp Considerations
Despite the introduction of the additional cost-context information, Despite the introduction of the additional "cost-context"
the metrics do not have a field to indicate the timestamps of the information, the metrics do not have a field to indicate the
data used to compute the metrics. To indicate this attribute, the timestamps of the data used to compute the metrics. To indicate this
ALTO server SHOULD return HTTP "Last-Modified", to indicate the attribute, the ALTO server SHOULD return an HTTP Last-Modified value
freshness of the data used to compute the performance metrics. to indicate the 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.
6.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 the case where an IRD defines two
types with the same "cost-mode" and "cost-metric", but one with "cost-type" entries with the same "cost-mode" and "cost-metric", but
"cost-source" being "estimation" and the other being "sla". Then an one with "cost-source" being "estimation" and the other being "sla".
ALTO client that is not aware of the extension will not be able to In such a case, an ALTO client that is not aware of the extension
distinguish between these two types. A similar issue can arise even will not be able to distinguish between these two types. A similar
with a single cost-type, whose "cost-source" is "sla": an ALTO client issue can arise even with a single "cost-type" whose "cost-source" is
that is not aware of this extension will ignore this field and "sla": an ALTO client that is not aware of this extension will ignore
consider the metric estimation. this field and instead 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.
6.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 of 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. The computation of ALTO
computation of ALTO performance metrics. performance metrics can present two challenges.
6.4.1. Configuration Parameters Considerations 6.4.1. Configuration Parameter 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) at
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 were 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.
6.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 information. For example, routing protocols
and report only per link loss, not end-to-end loss; similarly, often measure and report only per-link loss and not end-to-end loss;
routing protocols report link level available bandwidth, not end-to- similarly, routing protocols report link-level available bandwidth
end available bandwidth. The ALTO server then needs to aggregate and not end-to-end available bandwidth. The ALTO server then needs
these data to provide an abstract and unified view that can be more to aggregate these data to provide an abstract and unified view that
useful to applications. The server should consider that different can be more useful to applications. The server should be aware that
metrics may use different aggregation computation. For example, the different metrics may use different aggregation computations. For
end-to-end latency of a path is the sum of the latency of the links example, the end-to-end latency of a path is the sum of the latencies
on the path; the end-to-end available bandwidth of a path is the of the links on the path; the end-to-end available bandwidth of a
minimum of the available bandwidth of the links on the path; in path is the minimum of the available bandwidth of the links on the
contrast, aggregating loss values is complicated by the potential for path; in contrast, aggregating loss values is complicated by the
correlated loss events on different links in the path potential for correlated loss events on different links in the path.
7. 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, 15.2, and 15.3 of However, concerns addressed in Sections 15.1, 15.2, and 15.3 of
[RFC7285] remain of utmost importance. Indeed, Traffic Engineering [RFC7285] remain of utmost importance. Indeed, TE performance is
(TE) performance is highly sensitive ISP information; therefore, highly sensitive ISP information; therefore, sharing TE metric values
sharing TE metric values in numerical mode requires full mutual in numerical mode requires full mutual confidence between the
confidence between the entities managing the ALTO server and the ALTO entities managing the ALTO server and the ALTO client. ALTO servers
client. ALTO servers will most likely distribute numerical TE will most likely distribute numerical TE performance to ALTO clients
performance to ALTO clients under strict and formal mutual trust under strict and formal mutual trust agreements. On the other hand,
agreements. On the other hand, ALTO clients must be cognizant on the ALTO clients must be cognizant of the risks attached to such
risks attached to such information that they would have acquired information that they would have acquired outside formal conditions
outside formal conditions of mutual trust. 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 such attacks as person-in-the-middle (PITM) attacks. As
specified in "Protection Strategies" (Section 15.3.2 of [RFC7285]), specified in Section 15.3.2 ("Protection Strategies") 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. Section 8.3.5 ("Authentication and Encryption") of
[RFC7285]) specifies that "ALTO Server implementations as well as [RFC7285] specifies that ALTO server implementations as well as ALTO
ALTO Client implementations MUST support the "https" URI scheme of client implementations MUST support the "https" URI scheme [RFC9110]
[RFC7230] and Transport Layer Security (TLS) of [RFC8446]". and Transport Layer Security (TLS) [RFC8446].
8. IANA Considerations 8. IANA Considerations
IANA has created and now maintains the "ALTO Cost Metric" registry, 8.1. ALTO Cost Metrics Registry
listed in Section 14.2, Table 3 of [RFC7285]. This registry is
located at <https://www.iana.org/assignments/alto-protocol/alto-
protocol.xhtml#cost-metrics>. This document requests to add the
following entries to the "ALTO Cost Metric" registry.
+-----------------+----------------------------+ IANA created and now maintains the "ALTO Cost Metrics" registry, as
| Identifier | Intended Semantics | listed in [RFC7285], Section 14.2, Table 3. This registry is located
+-----------------+----------------------------+ at <https://www.iana.org/assignments/alto-protocol/>. IANA has added
| delay-ow | Section 4.1 of [RFCXXX] | the following entries to the "ALTO Cost Metrics" registry.
| delay-rt | Section 4.2 of [RFCXXX] |
| delay-variation | Section 4.3 of [RFCXXX] |
| lossrate | Section 4.4 of [RFCXXX] |
| hopcount | Section 4.5 of [RFCXXX] |
| tput | Section 5.1 of [RFCXXX] |
| bw-residual | Section 5.2 of [RFCXXX] |
| bw-available | Section 5.3 of [RFCXXX] |
+-----------------+----------------------------+
* [Note to the RFC Editor]: Please replace RFCXXX with the RFC +=================+====================+===========+
number assigned to this document. | Identifier | Intended Semantics | Reference |
+=================+====================+===========+
| delay-ow | See Section 4.1 | RFC 9439 |
+-----------------+--------------------+-----------+
| delay-rt | See Section 4.2 | RFC 9439 |
+-----------------+--------------------+-----------+
| delay-variation | See Section 4.3 | RFC 9439 |
+-----------------+--------------------+-----------+
| lossrate | See Section 4.4 | RFC 9439 |
+-----------------+--------------------+-----------+
| hopcount | See Section 4.5 | RFC 9439 |
+-----------------+--------------------+-----------+
| tput | See Section 5.1 | RFC 9439 |
+-----------------+--------------------+-----------+
| bw-residual | See Section 5.2 | RFC 9439 |
+-----------------+--------------------+-----------+
| bw-available | See Section 5.3 | RFC 9439 |
+-----------------+--------------------+-----------+
This document requests the creation of the "ALTO Cost Source" Table 2: ALTO Cost Metrics Registry
registry. This registry serves two purposes. First, it ensures
uniqueness of identifiers referring to ALTO cost source types.
Second, it provides references to particular semantics of allocated
cost source types to be applied by both ALTO servers and applications
utilizing ALTO clients.
A new ALTO cost source can be added after IETF Review [RFC8126], to 8.2. ALTO Cost Source Types Registry
ensure that proper documentation regarding the new ALTO cost source
and its security considerations have been provided. The RFC(s) IANA has created the "ALTO Cost Source Types" registry. This
documenting the new cost source should be detailed enough to provide registry serves two purposes. First, it ensures the uniqueness of
guidance to both ALTO service providers and applications utilizing identifiers referring to ALTO cost source types. Second, it provides
ALTO clients as to how values of the registered ALTO cost source references to particular semantics of allocated cost source types to
should be interpreted. Updates and deletions of ALTO cost source be applied by both ALTO servers and applications utilizing ALTO
follow the same procedure. clients.
A new ALTO cost source type can be added after IETF Review [RFC8126],
to ensure that proper documentation regarding the new ALTO cost
source type and its security considerations has been provided. The
RFC(s) documenting the new cost source type should be detailed enough
to provide guidance to both ALTO service providers and applications
utilizing ALTO clients as to how values of the registered ALTO cost
source type should be interpreted. Updates and deletions of ALTO
cost source types follow the same procedure.
Registered ALTO address type identifiers MUST conform to the Registered ALTO address type identifiers MUST conform to the
syntactical requirements specified in Section 3.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 types carry with them semantics
semantics to guide their usage by ALTO clients. Hence, a document to guide their usage by ALTO clients. Hence, a document defining
defining a new type should provide guidance to both ALTO service a new type should provide guidance to both ALTO service providers
providers and applications utilizing ALTO clients as to how values and applications utilizing ALTO clients as to how values of the
of the registered ALTO endpoint property should be interpreted. 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 IANA has registered the identifiers "nominal", "sla", and
"nominal", "sla", and "estimation" listed in the table below. "estimation" as listed in the table below.
Semantics for the these are documented in Section 3.1, and security
considerations are documented in Section 7.
+------------+----------------------------------+----------------+
| Identifier | Intended Semantics | Security |
| | | Considerations |
+------------+----------------------------------+----------------+
| nominal | Values in nominal cases; | Section 7 of |
| | Section 3.1 of [RFCXXX] | [RFCXXX] |
| sla | Values reflecting service level | Section 7 of |
| | agreement; Section 3.1 of | [RFCXXX] |
| | [RFCXXXX] | |
| estimation | Values by estimation; | Section 7 of |
| | Section 3.1 of [RFCXXX] | [RFCXXX] |
+------------+----------------------------------+----------------+
9. Acknowledgments
The authors of this document would also like to thank Martin Duke for +============+=========================+================+===========+
the highly informative, thorough AD reviews and comments. We thank | Identifier | Intended | Security | Reference |
Christian Amsuess, Elwyn Davies, Haizhou Du, Kai Gao, Geng Li, Lili | | Semantics | Considerations | |
Liu, Danny Alex Lachos Perez, and Brian Trammell for the reviews and +============+=========================+================+===========+
comments. We thank Benjamin Kaduk, Eric Kline, Francesca Palombini, | nominal | Values in nominal | Section 7 | RFC 9439 |
Lars Eggert, Martin Vigoureux, Murrary Kucherawy, Roman Danyliw, | | cases | | |
Zaheduzzaman Sarker, Eric Vyncke for discussions and comments that | | (Section 3.1) | | |
improve this document. +------------+-------------------------+----------------+-----------+
| sla | Values reflecting | Section 7 | RFC 9439 |
| | Service Level | | |
| | Agreement | | |
| | (Section 3.1) | | |
+------------+-------------------------+----------------+-----------+
| estimation | Values by | Section 7 | RFC 9439 |
| | estimation | | |
| | (Section 3.1) | | |
+------------+-------------------------+----------------+-----------+
10. References Table 3: ALTO Cost Source Types Registry
10.1. Normative References 9. References
[I-D.ietf-tcpm-rfc8312bis] 9.1. Normative References
Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, "CUBIC
for Fast and Long-Distance Networks", Work in Progress,
Internet-Draft, draft-ietf-tcpm-rfc8312bis-07, 4 March
2022, <https://www.ietf.org/archive/id/draft-ietf-tcpm-
rfc8312bis-07.txt>.
[IANA-IPPM] [IANA-IPPM]
IANA, "Performance Metrics Registry, IANA, "Performance Metrics",
https://www.iana.org/assignments/performance-metrics/ <https://www.iana.org/assignments/performance-metrics/>.
performance-metrics.xhtml".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>. <https://www.rfc-editor.org/info/rfc3630>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>. 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390, Performance Metric Development", BCP 170, RFC 6390,
DOI 10.17487/RFC6390, October 2011, DOI 10.17487/RFC6390, October 2011,
<https://www.rfc-editor.org/info/rfc6390>. <https://www.rfc-editor.org/info/rfc6390>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy, Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol", "Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014, RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>. <https://www.rfc-editor.org/info/rfc7285>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>. <https://www.rfc-editor.org/info/rfc7471>.
skipping to change at page 37, line 21 skipping to change at line 1633
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>.
10.2. Informative References [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9438] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed.,
"CUBIC for Fast and Long-Distance Networks", RFC 9438,
DOI 10.17487/RFC9438, August 2023,
<https://www.rfc-editor.org/info/rfc9438>.
9.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 '19, December 2019.
[G2] Ros-Giralt, J., Bohara, A., Yellamraju, S., and et. al.,
"On the Bottleneck Structure of Congestion-Controlled
Networks", ACM SIGMETRICS 2019, 2020.
[I-D.corre-quic-throughput-testing] [G2] Ros-Giralt, J., Bohara, A., Yellamraju, S., Harper
Corre, K., "Framework for QUIC Throughput Testing", Work Langston, M., Lethin, R., Jiang, Y., Tassiulas, L., Li,
in Progress, Internet-Draft, draft-corre-quic-throughput- J., Tan, Y., and M. Veeraraghavan, "On the Bottleneck
testing-00, 17 September 2021, Structure of Congestion-Controlled Networks", Proceedings
<https://www.ietf.org/archive/id/draft-corre-quic- of the ACM on Measurement and Analysis of Computing
throughput-testing-00.txt>. Systems, Vol. 3, No. 3, Article No. 59, pp. 1-31,
DOI 10.1145/3366707, December 2019,
<https://dl.acm.org/doi/10.1145/3366707>.
[Prometheus] [Prometheus]
Volz, J. and B. Rabenstein, "Prometheus: A Next-Generation Volz, J. and B. Rabenstein, "Prometheus: A Next-Generation
Monitoring System", 2015. Monitoring System (Talk)", SREcon15 Europe, May 2015.
[Prophet] Gao, K., Zhang, J., and YR. Yang, "Prophet: Fast, Accurate [Prophet] Zhang, J., Gao, K., Yang, YR., and J. Bi, "Prophet: Toward
Throughput Prediction with Reactive Flows", ACM/IEEE Fast, Error-Tolerant Model-Based Throughput Prediction for
Transactions on Networking July, 2020. Reactive Flows in DC Networks", IEEE/ACM Transactions on
Networking, Volume 28, Issue 601, pp. 2475-2488, December
2020, <https://dl.acm.org/doi/10.1109/TNET.2020.3016838>.
[QUIC-THROUGHPUT-TESTING]
Corre, K., "Framework for QUIC Throughput Testing", Work
in Progress, Internet-Draft, draft-corre-quic-throughput-
testing-00, 17 September 2021,
<https://datatracker.ietf.org/doc/html/draft-corre-quic-
throughput-testing-00>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998, DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>. <https://www.rfc-editor.org/info/rfc2330>.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
September 1999, <https://www.rfc-editor.org/info/rfc2681>. September 1999, <https://www.rfc-editor.org/info/rfc2681>.
skipping to change at page 38, line 35 skipping to change at line 1711
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 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
Acknowledgments
The authors of this document would like to thank Martin Duke for the
highly informative, thorough AD reviews and comments. We thank
Christian Amsüss, Elwyn Davies, Haizhou Du, Kai Gao, Geng Li, Lili
Liu, Danny Alex Lachos Perez, and Brian Trammell for their reviews
and comments. We thank Benjamin Kaduk, Erik Kline, Francesca
Palombini, Lars Eggert, Martin Vigoureux, Murray Kucherawy, Roman
Danyliw, Zaheduzzaman Sarker, and Éric Vyncke for discussions and
comments that improved this document.
Authors' Addresses Authors' Addresses
Qin Wu Qin Wu
Huawei Huawei
101 Software Avenue, Yuhua District Yuhua District
101 Software Avenue
Nanjing Nanjing
Jiangsu, 210012 Jiangsu, 210012
China China
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
Y. Richard Yang Y. Richard Yang
Yale University Yale University
51 Prospect St 51 Prospect St.
New Haven, CT 06520 New Haven, CT 06520
United States of America United States of America
Email: yry@cs.yale.edu Email: yry@cs.yale.edu
Young Lee Young Lee
Samsung Samsung
Email: young.lee@gmail.com Email: younglee.tx@gmail.com
Dhruv Dhody Dhruv Dhody
Huawei Huawei
Leela Palace
Bangalore 560008
Karnataka
India India
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Sabine Randriamasy Sabine Randriamasy
Nokia Bell Labs Nokia Networks France
Route de Villejust
91460 Nozay
France France
Email: sabine.randriamasy@nokia-bell-labs.com Email: sabine.randriamasy@nokia-bell-labs.com
Luis Miguel Contreras Murillo Luis Miguel Contreras Murillo
Telefonica Telefonica
Madrid Madrid
Spain Spain
Email: luismiguel.contrerasmurillo@telefonica.com Email: luismiguel.contrerasmurillo@telefonica.com
 End of changes. 176 change blocks. 
725 lines changed or deleted 767 lines changed or added

This html diff was produced by rfcdiff 1.48.