rfc9439xml2.original.xml   rfc9439.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com) <!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) --> by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="std" docName="draft-ietf-alto-performance-metrics-28"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-alto-perform
ance-metrics-28" number="9439" ipr="trust200902" obsoletes="" updates="" submiss
<?rfc symrefs="yes" ?> ionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" s
ymRefs="true" sortRefs="true" version="3">
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?> <!-- xml2rfc v2v3 conversion 3.12.2 -->
<front> <front>
<title abbrev="ALTO Performance Cost Metrics">ALTO Performance Cost <title abbrev="ALTO Performance Cost Metrics">Application-Layer Traffic Opti mization (ALTO) Performance Cost
Metrics</title> Metrics</title>
<seriesInfo name="RFC" value="9439"/>
<author fullname="Qin Wu" initials="Q." surname="Wu"> <author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street>101 Software Avenue, Yuhua District</street> <extaddr>Yuhua District</extaddr>
<street>101 Software Avenue</street>
<city>Nanjing</city> <city>Nanjing</city>
<region>Jiangsu</region> <region>Jiangsu</region>
<code>210012</code> <code>210012</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>bill.wu@huawei.com</email> <email>bill.wu@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Y. Richard Yang" initials="Y." surname="Yang"> <author fullname="Y. Richard Yang" initials="Y." surname="Yang">
<organization>Yale University</organization> <organization>Yale University</organization>
<address> <address>
<postal> <postal>
<street>51 Prospect St</street> <street>51 Prospect St.</street>
<city>New Haven</city> <city>New Haven</city>
<region>CT</region> <region>CT</region>
<code>06520</code> <code>06520</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>yry@cs.yale.edu</email> <email>yry@cs.yale.edu</email>
</address> </address>
</author> </author>
<author fullname="Young Lee" initials="Y." surname="Lee"> <author fullname="Young Lee" initials="Y." surname="Lee">
<organization>Samsung</organization> <organization>Samsung</organization>
<address> <address>
<email>young.lee@gmail.com</email> <email>younglee.tx@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Dhruv Dhody" initials="D." surname="Dhody"> <author fullname="Dhruv Dhody" initials="D." surname="Dhody">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>dhruv.ietf@gmail.com</email> <email>dhruv.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Sabine Randriamasy" initials="S." surname="Randriamasy"> <author fullname="Sabine Randriamasy" initials="S." surname="Randriamasy">
<organization>Nokia Bell Labs</organization> <organization>Nokia Networks France</organization>
<address> <address>
<postal> <postal>
<street>Route de Villejust</street>
<city>Nozay</city>
<region></region>
<code>91460</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>sabine.randriamasy@nokia-bell-labs.com</email> <email>sabine.randriamasy@nokia-bell-labs.com</email>
</address> </address>
</author> </author>
<author fullname="Luis Miguel Contreras Murillo" initials="L." surname="Cont
<author fullname="Luis Miguel Contreras Murillo" initials="L." reras">
surname="Contreras">
<organization>Telefonica</organization> <organization>Telefonica</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Madrid</city> <city>Madrid</city>
<region/>
<region></region> <code/>
<code></code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>luismiguel.contrerasmurillo@telefonica.com</email> <email>luismiguel.contrerasmurillo@telefonica.com</email>
</address> </address>
</author> </author>
<date year="2023" month="August" />
<date year="2022" /> <area>tsv</area>
<workgroup>alto</workgroup>
<area>TSV Area</area> <keyword>JavaScript Object Notation</keyword>
<keyword>Application-Layer Traffic Optimization</keyword>
<workgroup>ALTO Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>JavaScript Object Notation, Application-Layer Traffic
Optimization</keyword>
<abstract> <abstract>
<t>The cost metric is a basic concept in Application-Layer Traffic <t>The cost metric is a basic concept in Application-Layer Traffic
Optimization (ALTO), and different applications may use different types Optimization (ALTO), and different applications may use different types
of cost metrics. Since the ALTO base protocol (RFC 7285) defines only a of cost metrics. Since the ALTO base protocol (RFC 7285) defines only a
single cost metric (namely, the generic "routingcost" metric), if an single cost metric (namely, the generic "routingcost" metric), if an
application wants to issue a cost map or an endpoint cost request in application wants to issue a cost map or an endpoint cost request in
order to identify a resource provider that offers better performance order to identify a resource provider that offers better performance
metrics (e.g., lower delay or loss rate), the base protocol does not metrics (e.g., lower delay or loss rate), the base protocol does not
define the cost metric to be used.</t> define the cost metric to be used.</t>
<t>This document addresses this issue by extending the specification to <t>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, and delay, delay variation (a.k.a.&nbsp;jitter), packet loss rate, hop count, and
bandwidth.</t> bandwidth.</t>
<t>There are multiple sources (e.g., estimations based on measurements or
<t>There are multiple sources (e.g., estimation based on measurements or a Service Level Agreement) available for deriving a performance metric. Th
service-level agreement) to derive a performance metric. This document is document
introduces an additional "cost-context" field to the ALTO "cost-type" introduces an additional "cost-context" field to the ALTO "cost-type"
field to convey the source of a performance metric.</t> field to convey the source of a performance metric.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="secintro" title="Introduction"> <section anchor="secintro" numbered="true" toc="default">
<name>Introduction</name>
<t>Application-Layer Traffic Optimization (ALTO) provides a means for <t>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 patterns applications can identify efficient application-layer traffic patterns
using the networks. Cost metrics are used in both the ALTO cost map 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 service and the ALTO endpoint cost service in the ALTO base protocol
<xref target="RFC7285"></xref>.</t> <xref target="RFC7285" format="default"/>.</t>
<t>Since different applications may use different cost metrics, the ALTO <t>Since different applications may use different cost metrics, the ALTO
base protocol introduces an ALTO Cost Metric Registry (Section 14.2 of base protocol introduced the "ALTO Cost Metrics" registry (<xref target="R
<xref target="RFC7285"></xref>) as a systematic mechanism to allow FC7285" section="14.2" sectionFormat="of"/>) as a systematic mechanism to allow
different metrics to be specified. For example, a delay-sensitive different metrics to be specified. For example, a delay-sensitive
application may want to use latency related metrics, and a application may want to use latency-related metrics, and a
bandwidth-sensitive application may want to use bandwidth related bandwidth-sensitive application may want to use bandwidth-related
metrics. However, the ALTO base protocol has registered only a single metrics. However, the ALTO base protocol has registered only a single
cost metric, i.e., the generic "routingcost" metric (Section 14.2 of cost metric, i.e., the generic "routingcost" metric (<xref target="RFC7285
<xref target="RFC7285"></xref>); no latency or bandwidth related metrics " section="14.2" sectionFormat="of"/>); no latency- or bandwidth-related metrics
are defined in the base protocol.</t> are defined in the base protocol.</t>
<t>This document registers a set of new cost metrics (<xref target="costme
tric" sectionFormat="bare"/>) to allow
applications to determine where to connect based on network
performance criteria, including delay- and bandwidth-related metrics.</t>
<t>This document registers a set of new cost metrics (Table 1) to allow <table anchor="costmetric">
applications to determine "where" to connect based on network <name>Cost Metrics Defined in This Document</name>
performance criteria including delay and bandwidth related metrics.</t> <thead>
<tr>
<figure> <th>Metric</th>
<artwork><![CDATA[ <th>Definition in This Document</th>
+--------------------+-------------+--------------------------------+ <th>Semantics Based On</th>
| Metric | Definition | Semantics Based On | </tr>
| | in this doc | | </thead>
+--------------------+-------------+--------------------------------+ <tbody>
| One-way Delay | Section 4.1 | Base: [RFC7471,8570,8571] | <tr>
| | | sum Unidirectional Delay | <td>One-Way Delay</td>
| Round-trip Delay | Section 4.2 | Base: Sum of two directions | <td><xref target="oneway" sectionFormat="bare"/></td>
| | | from above | <td>Base: <xref target="RFC7471"/> <xref target="RFC8570"/> <xref target="RFC8
| Delay Variation | Section 4.3 | Base: [RFC7471,8570,8571] | 571"/>
| | | sum of Unidirectional Delay | sum of Unidirectional Delay of links along the path</td>
| | | Variation | </tr>
| Loss Rate | Section 4.4 | Base: [RFC7471,8570,8571] | <tr>
| | | aggr Unidirectional Link Loss | <td>Round-Trip Delay</td>
| Residual Bandwidth | Section 5.2 | Base: [RFC7471,8570,8571] | <td><xref target="delayrt" sectionFormat="bare"/></td>
| | | min Unidirectional Residual BW| <td>Base: Sum of two directions of Unidirectional Delay</td>
| Available Bandwidth| Section 5.3 | Base: [RFC7471,8570,8571] | </tr>
| | | min Unidirectional Avail. BW | <tr>
| | | | <td>Delay Variation</td>
| TCP Throughput | Section 5.1 | [I-D.ietf-tcpm-rfc8312bis] | <td><xref target="delayvar" sectionFormat="bare"/></td>
| | | | <td>Base: <xref target="RFC7471"/> <xref target="RFC8570"/> <xref target="RFC8
| Hop Count | Section 4.5 | [RFC7285] | 571"/>
+--------------------+-------------+--------------------------------+ Sum of Unidirectional Delay Variation of links along the path</td>
Table 1. Cost Metrics Defined in this Document. </tr>
]]></artwork> <tr>
</figure> <td>Loss Rate</td>
<td><xref target="lossrate" sectionFormat="bare"/></td>
<t>The first 6 metrics listed in Table 1 (i.e., One-way Delay, <td>Base: <xref target="RFC7471"/> <xref target="RFC8570"/> <xref target="RFC8
Round-trip Delay, Delay Variation, Loss Rate, Residual Bandwidth, and 571"/>
Available Bandwidth) are derived from the set of traffic engineering aggr Unidirectional Link Loss</td>
performance metrics commonly defined in OSPF <xref </tr>
target="RFC3630"></xref>, <xref target="RFC7471"></xref>; IS-IS <xref <tr>
target="RFC5305"></xref>, <xref target="RFC8570"></xref>; and BGP-LS <td>Residual Bandwidth</td>
<xref target="RFC8571"></xref>. Deriving ALTO cost performance metrics <td><xref target="bwresidual" sectionFormat="bare"/></td>
from existing network-layer traffic engineering performance metrics, to <td>Base: <xref target="RFC7471"/> <xref target="RFC8570"/> <xref target="RFC8
expose to application-layer traffic optimization, can be a typical 571"/>
mechanism by network operators to deploy ALTO <xref min Unidirectional Residual BW</td>
target="RFC7971"></xref>, <xref target="FlowDirector"></xref>. This </tr>
<tr>
<td>Available Bandwidth</td>
<td><xref target="bwavailable" sectionFormat="bare"/></td>
<td>Base: <xref target="RFC7471"/> <xref target="RFC8570"/> <xref target="RFC8
571"/>
min Unidirectional Available BW</td>
</tr>
<tr>
<td>TCP Throughput</td>
<td><xref target="tput" sectionFormat="bare"/></td>
<td><xref target="RFC9438"/></td>
</tr>
<tr>
<td>Hop Count</td>
<td><xref target="hopcount" sectionFormat="bare"/></td>
<td><xref target="RFC7285"/></td>
</tr>
</tbody>
</table>
<t>The first six metrics listed in <xref target="costmetric" sectionFormat
="bare"/> (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 <xref target="RFC3630" format
="default"/> <xref target="RFC7471" format="default"/>, IS-IS <xref target="RFC5
305" format="default"/> <xref target="RFC8570" format="default"/>, and BGP - Lin
k State (BGP-LS)
<xref target="RFC8571" format="default"/>. 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 <xref target="RFC7971"
format="default"/> <xref target="FlowDirector" format="default"/>. This
document defines the base semantics of these metrics by extending them document defines the base semantics of these metrics by extending them
from link metrics to end-to-end metrics for ALTO. The "Semantics Based 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 On" column specifies at a high level how the end-to-end metrics are
computed from link metrics; the details will be specified in the computed from link metrics; details will be specified in the
following sections.</t> following sections.</t>
<t>The Min/Max Unidirectional Link Delay metric as defined in
<t>The common metrics Min/Max Unidirectional Delay defined in <xref target="RFC8570"/> and <xref target="RFC8571"/>, and Maximum (Link)
[RFC8570][RFC8571] and Max Link Bandwidth defined in [RFC3630,RFC5305] Bandwidth as defined in <xref target="RFC3630"/> and <xref target="RFC5305"/>,
are not listed in Table 1 because they can be handled by applying the are not listed in <xref target="costmetric" sectionFormat="bare"/> because
statistical operators defined in this document. The metrics related with they can be handled by applying the
utilized bandwidth and reservable bandwidth (i.e., Max Reservable BW and statistical operators defined in this document. The metrics related to
Unreserved BW defined in [RFC3630,RFC5305]) are outside the scope of utilized bandwidth and reservable bandwidth (i.e., Maximum Reservable (Lin
k) Bandwidth and Unreserved Bandwidth as defined in <xref target="RFC3630"/> and
<xref target="RFC5305"/>) are outside the scope of
this document.</t> this document.</t>
<t>The seventh metric in <xref target="costmetric"
<t>The 7th metric (the estimated TCP-flow throughput metric) provides an sectionFormat="bare"/> (the estimated TCP-flow throughput metric) provides an
estimation of the bandwidth of a TCP flow, using TCP throughput estimation of the bandwidth of a TCP flow, using TCP throughput
modeling, to support use cases of adaptive applications <xref modeling, to support use cases of adaptive applications <xref target="Prop
target="Prophet"></xref>, <xref target="G2"></xref>. Note that other het" format="default"/> <xref target="G2" format="default"/>. Note that other
transport-specific metrics can be defined in the future. For example, transport-specific metrics can be defined in the future. For example,
QUIC-related metrics <xref target="RFC9000"></xref> can be considered QUIC-related metrics <xref target="RFC9000" format="default"/> can be cons
when the methodology to measure such metrics is more mature (e.g., <xref idered
target="I-D.corre-quic-throughput-testing"></xref>).</t> when the methodology for measuring such metrics is more mature (e.g., see
<xref target="I-D.corre-quic-throughput-testing" format="default"/>).</t>
<t>The 8th metric (the hop count metric) in Table 1 is mentioned in the <t>The eighth metric in <xref target="costmetric"
ALTO base protocol [RFC7285], but not defined, and this document defines sectionFormat="bare"/> (the hop count metric) is mentioned, but not defined, in
it to be complete.</t> the
ALTO base protocol <xref target="RFC7285"/>; this document provides a defi
<t>These 8 performance metrics can be classified into two categories: nition for it.</t>
those derived from the performance of individual packets (i.e., One-way <t>These eight performance metrics can be classified into two categories:
Delay, Round-trip Delay, Delay Variation, Loss Rate, and Hop Count), and those derived from the performance of individual packets (i.e., one-way
those related to bandwidth/throughput (Residual bandwidth, and Available delay, round-trip delay, delay variation, loss rate, and hop count) and
Bandwidth, and TCP throughput). These two categories are defined in those related to bandwidth/throughput (residual bandwidth, available
Sections <xref format="counter" target="secpktmetrics"></xref> and <xref bandwidth, and TCP throughput). These two categories are defined in
format="counter" target="secbwmetrics"></xref> respectively. Note that Sections&nbsp;<xref format="counter" target="secpktmetrics"/> and <xref fo
all metrics except Round-trip Delay are unidirectional. An ALTO client rmat="counter" target="secbwmetrics"/>, respectively. Note that
all metrics except round-trip delay are unidirectional. An ALTO client
will need to query both directions if needed.</t> will need to query both directions if needed.</t>
<t>The purpose of this document is to ensure proper usage of these eight
<t>The purpose of this document is to ensure proper usage of these 8
performance metrics in the context of ALTO. This document follows the performance metrics in the context of ALTO. This document follows the
guideline defined in Section 14.2 of the ALTO base protocol <xref guidelines defined in <xref target="RFC7285" sectionFormat="of" section="1
target="RFC7285"></xref> on registering ALTO cost metrics. Hence, it 4.2"/>
on registering ALTO cost metrics. Hence, it
specifies the identifier, the intended semantics, and the security specifies the identifier, the intended semantics, and the security
considerations of each one of the metrics specified in Table 1.</t> considerations of each one of the metrics specified in <xref target="costm
etric" sectionFormat="bare"/>.</t>
<t>The definitions of the intended semantics of the metrics tend to be <t>The definitions of the intended semantics of the metrics tend to be
coarse-grained, for guidance only, and they may work well for ALTO. On 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 the other hand, a performance measurement framework, such as the IP
Performance Measurement (IPPM) framework, may provide more details in Performance Metrics (IPPM) framework, may provide more details for
defining a performance metric. This document introduces a mechanism defining a performance metric. This document introduces a mechanism
called "cost-context" to provide additional details, when they are called "cost-context" to provide additional details, when they are
available; see <xref target="sec2"></xref>.</t> available; see <xref target="sec3" format="default"/>.</t>
<!--
<t>Additionally, future versions of this document may define network
metric values that stem from both measurements and provider policies
such as many metrics related to end-to-end path bandwidth.</t>
-->
<t>Following the ALTO base protocol, this document uses JSON to specify <t>Following the ALTO base protocol, this document uses JSON to specify
the value type of each defined metric. See <xref the value type of each defined metric. See <xref target="RFC8259" format="
target="RFC8259"></xref> for JSON data type specification. In default"/> for JSON data type specifications. In
particular, <xref target="RFC7285"></xref> specifies that cost values particular, <xref target="RFC7285" format="default"/> specifies that cost
should be assumed by default as JSONNumber. When defining the value values
representation of each metric in Table 1, this document conforms to should be assumed by default to be 'JSONNumber'. When defining the value
[RFC7285], but specifies additional, generic constraints on valid representation of each metric in <xref target="costmetric" sectionFormat="
JSONNumbers for each metric. For example, each new metric in Table 1 bare"/>, this document conforms to
<xref target="RFC7285"/> but specifies additional, generic constraints on
valid
JSONNumbers for each metric. For example, each new metric in <xref target=
"costmetric" sectionFormat="bare"/>
will be specified as non-negative (&gt;= 0); Hop Count is specified to will be specified as non-negative (&gt;= 0); Hop Count is specified to
be an integer.</t> be an integer.</t>
<t>An ALTO server may provide only a subset of the metrics described in <t>An ALTO server may provide only a subset of the metrics described in
this document. For example, those that are subject to privacy concerns this document. For example, those that are subject to privacy concerns
should not be provided to unauthorized ALTO clients. Hence, all cost should not be provided to unauthorized ALTO clients. Hence, all cost
metrics defined in this document are optional; not all of them need to 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 be exposed to a given application. When an ALTO server supports a cost
metric defined in this document, it announces the metric in its metric defined in this document, it announces the metric in its
information resource directory (IRD) as defined in Section 9.2 of <xref information resource directory (IRD) as defined in <xref target="RFC7285"
target="RFC7285"></xref>.</t> section="9.2" sectionFormat="of"/>.</t>
<t>An ALTO server introducing these metrics should consider related <t>An ALTO server introducing these metrics should consider related
security issues. As a generic security consideration on the reliability security issues. As a generic security consideration regarding reliability
and trust in the exposed metric values, applications SHOULD rapidly give and trust in the exposed metric values, applications <bcp14>SHOULD</bcp14>
up using ALTO-based guidance if they detect that the exposed information promptly stop using ALTO-based guidance if they detect that the exposed in
does not preserve their performance level or even degrades it. <xref formation
target="secsecconsider"></xref> discusses security considerations in does not preserve their performance level or even degrades it. <xref targe
t="secsecconsider" format="default"/> discusses security considerations in
more detail.</t> more detail.</t>
<!-- <t>The definitions of a set of cost metrics can allow us to extend th
e
ALTO base protocol (e.g., allowing output and constraints use different
cost metrics), but such extensions are not in the scope of this
document.</t> -->
</section> </section>
<section numbered="true" toc="default">
<section title="Requirements Language"> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP 14 "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
<xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and "<bcp14>SHOULD NOT</bcp14>",
only when, they appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section> </section>
<section anchor="sec3" numbered="true" toc="default">
<section anchor="sec2" title="Performance Metric Attributes"> <name>Performance Metric Attributes</name>
<t>The definitions of the metrics in this document are coarse-grained, <t>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. A fine-grained framework specified in <xref guidance only. A fine-grained framework as specified in <xref target="RFC6
target="RFC6390"></xref> requires that the fine-grained specification of 390" format="default"/> requires that the fine-grained specification of
a network performance metric include 6 components: (i) Metric Name, (ii) a network performance metric include six components: (1) Metric Name, (2)
Metric Description, (iii) Method of Measurement or Calculation, (iv) Metric Description, (3) Method of Measurement or Calculation, (4)
Units of Measurement, (v) Measurement Points, and (vi) Measurement Units of Measurement, (5) Measurement Points, and (6) Measurement
Timing. Requiring that an ALTO server provides precise, fine-grained Timing. Requiring that an ALTO server provide precise, fine-grained
values for all 6 components for each metric that it exposes may not be values for all six components for each metric that it exposes may not be
feasible or necessary for all ALTO use cases. For example, an ALTO feasible or necessary for all ALTO use cases. For example, an ALTO
server computing its metrics from network-layer traffic-engineering server computing its metrics from network-layer TE
performance metrics may not have information about the method of performance metrics may not have information about the method of
measurement or calculation (e.g., measured traffic patterns).</t> measurement or calculation (e.g., measured traffic patterns).</t>
<t>To address the issue and realize ALTO use cases for the metrics listed
<t>To address the issue and realize ALTO use cases, for metrics in Table in <xref target="costmetric" sectionFormat="bare"/>, this document defines perfo
1, this document defines performance metric identifiers which can be rmance metric identifiers that can be
used in the ALTO protocol with well-defined (i) Metric Name, (ii) Metric used in the ALTO Protocol with the following well-defined items: (1) Metri
Description, (iv) Units of Measurement, and (v) Measurement Points, c Name, (2) Metric
Description, (3) Units of Measurement, and (4) Measurement Points,
which are always specified by the specific ALTO services; for example, which are always specified by the specific ALTO services; for example,
endpoint cost service is between the two endpoints. Hence, the ALTO the endpoint cost service is between the two endpoints. Hence, the ALTO
performance metric identifiers provide basic metric attributes.</t> performance metric identifiers provide basic metric attributes.</t>
<t>To allow the flexibility of allowing an ALTO server to provide <t>To allow the flexibility of allowing an ALTO server to provide
fine-grained information such as Method of Measurement or Calculation, fine-grained information such as Method of Measurement or Calculation
according to its policy and use cases, this document introduces context according to its policy and use cases, this document introduces context
information so that the server can provide these additional details.</t> information so that the server can provide these additional details.</t>
<section anchor="meta" numbered="true" toc="default">
<section anchor="meta" <name>Performance Metric Context: "cost-context"</name>
title="Performance Metric Context: &quot;cost-context&quot;"> <t>The core additional details of a performance metric specify how
<t>The core additional details of a performance metric specify "how"
the metric is obtained. This is referred to as the source of the the metric is obtained. This is referred to as the source of the
metric. Specifically, this document defines three types of metric. Specifically, this document defines three types of
coarse-grained metric information sources: "nominal", and "sla" coarse-grained metric information sources: "nominal", "sla", and "estima
(service level agreement), and "estimation".</t> tion".</t>
<t>For a given type of source, precise interpretation of a performance <t>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.</t> parameters.</t>
<t>To make it possible to specify the source and the aforementioned <t>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 (Section to the "cost-type" field defined by the ALTO base protocol (<xref target
10.7 of <xref target="RFC7285"></xref>) as the following:</t> ="RFC7285" section="10.7" sectionFormat="of"/>) as follows:</t>
<sourcecode type="json"><![CDATA[ object {
<figure>
<artwork><![CDATA[
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;
]]></artwork> ]]></sourcecode>
</figure>
<t>"cost-context" will not be used as a key to distinguish among <t>"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 <bcp14>MUST NOT
announce multiple CostType with the same "cost-metric", "cost-mode" </bcp14>
announce multiple CostType entries with the same "cost-metric", "cost-mo
de",
and "cost-context". They must be placed into different information and "cost-context". They must be placed into different information
resources.</t> resources.</t>
<t>The "cost-source" field of the "cost-context" field is defined as a <t>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 is (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A). The "cost-source" fie
ld is
used in this document to indicate a string of this format.</t> used in this document to indicate a string of this format.</t>
<t>As mentioned above, this document defines three values for <t>As mentioned above, this document defines three values for
"cost-source": "nominal", "sla", and "estimation". The "cost-source" "cost-source": "nominal", "sla", and "estimation". The "cost-source"
field of the "cost-context" field MUST be one registered in "ALTO Cost field of the "cost-context" field <bcp14>MUST</bcp14> be one that is reg
Source" registry (Section 8).</t> istered in the "ALTO Cost
Source Types" registry (<xref target="ianaconsider"/>).</t>
<t>The "nominal" category indicates that the metric value is <t>The "nominal" category indicates that the metric value is
statically configured by the underlying devices. Not all metrics have statically 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 the nominal value, which indicates the configured transmission rate of the
involved devices; latency typically does not have a nominal value.</t> involved devices; latency typically does not have a nominal value.</t>
<t>The "sla" category indicates that the metric value is derived from <t>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 Agreem
agreement (SLA). Some operators also use terms such as "target" or ent (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 <bcp14>RECOMMENDED</bcp14
> that the
"parameters" field provide a link to the SLA definition.</t> "parameters" field provide a link to the SLA definition.</t>
<t>The "estimation" category indicates that the metric value is <t>The "estimation" category indicates that the metric value is
computed through an estimation process. An ALTO server may compute computed 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., <xref target="RFC7471"></xref>, <xref routing protocols (e.g., see <xref target="RFC7471" format="default"/>,
target="RFC8570"></xref>, <xref target="RFC8571"></xref>), traffic <xref target="RFC8570" format="default"/>, and <xref target="RFC8571" format="de
measurement management tools (e.g., TWAMP <xref fault"/>), traffic
target="RFC5357"></xref>), and measurement frameworks (e.g., IPPM), measurement management tools (e.g., the Two-Way Active Measurement Proto
col (TWAMP) <xref target="RFC5357" format="default"/>), and measurement framewor
ks (e.g., IPPM),
with corresponding operational issues. An illustration of potential with corresponding operational issues. An illustration of potential
information flows used for estimating these metrics is shown in Figure information flows used for estimating these metrics is shown in <xref ta
1. <xref target="secopconsider"></xref> discusses in more detail the rget="fig1"/>. <xref target="secopconsider" format="default"/> discusses in more
operational issues and how a network may address them. <figure> detail the
<artwork><![CDATA[ operational issues and how a network may address them. </t>
<figure anchor="fig1">
<name>A Framework to Compute Estimation of Performance Metrics</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| 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 ]]></artwork>
]]></artwork> </figure>
</figure></t> <t>There can be multiple options available when choosing the "cost-sourc
e" category; the operator of an ALTO server will make that choice. If a
<!-- metric does not include a "cost-source" value, the application <bcp14>MU
<t> ST</bcp14>
A particular type of "estimation" is direct "import", which indicates that
the metric value is imported directly from a specific existing protocol or syst
em. Specifying "import" as the source instead of the more generic "estimation" m
ay allow better tracking of information flow. For an "import" metric, it is RECO
MMENDED that the "parameters" field provides details to the system from which ra
w data is imported.
In particular, one may notice that the set of end-to-end metrics defined i
n Table 1 has a large overlap
with the set defined in [RFC8571], in the setting of IGP traffic
engineering performance metrics for each link
(i.e., unidirectional link delay, min/max unidirectional link
delay, unidirectional delay variation, unidirectional link loss,
unidirectional residual bandwidth, unidirectional available bandwidth,
unidirectional utilized bandwidth). Hence, an ALTO server may use "impor
t" to indicate that
its end-to-end metrics are computed from link
metrics imported from [RFC8571].
</t>
-->
<t>There can be multiple choices in deciding the cost-source category.
It is the operator of an ALTO server who chooses the category. If a
metric does not include a "cost-source" value, the application MUST
assume that the value of "cost-source" is the most generic source, assume that the value of "cost-source" is the most generic source,
i.e., "estimation".</t> i.e., "estimation".</t>
</section> </section>
<section anchor="percentile" numbered="true" toc="default">
<section anchor="percentile" title="Performance Metric Statistics"> <name>Performance Metric Statistics</name>
<t>The measurement of a performance metric often yields a set of <t>The measurement of a performance metric often yields a set of
samples from an observation distribution (<xref samples from an observation distribution <xref target="Prometheus" forma
target="Prometheus"></xref>), instead of a single value. A statistical t="default"/>, instead of a single value. A statistical
operator is applied to the samples to obtain a value to be reported to operator is applied to the samples to obtain a value to be reported to
the client. Multiple statistical operators (e.g., min, median, and the client. Multiple statistical operators (e.g., min, median, and
max) are commonly being used.</t> max) are commonly being used.</t>
<t>Hence, this document extends the general ASCII alphanumeric cost
<t>Hence, this document extends the general US-ASCII alphanumeric cost
metric strings, formally specified as the CostMetric type defined in metric strings, formally specified as the CostMetric type defined in
Section 10.6 of [RFC7285], as follows:</t> <xref target="RFC7285" sectionFormat="of" section="10.6"/>, as follows:<
/t>
<t><list style="hanging"> <t indent="3">A cost metric string consists of a base metric identifie
<t>A cost metric string consists of a base metric identifier (or r (or
base identifier for short) string, followed by an optional base identifier for short) string, followed by an optional
statistical operator string, connected by the ASCII character statistical operator string, connected by the ASCII
colon (':', U+003A), if the statistical operator string exists. colon character (':', U+003A), if the statistical operator string ex
The total length of the cost metric string MUST NOT exceed 32, as ists.
required by [RFC7285].</t> The total length of the cost metric string <bcp14>MUST NOT</bcp14> e
</list></t> xceed 32, as
required by <xref target="RFC7285"/>.</t>
<!-- <t>The statistical operator string <bcp14>MUST</bcp14> be one of the fol
</t> lowing:</t>
<figure> <dl>
<artwork> <dt>cur:</dt>
<![CDATA[ <dd>The instantaneous
<metric-identifier> ::= <metric-base-identifier> [ '-' <stat> ]
]]>
</artwork>
</figure>
<t>where &lt;stat&gt; MUST be one of the following: </t>
-->
<t>The statistical operator string MUST be one of the following:</t>
<t><list style="hanging">
<t hangText="cur:"><vspace blankLines="1" /> the instantaneous
observation value of the metric from the most recent sample (i.e., observation value of the metric from the most recent sample (i.e.,
the current value). <vspace blankLines="1" /></t> the current value).</dd>
<dt>percentile, with the letter 'p' followed by a number:</dt>
<t <dd>Gives the percentile specified by the number
hangText="percentile, with letter 'p' followed by a number:"><vspace following the letter 'p'. The number <bcp14>MUST</bcp14> be a non-ne
blankLines="1" /> gives the percentile specified by the number gative JSON
following the letter 'p'. The number MUST be a non-negative JSON
number in the range [0, 100] (i.e., greater than or equal to 0 and number in the range [0, 100] (i.e., greater than or equal to 0 and
less than or equal to 100), followed by an optional decimal part, less than or equal to 100), followed by an optional decimal part,
if a higher precision is needed. The decimal part should start if higher precision is needed. The decimal part should start
with the '.' separator (U+002E), and followed by a sequence of one with the '.' separator (U+002E) and be followed by a sequence of one
or more ASCII numbers between '0' and '9'. Assume this number is y or more ASCII numbers between '0' and '9'. Assume that this number i
and consider the samples coming from a random variable X. Then the s y,
metric returns x, such that the probability of X is less than or and consider the case where the samples are coming from a random var
iable X. The
metric then returns x, such that the probability of X is less than o
r
equal to x, i.e., Prob(X &lt;= x), = y/100. For example, equal to x, i.e., Prob(X &lt;= x), = y/100. For example,
delay-ow:p99 gives the 99% percentile of observed one-way delay; delay-ow:p99 gives the 99th percentile of observed one-way delay;
delay-ow:p99.9 gives the 99.9% percentile. Note that some systems delay-ow:p99.9 gives the 99.9th percentile. Note that some systems
use quantile, which is in the range [0, 1]. When there is a more use quantile, which is in the range [0, 1]. When there is a more
common form for a given percentile, it is RECOMMENDED that the common form for a given percentile, it is <bcp14>RECOMMENDED</bcp14> that the
common form be used; that is, instead of p0, use min; instead of common form be used; that is, instead of p0, use min; instead of
p50, use median; instead of p100, use max. <vspace p50, use median; instead of p100, use max.</dd>
blankLines="1" /></t> <dt>min:</dt>
<dd>The minimal value of
<t hangText="min:"><vspace blankLines="1" /> the minimal value of the observations.</dd>
the observations. <vspace blankLines="1" /></t> <dt>max:</dt>
<dd>The maximal value of
<t hangText="max:"><vspace blankLines="1" /> the maximal value of the observations.</dd>
the observations. <vspace blankLines="1" /></t> <dt>median:</dt>
<dd>The midpoint
<t hangText="median:"><vspace blankLines="1" /> the mid-point (i.e., p50) of the observations.</dd>
(i.e., p50) of the observations. <vspace blankLines="1" /></t> <dt>mean:</dt>
<dd>The arithmetic mean
<t hangText="mean:"><vspace blankLines="1" /> the arithmetic mean value of the observations.</dd>
value of the observations. <vspace blankLines="1" /></t> <dt>stddev:</dt>
<dd>The standard
<t hangText="stddev:"><vspace blankLines="1" /> the standard deviation of the observations.</dd>
deviation of the observations. <vspace blankLines="1" /></t> <dt>stdvar:</dt>
<dd>The standard
<t hangText="stdvar:"><vspace blankLines="1" /> the standard variance of the observations.</dd>
variance of the observations. <vspace blankLines="1" /></t> </dl>
</list></t>
<t>Examples of cost metric strings then include "delay-ow", <t>Examples of cost metric strings then include "delay-ow",
"delay-ow:min", "delay-ow:p99", where "delay-ow" is the base metric "delay-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.</t> strings.</t>
<t>If a cost metric string does not have the optional statistical <t>If a cost metric string does not have the optional statistical
operator string, the statistical operator SHOULD be interpreted as the operator string, the statistical operator <bcp14>SHOULD</bcp14> be inter preted as the
default statistical operator in the definition of the base metric. If default statistical operator in the definition of the base metric. If
the definition of the base metric does not provide a definition for the definition of the base metric does not provide a definition for
the default statistical operator, the metric MUST be considered as the the default statistical operator, the metric <bcp14>MUST</bcp14> be cons idered the
median value.</t> median value.</t>
<t>Note that <xref target="RFC7285"/> limits the overall cost metric ide
<t>Note that RFC 7258 limits the overall cost metric identifier to 32 ntifier 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 overall suffixes defined by this document are also subject to the same overall
32-character limit, so certain combinations of (long) base metric 32-character limit, so certain combinations of (long) base metric
identifier and statistical operator will not be representable. If such identifiers and statistical operators will not be representable. If such
a situation arises, it could be addressed by defining a new base a situation arises, it could be addressed by defining a new base
metric identifier that is an "alias" of the desired base metric, with metric identifier that is an "alias" of the desired base metric, with
identical semantics and just a shorter name.</t> identical semantics and just a shorter name.</t>
</section> </section>
</section> </section>
<section anchor="secpktmetrics" numbered="true" toc="default">
<!-- End of metric attributes --> <name>Packet Performance Metrics</name>
<t>This section introduces ALTO network performance metrics on one-way
<section anchor="secpktmetrics" title="Packet Performance Metrics ">
<t>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 packets count. They measure the "quality of experience" of the stream of packets
sent from a resource provider to a resource consumer. The measures of sent from a resource provider to a resource consumer. The measurements of
each individual packet (pkt) can include the delay from the time when each individual packet (pkt) can include the delay from the time when
the packet enters the network to the time when the packet leaves the the packet enters the network to the time when the packet leaves the
network (pkt.delay); whether the packet is dropped before reaching the network (pkt.delay), whether the packet is dropped before reaching the
destination (pkt.dropped); the number of network hops that the packet destination (pkt.dropped), and the number of network hops that the packet
traverses (pkt.hopcount). The semantics of the performance metrics traverses (pkt.hopcount). The semantics of the performance metrics
defined in this section are that they are statistics computed from these defined in this section are that they are statistics computed from these
measures; for example, the x-percentile of the one-way delay is the measurements; for example, the x-percentile of the one-way delay is the
x-percentile of the set of delays {pkt.delay} for the packets in the x-percentile of the set of delays {pkt.delay} for the packets in the
stream.</t> stream.</t>
<section anchor="oneway" numbered="true" toc="default">
<section title="Cost Metric: One-Way Delay (delay-ow)"> <name>Cost Metric: One-Way Delay (delay-ow)</name>
<section title="Base Identifier"> <section numbered="true" toc="default">
<name>Base Identifier</name>
<t>The base identifier for this performance metric is <t>The base identifier for this performance metric is
"delay-ow".</t> "delay-ow".</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Value Representation"> <name>Value Representation</name>
<t>The metric value type is a single 'JSONNumber' type value <t>The metric value type is a single 'JSONNumber' type value
conforming to the number specification of Section 6 of [RFC8259]. conforming to the number specifications provided in <xref target="RFC8 259" sectionFormat="of" section="6"/>.
The unit is expressed in microseconds. Hence, the number can be a The unit is expressed in microseconds. Hence, the number can be a
floating point number to express delay that is smaller than floating-point number to express delay that is smaller than
microseconds. The number MUST be non-negative.</t> microseconds. The number <bcp14>MUST</bcp14> be non-negative.</t>
</section> </section>
<section numbered="true" toc="default">
<!-- <name>Intended Semantics and Use</name>
<t><list style="hanging"> <dl>
<t hangText="Metric name:"> <dt>Intended Semantics:</dt><dd>To specify the temporal and spatial
<vspace blankLines="1"/>One Way Delay<vspace blankLines="1"/>
</t>
<t hangText="Metric Identifier:">
<vspace blankLines="1"/>owdelay<vspace blankLines="1"/>
</t>
</list></t>
-->
<section title="Intended Semantics and Use">
<t>Intended Semantics: To specify the temporal and spatial
aggregated delay of a stream of packets from the specified source to aggregated delay of a stream of packets from the specified source to
the specified destination. The base semantics of the metric is the the specified destination. The base semantics of the metric is the
Unidirectional Delay metric defined in [RFC8571,RFC8570,RFC7471], Unidirectional Delay metric as defined in <xref target="RFC8571"/>, <x ref target="RFC8570"/>, and <xref target="RFC7471"/>,
but instead of specifying the delay for a link, it is the (temporal) but instead of specifying the delay for a link, it is the (temporal)
aggregation of the link delays from the source to the destination. A aggregation of the link delays from the source to the destination. A
non-normative reference definition of end-to-end one-way delay is non-normative reference definition of the end-to-end one-way delay met
<xref target="RFC7679"></xref>. The spatial aggregation level is ric is provided in
<xref target="RFC7679" format="default"/>. The spatial aggregation lev
el is
specified in the query context, e.g., provider-defined identifier specified in the query context, e.g., provider-defined identifier
(PID) to PID, or endpoint to endpoint, where PID is defined in (PID) to PID, or endpoint to endpoint, where the PID is as defined in
Section 5.1 of [RFC7285].</t> <xref target="RFC7285" sectionFormat="of" section="5.1"/>.</dd>
<dt>Use:</dt>
<t>Use: This metric could be used as a cost metric constraint <dd>This metric could be used as a cost metric constraint
attribute or as a returned cost metric in the response.</t> attribute or as a returned cost metric in the response.</dd>
</dl>
<figure> <figure anchor="example-1">
<artwork><![CDATA[Example 1: Delay value on source-destination endpo <name>Delay Value on Source-Destination Endpoint Pairs (Example 1)</name
int pairs >
<sourcecode type="json"><![CDATA[
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": {
"cost-mode": "numerical", "cost-mode": "numerical",
skipping to change at line 666 skipping to change at line 527
"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"
] ]
} }
} }
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
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
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>Note that since the "cost-type" does not include the <t>Note that since the "cost-type" does not include the
"cost-source" field, the values are based on "estimation". Since the "cost-source" field, the values are based on "estimation". Since the
identifier does not include the statistical operator string identifier does not include the statistical operator string
component, the values will represent median values.</t> component, the values will represent median values.</t>
<t><xref target="example-1a"/> shows an example that is similar to Exa
<t>Example 1a below shows an example that is similar to Example 1, mple 1 (<xref target="example-1"/>), but for IPv6.</t>
but for IPv6.</t> <figure anchor="example-1a">
<name>Delay Value on Source-Destination Endpoint Pairs for IPv6 (Example
<figure> 1a)</name>
<artwork><![CDATA[Example 1a: Delay value on source-destination endp <sourcecode type="json"><![CDATA[
oint 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": {
"cost-mode": "numerical", "cost-mode": "numerical",
skipping to change at line 725 skipping to change at line 578
"endpoints": { "endpoints": {
"srcs": [ "srcs": [
"ipv6:2001:db8:100::1" "ipv6:2001:db8:100::1"
], ],
"dsts": [ "dsts": [
"ipv6:2001:db8:100::2", "ipv6:2001:db8:100::2",
"ipv6:2001:db8:100::3" "ipv6:2001:db8:100::3"
] ]
} }
} }
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 257 Content-Length: 257
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": {
"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
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="ccspec-ow" numbered="true" toc="default">
<section anchor="ccspec-ow" <name>Cost-Context Specification Considerations</name>
title="Cost-Context Specification Considerations"> <dl>
<t>"nominal": Typically network one-way delay does not have a <dt>"nominal":</dt><dd>Typically, network one-way delay does not have
nominal value.</t> a
nominal value.</dd>
<t>"sla": Many networks provide delay-related parameters in their <dt>"sla":</dt><dd>Many networks provide delay-related parameters in t
application-level SLAs. It is RECOMMENDED that the "parameters" heir
application-level SLAs. It is <bcp14>RECOMMENDED</bcp14> that the "par
ameters"
field of an "sla" one-way delay metric include a link (i.e., a field field of an "sla" one-way delay metric include a link (i.e., a field
named "link") providing an URI to the specification of SLA details, named "link") providing a URI for the specification of SLA details,
if available. Such a specification can be either free text for if available. Such a specification can be either (1)&nbsp;free text fo
possible presentation to the user, or a formal specification. The r
format of the specification is out of the scope of this possible presentation to the user or (2)&nbsp;a formal specification.
document.</t> The
format of the specification is outside the scope of this
<!-- document.</dd>
<t>"import": There can be multiple sources to import one-way delay. Fo <dt>"estimation":</dt><dd>The exact estimation method is outside the s
r example, if the import is from [RFC8571] (by using unidirectional link delay, cope of
min/max unidirectional link delay), it is RECOMMENDED that "parameters" provides this document. There can be multiple sources for estimating one-way
"protocol" as a field and "RFC8571" as the value. During import, the server sho
uld be cognizant of potential issues when computing an end-to-end summary statis
tic from link statistics. Another example of an import source is the IPPM framew
ork. For IPPM, it is RECOMMENDED that "parameters" provides "protocol" as a fiel
d and "ippm" as the value; see Section 4 of [I-D.ietf-ippm-initial-registry] for
additional fields which can be specified for "ippm" in "parameters".
</t>
-->
<t>"estimation": The exact estimation method is out of the scope of
this document. There can be multiple sources to estimate one-way
delay. For example, the ALTO server may estimate the end-to-end delay. For example, the ALTO server may estimate the end-to-end
delay by aggregation of routing protocol link metrics; the server delay by aggregation of routing protocol link metrics; the server
may also estimate the delay using active, end-to-end measurements, may also estimate the delay using active, end-to-end measurements --
for example, using the IPPM framework <xref for example, using the IPPM framework <xref target="RFC2330" format="d
target="RFC2330"></xref>.</t> efault"/>.</dd>
</dl>
<t>If the estimation is computed by aggregation of routing protocol <t>If the estimation is computed by aggregation of routing protocol
link metrics (e.g., OSPF <xref target="RFC7471"></xref>, IS-IS <xref link metrics (e.g., Unidirectional Link Delay metrics for OSPF <xref t
target="RFC8570"></xref>, or BGP-LS <xref target="RFC8571"></xref>) arget="RFC7471" format="default"/>, IS-IS <xref target="RFC8570" format="default
Unidirectional Delay link metrics, it is RECOMMENDED that the "/>, or BGP-LS <xref target="RFC8571" format="default"/>), it is <bcp14>RECOMMEN
DED</bcp14> 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 <xref target="RFC7471"/> for
derived metrics); (2) configurations of the routing link metrics derived metrics), (2) configurations of the routing link metrics
such as configured intervals; and (3) the aggregation method from such as configured intervals, and (3) the aggregation method from
link metrics to end-to-end metrics. During aggregation from link link metrics to end-to-end metrics. During aggregation from link
metrics to the end-to-end metric, the server should be cognizant of metrics to end-to-end metrics, the server should be cognizant of
potential issues when computing an end-to-end summary statistic from potential issues when computing an end-to-end summary statistic from
link statistics. The default end-to-end average one-way delay is the 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 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 min and max statistical operators for the one-way delay metric, the
values can be computed directly from the routing link metrics, as values can be computed directly from the routing link metrics, as
[RFC7471,RFC8570,RFC8571] provide Min/Max Unidirectional Link <xref target="RFC7471"/>, <xref target="RFC8570"/>, and <xref target=" RFC8571"/> provide Min/Max Unidirectional Link
Delay.</t> Delay.</t>
<t>If the estimation is from the IPPM measurement framework, it is <t>If the estimation is from the IPPM measurement framework, it is
RECOMMEDED that the "parameters" field of an "estimation" one-way <bcp14>RECOMMENDED</bcp14> that the "parameters" field of an "estimati
delay metric includes the following information: the URI to the URI on" one-way
field of the IPPM metric defined in the IPPM performance metric delay metric include the URI in the "URI"
<xref target="IANA-IPPM"></xref> registry (e.g., field of the IPPM metric defined in the IPPM "Performance Metrics" reg
https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP istry
-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_95Percentile). <xref target="IANA-IPPM" format="default"/> (e.g.,
The IPPM metric MUST be one-way delay (i.e., IPPM OWDelay* metrics). <eref target="https://www.iana.org/assignments/performance-metrics/OWDelay_Activ
The statistical operator of the ALTO metric MUST be consistent with e_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_95Percentile" brackets="angle"/
the IPPM statistical property (e.g., 95-th percentile).</t> >).
The IPPM metric <bcp14>MUST</bcp14> be one-way delay (i.e., IPPM OWDel
<!-- ay* metrics).
<t><list style="hanging"> The statistical operator of the ALTO metric <bcp14>MUST</bcp14> be con
<t hangText="Method of Measurement or Calculation:"><vspace sistent with
blankLines="1"/>See section 8.3 of the IPPM statistical property (e.g., 95th percentile).</t>
[I-D.ietf-ippm-initial-registry] for potential measurement method.
<vspace
blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"
><vspace
blankLines="1"/>See Section 4.1, Data sources for potential data s
ources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
section 8.3.5 of [I-D.ietf-ippm-initial-registry] for potential me
asurement
timing considerations.<vspace blankLines="1"/></t>
</list></t>
-->
</section> </section>
</section> </section>
<section anchor="delayrt" numbered="true" toc="default">
<section title="Cost Metric: Round-trip Delay (delay-rt)"> <name>Cost Metric: Round-Trip Delay (delay-rt)</name>
<section title="Base Identifier"> <section numbered="true" toc="default">
<name>Base Identifier</name>
<t>The base identifier for this performance metric is <t>The base identifier for this performance metric is
"delay-rt".</t> "delay-rt".</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Value Representation"> <name>Value Representation</name>
<t>The metric value type is a single 'JSONNumber' type value <t>The metric value type is a single 'JSONNumber' type value
conforming to the number specification of Section 6 of [RFC8259]. conforming to the number specifications provided in <xref target="RFC8
The number MUST be non-negative. The unit is expressed in 259" sectionFormat="of" section="6"/>.
The number <bcp14>MUST</bcp14> be non-negative. The unit is expressed
in
microseconds.</t> microseconds.</t>
</section> </section>
<section numbered="true" toc="default">
<!-- <name>Intended Semantics and Use</name>
<t><list style="hanging"> <dl>
<t hangText="Metric name:"> <dt>Intended Semantics:</dt><dd><t>To specify temporal and spatial agg
<vspace blankLines="1"/>Round Trip Time<vspace blankLines="1"/> regated
</t>
<t hangText="Metric Identifier:">
<vspace blankLines="1"/>rtt<vspace blankLines="1"/>
</t>
</list></t>
-->
<section title="Intended Semantics and Use">
<t>Intended Semantics: To specify temporal and spatial aggregated
round-trip delay between the specified source and specified round-trip delay between the specified source and specified
destination. The base semantics is that it is the sum of one-way destination. The base semantics is that it is the sum of the one-way
delay from the source to the destination and the one-way delay from 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 the destination back to the source, where the one-way delay is as
defined in Section 4.1. A non-normative reference definition of defined in <xref target="oneway"/>. A non-normative reference definiti
end-to-end round-trip delay is <xref target="RFC2681"></xref>. The on of the
end-to-end round-trip delay metric is provided in <xref target="RFC268
1" format="default"/>. The
spatial aggregation level is specified in the query context (e.g., spatial aggregation level is specified in the query context (e.g.,
PID to PID, or endpoint to endpoint).</t> PID to PID, or endpoint to endpoint).</t>
<t>Note that it is possible for a client to query two one-way delay
<t>Note that it is possible for a client to query two one-way delays (delay-ow) items and then compute the round-trip delay. The server sho
(delay-ow) and then compute the round-trip delay. The server should uld
be cognizant of the consistency of values.</t> be cognizant of the consistency of values.</t></dd>
<dt>Use:</dt>
<t>Use: This metric could be used either as a cost metric constraint <dd>This metric could be used as a cost metric constraint
attribute or as a returned cost metric in the response.</t> attribute or as a returned cost metric in the response.</dd>
</dl>
<figure> <figure anchor="example-2">
<artwork><![CDATA[ <name>Round-Trip Delay of Source-Destination Endpoint Pairs (Example 2)</
Example 2: Round-trip Delay of source-destination endpoint pairs name>
<sourcecode type="json"><![CDATA[
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": {
"cost-mode": "numerical", "cost-mode": "numerical",
skipping to change at line 897 skipping to change at line 705
"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"
] ]
} }
} }
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 245 Content-Length: 245
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-rt" "cost-metric": "delay-rt"
} }
}, },
"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
} }
} }
} }
]]></sourcecode>
]]></artwork> </figure>
</figure>
</section>
<!--
<section title="Measurement Considerations">
<t><list style="hanging">
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See section 4.3 of
[I-D.ietf-ippm-initial-registry] for potential measurement method. <
vspace
blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"><
vspace
blankLines="1"/>See section 4.1, Data sources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
section 4.3.5 of [I-D.ietf-ippm-initial-registry] for Measurement
Timing. <vspace blankLines="1"/></t>
</list></t>
</section>
<section title="Measurement Considerations and Parameters">
<t>See Section 4 of [I-D.ietf-ippm-initial-registry] for measurement c
onsiderations and parameters which may be specified in "parameters". Note that t
he "parameters" field is an optional field providing non-normative information.
</t>
</section> </section>
--> <section numbered="true" toc="default">
<name>Cost-Context Specification Considerations</name>
<section title="Cost-Context Specification Considerations"> <dl>
<t>"nominal": Typically network round-trip delay does not have a <dt>"nominal":</dt><dd>Typically, network round-trip delay does not ha
nominal value.</t> ve a
nominal value.</dd>
<t>"sla": See the "sla" entry in <xref <dt>"sla":</dt><dd>See the "sla" entry in <xref target="ccspec-ow" for
target="ccspec-ow"></xref>.</t> mat="default"/>.</dd>
<dt>"estimation":</dt><dd>See the "estimation" entry in <xref target="
<!-- ccspec-ow" format="default"/>. For estimation by aggregation of routing
<t>"import": There can be multiple sources to import round-trip delay.
If the import is from [RFC8571] (by using unidirectional link delay, min/max un
idirectional link delay), it is RECOMMENDED that "parameters" provides "protocol
" as a field and "RFC8571" as the value; see <xref target="ccspec-ow" /> for dis
cussions on summing up link metrics to obtain end-to-end metrics. If the import
is from the IPPM framework, it is RECOMMENDED that "parameters" provides "protoc
ol" as a field and "ippm" as the value; see Section 4 of [I-D.ietf-ippm-initial-
registry] for additional fields which can be specified for "ippm" in "parameters
".
</t>
-->
<t>"estimation": See the "estimation" entry in <xref
target="ccspec-ow"></xref>. For estimation by aggregation of routing
protocol link metrics, the aggregation should include all links from protocol link metrics, the aggregation should include all links from
the source to the destination and then back to the source; for the source to the destination and then back to the source; for
estimation using IPPM, the IPPM metric MUST be round-trip delay estimation using IPPM, the IPPM metric <bcp14>MUST</bcp14> be round-tr ip delay
(i.e., IPPM RTDelay* metrics). The statistical operator of the ALTO (i.e., IPPM RTDelay* metrics). The statistical operator of the ALTO
metric MUST be consistent with the IPPM statistical property (e.g., metric <bcp14>MUST</bcp14> be consistent with the IPPM statistical pro
95-th percentile).</t> perty (e.g.,
95th percentile).</dd>
<!-- </dl>
<t><list style="hanging">
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See section 8.3 of
[I-D.ietf-ippm-initial-registry] for potential measurement method.
<vspace
blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"
><vspace
blankLines="1"/>See Section 4.1, Data sources for potential data s
ources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
section 8.3.5 of [I-D.ietf-ippm-initial-registry] for potential me
asurement
timing considerations.<vspace blankLines="1"/></t>
</list></t>
-->
</section> </section>
</section> </section>
<section anchor="delayvar" numbered="true" toc="default">
<section title="Cost Metric: Delay Variation (delay-variation)"> <name>Cost Metric: Delay Variation (delay-variation)</name>
<!-- <section numbered="true" toc="default">
<t><list style="hanging"> <name>Base Identifier</name>
<t hangText="Metric name:">
<vspace blankLines="1"/>Packet Delay Variation<vspace blankLines="
1"/>
</t>
<t hangText="Metric Identifier:">
<vspace blankLines="1"/>pdv<vspace blankLines="1"/>
</t>
</list></t>
-->
<section title="Base Identifier">
<t>The base identifier for this performance metric is <t>The base identifier for this performance metric is
"delay-variation".</t> "delay-variation".</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Value Representation"> <name>Value Representation</name>
<t>The metric value type is a single 'JSONNumber' type value <t>The metric value type is a single 'JSONNumber' type value
conforming to the number specification of Section 6 of [RFC8259]. conforming to the number specifications provided in <xref target="RFC8
The number MUST be non-negative. The unit is expressed in 259" sectionFormat="of" section="6"/>.
The number <bcp14>MUST</bcp14> be non-negative. The unit is expressed
in
microseconds.</t> microseconds.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Intended Semantics and Use"> <name>Intended Semantics and Use</name>
<t>Intended Semantics: To specify temporal and spatial aggregated <dl>
delay variation (also called delay jitter)) with respect to the <dt>Intended Semantics:</dt><dd><t>To specify temporal and spatial agg
regated
delay variation (also called delay jitter) with respect to the
minimum delay observed on the stream over the one-way delay from the minimum 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 define
in Section 4.1. A non-normative reference definition of end-to-end d
one-way delay variation is <xref target="RFC3393"></xref>. Note that in <xref target="oneway"/>. A non-normative reference definition of th
<xref target="RFC3393"></xref> allows the specification of a generic e end-to-end
one-way delay variation metric is provided in <xref target="RFC3393" f
ormat="default"/>. Note that
<xref target="RFC3393" format="default"/> allows the specification of
a generic
selection function F to unambiguously define the two packets selection function F to unambiguously define the two packets
selected to compute delay variations. This document defines the selected to compute delay variations. This document defines the
specific case that F selects as the "first" packet the one with the specific case where F selects the packet with the smallest one-way
smallest one-way delay. The spatial aggregation level is specified delay as the "first" packet. The spatial aggregation level is specifie
d
in the query context (e.g., PID to PID, or endpoint to in the query context (e.g., PID to PID, or endpoint to
endpoint).</t> endpoint).</t>
<t>Note that in statistics, variation is typically evaluated by
<t>Note that in statistics, variations are typically evaluated by the distance from samples relative to the mean. In the context of netw
the distance from samples relative to the mean. In networking orking, it is more commonly defined from samples relative to the
context, it is more commonly defined from samples relative to the
min. This definition follows the networking convention.</t> min. This definition follows the networking convention.</t>
</dd>
<t>Use: This metric could be used either as a cost metric constraint <dt>Use:</dt>
attribute or as a returned cost metric in the response.</t> <dd>This metric could be used as a cost metric constraint
attribute or as a returned cost metric in the response.</dd>
<figure> </dl>
<artwork><![CDATA[Example 3: Delay variation value on source-destina <figure anchor="example-3">
tion endpoint pairs <name>Delay Variation Value on Source-Destination Endpoint Pairs (Exa
mple 3)</name>
<sourcecode type="json"><![CDATA[
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": {
"cost-mode": "numerical", "cost-mode": "numerical",
skipping to change at line 1084 skipping to change at line 825
"cost-metric": "delay-variation" "cost-metric": "delay-variation"
} }
}, },
"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
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section>
<!--
<section title="Measurement Considerations">
<t><list style="hanging">
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See Section 5.3 of
[I-D.ietf-ippm-initial-registry] for potential measurement method.<v
space
blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"><
vspace
blankLines="1"/>See Section 4.1, Data sources for potential data sou
rces.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
Section 5.3.5 of [I-D.ietf-ippm-initial-registry] for Measurement
Timing.<vspace blankLines="1"/></t>
</list></t>
</section>
<section title="Measurement Considerations and Parameters">
<t>See Section 5 of [I-D.ietf-ippm-initial-registry] for measurement c
onsiderations and parameters which may be specified in "parameters". Note that t
he "parameters" field is an optional field providing non-normative information.
</t>
</section> </section>
--> <section numbered="true" toc="default">
<name>Cost-Context Specification Considerations</name>
<section title="Cost-Context Specification Considerations"> <dl>
<t>"nominal": Typically network delay variation does not have a <dt>"nominal":</dt><dd>Typically, network delay variation does not hav
nominal value.</t> e a
nominal value.</dd>
<t>"sla": See the "sla" entry in <xref <dt>"sla":</dt><dd>See the "sla" entry in <xref target="ccspec-ow" for
target="ccspec-ow"></xref>.</t> mat="default"/>.</dd>
<dt>"estimation":</dt><dd>See the "estimation" entry in <xref target="
<!-- ccspec-ow" format="default"/>. For estimation by aggregation of routing
<t>"import": There can be multiple sources to import delay variation.
If the import is from [RFC8571] (by using unidirectional delay variation), it is
RECOMMENDED that "parameters" provides "protocol" as a field and "RFC8571" as t
he value; see <xref target="ccspec-ow" /> for discussions on summing up link met
rics to obtain end-to-end metrics. If the import is from the IPPM framework, it
is RECOMMENDED that "parameters" provides "protocol" as a field and "ippm" as th
e value; see Section 4 of [I-D.ietf-ippm-initial-registry] for additional fields
which can be specified for "ippm" in "parameters".
</t>
-->
<t>"estimation": See the "estimation" entry in <xref
target="ccspec-ow"></xref>. For estimation by aggregation of routing
protocol link metrics, the default aggregation of the average of protocol link metrics, the default aggregation of the average of
delay variations is the sum of the link delay variations; for delay variations is the sum of the link delay variations; for
estimation using IPPM, the IPPM metric MUST be delay variation estimation using IPPM, the IPPM metric <bcp14>MUST</bcp14> be delay va riation
(i.e., IPPM OWPDV* metrics). The statistical operator of the ALTO (i.e., IPPM OWPDV* metrics). The statistical operator of the ALTO
metric MUST be consistent with the IPPM statistical property (e.g., metric <bcp14>MUST</bcp14> be consistent with the IPPM statistical pro
95-th percentile).</t> perty (e.g.,
95th percentile).</dd>
<!-- </dl>
<t><list style="hanging">
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See section 8.3 of
[I-D.ietf-ippm-initial-registry] for potential measurement method.
<vspace
blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"
><vspace
blankLines="1"/>See Section 4.1, Data sources for potential data s
ources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
section 8.3.5 of [I-D.ietf-ippm-initial-registry] for potential me
asurement
timing considerations.<vspace blankLines="1"/></t>
</list></t>
-->
</section> </section>
</section> </section>
<section anchor="lossrate" numbered="true" toc="default">
<section title="Cost Metric: Loss Rate (lossrate)"> <name>Cost Metric: Loss Rate (lossrate)</name>
<!-- <section numbered="true" toc="default">
<t><list style="hanging"> <name>Base Identifier</name>
<t hangText="Metric name:"><vspace blankLines="1"/>Packet
loss<vspace blankLines="1"/></t>
<t hangText="Metric Identifier:">
<vspace blankLines="1"/>pktloss<vspace blankLines="1"/>
</t>
</list></t>
-->
<section title="Base Identifier">
<t>The base identifier for this performance metric is <t>The base identifier for this performance metric is
"lossrate".</t> "lossrate".</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Value Representation"> <name>Value Representation</name>
<t>The metric value type is a single 'JSONNumber' type value <t>The metric value type is a single 'JSONNumber' type value
conforming to the number specification of Section 6 of [RFC8259]. conforming to the number specifications provided in <xref target="RFC8
The number MUST be non-negative. The value represents the percentage 259" sectionFormat="of" section="6"/>.
The number <bcp14>MUST</bcp14> be non-negative. The value represents t
he percentage
of packet losses.</t> of packet losses.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Intended Semantics and Use"> <name>Intended Semantics and Use</name>
<t>Intended Semantics: To specify temporal and spatial aggregated <dl>
<dt>Intended Semantics:</dt><dd>To specify the temporal and spatial ag
gregated
one-way packet loss rate from the specified source and the specified one-way packet loss rate from the specified source and the specified
destination. The base semantics of the metric is the Unidirectional destination. The base semantics of the metric is the Unidirectional
Link Loss metric defined in [RFC8571,RFC8570,RFC7471], but instead Link Loss metric as defined in <xref target="RFC8571"/>, <xref target= "RFC8570"/>, and <xref target="RFC7471"/>, but instead
of specifying the loss for a link, it is the aggregated loss of all of specifying the loss for a link, it is the aggregated loss of all
links from the source to the destination. The spatial aggregation links from the source to the destination. The spatial aggregation
level is specified in the query context (e.g., PID to PID, or level is specified in the query context (e.g., PID to PID, or
endpoint to endpoint).</t> endpoint to endpoint).</dd>
<dt>Use:</dt>
<t>Use: This metric could be used as a cost metric constraint <dd>This metric could be used as a cost metric constraint
attribute or as a returned cost metric in the response.</t> attribute or as a returned cost metric in the response.</dd>
</dl>
<figure> <figure anchor="example-4">
<artwork><![CDATA[ <name>Loss Rate Value on Source-Destination Endpoint Pairs (Example 4
Example 5: Loss rate value on source-destination endpoint pairs )</name>
<sourcecode type="json"><![CDATA[
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": {
"cost-mode": "numerical", "cost-mode": "numerical",
skipping to change at line 1218 skipping to change at line 898
"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"
] ]
} }
} }
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 248 Content-Length: 248
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": "lossrate" "cost-metric": "lossrate"
} }
}, },
"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
} }
} }
} }
]]></artwork> ]]></sourcecode></figure>
</figure>
</section>
<!--
<section title="Measurement Considerations and Parameters">
<t><list style="hanging">
<t hangText="Method of Measurement or Calculation:"><vspace
blankLines="1"/>See Section 2.6 of [RFC7680] for Measurement
Method.<vspace blankLines="1"/></t>
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"><
vspace
blankLines="1"/>See Section 4.1 this document, Data sources.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
Section 2 and Section 3 of [RFC7680] for Measurement Timing.<vspace
blankLines="1"/></t>
</list></t>
<t>See Section 4 of [I-D.ietf-ippm-initial-registry] for measurement c
onsiderations and parameters which may be specified in "parameters". Note that t
he "parameters" field is an optional field providing non-normative information.<
/t>
</section> </section>
--> <section numbered="true" toc="default">
<name>Cost-Context Specification Considerations</name>
<section title="Cost-Context Specification Considerations"> <dl>
<t>"nominal": Typically packet loss rate does not have a nominal <dt>"nominal":</dt>
value, although some networks may specify zero losses.</t> <dd>Typically, the packet loss rate does not have a nominal
value, although some networks may specify zero losses.</dd>
<t>"sla": See the "sla" entry in <xref <dt>"sla":</dt>
target="ccspec-ow"></xref>..</t> <dd>See the "sla" entry in <xref target="ccspec-ow" format="default"/>.
</dd>
<!-- <dt>"estimation":</dt>
<t>"import": There can be multiple sources to import packet loss rate. <dd>See the "estimation" entry in
If the import is from [RFC8571] (by using unidirectional link loss), it is RECO <xref target="ccspec-ow" format="default"/>. For estimation
MMENDED that "parameters" provides "protocol" as a field and "RFC8571" as the va by aggregation of routing protocol link metrics, the default
lue; see <xref target="ccspec-ow" /> for discussions on summing up link metrics aggregation of the average loss rate is the sum of the
to obtain end-to-end metrics. If the import is from the IPPM framework, it is RE link loss rates. But this default aggregation is valid
COMMENDED that "parameters" provides "protocol" as a field and "ippm" as the val only if two conditions are met: (1) link loss rates are low and (2) on
ue; see Section 4 of [I-D.ietf-ippm-initial-registry] for additional fields whic e assumes that each link's
h can be specified for "ippm" in "parameters". loss events are uncorrelated with every other link's loss
</t> events. When loss rates at the links are high but
--> independent, the general formula for aggregating loss,
assuming that each link is independent, is to compute end-to-end
<t>"estimation": See the "estimation" entry in <xref loss as one minus the product of the success rate for each
target="ccspec-ow"></xref>. For estimation by aggregation of routing link. Aggregation when losses at links are correlated can be
protocol link metrics, the default aggregation of the average of more complex, and the ALTO server should be cognizant of
loss rate is the sum of the link link loss rates. But this default correlated loss rates. For estimation using IPPM, the IPPM
aggregation is valid only if two conditions are met: (1) it is valid metric <bcp14>MUST</bcp14> be packet loss (i.e., IPPM
only when link loss rates are low, and (2) it assumes that each OWLoss* metrics). The statistical operator of the ALTO
link's loss events are uncorrelated with every other link's loss metric <bcp14>MUST</bcp14> be consistent with the IPPM
events. When loss rates at the links are high but independent, the statistical property (e.g., 95th percentile).</dd>
general formula for aggregating loss assuming each link is </dl>
independent is to compute end-to-end loss as one minus the product
of the success rate for each link. Aggregation when losses at links
are correlated can be more complex and the ALTO 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., 95-th percentile).</t>
</section> </section>
</section> </section>
<section anchor="hopcount" numbered="true" toc="default">
<section title="Cost Metric: Hop Count (hopcount)"> <name>Cost Metric: Hop Count (hopcount)</name>
<t>The hopcount metric is mentioned in Section 9.2.3 of <xref <t>The hop count (hopcount) metric is mentioned in <xref target="RFC7285
target="RFC7285"></xref> as an example. This section further clarifies " sectionFormat="of" section="9.2.3"/>
as an example. This section further clarifies
its properties.</t> its properties.</t>
<section numbered="true" toc="default">
<!-- <name>Base Identifier</name>
<t><list style="hanging">
<t hangText="Metric name:">
<vspace blankLines="1"/>Hop count<vspace blankLines="1"/>
</t>
<t hangText="Metric Identifier:">
<vspace blankLines="1"/>hopcount<vspace blankLines="1"/>
</t>
</list></t>
-->
<section title="Base Identifier">
<t>The base identifier for this performance metric is <t>The base identifier for this performance metric is
"hopcount".</t> "hopcount".</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Value Representation"> <name>Value Representation</name>
<t>The metric value type is a single 'JSONNumber' type value <t>The metric value type is a single 'JSONNumber' type value
conforming to the number specification of Section 6 of [RFC8259]. conforming to the number specifications provided in <xref target="RFC8
The number MUST be a non-negative integer (greater than or equal to 259" sectionFormat="of" section="6"/>.
The number <bcp14>MUST</bcp14> be a non-negative integer (greater than
or equal to
0). The value represents the number of hops.</t> 0). The value represents the number of hops.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Intended Semantics and Use"> <name>Intended Semantics and Use</name>
<!-- <dl>
<t><list style="hanging"> <dt>Intended Semantics:</dt>
<t hangText="Metric Description:"><vspace blankLines="1"/> To <dd>To specify the number of hops in the path
specify the number of hops in the path between the source endpoint
and the destination endpoint. The hop count is a basic measurement
of distance in a network and can be exposed as Router Hops, in
direct relation to the routing protocols originating this
information. </t>
<t hangText="Metric Representation:"><vspace blankLines="1"/>The met
ric value type is a single 'JSONNumber' type value conforming to the number spec
ification [RFC8259], Section 6. The number MUST be an integer and non-negative.
<vspace blankLines="1"/></t>
</list></t>
-->
<t>Intended Semantics: To specify the number of hops in the path
from the specified source to the specified destination. The hop from the specified source to the specified destination. The hop
count is a basic measurement of distance in a network and can be count is a basic measurement of distance in a network and can be
exposed as the number of router hops computed from the routing exposed as the number of router hops computed from the routing
protocols originating this information. A hop, however, may protocols originating this information. A hop, however, may
represent other units. The spatial aggregation level is specified in represent other units. The spatial aggregation level is specified in
the query context (e.g., PID to PID, or endpoint to endpoint).</t> the query context (e.g., PID to PID, or endpoint to endpoint).</dd>
<t>Use: This metric could be used as a cost metric constraint
attribute or as a returned cost metric in the response.</t>
<figure>
<artwork><![CDATA[
Example 4: hopcount value on source-destination endpoint pairs
<dt>Use:</dt>
<dd>This metric could be used as a cost metric constraint
attribute or as a returned cost metric in the response.</dd>
</dl>
<figure anchor="example-5">
<name>Hop Count Value on Source-Destination Endpoint Pairs (Example 5
)</name>
<sourcecode type="json"><![CDATA[
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": {
"cost-mode": "numerical", "cost-mode": "numerical",
skipping to change at line 1380 skipping to change at line 1007
"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"
] ]
} }
} }
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 245 Content-Length: 245
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": "hopcount" "cost-metric": "hopcount"
} }
}, },
"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
} }
} }
} }
]]></artwork> ]]></sourcecode></figure>
</figure> </section>
</section> <section numbered="true" toc="default">
<name>Cost-Context Specification Considerations</name>
<!-- <dl>
<section title="Measurement Considerations and Parameters"> <dt>"nominal":</dt><dd>Typically, the hop count does not have a nomina
l value.</dd>
<t>The hop count can be calculated based on the number of routers fr <dt>"sla":</dt><dd>Typically, the hop count does not have an SLA value
om the .</dd>
source endpoint through which data must <dt>"estimation":</dt><dd>The exact estimation method is outside the s
pass to reach the destination endpoint. This count can be measured cope of
at the source this document. An example of estimating hop count values is by importi
endpoint by traceroute.</t> ng
from IGP routing protocols. It is <bcp14>RECOMMENDED</bcp14> that the
<t>Upon "parameters"
need, the traceroute can use UDP probe message or other field of an "estimation" hop count define the meaning of a hop.</dd>
implementations that use ICMP and TCP to discover the hop counts </dl>
along the path from source endpoint to destination
endpoint.</t>
</section>
-->
<section title="Cost-Context Specification Considerations">
<t>"nominal": Typically hop count does not have a nominal value.</t>
<t>"sla": Typically hop count does not have an SLA value.</t>
<!--
<t>"import": There can be multiple sources to import hop count, such a
s from IGP routing protocols.
</t>
-->
<t>"estimation": The exact estimation method is out of the scope of
this document. An example of estimating hopcounts is by importing
from IGP routing protocols. It is RECOMMENDED that the "parameters"
field of an "estimation" hop count define the meaning of a hop.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="secbwmetrics" numbered="true" toc="default">
<section anchor="secbwmetrics" <name>Throughput/Bandwidth Performance Metrics</name>
title="Throughput/Bandwidth Performance Metrics"> <t>This section introduces three metrics related to throughput and bandwid
<t>This section introduces four throughput/bandwidth related metrics. th.
Given a specified source to a specified destination, these metrics Given a specified source and a specified destination, these metrics
reflect the volume of traffic that the network can carry from the source reflect the volume of traffic that the network can carry from the source
to the destination.</t> to the destination.</t>
<section anchor="tput" numbered="true" toc="default">
<section title="Cost Metric: TCP Throughput (tput)"> <name>Cost Metric: TCP Throughput (tput)</name>
<section title="Base Identifier"> <section numbered="true" toc="default">
<name>Base Identifier</name>
<t>The base identifier for this performance metric is "tput".</t> <t>The base identifier for this performance metric is "tput".</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Value Representation"> <name>Value Representation</name>
<t>The metric value type is a single 'JSONNumber' type value <t>The metric value type is a single 'JSONNumber' type value
conforming to the number specification of Section 6 of [RFC8259]. conforming to the number specifications provided in <xref target="RFC8
The number MUST be non-negative. The unit is bytes per second.</t> 259" sectionFormat="of" section="6"/>.
The number <bcp14>MUST</bcp14> be non-negative. The unit is bytes per
second.</t>
</section> </section>
<section numbered="true" toc="default">
<!-- <name>Intended Semantics and Use</name>
<t><list style="hanging"> <dl>
<t hangText="Metric name:"><vspace <dt>Intended Semantics:</dt><dd>To give the throughput of a
blankLines="1"/>Throughput<vspace blankLines="1"/></t> congestion control conforming TCP flow from the specified source to th
e
<t hangText="Metric Identifier:"> specified destination. The throughput <bcp14>SHOULD</bcp14> be interpr
<vspace blankLines="1"/>throughput<vspace blankLines="1"/> eted as only
</t>
</list></t>
-->
<section title="Intended Semantics and Use">
<t>Intended Semantics: To give the throughput of a TCP
congestion-control conforming 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 an estimation, and the estimation is designed only for bulk
flows.</t> flows.</dd>
<t>Use: This metric could be used as a cost metric constraint
attribute or as a returned cost metric in the response.</t>
<figure>
<artwork><![CDATA[
Example 5: TCP throughput value on source-destination endpoint pairs
<dt>Use:</dt>
<dd>This metric could be used as a cost metric constraint
attribute or as a returned cost metric in the response.</dd>
</dl>
<figure anchor="example-6">
<name>TCP Throughput Value on Source-Destination Endpoint Pairs (Exam
ple 6)</name>
<sourcecode type="json"><![CDATA[
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": {
"cost-mode": "numerical", "cost-mode": "numerical",
skipping to change at line 1507 skipping to change at line 1097
"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"
] ]
} }
} }
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 251 Content-Length: 251
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": "tput" "cost-metric": "tput"
} }
}, },
"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
} }
} }
} }
]]></artwork> ]]></sourcecode></figure>
</figure>
</section> </section>
<section numbered="true" toc="default">
<!-- <name>Cost-Context Specification Considerations</name>
<section title="Measurement Considerations and Parameters"> <dl>
<dt>"nominal":</dt><dd>Typically, TCP throughput does not have a nomin
<t><list style="hanging"> al
<t hangText="Method of Measurement or Calculation:"><vspace value and <bcp14>SHOULD NOT</bcp14> be generated.</dd>
blankLines="1"/>See Section 3.3 of [RFC6349] for Measurement <dt>"sla":</dt><dd>Typically, TCP throughput does not have an SLA valu
Method.<vspace blankLines="1"/></t> e and
<bcp14>SHOULD NOT</bcp14> be generated.</dd>
<t <dt>"estimation":</dt><dd>The exact estimation method is outside the s
hangText="Measurement Point(s) with Potential Measurement Domain:"> cope of
<vspace this document. It is <bcp14>RECOMMENDED</bcp14> that the "parameters"
blankLines="1"/>See Section 4.1 of this document.<vspace field of an
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>Similar
to RTT. See Section 4.3.5 of [I-D.ietf-ippm-initial-registry] for
Measurement Timing. <vspace blankLines="1"/></t>
</list></t>
<t>See Section 3.3 of [RFC6349] for measurement
method and parameters which may be specified in "parameters". Note
that the "parameters" field is an optional field providing non-normative inform
ation.</t>
</section>
-->
<section title="Cost-Context Specification Considerations">
<t>"nominal": Typically TCP throughput does not have a nominal
value, and SHOULD NOT be generated.</t>
<t>"sla": Typically TCP throughput does not have an SLA value, and
SHOULD NOT be generated.</t>
<!--
<t>"import": Typically there is not a routing protocol through which o
ne can import TCP throughput. If the import is from the IPPM framework, it is RE
COMMENDED that "parameters" provides "protocol" as a field and "ippm" as the val
ue; see Section 4 of [I-D.ietf-ippm-initial-registry] for additional fields whic
h can be specified for "ippm" in "parameters".
</t>
-->
<t>"estimation": The exact estimation method is out of the scope of
this document. It is RECOMMENDED that the "parameters" field of an
"estimation" TCP throughput metric include the following "estimation" TCP throughput metric include the following
information: (1) the congestion-control algorithm; and (2) the information: (1) the congestion control algorithm and (2) the
estimation methodology. To specify (1), it is RECOMMENDED that the estimation methodology. To specify (1), it is <bcp14>RECOMMENDED</bcp1
4> that the
"parameters" field (object) include a field named "parameters" field (object) include a field named
"congestion-control-algorithm", which provides a URI for the "congestion-control-algorithm", which provides a URI for the
specification of the algorithm; for example, for an ALTO server to specification of the algorithm; for example, for an ALTO server to
provide estimation to the throughput of a Cubic Congestion control provide estimation of the throughput of a CUBIC congestion control
flow, its "parameters" includes a field flow, its "parameters" field includes the
"congestion-control-algorithm", with value being set to <xref "congestion-control-algorithm" field, with value being set to the URI
target="I-D.ietf-tcpm-rfc8312bis"></xref>; for an ongoing congestion for <xref target="RFC9438" format="default"/>; for an ongoing congestion control
control algorithm such as BBR, a a link to its specification. To algorithm such as BBR, a link to its specification can be added. To
specify (2), the "parameters" includes as many details as possible; specify (2), the "parameters" field includes as many details as possib
for example, for TCP Cubic throughout estimation, the "parameters" le;
for example, for the TCP Cubic throughout estimation, the "parameters"
field specifies that the throughput is estimated by setting _C_ to field specifies that the throughput is estimated by setting _C_ to
0.4, and the Equation in Figure 8 of <xref 0.4, and the equation in <xref target="RFC9438" sectionFormat="comma"
target="I-D.ietf-tcpm-rfc8312bis"></xref> is applied; as an section="5.1"/>, Figure 8 is applied; as an
alternative, the methodology may be based on the NUM model <xref alternative, the methodology may be based on the NUM model <xref targe
target="Prophet"></xref>, or the G2 model <xref target="G2"></xref>. t="Prophet" format="default"/> or the model described in <xref target="G2" forma
The exact specification of the parameters field is out of the scope t="default"/>.
of this document.</t> The exact specification of the "parameters" field is outside the scope
of this document.</dd>
</dl>
</section> </section>
</section> </section>
<section anchor="bwresidual" numbered="true" toc="default">
<!-- TCP Throughput --> <name>Cost Metric: Residual Bandwidth (bw-residual)</name>
<section numbered="true" toc="default">
<section title="Cost Metric: Residual Bandwidth (bw-residual)"> <name>Base Identifier</name>
<!--
<t><list style="hanging">
<t hangText="Metric name:"><vspace blankLines="1"/>Residual
Bandwidth<vspace blankLines="1"/></t>
<t hangText="Metric Identifier:">
<vspace blankLines="1"/>residualbw<vspace blankLines="1"/>
</t>
</list></t>
-->
<section title="Base Identifier">
<t>The base identifier for this performance metric is <t>The base identifier for this performance metric is
"bw-residual".</t> "bw-residual".</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Value Representation"> <name>Value Representation</name>
<t>The metric value type is a single 'JSONNumber' type value that is <t>The metric value type is a single 'JSONNumber' type value that is
non-negative. The unit of measurement is bytes per second.</t> non-negative. The unit of measurement is bytes per second.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Intended Semantics and Use"> <name>Intended Semantics and Use</name>
<t>Intended Semantics: To specify temporal and spatial residual <dl>
bandwidth from the specified source and the specified destination. <dt>Intended Semantics:</dt><dd><t>To specify temporal and spatial res
idual
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 Bandwidth metric as defined in <xref target="RFC8571"/>, <xref target= "RFC8570"/>, and <xref target="RFC7471"/>, but instead
of specifying the residual bandwidth for a link, it is the residual of specifying the residual bandwidth for a link, it is the residual
bandwidth of the path from the source to the destination. Hence, it bandwidth of the path from the source to the destination. Hence, it
is the minimal residual bandwidth among all links from the source to is the minimal residual bandwidth among all links from the source to
the destination. When the max statistical operator is defined for the destination. When the max statistical operator is defined for
the metric, it typically provides the minimum of the link capacities the metric, it typically provides the minimum of the link capacities
along the path, as the default value of the residual bandwidth of a along the path, as the default value of the residual bandwidth of a
link is its link capacity [RFC8571,8570,7471]. The spatial link is its link capacity <xref target="RFC8571"/> <xref target="RFC85 70"/> <xref target="RFC7471"/>. The spatial
aggregation unit is specified in the query context (e.g., PID to aggregation unit is specified in the query context (e.g., PID to
PID, or endpoint to endpoint).</t> PID, or endpoint to endpoint).</t>
<t>The default statistical operator for residual bandwidth is the <t>The default statistical operator for residual bandwidth is the
current instantaneous sample; that is, the default is assumed to be current instantaneous sample; that is, the default is assumed to be
"cur".</t> "cur".</t>
</dd>
<t>Use: This metric could be used either as a cost metric constraint <dt>Use:</dt>
attribute or as a returned cost metric in the response.</t> <dd>This metric could be used as a cost metric constraint
attribute or as a returned cost metric in the response.</dd>
<figure> </dl>
<artwork><![CDATA[ <figure anchor="example-7">
Example 7: bw-residual value on source-destination endpoint pairs <name>Residual Bandwidth Value on Source-Destination Endpoint Pairs (
Example 7)</name>
<sourcecode type="json"><![CDATA[
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": {
"cost-mode": "numerical", "cost-mode": "numerical",
skipping to change at line 1666 skipping to change at line 1207
"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"
] ]
} }
} }
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
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
} }
} }
} }
]]></artwork> ]]></sourcecode></figure>
</figure>
</section> </section>
<section numbered="true" toc="default">
<!-- <name>Cost-Context Specification Considerations</name>
<section title="Measurement Considerations and Parameters"> <dl>
<t><list style="hanging"> <dt>"nominal":</dt><dd>Typically, residual bandwidth does not have a n
<t hangText="Method of Measurement or Calculation:"><vspace ominal
blankLines="1"/>residual Bandwidth is the Unidirectional residual value.</dd>
bandwidth measured between two directly connected IS-IS neighbors <dt>"sla":</dt><dd>Typically, residual bandwidth does not have an SLA
or OSPF neighbors. See Section 4.5 of [RFC7810] for Measurement value.</dd>
Method. <vspace blankLines="1"/></t> <dt>"estimation":</dt><dd>See the "estimation" entry in <xref target="
ccspec-ow"/>. The current ("cur")
<t residual bandwidth of a path is the minimal residual
hangText="Measurement Point(s) with Potential Measurement Domain:">< bandwidth of all links on the path.</dd>
vspace </dl>
blankLines="1"/>See Section 4.1 of this document.<vspace
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
Section 5 of [RFC7810] for Measurement Timing.<vspace
blankLines="1"/></t>
</list></t>
</section>
-->
<section title="Cost-Context Specification Considerations">
<t>"nominal": Typically residual bandwidth does not have a nominal
value.</t>
<t>"sla": Typically residual bandwidth does not have an "sla"
value.</t>
<!--
<t>"import": There can be multiple sources to import residual bandwidt
h. If the import is from [RFC8571] (by using unidirectional residual bandwidth),
it is RECOMMENDED that "parameters" provides "protocol" as a field and "RFC8571
" as the value. The server should be cognizant of issues when computing end-to-e
nd summary statistics from link statistics. For example, the min of the end-to-e
nd path residual bandwidth is the min of all links on the path.
</t>
-->
<t>"estimation": See the "estimation" entry in Section 4.1.4 on
aggregation of routing protocol link metrics. The current ("cur")
residual bandwidth of a path is the minimal of the residual
bandwidth of all links on the path.</t>
</section> </section>
</section> </section>
<section anchor="bwavailable" numbered="true" toc="default">
<!-- residual bandwidth --> <name>Cost Metric: Available Bandwidth (bw-available)</name>
<section numbered="true" toc="default">
<section title="Cost Metric: Available Bandwidth (bw-available)"> <name>Base Identifier</name>
<!--
<t><list style="hanging">
<t hangText="Metric name:"><vspace blankLines="1"/>Maximum
Reservable Bandwidth<vspace blankLines="1"/></t>
<t hangText="Metric Identifier:">
<vspace blankLines="1"/>maxresbw<vspace blankLines="1"/>
</t>
</list></t>
-->
<section title="Base Identifier">
<t>The base identifier for this performance metric is <t>The base identifier for this performance metric is
"bw-available".</t> "bw-available".</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Value Representation"> <name>Value Representation</name>
<t>The metric value type is a single 'JSONNumber' type value that is <t>The metric value type is a single 'JSONNumber' type value that is
non-negative. The unit of measurement is bytes per second.</t> non-negative. The unit of measurement is bytes per second.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Intended Semantics and Use"> <name>Intended Semantics and Use</name>
<t>Intended Semantics: To specify temporal and spatial available <dl>
<dt>Intended Semantics:</dt><dd><t>To specify temporal and spatial ava
ilable
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 Bandwidth metric as defined in <xref target="RFC8571"/>, <xref target= "RFC8570"/>, and <xref target="RFC7471"/>, but instead
of specifying the available bandwidth for a link, it is the of specifying the available bandwidth for a link, it is the
available bandwidth of the path from the source to the destination. available bandwidth of the path from the source to the destination.
Hence, it is the minimal available bandwidth among all links from Hence, it is the minimal available bandwidth among all links from
the source to the destination.The spatial aggregation unit is the source to the destination. The spatial aggregation unit is
specified in the query context (e.g., PID to PID, or endpoint to specified in the query context (e.g., PID to PID, or endpoint to
endpoint).</t> endpoint).</t>
<t>The default statistical operator for available bandwidth is the <t>The default statistical operator for available bandwidth is the
current instantaneous sample; that is, the default is assumed to be current instantaneous sample; that is, the default is assumed to be
"cur".</t> "cur".</t>
</dd>
<t>Use: This metric could be used either as a cost metric constraint <dt>Use:</dt><dd>This metric could be used as a cost metric constra
attribute or as a returned cost metric in the response.</t> int
attribute or as a returned cost metric in the response.</dd>
<figure> </dl>
<artwork><![CDATA[ <figure anchor="example-8">
Example 8: bw-available value on source-destination endpoint pairs <name>Available Bandwidth Value on Source-Destination Endpoint Pairs
(Example 8)</name>
<sourcecode type="json"><![CDATA[
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": {
"cost-mode": "numerical", "cost-mode": "numerical",
skipping to change at line 1803 skipping to change at line 1298
"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"
] ]
} }
} }
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
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
} }
} }
} }
]]></artwork> ]]></sourcecode></figure>
</figure>
</section> </section>
<section numbered="true" toc="default">
<!-- <name>Cost-Context Specification Considerations</name>
<section title="Measurement Considerations and Parameters"> <dl>
<t><list style="hanging"> <dt>"nominal":</dt><dd>Typically, available bandwidth does not have a
<t hangText="Method of Measurement or Calculation:"><vspace nominal
blankLines="1"/>Maximum Reservable Bandwidth is the bandwidth value.</dd>
measured between two directly connected IS-IS neighbors or OSPF <dt>"sla":</dt><dd>Typically, available bandwidth does not have an SLA
neighbors. See Section 3.5 of [RFC5305] for Measurement value.</dd>
Method.<vspace blankLines="1"/></t> <dt>"estimation":</dt><dd>See the "estimation" entry in <xref target="
ccspec-ow"/>. The current ("cur")
<t
hangText="Measurement Point(s) with Potential Measurement Domain:"><
vspace
blankLines="1"/>See Section 4.1 this document for discussions.<vspac
e
blankLines="1"/></t>
<t hangText="Measurement Timing:"><vspace blankLines="1"/>See
Section 3.5 of [RFC5305] and Section 5 of [RFC7810] for
Measurement Timing.<vspace blankLines="1"/></t>
</list></t>
</section>
-->
<section title="Cost-Context Specification Considerations">
<t>"nominal": Typically available bandwidth does not have a nominal
value.</t>
<t>"sla": Typically available bandwidth does not have an "sla"
value.</t>
<!--
<t>"import": There can be multiple sources to import maximum reservabl
e bandwidth. For example, Maximum reservable bandwidth is defined by IS-IS/OSPF
TE, and
measures the reservable bandwidth between two directly connected IS-IS
neighbors or OSPF
neighbors; see Section 3.5 of [RFC5305]. If the import is from [RFC857
1] (by using unidirectional maximum reservable bandwidth), it is RECOMMENDED tha
t "parameters" provides "protocol" as a field and "RFC8571" as the value.
</t>
-->
<t>"estimation": See the "estimation" entry in Section 4.1.4 on
aggregation of routing protocol link metrics. The current ("cur")
available bandwidth of a path is the minimum of the available available bandwidth of a path is the minimum of the available
bandwidth of all links on the path.</t> bandwidth of all links on the path.</dd>
</dl>
</section> </section>
<!-- cc consider -->
</section> </section>
<!-- end of available bw -->
</section> </section>
<section anchor="secopconsider" numbered="true" toc="default">
<section anchor="secopconsider" title="Operational Considerations"> <name>Operational Considerations</name>
<t>The exact measurement infrastructure, measurement condition, and <t>The exact measurement infrastructure, measurement conditions, and
computation algorithms can vary from different networks, and are outside computation algorithms can vary between different networks and are outside
the scope of this document. Both the ALTO server and the ALTO clients, 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 however, need to be cognizant of the operational issues discussed in the
following sub-sections.</t> following subsections.</t>
<t>Also, the performance metrics specified in this document are similar
<t>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 unless their calculation. Hence, this document specifies issues that the
one metric has its unique challenges.</t> performance metrics might have in common and also discusses challenges
regarding the computation of ALTO performance metrics (<xref target="comp-
<section title="Source Considerations"> consider"/>).</t>
<t>The addition of the "cost-source" field is to solve a key issue: An <section numbered="true" toc="default">
<name>Source Considerations</name>
<t>The addition of the "cost-source" field solves a key issue: an
ALTO server needs data sources to compute the cost metrics described ALTO server needs data sources to compute the cost metrics described
in this document, and an ALTO client needs to know the data sources to in this document, and an ALTO client needs to know the data sources to
better interpret the values.</t> better interpret the values.</t>
<t>To avoid information that is too fine grained, this document introduc
<t>To avoid too fine-grained information, this document introduces es
"cost-source" to indicate only the high-level type of data sources: "cost-source" to indicate only the high-level types of data sources:
"estimation", "nominal" or "lsa", where "estimation" is a type of "estimation", "nominal", or "sla", where "estimation" is a type of
measurement data source, "nominal" is a type of static configuration, measurement data source, "nominal" is a type of static configuration,
and "sla" is a type that is more based on policy.</t> and "sla" is a type that is based more on policy.</t>
<t>For example, for "estimation", the ALTO server may use log servers or
<t>For estimation, for example, the ALTO server may use log servers or the Operations, Administration, and Maintenance (OAM) system as its data
the OAM system as its data source as recommended by <xref source, as recommended by <xref target="RFC7971" format="default"/>. In particu
target="RFC7971"></xref>. In particular, the cost metrics defined in lar, the cost metrics defined in
this document can be computed using routing systems as the data this document can be computed using routing systems as the data
sources.</t> sources.</t>
<!--
Mechanisms defined in [RFC2681], [RFC3393],
[RFC7679], [RFC7680], [RFC3630], [RFC3784], [RFC7471], [RFC7810],
[RFC7752] and [I-D.ietf-idr-te-pm-bgp] that allow an ALTO Server to
retrieve and derive the necessary information to compute the metrics
that we describe in this document.</t>
-->
</section> </section>
<section numbered="true" toc="default">
<section title="Metric Timestamp Consideration "> <name>Metric Timestamp Considerations</name>
<t>Despite the introduction of the additional cost-context <t>Despite the introduction of the additional "cost-context"
information, the metrics do not have a field to indicate the information, the metrics do not have a field to indicate the
timestamps of the data used to compute the metrics. To indicate this timestamps of the data used to compute the metrics. To indicate this
attribute, the ALTO server SHOULD return HTTP "Last-Modified", to attribute, the ALTO server <bcp14>SHOULD</bcp14> return an HTTP Last-Mod ified value to
indicate the freshness of the data used to compute the performance indicate the freshness of the data used to compute the performance
metrics.</t> metrics.</t>
<t>If the ALTO client obtains updates through an incremental update <t>If the ALTO client obtains updates through an incremental update
mechanism <xref target="RFC8895"></xref>, the client SHOULD assume mechanism <xref target="RFC8895" format="default"/>, the client <bcp14>S HOULD</bcp14> assume
that the metric is computed using a snapshot at the time that is that the metric is computed using a snapshot at the time that is
approximated by the receiving time.</t> approximated by the receiving time.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Backward Compatibility Considerations"> <name>Backward-Compatibility Considerations</name>
<t>One potential issue introduced by the optional "cost-source" field <t>One potential issue introduced by the optional "cost-source" field
is backward compatibility. Consider that an IRD which defines two is backward compatibility. Consider the case where an IRD defines two
cost-types with the same "cost-mode" and "cost-metric", but one with "cost-type" entries with the same "cost-mode" and "cost-metric", but one
"cost-source" being "estimation" and the other being "sla". Then an with
"cost-source" being "estimation" and the other being "sla". In such a ca
se, an
ALTO client that is not aware of the extension will not be able to ALTO client that is not aware of the extension will not be able to
distinguish between these two types. A similar issue can arise even distinguish between these two types. A similar issue can arise even
with a single cost-type, whose "cost-source" is "sla": an ALTO client with a single "cost-type" whose "cost-source" is "sla": an ALTO client
that is not aware of this extension will ignore this field and that is not aware of this extension will ignore this field and instead
consider the metric estimation.</t> consider the metric estimation.</t>
<t>To address the backward-compatibility issue, if a "cost-metric" is <t>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 <bcp14>MUST</bcp14> be "estimation"; if it is not, the client <bcp14>SHO ULD</bcp14> reject the
information as invalid.</t> information as invalid.</t>
</section> </section>
<section anchor="comp-consider" numbered="true" toc="default">
<section title="Computation Considerations"> <name>Computation Considerations</name>
<t>The metric values exposed by an ALTO server may result from <t>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 performance
computation of ALTO performance metrics.</t> metrics can present two challenges.</t>
<section numbered="true" toc="default">
<section title="Configuration Parameters Considerations"> <name>Configuration Parameter Considerations</name>
<t>Performance metrics often depend on configuration parameters, and <t>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 information: (1) when the metrics were last computed and (2) when
the metrics will be updated (i.e., the validity period of the the metrics will be updated (i.e., the validity period of the
exposed metric values). The ALTO server can expose these two pieces exposed metric values). The ALTO server can expose these two pieces
of information by using the HTTP response headers Last-Modified and of information by using the HTTP response headers Last-Modified and
Expires.</t> Expires.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Aggregation Computation Considerations"> <name>Aggregation Computation Considerations</name>
<t>An ALTO server may not be able to measure the performance metrics <t>An ALTO server may not be able to measure the performance metrics
to be exposed. The basic issue is that the "source" information can to 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 often
and report only per link loss, not end-to-end loss; similarly, measure
routing protocols report link level available bandwidth, not 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 end-to-end available bandwidth. The ALTO server then needs to
aggregate these data to provide an abstract and unified view that aggregate these data to provide an abstract and unified view that
can be more useful to applications. The server should consider that can be more useful to applications. The server should be aware that
different metrics may use different aggregation computation. For different metrics may use different aggregation computations. For
example, the end-to-end latency of a path is the sum of the latency 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 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 is the minimum of the available bandwidth of the links on the
path; in contrast, aggregating loss values is complicated by the path; in contrast, aggregating loss values is complicated by the
potential for correlated loss events on different links in the potential for correlated loss events on different links in the
path</t> path.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="secsecconsider" numbered="true" toc="default">
<section anchor="secsecconsider" title="Security Considerations"> <name>Security Considerations</name>
<t>The properties defined in this document present no security <t>The properties defined in this document present no security
considerations beyond those in Section 15 of the base ALTO specification considerations beyond those in Section <xref target="RFC7285"
<xref target="RFC7285"></xref>.</t> section="15" sectionFormat="bare"/> of the base ALTO
specification <xref target="RFC7285" format="default"/>.</t>
<t>However, concerns addressed in Sections 15.1, 15.2, and 15.3 of <xref <t>However, concerns addressed in Sections&nbsp;<xref target="RFC7285" sec
target="RFC7285"></xref> remain of utmost importance. Indeed, Traffic tion="15.1" sectionFormat="bare"/>, <xref target="RFC7285" section="15.2" sectio
Engineering (TE) performance is highly sensitive ISP information; nFormat="bare"/>, and <xref target="RFC7285" section="15.3" sectionFormat="bare"
/> of <xref target="RFC7285" format="default"/> remain of utmost importance. Ind
eed,
TE performance is highly sensitive ISP information;
therefore, sharing TE metric values in numerical mode requires full therefore, sharing TE metric values in numerical mode requires full
mutual confidence between the entities managing the ALTO server and the mutual confidence between the entities managing the ALTO server and the
ALTO client. ALTO servers will most likely distribute numerical TE ALTO client. ALTO servers will most likely distribute numerical TE
performance to ALTO clients under strict and formal mutual trust performance to ALTO clients under strict and formal mutual trust
agreements. On the other hand, ALTO clients must be cognizant on the agreements. On the other hand, ALTO clients must be cognizant of the
risks attached to such information that they would have acquired outside risks attached to such information that they would have acquired outside
formal conditions of mutual trust.</t> formal conditions of mutual trust.</t>
<t>To mitigate confidentiality risks during information transport of TE <t>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, through information being leaked to malicious clients or third parties through
attacks such as the person-in-the-middle (PITM) attacks. As specified in such attacks as person-in-the-middle (PITM) attacks. As specified in
"Protection Strategies" (Section 15.3.2 of <xref Section&nbsp;<xref target="RFC7285" section="15.3.2"
target="RFC7285"></xref>), the ALTO Server should authenticate ALTO sectionFormat="bare">"Protection Strategies"</xref> of <xref target="RFC7285"/>,
Clients when transmitting an ALTO information resource containing the ALTO server should authenticate ALTO
sensitive TE performance metrics. "Authentication and Encryption" clients when transmitting an ALTO information resource containing
(Section 8.3.5 of <xref target="RFC7285"></xref>) specifies that "ALTO sensitive TE performance metrics. Section&nbsp;<xref target="RFC7285" sect
Server implementations as well as ALTO Client implementations MUST ion="8.3.5" sectionFormat="bare">"Authentication and Encryption"</xref> of <xref
support the "https" URI scheme of <xref target="RFC7230"></xref> and target="RFC7285"/> specifies that ALTO
Transport Layer Security (TLS) of <xref target="RFC8446"></xref>".</t> server implementations as well as ALTO client implementations <bcp14>MUST<
/bcp14>
support the "https" URI scheme <xref target="RFC9110" format="default"/> a
nd
Transport Layer Security (TLS) <xref target="RFC8446" format="default"/>.<
/t>
</section> </section>
<section anchor="ianaconsider" numbered="true" toc="default">
<section anchor="ianaconsider" title="IANA Considerations"> <name>IANA Considerations</name>
<t>IANA has created and now maintains the "ALTO Cost Metric" registry, <section>
listed in Section 14.2, Table 3 of <xref target="RFC7285"></xref>. This <name>ALTO Cost Metrics Registry</name>
registry is located at <t>IANA created and now maintains the "ALTO Cost Metrics" registry, as
&lt;https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml#cos listed in <xref target="RFC7285" section="14.2" sectionFormat="comma"/>, T
t-metrics&gt;. able 3. This registry is located at
This document requests to add the following entries to the &ldquo;ALTO <eref target="https://www.iana.org/assignments/alto-protocol/" brackets="angle"/
Cost Metric&rdquo; registry.</t> >.
IANA has added the following entries to the "ALTO
<figure> Cost Metrics" registry.</t>
<artwork><![CDATA[ <table>
+-----------------+----------------------------+ <name>ALTO Cost Metrics Registry</name>
| Identifier | Intended Semantics | <thead>
+-----------------+----------------------------+ <tr>
| delay-ow | Section 4.1 of [RFCXXX] | <th>Identifier</th>
| delay-rt | Section 4.2 of [RFCXXX] | <th>Intended Semantics</th>
| delay-variation | Section 4.3 of [RFCXXX] | <th>Reference</th>
| lossrate | Section 4.4 of [RFCXXX] | </tr>
| hopcount | Section 4.5 of [RFCXXX] | </thead>
| tput | Section 5.1 of [RFCXXX] | <tbody>
| bw-residual | Section 5.2 of [RFCXXX] | <tr>
| bw-available | Section 5.3 of [RFCXXX] | <td>delay-ow</td>
+-----------------+----------------------------+ <td>See <xref target="oneway"/></td>
]]></artwork> <td>RFC 9439</td>
</figure> </tr><tr>
<td>delay-rt</td>
<t><list style="symbols"> <td>See <xref target="delayrt"/></td>
<t>[Note to the RFC Editor]: Please replace RFCXXX with the RFC <td>RFC 9439</td>
number assigned to this document.</t> </tr><tr>
</list></t> <td>delay-variation</td>
<td>See <xref target="delayvar"/></td>
<t>This document requests the creation of the "ALTO Cost Source" <td>RFC 9439</td>
registry. This registry serves two purposes. First, it ensures </tr><tr>
<td>lossrate</td>
<td>See <xref target="lossrate"/></td>
<td>RFC 9439</td>
</tr><tr>
<td>hopcount</td>
<td>See <xref target="hopcount"/></td>
<td>RFC 9439</td>
</tr><tr>
<td>tput</td>
<td>See <xref target="tput"/></td>
<td>RFC 9439</td>
</tr><tr>
<td>bw-residual</td>
<td>See <xref target="bwresidual"/></td>
<td>RFC 9439</td>
</tr><tr>
<td>bw-available</td>
<td>See <xref target="bwavailable"/></td>
<td>RFC 9439</td>
</tr>
</tbody>
</table>
</section>
<section>
<name>ALTO Cost Source Types Registry</name>
<t>IANA has created the "ALTO Cost Source Types"
registry. This registry serves two purposes. First, it ensures the
uniqueness of identifiers referring to ALTO cost source types. Second, uniqueness of identifiers referring to ALTO cost source types. Second,
it provides references to particular semantics of allocated cost source it provides references to particular semantics of allocated cost source
types to be applied by both ALTO servers and applications utilizing ALTO types to be applied by both ALTO servers and applications utilizing ALTO
clients.</t> clients.</t>
<t>A new ALTO cost source type can be added after IETF Review <xref target
<t>A new ALTO cost source can be added after IETF Review <xref ="RFC8126" format="default"/>, to ensure that proper documentation regarding
target="RFC8126"></xref>, to ensure that proper documentation regarding the new ALTO cost source type and its security considerations has been
the new ALTO cost source and its security considerations have been provided. The RFC(s) documenting the new cost source type should be detail
provided. The RFC(s) documenting the new cost source should be detailed ed
enough to provide guidance to both ALTO service providers and enough to provide guidance to both ALTO service providers and
applications utilizing ALTO clients as to how values of the registered applications utilizing ALTO clients as to how values of the registered
ALTO cost source should be interpreted. Updates and deletions of ALTO ALTO cost source type should be interpreted. Updates and deletions of ALTO
cost source follow the same procedure.</t> cost source types follow the same procedure.</t>
<t>Registered ALTO address type identifiers <bcp14>MUST</bcp14> conform to
<t>Registered ALTO address type identifiers MUST conform to the the
syntactical requirements specified in Section 3.1. Identifiers are to be syntactical requirements specified in <xref target="meta" sectionFormat="b
are"/>. Identifiers are to be
recorded and displayed as strings.</t> recorded and displayed as strings.</t>
<t>Requests to add a new value to the registry <bcp14>MUST</bcp14> include
<t>Requests to add a new value to the registry MUST include the the
following information: <list style="symbols"> following information: </t>
<t>Identifier: The name of the desired ALTO cost source type.</t> <dl>
<dt>Identifier:</dt><dd>The name of the desired ALTO cost source type.</
<t>Intended Semantics: ALTO cost source type carry with them dd>
<dt>Intended Semantics:</dt><dd> ALTO cost source types carry with them
semantics to guide their usage by ALTO clients. Hence, a document semantics to guide their usage by ALTO clients. Hence, a document
defining a new type should provide guidance to both ALTO service defining a new type should provide guidance to both ALTO service
providers and applications utilizing ALTO clients as to how values providers and applications utilizing ALTO clients as to how values
of the registered ALTO endpoint property should be interpreted.</t> of the registered ALTO endpoint property should be interpreted.</dd>
<dt>Security Considerations:</dt><dd> ALTO cost source types expose
<t>Security Considerations: ALTO cost source types expose
information to ALTO clients. ALTO service providers should be made information to ALTO clients. ALTO service providers should be made
aware of the security ramifications related to the exposure of a aware of the security ramifications related to the exposure of a
cost source type.</t> cost source type.</dd>
</list></t> </dl>
<t>IANA has registered the identifiers
<t>This specification requests registration of the identifiers "nominal", "sla", and "estimation" as listed in the table below.</t>
"nominal", "sla", and "estimation" listed in the table below. Semantics <table>
for the these are documented in Section 3.1, and security considerations <name>ALTO Cost Source Types Registry</name>
are documented in Section 7.</t> <thead>
<tr>
<figure> <th>Identifier</th>
<artwork><![CDATA[ <th>Intended Semantics</th>
+------------+----------------------------------+----------------+ <th>Security Considerations</th>
| Identifier | Intended Semantics | Security | <th>Reference</th>
| | | Considerations | </tr>
+------------+----------------------------------+----------------+ </thead>
| nominal | Values in nominal cases; | Section 7 of | <tbody>
| | Section 3.1 of [RFCXXX] | [RFCXXX] | <tr>
| sla | Values reflecting service level | Section 7 of | <td>nominal</td>
| | agreement; Section 3.1 of | [RFCXXX] | <td>Values in nominal cases (<xref target="meta"/>)</td>
| | [RFCXXXX] | | <td><xref target="secsecconsider"/></td>
| estimation | Values by estimation; | Section 7 of | <td>RFC 9439</td>
| | Section 3.1 of [RFCXXX] | [RFCXXX] | </tr>
+------------+----------------------------------+----------------+ <tr>
]]></artwork> <td>sla</td>
</figure> <td>Values reflecting Service Level Agreement (<xref target="meta"/>
</section> )</td>
<td><xref target="secsecconsider"/></td>
<section title="Acknowledgments"> <td>RFC 9439</td>
<t>The authors of this document would also like to thank Martin Duke for </tr>
the highly informative, thorough AD reviews and comments. We thank <tr>
Christian Ams&uuml;ss, Elwyn Davies, Haizhou Du, Kai Gao, Geng Li, Lili <td>estimation</td>
Liu, Danny Alex Lachos Perez, and Brian Trammell for the reviews and <td>Values by estimation (<xref target="meta"/>)</td>
comments. We thank Benjamin Kaduk, Eric Kline, Francesca Palombini, Lars <td><xref target="secsecconsider"/></td>
Eggert, Martin Vigoureux, Murrary Kucherawy, Roman Danyliw, Zaheduzzaman <td>RFC 9439</td>
Sarker, &Eacute;ric Vyncke for discussions and comments that improve </tr>
this document.</t> </tbody>
</table>
</section>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.corre-quic-throughput-testing" to="QUIC-THROUGHPUT
<!-- -TESTING"/>
<?rfc include="reference.RFC.5234.xml"?> <references>
<name>References</name>
<?rfc include="reference.RFC.4627.xml"?> <references>
<name>Normative References</name>
<?rfc include="reference.RFC.7471.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
9.xml"/>
<?rfc include="reference.RFC.7752.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.363
0.xml"/>
<?rfc include="reference.RFC.7810.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.530
5.xml"/>
<?rfc include="reference.RFC.7680.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.639
0.xml"/>
<?rfc include="reference.RFC.2679.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.728
5.xml"/>
<?rfc include="reference.RFC.2681.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.747
1.xml"/>
<?rfc include="reference.RFC.3393.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.812
6.xml"/>
<?rfc include="reference.RFC.5305.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
4.xml"/>
<?rfc include="reference.RFC.6349.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.825
9.xml"/>
<?rfc include="reference.RFC.7679.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.844
6.xml"/>
<?rfc include="reference.RFC.8571.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.857
0.xml"/>
<?rfc include="reference.I-D.ietf-idr-te-pm-bgp.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.857
1.xml"/>
<?rfc include="reference.I-D.ietf-ippm-initial-registry.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.889
5.xml"/>
<?rfc include="reference.RFC.2818.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.911
0.xml"/>
-->
<!-- requirements words -->
<?rfc include="reference.RFC.2119.xml"?>
<!-- TE for OSPF -->
<?rfc include="reference.RFC.3630.xml"?>
<!-- TE for ISIS -->
<?rfc include="reference.RFC.5305.xml"?>
<!-- guidelines on new metrics -->
<?rfc include="reference.RFC.6390.xml"?>
<!-- https change rfc 2818 to 7230 as 2818 is informational-->
<?rfc include="reference.RFC.7230.xml"?>
<!-- alto base -->
<?rfc include="reference.RFC.7285.xml"?>
<!-- OSPF TE metrics -->
<?rfc include="reference.RFC.7471.xml"?>
<!-- iana -->
<?rfc include="reference.RFC.8126.xml"?>
<!-- requirement words -->
<?rfc include="reference.RFC.8174.xml"?>
<!-- JSON Data-->
<?rfc include="reference.RFC.8259.xml"?>
<!-- TLS 1.3 -->
<?rfc include="reference.RFC.8446.xml"?>
<!-- ISIS TE -->
<?rfc include="reference.RFC.8570.xml"?>
<!-- BGP-LS -->
<?rfc include="reference.RFC.8571.xml"?>
<!-- ALTO SSE -->
<?rfc include="reference.RFC.8895.xml"?>
<reference anchor="IANA-IPPM">
<front>
<title>Performance Metrics Registry,
https://www.iana.org/assignments/performance-metrics/performance-metri
cs.xhtml</title>
<author initials="" surname="IANA"></author>
<date year="" />
</front>
</reference>
<?rfc include="reference.I-D.ietf-tcpm-rfc8312bis.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2330.xml"?>
<!-- IPPM Framework -->
<?rfc include="reference.RFC.2681.xml"?>
<!-- IPPM Round Trip Delay -->
<?rfc include="reference.RFC.3393.xml"?>
<!-- IPPM Packet Delay Variation -->
<?rfc include="reference.RFC.5357.xml"?>
<!-- TWAMP -->
<?rfc include="reference.RFC.7679.xml"?>
<!-- IPPM One Way Delay --> <reference anchor="IANA-IPPM" target="https://www.iana.org/assignments/p
erformance-metrics/">
<front>
<title>Performance Metrics</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<?rfc include="reference.RFC.7971.xml"?> <!-- draft-ietf-tcpm-rfc8312bis (RFC 9438) (AUTH48-DONE) -->
<reference anchor='RFC9438' target='https://www.rfc-editor.org/info/rfc9438'>
<front>
<title>CUBIC for Fast and Long-Distance Networks</title>
<author fullname="Lisong Xu">
</author>
<author fullname="Sangtae Ha">
</author>
<author fullname="Injong Rhee">
</author>
<author fullname="Vidhi Goel">
</author>
<author fullname="Lars Eggert" role="editor">
</author>
<date month="August" year="2023"/>
</front>
<seriesInfo name="RFC" value="9438"/>
<seriesInfo name="DOI" value="10.17487/RFC9438"/>
</reference>
<?rfc include='reference.I-D.corre-quic-throughput-testing'?> </references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.233
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.268
1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.339
3.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.535
7.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.767
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.797
1.xml"/>
<?rfc include='reference.RFC.9000'?> <!-- draft-corre-quic-throughput-testing (Expired) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.corre-quic-throughput-testing.xml"/>
<!-- ALTO requirements --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 000.xml"/>
<reference anchor="G2"> <reference anchor="G2" target="https://dl.acm.org/doi/10.1145/3366707">
<front> <front>
<title>On the Bottleneck Structure of Congestion-Controlled <title>On the Bottleneck Structure of Congestion-Controlled
Networks</title> Networks</title>
<author initials="J" surname="Ros-Giralt"/>
<author initials="A" surname="Bohara"/>
<author initials="S" surname="Yellamraju"/>
<author initials="M" surname="Harper Langston"/>
<author initials="R" surname="Lethin"/>
<author initials="Y" surname="Jiang"/>
<author initials="L" surname="Tassiulas"/>
<author initials="J" surname="Li"/>
<author initials="Y" surname="Tan"/>
<author initials="M" surname="Veeraraghavan"/>
<date month="December" year="2019"/>
</front>
<refcontent>Proceedings of the ACM on Measurement and Analysis of Comp
uting Systems, Vol. 3, No. 3, Article No. 59, pp. 1-31</refcontent>
<seriesInfo name="DOI" value="10.1145/3366707"/>
</reference>
<author initials="J" surname="Ros-Giralt"></author> <reference anchor="FlowDirector" target="">
<front>
<author initials="A" surname="Bohara"></author> <title>Steering Hyper-Giants' Traffic at Scale</title>
<author initials="E" surname="Pujol"/>
<author initials="S" surname="Yellamraju"></author> <author initials="I" surname="Poese"/>
<author initials="J" surname="Zerwas"/>
<author initials="" surname="et. al."></author> <author initials="G" surname="Smaragdakis"/>
<author initials="A" surname="Feldmann"/>
<date year="2020" /> <date month="December" year="2019"/>
</front> </front>
<refcontent>ACM CoNEXT '19</refcontent>
<seriesInfo name="ACM SIGMETRICS" value="2019" /> </reference>
</reference>
<reference anchor="FlowDirector">
<front>
<title>Steering Hyper-Giants' Traffic at Scale</title>
<author initials="E" surname="Pujol"></author>
<author initials="I" surname="Poese"></author>
<author initials="J" surname="Zerwas"></author>
<author initials="G" surname="Smaragdakis"></author>
<author initials="A" surname="Feldmann"></author>
<date year="2020" />
</front>
<seriesInfo name="ACM CoNEXT" value="2020" />
</reference>
<reference anchor="Prometheus">
<front>
<title>Prometheus: A Next-Generation Monitoring System</title>
<author initials="J" surname="Volz"></author>
<author initials="B" surname="Rabenstein"></author>
<date year="2015" />
</front>
</reference>
<reference anchor="Prophet">
<front>
<title>Prophet: Fast, Accurate Throughput Prediction with Reactive
Flows</title>
<author initials="K" surname="Gao"></author>
<author initials="J" surname="Zhang"></author>
<author initials="YR" surname="Yang"></author>
<date year="2020" /> <reference anchor="Prometheus" target="">
</front> <front>
<title>Prometheus: A Next-Generation Monitoring System (Talk)</title
>
<author initials="J" surname="Volz"/>
<author initials="B" surname="Rabenstein"/>
<date month="May" year="2015"/>
</front>
<refcontent>SREcon15 Europe</refcontent>
</reference>
<seriesInfo name="ACM/IEEE Transactions on Networking" value="July" /> <reference anchor="Prophet" target="https://dl.acm.org/doi/10.1109/TNET.
</reference> 2020.3016838">
<front>
<title>Prophet: Toward Fast, Error-Tolerant Model-Based Throughput P
rediction for Reactive Flows in DC Networks</title>
<author initials="J" surname="Zhang"/>
<author initials="K" surname="Gao"/>
<author initials="YR" surname="Yang"/>
<author initials="J" surname="Bi"/>
<date month="December" year="2020"/>
</front>
<refcontent>IEEE/ACM Transactions on Networking, Volume 28, Issue 601,
pp. 2475-2488</refcontent>
</reference>
</references>
</references> </references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors of this document would like to thank <contact fullname="Mar
tin Duke"/> for
the highly informative, thorough AD reviews and comments. We thank <contac
t fullname="Christian Amsüss"/>, <contact fullname="Elwyn Davies"/>, <contact fu
llname="Haizhou Du"/>, <contact fullname="Kai Gao"/>, <contact fullname="Geng Li
"/>, <contact fullname="Lili Liu"/>, <contact fullname="Danny Alex Lachos Perez"
/>, and <contact fullname="Brian Trammell"/> for their reviews and comments. We
thank <contact fullname="Benjamin Kaduk"/>, <contact fullname="Erik Kline"/>, <c
ontact fullname="Francesca Palombini"/>, <contact fullname="Lars Eggert"/>, <con
tact fullname="Martin Vigoureux"/>, <contact fullname="Murray Kucherawy"/>, <con
tact fullname="Roman Danyliw"/>, <contact fullname="Zaheduzzaman Sarker"/>, and
<contact fullname="Éric Vyncke"/> for discussions and comments that improved
this document.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 264 change blocks. 
1599 lines changed or deleted 1111 lines changed or added

This html diff was produced by rfcdiff 1.48.