<?xml version="1.0" encoding="US-ASCII"?> 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)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-alto-performance-metrics-28"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?> number="9439" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.12.2 -->

  <front>
    <title abbrev="ALTO Performance Cost Metrics">ALTO Metrics">Application-Layer Traffic Optimization (ALTO) Performance Cost
    Metrics</title>
    <seriesInfo name="RFC" value="9439"/>
    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>
      <address>
        <postal>
	  <extaddr>Yuhua District</extaddr>
          <street>101 Software Avenue, Yuhua District</street> Avenue</street>
          <city>Nanjing</city>
          <region>Jiangsu</region>
          <code>210012</code>
          <country>China</country>
        </postal>
        <email>bill.wu@huawei.com</email>
      </address>
    </author>
    <author fullname="Y. Richard Yang" initials="Y." surname="Yang">
      <organization>Yale University</organization>
      <address>
        <postal>
          <street>51 Prospect St</street> St.</street>
          <city>New Haven</city>
          <region>CT</region>
          <code>06520</code>
          <country>United States of America</country>
        </postal>
        <email>yry@cs.yale.edu</email>
      </address>
    </author>
    <author fullname="Young Lee" initials="Y." surname="Lee">
      <organization>Samsung</organization>
      <address>
        <email>young.lee@gmail.com</email>
        <email>younglee.tx@gmail.com</email>
      </address>
    </author>
    <author fullname="Dhruv Dhody" initials="D." surname="Dhody">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>Leela Palace</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560008</code>
          <country>India</country>
        </postal>
        <email>dhruv.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Sabine Randriamasy" initials="S." surname="Randriamasy">
      <organization>Nokia Bell Labs</organization> Networks France</organization>
      <address>
        <postal>
          <street>Route de Villejust</street>

          <city>Nozay</city>

          <region></region>

          <code>91460</code>
          <country>France</country>
        </postal>
        <email>sabine.randriamasy@nokia-bell-labs.com</email>
      </address>
    </author>
    <author fullname="Luis Miguel Contreras Murillo" initials="L." surname="Contreras">
      <organization>Telefonica</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Madrid</city>

          <region></region>

          <code></code>
          <region/>
          <code/>
          <country>Spain</country>
        </postal>
        <email>luismiguel.contrerasmurillo@telefonica.com</email>
      </address>
    </author>
    <date year="2022" year="2023" month="August" />

    <area>TSV Area</area>

    <workgroup>ALTO Working Group</workgroup>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>
    <area>tsv</area>
    <workgroup>alto</workgroup>
    <keyword>JavaScript Object Notation, Application-Layer Notation</keyword>
    <keyword>Application-Layer Traffic Optimization</keyword>
    <abstract>
      <t>The cost metric is a basic concept in Application-Layer Traffic
      Optimization (ALTO), and different applications may use different types
      of cost metrics. Since the ALTO base protocol (RFC 7285) defines only a
      single cost metric (namely, the generic "routingcost" metric), if an
      application wants to issue a cost map or an endpoint cost request in
      order to identify a resource provider that offers better performance
      metrics (e.g., lower delay or loss rate), the base protocol does not
      define the cost metric to be used.</t>
      <t>This document addresses this issue by extending the specification to
      provide a variety of network performance metrics, including network
      delay, delay variation (a.k.a, jitter), (a.k.a.&nbsp;jitter), packet loss rate, hop count, and
      bandwidth.</t>
      <t>There are multiple sources (e.g., estimation estimations based on measurements or
      service-level agreement) to derive
      a Service Level Agreement) available for deriving a performance metric. This document
      introduces an additional "cost-context" field to the ALTO "cost-type"
      field to convey the source of a performance metric.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="secintro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Application-Layer Traffic Optimization (ALTO) provides a means for
      network applications to obtain network information so that the
      applications can identify efficient application-layer traffic patterns
      using the networks. Cost metrics are used in both the ALTO cost map
      service and the ALTO endpoint cost service in the ALTO base protocol
      <xref target="RFC7285"></xref>.</t> target="RFC7285" format="default"/>.</t>
      <t>Since different applications may use different cost metrics, the ALTO
      base protocol introduces an ALTO introduced the "ALTO Cost Metric Registry (Section 14.2 of
      <xref target="RFC7285"></xref>) Metrics" registry (<xref target="RFC7285" section="14.2" sectionFormat="of"/>) as a systematic mechanism to allow
      different metrics to be specified. For example, a delay-sensitive
      application may want to use latency related latency-related metrics, and a
      bandwidth-sensitive application may want to use bandwidth related bandwidth-related
      metrics. However, the ALTO base protocol has registered only a single
      cost metric, i.e., the generic "routingcost" metric (Section 14.2 of
      <xref target="RFC7285"></xref>); (<xref target="RFC7285" section="14.2" sectionFormat="of"/>); no latency latency- or bandwidth related bandwidth-related metrics
      are defined in the base protocol.</t>
      <t>This document registers a set of new cost metrics (Table 1) (<xref target="costmetric" sectionFormat="bare"/>) to allow
      applications to determine "where" where to connect based on network
      performance criteria criteria, including delay delay- and bandwidth related bandwidth-related metrics.</t>

      <figure>
        <artwork><![CDATA[
+--------------------+-------------+--------------------------------+
| Metric             | Definition  |  Semantics Based On            |
|                    |

      <table anchor="costmetric">
	<name>Cost Metrics Defined in this doc |                                |
+--------------------+-------------+--------------------------------+
| One-way Delay      | Section 4.1 | Base: [RFC7471,8570,8571]      |
|                    |             | This Document</name>
  <thead>
    <tr>
      <th>Metric</th>
      <th>Definition in This Document</th>
      <th>Semantics Based On</th>
    </tr>
  </thead>
  <tbody>
<tr>
  <td>One-Way Delay</td>
  <td><xref target="oneway" sectionFormat="bare"/></td>
  <td>Base: <xref target="RFC7471"/> <xref target="RFC8570"/> <xref target="RFC8571"/>
  sum of Unidirectional Delay      |
| Round-trip Delay   | Section 4.2 | Base: of links along the path</td>
</tr>
<tr>
<td>Round-Trip Delay</td>
<td><xref target="delayrt" sectionFormat="bare"/></td>
<td>Base: Sum of two directions    |
|                    |             |  from above                    |
| Delay Variation    | Section 4.3 | Base: [RFC7471,8570,8571]      |
|                    |             |  sum of Unidirectional Delay</td>
</tr>
<tr>
  <td>Delay Variation</td>
  <td><xref target="delayvar" sectionFormat="bare"/></td>
  <td>Base: <xref target="RFC7471"/> <xref target="RFC8570"/> <xref target="RFC8571"/>
  Sum of Unidirectional Delay   |
|                    |             | Variation              |
| Loss Rate          | Section 4.4 | Base: [RFC7471,8570,8571]      |
|                    |             | of links along the path</td>
</tr>
<tr>
  <td>Loss Rate</td>
  <td><xref target="lossrate" sectionFormat="bare"/></td>
  <td>Base: <xref target="RFC7471"/> <xref target="RFC8570"/> <xref target="RFC8571"/>
  aggr Unidirectional Link Loss |
| Residual Bandwidth | Section 5.2 | Base: [RFC7471,8570,8571]      |
|                    |             | Loss</td>
</tr>
<tr>
  <td>Residual Bandwidth</td>
  <td><xref target="bwresidual" sectionFormat="bare"/></td>
  <td>Base: <xref target="RFC7471"/> <xref target="RFC8570"/> <xref target="RFC8571"/>
  min Unidirectional Residual BW|
| Available Bandwidth| Section 5.3 | Base: [RFC7471,8570,8571]      |
|                    |             | BW</td>
</tr>
<tr>
  <td>Available Bandwidth</td>
  <td><xref target="bwavailable" sectionFormat="bare"/></td>
  <td>Base: <xref target="RFC7471"/> <xref target="RFC8570"/> <xref target="RFC8571"/>
  min Unidirectional Avail. BW  |
|                    |             |                                |
| TCP Throughput     | Section 5.1 | [I-D.ietf-tcpm-rfc8312bis]     |
|                    |             |                                |
| Hop Count          | Section 4.5 | [RFC7285]                      |
+--------------------+-------------+--------------------------------+
   Table 1. Cost Metrics Defined in this Document.
        ]]></artwork>
      </figure> 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 6 six metrics listed in Table 1 <xref target="costmetric" sectionFormat="bare"/> (i.e., One-way Delay,
      Round-trip Delay, Delay Variation, Loss Rate, Residual Bandwidth, one-way delay,
      round-trip delay, delay variation, loss rate, residual bandwidth, and
      Available Bandwidth)
      available bandwidth) are derived from the set of traffic engineering Traffic Engineering (TE)
      performance metrics commonly defined in OSPF <xref
      target="RFC3630"></xref>, target="RFC3630" format="default"/> <xref target="RFC7471"></xref>; target="RFC7471" format="default"/>, IS-IS <xref
      target="RFC5305"></xref>, target="RFC5305" format="default"/> <xref target="RFC8570"></xref>; target="RFC8570" format="default"/>, and BGP-LS BGP - Link State (BGP-LS)
      <xref target="RFC8571"></xref>. target="RFC8571" format="default"/>. Deriving ALTO cost performance metrics
      from existing network-layer traffic engineering TE performance metrics, and making it exposed to
      expose to application-layer traffic optimization, ALTO, can be a typical
      mechanism used by network operators to deploy ALTO <xref
      target="RFC7971"></xref>, target="RFC7971" format="default"/> <xref target="FlowDirector"></xref>. target="FlowDirector" format="default"/>. This
      document defines the base semantics of these metrics by extending them
      from link metrics to end-to-end metrics for ALTO. The "Semantics Based
      On" column specifies at a high level how the end-to-end metric is metrics are
      computed from link metrics; the details will be specified in the
      following sections.</t>
      <t>The common metrics Min/Max Unidirectional Link Delay metric as defined in
      [RFC8570][RFC8571]
      <xref target="RFC8570"/> and Max Link <xref target="RFC8571"/>, and Maximum (Link) Bandwidth as defined in [RFC3630,RFC5305] <xref target="RFC3630"/> and <xref target="RFC5305"/>,
      are not listed in Table 1 <xref target="costmetric" sectionFormat="bare"/> because they can be handled by applying the
      statistical operators defined in this document. The metrics related with to
      utilized bandwidth and reservable bandwidth (i.e., Max Maximum Reservable BW (Link) Bandwidth and Unreserved BW Bandwidth as defined in [RFC3630,RFC5305]) <xref target="RFC3630"/> and <xref target="RFC5305"/>) are outside the scope of
      this document.</t>
      <t>The 7th seventh metric in <xref target="costmetric"
