Application-Layer Traffic Optimization (ALTO) Performance Cost Metrics
Extracted elements (27)
Delay variation is defined relative to the minimum observed delay (networking convention), rather than relative to the mean (statistical convention), because in networking contexts variation is more commonly defined from samples relative to the min delay packet.
Loss rate aggregation from link-level metrics uses sum of link loss rates only when rates are low and uncorrelated. When link loss rates are high but independent, end-to-end loss is computed as one minus the product of per-link success rates. Correlated loss requires more complex handling.
The document deliberately defines performance metric identifiers with coarse-grained semantics (name, description, units, measurement points) only, and uses the optional 'cost-context' mechanism to allow servers to optionally supply fine-grained details (method of measurement, parameters). This avoids requiring ALTO servers to always provide full IPPM-style six-component specifications that may not be feasible from routing-protocol data sources.
The 'tput' metric is explicitly scoped to TCP bulk flows using congestion-control-conforming behavior (e.g., CUBIC per RFC 9438). Other transport-specific metrics (e.g., QUIC) are deferred until measurement methodology matures.
An ALTO client unaware of the 'cost-context' extension cannot distinguish between cost types with the same 'cost-mode' and 'cost-metric' but different 'cost-source' values (e.g., 'estimation' vs. 'sla'). Such clients will ignore the 'cost-context' field and treat all values as estimation.
An ALTO information resource MUST NOT announce multiple CostType entries with the same 'cost-metric', 'cost-mode', and 'cost-context'; such entries must be placed into different information resources.
For the 'tput' (TCP throughput) metric, the 'nominal' and 'sla' cost-source values SHOULD NOT be generated, as TCP throughput typically does not have meaningful nominal or SLA values.
If a 'cost-metric' is 'routingcost' and the metric contains a 'cost-context' field, then the 'cost-source' MUST be 'estimation'; if it is not, the client SHOULD reject the information as invalid.
If a cost metric string does not include the optional statistical operator, the statistical operator SHOULD be interpreted as the default defined for the base metric. If the base metric defines no default, the metric MUST be considered the median value.
If an ALTO client obtains updates through an incremental update mechanism (RFC 8895), the client SHOULD assume that the metric is computed using a snapshot at approximately the receiving time.
The ALTO server SHOULD return an HTTP Last-Modified header to indicate the freshness of data used to compute performance metrics, since the metrics themselves have no timestamp field.
The 'cost-source' field of the 'cost-context' field MUST be one that is registered in the 'ALTO Cost Source Types' registry. If a metric does not include a 'cost-source' value, the application MUST assume the value is 'estimation'.
The total length of the cost metric string (base identifier plus optional statistical operator) MUST NOT exceed 32 characters, as required by RFC 7285.
Cost metric strings may include an optional statistical operator suffix appended with a colon (':'). Valid operators are: 'cur' (current), percentile ('p' followed by a number in [0,100]), 'min', 'max', 'median', 'mean', 'stddev', 'stdvar'. The total cost metric string MUST NOT exceed 32 characters as required by RFC 7285.
The available bandwidth metric 'bw-available' is a non-negative JSONNumber in bytes per second representing the minimum available bandwidth among all links from source to destination. The default statistical operator is 'cur' (current instantaneous value).
The 'cost-context' field is an optional extension to the ALTO 'cost-type' object, containing a 'cost-source' string and optional 'parameters' value. It conveys the source of a performance metric (nominal, sla, or estimation) and cannot be used as a key to distinguish cost metrics within the same information resource.
The delay variation metric 'delay-variation' is a non-negative JSONNumber in microseconds representing jitter with respect to the minimum delay observed, defined as the temporal and spatial aggregation of per-link delay variation along the path (RFC 7471, RFC 8570, RFC 8571). The selection function F chooses the packet with the smallest one-way delay as the reference.
The hop count metric 'hopcount' is a non-negative integer JSONNumber representing the number of network hops from source to destination. The meaning of 'hop' may vary and SHOULD be clarified in the 'parameters' field of an estimation cost-context.
The loss rate metric 'lossrate' is a non-negative JSONNumber representing the percentage of packet losses from source to destination, derived from aggregation of Unidirectional Link Loss metrics (RFC 7471, RFC 8570, RFC 8571).
The one-way delay metric 'delay-ow' is a non-negative JSONNumber in microseconds representing the temporal and spatial aggregated unidirectional delay from source to destination, derived from the sum of Unidirectional Delay of links along the path (based on RFC 7471, RFC 8570, RFC 8571).
The residual bandwidth metric 'bw-residual' is a non-negative JSONNumber in bytes per second representing the minimum residual bandwidth among all links from source to destination. The default statistical operator is 'cur' (current instantaneous value).
The round-trip delay metric 'delay-rt' is a non-negative JSONNumber in microseconds, representing the sum of the one-way delay from source to destination and the one-way delay from destination back to source.
The TCP throughput metric 'tput' is a non-negative JSONNumber in bytes per second estimating the throughput of a congestion-control-conforming TCP bulk flow from source to destination, based on TCP throughput modeling (e.g., RFC 9438/CUBIC).
This document adds eight new entries to the IANA 'ALTO Cost Metrics' registry (originally created by RFC 7285): delay-ow, delay-rt, delay-variation, lossrate, hopcount, tput, bw-residual, and bw-available.
This document creates the new IANA 'ALTO Cost Source Types' registry with initial entries 'nominal', 'sla', and 'estimation'. New entries require IETF Review (RFC 8126). Registered identifiers must consist of only ASCII alphanumeric characters.
Applications SHOULD promptly stop using ALTO-based guidance if they detect that the exposed information does not preserve their performance level or degrades it, as a mitigation against inaccurate or maliciously crafted performance metrics.
Traffic engineering performance metrics are highly sensitive ISP information. ALTO servers MUST use HTTPS and TLS (RFC 8446) and SHOULD authenticate ALTO clients before transmitting resources containing sensitive TE performance metrics such as numerical delay, loss, or bandwidth values. Sharing such values requires full mutual trust between server and client operators.