<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" docName="draft-ietf-alto-performance-metrics-28" number="9439" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" prepTime="2023-08-11T21:34:19" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics-28" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9439" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="ALTO Performance Cost Metrics">Application-Layer Traffic Optimization (ALTO) Performance Cost Metrics</title>
    <seriesInfo name="RFC" value="9439" stream="IETF"/>
    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization showOnFrontPage="true">Huawei</organization>
      <address>
        <postal>
          <extaddr>Yuhua District</extaddr>
          <street>101 Software 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 showOnFrontPage="true">Yale University</organization>
      <address>
        <postal>
          <street>51 Prospect 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 showOnFrontPage="true">Samsung</organization>
      <address>
        <email>younglee.tx@gmail.com</email>
      </address>
    </author>
    <author fullname="Dhruv Dhody" initials="D." surname="Dhody">
      <organization showOnFrontPage="true">Huawei</organization>
      <address>
        <postal>
          <country>India</country>
        </postal>
        <email>dhruv.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Sabine Randriamasy" initials="S." surname="Randriamasy">
      <organization showOnFrontPage="true">Nokia Networks France</organization>
      <address>
        <postal>
          <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 showOnFrontPage="true">Telefonica</organization>
      <address>
        <postal>
          <street/>
          <city>Madrid</city>
          <region/>
          <code/>
          <country>Spain</country>
        </postal>
        <email>luismiguel.contrerasmurillo@telefonica.com</email>
      </address>
    </author>
    <date month="08" year="2023"/>
    <area>tsv</area>
    <workgroup>alto</workgroup>
    <keyword>JavaScript Object Notation</keyword>
    <keyword>Application-Layer Traffic Optimization</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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 indent="0" pn="section-abstract-2">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), packet loss rate, hop count, and
      bandwidth.</t>
      <t indent="0" pn="section-abstract-3">There are multiple sources (e.g., estimations based on measurements or
      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>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9439" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-performance-metric-attribut">Performance Metric Attributes</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-performance-metric-context-">Performance Metric Context: "cost-context"</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-performance-metric-statisti">Performance Metric Statistics</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-packet-performance-metrics">Packet Performance Metrics</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-metric-one-way-delay-d">Cost Metric: One-Way Delay (delay-ow)</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.1.2">
                  <li pn="section-toc.1-1.4.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-base-identifier">Base Identifier</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.2.1"><xref derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-value-representation">Value Representation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.3.1"><xref derivedContent="4.1.3" format="counter" sectionFormat="of" target="section-4.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-intended-semantics-and-use">Intended Semantics and Use</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.4.1"><xref derivedContent="4.1.4" format="counter" sectionFormat="of" target="section-4.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-context-specification-">Cost-Context Specification Considerations</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-metric-round-trip-dela">Cost Metric: Round-Trip Delay (delay-rt)</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-base-identifier-2">Base Identifier</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-value-representation-2">Value Representation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.3.1"><xref derivedContent="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-intended-semantics-and-use-2">Intended Semantics and Use</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.4.1"><xref derivedContent="4.2.4" format="counter" sectionFormat="of" target="section-4.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-context-specification-c">Cost-Context Specification Considerations</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-metric-delay-variation">Cost Metric: Delay Variation (delay-variation)</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2">
                  <li pn="section-toc.1-1.4.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.1.1"><xref derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-base-identifier-3">Base Identifier</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.2.1"><xref derivedContent="4.3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-value-representation-3">Value Representation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.3.1"><xref derivedContent="4.3.3" format="counter" sectionFormat="of" target="section-4.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-intended-semantics-and-use-3">Intended Semantics and Use</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.4.1"><xref derivedContent="4.3.4" format="counter" sectionFormat="of" target="section-4.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-context-specification-co">Cost-Context Specification Considerations</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-metric-loss-rate-lossr">Cost Metric: Loss Rate (lossrate)</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.4.2">
                  <li pn="section-toc.1-1.4.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.1.1"><xref derivedContent="4.4.1" format="counter" sectionFormat="of" target="section-4.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-base-identifier-4">Base Identifier</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.2.1"><xref derivedContent="4.4.2" format="counter" sectionFormat="of" target="section-4.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-value-representation-4">Value Representation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.4.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.3.1"><xref derivedContent="4.4.3" format="counter" sectionFormat="of" target="section-4.4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-intended-semantics-and-use-4">Intended Semantics and Use</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.4.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.4.1"><xref derivedContent="4.4.4" format="counter" sectionFormat="of" target="section-4.4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-context-specification-con">Cost-Context Specification Considerations</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-metric-hop-count-hopco">Cost Metric: Hop Count (hopcount)</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.5.2">
                  <li pn="section-toc.1-1.4.2.5.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.5.2.1.1"><xref derivedContent="4.5.1" format="counter" sectionFormat="of" target="section-4.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-base-identifier-5">Base Identifier</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.5.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.5.2.2.1"><xref derivedContent="4.5.2" format="counter" sectionFormat="of" target="section-4.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-value-representation-5">Value Representation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.5.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.5.2.3.1"><xref derivedContent="4.5.3" format="counter" sectionFormat="of" target="section-4.5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-intended-semantics-and-use-5">Intended Semantics and Use</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.5.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.5.2.4.1"><xref derivedContent="4.5.4" format="counter" sectionFormat="of" target="section-4.5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-context-specification-cons">Cost-Context Specification Considerations</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-throughput-bandwidth-perfor">Throughput/Bandwidth Performance Metrics</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-metric-tcp-throughput-">Cost Metric: TCP Throughput (tput)</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.1.2">
                  <li pn="section-toc.1-1.5.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-base-identifier-6">Base Identifier</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-value-representation-6">Value Representation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.3.1"><xref derivedContent="5.1.3" format="counter" sectionFormat="of" target="section-5.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-intended-semantics-and-use-6">Intended Semantics and Use</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.4.1"><xref derivedContent="5.1.4" format="counter" sectionFormat="of" target="section-5.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-context-specification-consi">Cost-Context Specification Considerations</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-metric-residual-bandwi">Cost Metric: Residual Bandwidth (bw-residual)</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.2.2">
                  <li pn="section-toc.1-1.5.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.1.1"><xref derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-base-identifier-7">Base Identifier</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.2.1"><xref derivedContent="5.2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-value-representation-7">Value Representation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.3.1"><xref derivedContent="5.2.3" format="counter" sectionFormat="of" target="section-5.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-intended-semantics-and-use-7">Intended Semantics and Use</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.4.1"><xref derivedContent="5.2.4" format="counter" sectionFormat="of" target="section-5.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-context-specification-consid">Cost-Context Specification Considerations</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-metric-available-bandw">Cost Metric: Available Bandwidth (bw-available)</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.3.2">
                  <li pn="section-toc.1-1.5.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref derivedContent="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-base-identifier-8">Base Identifier</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref derivedContent="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-value-representation-8">Value Representation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.3.1"><xref derivedContent="5.3.3" format="counter" sectionFormat="of" target="section-5.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-intended-semantics-and-use-8">Intended Semantics and Use</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.4.1"><xref derivedContent="5.3.4" format="counter" sectionFormat="of" target="section-5.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-context-specification-conside">Cost-Context Specification Considerations</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-considerations">Operational Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-source-considerations">Source Considerations</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-metric-timestamp-considerat">Metric Timestamp Considerations</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-backward-compatibility-cons">Backward-Compatibility Considerations</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-computation-considerations">Computation Considerations</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.4.2">
                  <li pn="section-toc.1-1.6.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.4.2.1.1"><xref derivedContent="6.4.1" format="counter" sectionFormat="of" target="section-6.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-configuration-parameter-con">Configuration Parameter Considerations</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.4.2.2.1"><xref derivedContent="6.4.2" format="counter" sectionFormat="of" target="section-6.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-aggregation-computation-con">Aggregation Computation Considerations</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-alto-cost-metrics-registry">ALTO Cost Metrics Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-alto-cost-source-types-regi">ALTO Cost Source Types Registry</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="secintro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">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" format="default" sectionFormat="of" derivedContent="RFC7285"/>.</t>
      <t indent="0" pn="section-1-2">Since different applications may use different cost metrics, the ALTO
      base protocol introduced the "ALTO Cost Metrics" registry (<xref target="RFC7285" section="14.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-14.2" derivedContent="RFC7285"/>) as a systematic mechanism to allow
      different metrics to be specified. For example, a delay-sensitive
      application may want to use latency-related metrics, and a
      bandwidth-sensitive application may want to use bandwidth-related
      metrics. However, the ALTO base protocol has registered only a single
      cost metric, i.e., the generic "routingcost" metric (<xref target="RFC7285" section="14.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-14.2" derivedContent="RFC7285"/>); no latency- or bandwidth-related metrics
      are defined in the base protocol.</t>
      <t indent="0" pn="section-1-3">This document registers a set of new cost metrics (<xref target="costmetric" sectionFormat="bare" format="default" derivedContent="Table 1"/>) to allow
      applications to determine where to connect based on network
      performance criteria, including delay- and bandwidth-related metrics.</t>
      <table anchor="costmetric" align="center" pn="table-1">
        <name slugifiedName="name-cost-metrics-defined-in-thi">Cost Metrics Defined in This Document</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Metric</th>
            <th align="left" colspan="1" rowspan="1">Definition in This Document</th>
            <th align="left" colspan="1" rowspan="1">Semantics Based On</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">One-Way Delay</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="oneway" sectionFormat="bare" format="default" derivedContent="Section 4.1"/></td>
            <td align="left" colspan="1" rowspan="1">Base: <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/> <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/> <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>
  sum of Unidirectional Delay of links along the path</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Round-Trip Delay</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="delayrt" sectionFormat="bare" format="default" derivedContent="Section 4.2"/></td>
            <td align="left" colspan="1" rowspan="1">Base: Sum of two directions of Unidirectional Delay</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Delay Variation</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="delayvar" sectionFormat="bare" format="default" derivedContent="Section 4.3"/></td>
            <td align="left" colspan="1" rowspan="1">Base: <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/> <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/> <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>
  Sum of Unidirectional Delay Variation of links along the path</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Loss Rate</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="lossrate" sectionFormat="bare" format="default" derivedContent="Section 4.4"/></td>
            <td align="left" colspan="1" rowspan="1">Base: <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/> <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/> <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>
  aggr Unidirectional Link Loss</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Residual Bandwidth</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="bwresidual" sectionFormat="bare" format="default" derivedContent="Section 5.2"/></td>
            <td align="left" colspan="1" rowspan="1">Base: <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/> <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/> <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>
  min Unidirectional Residual BW</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Available Bandwidth</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="bwavailable" sectionFormat="bare" format="default" derivedContent="Section 5.3"/></td>
            <td align="left" colspan="1" rowspan="1">Base: <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/> <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/> <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>
  min Unidirectional Available BW</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">TCP Throughput</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="tput" sectionFormat="bare" format="default" derivedContent="Section 5.1"/></td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC9438" format="default" sectionFormat="of" derivedContent="RFC9438"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Hop Count</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="hopcount" sectionFormat="bare" format="default" derivedContent="Section 4.5"/></td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/></td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-1-5">The first six metrics listed in <xref target="costmetric" sectionFormat="bare" format="default" derivedContent="Table 1"/> (i.e., one-way delay,
      round-trip delay, delay variation, loss rate, residual bandwidth, and
      available bandwidth) are derived from the set of Traffic Engineering (TE)
      performance metrics commonly defined in OSPF <xref target="RFC3630" format="default" sectionFormat="of" derivedContent="RFC3630"/> <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/>, IS-IS <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/> <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>, and BGP - Link State (BGP-LS)
      <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>. Deriving ALTO cost performance metrics
      from existing network-layer TE performance metrics, and making it exposed to ALTO, can be a typical
      mechanism used by network operators to deploy ALTO <xref target="RFC7971" format="default" sectionFormat="of" derivedContent="RFC7971"/> <xref target="FlowDirector" format="default" sectionFormat="of" derivedContent="FlowDirector"/>. This
      document defines the base semantics of these metrics by extending them
      from link metrics to end-to-end metrics for ALTO. The "Semantics Based
      On" column specifies at a high level how the end-to-end metrics are
      computed from link metrics; details will be specified in the
      following sections.</t>
      <t indent="0" pn="section-1-6">The Min/Max Unidirectional Link Delay metric as defined in
      <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/> and <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>, and Maximum (Link) Bandwidth as defined in <xref target="RFC3630" format="default" sectionFormat="of" derivedContent="RFC3630"/> and <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/>,
      are not listed in <xref target="costmetric" sectionFormat="bare" format="default" derivedContent="Table 1"/> because they can be handled by applying the
      statistical operators defined in this document. The metrics related to
      utilized bandwidth and reservable bandwidth (i.e., Maximum Reservable (Link) Bandwidth and Unreserved Bandwidth as defined in <xref target="RFC3630" format="default" sectionFormat="of" derivedContent="RFC3630"/> and <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/>) are outside the scope of
      this document.</t>
      <t indent="0" pn="section-1-7">The seventh metric in <xref target="costmetric" sectionFormat="bare" format="default" derivedContent="Table 1"/> (the estimated TCP-flow throughput metric) provides an
      estimation of the bandwidth of a TCP flow, using TCP throughput
      modeling, to support use cases of adaptive applications <xref target="Prophet" format="default" sectionFormat="of" derivedContent="Prophet"/> <xref target="G2" format="default" sectionFormat="of" derivedContent="G2"/>. Note that other
      transport-specific metrics can be defined in the future. For example,
      QUIC-related metrics <xref target="RFC9000" format="default" sectionFormat="of" derivedContent="RFC9000"/> can be considered
      when the methodology for measuring such metrics is more mature (e.g., see <xref target="I-D.corre-quic-throughput-testing" format="default" sectionFormat="of" derivedContent="QUIC-THROUGHPUT-TESTING"/>).</t>
      <t indent="0" pn="section-1-8">The eighth metric in <xref target="costmetric" sectionFormat="bare" format="default" derivedContent="Table 1"/> (the hop count metric) is mentioned, but not defined, in the
      ALTO base protocol <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/>; this document provides a definition for it.</t>
      <t indent="0" pn="section-1-9">These eight performance metrics can be classified into two categories:
      those derived from the performance of individual packets (i.e., one-way
      delay, round-trip delay, delay variation, loss rate, and hop count) and
      those related to bandwidth/throughput (residual bandwidth, available
      bandwidth, and TCP throughput). These two categories are defined in
      Sections <xref format="counter" target="secpktmetrics" sectionFormat="of" derivedContent="4"/> and <xref format="counter" target="secbwmetrics" sectionFormat="of" derivedContent="5"/>, respectively. Note that
      all metrics except round-trip delay are unidirectional. An ALTO client
      will need to query both directions if needed.</t>
      <t indent="0" pn="section-1-10">The purpose of this document is to ensure proper usage of these eight
      performance metrics in the context of ALTO. This document follows the
      guidelines defined in <xref target="RFC7285" sectionFormat="of" section="14.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-14.2" derivedContent="RFC7285"/>
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 <xref target="costmetric" sectionFormat="bare" format="default" derivedContent="Table 1"/>.</t>
      <t indent="0" pn="section-1-11">The definitions of the intended semantics of the metrics tend to be
      coarse grained and are for guidance only, and they may work well for ALTO. On
      the other hand, a performance measurement framework, such as the IP
      Performance Metrics (IPPM) framework, may provide more details for
      defining a performance metric. This document introduces a mechanism
      called "cost-context" to provide additional details, when they are
      available; see <xref target="sec3" format="default" sectionFormat="of" derivedContent="Section 3"/>.</t>
      <t indent="0" pn="section-1-12">Following the ALTO base protocol, this document uses JSON to specify
      the value type of each defined metric. See <xref target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259"/> for JSON data type specifications. In
      particular, <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/> specifies that cost values
      should be assumed by default to be 'JSONNumber'. When defining the value
      representation of each metric in <xref target="costmetric" sectionFormat="bare" format="default" derivedContent="Table 1"/>, this document conforms to
      <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/> but specifies additional, generic constraints on valid
      JSONNumbers for each metric. For example, each new metric in <xref target="costmetric" sectionFormat="bare" format="default" derivedContent="Table 1"/>
      will be specified as non-negative (&gt;= 0); Hop Count is specified to
      be an integer.</t>
      <t indent="0" pn="section-1-13">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 <xref target="RFC7285" section="9.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-9.2" derivedContent="RFC7285"/>.</t>
      <t indent="0" pn="section-1-14">An ALTO server introducing these metrics should consider related
      security issues. As a generic security consideration regarding reliability
      and trust in the exposed metric values, applications <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" format="default" sectionFormat="of" derivedContent="Section 7"/> discusses security considerations in
      more detail.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-requirements-language">Requirements Language</name>
      <t indent="0" pn="section-2-1">The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14
       <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="sec3" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-performance-metric-attribut">Performance Metric Attributes</name>
      <t indent="0" pn="section-3-1">The definitions of the metrics in this document are coarse grained,
      based on network-layer TE performance metrics, and for
      guidance only. A fine-grained framework as specified in <xref target="RFC6390" format="default" sectionFormat="of" derivedContent="RFC6390"/> requires that the fine-grained specification of
      a network performance metric include six components: (1) Metric Name, (2)
      Metric Description, (3) Method of Measurement or Calculation, (4)
      Units of Measurement, (5) Measurement Points, and (6) Measurement
      Timing. Requiring that an ALTO server provide precise, fine-grained
      values for all six components for each metric that it exposes may not be
      feasible or necessary for all ALTO use cases. For example, an ALTO
      server computing its metrics from network-layer TE
      performance metrics may not have information about the method of
      measurement or calculation (e.g., measured traffic patterns).</t>
      <t indent="0" pn="section-3-2">To address the issue and realize ALTO use cases for the metrics listed in <xref target="costmetric" sectionFormat="bare" format="default" derivedContent="Table 1"/>, this document defines performance metric identifiers that can be
      used in the ALTO Protocol with the following well-defined items: (1) Metric Name, (2) Metric
      Description, (3) Units of Measurement, and (4) Measurement Points,
      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 indent="0" pn="section-3-3">To allow the flexibility of allowing an ALTO server to provide
      fine-grained information such as Method of Measurement or 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" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-performance-metric-context-">Performance Metric Context: "cost-context"</name>
        <t indent="0" pn="section-3.1-1">The core additional details of a performance metric specify 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", "sla", and "estimation".</t>
        <t indent="0" pn="section-3.1-2">For a given type of source, precise interpretation of a performance
        metric value can depend on specific measurement and computation
        parameters.</t>
        <t indent="0" pn="section-3.1-3">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 (<xref target="RFC7285" section="10.7" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-10.7" derivedContent="RFC7285"/>) as follows:</t>
        <sourcecode type="json" markers="false" pn="section-3.1-4">    object {
      CostMetric   cost-metric;
      CostMode     cost-mode;
      [CostContext cost-context;]
      [JSONString  description;]
    } CostType;

    object {
      JSONString    cost-source;
      [JSONValue    parameters;]
    } CostContext;
</sourcecode>
        <t indent="0" pn="section-3.1-5">"cost-context" will not be used as a key to distinguish among
        performance metrics. Hence, an ALTO information resource <bcp14>MUST NOT</bcp14>
        announce multiple CostType entries with the same "cost-metric", "cost-mode",
        and "cost-context". They must be placed into different information
        resources.</t>
        <t indent="0" pn="section-3.1-6">The "cost-source" field of the "cost-context" field is defined as a
        string consisting of only ASCII alphanumeric characters
        (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A). The "cost-source" field is
        used in this document to indicate a string of this format.</t>
        <t indent="0" pn="section-3.1-7">As mentioned above, this document defines three values for
        "cost-source": "nominal", "sla", and "estimation". The "cost-source"
        field of the "cost-context" field <bcp14>MUST</bcp14> be one that is registered in the "ALTO Cost
        Source Types" registry (<xref target="ianaconsider" format="default" sectionFormat="of" derivedContent="Section 8"/>).</t>
        <t indent="0" pn="section-3.1-8">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 indent="0" pn="section-3.1-9">The "sla" category indicates that the metric value is derived from
        some commitment, which this document refers to as a Service Level Agreement (SLA). Some operators also use terms such as "target" or
        "committed" values. For an "sla" metric, it is <bcp14>RECOMMENDED</bcp14> that the
        "parameters" field provide a link to the SLA definition.</t>
        <t indent="0" pn="section-3.1-10">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" format="default" sectionFormat="of" derivedContent="RFC7471"/>, <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>, and <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>), traffic
        measurement management tools (e.g., the Two-Way Active Measurement Protocol (TWAMP) <xref target="RFC5357" format="default" sectionFormat="of" derivedContent="RFC5357"/>), and measurement frameworks (e.g., IPPM),
        with corresponding operational issues. An illustration of potential
        information flows used for estimating these metrics is shown in <xref target="fig1" format="default" sectionFormat="of" derivedContent="Figure 1"/>. <xref target="secopconsider" format="default" sectionFormat="of" derivedContent="Section 6"/> discusses in more detail the
        operational issues and how a network may address them. </t>
        <figure anchor="fig1" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-a-framework-to-compute-esti">A Framework to Compute Estimation of Performance Metrics</name>
          <artwork name="" type="" align="left" alt="" pn="section-3.1-11.1">
  +--------+   +--------+  +--------+
  | Client |   | Client |  | Client |
  +----^---+   +---^----+  +---^----+
       |           |           |
       +-----------|-----------+
                   |ALTO Protocol
                   |
                   |
                +--+-----+  retrieval      +-----------+
                |  ALTO  |&lt;----------------| Routing   |
                | Server |  and aggregation| Protocols |
                |        |&lt;-------------+  |           |
                +--------+              |  +-----------+
                                        |
                                        |  +------------+
                                        |  |Performance |
                                        ---| Monitoring |
                                           |  Tools     |
                                           +------------+
</artwork>
        </figure>
        <t indent="0" pn="section-3.1-12">There can be multiple options available when choosing the "cost-source" category; the operator of an ALTO server will make that choice. If a
        metric does not include a "cost-source" value, the application <bcp14>MUST</bcp14>
        assume that the value of "cost-source" is the most generic source,
        i.e., "estimation".</t>
      </section>
      <section anchor="percentile" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-performance-metric-statisti">Performance Metric Statistics</name>
        <t indent="0" pn="section-3.2-1">The measurement of a performance metric often yields a set of
        samples from an observation distribution <xref target="Prometheus" format="default" sectionFormat="of" derivedContent="Prometheus"/>, 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 indent="0" pn="section-3.2-2">Hence, this document extends the general ASCII alphanumeric cost
        metric strings, formally specified as the CostMetric type defined in
        <xref target="RFC7285" sectionFormat="of" section="10.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-10.6" derivedContent="RFC7285"/>, as follows:</t>
        <t indent="3" pn="section-3.2-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 
            colon character (':', U+003A), if the statistical operator string exists.
            The total length of the cost metric string <bcp14>MUST NOT</bcp14> exceed 32, as
            required by <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/>.</t>
        <t indent="0" pn="section-3.2-4">The statistical operator string <bcp14>MUST</bcp14> be one of the following:</t>
        <dl indent="3" newline="false" spacing="normal" pn="section-3.2-5">
          <dt pn="section-3.2-5.1">cur:</dt>
          <dd pn="section-3.2-5.2">The instantaneous
            observation value of the metric from the most recent sample (i.e.,
            the current value).</dd>
          <dt pn="section-3.2-5.3">percentile, with the letter 'p' followed by a number:</dt>
          <dd pn="section-3.2-5.4">Gives the percentile specified by the number
            following the letter 'p'. The number <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 higher precision is needed. The decimal part should start
            with the '.' separator (U+002E) and be followed by a sequence of one
            or more ASCII numbers between '0' and '9'. Assume that this number is y,
            and consider the case where the samples are coming from a random variable X. 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 99th percentile of observed one-way delay;
            delay-ow:p99.9 gives the 99.9th percentile. Note that some systems
            use quantile, which is in the range [0, 1]. When there is a more
            common form for a given percentile, it is <bcp14>RECOMMENDED</bcp14> that the
            common form be used; that is, instead of p0, use min; instead of
            p50, use median; instead of p100, use max.</dd>
          <dt pn="section-3.2-5.5">min:</dt>
          <dd pn="section-3.2-5.6">The minimal value of
            the observations.</dd>
          <dt pn="section-3.2-5.7">max:</dt>
          <dd pn="section-3.2-5.8">The maximal value of
            the observations.</dd>
          <dt pn="section-3.2-5.9">median:</dt>
          <dd pn="section-3.2-5.10">The midpoint
            (i.e., p50) of the observations.</dd>
          <dt pn="section-3.2-5.11">mean:</dt>
          <dd pn="section-3.2-5.12">The arithmetic mean
            value of the observations.</dd>
          <dt pn="section-3.2-5.13">stddev:</dt>
          <dd pn="section-3.2-5.14">The standard
            deviation of the observations.</dd>
          <dt pn="section-3.2-5.15">stdvar:</dt>
          <dd pn="section-3.2-5.16">The standard
            variance of the observations.</dd>
        </dl>
        <t indent="0" pn="section-3.2-6">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 indent="0" pn="section-3.2-7">If a cost metric string does not have the optional statistical
        operator string, the statistical operator <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 <bcp14>MUST</bcp14> be considered the
        median value.</t>
        <t indent="0" pn="section-3.2-8">Note that <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="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
        identifiers and statistical 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>
    <section anchor="secpktmetrics" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-packet-performance-metrics">Packet Performance Metrics</name>
      <t indent="0" pn="section-4-1">This section introduces ALTO network performance metrics on 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 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), whether the packet is dropped before reaching the
      destination (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
      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 anchor="oneway" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-cost-metric-one-way-delay-d">Cost Metric: One-Way Delay (delay-ow)</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1.1">
          <name slugifiedName="name-base-identifier">Base Identifier</name>
          <t indent="0" pn="section-4.1.1-1">The base identifier for this performance metric is
          "delay-ow".</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1.2">
          <name slugifiedName="name-value-representation">Value Representation</name>
          <t indent="0" pn="section-4.1.2-1">The metric value type is a single 'JSONNumber' type value
          conforming to the number specifications provided in <xref target="RFC8259" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8259#section-6" derivedContent="RFC8259"/>.
          The unit is expressed in microseconds. Hence, the number can be a
          floating-point number to express delay that is smaller than
          microseconds. The number <bcp14>MUST</bcp14> be non-negative.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1.3">
          <name slugifiedName="name-intended-semantics-and-use">Intended Semantics and Use</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-4.1.3-1">
            <dt pn="section-4.1.3-1.1">Intended Semantics:</dt>
            <dd pn="section-4.1.3-1.2">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 <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>, <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>, and <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="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" format="default" sectionFormat="of" derivedContent="RFC7679"/>. 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
          <xref target="RFC7285" sectionFormat="of" section="5.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-5.1" derivedContent="RFC7285"/>.</dd>
            <dt pn="section-4.1.3-1.3">Use:</dt>
            <dd pn="section-4.1.3-1.4">This metric could be used as a cost metric constraint
          attribute or as a returned cost metric in the response.</dd>
          </dl>
          <figure anchor="example-1" align="left" suppress-title="false" pn="figure-2">
            <name slugifiedName="name-delay-value-on-source-desti">Delay Value on Source-Destination Endpoint Pairs (Example 1)</name>
            <sourcecode type="json" markers="false" pn="section-4.1.3-2.1">
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 239
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

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

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

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "delay-ow"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    10,
      "ipv4:198.51.100.34": 20
    }
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-4.1.3-3">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 indent="0" pn="section-4.1.3-4"><xref target="example-1a" format="default" sectionFormat="of" derivedContent="Figure 3"/> shows an example that is similar to Example 1 (<xref target="example-1" format="default" sectionFormat="of" derivedContent="Figure 2"/>), but for IPv6.</t>
          <figure anchor="example-1a" align="left" suppress-title="false" pn="figure-3">
            <name slugifiedName="name-delay-value-on-source-destin">Delay Value on Source-Destination Endpoint Pairs for IPv6 (Example 1a)</name>
            <sourcecode type="json" markers="false" pn="section-4.1.3-5.1">
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 252
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

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

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

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "delay-ow"
    }
  },
  "endpoint-cost-map": {
    "ipv6:2001:db8:100::1": {
      "ipv6:2001:db8:100::2": 10,
      "ipv6:2001:db8:100::3": 20
    }
  }
}
</sourcecode>
          </figure>
        </section>
        <section anchor="ccspec-ow" numbered="true" toc="include" removeInRFC="false" pn="section-4.1.4">
          <name slugifiedName="name-cost-context-specification-">Cost-Context Specification Considerations</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-4.1.4-1">
            <dt pn="section-4.1.4-1.1">"nominal":</dt>
            <dd pn="section-4.1.4-1.2">Typically, network one-way delay does not have a
          nominal value.</dd>
            <dt pn="section-4.1.4-1.3">"sla":</dt>
            <dd pn="section-4.1.4-1.4">Many networks provide delay-related parameters in their
          application-level SLAs. It is <bcp14>RECOMMENDED</bcp14> that the "parameters"
          field of an "sla" one-way delay metric include a link (i.e., a field
          named "link") providing a URI for the specification of SLA details,
          if available. Such a specification can be either (1) free text for
          possible presentation to the user or (2) a formal specification. The
          format of the specification is outside the scope of this
          document.</dd>
            <dt pn="section-4.1.4-1.5">"estimation":</dt>
            <dd pn="section-4.1.4-1.6">The exact estimation method is outside the scope of
          this document. There can be multiple sources for estimating one-way
          delay. For example, the ALTO server may estimate the end-to-end
          delay by aggregation of routing protocol link metrics; the server
          may also estimate the delay using active, end-to-end measurements --
          for example, using the IPPM framework <xref target="RFC2330" format="default" sectionFormat="of" derivedContent="RFC2330"/>.</dd>
          </dl>
          <t indent="0" pn="section-4.1.4-2">If the estimation is computed by aggregation of routing protocol
          link metrics (e.g., Unidirectional Link Delay metrics for OSPF <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/>, IS-IS <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>, or BGP-LS <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>), it is <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., see <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/> for
          derived metrics), (2) configurations of the routing link metrics
          such as configured intervals, and (3) the aggregation method from
          link metrics to end-to-end metrics. During aggregation from link
          metrics to end-to-end metrics, the server should be cognizant of
          potential issues when computing an end-to-end summary statistic from
          link statistics. The default end-to-end average one-way delay is the
          sum of average link one-way delays. If an ALTO server provides the
          min and max statistical operators for the one-way delay metric, the
          values can be computed directly from the routing link metrics, as
          <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/>, <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>, and <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/> provide Min/Max Unidirectional Link
          Delay.</t>
          <t indent="0" pn="section-4.1.4-3">If the estimation is from the IPPM measurement framework, it is
          <bcp14>RECOMMENDED</bcp14> that the "parameters" field of an "estimation" one-way
          delay metric include the URI in the "URI"
          field of the IPPM metric defined in the IPPM "Performance Metrics" registry
          <xref target="IANA-IPPM" format="default" sectionFormat="of" derivedContent="IANA-IPPM"/> (e.g.,
<eref target="https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_95Percentile" brackets="angle"/>).
          The IPPM metric <bcp14>MUST</bcp14> be one-way delay (i.e., IPPM OWDelay* metrics).
          The statistical operator of the ALTO metric <bcp14>MUST</bcp14> be consistent with
          the IPPM statistical property (e.g., 95th percentile).</t>
        </section>
      </section>
      <section anchor="delayrt" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-cost-metric-round-trip-dela">Cost Metric: Round-Trip Delay (delay-rt)</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1">
          <name slugifiedName="name-base-identifier-2">Base Identifier</name>
          <t indent="0" pn="section-4.2.1-1">The base identifier for this performance metric is
          "delay-rt".</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2.2">
          <name slugifiedName="name-value-representation-2">Value Representation</name>
          <t indent="0" pn="section-4.2.2-1">The metric value type is a single 'JSONNumber' type value
          conforming to the number specifications provided in <xref target="RFC8259" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8259#section-6" derivedContent="RFC8259"/>.
          The number <bcp14>MUST</bcp14> be non-negative. The unit is expressed in
          microseconds.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2.3">
          <name slugifiedName="name-intended-semantics-and-use-2">Intended Semantics and Use</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-4.2.3-1">
            <dt pn="section-4.2.3-1.1">Intended Semantics:</dt>
            <dd pn="section-4.2.3-1.2">
              <t indent="0" pn="section-4.2.3-1.2.1">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 <xref target="oneway" format="default" sectionFormat="of" derivedContent="Section 4.1"/>. A non-normative reference definition of the
          end-to-end round-trip delay metric is provided in <xref target="RFC2681" format="default" sectionFormat="of" derivedContent="RFC2681"/>. The
          spatial aggregation level is specified in the query context (e.g.,
          PID to PID, or endpoint to endpoint).</t>
              <t indent="0" pn="section-4.2.3-1.2.2">Note that it is possible for a client to query two one-way delay
          (delay-ow) items and then compute the round-trip delay. The server should
          be cognizant of the consistency of values.</t>
            </dd>
            <dt pn="section-4.2.3-1.3">Use:</dt>
            <dd pn="section-4.2.3-1.4">This metric could be used as a cost metric constraint
          attribute or as a returned cost metric in the response.</dd>
          </dl>
          <figure anchor="example-2" align="left" suppress-title="false" pn="figure-4">
            <name slugifiedName="name-round-trip-delay-of-source-">Round-Trip Delay of Source-Destination Endpoint Pairs (Example 2)</name>
            <sourcecode type="json" markers="false" pn="section-4.2.3-2.1">
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

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