sectionFormat="bare"/> (the estimated TCP-flow throughput metric) provides an
      estimation of the bandwidth of a TCP flow, using TCP throughput
      modeling, to support use cases of adaptive applications <xref
      target="Prophet"></xref>, target="Prophet" format="default"/> <xref target="G2"></xref>. target="G2" format="default"/>. Note that other
      transport-specific metrics can be defined in the future. For example,
      QUIC-related metrics <xref target="RFC9000"></xref> target="RFC9000" format="default"/> can be considered
      when the methodology to measure for measuring such metrics is more mature (e.g., see <xref
      target="I-D.corre-quic-throughput-testing"></xref>).</t> target="I-D.corre-quic-throughput-testing" format="default"/>).</t>
      <t>The 8th eighth metric in <xref target="costmetric"
sectionFormat="bare"/> (the hop count metric) in Table 1 is mentioned mentioned, but not defined, in the
      ALTO base protocol [RFC7285], but not defined, and <xref target="RFC7285"/>; this document defines
      it to be complete.</t> provides a definition for it.</t>
      <t>These 8 eight performance metrics can be classified into two categories:
      those derived from the performance of individual packets (i.e., One-way
      Delay, Round-trip Delay, Delay Variation, Loss Rate, one-way
      delay, round-trip delay, delay variation, loss rate, and Hop Count), hop count) and
      those related to bandwidth/throughput (Residual (residual bandwidth, available
      bandwidth, and Available
      Bandwidth, and TCP throughput). These two categories are defined in
      Sections <xref
      Sections&nbsp;<xref format="counter" target="secpktmetrics"></xref> target="secpktmetrics"/> and <xref format="counter" target="secbwmetrics"></xref> target="secbwmetrics"/>, respectively. Note that
      all metrics except Round-trip Delay round-trip delay are unidirectional. An ALTO client
      will need to query both directions if needed.</t>
      <t>The purpose of this document is to ensure proper usage of these 8 eight
      performance metrics in the context of ALTO. This document follows the
      guideline
      guidelines defined in Section 14.2 of the ALTO base protocol <xref
      target="RFC7285"></xref> target="RFC7285" sectionFormat="of" section="14.2"/>
on registering ALTO cost metrics. Hence, it
      specifies the identifier, the intended semantics, and the security
      considerations of each one of the metrics specified in Table 1.</t> <xref target="costmetric" sectionFormat="bare"/>.</t>
      <t>The definitions of the intended semantics of the metrics tend to be
      coarse-grained,
      coarse grained and are for guidance only, and they may work well for ALTO. On
      the other hand, a performance measurement framework, such as the IP
      Performance Measurement Metrics (IPPM) framework, may provide more details in for
      defining a performance metric. This document introduces a mechanism
      called "cost-context" to provide additional details, when they are
      available; see <xref target="sec2"></xref>.</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>
     --> target="sec3" format="default"/>.</t>
      <t>Following the ALTO base protocol, this document uses JSON to specify
      the value type of each defined metric. See <xref
      target="RFC8259"></xref> target="RFC8259" format="default"/> for JSON data type specification. specifications. In
      particular, <xref target="RFC7285"></xref> target="RFC7285" format="default"/> specifies that cost values
      should be assumed by default as JSONNumber. to be 'JSONNumber'. When defining the value
      representation of each metric in Table 1, <xref target="costmetric" sectionFormat="bare"/>, this document conforms to
      [RFC7285],
      <xref target="RFC7285"/> but specifies additional, generic constraints on valid
      JSONNumbers for each metric. For example, each new metric in Table 1 <xref target="costmetric" sectionFormat="bare"/>
      will be specified as non-negative (&gt;= 0); Hop Count is specified to
      be an integer.</t>
      <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
      should not be provided to unauthorized ALTO clients. Hence, all cost
      metrics defined in this document are optional; not all of them need to
      be exposed to a given application. When an ALTO server supports a cost
      metric defined in this document, it announces the metric in its
      information resource directory (IRD) as defined in Section 9.2 of <xref
      target="RFC7285"></xref>.</t> target="RFC7285" section="9.2" sectionFormat="of"/>.</t>
      <t>An ALTO server introducing these metrics should consider related
      security issues. As a generic security consideration on the regarding reliability
      and trust in the exposed metric values, applications SHOULD rapidly give
      up <bcp14>SHOULD</bcp14>
      promptly stop using ALTO-based guidance if they detect that the exposed information
      does not preserve their performance level or even degrades it. <xref
      target="secsecconsider"></xref> target="secsecconsider" format="default"/> discusses security considerations in
      more detail.</t>

      <!-- <t>The definitions of a set of cost metrics can allow us to extend the
      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 title="Requirements Language"> numbered="true" toc="default">
      <name>Requirements Language</name>
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC2119"></xref><xref target="RFC8174"></xref> target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="sec2" title="Performance anchor="sec3" numbered="true" toc="default">
      <name>Performance Metric Attributes"> Attributes</name>
      <t>The definitions of the metrics in this document are coarse-grained, coarse grained,
      based on network-layer traffic engineering TE performance metrics, and for
      guidance only. A fine-grained framework as specified in <xref
      target="RFC6390"></xref> target="RFC6390" format="default"/> requires that the fine-grained specification of
      a network performance metric include 6 six components: (i) (1) Metric Name, (ii) (2)
      Metric Description, (iii) (3) Method of Measurement or Calculation, (iv) (4)
      Units of Measurement, (v) (5) Measurement Points, and (vi) (6) Measurement
      Timing. Requiring that an ALTO server provides provide precise, fine-grained
      values for all 6 six components for each metric that it exposes may not be
      feasible or necessary for all ALTO use cases. For example, an ALTO
      server computing its metrics from network-layer traffic-engineering TE
      performance metrics may not have information about the method of
      measurement or calculation (e.g., measured traffic patterns).</t>
      <t>To address the issue and realize ALTO use cases, cases for the metrics listed in Table
      1, <xref target="costmetric" sectionFormat="bare"/>, this document defines performance metric identifiers which that can be
      used in the ALTO protocol Protocol with the following well-defined (i) items: (1) Metric Name, (ii) (2) Metric
      Description, (iv) (3) Units of Measurement, and (v) (4) Measurement Points,
      which are always specified by the specific ALTO services; for example,
      the endpoint cost service is between the two endpoints. Hence, the ALTO
      performance metric identifiers provide basic metric attributes.</t>
      <t>To allow the flexibility of allowing an ALTO server to provide
      fine-grained information such as Method of Measurement or Calculation, Calculation
      according to its policy and use cases, this document introduces context
      information so that the server can provide these additional details.</t>
      <section anchor="meta"
               title="Performance numbered="true" toc="default">
        <name>Performance Metric Context: &quot;cost-context&quot;"> "cost-context"</name>
        <t>The core additional details of a performance metric specify "how" how
        the metric is obtained. This is referred to as the source of the
        metric. Specifically, this document defines three types of
        coarse-grained metric information sources: "nominal", and "sla"
        (service level agreement), "sla", and "estimation".</t>
        <t>For a given type of source, precise interpretation of a performance
        metric value can depend on specific measurement and computation
        parameters.</t>
        <t>To make it possible to specify the source and the aforementioned
        parameters, this document introduces an optional "cost-context" field
        to the "cost-type" field defined by the ALTO base protocol (Section
        10.7 of <xref target="RFC7285"></xref>) (<xref target="RFC7285" section="10.7" sectionFormat="of"/>) as the following:</t>

        <figure>
          <artwork><![CDATA[ follows:</t>
        <sourcecode type="json"><![CDATA[    object {
      CostMetric   cost-metric;
      CostMode     cost-mode;
      [CostContext cost-context;]
      [JSONString  description;]
    } CostType;

    object {
      JSONString    cost-source;
      [JSONValue    parameters;]
    } CostContext;
    ]]></artwork>
        </figure>
]]></sourcecode>
        <t>"cost-context" will not be used as a key to distinguish among
        performance metrics. Hence, an ALTO information resource MUST NOT <bcp14>MUST NOT</bcp14>
        announce multiple CostType entries with the same "cost-metric", "cost-mode" "cost-mode",
        and "cost-context". They must be placed into different information
        resources.</t>
        <t>The "cost-source" field of the "cost-context" field is defined as a
        string consisting of only US-ASCII ASCII alphanumeric characters
        (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A). The cost-source "cost-source" field is
        used in this document to indicate a string of this format.</t>
        <t>As mentioned above, this document defines three values for
        "cost-source": "nominal", "sla", and "estimation". The "cost-source"
        field of the "cost-context" field MUST <bcp14>MUST</bcp14> be one that is registered in the "ALTO Cost
        Source"
        Source Types" registry (Section 8).</t> (<xref target="ianaconsider"/>).</t>
        <t>The "nominal" category indicates that the metric value is
        statically configured by the underlying devices. Not all metrics have
        reasonable "nominal" values. For example, throughput can have a
        nominal value, which indicates the configured transmission rate of the
        involved devices; latency typically does not have a nominal value.</t>
        <t>The "sla" category indicates that the metric value is derived from
        some commitment commitment, which this document refers to as service-level
        agreement a Service Level Agreement (SLA). Some operators also use terms such as "target" or
        "committed" values. For an "sla" metric, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the
        "parameters" field provide a link to the SLA definition.</t>
        <t>The "estimation" category indicates that the metric value is
        computed through an estimation process. An ALTO server may compute
        "estimation" values by retrieving and/or aggregating information from
        routing protocols (e.g., see <xref target="RFC7471"></xref>, target="RFC7471" format="default"/>, <xref
        target="RFC8570"></xref>, target="RFC8570" format="default"/>, and <xref target="RFC8571"></xref>), target="RFC8571" format="default"/>), traffic
        measurement management tools (e.g., TWAMP the Two-Way Active Measurement Protocol (TWAMP) <xref
        target="RFC5357"></xref>), target="RFC5357" format="default"/>), and measurement frameworks (e.g., IPPM),
        with corresponding operational issues. An illustration of potential
        information flows used for estimating these metrics is shown in Figure
        1. <xref target="secopconsider"></xref> target="fig1"/>. <xref target="secopconsider" format="default"/> discusses in more detail the
        operational issues and how a network may address them. <figure>
            <artwork><![CDATA[ </t>
	<figure anchor="fig1">
	  <name>A Framework to Compute Estimation of Performance Metrics</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  +--------+   +--------+  +--------+
  | Client |   | Client |  | Client |
  +----^---+   +---^----+  +---^----+
       |           |           |
       +-----------|-----------+
      North-Bound
                   |ALTO protocol
    Interface (NBI)| Protocol
                   |
                   |
                +--+-----+  retrieval      +-----------+
                |  ALTO  |<----------------| Routing   |
                | Server |  and aggregation| Protocols |
                |        |<-------------+  | Protocols           |
                +--------+              |  +-----------+
                                        |
                                        |  +------------+
                                        |  |Performance |
                                        ---| Monitoring |
                                           |  Tools     |
                                           +------------+
Figure 1. A framework to compute estimation to performance metrics
]]></artwork>
          </figure></t>

        <!--
      <t>
      A particular type of "estimation" is direct "import", which indicates that the metric value is imported directly from a specific existing protocol or system. Specifying "import" as the source instead of the more generic "estimation" may allow better tracking of information flow. For an "import" metric, it is RECOMMENDED that the "parameters" field provides details to the system from which raw data is imported.
      In particular, one may notice that the set of end-to-end metrics defined in 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 "import" to indicate that
        its end-to-end metrics are computed from link
        metrics imported from [RFC8571].
      </t>
    -->
	</figure>
        <t>There can be multiple choices in deciding options available when choosing the cost-source category.
        It is "cost-source" category; the operator of an ALTO server who chooses the category. will make that choice. If a
        metric does not include a "cost-source" value, the application MUST <bcp14>MUST</bcp14>
        assume that the value of "cost-source" is the most generic source,
        i.e., "estimation".</t>
      </section>
      <section anchor="percentile" title="Performance numbered="true" toc="default">
        <name>Performance Metric Statistics"> Statistics</name>
        <t>The measurement of a performance metric often yields a set of
        samples from an observation distribution (<xref
        target="Prometheus"></xref>), <xref target="Prometheus" format="default"/>, instead of a single value. A statistical
        operator is applied to the samples to obtain a value to be reported to
        the client. Multiple statistical operators (e.g., min, median, and
        max) are commonly being used.</t>
        <t>Hence, this document extends the general US-ASCII ASCII alphanumeric cost
        metric strings, formally specified as the CostMetric type defined in
        Section 10.6 of [RFC7285],
        <xref target="RFC7285" sectionFormat="of" section="10.6"/>, as follows:</t>

        <t><list style="hanging">
            <t>A
          <t indent="3">A cost metric string consists of a base metric identifier (or
            base identifier for short) string, followed by an optional
            statistical operator string, connected by the ASCII character
            colon character (':', U+003A), if the statistical operator string exists.
            The total length of the cost metric string MUST NOT <bcp14>MUST NOT</bcp14> exceed 32, as
            required by [RFC7285].</t>
          </list></t>

        <!--
      </t>
      <figure>
        <artwork>
          <![CDATA[
  <metric-identifier> ::= <metric-base-identifier> [ '-' <stat> ]
          ]]>
        </artwork>
      </figure>
      <t>where &lt;stat&gt; MUST be one of the following: </t>
      --> <xref target="RFC7285"/>.</t>
        <t>The statistical operator string MUST <bcp14>MUST</bcp14> be one of the following:</t>

        <t><list style="hanging">
            <t hangText="cur:"><vspace blankLines="1" /> the
        <dl>
          <dt>cur:</dt>
          <dd>The instantaneous
            observation value of the metric from the most recent sample (i.e.,
            the current value). <vspace blankLines="1" /></t>

            <t
            hangText="percentile, value).</dd>
          <dt>percentile, with the letter 'p' followed by a number:"><vspace
            blankLines="1" /> gives number:</dt>
          <dd>Gives the percentile specified by the number
            following the letter 'p'. The number MUST <bcp14>MUST</bcp14> be a non-negative JSON
            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,
            if a higher precision is needed. The decimal part should start
            with the '.' separator (U+002E), (U+002E) and be followed by a sequence of one
            or more ASCII numbers between '0' and '9'. Assume that this number is y y,
            and consider the case where the samples are coming from a random variable X. Then the The
            metric then returns x, such that the probability of X is less than or
            equal to x, i.e., Prob(X &lt;= x), = y/100. For example,
            delay-ow:p99 gives the 99% 99th percentile of observed one-way delay;
            delay-ow:p99.9 gives the 99.9% 99.9th percentile. Note that some systems
            use quantile, which is in the range [0, 1]. When there is a more
            common form for a given percentile, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the
            common form be used; that is, instead of p0, use min; instead of
            p50, use median; instead of p100, use max. <vspace
            blankLines="1" /></t>

            <t hangText="min:"><vspace blankLines="1" /> the max.</dd>
          <dt>min:</dt>
          <dd>The minimal value of
            the observations. <vspace blankLines="1" /></t>

            <t hangText="max:"><vspace blankLines="1" /> the observations.</dd>
          <dt>max:</dt>
          <dd>The maximal value of
            the observations. <vspace blankLines="1" /></t>

            <t hangText="median:"><vspace blankLines="1" /> the mid-point observations.</dd>
          <dt>median:</dt>
          <dd>The midpoint
            (i.e., p50) of the observations. <vspace blankLines="1" /></t>

            <t hangText="mean:"><vspace blankLines="1" /> the observations.</dd>
          <dt>mean:</dt>
          <dd>The arithmetic mean
            value of the observations. <vspace blankLines="1" /></t>

            <t hangText="stddev:"><vspace blankLines="1" /> the observations.</dd>
          <dt>stddev:</dt>
          <dd>The standard
            deviation of the observations. <vspace blankLines="1" /></t>

            <t hangText="stdvar:"><vspace blankLines="1" /> the observations.</dd>
          <dt>stdvar:</dt>
          <dd>The standard
            variance of the observations. <vspace blankLines="1" /></t>
          </list></t> observations.</dd>
        </dl>
        <t>Examples of cost metric strings then include "delay-ow",
        "delay-ow:min", and "delay-ow:p99", where "delay-ow" is the base metric
        identifier string; "min" and "p99" are example statistical operator
        strings.</t>
        <t>If a cost metric string does not have the optional statistical
        operator string, the statistical operator SHOULD <bcp14>SHOULD</bcp14> be interpreted as the
        default statistical operator in the definition of the base metric. If
        the definition of the base metric does not provide a definition for
        the default statistical operator, the metric MUST <bcp14>MUST</bcp14> be considered as the
        median value.</t>
        <t>Note that RFC 7258 <xref target="RFC7285"/> limits the overall cost metric identifier to 32
        characters. The cost metric variants with statistical operator
        suffixes defined by this document are also subject to the same overall
        32-character limit, so certain combinations of (long) base metric
        identifier
        identifiers and statistical operator operators will not be representable. If such
        a situation arises, it could be addressed by defining a new base
        metric identifier that is an "alias" of the desired base metric, with
        identical semantics and just a shorter name.</t>
      </section>
    </section>

    <!-- End of metric attributes -->
    <section anchor="secpktmetrics" title="Packet numbered="true" toc="default">
      <name>Packet Performance Metrics "> Metrics</name>
      <t>This section introduces ALTO network performance metrics on one way one-way
      delay, round-trip delay, delay variation, packet loss rate, and hop
      count. They measure the "quality of experience" of the stream of packets
      sent from a resource provider to a resource consumer. The measures measurements of
      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
      network (pkt.delay); (pkt.delay), whether the packet is dropped before reaching the
      destination (pkt.dropped); (pkt.dropped), and the number of network hops that the packet
      traverses (pkt.hopcount). The semantics of the performance metrics
      defined in this section are that they are statistics computed from these
      measures;
      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
      stream.</t>
      <section title="Cost anchor="oneway" numbered="true" toc="default">
        <name>Cost Metric: One-Way Delay (delay-ow)"> (delay-ow)</name>
        <section title="Base Identifier"> numbered="true" toc="default">
          <name>Base Identifier</name>
          <t>The base identifier for this performance metric is
          "delay-ow".</t>
        </section>
        <section title="Value Representation"> numbered="true" toc="default">
          <name>Value Representation</name>
          <t>The metric value type is a single 'JSONNumber' type value
          conforming to the number specification of Section 6 of [RFC8259]. specifications provided in <xref target="RFC8259" sectionFormat="of" section="6"/>.
          The unit is expressed in microseconds. Hence, the number can be a
          floating point
          floating-point number to express delay that is smaller than
          microseconds. The number MUST <bcp14>MUST</bcp14> be non-negative.</t>
        </section>

        <!--
        <t><list style="hanging">
            <t hangText="Metric name:">
              <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 numbered="true" toc="default">
          <name>Intended Semantics and Use">
          <t>Intended Semantics: To Use</name>
      <dl>
          <dt>Intended Semantics:</dt><dd>To specify the temporal and spatial
          aggregated delay of a stream of packets from the specified source to
          the specified destination. The base semantics of the metric is the
          Unidirectional Delay metric as defined in [RFC8571,RFC8570,RFC7471], <xref target="RFC8571"/>, <xref target="RFC8570"/>, and <xref target="RFC7471"/>,
          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
          non-normative reference definition of the end-to-end one-way delay metric is provided in
          <xref target="RFC7679"></xref>. target="RFC7679" format="default"/>. The spatial aggregation level is
          specified in the query context, e.g., provider-defined identifier
          (PID) to PID, or endpoint to endpoint, where the PID is as defined in
          Section 5.1 of [RFC7285].</t>

          <t>Use: This
          <xref target="RFC7285" sectionFormat="of" section="5.1"/>.</dd>
          <dt>Use:</dt>
          <dd>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 1: Delay value response.</dd>
      </dl>
      <figure anchor="example-1">
        <name>Delay Value on source-destination endpoint pairs Source-Destination Endpoint Pairs (Example 1)</name>
          <sourcecode type="json"><![CDATA[
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 239
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "delay-ow"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}
]]></artwork>
          </figure>

          <figure>
            <artwork><![CDATA[

HTTP/1.1 200 OK
Content-Length: 247
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "delay-ow"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    10,
      "ipv4:198.51.100.34": 20
    }
  }
}
]]></artwork>
]]></sourcecode>
      </figure>
          <t>Note that since the "cost-type" does not include the
          "cost-source" field, the values are based on "estimation". Since the
          identifier does not include the statistical operator string
          component, the values will represent median values.</t>

          <t>Example 1a below
          <t><xref target="example-1a"/> shows an example that is similar to Example 1, 1 (<xref target="example-1"/>), but for IPv6.</t>

          <figure>
            <artwork><![CDATA[Example 1a: Delay value
      <figure anchor="example-1a">
        <name>Delay Value on source-destination endpoint pairs Source-Destination Endpoint Pairs for IPv6 (Example 1a)</name>
          <sourcecode type="json"><![CDATA[
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 252
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "delay-ow"
  },
  "endpoints": {
    "srcs": [
      "ipv6:2001:db8:100::1"
    ],
    "dsts": [
      "ipv6:2001:db8:100::2",
      "ipv6:2001:db8:100::3"
    ]
  }
}
]]></artwork>
          </figure>

          <figure>
            <artwork><![CDATA[

HTTP/1.1 200 OK
Content-Length: 257
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "delay-ow"
    }
  },
  "endpoint-cost-map": {
    "ipv6:2001:db8:100::1": {
      "ipv6:2001:db8:100::2": 10,
      "ipv6:2001:db8:100::3": 20
    }
  }
}
]]></artwork>
]]></sourcecode>
      </figure>
        </section>
        <section anchor="ccspec-ow"
                 title="Cost-Context numbered="true" toc="default">
          <name>Cost-Context Specification Considerations">
          <t>"nominal": Typically Considerations</name>
	  <dl>
          <dt>"nominal":</dt><dd>Typically, network one-way delay does not have a
          nominal value.</t>

          <t>"sla": Many value.</dd>
          <dt>"sla":</dt><dd>Many networks provide delay-related parameters in their
          application-level SLAs. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the "parameters"
          field of an "sla" one-way delay metric include a link (i.e., a field
          named "link") providing an a URI to for the specification of SLA details,
          if available. Such a specification can be either free (1)&nbsp;free text for
          possible presentation to the user, user or a (2)&nbsp;a formal specification. The
          format of the specification is out of outside the scope of this
          document.</t>

          <!--
          <t>"import": There can be multiple sources to import one-way delay. For example, if the import is from [RFC8571] (by using unidirectional link delay, min/max unidirectional link delay), it is RECOMMENDED that "parameters" provides "protocol" as a field and "RFC8571" as the value. During import, the server should be cognizant of potential issues when computing an end-to-end summary statistic from link statistics. Another example of an import source is the IPPM framework. For IPPM, it is RECOMMENDED that "parameters" provides "protocol" 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": The
          document.</dd>
          <dt>"estimation":</dt><dd>The exact estimation method is out of outside the scope of
          this document. There can be multiple sources to estimate for estimating one-way
          delay. For example, the ALTO server may estimate the end-to-end
          delay by aggregation of routing protocol link metrics; the server
          may also estimate the delay using active, end-to-end measurements, measurements --
          for example, using the IPPM framework <xref
          target="RFC2330"></xref>.</t> target="RFC2330" format="default"/>.</dd>
	  </dl>
          <t>If the estimation is computed by aggregation of routing protocol
          link metrics (e.g., Unidirectional Link Delay metrics for OSPF <xref target="RFC7471"></xref>, target="RFC7471" format="default"/>, IS-IS <xref
          target="RFC8570"></xref>, target="RFC8570" format="default"/>, or BGP-LS <xref target="RFC8571"></xref>)
          Unidirectional Delay link metrics, target="RFC8571" format="default"/>), it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the
          "parameters" field of an "estimation" one-way delay metric include
          the following information: (1) the RFC defining the routing protocol
          metrics (e.g., https://www.rfc-editor.org/info/rfc7471 see <xref target="RFC7471"/> for RFC7471
          derived metrics); metrics), (2) configurations of the routing link metrics
          such as configured intervals; intervals, and (3) the aggregation method from
          link metrics to end-to-end metrics. During aggregation from link
          metrics to the end-to-end metric, metrics, the server should be cognizant of
          potential issues when computing an end-to-end summary statistic from
          link statistics. The default end-to-end average one-way delay is the
          sum of average link one-way delays. If an ALTO server provides the
          min and max statistical operators for the one-way delay metric, the
          values can be computed directly from the routing link metrics, as
          [RFC7471,RFC8570,RFC8571]
          <xref target="RFC7471"/>, <xref target="RFC8570"/>, and <xref target="RFC8571"/> provide Min/Max Unidirectional Link
          Delay.</t>
          <t>If the estimation is from the IPPM measurement framework, it is
          RECOMMEDED
          <bcp14>RECOMMENDED</bcp14> that the "parameters" field of an "estimation" one-way
          delay metric includes the following information: include the URI to in the URI "URI"
          field of the IPPM metric defined in the IPPM performance metric
          <xref target="IANA-IPPM"></xref> "Performance Metrics" registry
          <xref target="IANA-IPPM" format="default"/> (e.g.,
          https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_95Percentile).
