Application-Layer Traffic Optimization (ALTO) provides a means for network applications to obtain network information so that the applications can identify efficient application-layer traffic patterns using the networks. Cost metrics are used in both the ALTO cost map service and the ALTO endpoint cost service in the ALTO base protocol [RFC 7285
Since different applications may use different cost metrics, the ALTO base protocol introduced the "ALTO Cost Metrics" registry (Section 14.2
of RFC 7285
) as a systematic mechanism to allow different metrics to be specified. For example, a delay-sensitive application may want to use latency-related metrics, and a bandwidth-sensitive application may want to use bandwidth-related metrics. However, the ALTO base protocol has registered only a single cost metric, i.e., the generic "routingcost" metric (Section 14.2
of RFC 7285
); 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 applications to determine where to connect based on network performance criteria, including delay- and bandwidth-related metrics.
Table 1: Cost Metrics Defined in This Document
The first six metrics listed in Table 1
(i.e., one-way delay, round-trip delay, delay variation, loss rate, residual bandwidth, and available bandwidth) are derived from the set of Traffic Engineering (TE) performance metrics commonly defined in OSPF [RFC 3630
] [RFC 7471
], IS-IS [RFC 5305
] [RFC 8570
], and BGP - Link State (BGP-LS) [RFC 8571
]. Deriving ALTO cost performance metrics from existing network-layer TE performance metrics, and making it exposed to ALTO, can be a typical mechanism used by network operators to deploy ALTO [RFC 7971
]. 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 Min/Max Unidirectional Link Delay metric as defined in [RFC 8570
] and [RFC 8571
], and Maximum (Link) Bandwidth as defined in [RFC 3630
] and [RFC 5305
], are not listed in Table 1
because they can be handled by applying the statistical operators defined in this document. The metrics related to utilized bandwidth and reservable bandwidth (i.e., Maximum Reservable (Link) Bandwidth and Unreserved Bandwidth as defined in [RFC 3630
] and [RFC 5305
]) are outside the scope of this document.
The seventh metric in Table 1
(the estimated TCP-flow throughput metric) provides an estimation of the bandwidth of a TCP flow, using TCP throughput modeling, to support use cases of adaptive applications [Prophet
]. Note that other transport-specific metrics can be defined in the future. For example, QUIC-related metrics [RFC 9000
] can be considered when the methodology for measuring such metrics is more mature (e.g., see [QUIC-THROUGHPUT-TESTING
The eighth metric in Table 1
(the hop count metric) is mentioned, but not defined, in the ALTO base protocol [RFC 7285
]; this document provides a definition for it.
These eight performance metrics can be classified into two categories: those derived from the performance of individual packets (i.e., one-way delay, round-trip delay, delay variation, loss rate, and hop count) and those related to bandwidth/throughput (residual bandwidth, available bandwidth, and TCP throughput). These two categories are defined in Sections [4
] and [5
], respectively. Note that all metrics except round-trip delay are unidirectional. An ALTO client will need to query both directions if needed.
The purpose of this document is to ensure proper usage of these eight performance metrics in the context of ALTO. This document follows the guidelines defined in Section 14.2
of RFC 7285
on registering ALTO cost metrics. Hence, it specifies the identifier, the intended semantics, and the security considerations of each one of the metrics specified in Table 1
The definitions of the intended semantics of the metrics tend to be coarse grained and are for guidance only, and they may work well for ALTO. On the other hand, a performance measurement framework, such as the IP Performance Metrics (IPPM) framework, may provide more details for defining a performance metric. This document introduces a mechanism called "cost-context" to provide additional details, when they are available; see Section 3
Following the ALTO base protocol, this document uses JSON to specify the value type of each defined metric. See [RFC 8259
] for JSON data type specifications. In particular, [RFC 7285
] specifies that cost values should be assumed by default to be 'JSONNumber'. When defining the value representation of each metric in Table 1
, this document conforms to [RFC 7285
] but specifies additional, generic constraints on valid JSONNumbers for each metric. For example, each new metric in Table 1
will be specified as non-negative (>= 0); Hop Count is specified to be an integer.
An ALTO server may provide only a subset of the metrics described in this document. For example, those that are subject to privacy concerns should not be provided to unauthorized ALTO clients. Hence, all cost metrics defined in this document are optional; not all of them need to be exposed to a given application. When an ALTO server supports a cost metric defined in this document, it announces the metric in its information resource directory (IRD) as defined in Section 9.2
of RFC 7285
An ALTO server introducing these metrics should consider related security issues. As a generic security consideration regarding reliability and trust in the exposed metric values, applications SHOULD
promptly stop using ALTO-based guidance if they detect that the exposed information does not preserve their performance level or even degrades it. Section 7
discusses security considerations in more detail.