HTTP/1.1 200 OK
Content-Length: 245
Content-Type: application/alto-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
    }
  }
}
</sourcecode>
          </figure>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2.4">
          <name slugifiedName="name-cost-context-specification-c">Cost-Context Specification Considerations</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-4.2.4-1">
            <dt pn="section-4.2.4-1.1">"nominal":</dt>
            <dd pn="section-4.2.4-1.2">Typically, network round-trip delay does not have a
          nominal value.</dd>
            <dt pn="section-4.2.4-1.3">"sla":</dt>
            <dd pn="section-4.2.4-1.4">See the "sla" entry in <xref target="ccspec-ow" format="default" sectionFormat="of" derivedContent="Section 4.1.4"/>.</dd>
            <dt pn="section-4.2.4-1.5">"estimation":</dt>
            <dd pn="section-4.2.4-1.6">See the "estimation" entry in <xref target="ccspec-ow" format="default" sectionFormat="of" derivedContent="Section 4.1.4"/>. For estimation by aggregation of routing
          protocol link metrics, the aggregation should include all links from
          the source to the destination and then back to the source; for
          estimation using IPPM, the IPPM metric <bcp14>MUST</bcp14> be round-trip delay
          (i.e., IPPM RTDelay* metrics). The statistical operator of the ALTO
          metric <bcp14>MUST</bcp14> be consistent with the IPPM statistical property (e.g.,
          95th percentile).</dd>
          </dl>
        </section>
      </section>
      <section anchor="delayvar" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-cost-metric-delay-variation">Cost Metric: Delay Variation (delay-variation)</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.3.1">
          <name slugifiedName="name-base-identifier-3">Base Identifier</name>
          <t indent="0" pn="section-4.3.1-1">The base identifier for this performance metric is
          "delay-variation".</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.3.2">
          <name slugifiedName="name-value-representation-3">Value Representation</name>
          <t indent="0" pn="section-4.3.2-1">The metric value type is a single 'JSONNumber' type value
          conforming to the number specifications provided in <xref target="RFC8259" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8259#section-6" derivedContent="RFC8259"/>.
          The number <bcp14>MUST</bcp14> be non-negative. The unit is expressed in
          microseconds.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.3.3">
          <name slugifiedName="name-intended-semantics-and-use-3">Intended Semantics and Use</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-4.3.3-1">
            <dt pn="section-4.3.3-1.1">Intended Semantics:</dt>
            <dd pn="section-4.3.3-1.2">
              <t indent="0" pn="section-4.3.3-1.2.1">To specify temporal and spatial aggregated
          delay variation (also called delay jitter) with respect to the
          minimum delay observed on the stream over the one-way delay from the
          specified source and destination, where the one-way delay is as defined
          in <xref target="oneway" format="default" sectionFormat="of" derivedContent="Section 4.1"/>. A non-normative reference definition of the end-to-end
          one-way delay variation metric is provided in <xref target="RFC3393" format="default" sectionFormat="of" derivedContent="RFC3393"/>. Note that
          <xref target="RFC3393" format="default" sectionFormat="of" derivedContent="RFC3393"/> allows the specification of a generic
          selection function F to unambiguously define the two packets
          selected to compute delay variations. This document defines the
          specific case where F selects the packet with the smallest one-way
          delay as the "first" packet. The spatial aggregation level is specified
          in the query context (e.g., PID to PID, or endpoint to
          endpoint).</t>
              <t indent="0" pn="section-4.3.3-1.2.2">Note that in statistics, variation is typically evaluated by
          the distance from samples relative to the mean. In the context of networking, it is more commonly defined from samples relative to the
          min. This definition follows the networking convention.</t>
            </dd>
            <dt pn="section-4.3.3-1.3">Use:</dt>
            <dd pn="section-4.3.3-1.4">This metric could be used as a cost metric constraint
              attribute or as a returned cost metric in the response.</dd>
          </dl>
          <figure anchor="example-3" align="left" suppress-title="false" pn="figure-5">
            <name slugifiedName="name-delay-variation-value-on-so">Delay Variation Value on Source-Destination Endpoint Pairs (Example 3)</name>
            <sourcecode type="json" markers="false" pn="section-4.3.3-2.1">
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
    }
  }
}
</sourcecode>
          </figure>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.3.4">
          <name slugifiedName="name-cost-context-specification-co">Cost-Context Specification Considerations</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-4.3.4-1">
            <dt pn="section-4.3.4-1.1">"nominal":</dt>
            <dd pn="section-4.3.4-1.2">Typically, network delay variation does not have a
          nominal value.</dd>
            <dt pn="section-4.3.4-1.3">"sla":</dt>
            <dd pn="section-4.3.4-1.4">See the "sla" entry in <xref target="ccspec-ow" format="default" sectionFormat="of" derivedContent="Section 4.1.4"/>.</dd>
            <dt pn="section-4.3.4-1.5">"estimation":</dt>
            <dd pn="section-4.3.4-1.6">See the "estimation" entry in <xref target="ccspec-ow" format="default" sectionFormat="of" derivedContent="Section 4.1.4"/>. 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 <bcp14>MUST</bcp14> be delay variation
          (i.e., IPPM OWPDV* metrics). The statistical operator of the ALTO
          metric <bcp14>MUST</bcp14> be consistent with the IPPM statistical property (e.g.,
          95th percentile).</dd>
          </dl>
        </section>
      </section>
      <section anchor="lossrate" numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-cost-metric-loss-rate-lossr">Cost Metric: Loss Rate (lossrate)</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.4.1">
          <name slugifiedName="name-base-identifier-4">Base Identifier</name>
          <t indent="0" pn="section-4.4.1-1">The base identifier for this performance metric is
          "lossrate".</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.4.2">
          <name slugifiedName="name-value-representation-4">Value Representation</name>
          <t indent="0" pn="section-4.4.2-1">The metric value type is a single 'JSONNumber' type value
          conforming to the number specifications provided in <xref target="RFC8259" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8259#section-6" derivedContent="RFC8259"/>.
          The number <bcp14>MUST</bcp14> be non-negative. The value represents the percentage
          of packet losses.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.4.3">
          <name slugifiedName="name-intended-semantics-and-use-4">Intended Semantics and Use</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-4.4.3-1">
            <dt pn="section-4.4.3-1.1">Intended Semantics:</dt>
            <dd pn="section-4.4.3-1.2">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 <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>, <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>, and <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="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).</dd>
            <dt pn="section-4.4.3-1.3">Use:</dt>
            <dd pn="section-4.4.3-1.4">This metric could be used as a cost metric constraint
              attribute or as a returned cost metric in the response.</dd>
          </dl>
          <figure anchor="example-4" align="left" suppress-title="false" pn="figure-6">
            <name slugifiedName="name-loss-rate-value-on-source-d">Loss Rate Value on Source-Destination Endpoint Pairs (Example 4)</name>
            <sourcecode type="json" markers="false" pn="section-4.4.3-2.1">
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

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

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

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "lossrate"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    0,
      "ipv4:198.51.100.34": 0.01
    }
  }
}
</sourcecode>
          </figure>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.4.4">
          <name slugifiedName="name-cost-context-specification-con">Cost-Context Specification Considerations</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-4.4.4-1">
            <dt pn="section-4.4.4-1.1">"nominal":</dt>
            <dd pn="section-4.4.4-1.2">Typically, the packet loss rate does not have a nominal
          value, although some networks may specify zero losses.</dd>
            <dt pn="section-4.4.4-1.3">"sla":</dt>
            <dd pn="section-4.4.4-1.4">See the "sla" entry in <xref target="ccspec-ow" format="default" sectionFormat="of" derivedContent="Section 4.1.4"/>.</dd>
            <dt pn="section-4.4.4-1.5">"estimation":</dt>
            <dd pn="section-4.4.4-1.6">See the "estimation" entry in
          <xref target="ccspec-ow" format="default" sectionFormat="of" derivedContent="Section 4.1.4"/>. For estimation
          by aggregation of routing protocol link metrics, the default
          aggregation of the average loss rate is the sum of the
          link loss rates. But this default aggregation is valid
          only if two conditions are met: (1) link loss rates are low and (2) 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,
          assuming that each link is independent, is to compute end-to-end
          loss as one minus the product of the success rate for each
          link. Aggregation when losses at links are correlated can be
          more complex, and the ALTO server should be cognizant of
          correlated loss rates. For estimation using IPPM, the IPPM
          metric <bcp14>MUST</bcp14> be packet loss (i.e., IPPM
          OWLoss* metrics). The statistical operator of the ALTO
          metric <bcp14>MUST</bcp14> be consistent with the IPPM
          statistical property (e.g., 95th percentile).</dd>
          </dl>
        </section>
      </section>
      <section anchor="hopcount" numbered="true" toc="include" removeInRFC="false" pn="section-4.5">
        <name slugifiedName="name-cost-metric-hop-count-hopco">Cost Metric: Hop Count (hopcount)</name>
        <t indent="0" pn="section-4.5-1">The hop count (hopcount) metric is mentioned in <xref target="RFC7285" sectionFormat="of" section="9.2.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-9.2.3" derivedContent="RFC7285"/>
as an example. This section further clarifies
        its properties.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.5.1">
          <name slugifiedName="name-base-identifier-5">Base Identifier</name>
          <t indent="0" pn="section-4.5.1-1">The base identifier for this performance metric is
          "hopcount".</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.5.2">
          <name slugifiedName="name-value-representation-5">Value Representation</name>
          <t indent="0" pn="section-4.5.2-1">The metric value type is a single 'JSONNumber' type value
          conforming to the number specifications provided in <xref target="RFC8259" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8259#section-6" derivedContent="RFC8259"/>.
          The number <bcp14>MUST</bcp14> be a non-negative integer (greater than or equal to
          0). The value represents the number of hops.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.5.3">
          <name slugifiedName="name-intended-semantics-and-use-5">Intended Semantics and Use</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-4.5.3-1">
            <dt pn="section-4.5.3-1.1">Intended Semantics:</dt>
            <dd pn="section-4.5.3-1.2">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).</dd>
            <dt pn="section-4.5.3-1.3">Use:</dt>
            <dd pn="section-4.5.3-1.4">This metric could be used as a cost metric constraint
              attribute or as a returned cost metric in the response.</dd>
          </dl>
          <figure anchor="example-5" align="left" suppress-title="false" pn="figure-7">
            <name slugifiedName="name-hop-count-value-on-source-d">Hop Count Value on Source-Destination Endpoint Pairs (Example 5)</name>
            <sourcecode type="json" markers="false" pn="section-4.5.3-2.1">
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

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

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

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "hopcount"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    5,
      "ipv4:198.51.100.34": 3
    }
  }
}
</sourcecode>
          </figure>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.5.4">
          <name slugifiedName="name-cost-context-specification-cons">Cost-Context Specification Considerations</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-4.5.4-1">
            <dt pn="section-4.5.4-1.1">"nominal":</dt>
            <dd pn="section-4.5.4-1.2">Typically, the hop count does not have a nominal value.</dd>
            <dt pn="section-4.5.4-1.3">"sla":</dt>
            <dd pn="section-4.5.4-1.4">Typically, the hop count does not have an SLA value.</dd>
            <dt pn="section-4.5.4-1.5">"estimation":</dt>
            <dd pn="section-4.5.4-1.6">The exact estimation method is outside the scope of
          this document. An example of estimating hop count values is by importing
          from IGP routing protocols. It is <bcp14>RECOMMENDED</bcp14> that the "parameters"
          field of an "estimation" hop count define the meaning of a hop.</dd>
          </dl>
        </section>
      </section>
    </section>
    <section anchor="secbwmetrics" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-throughput-bandwidth-perfor">Throughput/Bandwidth Performance Metrics</name>
      <t indent="0" pn="section-5-1">This section introduces three metrics related to throughput and bandwidth.
      Given a specified source and a specified destination, these metrics
      reflect the volume of traffic that the network can carry from the source
      to the destination.</t>
      <section anchor="tput" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-cost-metric-tcp-throughput-">Cost Metric: TCP Throughput (tput)</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.1.1">
          <name slugifiedName="name-base-identifier-6">Base Identifier</name>
          <t indent="0" pn="section-5.1.1-1">The base identifier for this performance metric is "tput".</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.1.2">
          <name slugifiedName="name-value-representation-6">Value Representation</name>
          <t indent="0" pn="section-5.1.2-1">The metric value type is a single 'JSONNumber' type value
          conforming to the number specifications provided in <xref target="RFC8259" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8259#section-6" derivedContent="RFC8259"/>.
          The number <bcp14>MUST</bcp14> be non-negative. The unit is bytes per second.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.1.3">
          <name slugifiedName="name-intended-semantics-and-use-6">Intended Semantics and Use</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-5.1.3-1">
            <dt pn="section-5.1.3-1.1">Intended Semantics:</dt>
            <dd pn="section-5.1.3-1.2">To give the throughput of a
          congestion control conforming TCP flow from the specified source to the
          specified destination. The throughput <bcp14>SHOULD</bcp14> be interpreted as only
          an estimation, and the estimation is designed only for bulk
          flows.</dd>
            <dt pn="section-5.1.3-1.3">Use:</dt>
            <dd pn="section-5.1.3-1.4">This metric could be used as a cost metric constraint
              attribute or as a returned cost metric in the response.</dd>
          </dl>
          <figure anchor="example-6" align="left" suppress-title="false" pn="figure-8">
            <name slugifiedName="name-tcp-throughput-value-on-sou">TCP Throughput Value on Source-Destination Endpoint Pairs (Example 6)</name>
            <sourcecode type="json" markers="false" pn="section-5.1.3-2.1">
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 234
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

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

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

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "tput"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    256000,
      "ipv4:198.51.100.34": 128000
    }
  }
}
</sourcecode>
          </figure>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.1.4">
          <name slugifiedName="name-cost-context-specification-consi">Cost-Context Specification Considerations</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-5.1.4-1">
            <dt pn="section-5.1.4-1.1">"nominal":</dt>
            <dd pn="section-5.1.4-1.2">Typically, TCP throughput does not have a nominal
          value and <bcp14>SHOULD NOT</bcp14> be generated.</dd>
            <dt pn="section-5.1.4-1.3">"sla":</dt>
            <dd pn="section-5.1.4-1.4">Typically, TCP throughput does not have an SLA value and
          <bcp14>SHOULD NOT</bcp14> be generated.</dd>
            <dt pn="section-5.1.4-1.5">"estimation":</dt>
            <dd pn="section-5.1.4-1.6">The exact estimation method is outside the scope of
          this document. It is <bcp14>RECOMMENDED</bcp14> that the "parameters" field of an
          "estimation" TCP throughput metric include the following
          information: (1) the congestion control algorithm and (2) the
          estimation methodology. To specify (1), it is <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 of the throughput of a CUBIC congestion control
          flow, its "parameters" field includes the
          "congestion-control-algorithm" field, with value being set to the URI for <xref target="RFC9438" format="default" sectionFormat="of" derivedContent="RFC9438"/>; for an ongoing congestion control algorithm such as BBR, a link to its 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 in <xref target="RFC9438" sectionFormat="comma" section="5.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9438#section-5.1" derivedContent="RFC9438"/>, Figure 8 is applied; as an
          alternative, the methodology may be based on the NUM model <xref target="Prophet" format="default" sectionFormat="of" derivedContent="Prophet"/> or the model described in <xref target="G2" format="default" sectionFormat="of" derivedContent="G2"/>.
          The exact specification of the "parameters" field is outside the scope
          of this document.</dd>
          </dl>
        </section>
      </section>
      <section anchor="bwresidual" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-cost-metric-residual-bandwi">Cost Metric: Residual Bandwidth (bw-residual)</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.2.1">
          <name slugifiedName="name-base-identifier-7">Base Identifier</name>
          <t indent="0" pn="section-5.2.1-1">The base identifier for this performance metric is
          "bw-residual".</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.2.2">
          <name slugifiedName="name-value-representation-7">Value Representation</name>
          <t indent="0" pn="section-5.2.2-1">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 numbered="true" toc="include" removeInRFC="false" pn="section-5.2.3">
          <name slugifiedName="name-intended-semantics-and-use-7">Intended Semantics and Use</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-5.2.3-1">
            <dt pn="section-5.2.3-1.1">Intended Semantics:</dt>
            <dd pn="section-5.2.3-1.2">
              <t indent="0" pn="section-5.2.3-1.2.1">To specify temporal and spatial residual
          bandwidth from the specified source to the specified destination.
          The base semantics of the metric is the Unidirectional Residual
          Bandwidth metric as defined in <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>, <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>, and <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="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 <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/> <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/> <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/>. The spatial
          aggregation unit is specified in the query context (e.g., PID to
          PID, or endpoint to endpoint).</t>
              <t indent="0" pn="section-5.2.3-1.2.2">The default statistical operator for residual bandwidth is the
          current instantaneous sample; that is, the default is assumed to be
          "cur".</t>
            </dd>
            <dt pn="section-5.2.3-1.3">Use:</dt>
            <dd pn="section-5.2.3-1.4">This metric could be used as a cost metric constraint
              attribute or as a returned cost metric in the response.</dd>
          </dl>
          <figure anchor="example-7" align="left" suppress-title="false" pn="figure-9">
            <name slugifiedName="name-residual-bandwidth-value-on">Residual Bandwidth Value on Source-Destination Endpoint Pairs (Example 7)</name>
            <sourcecode type="json" markers="false" pn="section-5.2.3-2.1">
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 241
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

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

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

{
  "meta": {
    "cost-type": {
      "cost-mode":   "numerical",
      "cost-metric": "bw-residual"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.2":  {
      "ipv4:192.0.2.89":       0,
      "ipv4:198.51.100.34": 2000
    }
  }
}
</sourcecode>
          </figure>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.2.4">
          <name slugifiedName="name-cost-context-specification-consid">Cost-Context Specification Considerations</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-5.2.4-1">
            <dt pn="section-5.2.4-1.1">"nominal":</dt>
            <dd pn="section-5.2.4-1.2">Typically, residual bandwidth does not have a nominal
          value.</dd>
            <dt pn="section-5.2.4-1.3">"sla":</dt>
            <dd pn="section-5.2.4-1.4">Typically, residual bandwidth does not have an SLA
          value.</dd>
            <dt pn="section-5.2.4-1.5">"estimation":</dt>
            <dd pn="section-5.2.4-1.6">See the "estimation" entry in <xref target="ccspec-ow" format="default" sectionFormat="of" derivedContent="Section 4.1.4"/>. The current ("cur")
          residual bandwidth of a path is the minimal residual
          bandwidth of all links on the path.</dd>
          </dl>
        </section>
      </section>
      <section anchor="bwavailable" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-cost-metric-available-bandw">Cost Metric: Available Bandwidth (bw-available)</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.3.1">
          <name slugifiedName="name-base-identifier-8">Base Identifier</name>
          <t indent="0" pn="section-5.3.1-1">The base identifier for this performance metric is
          "bw-available".</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.3.2">
          <name slugifiedName="name-value-representation-8">Value Representation</name>
          <t indent="0" pn="section-5.3.2-1">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 numbered="true" toc="include" removeInRFC="false" pn="section-5.3.3">
          <name slugifiedName="name-intended-semantics-and-use-8">Intended Semantics and Use</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-5.3.3-1">
            <dt pn="section-5.3.3-1.1">Intended Semantics:</dt>
            <dd pn="section-5.3.3-1.2">
              <t indent="0" pn="section-5.3.3-1.2.1">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 <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>, <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>, and <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="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 spatial aggregation unit is
          specified in the query context (e.g., PID to PID, or endpoint to
          endpoint).</t>
              <t indent="0" pn="section-5.3.3-1.2.2">The default statistical operator for available bandwidth is the
          current instantaneous sample; that is, the default is assumed to be
          "cur".</t>
            </dd>
            <dt pn="section-5.3.3-1.3">Use:</dt>
            <dd pn="section-5.3.3-1.4">This metric could be used as a cost metric constraint
              attribute or as a returned cost metric in the response.</dd>
          </dl>
          <figure anchor="example-8" align="left" suppress-title="false" pn="figure-10">
            <name slugifiedName="name-available-bandwidth-value-o">Available Bandwidth Value on Source-Destination Endpoint Pairs (Example 8)</name>
            <sourcecode type="json" markers="false" pn="section-5.3.3-2.1">
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 244
Content-Type: application/alto-endpointcostparams+json
Accept:
  application/alto-endpointcost+json,application/alto-error+json

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

HTTP/1.1 200 OK
Content-Length: 255
Content-Type: application/alto-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
    }
  }
}
</sourcecode>
          </figure>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.3.4">
          <name slugifiedName="name-cost-context-specification-conside">Cost-Context Specification Considerations</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-5.3.4-1">
            <dt pn="section-5.3.4-1.1">"nominal":</dt>
            <dd pn="section-5.3.4-1.2">Typically, available bandwidth does not have a nominal
          value.</dd>
            <dt pn="section-5.3.4-1.3">"sla":</dt>
            <dd pn="section-5.3.4-1.4">Typically, available bandwidth does not have an SLA
          value.</dd>
            <dt pn="section-5.3.4-1.5">"estimation":</dt>
            <dd pn="section-5.3.4-1.6">See the "estimation" entry in <xref target="ccspec-ow" format="default" sectionFormat="of" derivedContent="Section 4.1.4"/>. The current ("cur")
          available bandwidth of a path is the minimum of the available
          bandwidth of all links on the path.</dd>
          </dl>
        </section>
      </section>
    </section>
    <section anchor="secopconsider" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-operational-considerations">Operational Considerations</name>
      <t indent="0" pn="section-6-1">The exact measurement infrastructure, measurement conditions, and
      computation algorithms can vary between different networks and are outside
      the scope of this document. Both the ALTO server and the ALTO clients,
      however, need to be cognizant of the operational issues discussed in the
      following subsections.</t>
      <t indent="0" pn="section-6-2">Also, the performance metrics specified in this document are similar
      in that they may use similar data sources and have similar issues in
      their calculation. Hence, this document specifies issues that the
      performance metrics might have in common and also discusses challenges
      regarding the computation of ALTO performance metrics (<xref target="comp-consider" format="default" sectionFormat="of" derivedContent="Section 6.4"/>).</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-source-considerations">Source Considerations</name>
        <t indent="0" pn="section-6.1-1">The addition of the "cost-source" field solves a key issue: an
        ALTO server needs data sources to compute the cost metrics described
        in this document, and an ALTO client needs to know the data sources to
        better interpret the values.</t>
        <t indent="0" pn="section-6.1-2">To avoid information that is too fine grained, this document introduces
        "cost-source" to indicate only the high-level types of data sources:
        "estimation", "nominal", or "sla", where "estimation" is a type of
        measurement data source, "nominal" is a type of static configuration,
        and "sla" is a type that is based more on policy.</t>
        <t indent="0" pn="section-6.1-3">For example, for "estimation", the ALTO server may use log servers or
        the Operations, Administration, and Maintenance (OAM) system as its data source, as recommended by <xref target="RFC7971" format="default" sectionFormat="of" derivedContent="RFC7971"/>. In particular, the cost metrics defined in
        this document can be computed using routing systems as the data
        sources.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-metric-timestamp-considerat">Metric Timestamp Considerations</name>
        <t indent="0" pn="section-6.2-1">Despite the introduction of the additional "cost-context"
        information, the metrics do not have a field to indicate the
        timestamps of the data used to compute the metrics. To indicate this
        attribute, the ALTO server <bcp14>SHOULD</bcp14> return an HTTP Last-Modified value to
        indicate the freshness of the data used to compute the performance
        metrics.</t>
        <t indent="0" pn="section-6.2-2">If the ALTO client obtains updates through an incremental update
        mechanism <xref target="RFC8895" format="default" sectionFormat="of" derivedContent="RFC8895"/>, the client <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 numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-backward-compatibility-cons">Backward-Compatibility Considerations</name>
        <t indent="0" pn="section-6.3-1">One potential issue introduced by the optional "cost-source" field
        is backward compatibility. Consider the case where an IRD defines two
        "cost-type" entries with the same "cost-mode" and "cost-metric", but one with
        "cost-source" being "estimation" and the other being "sla". In such a case, an
        ALTO client that is not aware of the extension will not be able to
        distinguish between these two types. A similar issue can arise even
        with a single "cost-type" whose "cost-source" is "sla": an ALTO client
        that is not aware of this extension will ignore this field and instead
        consider the metric estimation.</t>
        <t indent="0" pn="section-6.3-2">To address the backward-compatibility issue, if a "cost-metric" is
        "routingcost" and the metric contains a "cost-context" field, then it
        <bcp14>MUST</bcp14> be "estimation"; if it is not, the client <bcp14>SHOULD</bcp14> reject the
        information as invalid.</t>
      </section>
      <section anchor="comp-consider" numbered="true" toc="include" removeInRFC="false" pn="section-6.4">
        <name slugifiedName="name-computation-considerations">Computation Considerations</name>
        <t indent="0" pn="section-6.4-1">The metric values exposed by an ALTO server may result from
        additional processing of measurements from data sources to compute
        exposed metrics. This may involve data processing tasks such as
        aggregating the results across multiple systems, removing outliers,
        and creating additional statistics. The computation of ALTO performance metrics can present two challenges.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-6.4.1">
          <name slugifiedName="name-configuration-parameter-con">Configuration Parameter Considerations</name>
          <t indent="0" pn="section-6.4.1-1">Performance metrics often depend on configuration parameters, and
          exposing such configuration parameters can help an ALTO client to
          better understand the exposed metrics. In particular, an ALTO server
          may be configured to compute a TE metric (e.g., packet loss rate) at
          fixed intervals, say every T seconds. To expose this information,
          the ALTO server may provide the client with two pieces of additional
          information: (1) when the metrics were last computed and (2) when
          the metrics will be updated (i.e., the validity period of the
          exposed metric values). The ALTO server can expose these two pieces
          of information by using the HTTP response headers Last-Modified and
          Expires.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-6.4.2">
          <name slugifiedName="name-aggregation-computation-con">Aggregation Computation Considerations</name>
          <t indent="0" pn="section-6.4.2-1">An ALTO server may not be able to measure the performance metrics
          to be exposed. The basic issue is that the "source" information can
          often be link-level information. For example, routing protocols often measure
          and report only per-link loss and not end-to-end loss; similarly,
          routing protocols report link-level available bandwidth and not
          end-to-end available bandwidth. The ALTO server then needs to
          aggregate these data to provide an abstract and unified view that
          can be more useful to applications. The server should be aware that
          different metrics may use different aggregation computations. For
          example, the end-to-end latency of a path is the sum of the latencies
          of the links on the path; the end-to-end available bandwidth of a
          path is the minimum of the available bandwidth of the links on the
          path; in contrast, aggregating loss values is complicated by the
          potential for correlated loss events on different links in the
          path.</t>
        </section>
      </section>
    </section>
    <section anchor="secsecconsider" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">The properties defined in this document present no security
      considerations beyond those in Section <xref target="RFC7285" section="15" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-15" derivedContent="RFC7285"/> of the base ALTO
      specification <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/>.</t>
      <t indent="0" pn="section-7-2">However, concerns addressed in Sections <xref target="RFC7285" section="15.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-15.1" derivedContent="RFC7285"/>, <xref target="RFC7285" section="15.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-15.2" derivedContent="RFC7285"/>, and <xref target="RFC7285" section="15.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-15.3" derivedContent="RFC7285"/> of <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/> remain of utmost importance. Indeed,
      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 of the
      risks attached to such information that they would have acquired outside
      formal conditions of mutual trust.</t>
      <t indent="0" pn="section-7-3">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 or third parties through
      such attacks as person-in-the-middle (PITM) attacks. As specified in
      Section <xref target="RFC7285" section="15.3.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-15.3.2" derivedContent="RFC7285">"Protection Strategies"</xref> of <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/>,
the ALTO server should authenticate ALTO
      clients when transmitting an ALTO information resource containing
      sensitive TE performance metrics. Section <xref target="RFC7285" section="8.3.5" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-8.3.5" derivedContent="RFC7285">"Authentication and Encryption"</xref> of <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/> specifies that ALTO
      server implementations as well as ALTO client implementations <bcp14>MUST</bcp14>
      support the "https" URI scheme <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="RFC9110"/> and
      Transport Layer Security (TLS) <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>.</t>
    </section>
    <section anchor="ianaconsider" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-8.1">
        <name slugifiedName="name-alto-cost-metrics-registry">ALTO Cost Metrics Registry</name>
        <t indent="0" pn="section-8.1-1">IANA created and now maintains the "ALTO Cost Metrics" registry, as
      listed in <xref target="RFC7285" section="14.2" sectionFormat="comma" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-14.2" derivedContent="RFC7285"/>, Table 3. This registry is located at
<eref target="https://www.iana.org/assignments/alto-protocol/" brackets="angle"/>.
      IANA has added the following entries to the "ALTO
      Cost Metrics" registry.</t>
        <table align="center" pn="table-2">
          <name slugifiedName="name-alto-cost-metrics-registry-2">ALTO Cost Metrics Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Identifier</th>
              <th align="left" colspan="1" rowspan="1">Intended Semantics</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">delay-ow</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="oneway" format="default" sectionFormat="of" derivedContent="Section 4.1"/></td>
              <td align="left" colspan="1" rowspan="1">RFC 9439</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">delay-rt</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="delayrt" format="default" sectionFormat="of" derivedContent="Section 4.2"/></td>
              <td align="left" colspan="1" rowspan="1">RFC 9439</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">delay-variation</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="delayvar" format="default" sectionFormat="of" derivedContent="Section 4.3"/></td>
              <td align="left" colspan="1" rowspan="1">RFC 9439</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">lossrate</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="lossrate" format="default" sectionFormat="of" derivedContent="Section 4.4"/></td>
              <td align="left" colspan="1" rowspan="1">RFC 9439</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">hopcount</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="hopcount" format="default" sectionFormat="of" derivedContent="Section 4.5"/></td>
              <td align="left" colspan="1" rowspan="1">RFC 9439</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">tput</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="tput" format="default" sectionFormat="of" derivedContent="Section 5.1"/></td>
              <td align="left" colspan="1" rowspan="1">RFC 9439</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">bw-residual</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="bwresidual" format="default" sectionFormat="of" derivedContent="Section 5.2"/></td>
              <td align="left" colspan="1" rowspan="1">RFC 9439</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">bw-available</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="bwavailable" format="default" sectionFormat="of" derivedContent="Section 5.3"/></td>
              <td align="left" colspan="1" rowspan="1">RFC 9439</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-8.2">
        <name slugifiedName="name-alto-cost-source-types-regi">ALTO Cost Source Types Registry</name>
        <t indent="0" pn="section-8.2-1">IANA has created the "ALTO Cost Source Types"
      registry. This registry serves two purposes. First, it ensures the
      uniqueness of identifiers referring to ALTO cost source types. Second,
      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 indent="0" pn="section-8.2-2">A new ALTO cost source type can be added after IETF Review <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>, to ensure that proper documentation regarding
      the new ALTO cost source type and its security considerations 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 indent="0" pn="section-8.2-3">Registered ALTO address type identifiers <bcp14>MUST</bcp14> conform to the
      syntactical requirements specified in <xref target="meta" sectionFormat="bare" format="default" derivedContent="Section 3.1"/>. Identifiers are to be
      recorded and displayed as strings.</t>
        <t indent="0" pn="section-8.2-4">Requests to add a new value to the registry <bcp14>MUST</bcp14> include the
      following information: </t>
        <dl indent="3" newline="false" spacing="normal" pn="section-8.2-5">
          <dt pn="section-8.2-5.1">Identifier:</dt>
          <dd pn="section-8.2-5.2">The name of the desired ALTO cost source type.</dd>
          <dt pn="section-8.2-5.3">Intended Semantics:</dt>
          <dd pn="section-8.2-5.4"> ALTO cost source 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.</dd>
          <dt pn="section-8.2-5.5">Security Considerations:</dt>
          <dd pn="section-8.2-5.6"> 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.</dd>
        </dl>
        <t indent="0" pn="section-8.2-6">IANA has registered the identifiers
      "nominal", "sla", and "estimation" as listed in the table below.</t>
        <table align="center" pn="table-3">
          <name slugifiedName="name-alto-cost-source-types-regis">ALTO Cost Source Types Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Identifier</th>
              <th align="left" colspan="1" rowspan="1">Intended Semantics</th>
              <th align="left" colspan="1" rowspan="1">Security Considerations</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">nominal</td>
              <td align="left" colspan="1" rowspan="1">Values in nominal cases (<xref target="meta" format="default" sectionFormat="of" derivedContent="Section 3.1"/>)</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="secsecconsider" format="default" sectionFormat="of" derivedContent="Section 7"/></td>
              <td align="left" colspan="1" rowspan="1">RFC 9439</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">sla</td>
              <td align="left" colspan="1" rowspan="1">Values reflecting Service Level Agreement (<xref target="meta" format="default" sectionFormat="of" derivedContent="Section 3.1"/>)</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="secsecconsider" format="default" sectionFormat="of" derivedContent="Section 7"/></td>
              <td align="left" colspan="1" rowspan="1">RFC 9439</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">estimation</td>
              <td align="left" colspan="1" rowspan="1">Values by estimation (<xref target="meta" format="default" sectionFormat="of" derivedContent="Section 3.1"/>)</td>
              <td align="left" colspan="1" rowspan="1">
                <xref target="secsecconsider" format="default" sectionFormat="of" derivedContent="Section 7"/></td>
              <td align="left" colspan="1" rowspan="1">RFC 9439</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.corre-quic-throughput-testing" to="QUIC-THROUGHPUT-TESTING"/>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="IANA-IPPM" target="https://www.iana.org/assignments/performance-metrics/" quoteTitle="true" derivedAnchor="IANA-IPPM">
          <front>
            <title>Performance Metrics</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3630" target="https://www.rfc-editor.org/info/rfc3630" quoteTitle="true" derivedAnchor="RFC3630">
          <front>
            <title>Traffic Engineering (TE) Extensions to OSPF Version 2</title>
            <author fullname="D. Katz" initials="D." surname="Katz"/>
            <author fullname="K. Kompella" initials="K." surname="Kompella"/>
            <author fullname="D. Yeung" initials="D." surname="Yeung"/>
            <date month="September" year="2003"/>
            <abstract>
              <t indent="0">This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3630"/>
          <seriesInfo name="DOI" value="10.17487/RFC3630"/>
        </reference>
        <reference anchor="RFC5305" target="https://www.rfc-editor.org/info/rfc5305" quoteTitle="true" derivedAnchor="RFC5305">
          <front>
            <title>IS-IS Extensions for Traffic Engineering</title>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="H. Smit" initials="H." surname="Smit"/>
            <date month="October" year="2008"/>
            <abstract>
              <t indent="0">This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5305"/>
          <seriesInfo name="DOI" value="10.17487/RFC5305"/>
        </reference>
        <reference anchor="RFC6390" target="https://www.rfc-editor.org/info/rfc6390" quoteTitle="true" derivedAnchor="RFC6390">
          <front>
            <title>Guidelines for Considering New Performance Metric Development</title>
            <author fullname="A. Clark" initials="A." surname="Clark"/>
            <author fullname="B. Claise" initials="B." surname="Claise"/>
            <date month="October" year="2011"/>
            <abstract>
              <t indent="0">This document describes a framework and a process for developing Performance Metrics of protocols and applications transported over IETF-specified protocols. These metrics can be used to characterize traffic on live networks and services. This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="170"/>
          <seriesInfo name="RFC" value="6390"/>
          <seriesInfo name="DOI" value="10.17487/RFC6390"/>
        </reference>
        <reference anchor="RFC7285" target="https://www.rfc-editor.org/info/rfc7285" quoteTitle="true" derivedAnchor="RFC7285">
          <front>
            <title>Application-Layer Traffic Optimization (ALTO) Protocol</title>
            <author fullname="R. Alimi" initials="R." role="editor" surname="Alimi"/>
            <author fullname="R. Penno" initials="R." role="editor" surname="Penno"/>
            <author fullname="Y. Yang" initials="Y." role="editor" surname="Yang"/>
            <author fullname="S. Kiesel" initials="S." surname="Kiesel"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="W. Roome" initials="W." surname="Roome"/>
            <author fullname="S. Shalunov" initials="S." surname="Shalunov"/>
            <author fullname="R. Woundy" initials="R." surname="Woundy"/>
            <date month="September" year="2014"/>
            <abstract>
              <t indent="0">Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.</t>
              <t indent="0">The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.</t>
              <t indent="0">This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7285"/>
          <seriesInfo name="DOI" value="10.17487/RFC7285"/>
        </reference>
        <reference anchor="RFC7471" target="https://www.rfc-editor.org/info/rfc7471" quoteTitle="true" derivedAnchor="RFC7471">
          <front>
            <title>OSPF Traffic Engineering (TE) Metric Extensions</title>
            <author fullname="S. Giacalone" initials="S." surname="Giacalone"/>
            <author fullname="D. Ward" initials="D." surname="Ward"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="A. Atlas" initials="A." surname="Atlas"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <date month="March" year="2015"/>
            <abstract>
              <t indent="0">In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection.</t>
              <t indent="0">This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance.</t>
              <t indent="0">Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7471"/>
          <seriesInfo name="DOI" value="10.17487/RFC7471"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" quoteTitle="true" derivedAnchor="RFC8259">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
            <date month="December" year="2017"/>
            <abstract>
              <t indent="0">JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t>
              <t indent="0">This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="90"/>
          <seriesInfo name="RFC" value="8259"/>
          <seriesInfo name="DOI" value="10.17487/RFC8259"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC8570" target="https://www.rfc-editor.org/info/rfc8570" quoteTitle="true" derivedAnchor="RFC8570">
          <front>
            <title>IS-IS Traffic Engineering (TE) Metric Extensions</title>
            <author fullname="L. Ginsberg" initials="L." role="editor" surname="Ginsberg"/>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="S. Giacalone" initials="S." surname="Giacalone"/>
            <author fullname="D. Ward" initials="D." surname="Ward"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <date month="March" year="2019"/>
            <abstract>
              <t indent="0">In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.</t>
              <t indent="0">This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.</t>
              <t indent="0">Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.</t>
              <t indent="0">This document obsoletes RFC 7810.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8570"/>
          <seriesInfo name="DOI" value="10.17487/RFC8570"/>
        </reference>
        <reference anchor="RFC8571" target="https://www.rfc-editor.org/info/rfc8571" quoteTitle="true" derivedAnchor="RFC8571">
          <front>
            <title>BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions</title>
            <author fullname="L. Ginsberg" initials="L." role="editor" surname="Ginsberg"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <date month="March" year="2019"/>
            <abstract>
              <t indent="0">This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8571"/>
          <seriesInfo name="DOI" value="10.17487/RFC8571"/>
        </reference>
        <reference anchor="RFC8895" target="https://www.rfc-editor.org/info/rfc8895" quoteTitle="true" derivedAnchor="RFC8895">
          <front>
            <title>Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)</title>
            <author fullname="W. Roome" initials="W." surname="Roome"/>
            <author fullname="Y. Yang" initials="Y." surname="Yang"/>
            <date month="November" year="2020"/>
            <abstract>
              <t indent="0">The Application-Layer Traffic Optimization (ALTO) protocol (RFC 7285) provides network-related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8895"/>
          <seriesInfo name="DOI" value="10.17487/RFC8895"/>
        </reference>
        <reference anchor="RFC9110" target="https://www.rfc-editor.org/info/rfc9110" quoteTitle="true" derivedAnchor="RFC9110">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t indent="0">This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="RFC9438" target="https://www.rfc-editor.org/info/rfc9438" quoteTitle="true" derivedAnchor="RFC9438">
          <front>
            <title>CUBIC for Fast and Long-Distance Networks</title>
            <author fullname="Lisong Xu">
</author>
            <author fullname="Sangtae Ha">
</author>
            <author fullname="Injong Rhee">
</author>
            <author fullname="Vidhi Goel">
</author>
            <author fullname="Lars Eggert" role="editor">
</author>
            <date month="August" year="2023"/>
          </front>
          <seriesInfo name="RFC" value="9438"/>
          <seriesInfo name="DOI" value="10.17487/RFC9438"/>
        </reference>
      </references>
      <references pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="FlowDirector" target="" quoteTitle="true" derivedAnchor="FlowDirector">
          <front>
            <title>Steering Hyper-Giants' Traffic at Scale</title>
            <author initials="E" surname="Pujol"/>
            <author initials="I" surname="Poese"/>
            <author initials="J" surname="Zerwas"/>
            <author initials="G" surname="Smaragdakis"/>
            <author initials="A" surname="Feldmann"/>
            <date month="December" year="2019"/>
          </front>
          <refcontent>ACM CoNEXT '19</refcontent>
        </reference>
        <reference anchor="G2" target="https://dl.acm.org/doi/10.1145/3366707" quoteTitle="true" derivedAnchor="G2">
          <front>
            <title>On the Bottleneck Structure of Congestion-Controlled Networks</title>
            <author initials="J" surname="Ros-Giralt"/>
            <author initials="A" surname="Bohara"/>
            <author initials="S" surname="Yellamraju"/>
            <author initials="M" surname="Harper Langston"/>
            <author initials="R" surname="Lethin"/>
            <author initials="Y" surname="Jiang"/>
            <author initials="L" surname="Tassiulas"/>
            <author initials="J" surname="Li"/>
            <author initials="Y" surname="Tan"/>
            <author initials="M" surname="Veeraraghavan"/>
            <date month="December" year="2019"/>
          </front>
          <refcontent>Proceedings of the ACM on Measurement and Analysis of Computing Systems, Vol. 3, No. 3, Article No. 59, pp. 1-31</refcontent>
          <seriesInfo name="DOI" value="10.1145/3366707"/>
        </reference>
        <reference anchor="Prometheus" target="" quoteTitle="true" derivedAnchor="Prometheus">
          <front>
            <title>Prometheus: A Next-Generation Monitoring System (Talk)</title>
            <author initials="J" surname="Volz"/>
            <author initials="B" surname="Rabenstein"/>
            <date month="May" year="2015"/>
          </front>
          <refcontent>SREcon15 Europe</refcontent>
        </reference>
        <reference anchor="Prophet" target="https://dl.acm.org/doi/10.1109/TNET.2020.3016838" quoteTitle="true" derivedAnchor="Prophet">
          <front>
            <title>Prophet: Toward Fast, Error-Tolerant Model-Based Throughput Prediction for Reactive Flows in DC Networks</title>
            <author initials="J" surname="Zhang"/>
            <author initials="K" surname="Gao"/>
            <author initials="YR" surname="Yang"/>
            <author initials="J" surname="Bi"/>
            <date month="December" year="2020"/>
          </front>
          <refcontent>IEEE/ACM Transactions on Networking, Volume 28, Issue 601, pp. 2475-2488</refcontent>
        </reference>
        <reference anchor="I-D.corre-quic-throughput-testing" target="https://datatracker.ietf.org/doc/html/draft-corre-quic-throughput-testing-00" quoteTitle="true" derivedAnchor="QUIC-THROUGHPUT-TESTING">
          <front>
            <title>Framework for QUIC Throughput Testing</title>
            <author initials="K." surname="Corre" fullname="Kevin Corre">
              <organization showOnFrontPage="true">EXFO</organization>
            </author>
            <date month="September" day="17" year="2021"/>
            <abstract>
              <t indent="0">   This document adapts the [RFC6349] Framework for TCP Throughput
   Testing to the [RFC9000] QUIC protocol.  The adapted framework
   describes a practical methodology for measuring end-to-end QUIC
   Throughput in a managed IP network.  The goal of the methodology is
   to provide a better indication in regard to user experience.  In this
   framework, QUIC, UDP, and IP parameters are specified to optimize
   QUIC Throughput.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-corre-quic-throughput-testing-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC2330" target="https://www.rfc-editor.org/info/rfc2330" quoteTitle="true" derivedAnchor="RFC2330">
          <front>
            <title>Framework for IP Performance Metrics</title>
            <author fullname="V. Paxson" initials="V." surname="Paxson"/>
            <author fullname="G. Almes" initials="G." surname="Almes"/>
            <author fullname="J. Mahdavi" initials="J." surname="Mahdavi"/>
            <author fullname="M. Mathis" initials="M." surname="Mathis"/>
            <date month="May" year="1998"/>
            <abstract>
              <t indent="0">The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2330"/>
          <seriesInfo name="DOI" value="10.17487/RFC2330"/>
        </reference>
        <reference anchor="RFC2681" target="https://www.rfc-editor.org/info/rfc2681" quoteTitle="true" derivedAnchor="RFC2681">
          <front>
            <title>A Round-trip Delay Metric for IPPM</title>
            <author fullname="G. Almes" initials="G." surname="Almes"/>
            <author fullname="S. Kalidindi" initials="S." surname="Kalidindi"/>
            <author fullname="M. Zekauskas" initials="M." surname="Zekauskas"/>
            <date month="September" year="1999"/>
            <abstract>
              <t indent="0">This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2681"/>
          <seriesInfo name="DOI" value="10.17487/RFC2681"/>
        </reference>
        <reference anchor="RFC3393" target="https://www.rfc-editor.org/info/rfc3393" quoteTitle="true" derivedAnchor="RFC3393">
          <front>
            <title>IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)</title>
            <author fullname="C. Demichelis" initials="C." surname="Demichelis"/>
            <author fullname="P. Chimento" initials="P." surname="Chimento"/>
            <date month="November" year="2002"/>
          </front>
          <seriesInfo name="RFC" value="3393"/>
          <seriesInfo name="DOI" value="10.17487/RFC3393"/>
        </reference>
        <reference anchor="RFC5357" target="https://www.rfc-editor.org/info/rfc5357" quoteTitle="true" derivedAnchor="RFC5357">
          <front>
            <title>A Two-Way Active Measurement Protocol (TWAMP)</title>
            <author fullname="K. Hedayat" initials="K." surname="Hedayat"/>
            <author fullname="R. Krzanowski" initials="R." surname="Krzanowski"/>
            <author fullname="A. Morton" initials="A." surname="Morton"/>
            <author fullname="K. Yum" initials="K." surname="Yum"/>
            <author fullname="J. Babiarz" initials="J." surname="Babiarz"/>
            <date month="October" year="2008"/>
            <abstract>
              <t indent="0">The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5357"/>
          <seriesInfo name="DOI" value="10.17487/RFC5357"/>
        </reference>
        <reference anchor="RFC7679" target="https://www.rfc-editor.org/info/rfc7679" quoteTitle="true" derivedAnchor="RFC7679">
          <front>
            <title>A One-Way Delay Metric for IP Performance Metrics (IPPM)</title>
            <author fullname="G. Almes" initials="G." surname="Almes"/>
            <author fullname="S. Kalidindi" initials="S." surname="Kalidindi"/>
            <author fullname="M. Zekauskas" initials="M." surname="Zekauskas"/>
            <author fullname="A. Morton" initials="A." role="editor" surname="Morton"/>
            <date month="January" year="2016"/>
            <abstract>
              <t indent="0">This memo defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2679 obsolete.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="81"/>
          <seriesInfo name="RFC" value="7679"/>
          <seriesInfo name="DOI" value="10.17487/RFC7679"/>
        </reference>
        <reference anchor="RFC7971" target="https://www.rfc-editor.org/info/rfc7971" quoteTitle="true" derivedAnchor="RFC7971">
          <front>
            <title>Application-Layer Traffic Optimization (ALTO) Deployment Considerations</title>
            <author fullname="M. Stiemerling" initials="M." surname="Stiemerling"/>
            <author fullname="S. Kiesel" initials="S." surname="Kiesel"/>
            <author fullname="M. Scharf" initials="M." surname="Scharf"/>
            <author fullname="H. Seidel" initials="H." surname="Seidel"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <date month="October" year="2016"/>
            <abstract>
              <t indent="0">Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. This memo discusses deployment-related issues of ALTO. It addresses different use cases of ALTO such as peer-to-peer file sharing and Content Delivery Networks (CDNs) and presents corresponding examples. The document also includes recommendations for network administrators and application designers planning to deploy ALTO, such as recommendations on how to generate ALTO map information.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7971"/>
          <seriesInfo name="DOI" value="10.17487/RFC7971"/>
        </reference>
        <reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9000" quoteTitle="true" derivedAnchor="RFC9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <date month="May" year="2021"/>
            <abstract>
              <t indent="0">This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">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>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Qin Wu" initials="Q." surname="Wu">
        <organization showOnFrontPage="true">Huawei</organization>
        <address>
          <postal>
            <extaddr>Yuhua District</extaddr>
            <street>101 Software 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 showOnFrontPage="true">Yale University</organization>
        <address>
          <postal>
            <street>51 Prospect 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 showOnFrontPage="true">Samsung</organization>
        <address>
          <email>younglee.tx@gmail.com</email>
        </address>
      </author>
      <author fullname="Dhruv Dhody" initials="D." surname="Dhody">
        <organization showOnFrontPage="true">Huawei</organization>
        <address>
          <postal>
            <country>India</country>
          </postal>
          <email>dhruv.ietf@gmail.com</email>
        </address>
      </author>
      <author fullname="Sabine Randriamasy" initials="S." surname="Randriamasy">
        <organization showOnFrontPage="true">Nokia Networks France</organization>
        <address>
          <postal>
            <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 showOnFrontPage="true">Telefonica</organization>
        <address>
          <postal>
            <street/>
            <city>Madrid</city>
            <region/>
            <code/>
            <country>Spain</country>
          </postal>
          <email>luismiguel.contrerasmurillo@telefonica.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