<eref target="https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_95Percentile" brackets="angle"/>).
          The IPPM metric MUST <bcp14>MUST</bcp14> be one-way delay (i.e., IPPM OWDelay* metrics).
          The statistical operator of the ALTO metric MUST <bcp14>MUST</bcp14> be consistent with
          the IPPM statistical property (e.g., 95-th 95th percentile).</t>

          <!--
          <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 sources.<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 measurement
              timing considerations.<vspace blankLines="1"/></t>
          </list></t>
          -->
        </section>
      </section>
      <section title="Cost anchor="delayrt" numbered="true" toc="default">
        <name>Cost Metric: Round-trip Round-Trip Delay (delay-rt)"> (delay-rt)</name>
        <section title="Base Identifier"> numbered="true" toc="default">
          <name>Base Identifier</name>
          <t>The base identifier for this performance metric is
          "delay-rt".</t>
        </section>
        <section title="Value Representation"> numbered="true" toc="default">
          <name>Value Representation</name>
          <t>The metric value type is a single 'JSONNumber' type value
          conforming to the number specification of Section 6 of [RFC8259]. specifications provided in <xref target="RFC8259" sectionFormat="of" section="6"/>.
          The number MUST <bcp14>MUST</bcp14> be non-negative. The unit is expressed in
          microseconds.</t>
        </section>

        <!--
        <t><list style="hanging">
            <t hangText="Metric name:">
              <vspace blankLines="1"/>Round Trip Time<vspace blankLines="1"/>
            </t>

           <t hangText="Metric Identifier:">
              <vspace blankLines="1"/>rtt<vspace blankLines="1"/>
            </t>
        </list></t>
        -->
        <section title="Intended numbered="true" toc="default">
          <name>Intended Semantics and Use">
          <t>Intended Semantics: To Use</name>
      <dl>
          <dt>Intended Semantics:</dt><dd><t>To specify temporal and spatial aggregated
          round-trip delay between the specified source and specified
          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
          the destination back to the source, where the one-way delay is as
          defined in Section 4.1. <xref target="oneway"/>. A non-normative reference definition of the
          end-to-end round-trip delay metric is provided in <xref target="RFC2681"></xref>. target="RFC2681" format="default"/>. The
          spatial aggregation level is specified in the query context (e.g.,
          PID to PID, or endpoint to endpoint).</t>
          <t>Note that it is possible for a client to query two one-way delays delay
          (delay-ow) items and then compute the round-trip delay. The server should
          be cognizant of the consistency of values.</t>

          <t>Use: This values.</t></dd>
          <dt>Use:</dt>
          <dd>This metric could be used either as a cost metric constraint
          attribute or as a returned cost metric in the response.</t>

          <figure>
            <artwork><![CDATA[
Example 2: Round-trip response.</dd>
      </dl>
     <figure anchor="example-2">
       <name>Round-Trip Delay of source-destination endpoint pairs Source-Destination Endpoint Pairs (Example 2)</name>
          <sourcecode type="json"><![CDATA[
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "delay-rt"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}
]]></artwork>
          </figure>

          <figure>
            <artwork><![CDATA[

HTTP/1.1 200 OK
Content-Length: 245
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "delay-rt"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    4,
      "ipv4:198.51.100.34": 3
    }
  }
}

]]></artwork>
]]></sourcecode>
     </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 considerations and parameters which may be specified in "parameters". Note that the "parameters" field is an optional field providing non-normative information.
          </t>
        </section>
        -->

        <section title="Cost-Context numbered="true" toc="default">
          <name>Cost-Context Specification Considerations">
          <t>"nominal": Typically Considerations</name>
        <dl>
          <dt>"nominal":</dt><dd>Typically, network round-trip delay does not have a
          nominal value.</t>

          <t>"sla": See value.</dd>
          <dt>"sla":</dt><dd>See the "sla" entry in <xref
          target="ccspec-ow"></xref>.</t>

          <!--
          <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 unidirectional link delay), it is RECOMMENDED that "parameters" provides "protocol" as a field and "RFC8571" as the value; see <xref target="ccspec-ow" /> for discussions 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 "protocol" 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 format="default"/>.</dd>
          <dt>"estimation":</dt><dd>See the "estimation" entry in <xref
          target="ccspec-ow"></xref>. target="ccspec-ow" format="default"/>. For estimation by aggregation of routing
          protocol link metrics, the aggregation should include all links from
          the source to the destination and then back to the source; for
          estimation using IPPM, the IPPM metric MUST <bcp14>MUST</bcp14> be round-trip delay
          (i.e., IPPM RTDelay* metrics). The statistical operator of the ALTO
          metric MUST <bcp14>MUST</bcp14> be consistent with the IPPM statistical property (e.g.,
          95-th percentile).</t>

          <!--
          <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 sources.<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 measurement
              timing considerations.<vspace blankLines="1"/></t>
          </list></t>
          -->
          95th percentile).</dd>
	</dl>
        </section>
      </section>
      <section title="Cost anchor="delayvar" numbered="true" toc="default">
        <name>Cost Metric: Delay Variation (delay-variation)">
        <!--
        <t><list style="hanging">
            <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>
        --> (delay-variation)</name>
        <section title="Base Identifier"> numbered="true" toc="default">
          <name>Base Identifier</name>
          <t>The base identifier for this performance metric is
          "delay-variation".</t>
        </section>
        <section title="Value Representation"> numbered="true" toc="default">
          <name>Value Representation</name>
          <t>The metric value type is a single 'JSONNumber' type value
          conforming to the number specification of Section 6 of [RFC8259]. specifications provided in <xref target="RFC8259" sectionFormat="of" section="6"/>.
          The number MUST <bcp14>MUST</bcp14> be non-negative. The unit is expressed in
          microseconds.</t>
        </section>
        <section title="Intended numbered="true" toc="default">
          <name>Intended Semantics and Use">
          <t>Intended Semantics: To Use</name>
	  <dl>
          <dt>Intended Semantics:</dt><dd><t>To specify temporal and spatial aggregated
          delay variation (also called delay jitter)) jitter) with respect to the
          minimum delay observed on the stream over the one-way delay from the
          specified source and destination, where the one-way delay is as defined
          in Section 4.1. <xref target="oneway"/>. A non-normative reference definition of the end-to-end
          one-way delay variation metric is provided in <xref target="RFC3393"></xref>. target="RFC3393" format="default"/>. Note that
          <xref target="RFC3393"></xref> target="RFC3393" format="default"/> allows the specification of a generic
          selection function F to unambiguously define the two packets
          selected to compute delay variations. This document defines the
          specific case that where F selects as the "first" packet the one with the smallest one-way delay.
          delay as the "first" packet. The spatial aggregation level is specified
          in the query context (e.g., PID to PID, or endpoint to
          endpoint).</t>
          <t>Note that in statistics, variations are variation is typically evaluated by
          the distance from samples relative to the mean. In networking
          context, the context of networking, it is more commonly defined from samples relative to the
          min. This definition follows the networking convention.</t>

          <t>Use: This
</dd>
	      <dt>Use:</dt>
              <dd>This metric could be used either as a cost metric constraint
              attribute or as a returned cost metric in the response.</t>

          <figure>
            <artwork><![CDATA[Example 3: Delay variation value response.</dd>
	    </dl>
          <figure anchor="example-3">
           <name>Delay Variation Value on source-destination endpoint pairs Source-Destination Endpoint Pairs (Example 3)</name>
          <sourcecode type="json"><![CDATA[
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 245
Content-Type: application/alto-endpointcostparams+json
Accept:
   application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "delay-variation"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}

HTTP/1.1 200 OK
Content-Length: 252
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "delay-variation"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    0,
      "ipv4:198.51.100.34": 1
    }
  }
}
]]></artwork>
]]></sourcecode>
	  </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.<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 sources.<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 considerations and parameters which may be specified in "parameters". Note that the "parameters" field is an optional field providing non-normative information.
          </t>
        </section>
        -->
        <section title="Cost-Context numbered="true" toc="default">
          <name>Cost-Context Specification Considerations">
          <t>"nominal": Typically Considerations</name>
          <dl>
          <dt>"nominal":</dt><dd>Typically, network delay variation does not have a
          nominal value.</t>

          <t>"sla": See value.</dd>
          <dt>"sla":</dt><dd>See the "sla" entry in <xref
          target="ccspec-ow"></xref>.</t>

          <!--
          <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 the value; see <xref target="ccspec-ow" /> for discussions 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 "protocol" 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 format="default"/>.</dd>
          <dt>"estimation":</dt><dd>See the "estimation" entry in <xref
          target="ccspec-ow"></xref>. target="ccspec-ow" format="default"/>. For estimation by aggregation of routing
          protocol link metrics, the default aggregation of the average of
          delay variations is the sum of the link delay variations; for
          estimation using IPPM, the IPPM metric MUST <bcp14>MUST</bcp14> be delay variation
          (i.e., IPPM OWPDV* metrics). The statistical operator of the ALTO
          metric MUST <bcp14>MUST</bcp14> be consistent with the IPPM statistical property (e.g.,
          95-th percentile).</t>

          <!--
          <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 sources.<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 measurement
              timing considerations.<vspace blankLines="1"/></t>
          </list></t>
          -->
          95th percentile).</dd>
	  </dl>
        </section>
      </section>
      <section title="Cost anchor="lossrate" numbered="true" toc="default">
        <name>Cost Metric: Loss Rate (lossrate)">
        <!--
        <t><list style="hanging">
            <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>
        --> (lossrate)</name>
        <section title="Base Identifier"> numbered="true" toc="default">
          <name>Base Identifier</name>
          <t>The base identifier for this performance metric is
          "lossrate".</t>
        </section>
        <section title="Value Representation"> numbered="true" toc="default">
          <name>Value Representation</name>
          <t>The metric value type is a single 'JSONNumber' type value
          conforming to the number specification of Section 6 of [RFC8259]. specifications provided in <xref target="RFC8259" sectionFormat="of" section="6"/>.
          The number MUST <bcp14>MUST</bcp14> be non-negative. The value represents the percentage
          of packet losses.</t>
        </section>
        <section title="Intended numbered="true" toc="default">
          <name>Intended Semantics and Use">
          <t>Intended Semantics: To Use</name>
	  <dl>
          <dt>Intended Semantics:</dt><dd>To specify the temporal and spatial aggregated
          one-way packet loss rate from the specified source and the specified
          destination. The base semantics of the metric is the Unidirectional
          Link Loss metric as defined in [RFC8571,RFC8570,RFC7471], <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
          links from the source to the destination. The spatial aggregation
          level is specified in the query context (e.g., PID to PID, or
          endpoint to endpoint).</t>

          <t>Use: This endpoint).</dd>
    <dt>Use:</dt>
     <dd>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: Loss rate value response.</dd>
	    </dl>
          <figure anchor="example-4">
           <name>Loss Rate Value on source-destination endpoint pairs Source-Destination Endpoint Pairs (Example 4)</name>
          <sourcecode type="json"><![CDATA[
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "lossrate"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}
]]></artwork>
          </figure>

          <figure>
            <artwork><![CDATA[

HTTP/1.1 200 OK
Content-Length: 248
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "lossrate"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    0,
      "ipv4:198.51.100.34": 0.01
    }
  }
}
]]></artwork>
          </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 considerations and parameters which may be specified in "parameters". Note that the "parameters" field is an optional field providing non-normative information.</t>
]]></sourcecode></figure>
        </section>
        -->
        <section title="Cost-Context numbered="true" toc="default">
          <name>Cost-Context Specification Considerations">
          <t>"nominal": Typically Considerations</name>
	  <dl>
            <dt>"nominal":</dt>
	    <dd>Typically, the packet loss rate does not have a nominal
          value, although some networks may specify zero losses.</t>

          <t>"sla": See losses.</dd>
          <dt>"sla":</dt>
	  <dd>See the "sla" entry in <xref
          target="ccspec-ow"></xref>..</t>

          <!--
          <t>"import": There can be multiple sources to import packet loss rate. If the import is from [RFC8571] (by using unidirectional link loss), it is RECOMMENDED that "parameters" provides "protocol" as a field and "RFC8571" as the value; see <xref target="ccspec-ow" /> for discussions 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 "protocol" 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 format="default"/>.</dd>
          <dt>"estimation":</dt>
	  <dd>See the "estimation" entry in
          <xref
          target="ccspec-ow"></xref>. target="ccspec-ow" format="default"/>. For estimation
          by aggregation of routing protocol link metrics, the default
          aggregation of the average of loss rate is the sum of the
          link link loss rates. But this default aggregation is valid
          only if two conditions are met: (1) it is valid
          only when link loss rates are low, low and (2) it one assumes that each link's
          loss events are uncorrelated with every other link's loss
          events. When loss rates at the links are high but
          independent, the general formula for aggregating loss loss,
          assuming that each link is
          independent 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 complex, and the ALTO server should be cognizant of
          correlated loss rates. For estimation using IPPM, the IPPM
          metric MUST <bcp14>MUST</bcp14> be packet loss (i.e., IPPM
          OWLoss* metrics). The statistical operator of the ALTO
          metric MUST <bcp14>MUST</bcp14> be consistent with the IPPM
          statistical property (e.g., 95-th percentile).</t> 95th percentile).</dd>
	</dl>
        </section>
      </section>
      <section title="Cost anchor="hopcount" numbered="true" toc="default">
        <name>Cost Metric: Hop Count (hopcount)"> (hopcount)</name>
        <t>The hopcount hop count (hopcount) metric is mentioned in Section 9.2.3 of <xref
        target="RFC7285"></xref> target="RFC7285" sectionFormat="of" section="9.2.3"/>
as an example. This section further clarifies
        its properties.</t>

        <!--
        <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"> numbered="true" toc="default">
          <name>Base Identifier</name>
          <t>The base identifier for this performance metric is
          "hopcount".</t>
        </section>
        <section title="Value Representation"> numbered="true" toc="default">
          <name>Value Representation</name>
          <t>The metric value type is a single 'JSONNumber' type value
          conforming to the number specification of Section 6 of [RFC8259]. specifications provided in <xref target="RFC8259" sectionFormat="of" section="6"/>.
          The number MUST <bcp14>MUST</bcp14> be a non-negative integer (greater than or equal to
          0). The value represents the number of hops.</t>
        </section>
        <section title="Intended numbered="true" toc="default">
          <name>Intended Semantics and Use">
          <!--
          <t><list style="hanging">
            <t hangText="Metric Description:"><vspace blankLines="1"/> To
            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 metric value type is a single 'JSONNumber' type value conforming to the number specification [RFC8259], Section 6. The number MUST be an integer and non-negative.  <vspace blankLines="1"/></t>
          </list></t>
        -->

          <t>Intended Semantics: To Use</name>
          <dl>
          <dt>Intended Semantics:</dt>
	  <dd>To specify the number of hops in the path
          from the specified source to the specified destination. The hop
          count is a basic measurement of distance in a network and can be
          exposed as the number of router hops computed from the routing
          protocols originating this information. A hop, however, may
          represent other units. The spatial aggregation level is specified in
          the query context (e.g., PID to PID, or endpoint to endpoint).</t>

          <t>Use: This endpoint).</dd>

	      <dt>Use:</dt>
              <dd>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 response.</dd>
	    </dl>
	  <figure anchor="example-5">
           <name>Hop Count Value on source-destination endpoint pairs Source-Destination Endpoint Pairs (Example 5)</name>
          <sourcecode type="json"><![CDATA[
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "hopcount"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}
]]></artwork>
          </figure>

          <figure>
            <artwork><![CDATA[

HTTP/1.1 200 OK
Content-Length: 245
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "hopcount"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    5,
      "ipv4:198.51.100.34": 3
    }
  }
}
]]></artwork>
          </figure>
]]></sourcecode></figure>
       </section>

        <!--
        <section title="Measurement Considerations and Parameters">

            <t>The hop count can be calculated based on the number of routers from the
              source endpoint through which data must
              pass to reach the destination endpoint. This count can be measured at the source
            endpoint by traceroute.</t>

            <t>Upon
            need, the traceroute can use UDP probe message or other
            implementations that use ICMP and TCP to discover the hop counts
            along the path from source endpoint to destination
            endpoint.</t>

        </section>
        -->

        <section title="Cost-Context numbered="true" toc="default">
          <name>Cost-Context Specification Considerations">
          <t>"nominal": Typically Considerations</name>
          <dl>
          <dt>"nominal":</dt><dd>Typically, the hop count does not have a nominal value.</t>

          <t>"sla": Typically value.</dd>
          <dt>"sla":</dt><dd>Typically, the hop count does not have an SLA value.</t>

          <!--
          <t>"import": There can be multiple sources to import hop count, such as from IGP routing protocols.
          </t>
          -->

          <t>"estimation": The value.</dd>
          <dt>"estimation":</dt><dd>The exact estimation method is out of outside the scope of
          this document. An example of estimating hopcounts hop count values is by importing
          from IGP routing protocols. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the "parameters"
          field of an "estimation" hop count define the meaning of a hop.</t> hop.</dd>
	  </dl>
        </section>
      </section>
    </section>
    <section anchor="secbwmetrics"
             title="Throughput/Bandwidth numbered="true" toc="default">
      <name>Throughput/Bandwidth Performance Metrics"> Metrics</name>
      <t>This section introduces four throughput/bandwidth three metrics related metrics. to throughput and bandwidth.
      Given a specified source to and a specified destination, these metrics
      reflect the volume of traffic that the network can carry from the source
      to the destination.</t>
      <section title="Cost anchor="tput" numbered="true" toc="default">
        <name>Cost Metric: TCP Throughput (tput)"> (tput)</name>
        <section title="Base Identifier"> numbered="true" toc="default">
          <name>Base Identifier</name>
          <t>The base identifier for this performance metric is "tput".</t>
        </section>
        <section title="Value Representation"> numbered="true" toc="default">
          <name>Value Representation</name>
          <t>The metric value type is a single 'JSONNumber' type value
          conforming to the number specification of Section 6 of [RFC8259]. specifications provided in <xref target="RFC8259" sectionFormat="of" section="6"/>.
          The number MUST <bcp14>MUST</bcp14> be non-negative. The unit is bytes per second.</t>
        </section>

        <!--
        <t><list style="hanging">
            <t hangText="Metric name:"><vspace
            blankLines="1"/>Throughput<vspace blankLines="1"/></t>

            <t hangText="Metric Identifier:">
              <vspace blankLines="1"/>throughput<vspace blankLines="1"/>
            </t>
        </list></t>
        -->
        <section title="Intended numbered="true" toc="default">
          <name>Intended Semantics and Use">
          <t>Intended Semantics: To Use</name>
	  <dl>
          <dt>Intended Semantics:</dt><dd>To give the throughput of a TCP
          congestion-control
          congestion control conforming TCP flow from the specified source to the
          specified destination. The throughput SHOULD <bcp14>SHOULD</bcp14> be interpreted as only
          an estimation, and the estimation is designed only for bulk
          flows.</t>

          <t>Use: This
          flows.</dd>

	      <dt>Use:</dt>
	      <dd>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 response.</dd>
	    </dl>
          <figure anchor="example-6">
           <name>TCP Throughput Value on source-destination endpoint pairs Source-Destination Endpoint Pairs (Example 6)</name>
          <sourcecode type="json"><![CDATA[
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 234
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "tput"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}
]]></artwork>
          </figure>

          <figure>
            <artwork><![CDATA[

HTTP/1.1 200 OK
Content-Length: 251
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "tput"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    256000,
      "ipv4:198.51.100.34": 128000
    }
  }
}
]]></artwork>
          </figure>
        </section>

        <!--
      <section title="Measurement Considerations and Parameters">

          <t><list style="hanging">
             <t hangText="Method of Measurement or Calculation:"><vspace
              blankLines="1"/>See Section 3.3 of [RFC6349] for Measurement
              Method.<vspace blankLines="1"/></t>

             <t
             hangText="Measurement Point(s) with Potential Measurement Domain:"><vspace
             blankLines="1"/>See Section 4.1 of this document.<vspace
            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 information.</t>
]]></sourcecode></figure>
        </section>
      -->
        <section title="Cost-Context numbered="true" toc="default">
          <name>Cost-Context Specification Considerations">
          <t>"nominal": Typically Considerations</name>
          <dl>
          <dt>"nominal":</dt><dd>Typically, TCP throughput does not have a nominal
          value,
          value and SHOULD NOT <bcp14>SHOULD NOT</bcp14> be generated.</t>

          <t>"sla": Typically generated.</dd>
          <dt>"sla":</dt><dd>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 one can import TCP throughput. If the import is from the IPPM framework, it is RECOMMENDED that "parameters" provides "protocol" as a field value and "ippm" as the value; see Section 4 of [I-D.ietf-ippm-initial-registry] for additional fields which can
          <bcp14>SHOULD NOT</bcp14> be specified for "ippm" in "parameters".
          </t>
        -->

          <t>"estimation": The generated.</dd>
          <dt>"estimation":</dt><dd>The exact estimation method is out of outside the scope of
          this document. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the "parameters" field of an
          "estimation" TCP throughput metric include the following
          information: (1) the congestion-control algorithm; congestion control algorithm and (2) the
          estimation methodology. To specify (1), it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the
          "parameters" field (object) include a field named
          "congestion-control-algorithm", which provides a URI for the
          specification of the algorithm; for example, for an ALTO server to
          provide estimation to of the throughput of a Cubic Congestion CUBIC congestion control
          flow, its "parameters" includes a field
          "congestion-control-algorithm", includes the
          "congestion-control-algorithm" field, with value being set to the URI for <xref
          target="I-D.ietf-tcpm-rfc8312bis"></xref>; target="RFC9438" format="default"/>; for an ongoing congestion control algorithm such as BBR, a a link to its specification. specification can be added. To
          specify (2), the "parameters" field includes as many details as possible;
          for example, for the TCP Cubic throughout estimation, the "parameters"
          field specifies that the throughput is estimated by setting _C_ to
          0.4, and the Equation equation in <xref target="RFC9438" sectionFormat="comma" section="5.1"/>, Figure 8 of <xref
          target="I-D.ietf-tcpm-rfc8312bis"></xref> is applied; as an
          alternative, the methodology may be based on the NUM model <xref
          target="Prophet"></xref>, target="Prophet" format="default"/> or the G2 model described in <xref target="G2"></xref>. target="G2" format="default"/>.
          The exact specification of the parameters "parameters" field is out of outside the scope
          of this document.</t> document.</dd>
	  </dl>
        </section>
      </section>

      <!-- TCP Throughput -->
      <section title="Cost anchor="bwresidual" numbered="true" toc="default">
        <name>Cost Metric: Residual Bandwidth (bw-residual)">
        <!--
        <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>
        --> (bw-residual)</name>
        <section title="Base Identifier"> numbered="true" toc="default">
          <name>Base Identifier</name>
          <t>The base identifier for this performance metric is
          "bw-residual".</t>
        </section>
        <section title="Value Representation"> numbered="true" toc="default">
          <name>Value Representation</name>
          <t>The metric value type is a single 'JSONNumber' type value that is
          non-negative. The unit of measurement is bytes per second.</t>
        </section>
        <section title="Intended numbered="true" toc="default">
          <name>Intended Semantics and Use">
          <t>Intended Semantics: To Use</name>
	  <dl>
          <dt>Intended Semantics:</dt><dd><t>To specify temporal and spatial residual
          bandwidth from the specified source and to the specified destination.
          The base semantics of the metric is the Unidirectional Residual
          Bandwidth metric as defined in [RFC8571,RFC8570,RFC7471], <xref target="RFC8571"/>, <xref target="RFC8570"/>, and <xref target="RFC7471"/>, but instead
          of specifying the residual bandwidth for a link, it is the residual
          bandwidth of the path from the source to the destination. Hence, it
          is the minimal residual bandwidth among all links from the source to
          the destination. When the max statistical operator is defined for
          the metric, it typically provides the minimum of the link capacities
          along the path, as the default value of the residual bandwidth of a
          link is its link capacity [RFC8571,8570,7471]. <xref target="RFC8571"/> <xref target="RFC8570"/> <xref target="RFC7471"/>. The spatial
          aggregation unit is specified in the query context (e.g., PID to
          PID, or endpoint to endpoint).</t>
          <t>The default statistical operator for residual bandwidth is the
          current instantaneous sample; that is, the default is assumed to be
          "cur".</t>

          <t>Use: This
         </dd>
	      <dt>Use:</dt>
	      <dd>This metric could be used either as a cost metric constraint
              attribute or as a returned cost metric in the response.</t>

          <figure>
            <artwork><![CDATA[
Example 7: bw-residual value response.</dd>
	    </dl>
          <figure anchor="example-7">
           <name>Residual Bandwidth Value on source-destination endpoint pairs Source-Destination Endpoint Pairs (Example 7)</name>
          <sourcecode type="json"><![CDATA[
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 241
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "bw-residual"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}
]]></artwork>
          </figure>

          <figure>
            <artwork><![CDATA[

HTTP/1.1 200 OK
Content-Length: 255
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "bw-residual"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2":  {
      "ipv4:192.0.2.89":       0,
      "ipv4:198.51.100.34": 2000
    }
  }
}
]]></artwork>
          </figure>
        </section>

        <!--
      <section title="Measurement Considerations and Parameters">
          <t><list style="hanging">
            <t hangText="Method of Measurement or Calculation:"><vspace
            blankLines="1"/>residual Bandwidth is the Unidirectional residual
            bandwidth measured between two directly connected IS-IS neighbors
            or OSPF neighbors. See Section 4.5 of [RFC7810] for Measurement
            Method. <vspace blankLines="1"/></t>

            <t
            hangText="Measurement Point(s) with Potential Measurement Domain:"><vspace
            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>
]]></sourcecode></figure>
        </section>
      -->
        <section title="Cost-Context numbered="true" toc="default">
          <name>Cost-Context Specification Considerations">
          <t>"nominal": Typically Considerations</name>
         <dl>
          <dt>"nominal":</dt><dd>Typically, residual bandwidth does not have a nominal
          value.</t>

          <t>"sla": Typically
          value.</dd>
          <dt>"sla":</dt><dd>Typically, residual bandwidth does not have an "sla"
          value.</t>

          <!--
          <t>"import": There can be multiple sources to import residual bandwidth. 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-end summary statistics from link statistics. For example, the min of the end-to-end path residual bandwidth is the min of all links on the path.
          </t>
        -->

          <t>"estimation": See SLA
          value.</dd>
          <dt>"estimation":</dt><dd>See the "estimation" entry in Section 4.1.4 on
          aggregation of routing protocol link metrics. <xref target="ccspec-ow"/>. The current ("cur")
          residual bandwidth of a path is the minimal of the residual
          bandwidth of all links on the path.</t> path.</dd>
	 </dl>
        </section>
      </section>

      <!-- residual bandwidth -->
      <section title="Cost anchor="bwavailable" numbered="true" toc="default">
        <name>Cost Metric: Available Bandwidth (bw-available)">
        <!--
        <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>
        --> (bw-available)</name>
        <section title="Base Identifier"> numbered="true" toc="default">
          <name>Base Identifier</name>
          <t>The base identifier for this performance metric is
          "bw-available".</t>
        </section>
        <section title="Value Representation"> numbered="true" toc="default">
          <name>Value Representation</name>
          <t>The metric value type is a single 'JSONNumber' type value that is
          non-negative. The unit of measurement is bytes per second.</t>
        </section>
        <section title="Intended numbered="true" toc="default">
          <name>Intended Semantics and Use">
          <t>Intended Semantics: To Use</name>
	  <dl>
          <dt>Intended Semantics:</dt><dd><t>To specify temporal and spatial available
          bandwidth from the specified source to the specified destination.
          The base semantics of the metric is the Unidirectional Available
          Bandwidth metric as defined in [RFC8571,RFC8570,RFC7471], <xref target="RFC8571"/>, <xref target="RFC8570"/>, and <xref target="RFC7471"/>, but instead
          of specifying the available bandwidth for a link, it is the
          available bandwidth of the path from the source to the destination.
          Hence, it is the minimal available bandwidth among all links from
          the source to the destination.The destination. The spatial aggregation unit is
          specified in the query context (e.g., PID to PID, or endpoint to
          endpoint).</t>
          <t>The default statistical operator for available bandwidth is the
          current instantaneous sample; that is, the default is assumed to be
          "cur".</t>

          <t>Use: This
        </dd>
	      <dt>Use:</dt><dd>This metric could be used either as a cost metric constraint
              attribute or as a returned cost metric in the response.</t>

          <figure>
            <artwork><![CDATA[
  Example 8: bw-available value response.</dd>
	    </dl>
          <figure anchor="example-8">
           <name>Available Bandwidth Value on source-destination endpoint pairs Source-Destination Endpoint Pairs (Example 8)</name>
          <sourcecode type="json"><![CDATA[
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 244
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

{
  "cost-type": {
    "cost-mode":   "numerical",
    "cost-metric": "bw-available"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.2"
    ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34"
    ]
  }
}
]]></artwork>
          </figure>

          <figure>
            <artwork><![CDATA[

HTTP/1.1 200 OK
Content-Length: 255
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "bw-available"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":       0,
      "ipv4:198.51.100.34": 2000
    }
  }
}
]]></artwork>
          </figure>
        </section>

        <!--
      <section title="Measurement Considerations and Parameters">
          <t><list style="hanging">
            <t hangText="Method of Measurement or Calculation:"><vspace
            blankLines="1"/>Maximum Reservable Bandwidth is the bandwidth
            measured between two directly connected IS-IS neighbors or OSPF
            neighbors. See Section 3.5 of [RFC5305] 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 for discussions.<vspace
            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>
]]></sourcecode></figure>
        </section>
      -->
        <section title="Cost-Context numbered="true" toc="default">
          <name>Cost-Context Specification Considerations">
          <t>"nominal": Typically Considerations</name>
         <dl>
          <dt>"nominal":</dt><dd>Typically, available bandwidth does not have a nominal
          value.</t>

          <t>"sla": Typically
          value.</dd>
          <dt>"sla":</dt><dd>Typically, available bandwidth does not have an "sla"
          value.</t>

          <!--
          <t>"import": There can be multiple sources to import maximum reservable 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 [RFC8571] (by using unidirectional maximum reservable bandwidth), it is RECOMMENDED that "parameters" provides "protocol" as a field and "RFC8571" as the value.
          </t>
        -->

          <t>"estimation": See SLA
          value.</dd>
          <dt>"estimation":</dt><dd>See the "estimation" entry in Section 4.1.4 on
          aggregation of routing protocol link metrics. <xref target="ccspec-ow"/>. The current ("cur")
          available bandwidth of a path is the minimum of the available
          bandwidth of all links on the path.</t> path.</dd>
	 </dl>
        </section>

        <!-- cc consider -->
      </section>

      <!-- end of available bw -->
    </section>
    <section anchor="secopconsider" title="Operational Considerations"> numbered="true" toc="default">
      <name>Operational Considerations</name>
      <t>The exact measurement infrastructure, measurement condition, conditions, and
      computation algorithms can vary from between different networks, networks and are outside
      the scope of this document. Both the ALTO server and the ALTO clients,
      however, need to be cognizant of the operational issues discussed in the
      following sub-sections.</t> subsections.</t>
      <t>Also, the performance metrics specified in this document are similar, similar
      in that they may use similar data sources and have similar issues in
      their calculation. Hence, this document specifies common issues unless
      one metric has its unique challenges.</t> that the
      performance metrics might have in common and also discusses challenges
      regarding the computation of ALTO performance metrics (<xref target="comp-consider"/>).</t>
      <section title="Source Considerations"> numbered="true" toc="default">
        <name>Source Considerations</name>
        <t>The addition of the "cost-source" field is to solve solves a key issue: An an
        ALTO server needs data sources to compute the cost metrics described
        in this document, and an ALTO client needs to know the data sources to
        better interpret the values.</t>
        <t>To avoid information that is too fine-grained information, fine grained, this document introduces
        "cost-source" to indicate only the high-level type types of data sources:
        "estimation", "nominal" "nominal", or "lsa", "sla", where "estimation" is a type of
        measurement data source, "nominal" is a type of static configuration,
        and "sla" is a type that is more based more on policy.</t>
        <t>For estimation, for example, for "estimation", the ALTO server may use log servers or
        the OAM Operations, Administration, and Maintenance (OAM) system as its data source source, as recommended by <xref
        target="RFC7971"></xref>. target="RFC7971" format="default"/>. In particular, the cost metrics defined in
        this document can be computed using routing systems as the data
        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 title="Metric numbered="true" toc="default">
        <name>Metric Timestamp Consideration "> Considerations</name>
        <t>Despite the introduction of the additional cost-context "cost-context"
        information, the metrics do not have a field to indicate the
        timestamps of the data used to compute the metrics. To indicate this
        attribute, the ALTO server SHOULD <bcp14>SHOULD</bcp14> return an HTTP "Last-Modified", Last-Modified value to
        indicate the freshness of the data used to compute the performance
        metrics.</t>
        <t>If the ALTO client obtains updates through an incremental update
        mechanism <xref target="RFC8895"></xref>, target="RFC8895" format="default"/>, the client SHOULD <bcp14>SHOULD</bcp14> assume
        that the metric is computed using a snapshot at the time that is
        approximated by the receiving time.</t>
      </section>
      <section title="Backward Compatibility Considerations"> numbered="true" toc="default">
        <name>Backward-Compatibility Considerations</name>
        <t>One potential issue introduced by the optional "cost-source" field
        is backward compatibility. Consider that the case where an IRD which defines two
        cost-types
        "cost-type" entries with the same "cost-mode" and "cost-metric", but one with
        "cost-source" being "estimation" and the other being "sla". Then In such a case, an
        ALTO client that is not aware of the extension will not be able to
        distinguish between these two types. A similar issue can arise even
        with a single cost-type, "cost-type" whose "cost-source" is "sla": an ALTO client
        that is not aware of this extension will ignore this field and instead
        consider the metric estimation.</t>
        <t>To address the backward-compatibility issue, if a "cost-metric" is
        "routingcost" and the metric contains a "cost-context" field, then it
        MUST
        <bcp14>MUST</bcp14> be "estimation"; if it is not, the client SHOULD <bcp14>SHOULD</bcp14> reject the
        information as invalid.</t>
      </section>
      <section title="Computation Considerations"> anchor="comp-consider" numbered="true" toc="default">
        <name>Computation Considerations</name>
        <t>The metric values exposed by an ALTO server may result from
        additional processing on of measurements from data sources to compute
        exposed metrics. This may involve data processing tasks such as
        aggregating the results across multiple systems, removing outliers,
        and creating additional statistics. There are two challenges on the The computation of ALTO performance metrics.</t> metrics can present two challenges.</t>
        <section title="Configuration Parameters Considerations"> numbered="true" toc="default">
          <name>Configuration Parameter Considerations</name>
          <t>Performance metrics often depend on configuration parameters, and
          exposing such configuration parameters can help an ALTO client to
          better understand the exposed metrics. In particular, an ALTO server
          may be configured to compute a TE metric (e.g., packet loss rate) in at
          fixed intervals, say every T seconds. To expose this information,
          the ALTO server may provide the client with two pieces of additional
          information: (1) when the metrics are were last computed, computed and (2) when
          the metrics will be updated (i.e., the validity period of the
          exposed metric values). The ALTO server can expose these two pieces
          of information by using the HTTP response headers Last-Modified and
          Expires.</t>
        </section>
        <section title="Aggregation numbered="true" toc="default">
          <name>Aggregation Computation Considerations"> Considerations</name>
          <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
          often be link level. link-level information. For example, routing protocols often measure
          and report only per link loss, per-link loss and not end-to-end loss; similarly,
          routing protocols report link level link-level available bandwidth, bandwidth and not
          end-to-end available bandwidth. The ALTO server then needs to
          aggregate these data to provide an abstract and unified view that
          can be more useful to applications. The server should consider be aware that
          different metrics may use different aggregation computation. computations. For
          example, the end-to-end latency of a path is the sum of the latency latencies
          of the links on the path; the end-to-end available bandwidth of a
          path is the minimum of the available bandwidth of the links on the
          path; in contrast, aggregating loss values is complicated by the
          potential for correlated loss events on different links in the
          path</t>
          path.</t>
        </section>
      </section>
    </section>
    <section anchor="secsecconsider" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The properties defined in this document present no security
      considerations beyond those in Section 15 <xref target="RFC7285"
      section="15" sectionFormat="bare"/> of the base ALTO
      specification <xref target="RFC7285"></xref>.</t> target="RFC7285" format="default"/>.</t>
      <t>However, concerns addressed in Sections 15.1, 15.2, Sections&nbsp;<xref target="RFC7285" section="15.1" sectionFormat="bare"/>, <xref target="RFC7285" section="15.2" sectionFormat="bare"/>, and 15.3 <xref target="RFC7285" section="15.3" sectionFormat="bare"/> of <xref
      target="RFC7285"></xref> target="RFC7285" format="default"/> remain of utmost importance. Indeed, Traffic
      Engineering (TE)
      TE performance is highly sensitive ISP information;
      therefore, sharing TE metric values in numerical mode requires full
      mutual confidence between the entities managing the ALTO server and the
      ALTO client. ALTO servers will most likely distribute numerical TE
      performance to ALTO clients under strict and formal mutual trust
      agreements. On the other hand, ALTO clients must be cognizant on of the
      risks attached to such information that they would have acquired outside
      formal conditions of mutual trust.</t>
      <t>To mitigate confidentiality risks during information transport of TE
      performance metrics, the operator should address the risk of ALTO
      information being leaked to malicious Clients clients or third parties, parties through
      attacks
      such attacks as the person-in-the-middle (PITM) attacks. As specified in
      "Protection Strategies" (Section 15.3.2
      Section&nbsp;<xref target="RFC7285" section="15.3.2"
sectionFormat="bare">"Protection Strategies"</xref> of <xref
      target="RFC7285"></xref>), target="RFC7285"/>,
the ALTO Server server should authenticate ALTO
      Clients
      clients when transmitting an ALTO information resource containing
      sensitive TE performance metrics. "Authentication Section&nbsp;<xref target="RFC7285" section="8.3.5" sectionFormat="bare">"Authentication and Encryption"
      (Section 8.3.5 Encryption"</xref> of <xref target="RFC7285"></xref>) target="RFC7285"/> specifies that "ALTO
      Server ALTO
      server implementations as well as ALTO Client client implementations MUST <bcp14>MUST</bcp14>
      support the "https" URI scheme of <xref target="RFC7230"></xref> target="RFC9110" format="default"/> and
      Transport Layer Security (TLS) of <xref target="RFC8446"></xref>".</t> target="RFC8446" format="default"/>.</t>
    </section>
    <section anchor="ianaconsider" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section>
	 <name>ALTO Cost Metrics Registry</name>
      <t>IANA has created and now maintains the "ALTO Cost Metric" Metrics" registry, as
      listed in Section 14.2, Table 3 of <xref target="RFC7285"></xref>. target="RFC7285" section="14.2" sectionFormat="comma"/>, Table 3. This registry is located at
      &lt;https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml#cost-metrics&gt;.
      This document requests to add
<eref target="https://www.iana.org/assignments/alto-protocol/" brackets="angle"/>.
      IANA has added the following entries to the &ldquo;ALTO "ALTO
      Cost Metric&rdquo; Metrics" registry.</t>

      <figure>
        <artwork><![CDATA[
+-----------------+----------------------------+
| Identifier      | Intended Semantics         |
+-----------------+----------------------------+
| delay-ow        | Section 4.1 of [RFCXXX]    |
| delay-rt        | Section 4.2 of [RFCXXX]    |
| delay-variation | Section 4.3 of [RFCXXX]    |
| lossrate        | Section 4.4 of [RFCXXX]    |
| hopcount        | Section 4.5 of [RFCXXX]    |
| tput            | Section 5.1 of [RFCXXX]    |
| bw-residual     | Section 5.2 of [RFCXXX]    |
| bw-available    | Section 5.3 of [RFCXXX]    |
+-----------------+----------------------------+
]]></artwork>
      </figure>

      <t><list style="symbols">
          <t>[Note to the RFC Editor]: Please replace RFCXXX with the RFC
          number assigned to this document.</t>
        </list></t>

      <t>This document requests the creation of
      <table>
	<name>ALTO Cost Metrics Registry</name>
	<thead>
	  <tr>
	    <th>Identifier</th>
	    <th>Intended Semantics</th>
	    <th>Reference</th>
	  </tr>
	</thead>
	<tbody>
	  <tr>
	    <td>delay-ow</td>
	    <td>See <xref target="oneway"/></td>
	    <td>RFC 9439</td>
	    </tr><tr>
	    <td>delay-rt</td>
	    <td>See <xref target="delayrt"/></td>
	    <td>RFC 9439</td>
	    </tr><tr>
	    <td>delay-variation</td>
	    <td>See <xref target="delayvar"/></td>
	    <td>RFC 9439</td>
	    </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" Source Types"
      registry. This registry serves two purposes. First, it ensures the
      uniqueness of identifiers referring to ALTO cost source types. Second,
      it provides references to particular semantics of allocated cost source
      types to be applied by both ALTO servers and applications utilizing ALTO
      clients.</t>
      <t>A new ALTO cost source type can be added after IETF Review <xref
      target="RFC8126"></xref>, target="RFC8126" format="default"/>, to ensure that proper documentation regarding
      the new ALTO cost source type and its security considerations have has been
      provided. The RFC(s) documenting the new cost source type should be detailed
      enough to provide guidance to both ALTO service providers and
      applications utilizing ALTO clients as to how values of the registered
      ALTO cost source type should be interpreted. Updates and deletions of ALTO
      cost source types follow the same procedure.</t>
      <t>Registered ALTO address type identifiers MUST <bcp14>MUST</bcp14> conform to the
      syntactical requirements specified in Section 3.1. <xref target="meta" sectionFormat="bare"/>. Identifiers are to be
      recorded and displayed as strings.</t>
      <t>Requests to add a new value to the registry MUST <bcp14>MUST</bcp14> include the
      following information: <list style="symbols">
          <t>Identifier: The </t>
      <dl>
        <dt>Identifier:</dt><dd>The name of the desired ALTO cost source type.</t>

          <t>Intended Semantics: type.</dd>
        <dt>Intended Semantics:</dt><dd> ALTO cost source type types carry with them
          semantics to guide their usage by ALTO clients. Hence, a document
          defining a new type should provide guidance to both ALTO service
          providers and applications utilizing ALTO clients as to how values
          of the registered ALTO endpoint property should be interpreted.</t>

          <t>Security Considerations: interpreted.</dd>
        <dt>Security Considerations:</dt><dd> ALTO cost source types expose
          information to ALTO clients. ALTO service providers should be made
          aware of the security ramifications related to the exposure of a
          cost source type.</t>
        </list></t>

      <t>This specification requests registration of type.</dd>
      </dl>
      <t>IANA has registered the identifiers
      "nominal", "sla", and "estimation" as listed in the table below. Semantics
      for the these are documented in Section 3.1, and security considerations
      are documented in Section 7.</t>

      <figure>
        <artwork><![CDATA[
+------------+----------------------------------+----------------+
| Identifier | Intended Semantics               | Security       |
|            |                                  | Considerations |
+------------+----------------------------------+----------------+
| nominal    | Values below.</t>
      <table>
	<name>ALTO Cost Source Types Registry</name>
	<thead>
	  <tr>
	  <th>Identifier</th>
	  <th>Intended Semantics</th>
          <th>Security Considerations</th>
          <th>Reference</th>
	  </tr>
	</thead>
	<tbody>
	  <tr>
	    <td>nominal</td>
	    <td>Values in nominal cases;         | Section 7 of   |
|            |  Section 3.1 of [RFCXXX]         |     [RFCXXX]   |
| sla        | Values cases (<xref target="meta"/>)</td>
            <td><xref target="secsecconsider"/></td>
            <td>RFC 9439</td>
	  </tr>
	  <tr>
	    <td>sla</td>
	    <td>Values reflecting service level  | Section 7 of   |
|            | agreement; Section 3.1 of        |     [RFCXXX]   |
|            |   [RFCXXXX]                      |                |
| estimation | Values Service Level Agreement (<xref  target="meta"/>)</td>
	    <td><xref target="secsecconsider"/></td>
            <td>RFC 9439</td>
	  </tr>
	  <tr>
	 <td>estimation</td>
	 <td>Values by estimation;            | Section 7 of   |
|            |  Section 3.1 of [RFCXXX]         |     [RFCXXX]   |
+------------+----------------------------------+----------------+
]]></artwork>
      </figure> estimation (<xref target="meta"/>)</td>
	 <td><xref target="secsecconsider"/></td>
         <td>RFC 9439</td>
	  </tr>
	</tbody>
      </table>
     </section>

    <section title="Acknowledgments">
      <t>The authors of this document would also like to thank Martin Duke for
      the highly informative, thorough AD reviews and comments. We thank
      Christian Ams&uuml;ss, Elwyn Davies, Haizhou Du, Kai Gao, Geng Li, Lili
      Liu, Danny Alex Lachos Perez, and Brian Trammell for the reviews and
      comments. We thank Benjamin Kaduk, Eric Kline, Francesca Palombini, Lars
      Eggert, Martin Vigoureux, Murrary Kucherawy, Roman Danyliw, Zaheduzzaman
      Sarker, &Eacute;ric Vyncke for discussions and comments that improve
      this document.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <!--
      <?rfc include="reference.RFC.5234.xml"?>

      <?rfc include="reference.RFC.4627.xml"?>

      <?rfc include="reference.RFC.7471.xml"?>

      <?rfc include="reference.RFC.7752.xml"?>

      <?rfc include="reference.RFC.7810.xml"?>

      <?rfc include="reference.RFC.7680.xml"?>

      <?rfc include="reference.RFC.2679.xml"?>

      <?rfc include="reference.RFC.2681.xml"?>

      <?rfc include="reference.RFC.3393.xml"?>

      <?rfc include="reference.RFC.5305.xml"?>

      <?rfc include="reference.RFC.6349.xml"?>

      <?rfc include="reference.RFC.7679.xml"?>

      <?rfc include="reference.RFC.8571.xml"?>

      <?rfc include="reference.I-D.ietf-idr-te-pm-bgp.xml"?>

      <?rfc include="reference.I-D.ietf-ippm-initial-registry.xml"?>

      <?rfc include="reference.RFC.2818.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"?>
<displayreference target="I-D.corre-quic-throughput-testing" to="QUIC-THROUGHPUT-TESTING"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6390.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7285.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7471.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8570.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8571.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8895.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>

        <reference anchor="IANA-IPPM" target="https://www.iana.org/assignments/performance-metrics/">
          <front>
            <title>Performance Metrics</title>
            <author>
             <organization>IANA</organization>
	    </author>
            <date/>
          </front>
        </reference>

<!-- ALTO SSE draft-ietf-tcpm-rfc8312bis (RFC 9438) (AUTH48-DONE) -->

      <?rfc include="reference.RFC.8895.xml"?>
<reference anchor="IANA-IPPM"> anchor='RFC9438' target='https://www.rfc-editor.org/info/rfc9438'>
<front>
          <title>Performance Metrics Registry,
          https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml</title>
<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 initials="" surname="IANA"></author> fullname="Vidhi Goel">
</author>
<author fullname="Lars Eggert" role="editor">
</author>
<date year="" /> month="August" year="2023"/>
</front>
<seriesInfo name="RFC" value="9438"/>
<seriesInfo name="DOI" value="10.17487/RFC9438"/>
</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 -->

      <?rfc include="reference.RFC.7971.xml"?>

      <?rfc include='reference.I-D.corre-quic-throughput-testing'?>

      <?rfc include='reference.RFC.9000'?>

      <!-- ALTO requirements -->
      <references>
        <name>Informative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2330.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2681.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3393.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5357.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7679.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7971.xml"/>

<!-- draft-corre-quic-throughput-testing (Expired) -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.corre-quic-throughput-testing.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>

      <reference anchor="G2"> anchor="G2" target="https://dl.acm.org/doi/10.1145/3366707">
          <front>
            <title>On the Bottleneck Structure of Congestion-Controlled
          Networks</title>
            <author initials="J" surname="Ros-Giralt"></author> surname="Ros-Giralt"/>
            <author initials="A" surname="Bohara"></author> surname="Bohara"/>
            <author initials="S" surname="Yellamraju"></author> surname="Yellamraju"/>
            <author initials="M" surname="Harper Langston"/>
            <author initials="R" surname="Lethin"/>
            <author initials="" surname="et. al."></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 year="2020" /> month="December" year="2019"/>
          </front>
          <refcontent>Proceedings of the ACM on Measurement and Analysis of Computing Systems, Vol. 3, No. 3, Article No. 59, pp. 1-31</refcontent>
        <seriesInfo name="ACM SIGMETRICS" value="2019" /> name="DOI" value="10.1145/3366707"/>
        </reference>

        <reference anchor="FlowDirector"> anchor="FlowDirector" target="">
          <front>
            <title>Steering Hyper-Giants' Traffic at Scale</title>
            <author initials="E" surname="Pujol"></author> surname="Pujol"/>
            <author initials="I" surname="Poese"></author> surname="Poese"/>
            <author initials="J" surname="Zerwas"></author> surname="Zerwas"/>
            <author initials="G" surname="Smaragdakis"></author> surname="Smaragdakis"/>
            <author initials="A" surname="Feldmann"></author> surname="Feldmann"/>
            <date year="2020" /> month="December" year="2019"/>
          </front>

        <seriesInfo name="ACM CoNEXT" value="2020" />
          <refcontent>ACM CoNEXT '19</refcontent>
        </reference>

        <reference anchor="Prometheus"> anchor="Prometheus" target="">
          <front>
            <title>Prometheus: A Next-Generation Monitoring System</title> System (Talk)</title>
            <author initials="J" surname="Volz"></author> surname="Volz"/>
            <author initials="B" surname="Rabenstein"></author> surname="Rabenstein"/>
            <date year="2015" /> month="May" year="2015"/>
          </front>
          <refcontent>SREcon15 Europe</refcontent>
        </reference>

        <reference anchor="Prophet"> anchor="Prophet" target="https://dl.acm.org/doi/10.1109/TNET.2020.3016838">
          <front>
            <title>Prophet: Toward Fast, Accurate Error-Tolerant Model-Based Throughput Prediction with for Reactive
          Flows</title>

          <author initials="K" surname="Gao"></author> Flows in DC Networks</title>
            <author initials="J" surname="Zhang"></author> surname="Zhang"/>
            <author initials="K" surname="Gao"/>
            <author initials="YR" surname="Yang"></author> surname="Yang"/>
            <author initials="J" surname="Bi"/>
            <date year="2020" /> month="December" year="2020"/>
          </front>

        <seriesInfo name="ACM/IEEE
          <refcontent>IEEE/ACM Transactions on Networking" value="July" /> Networking, Volume 28, Issue 601, pp. 2475-2488</refcontent>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors of this document would like to thank <contact fullname="Martin Duke"/> for
      the highly informative, thorough AD reviews and comments. We thank <contact fullname="Christian Amsüss"/>, <contact fullname="Elwyn Davies"/>, <contact fullname="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"/>, <contact fullname="Francesca Palombini"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Martin Vigoureux"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Zaheduzzaman Sarker"/>, and <contact fullname="Éric Vyncke"/> for discussions and comments that improved
      this document.</t>
    </section>
  </back>
</rfc>