RFC 9439
Application-Layer Traffic Optimization (ALTO) Performance Cost Metrics
Part 1 of 8 💖
Application-Layer Traffic Optimization (ALTO) Performance Cost Metrics 🎀
okay so this RFC is from the Internet Engineering Task Force (IETF) 🌸, and it's RFC 9439 ✨, published in August 2023 📅. It's on the Standards Track 👑, which means it's an actual Internet standard and not just a suggestion, bestie 💅. The ISSN is 2070-1721 🦋.
The lead author is Q. Wu from Huawei 🧚. Co-authors are Y. Yang from Yale University 🎓, Y. Lee from Samsung 💜, D. Dhody also from Huawei 🍓, S. Randriamasy from Nokia Networks France 🌈, and L. Contreras from Telefonica ⭐. That's a whole international squad 🫶.
Nothing in the header says it obsoletes or updates any other RFC, so it's a brand new standard, not a fix to an old one 🔥. It's the standards-track version of a new feature, not a patch 💖.
Abstract
okay so the cost metric is basically the core idea in Application-Layer Traffic Optimization (ALTO) 💅, and different apps might want different kinds of cost metrics 🌸. The ALTO base protocol (RFC 7285) only defines one cost metric, the generic routingcost 😭. So if an app wants to ask for a cost map or an endpoint cost request to find a provider with better performance (like lower delay or loss rate 👀), the base protocol just doesn't say which cost metric to use 💀.
This document fixes that gap ✨ by adding a bunch of network performance metrics 🦋. We're talking network delay, delay variation (a.k.a. jitter 🎀), packet loss rate, hop count, and bandwidth 🌈. Iconic.
There are lots of places a performance metric can come from 🧚, like estimates based on measurements or a Service Level Agreement 📊. So this doc adds an extra cost-context field next to the ALTO cost-type field 💜, so you can tell where the number came from 🔥.
Status of This Memo
okay this part is the boring legal bit, but it's important 💅. This is an Internet Standards Track document 👑.
It's an official product of the IETF 🌸, and it represents the consensus of the IETF community 🫶. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) ✨. If you want more info on Internet Standards, check out Section 2 of RFC 7841 🦋.
For the current status, any errata, or how to send feedback, go to https://www.rfc-editor.org/info/rfc9439 🎀.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved 💖.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info 🌈, as they were in effect on the publication date 📅. Please actually read these, bestie, because they explain your rights and restrictions 🙈. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 💅.
Table of Contents
1. Introduction
2. Requirements Language
3. Performance Metric Attributes
3.1. Performance Metric Context: "cost-context"
3.2. Performance Metric Statistics
4. Packet Performance Metrics
4.1. Cost Metric: One-Way Delay (delay-ow)
4.1.1. Base Identifier
4.1.2. Value Representation
4.1.3. Intended Semantics and Use
4.1.4. Cost-Context Specification Considerations
4.2. Cost Metric: Round-Trip Delay (delay-rt)
4.2.1. Base Identifier
4.2.2. Value Representation
4.2.3. Intended Semantics and Use
4.2.4. Cost-Context Specification Considerations
4.3. Cost Metric: Delay Variation (delay-variation)
4.3.1. Base Identifier
4.3.2. Value Representation
4.3.3. Intended Semantics and Use
4.3.4. Cost-Context Specification Considerations
4.4. Cost Metric: Loss Rate (lossrate)
4.4.1. Base Identifier
4.4.2. Value Representation
4.4.3. Intended Semantics and Use
4.4.4. Cost-Context Specification Considerations
4.5. Cost Metric: Hop Count (hopcount)
4.5.1. Base Identifier
4.5.2. Value Representation
4.5.3. Intended Semantics and Use
4.5.4. Cost-Context Specification Considerations
5. Throughput/Bandwidth Performance Metrics
5.1. Cost Metric: TCP Throughput (tput)
5.1.1. Base Identifier
5.1.2. Value Representation
5.1.3. Intended Semantics and Use
5.1.4. Cost-Context Specification Considerations
5.2. Cost Metric: Residual Bandwidth (bw-residual)
5.2.1. Base Identifier
5.2.2. Value Representation
5.2.3. Intended Semantics and Use
5.2.4. Cost-Context Specification Considerations
5.3. Cost Metric: Available Bandwidth (bw-available)
5.3.1. Base Identifier
5.3.2. Value Representation
5.3.3. Intended Semantics and Use
5.3.4. Cost-Context Specification Considerations
6. Operational Considerations
6.1. Source Considerations
6.2. Metric Timestamp Considerations
6.3. Backward-Compatibility Considerations
6.4. Computation Considerations
6.4.1. Configuration Parameter Considerations
6.4.2. Aggregation Computation Considerations
7. Security Considerations
8. IANA Considerations
8.1. ALTO Cost Metrics Registry
8.2. ALTO Cost Source Types Registry
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Authors' Addresses1. Introduction ✨
okay so ALTO (Application-Layer Traffic Optimization) is giving network apps a way to grab network info so they can figure out the most efficient application-layer traffic patterns 🦋 Cost metrics show up in both the ALTO cost map service and the ALTO endpoint cost service in the ALTO base protocol [RFC7285].
different apps want different things, so the ALTO base protocol introduced the "ALTO Cost Metrics" registry (Section 14.2 of [RFC7285]) as a systematic way to specify different metrics 🎀 For example, a delay-sensitive app might want latency metrics, and a bandwidth-sensitive app might want bandwidth metrics. BUT the base protocol only registered one metric, the generic "routingcost" metric (Section 14.2 of [RFC7285]). no latency or bandwidth metrics are defined in the base protocol 😭
this document registers a new set of cost metrics (Table 1) so apps can pick where to connect based on network performance criteria, including delay and bandwidth metrics 💖
+============+===============+=====================================+
| Metric | Definition in | Semantics Based On |
| | This Document | |
+============+===============+=====================================+
| One-Way | Section 4.1 | Base: [RFC7471] [RFC8570] [RFC8571] |
| Delay | | sum of Unidirectional Delay of |
| | | links along the path |
+------------+---------------+-------------------------------------+
| Round-Trip | Section 4.2 | Base: Sum of two directions of |
| Delay | | Unidirectional Delay |
+------------+---------------+-------------------------------------+
| Delay | Section 4.3 | Base: [RFC7471] [RFC8570] [RFC8571] |
| Variation | | Sum of Unidirectional Delay |
| | | Variation of links along the path |
+------------+---------------+-------------------------------------+
| Loss Rate | Section 4.4 | Base: [RFC7471] [RFC8570] [RFC8571] |
| | | aggr Unidirectional Link Loss |
+------------+---------------+-------------------------------------+
| Residual | Section 5.2 | Base: [RFC7471] [RFC8570] [RFC8571] |
| Bandwidth | | min Unidirectional Residual BW |
+------------+---------------+-------------------------------------+
| Available | Section 5.3 | Base: [RFC7471] [RFC8570] [RFC8571] |
| Bandwidth | | min Unidirectional Available BW |
+------------+---------------+-------------------------------------+
| TCP | Section 5.1 | [RFC9438] |
| Throughput | | |
+------------+---------------+-------------------------------------+
| Hop Count | Section 4.5 | [RFC7285] |
+------------+---------------+-------------------------------------+
Table 1: Cost Metrics Defined in This Documentthe first six metrics in Table 1 (one-way delay, round-trip delay, delay variation, loss rate, residual bandwidth, and available bandwidth) are built from the TE (Traffic Engineering) performance metrics that are commonly defined in OSPF [RFC3630] [RFC7471], IS-IS [RFC5305] [RFC8570], and BGP - Link State (BGP-LS) [RFC8571] ✨ Deriving ALTO cost performance metrics from existing network-layer TE performance metrics, and exposing them to ALTO, can be a typical way for network operators to deploy ALTO [RFC7971] [FlowDirector]. this document sets the base semantics of these metrics by extending them from link metrics to end-to-end metrics for ALTO 🧚 The "Semantics Based On" column says at a high level how the end-to-end metrics get computed from link metrics, and the details come in the following sections.
the Min/Max Unidirectional Link Delay metric (from [RFC8570] and [RFC8571]) and Maximum (Link) Bandwidth (from [RFC3630] and [RFC5305]) aren't in Table 1 because the statistical operators defined in this document can handle them 🍓 The utilized bandwidth and reservable bandwidth metrics (Maximum Reservable (Link) Bandwidth and Unreserved Bandwidth, as defined in [RFC3630] and [RFC5305]) are outside the scope of this document, so we're not touching them 🙅♀️
the seventh metric in Table 1, estimated TCP-flow throughput, gives an estimate of the bandwidth of a TCP flow using TCP throughput modeling, which supports adaptive apps [Prophet] [G2] 👑 other transport-specific metrics can be defined later. for example, QUIC-related metrics [RFC9000] can be considered once the methodology for measuring them is more mature (e.g., see [QUIC-THROUGHPUT-TESTING]).
the eighth metric in Table 1, hop count, is mentioned but not defined in the ALTO base protocol [RFC7285], so this document gives it a definition 🌈
these eight performance metrics fall into two categories. the first is about the performance of individual packets (one-way delay, round-trip delay, delay variation, loss rate, and hop count), and the second is about bandwidth and throughput (residual bandwidth, available bandwidth, and TCP throughput). these two categories are defined in Sections 4 and 5, respectively. heads up: all metrics except round-trip delay are unidirectional, so an ALTO client will need to query both directions if it needs them ⭐
the purpose of this doc is to make sure these eight performance metrics get used properly in ALTO 💅 It follows the guidelines in Section 14.2 of [RFC7285] for registering ALTO cost metrics, so for each metric in Table 1 it specifies the identifier, the intended semantics, and the security considerations.
the intended semantics of these metrics are pretty coarse-grained and are for guidance only, though they may work well for ALTO. a performance measurement framework like the IP Performance Metrics (IPPM) framework can give a lot more detail about a performance metric 🤓 this document introduces a mechanism called "cost-context" to add those extra details when they're available. see Section 3.
following the ALTO base protocol, this document uses JSON to specify the value type of each metric. see [RFC8259] for JSON data type specifications. [RFC7285] says cost values should be assumed to be 'JSONNumber' by default. when this document defines the value representation for each metric in Table 1, it conforms to [RFC7285] but adds generic constraints on valid JSONNumbers for each metric. for example, every new metric in Table 1 is non-negative (>= 0), and Hop Count is an integer 🔢
an ALTO server doesn't have to provide every metric in this document. for example, metrics that raise privacy concerns should not be given to unauthorized ALTO clients 🙈 so all cost metrics defined here are optional, and not every one of them needs to be exposed to a given application. when an ALTO server supports a cost metric from this document, it announces the metric in its information resource directory (IRD), as defined in Section 9.2 of [RFC7285].
an ALTO server introducing these metrics should think about related security issues 🔐 as a generic security consideration about 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 goes into security considerations in more detail 🫶
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📖✨
3. Performance Metric Attributes
the definitions of the metrics in this document are coarse-grained, based on network-layer TE performance metrics, and for guidance only 💜 A fine-grained framework, as specified in [RFC6390], requires that the fine-grained specification of a network performance metric include six components: (1) Metric Name, (2) Metric Description, (3) Method of Measurement or Calculation, (4) Units of Measurement, (5) Measurement Points, and (6) Measurement Timing. requiring an ALTO server to provide precise, fine-grained values for all six components for every metric it exposes may not be feasible or necessary for all ALTO use cases. for example, an ALTO server that computes its metrics from network-layer TE performance metrics may not have information about the method of measurement or calculation (e.g., measured traffic patterns) 🥺
to deal with this and make the ALTO use cases for the metrics in Table 1 work, this document defines performance metric identifiers that can be used in the ALTO Protocol with the following well-defined items: (1) Metric Name, (2) Metric Description, (3) Units of Measurement, and (4) Measurement Points. the measurement points are always specified by the specific ALTO services. for example, the endpoint cost service is between the two endpoints. so the ALTO performance metric identifiers provide basic metric attributes 🦋
to keep things flexible, letting an ALTO server give fine-grained info like the Method of Measurement or Calculation according to its own policy and use cases, this document introduces context information so the server can provide these extra details 🌸
3.1. Performance Metric Context: "cost-context" 🧚
okay so the core extra details of a performance metric tell you how the metric gets obtained 👀 that's called the source of the metric 💅 this doc defines three coarse-grained source types: "nominal", "sla", and "estimation" ✨
the precise meaning of a metric value can depend on specific measurement and computation parameters, so we need a way to spell out the source and those parameters 🎀 that's where the optional "cost-context" field comes in. it gets added to the "cost-type" field from the ALTO base protocol (Section 10.7 of [RFC7285]) like this:
object {
CostMetric cost-metric;
CostMode cost-mode;
[CostContext cost-context;]
[JSONString description;]
} CostType;
object {
JSONString cost-source;
[JSONValue parameters;]
} CostContext;ngl "cost-context" is NOT a key for telling performance metrics apart 🙈 so an ALTO information resource MUST NOT announce multiple CostType entries with the same "cost-metric", "cost-mode", and "cost-context". they must be placed into different information resources 🧚
the "cost-source" field is a string made of only ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A) 🌸 this doc uses "cost-source" to hold a string in that format.
and as we said, this doc gives three values for "cost-source": "nominal", "sla", and "estimation" 💖 the "cost-source" field of the "cost-context" field MUST be one that is registered in the "ALTO Cost Source Types" registry (Section 8). no freelancing the names, bestie 😤
- "nominal": the metric value is statically configured by the underlying devices 🍓 not every metric has a reasonable nominal value. throughput can have one (the configured transmission rate of the devices involved), but latency typically doesn't.
- "sla": the metric value comes from some commitment, which this doc calls a Service Level Agreement (SLA) 📜 some operators say "target" or "committed" instead. for an "sla" metric, it is RECOMMENDED that the "parameters" field provide a link to the SLA definition 🔗
- "estimation": the metric value is computed through an estimation process 🦋 an ALTO server may compute "estimation" values by pulling and/or aggregating info from routing protocols (e.g., see [RFC7471], [RFC8570], and [RFC8571]), traffic measurement management tools (e.g., the Two-Way Active Measurement Protocol (TWAMP) [RFC5357]), and measurement frameworks (e.g., IPPM). there are operational issues that come with that, and Section 6 digs into them and how a network can address them 🛠️ here's the flow of info used to estimate these metrics:
+--------+ +--------+ +--------+
| Client | | Client | | Client |
+----^---+ +---^----+ +---^----+
| | |
+-----------|-----------+
|ALTO Protocol
|
|
+--+-----+ retrieval +-----------+
| ALTO |<----------------| Routing |
| Server | and aggregation| Protocols |
| |<-------------+ | |
+--------+ | +-----------+
|
| +------------+
| |Performance |
---| Monitoring |
| Tools |
+------------+Figure 1: A Framework to Compute Estimation of Performance Metrics
there can be multiple options when choosing a "cost-source" category, and the operator of the ALTO server is the one who makes that call 👑 if a metric doesn't include a "cost-source" value, the application MUST assume that "cost-source" is the most generic source, which is "estimation" 🫶
3.2. Performance Metric Statistics 📊
measuring a performance metric often gives you a whole set of samples from an observation distribution [Prometheus], not just one number 🌈 so a statistical operator gets applied to the samples to get the value that's reported to the client. people use multiple statistical operators all the time (min, median, max, the whole squad) 💅
so this doc extends the general ASCII alphanumeric cost metric strings (formally the CostMetric type from Section 10.6 of [RFC7285]) like this 🎀 a cost metric string is a base metric identifier (base identifier for short), followed by an optional statistical operator string, joined by the ASCII colon ':' (U+003A) when that operator exists. the whole cost metric string MUST NOT go over 32 characters, as [RFC7285] requires 🙅♀️
the statistical operator string MUST be one of these:
cur: the instantaneous observation value from the most recent sample, aka the current value ⚡pfollowed by a number (percentile): gives the percentile that the number after the 'p' points to 📈 the number MUST be a non-negative JSON number in the range [0, 100] (so, greater than or equal to 0 and less than or equal to 100), and it can have an optional decimal part if you need more precision. the decimal part should start with the '.' separator (U+002E) and be followed by one or more ASCII digits between '0' and '9'. say that number is y, and the samples come from a random variable X. the metric returns x so that the probability of X being less than or equal to x, i.e.Prob(X <= x), = y/100. for example,delay-ow:p99gives the 99th percentile of observed one-way delay, anddelay-ow:p99.9gives the 99.9th. some systems use quantile, which runs over [0, 1] instead, so just a heads up 👀 and when a percentile has a more common name, it is RECOMMENDED to use that common form:mininstead ofp0,medianinstead ofp50, andmaxinstead ofp100🌟min: the minimal value of the observations 🔻max: the maximal value of the observations 🔺median: the midpoint (i.e., p50) of the observations ⚖️mean: the arithmetic mean value of the observations 🧮stddev: the standard deviation of the observations 📉stdvar: the standard variance of the observations 📉
so examples of cost metric strings are "delay-ow", "delay-ow:min", and "delay-ow:p99", where "delay-ow" is the base metric identifier string and "min" and "p99" are example statistical operator strings 🦋
if a cost metric string has no statistical operator string, the statistical operator SHOULD be read as the default statistical operator from the base metric's definition 🧠 and if the base metric's definition doesn't give a default operator, the metric MUST be considered the median value. no drama, just median 🍀
⚠️ heads up: [RFC7285] caps the whole cost metric identifier at 32 characters, and the statistical-operator variants in this doc have the same 32-character limit 😭 so some combos of long base identifiers plus operators just won't fit. if that happens, the fix is to define a new base metric identifier that's an "alias" of the one you want, with identical semantics and a shorter name ✂️
4. Packet Performance Metrics 📦
this section brings in ALTO network performance metrics for one-way delay, round-trip delay, delay variation, packet loss rate, and hop count 💖 they measure the "quality of experience" for the stream of packets going from a resource provider to a resource consumer ✨ the stuff we measure per packet (pkt) can include how long it took to go from entering the network to leaving it (pkt.delay), whether it got dropped before it reached its destination (pkt.dropped), and how many network hops it crossed (pkt.hopcount). the metrics in this section are statistics computed from those measurements. for example, the x-percentile of one-way delay is the x-percentile of the set of delays {pkt.delay} for the packets in the stream 📊
4.1. Cost Metric: One-Way Delay (delay-ow) 🕐
4.1.1. Base Identifier 🪪
the base identifier for this performance metric is "delay-ow" 💅
4.1.2. Value Representation 🔢
the metric value type is a single 'JSONNumber' value that follows the number rules in Section 6 of [RFC8259] 🎀 the unit is microseconds, so the number can be a floating-point number to express a delay smaller than a microsecond 🌸 the number MUST be non-negative. no negative delays in this house 🙅♀️✨
4.1.3. Intended Semantics and Use ✨
Okay bestie, the intended semantics are the vibe check here 💖. This metric is all about the temporal and spatial aggregated delay of a stream of packets from the specified source to the specified destination. Its base semantics is the Unidirectional Delay metric from [RFC8571], [RFC8570], and [RFC7471], but instead of the delay for one link, it's the (temporal) aggregation of the link delays from the source to the destination. A non-normative reference definition of the end-to-end one-way delay metric is in [RFC7679]. The spatial aggregation level lives in the query context, e.g., 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 🎀.
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 239
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-ow"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 247
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-ow"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 10,
"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" field, the values are based on "estimation". Since the identifier does not include the statistical operator string component, the values will represent median values 🌸.
Figure 3 shows an example that is similar to Example 1 (Figure 2), but for IPv6 💜.
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 252
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-ow"
},
"endpoints": {
"srcs": [
"ipv6:2001:db8:100::1"
],
"dsts": [
"ipv6:2001:db8:100::2",
"ipv6:2001:db8:100::3"
]
}
}
HTTP/1.1 200 OK
Content-Length: 257
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-ow"
}
},
"endpoint-cost-map": {
"ipv6:2001:db8:100::1": {
"ipv6:2001:db8:100::2": 10,
"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 🧚
"nominal": typically, network one-way delay doesn't have a nominal value, so don't expect one 🙈.
"sla": loads of networks put delay-related parameters in their application-level SLAs 💅. It is RECOMMENDED that the "parameters" field of an "sla" one-way delay metric include a link (i.e., a field named "link") providing a URI for the specification of SLA details, if available. That specification can be either (1) free text for possible presentation to the user or (2) a formal specification. The format of the specification is outside the scope of this document 📝.
"estimation": the exact estimation method is outside the scope of this document 🌈. There can be multiple sources for estimating one-way delay. For example, the ALTO server may estimate the end-to-end delay by aggregation of routing protocol link metrics. The server may also estimate the delay using active, end-to-end measurements, for example using the IPPM framework [RFC2330] ✨.
If the estimation is computed by aggregation of routing protocol link metrics (e.g., Unidirectional Link Delay metrics for OSPF [RFC7471], IS-IS [RFC8570], or BGP-LS [RFC8571]), it is RECOMMENDED that the "parameters" field of an "estimation" one-way delay metric include the following information: (1) the RFC defining the routing protocol metrics (e.g., see [RFC7471] for derived metrics), (2) configurations of the routing link metrics such as configured intervals, and (3) the aggregation method from link metrics to end-to-end metrics. During aggregation from link metrics to end-to-end metrics, the server should be cognizant of potential issues when computing an end-to-end summary statistic from link statistics. The default end-to-end average one-way delay is the sum of average link one-way delays. If an ALTO server provides the min and max statistical operators for the one-way delay metric, the values can be computed directly from the routing link metrics, as [RFC7471], [RFC8570], and [RFC8571] provide Min/Max Unidirectional Link Delay 🔥.
If the estimation is from the IPPM measurement framework, it is RECOMMENDED that the "parameters" field of an "estimation" one-way delay metric include the URI in the "URI" field of the IPPM metric defined in the IPPM "Performance Metrics" registry [IANA-IPPM] (e.g., <https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_95Percentile>). The IPPM metric MUST be one-way delay (i.e., IPPM OWDelay* metrics). The statistical operator of the ALTO metric MUST be consistent with the IPPM statistical property (e.g., 95th percentile) 👑.
4.2. Cost Metric: Round-Trip Delay (delay-rt) 🍓
4.2.1. Base Identifier
The base identifier for this performance metric is "delay-rt" 🎀.
4.2.2. Value Representation
The metric value type is a single 'JSONNumber' type value conforming to the number specifications provided in Section 6 of [RFC8259]. The number MUST be non-negative. The unit is expressed in microseconds ⏱️.
4.2.3. Intended Semantics and Use
Intended Semantics: this is the temporal and spatial aggregated round-trip delay between the specified source and specified destination 💖. The base semantics is that it's the sum of the one-way delay from the source to the destination and the one-way delay from the destination back to the source, where the one-way delay is as defined in Section 4.1. A non-normative reference definition of the end-to-end round-trip delay metric is in [RFC2681]. The spatial aggregation level is specified in the query context (e.g., PID to PID, or endpoint to endpoint).
Note that it is possible for a client to query two one-way delay (delay-ow) items and then compute the round-trip delay. The server should be cognizant of the consistency of values 🫶.
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
Host: alto.example.com
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-rt"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 245
Content-Type: application/alto-endnpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-rt"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 4,
"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
"nominal": typically, network round-trip delay doesn't have a nominal value 🙈.
"sla": see the "sla" entry in Section 4.1.4 🫶.
"estimation": see the "estimation" entry in Section 4.1.4. For estimation by aggregation of routing protocol link metrics, the aggregation should include all links from the source to the destination and then back to the source. For estimation using IPPM, the IPPM metric MUST be round-trip delay (i.e., IPPM RTDelay* metrics). The statistical operator of the ALTO metric MUST be consistent with the IPPM statistical property (e.g., 95th percentile) 🔥.
4.3. Cost Metric: Delay Variation (delay-variation) 🦋
4.3.1. Base Identifier
The base identifier for this performance metric is "delay-variation" 🌸.
4.3.2. Value Representation
The metric value type is a single 'JSONNumber' type value conforming to the number specifications provided in Section 6 of [RFC8259]. The number MUST be non-negative. The unit is expressed in microseconds ⏱️.
4.3.3. Intended Semantics and Use
Intended Semantics: this is the temporal and spatial aggregated delay variation (also called delay jitter) with respect to the minimum delay observed on the stream over the one-way delay from the specified source and destination, where the one-way delay is as defined in Section 4.1 ✨. A non-normative reference definition of the end-to-end one-way delay variation metric is in [RFC3393]. Note that [RFC3393] allows the specification of a generic selection function F to unambiguously define the two packets selected to compute delay variations. This document defines the specific case where F selects the packet with the smallest one-way delay as the "first" packet. The spatial aggregation level is specified in the query context (e.g., PID to PID, or endpoint to endpoint).
Note that in statistics, variation is typically evaluated by the 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 🤓.
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
Host: alto.example.com
Content-Length: 245
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-variation"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 252
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "delay-variation"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 0,
"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 ✨
"nominal": Bestie, network delay variation typically doesn't have a nominal value 🙈
"sla": Check the "sla" entry in Section 4.1.4 💅
"estimation": Check the "estimation" entry in Section 4.1.4 too 🫶. For estimation by aggregating routing protocol link metrics, the default aggregation of the average delay variations is the sum of the link delay variations. For estimation using IPPM, the IPPM metric MUST be delay variation (i.e., IPPM OWPDV* metrics). The statistical operator of the ALTO metric MUST be consistent with the IPPM statistical property (e.g., 95th percentile). It's giving precision 🔥
4.4. Cost Metric: Loss Rate (lossrate) 💜
4.4.1. Base Identifier
The base identifier for this performance metric is "lossrate" 🍓
4.4.2. Value Representation
The metric value type is a single 'JSONNumber' type value that follows the number specifications in Section 6 of [RFC8259] ✨. The number MUST be non-negative. The value represents the percentage of packet losses, so think of it as the loss rate in percent 📉.
4.4.3. Intended Semantics and Use
Intended Semantics: This gives the temporal and spatial aggregated one-way packet loss rate from the specified source to the specified destination 🦋. The base semantics come from the Unidirectional Link Loss metric in [RFC8571], [RFC8570], and [RFC7471]. The difference is that instead of the loss for one link, you get the aggregated loss across all the links from source to destination. The spatial aggregation level is set in 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 🎀.
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "lossrate"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 248
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "lossrate"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 0,
"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
"nominal": The packet loss rate typically doesn't have a nominal value, although some networks may specify zero losses 🌸.
"sla": Check the "sla" entry in Section 4.1.4 💖.
"estimation": Check the "estimation" entry in Section 4.1.4 as well 🧚. For estimation by aggregating routing protocol link metrics, the default aggregation of the average loss rate is the sum of the link loss rates. But that default only works if two conditions are met: (1) the link loss rates are low, and (2) each link's loss events are assumed to be uncorrelated with every other link's loss events. When link loss rates are high but independent, the general formula assumes each link is independent and computes the end-to-end loss as one minus the product of each link's success rate. Aggregation when link losses are correlated can get more complex, and the ALTO server should be cognizant of correlated loss rates 👀. For estimation using IPPM, the IPPM metric MUST be packet loss (i.e., IPPM OWLoss* metrics). The statistical operator of the ALTO metric MUST be consistent with the IPPM statistical property (e.g., 95th percentile) 💅.
4.5. Cost Metric: Hop Count (hopcount) 🌈
The hop count (hopcount) metric is mentioned as an example in Section 9.2.3 of [RFC7285]. This section goes further into its properties 🔍.
4.5.1. Base Identifier
The base identifier for this performance metric is "hopcount" 🦋.
4.5.2. Value Representation
The metric value type is a single 'JSONNumber' type value that follows the number specifications in Section 6 of [RFC8259]. The number MUST be a non-negative integer (greater than or equal to 0). The value represents the number of hops ✨.
4.5.3. Intended Semantics and Use
Intended Semantics: This specifies the number of hops in the path from the specified source to the specified destination. Hop count is a basic measure of distance in a network and can be exposed as the number of router hops computed from the routing protocols that originate this information. A hop can also represent other units, though 🤷♀️. The spatial aggregation level is set in 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 🎀.
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "hopcount"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 245
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "hopcount"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 5,
"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
"nominal": Hop count typically doesn't have a nominal value 🙃.
"sla": Hop count typically doesn't have an SLA value either 💀.
"estimation": The exact estimation method is outside the scope of this document 🫠. One example of estimating hop count values is importing them from IGP routing protocols. It is RECOMMENDED that the "parameters" field of an "estimation" hop count define the meaning of a hop 📝.
5. Throughput/Bandwidth Performance Metrics 🚀
This section introduces three metrics related to throughput and bandwidth 💜. Given a specified source and a specified destination, these metrics reflect how much traffic the network can carry from the source to the destination.
5.1. Cost Metric: TCP Throughput (tput) 🌊
5.1.1. Base Identifier
The base identifier for this performance metric is "tput" 🍓.
5.1.2. Value Representation
The metric value type is a single 'JSONNumber' type value that follows the number specifications in Section 6 of [RFC8259]. The number MUST be non-negative. The unit is bytes per second 📊.
5.1.3. Intended Semantics and Use
Intended Semantics: This gives the throughput of a congestion-control-conforming TCP flow from the specified source to the specified destination. The throughput SHOULD be interpreted as only an 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 🎀.
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 234
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "tput"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 251
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "tput"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 256000,
"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
"nominal": TCP throughput typically doesn't have a nominal value and SHOULD NOT be generated 🙅♀️.
"sla": TCP throughput typically doesn't have an SLA value and SHOULD NOT be generated either 🙅♀️.
"estimation": The exact estimation method is outside the scope of this document 💅. It is RECOMMENDED that the "parameters" field of an "estimation" TCP throughput metric include the following information: (1) the congestion control algorithm and (2) the estimation methodology.
For (1), it is RECOMMENDED that the "parameters" field (object) include a field named "congestion-control-algorithm", which provides a URI for the specification of the algorithm. For example, if an ALTO server estimates the throughput of a CUBIC congestion control flow, its "parameters" field includes the "congestion-control-algorithm" field, with the value set to the URI for [RFC9438]. For an ongoing congestion control algorithm such as BBR, a link to its specification can be added 🔗.
For (2), the "parameters" field includes as many details as possible. For example, for the TCP Cubic throughput estimation, the "parameters" field specifies that the throughput is estimated by setting _C_ to 0.4, and that the equation in [RFC9438], Section 5.1, Figure 8 is applied. As an alternative, the methodology may be based on the NUM model [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.1. Base Identifier
The base identifier for this performance metric is "bw-residual" 🦋.
5.2.2. Value Representation
The metric value type is a single 'JSONNumber' type value that is non-negative. The unit of measurement is bytes per second 🫧.
5.2.3. Intended Semantics and Use ✨
Intended Semantics: Okay bestie, this one is all about residual bandwidth 💖. It pins down the temporal and spatial residual bandwidth going from the specified source to the specified destination 🦋. The base semantics come from the Unidirectional Residual Bandwidth metric in [RFC8571], [RFC8570], and [RFC7471], but instead of being about one link, it's about the whole path from source to destination 🛤️. So it's the minimal residual bandwidth among all links on that path, aka the bottleneck (iykyk 💀). When the max statistical operator is defined for the metric, it typically gives you the minimum of the link capacities along the path, since the default residual bandwidth of a link is just its link capacity [RFC8571] [RFC8570] [RFC7471] 🔥. The spatial aggregation unit gets set in the query context, like PID to PID or endpoint to endpoint 🌈.
The default statistical operator for residual bandwidth is the current instantaneous sample. So the default is assumed to be "cur" ✨.
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
Host: alto.example.com
Content-Length: 241
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "bw-residual"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 255
Content-Type: application/alto-endpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "bw-residual"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 0,
"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 🌸
"nominal": Typically, residual bandwidth does not have a nominal value. 🎀"sla": Typically, residual bandwidth does not have an SLA value. 💜"estimation": See the"estimation"entry in Section 4.1.4. The current ("cur") residual bandwidth of a path is the minimal residual bandwidth of all links on the path. 🦋
5.3. Cost Metric: Available Bandwidth (bw-available) 🌈
5.3.1. Base Identifier
The base identifier for this performance metric is "bw-available" 🧚.
5.3.2. Value Representation
The metric value type is a single JSONNumber type value that is non-negative. The unit of measurement is bytes per second 📏.
5.3.3. Intended Semantics and Use ✨
Intended Semantics: This metric is giving temporal and spatial available bandwidth from the specified source to the specified destination 💅. The base semantics come from the Unidirectional Available Bandwidth metric in [RFC8571], [RFC8570], and [RFC7471]. But instead of being about one link, it's about the path from source to destination, so it's the minimal available bandwidth among all links from the source to the destination 🛤️. The spatial aggregation unit gets specified in the query context, like PID to PID or endpoint to endpoint 🌸.
The default statistical operator for available bandwidth is the current instantaneous sample. So the default is assumed to be "cur" ✨.
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
Host: alto.example.com
Content-Length: 244
Content-Type: application/alto-endpointcostparams+json
Accept:
application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "bw-available"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.2"
],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34"
]
}
}
HTTP/1.1 200 OK
Content-Length: 255
Content-Type: application/alto-endnpointcost+json
{
"meta": {
"cost-type": {
"cost-mode": "numerical",
"cost-metric": "bw-available"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": 0,
"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 🦋
"nominal": Typically, available bandwidth does not have a nominal value. 🎀"sla": Typically, available bandwidth does not have an SLA value. 💜"estimation": See the"estimation"entry in Section 4.1.4. The current ("cur") available bandwidth of a path is the minimum of the available bandwidth of all links on the path. 🌈
6. Operational Considerations 🎀
The exact measurement infrastructure, measurement conditions, and computation algorithms can vary between different networks and are outside the scope of this document 🌍. Both the ALTO server and the ALTO clients, however, need to be cognizant of the operational issues discussed in the following subsections 🧠.
Also, the performance metrics specified in this document are similar in that they may use similar data sources and have similar issues in their calculation. Hence, this document specifies issues that the performance metrics might have in common, and it also discusses challenges regarding the computation of ALTO performance metrics (Section 6.4) 💅.
6.1. Source Considerations 🔍
The addition of the cost-source field solves a key issue: an ALTO server needs data sources to compute the cost metrics described in this document, and an ALTO client needs to know the data sources to better interpret the values 🫶.
To avoid information that is too fine grained, this document introduces cost-source to indicate only the high-level types of data sources: "estimation", "nominal", or "sla". Here, "estimation" is a type of measurement data source, "nominal" is a type of static configuration, and "sla" is a type that is based more on policy 📊.
For example, for "estimation", the ALTO server may use log servers or the Operations, Administration, and Maintenance (OAM) system as its data source, as recommended by [RFC7971]. In particular, the cost metrics defined in this document can be computed using routing systems as the data sources 🛰️.
6.2. Metric Timestamp Considerations ⏰
Despite the introduction of the additional cost-context information, the metrics do not have a field to indicate the timestamps of the data used to compute the metrics. To indicate this attribute, the ALTO server SHOULD return an HTTP Last-Modified value to indicate the freshness of the data used to compute the performance metrics 🍓.
If the ALTO client obtains updates through an incremental update mechanism [RFC8895], the client SHOULD assume that the metric is computed using a snapshot at the time that is approximated by the receiving time 🌷.
6.3. Backward-Compatibility Considerations 🙈
One potential issue introduced by the optional cost-source field is backward compatibility. Consider the case where an IRD defines two cost-type entries with the same cost-mode and cost-metric, but one with cost-source being "estimation" and the other being "sla". In such a case, an ALTO client that is not aware of the extension will not be able to distinguish between these two types 😭. A similar issue can arise even with a single cost-type whose cost-source is "sla": an ALTO client that is not aware of this extension will ignore this field and instead consider the metric estimation 💀.
To address the backward-compatibility issue, if a cost-metric is routingcost and the metric contains a cost-context field, then it MUST be "estimation". If it is not, the client SHOULD reject the information as invalid 🚫.
6.4. Computation Considerations 🧮
The metric values exposed by an ALTO server may result from additional processing of measurements from data sources to compute exposed metrics. This may involve data processing tasks such as aggregating the results across multiple systems, removing outliers, and creating additional statistics. The computation of ALTO performance metrics can present two challenges 👑.
6.4.1. Configuration Parameter Considerations ⚙️
Performance metrics often depend on configuration parameters, and exposing such configuration parameters can help an ALTO client to better understand the exposed metrics. In particular, an ALTO server may be configured to compute a TE metric (e.g., packet loss rate) at fixed intervals, say every T seconds. To expose this information, the ALTO server may provide the client with two pieces of additional information: (1) when the metrics were last computed and (2) when the metrics will be updated (i.e., the validity period of the exposed metric values). The ALTO server can expose these two pieces of information by using the HTTP response headers Last-Modified and Expires 🎀.
6.4.2. Aggregation Computation Considerations 🧩
An ALTO server may not be able to measure the performance metrics to be exposed. The basic issue is that the "source" information can often be link-level information. For example, routing protocols often measure and report only per-link loss and not end-to-end loss. Similarly, routing protocols report link-level available bandwidth and not end-to-end available bandwidth 😤. The ALTO server then needs to aggregate these data to provide an abstract and unified view that can be more useful to applications. The server should be aware that different metrics may use different aggregation computations. For example, the end-to-end latency of a path is the sum of the latencies of the links on the path. The end-to-end available bandwidth of a path is the minimum of the available bandwidth of the links on the path. In contrast, aggregating loss values is complicated by the potential for correlated loss events on different links in the path 🌊.
7. Security Considerations 🔐
okay bestie, this section is lowkey short but it's SO important. 🫶 The properties in this doc don't add any security considerations beyond what's already in Section 15 of the base ALTO specification [RFC7285]. 💅
BUT the stuff in Sections 15.1, 15.2, and 15.3 of [RFC7285] is still of utmost importance, no cap. 😭 TE performance is super sensitive ISP info, so sharing TE metric values in numerical mode needs full mutual confidence between the people running the ALTO server and the people running the ALTO client. 🔥 ALTO servers will most likely hand out numerical TE performance only under strict and formal mutual trust agreements. 🤝 And ALTO clients need to be cognizant of the risks of any such info they got outside those formal, mutually trusted conditions. 👀
Now for the transport part, which is giving main character energy. 🎀 To keep TE performance metrics confidential while they're in transit, the operator should address the risk of ALTO information leaking to malicious clients or third parties through attacks like person-in-the-middle (PITM) attacks. 🙈 As Section 15.3.2 ("Protection Strategies") of [RFC7285] lays out, the ALTO server should authenticate ALTO clients when it sends out an ALTO information resource that contains sensitive TE performance metrics. 🛡️ And Section 8.3.5 ("Authentication and Encryption") of [RFC7285] says that ALTO server implementations AND ALTO client implementations MUST support the "https" URI scheme [RFC9110] and Transport Layer Security (TLS) [RFC8446]. 🔒✨
8. IANA Considerations 🌸
8.1. ALTO Cost Metrics Registry 🎀
okay so IANA created and still maintains the "ALTO Cost Metrics" registry, which is listed in [RFC7285], Section 14.2, Table 3. 📋 You can find it at <https://www.iana.org/assignments/alto-protocol/>. IANA has added the following entries to that registry, and they're all giving RFC 9439 vibes. 🦋
+=================+====================+===========+
| 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 |
+-----------------+--------------------+-----------+
Table 2: ALTO Cost Metrics Registry8.2. ALTO Cost Source Types Registry 🧚
IANA has created the "ALTO Cost Source Types" registry, and it does two jobs. 💖 First, it makes sure every identifier for an ALTO cost source type is unique. Second, it points to the particular semantics of each allocated cost source type, so ALTO servers AND the applications using ALTO clients can apply them. ✨
A new ALTO cost source type can be added after IETF Review [RFC8126], which makes sure the new type comes with proper documentation and a proper security considerations write-up. 📚 The RFC(s) documenting a new cost source type should be detailed enough to guide both ALTO service providers and applications using ALTO clients on how to interpret values of the registered type. 🧠 Updates and deletions of ALTO cost source types follow that same procedure. 🔄
Registered ALTO address type identifiers MUST conform to the syntactical requirements in Section 3.1. Identifiers are to be recorded and displayed as strings. 🫶
Requests to add a new value to the registry MUST include the following information:
- Identifier: The name of the desired ALTO cost source type.
- Intended Semantics: ALTO cost source types carry semantics that guide how ALTO clients use them. So a document defining a new type should guide both ALTO service providers and applications using ALTO clients on how to interpret values of the registered ALTO endpoint property. 🎯
- Security Considerations: ALTO cost source types expose information to ALTO clients. ALTO service providers should be made aware of the security ramifications of exposing a cost source type. 🚨
IANA has registered the identifiers "nominal", "sla", and "estimation", as listed in the table below. 💅
+============+=========================+================+===========+
| Identifier | Intended | Security | Reference |
| | Semantics | Considerations | |
+============+=========================+================+===========+
| nominal | Values in nominal | Section 7 | RFC 9439 |
| | cases | | |
| | (Section 3.1) | | |
+------------+-------------------------+----------------+-----------+
| sla | Values reflecting | Section 7 | RFC 9439 |
| | Service Level | | |
| | Agreement | | |
| | (Section 3.1) | | |
+------------+-------------------------+----------------+-----------+
| estimation | Values by | Section 7 | RFC 9439 |
| | estimation | | |
| | (Section 3.1) | | |
+------------+-------------------------+----------------+-----------+
Table 3: ALTO Cost Source Types Registry9. References 📖
9.1. Normative References 🌈
these are the normative refs, so don't skip them, babe. 🙈
[IANA-IPPM]
IANA, "Performance Metrics",
<https://www.iana.org/assignments/performance-metrics/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390,
DOI 10.17487/RFC6390, October 2011,
<https://www.rfc-editor.org/info/rfc6390>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
IGP Traffic Engineering Performance Metric Extensions",
RFC 8571, DOI 10.17487/RFC8571, March 2019,
<https://www.rfc-editor.org/info/rfc8571>.
[RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic
Optimization (ALTO) Incremental Updates Using Server-Sent
Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November
2020, <https://www.rfc-editor.org/info/rfc8895>.
[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]: Pujol, E., Poese, I., Zerwas, J., Smaragdakis, G., and A. Feldmann, "Steering Hyper-Giants' Traffic at Scale", ACM CoNEXT '19, December 2019.
[G2]: Ros-Giralt, J., Bohara, A., Yellamraju, S., Harper Langston, M., Lethin, R., Jiang, Y., Tassiulas, L., Li, J., Tan, Y., and M. Veeraraghavan, "On the Bottleneck Structure of Congestion-Controlled Networks", Proceedings of the ACM on Measurement and Analysis of Computing 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]: Volz, J. and B. Rabenstein, "Prometheus: A Next-Generation Monitoring System (Talk)", SREcon15 Europe, May 2015. 🎤
[Prophet]: Zhang, J., Gao, K., Yang, YR., and J. Bi, "Prophet: Toward Fast, Error-Tolerant Model-Based Throughput Prediction for 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, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>. 💜
[RFC2681]: Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>. 🍓
[RFC3393]: Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393, November 2002, <https://www.rfc-editor.org/info/rfc3393>. 🧚
[RFC5357]: Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>. ⭐
[RFC7679]: Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-editor.org/info/rfc7679>. 🌈
[RFC7971]: Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and S. Previdi, "Application-Layer Traffic Optimization (ALTO) Deployment Considerations", RFC 7971, DOI 10.17487/RFC7971, October 2016, <https://www.rfc-editor.org/info/rfc7971>. 🫶
[RFC9000]: Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>. 👑
Acknowledgments ✨
Okay, the authors really want to shout out Martin Duke for the highly informative, thorough AD reviews and comments 💖. Huge thanks to 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 🫶. And a big group hug to Benjamin Kaduk, Erik Kline, Francesca Palombini, Lars Eggert, Martin Vigoureux, Murray Kucherawy, Roman Danyliw, Zaheduzzaman Sarker, and Éric Vyncke for the discussions and comments that made this document so much better 🔥💅.
Authors' Addresses ✨
Qin Wu
Huawei
Yuhua District
101 Software Avenue
Nanjing
Jiangsu, 210012
China
Email: bill.wu@huawei.com
Y. Richard Yang
Yale University
51 Prospect St.
New Haven, CT 06520
United States of America
Email: yry@cs.yale.edu
Young Lee
Samsung
Email: younglee.tx@gmail.com
Dhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.com
Sabine Randriamasy
Nokia Networks France
France
Email: sabine.randriamasy@nokia-bell-labs.com
Luis Miguel Contreras Murillo
Telefonica
Madrid
Spain
Email: luismiguel.contrerasmurillo@telefonica.com📦 where this page comes from
- ietf: rfc9439 2023-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms