<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-alto-incr-update-sse SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-alto-incr-update-sse.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC7285 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7285.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8189 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8189.xml">
<!ENTITY RFC8259 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml">
<!ENTITY I-D.ietf-alto-performance-metrics SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-alto-performance-metrics.xml">
<!ENTITY I-D.xiang-alto-multidomain-analytics SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.xiang-alto-multidomain-analytics.xml">
<!ENTITY IEEE.754.2008 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml6/reference.IEEE.754.2008.xml">
<!ENTITY RFC2818 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY RFC5246 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5693 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5693.xml">
<!ENTITY RFC6708 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6708.xml">
<!ENTITY RFC7159 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7159.xml">
<!ENTITY RFC7231 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml">
<!ENTITY RFC8446 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
]> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-ietf-alto-cost-calendar-21"
     category="std" ipr="trust200902"> consensus="true"
     docName="draft-ietf-alto-cost-calendar-21" number="8896"
     ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="true"
     symRefs="true" tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.42.0 -->
  <!-- Generated by id2xml 1.5.0 on 2020-02-23T20:23:49Z -->
	<?rfc compact="yes"?>
	<?rfc text-list-symbols="o*+-"?>
	<?rfc subcompact="no"?>
	<?rfc sortrefs="no"?>
	<?rfc symrefs="yes"?>
	<?rfc strict="yes"?>
	<?rfc toc="yes"?>
	<front>
    <title abbrev="ALTO Cost Calendar">Application-Layer Traffic Optimization
    (ALTO) Cost Calendar</title>
<seriesInfo name="RFC" value="8896"/>
    <author fullname="Sabine Randriamasy" initials="S." surname="Randriamasy">
      <organization>Nokia Bell Labs</organization>
	<address><postal><street>Route
      <address>
        <postal>
          <street>Route de Villejust</street>
	<street>NOZAY  91460</street>
	<street>FRANCE</street>
          <city>Nozay</city>
	  <code>91460</code>
          <country>France</country>
        </postal>
        <email>Sabine.Randriamasy@nokia-bell-labs.com</email>
      </address>
    </author>
    <author fullname="Richard fullname="Y. Richard Yang" initials="R." initials="Y." surname="Yang">
      <organization>Yale University</organization>
	<address><postal><street>51
      <address>
        <postal>
          <street>51 Prospect st</street>
	<street>New Haven, CT  06520</street>
	<street>USA</street> St.</street>
          <city>New Haven</city>
	  <region>CT</region>
	  <code>06520</code>
          <country>United States of America</country>
        </postal>
        <email>yry@cs.yale.edu</email>
      </address>
    </author>
    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>
	<address><postal><street>101
      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>
	<street>Nanjing, Jiangsu  210012</street>
	<street>China</street> Avenue</street>
	  <extaddr>Yuhua District</extaddr>
          <city>Nanjing</city>
	  <region>Jiangsu</region>
	  <code>210012</code>
          <country>China</country>
        </postal>
        <email>sunseawq@huawei.com</email>
      </address>
    </author>
    <author fullname="Lingli Deng" initials="L." surname="Deng">
      <organization>China Mobile</organization>
	<address><postal><street>China</street>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>denglingli@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Nico Schwan" initials="N." surname="Schwan">
      <organization>Thales Deutschland</organization>
	<address><postal><street>Lorenzstrasse
      <address>
        <postal>
          <street>Lorenzstrasse 10</street>
	<street>Stuttgart  70435</street>
	<street>Germany</street>
          <city>Stuttgart</city><code>70435</code>
          <country>Germany</country>
        </postal>
        <email>nico.schwan@thalesgroup.com</email>
      </address>
    </author>
    <date day="17" month="March" year="2020"/>
	<abstract><t>
   This year="2020" month="November" />

    <abstract>
      <t>This document is an extension to the base Application-Layer Traffic
      Optimization (ALTO) protocol.  It extends the ALTO cost information
      service so that applications decide not only 'where' to connect, connect but
      also 'when'.  This is useful for applications that need to perform bulk
      data transfer and would like to schedule these transfers during an
      off-peak hour, for example.  This extension introduces the ALTO Cost
   Calendar,
      Calendar with which an ALTO Server exposes ALTO cost values in JSON
      arrays where each value corresponds to a given time interval.  The time intervals
      intervals, as well as other Calendar attributes, are specified in the
      Information Resources Directory and ALTO Server responses.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sect-1"><t>
   The anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The base Application-Layer Traffic Optimization (ALTO) protocol
      specified in <xref target="RFC7285"/> target="RFC7285" format="default"/> provides guidance
      to overlay applications that need to select one or several hosts from a
      set of candidates able to provide a desired resource.  This guidance is
      based on parameters that affect performance and efficiency of the data
      transmission between the hosts hosts, such as the topological distance.  The
      goal of ALTO is to improve the Quality of Experience (QoE) in the
      application while optimizing resource usage in the underlying network
      infrastructure.</t>

	<t>
   The
      <t>The ALTO protocol in <xref target="RFC7285"/> target="RFC7285" format="default"/>
      specifies a network map which that defines groupings of endpoints in
      provider-defined network regions identified by Provider-defined
      Identifiers (PIDs).  The Cost Map Service, Endpoint Cost Service (ECS) (ECS),
      and Endpoint Ranking Service then provide ISP-defined costs and rankings
      for connections among the specified endpoints and PIDs and thus
      incentives for application clients to connect to ISP preferred ISP-preferred
      locations, for instance, to reduce their costs.  For the reasons
      outlined in the ALTO problem statement <xref target="RFC5693"/> target="RFC5693"
      format="default"/> and requirement AR-14 of <xref target="RFC6708"/>, target="RFC6708"
      format="default"/>, ALTO does not disseminate network metrics that
      change frequently.  In a network, the costs can fluctuate for many
      reasons having to do with instantaneous traffic load or due to diurnal
      patterns of traffic demand or planned events events, such as network
      maintenance, holidays holidays, or highly publicized events.  Thus, an ALTO
      application wishing to use the Cost Map and Endpoint Cost Service at
      some future time will have to estimate the state of the network at that
      time, a process that is, at best, fragile and brittle brittle, since the
      application does not have any visibility into the state of the network.
      Providing network costs for only the current time thus may not be
      sufficient, in particular for applications that can schedule their
      traffic in a span of time, for example example, by deferring backups or other
      background traffic to off- peak hours.</t>

	<t>
   In
      <t>In case the ALTO Cost cost value changes are predictable over a certain
      period of time and the application does not require immediate data
      transfer, it can save time to get the whole set of cost values over this
      period in one single ALTO response.  Using this set to schedule data
      transfers allows optimizing the network resources usage and QoE. ALTO
      Clients and Servers can also minimize their workload by reducing and
      accordingly scheduling their data exchanges.</t>

	<t>
   This
      <t>This document extends <xref target="RFC7285"/> target="RFC7285" format="default"/> to
      allow an ALTO Server to provide network costs for a given duration of
      time.  A sequence of network costs across a time span for a given pair
      of network locations is named an "ALTO Cost Calendar".  The Filtered
      Cost Map Service and Endpoint Cost Service are extended to provide Cost
      Calendars.  In addition to this functional ALTO enhancement, we expect
      to further save network and storage resources by gathering multiple Cost Values cost
      values for one cost type into one single ALTO Server response.</t>

	<t>
   In
      <t>In this document, an "ALTO Cost Calendar" is specified in terms of
      information resource capabilities that are applicable to time-
   sensitive time-sensitive
      ALTO metrics.  An ALTO Cost Calendar exposes ALTO Cost
   Values cost values in JSON
      arrays, see <xref target="RFC8259"/>, target="RFC8259" format="default"/>, where each value
      corresponds to a given time interval.  The time intervals intervals, as well as
      other Calendar
   attributes attributes, are specified in the Information Resources
      Directory (IRD) and in the Server response to allow the ALTO Client to
      interpret the received ALTO values.  Last, the extensions for ALTO
      Calendars are applicable to any Cost Mode cost mode, and they ensure backwards
      compatibility with legacy ALTO Clients - -- those that only support <xref target="RFC7285"/>.</t>

	<t>
   In
      target="RFC7285" format="default"/>.</t>
      <t>In the rest of this document, <xref target="sect-3"/> target="sect-3"
      format="default"/> provides the design characteristics.  Sections <xref target="sect-4"/>
      target="sect-4" format="counter"/> and <xref target="sect-5"/> target="sect-5"
      format="counter"/> define the formal specifications for the IRD and the
      information resources. IANA, security considerations, and operational
      considerations are addressed respectively in sections Sections <xref target="sect-6"/>,
      target="sect-6" format="counter"/>, <xref target="sect-7"/> target="sect-7"
      format="counter"/>, and <xref target="sect-8"/>.</t> target="sect-8" format="counter"/>.</t>
      <section title="Some recent known uses" anchor="sect-1.1"> anchor="sect-1.1" numbered="true" toc="default">
        <name>Some Recent Known Uses</name>
        <t> A potential use case is implementing smart network services that
	allow applications to dynamically build end-to-end, virtual networks, networks
	to satisfy given demands, demands with no manual intervention. For  example,
	data-transfer automation applications may need a network service to
	determine on the availability of bandwidth resources, resources to decide when
	to transfer their data sets. The SENSE project
   [SENSE-sdn-e2e-net]  <xref
	target="SENSE" format="default"/> supports such
	applications by requiring that a network provides services such as the
	Time-Bandwidth-Product (TBP) service, which informs applications of
	bandwidth availability during a specific time period. ALTO Calendars
	can support this service if the Calendar start date and duration cover
	the period of interest of the requesting application.
      </t>

	   <t>
       The application.</t>
        <t>The need of future scheduling of large scale large-scale traffic that can be
	addressed by the ALTO protocol is also motivated by Unicorn, a unified
	resource orchestration framework for multi-domain, geo-
       distributed geo-distributed
	data analytics, see <xref target="Unicorn-fgcs"/>.
      </t> target="UNICORN-FGCS"
	format="default"/>.</t>
      </section>
      <section title="Terminology" anchor="sect-1.2"><t><list style="symbols">
	<t>ALTO transaction: A anchor="sect-1.2" numbered="true" toc="default">
        <name>Terminology</name>
        <dl newline="true" spacing="normal">
          <dt>ALTO transaction:</dt>
	  <dd>A request/response exchange between an ALTO
      Client and an ALTO Server.</t>

	<t>Client: When Server.</dd>
          <dt>Client:</dt>
	  <dd>When used with a capital "C", this term refers to an ALTO
      Client.</t>

	<t>Calendar,
	  Client.</dd>
          <dt>Calendar, Cost Calendar: When Calendar, ALTO Calendar:</dt>
	  <dd>When used with capitalized words, these terms refer to an ALTO
	  Cost Calendar.</t>

      <t>Calendared: this Calendar.</dd>
          <dt>Calendared:</dt>
	  <dd>This adjective qualifies information resources providing Cost
	  Calendars and information on costs that are provided in the form of
	  a Cost Calendar.</t>

	<t>Endpoint (EP): An Calendar.</dd>
          <dt>Endpoint (EP):</dt>
	  <dd>An endpoint is defined as in Section 2.1 of <xref target="RFC7285"/>. target="RFC7285"
	  sectionFormat="of" section="2.1"/>.  It can be, for example, a peer,
	  a CDN storage location, a physical server involved in a virtual
	  server-supported application, a party in a resource-sharing swarm
	  such as a computation grid, or an online multi-party game.</t>

      <t>ECM: Is an game.</dd>
          <dt>ECM:</dt>
	  <dd>An abbreviation for Endpoint Cost Map.</t>

      <t>FCM: Is an Map.</dd>
          <dt>FCM:</dt>
	  <dd>An abbreviation for Filtered Cost Map.</t>

	<t>Server: When Map.</dd>
          <dt>Server:</dt>
	  <dd>When used with a capital "S", this term refers to an ALTO
      Server.</t>

	</list>
	</t> Server.</dd>
        </dl>
      </section>
    </section>
    <section title="Requirements Language" anchor="sect-2"><t> anchor="sect-2" numbered="true" toc="default">
      <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
   "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as
    described in
   BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t>

	<t>
   When here.
        </t>
      <t>When the words appear in lower case, they are to be interpreted with
      their natural language meanings.</t>
    </section>
    <section title="Overview anchor="sect-3" numbered="true" toc="default">
      <name>Overview of ALTO Cost Calendars and terminology" anchor="sect-3"> Terminology</name>
      <t>This section gives a high-level overview of the design.
      <!--It sets rules to ensure backwards compatibility with legacy ALTO Clients
      in <xref target="sect-3.3.2"/> .-->

      It assumes the reader is familiar with the ALTO protocol <xref target="RFC7285"/>
      target="RFC7285" format="default"/> and its Multi-Cost ALTO extension
      <xref target="RFC8189"/>.
      </t> target="RFC8189" format="default"/>.</t>
      <section title="ALTO anchor="sect-3.1" numbered="true" toc="default">
        <name>ALTO Cost Calendar overview" anchor="sect-3.1"> Overview</name>
        <t>An ALTO Cost Calendar provided by the ALTO Server provides 2
         information items:</t>

	      <t>
            <list style="symbols"><t>an
        <ul spacing="normal">
          <li>an array of values for a given metric, where each value
	  specifies the metric corresponding to a time interval, where the
	  value array can sometimes be a cyclic pattern that repeats a certain
	  number of
             times.</t>

	          <t>attributes times and</li>
          <li>attributes describing the time scope of the Calendar, including
	  the size and number of the intervals and the date of the starting
	  point of the Calendar, allowing an ALTO Client to interpret the
	  values properly.</t>
	         </list>
	      </t>

	<t>
   An properly.</li>
        </ul>
        <t>An ALTO Cost Calendar can be used like a "time table" to figure out
	the best time to schedule data transfers and also to proactively
	manage application traffic given predictable events events, such as an expected
	spike in traffic due to crowd gathering (concerts, sports, etc.),
	traffic-intensive holidays holidays, and network maintenance.  A Calendar may be
	viewed as a synthetic abstraction of, for example, real measurements
	gathered over previous periods on which statistics have been computed.
	However, like for any schedule, unexpected network incidents may
	require the current ALTO Calendar to be updated and re-
   sent resent to the
	ALTO Clients needing it.  The "ALTO Incremental Updates Using
	Server-Sent Events (SSE)" Service <xref target="I-D.ietf-alto-incr-update-sse"/> target="RFC8895"
	format="default"/> can be used to  directly update the Calendar upon
	value changes, changes if supported by both the Server and the Client.</t>
        <t>
   Most likely, the ALTO Cost Calendar would be used for the Endpoint
   Cost Service, assuming that a limited set of feasible Endpoints endpoints for a
   non-real time application is already identified, and that they those
   endpoints do not need to be accessed immediately and that their
   access can be scheduled within a given time period.
	The Filtered Cost Map Service is also
	applicable as long as the size of the Map allows it.</t>
      </section>
      <section title="ALTO anchor="sect-3.2" numbered="true" toc="default">
        <name>ALTO Cost Calendar information features" anchor="sect-3.2"><t> Information Features</name>
        <t>
   The Calendar attributes are provided in the Information Resources
   Directory (IRD) and in ALTO Server responses.  The IRD announces
   attributes without date values
   in its information resources capabilities, whereas attributes with
   time dependent
   time-dependent values are provided in the "meta" section of Server responses.
   The ALTO Cost Calendar attributes provide the following information:</t>

	<t><list style="symbols">
        <ul spacing="normal">
          <li>
            <t>attributes to describe the time scope of the Calendar value array:
         <list style="symbols">
            <!-- <t>The time is always expressed in UTC,
            </t> -->

	         <t>"time-interval-size":
            <ul spacing="normal">

	      <li>"time-interval-size": the applicable time interval size for
	      each Calendar value, defined in seconds, that can cover a wide
	      range of values.
            </t>

	         <t>"number-of-intervals": values.</li>
              <li>"number-of-intervals": the number of intervals provided in
	      the Calendar.
            </t>
	      </list>
	    </t>

	    <t>"calendar-start-time": Calendar.</li>
            </ul>
          </li>
          <li>"calendar-start-time": specifying when the Calendar starts, starts; that
        is
	  is, to which date the first value of the Cost Calendar is
        applicable.</t>

	    <t>"repeated":
	  applicable.</li>
          <li>"repeated": an optional attribute indicating how many iterations
	  of the provided Calendar will have the same values.  The Server may
	  use it to allow the Client to schedule its next request and thus
	  save its own workload by reducing processing of similar
       requests.</t>

	  </list>
	</t>

	<t>
   Attribute
	  requests.</li>
        </ul>
        <t>Attribute "repeated" may take a very high value if a Calendar
	represents a cyclic value pattern that the Server considers valid for
	a long period.  In this case, the Server will only update the Calendar
	values once this period has elapsed or if an unexpected event occurs
	on the network. See <xref target="sect-8"/> target="sect-8" format="default"/> for more
	discussion.</t>
      </section>
      <section title="ALTO anchor="sect-3.3" numbered="true" toc="default">
        <name>ALTO Calendar design characteristics" anchor="sect-3.3"> Design Characteristics</name>
        <t>The present document uses the notations defined in Section "8.2 Notation" of
	<xref target="RFC7285"/>.</t> "Notation"
	(<xref target="RFC7285" sectionFormat="of" section="8.2"/>).</t>
        <t>The extensions in this document encode requests and responses using
	JSON <xref target="RFC8259"/>.</t>

	<t>
   In target="RFC8259" format="default"/>.</t>

        <t>In the base protocol <xref target="RFC7285"/> section 11.2.3.6, target="RFC7285"/>, an ALTO cost is
        specified as a generic JSONValue <xref target="RFC8259"/>, target="RFC8259"
        format="default"/> to allow extensions. However, that section 11.2.3.6 states: "An (<xref
        target="RFC7285" sectionFormat="of" section="11.2.3.6"/>) states:</t>
	<blockquote>An implementation of the protocol in
	this document (<xref target="RFC7285"/>) SHOULD
	<bcp14>SHOULD</bcp14> assume that the cost is a JSONNumber and fail to
	parse if it is not, unless the implementation is using an extension to
	this document that indicates when and how costs of other data types
	are signaled". </t>

   <t>
   The signaled.</blockquote>
        <t>The present document extends the definition of a legacy cost map
	given in <xref target="RFC7285"/> target="RFC7285" format="default"/> to allow a cost
	entry to be an array of values, with one value per time interval,
	instead of being just one number, when the Cost Calendar functionality
	is activated on this cost.
   Therefore Therefore, the implementor of this extension MUST
	<bcp14>MUST</bcp14> consider that a cost entry is an array of values
	if this cost has been queried as a Calendar. </t>
        <t> Specifically, an implementation of this extension MUST
	<bcp14>MUST</bcp14> parse the "number-of-intervals" attribute of the
	Calendar attributes in an IRD entry announcing a service providing a
	Cost Calendar for a given cost type. The implementation then will know
	that a cost entry of the service will be an array of values, and the
	expected size of the array is that specified by the
	"number-of-intervals" attribute. The following rules attempt to ensure
	consistency between the array size announced by the Server and the
	actual size of the array received by the Client:
   <list style="symbols">
   <t>The Client:</t>
        <ul spacing="normal">
          <li>The size of the array of values conveyed in a Cost Calendar and
	  received by the Client MUST <bcp14>MUST</bcp14> be equal to the value of
	  attribute "number-of-intervals" indicated in the IRD for the
	  requested cost type.</t>
   <t>When type.</li>
          <li>When the size of the array received by the Client is different
	  from the expected size, the Client SHOULD <bcp14>SHOULD</bcp14> ignore the
	  received array.</t>
   </list>
   </t>

	<t>
   To array.</li>
        </ul>
        <t>To realize an ALTO Calendar, this document extends the IRD and the
	ALTO requests and responses for Cost Calendars.</t>

	<t>
   This
        <t>This extension is designed to be lightweight and to ensure
	backwards compatibility with base protocol ALTO Clients and with other
	extensions.  It relies on section 8.3.7 "Parsing of Unknown Fields"
   of <xref target="RFC7285"/> that writes: (<xref
	target="RFC7285" sectionFormat="of" section="8.3.7"/>), which states:
	"Extensions may include additional fields within JSON objects defined
	in this document.  ALTO implementations MUST <bcp14>MUST</bcp14> ignore
	unknown fields when processing ALTO messages."</t>

	<t>
   The
        <t>The Calendar-specific capabilities are integrated in the
	information resources of the IRD and in the "meta" member of ALTO
	responses to Cost Calendars requests.  A Calendar and its capabilities
	are associated with a given information resource and within this
	information resource, resource with a given cost type.  This design has several
	advantages:</t>

	<t><list style="symbols"><t>it
        <ul spacing="normal">
          <li>it does not introduce a new mode,</t>

	<t>it mode,</li>
          <li>it does not introduce new media types,</t>

	<t>it types, and</li>
          <li>it allows an ALTO Server to offer, for a cost type, different
	  Calendars with attributes that are specific to the information
	  resources providing a Calendar for this cost type, instead of being
	  globally specific to the cost type.
      </t>

	</list>
	</t>

	<t>
   The type.</li>
        </ul>
        <t>The applicable Calendared information resources are:</t>

	<t><list style="symbols"><t>the
        <ul spacing="normal">
          <li>the Filtered Cost Map,</t>

	<t>the Map and</li>
          <li>the Endpoint Cost Map.</t>

	</list>
	</t>

	<t>
   The Map.</li>
        </ul>
        <t>The ALTO Server can choose in which frequency it provides cost
	Calendars to ALTO Clients.  It may either provide Calendar updates
	starting at the request date, date or carefully schedule its updates so as
	to take profit from a potential repetition/periodicity of Calendar
	values.</t>
        <t>Since Calendar attributes are specific to an information resource,
	a Server may adapt the granularity of the calendared information so as
	to moderate the volume of exchanged data. For example: example, suppose a
	Server provides a Calendar for cost type name "routingcost". The
	Server may offer a Calendar in a Cost Map resource, which may be a
	voluminous resource, as an array of 6 intervals lasting each 4
	hours. It may also offer a Calendar in an Endpoint Cost Map resource,
	which is potentially less voluminous, as a finer-grained array of 24
	intervals lasting 1 hour each.
   </t> each.</t>
        <t>The ALTO Server does not support constraints on Calendars, provided
	Calendars are requested for numerical values, for two main reasons:
   <list style="symbols">

   <t>constraints
	reasons:</t>
        <ul spacing="normal">
          <li>Constraints on an array of values may be various: for various. For instance,
	  some Clients may refuse Calendars with one single value violating a
	  constraint, where as whereas other ones may tolerate Calendars with values
	  violating constraints constraints, for example example, at given times. Therefore,
	  expressing constraints in a way that covers all possible Client
	  preferences is challenging, </t>

   <t>if challenging.</li>
          <li>If constraints were to be supported, the processing overhead
	  would be substantial for the Server as it would have to parse alle all
	  the values of the Calendar array before returning a response. </t>
   </list>
    </t> </li>
        </ul>
        <t>As providing the constraint functionality in conjunction with the
	Calendar functionality is not feasible for the reasons described
	above, the two features are mutually exclusive. The absence of
	constraints on Filtered Cost Map and Endpoint Cost Map Calendars
	reflects a divergence from the non-calendared information resources
	defined in <xref target="RFC7285"/> target="RFC7285" format="default"/> and extended in
	<xref target="RFC8189"/>,
   that target="RFC8189" format="default"/>, which support optional
	constraints. </t>
        <section title="ALTO anchor="sect-3.3.1" numbered="true" toc="default">
          <name>ALTO Cost Calendar for all cost modes" anchor="sect-3.3.1"><t>
   An All Cost Modes</name>
          <t>An ALTO Cost Calendar is well-suited well suited for values encoded in the
	  "numerical" mode.  Actually, a Calendar can also represent metrics
	  in other modes considered as compatible with time-varying
	  values. For example, types of Cost cost values such (such as JSONBool JSONBool) can also
	  be
   calendared, as calendared (as their value may be 'true' or 'false' depending on
	  given time periods or likewise, likewise) values represented by strings, such
	  as "medium", "high", "low", "blue", and "open".</t>

	<t>
   Note
          <t>Note also that a Calendar is suitable as well for time-varying
	  metrics provided in the "ordinal" mode, mode if these values are time-
   varying
	  time-varying and the ALTO Server provides updates of cost value based
	  cost-value-based preferences.</t>
        </section>
        <section title="Compatibility anchor="sect-3.3.2" numbered="true" toc="default">
          <name>Compatibility with legacy Legacy ALTO Clients" anchor="sect-3.3.2"><t>
   The Clients</name>
          <t>The ALTO protocol extensions for Cost Calendars have been defined
	  so as to ensure that Calendar-capable ALTO Servers can provide
	  legacy ALTO Clients with legacy information resources as well.  That
	  is, a legacy ALTO Client can request resources and receive responses
	  as specified in <xref target="RFC7285"/>.</t>

	<t>
   A target="RFC7285" format="default"/>.</t>
          <t>A Calendar-aware ALTO Server MUST <bcp14>MUST</bcp14> implement the
	  base protocol specified in <xref target="RFC7285"/>.</t>
   <t>
   A target="RFC7285"
	  format="default"/>.</t>
          <t>A Calendar-aware ALTO Client MUST <bcp14>MUST</bcp14> implement the
	  base protocol specified in <xref target="RFC7285"/>.</t>

	<t>
   As target="RFC7285"
	  format="default"/>.</t>
          <t>As a consequence, when a metric is available as a Calendar array,
	  it also MUST <bcp14>MUST</bcp14> be available as a single value value, as
	  required by <xref target="RFC7285"/>. target="RFC7285" format="default"/>. The Server,
	  in this case, provides the current value of the metric to either
	  Calendar-aware Clients not interested in future or time-based
   values, values
	  or Clients implementing <xref target="RFC7285"/> target="RFC7285" format="default"/>
	  only.</t>

	<t>
   For
          <t>For compatibility with legacy ALTO Clients specified in <xref target="RFC7285"/>,
	  target="RFC7285" format="default"/>, calendared information
	  resources are not applicable for full cost maps for the following
	  reason: a legacy ALTO Client would receive a calendared cost map via
	  an HTTP 'GET' command.  As specified in
   section 8.3.7 of <xref target="RFC7285"/>, target="RFC7285"
	  sectionFormat="of" section="8.3.7"/>, it will ignore the Calendar Attributes
	  attributes indicated in the "meta" of the responses.  Therefore,
	  lacking information on Calendar attributes, it will not be able to
	  correctly interpret and process the values of the received array of
	  Calendar cost values.</t>

	<t>
   Therefore,
          <t>Therefore, calendared information resources MUST <bcp14>MUST</bcp14>
	  be requested via the Filtered Cost Map Service or the Endpoint Cost Service,
	  Service using a POST method.</t>
        </section>
      </section>
    </section>
    <section title="ALTO anchor="sect-4" numbered="true" toc="default">
      <name>ALTO Calendar specification: Specification: IRD extensions" anchor="sect-4"><t>
   The Extensions</name>
      <t>The Calendar attributes in the IRD information resources capabilities
      carry dateless values.  A Calendar is associated with an information
      resource rather than a cost type.  For example, a Server can provide a
      "routingcost" Calendar for the Filtered Cost Map Service at a
      granularity of one day and a "routingcost" Calendar for the Endpoint
      Cost Service at a finer granularity but for a limited number of
      endpoints.  An example IRD with Calendar specific Calendar-specific features is provided
      in <xref target="sect-4.3"/>.</t> target="sect-4.3" format="default"/>.</t>
      <section title="Calendar attributes anchor="sect-4.1" numbered="true" toc="default">
        <name>Calendar Attributes in the IRD resource capabilities" anchor="sect-4.1"><t>
   A Resource Capabilities</name>
        <t>A Cost Calendar for a given cost type MUST <bcp14>MUST</bcp14> be
	indicated in the IRD by an object of type CalendarAttributes.  A
	CalendarAttributes object is represented by the "calendar-attributes"
	member of a resource entry. Member "calendar-attributes" is an array
	of CalendarAttributes objects. Each CalendarAttributes object lists a
	set of one or more cost types it applies to. A cost type name MUST NOT
	<bcp14>MUST NOT</bcp14> appear more than once in the
	"calendar-attributes" member of a resource entry; multiple appearances
	of a cost type name in the CalendarAttributes object of the
	"calendar-attributes" member MUST <bcp14>MUST</bcp14> cause the ALTO Client
	to ignore any occurrences of this name beyond the first encountered
	occurrence.  The Client SHOULD <bcp14>SHOULD</bcp14> consider the
	CalendarAttributes object in the array containing the first
	encountered occurrence of a cost type as the valid one for this cost
	type. As an alternative, the Client may want to avoid the risks of
	erroneous guidance associated to the use of potentially invalid
	Calendar values. In this case, the Client MAY <bcp14>MAY</bcp14> ignore
	the totality of occurences occurrences of CalendarAttributes objects containing
	the cost type name and query the cost type using <xref target="RFC7285"/>. </t>

	<t>
   The
	target="RFC7285" format="default"/>.</t>
        <t>The encoding format for object CalendarAttributes, CalendarAttributes using JSON <xref target="RFC8259"/>,
	target="RFC8259" format="default"/> is as follows:</t>

	<t>
   CalendarAttributes
        <t>CalendarAttributes calendar-attributes &lt;1..*&gt;;</t>

	<figure><artwork><![CDATA[
<sourcecode><![CDATA[
object{
  JSONString cost-type-names <1..*>;
  JSONNumber time-interval-size;
  JSONNumber number-of-intervals;
} CalendarAttributes;
]]></artwork>
	</figure>
	<t><list style="symbols"><t>"cost-type-names":
	<list style="symbols"><t>An
]]></sourcecode>
        <dl newline="true" spacing="normal">
            <dt>"cost-type-names":</dt>
            <dd>An array of one or more elements indicating the cost type
	    names in the IRD entry to which the values of "time-interval-size"
	    and "number-of-intervals" apply.</t>
	</list>
	</t>

	<t>"time-interval-size":<list style="symbols"><t>is the apply.</dd>
            <dt>"time-interval-size":</dt>
            <dd>The duration of an ALTO Calendar time interval in a unit of
	    seconds. A "time-interval-size" value contains a non-negative
	    JSONNumber.  Example values are: are 300 and 7200, meaning that each
	    Calendar value applies on a time interval that lasts 5 minutes and
	    2 hours, respectively. Since an interval size (e.g., 100 ms) can
	    be smaller than the unit, the value specified may be a floating
	    point (e.g., 0.1). Both ALTO Clients and Servers should be aware
	    of potential precision issues caused by using floating point
	    numbers; for example, the floating number 0.1 cannot be
	    represented precisely using a finite number of binary bits. To
	    improve interoperability and be consistent with
         [RFC7285] <xref
	    target="RFC7285" format="default"/> on the
	    use of floating point numbers, the Server and the Client
         SHOULD
	    <bcp14>SHOULD</bcp14> use IEEE 754 double-precision floating point
	    <xref target="IEEE.754.2008"/> target="IEEE.754.2019" format="default"/> to store this value.
   </t>

   <!--
         , if the client and the server use different storage, they may encounter
         interop issues (see Sectio)
         the server may have an internal, integer representation in ms, and store
         100 as an int (0.1 sec) in the local storage; the sever sends "0.1" as
         the interval size to the client; the client may use a float/double to store
         the JSON number, which may not represent 0.1 precisely. To improve
         interoperability, the server and the client SHOULD use IEEE 754
         double-precision floating point <xref target="IEEE.754.2008"/> to store
         this value, in unit of seconds.</t>
   -->
	</list>
	</t>

	<t>"number-of-intervals":<list style="symbols">
	<t>is a
	    value.</dd>

            <dt>"number-of-intervals":</dt>
            <dd>A strictly positive integer (greater or equal to 1), 1) that
	    indicates the number of values of the Cost Calendar array.</t>
	</list>
	</t>

	</list>
	</t>

	<t>
   - An array.</dd>
	</dl>
        <ul spacing="normal">
	  <li>An ALTO Server SHOULD <bcp14>SHOULD</bcp14> specify the "time-interval-size" in the IRD
   as the smallest it is able to provide. A Client that needs
   a longer interval can aggregate multiple cost values to obtain it.</t>
	<t>
   - Attribute it.</li>
        <li>Attribute "cost-type-names" is associated with
	"time-interval-size" and "number-of-intervals", because multiple cost
	types may share the same values for attributes "time-interval-size"
	and "number-of-intervals". To avoid redundancies, cost type names
	sharing the same values for "time-interval-size" and
	"number-of-intervals" are grouped in the "cost-type-names"
	attribute. In the example IRD provided in <xref target="sect-4.3"/>, target="sect-4.3"
	format="default"/>, the information resource
   “filtered-cost-map-calendar”
	"filtered-cost-map-calendar" provides a Calendar for cost type names
	"num-routingcost", "num-throughputrating" "num-throughputrating", and
	"string-servicestatus". Cost type names "num-routingcost" and
	"num-throughputrating" are grouped in the "cost-type-names" attribute
	because they share the same values for "time-interval-size" and
	"number-of-intervals", which are respectively 7200 and 12.
   </t>

	<t>
   - Multiplying 12.</li>
        <li>Multiplying "time-interval-size" by "number-of-intervals" provides
	the duration of the provided Calendar.  For example, an ALTO Server
	may provide a Calendar for ALTO values changing every "time-interval-
   size"
	"time-interval-size" equal to 5 minutes.  If "number-of-intervals" has
	the value 12, then the duration of the provided Calendar is 1 hour.</t>
	hour.</li>
	</ul>
      </section>
      <section title="Calendars anchor="sect-4.2" numbered="true" toc="default">
        <name>Calendars in a delegate IRD" anchor="sect-4.2"><t>
   It Delegate IRD</name>
        <t>It may be useful to distinguish IRD resources supported by the base
	ALTO protocol from resources supported by its extensions. To achieve
	this, one option, option is that a "root" ALTO Server implementing <xref target="RFC7285"/>
	target="RFC7285" format="default"/> resources and running at a given domain,
	domain delegates "specialized" information resources resources, such as the ones
	providing Cost Calendars, to another ALTO Server running in a
	subdomain. The "root" ALTO Server can provide a Calendar-specific
	resource entry, entry that has a media-type of
	"application/alto-directory+json" and that specifies the  URI allowing
	to retrieve the location of a Calendar-aware Server and discover its
	resources. This option is described in Section 9.2.4 "Delegation using IRDs"
   of <xref target="RFC7285"/>.</t>

	<t>
   This Using IRD" (<xref
	target="RFC7285" sectionFormat="of" section="9.2.4"/>).</t>
        <t>This document provides an example, example where a "root" ALTO Server runs
	in a domain called "alto.example.com".  It delegates the announcement
	of Calendars capabilities to an ALTO Server running in a subdomain
	called "custom.alto.example.com".  The location of the "delegate
	Calendar IRD" is assumed to be indicated in the "root" IRD by the
	resource entry: "custom-calendared-resources".</t>
        <t>
	Another benefit of delegation is that some cost types for some resources
	may be more advantageous as Cost Calendars Calendars, and it makes little sense to get them
	as a single value. For example, if a cost type has predictable and frequently
	changing values, values calendared in short time intervals intervals, such as a minute,
	it saves time and network resources to track the cost values via a focused
	delegate Server rather than the more general "root" Server.</t>
      </section>
      <section title="Example anchor="sect-4.3" numbered="true" toc="default">
        <name>Example IRD with ALTO Cost Calendars" anchor="sect-4.3"><t>
   This Calendars</name>
        <t>This section provides an example ALTO Server IRD that supports
	various cost metrics and cost modes.  In particular, since <xref target="RFC7285"/>
	target="RFC7285" format="default"/> makes it mandatory, the Server
	uses metric "routingcost" in the "numerical" mode.</t>

	<t>
   For
        <t>For illustrative purposes, this section introduces 3 other
	fictitious example metrics and modes that should be understood as
	examples and should not be used or considered as normative.</t>

	<t>
   The
        <t>The cost type names used in the example IRD are as follows:</t>

	<t><list style="symbols"><t>"num-routingcost": refers
        <dl newline="true" spacing="normal">
          <dt>"num-routingcost":</dt>
	  <dd>Refers to metric "routingcost" in the
	  numerical
      mode mode, as defined in <xref target="RFC7285"/> target="RFC7285"
	  format="default"/> and registered with IANA.</t>

	<t>"num-owdelay": refers IANA.</dd>
          <dt>"num-owdelay":</dt>
	  <dd>Refers to fictitious performance metric "owdelay"
	  in the "numerical" mode, mode to reflect the one-way packet transmission
	  delay on a path.  A related performance metric is currently under
	  definition in <xref target="I-D.ietf-alto-performance-metrics"/>.</t>

	<t>"num-throughputrating": refers target="I-D.ietf-alto-performance-metrics"
	  format="default"/>.</dd>
          <dt>"num-throughputrating":</dt>
	  <dd>Refers to fictitious metric
	  "throughputrating" in the "numerical" mode, mode to reflect the provider
	  preference in terms of end to end throughput.</t>

	<t>"string-servicestatus": refers end-to-end throughput.</dd>
          <dt>"string-servicestatus":</dt>
	  <dd>Refers to fictitious metric
	  "servicestatus" containing a string, string to reflect the availability,
	  defined by the provider, of of, for instance instance, path connectivity.</t>

	</list>
	</t>

	<t>
   The connectivity.</dd>
        </dl>
        <t>The example IRD includes 2 particular URIs providing Calendars:</t>

	<t><list style="symbols"><t>"https://custom.alto.example.com/calendar/costmap/filtered": a
        <dl newline="true" spacing="normal">
          <dt>"https://custom.alto.example.com/calendar/costmap/filtered":</dt>
	  <dd>A Filtered Cost Map in which Calendar capabilities are indicated
	  for cost type names: names "num-routingcost", "num-throughputrating" "num-throughputrating", and
      "string-servicestatus",</t>

	<t>"https://custom.alto.example.com/calendar/endpointcost/lookup": an
	  "string-servicestatus" and</dd>
          <dt>"https://custom.alto.example.com/calendar/endpointcost/lookup":</dt>
	  <dd>An Endpoint Cost Map in which Calendar capabilities are indicated
	  for cost type names: names "num-routingcost", "num-owdelay",
	  "num-throughputrating", "string-servicestatus".</t>

	</list>
	</t>

	<t>
   The and "string-servicestatus".</dd>
        </dl>
        <t>The design of the Calendar capabilities allows some Calendars with
	the same cost type name to be available in several information
	resources with different Calendar Attributes. attributes.  This is the case for
	Calendars on "num-routingcost", "num-throughputrating" "num-throughputrating", and
	"string-servicestatus", available in both the Filtered Cost map Map and
	Endpoint Cost Service, Service but with different time interval sizes for
	"num-throughputrating" and "string-servicestatus".</t>

	<figure><artwork><![CDATA[
<sourcecode><![CDATA[
--- Client to Server request for IRD ----------

GET /calendars-directory HTTP/1.1
Host: custom.alto.example.com
Accept: application/alto-directory+json,application/alto-error+json

--- Server response to Client -----------------

HTTP/1.1 200 OK
Content-Length: 2622
Content-Type: application/alto-directory+json

{
  "meta" : {
    "default-alto-network-map" : "my-default-network-map",
    "cost-types": {
      "num-routingcost": {
        "cost-mode" : "numerical",
        "cost-metric" : "routingcost"
      },
      "num-owdelay": {
        "cost-mode"  : "numerical",
        "cost-metric": "owdelay"
      },
      "num-throughputrating": {
        "cost-mode"  : "numerical",
        "cost-metric": "throughputrating"
      },
      "string-servicestatus": {
        "cost-mode"  : "string",
        "cost-metric": "servicestatus"
      }
    }
  },
  "resources" : {
    "filtered-cost-map-calendar" : {
      "uri" :
        "https://custom.alto.example.com/calendar/costmap/filtered",
      "media-type" : "application/alto-costmap+json",
      "accepts" : "application/alto-costmapfilter+json",
      "capabilities" : {
        "cost-constraints" : true,
        "cost-type-names"  : [ "num-routingcost",
                               "num-throughputrating",
                               "string-servicestatus" ],
        "calendar-attributes" : [
          {"cost-type-names" : [ "num-routingcost",
                                 "num-throughputrating" ],
           "time-interval-size" : 7200,
           "number-of-intervals" : 12
          },
          {"cost-type-names" : [ "string-servicestatus" ],
           "time-interval-size" : 1800,
           "number-of-intervals" : 48
          }
        ]
      },
      "uses": [ "my-default-network-map" ]
    },
    "endpoint-cost-map-calendar" : {
      "uri" :
      "https://custom.alto.example.com/calendar/endpointcost/lookup",
      "media-type" : "application/alto-endpointcost+json",
      "accepts" : "application/alto-endpointcostparams+json",
      "capabilities" : {
        "cost-constraints" : true,
        "cost-type-names" : [ "num-routingcost",
                              "num-owdelay",
                              "num-throughputrating",
                              "string-servicestatus" ],
        "calendar-attributes" : [
          {"cost-type-names" : [ "num-routingcost" ],
           "time-interval-size" : 3600,
           "number-of-intervals" : 24
          },
          {"cost-type-names" : [ "num-owdelay" ],
           "time-interval-size" : 300,
           "number-of-intervals" : 12
          },
          {"cost-type-names" : [ "num-throughputrating" ],
           "time-interval-size" : 60,
           "number-of-intervals" : 60
          },
          {"cost-type-names" : [ "string-servicestatus" ],
           "time-interval-size" : 120,
           "number-of-intervals" : 30
          }
        ]
      }
    }
  }
}

In
]]></sourcecode>
<t>In this example IRD, for the Filtered Cost Map Service:
]]></artwork>
	</figure>
	<t><list style="symbols"><t>the Service:</t>
        <ul spacing="normal">
          <li>the Calendar for "num-routingcost" and "num-throughputrating" is
	  an array of 12 values values, each provided on a time interval lasting 7200
	  seconds (2 hours).</t>

	<t>the hours) and</li>
          <li>the Calendar for "string-servicestatus": "is "string-servicestatus" is an array of 48 values
	  values, each provided on a time interval lasting 1800 seconds (30 minutes).</t>

	</list>
	</t>

	<t>
   For
	  minutes).</li>
        </ul>
        <t>For the Endpoint Cost Service:</t>

	<t><list style="symbols"><t>the
        <ul spacing="normal">
          <li>the Calendar for "num-routingcost": "num-routingcost" is an array of 24 values values, each
	  provided on a time interval lasting 3600 seconds (1 hour).</t>

	<t>the hour),</li>
          <li>the Calendar for "num-owdelay": "num-owdelay" is an array of 12 values values, each
	  provided on a time interval lasting 300 seconds (5 minutes).</t>

	<t>the minutes),</li>
          <li>the Calendar for "num-throughputrating": "num-throughputrating" is an array of 60 values
	  values, each provided on a time interval lasting 60 seconds (1 minute).</t>

	<t>the
	  minute), and</li>
          <li>the Calendar for "string-servicestatus": "is "string-servicestatus" is an array of 30 values
	  values, each provided on a time interval lasting 120 seconds (2 minutes).</t>

	</list>
	</t>
	  minutes).</li>
        </ul>
        <t>Note that in this example IRD, member "cost-constraints" is present
	with a value set to "true" in both information resources
	"filtered-cost-map-calendar" and
	"endpoint-cost-map-calendar". Although a Calendar-aware ALTO Server
	does not support constraints for the reasons explained in section
	<xref target="sect-3.3"/>, target="sect-3.3" format="default"/>, it MUST <bcp14>MUST</bcp14>
	support constraints on cost types that are not requested as Calendars
	but are requested as specified in <xref target="RFC7285"/> target="RFC7285"
	format="default"/> and <xref target="RFC8189"/>.</t> target="RFC8189" format="default"/>.</t>
      </section>
    </section>
    <section title="ALTO anchor="sect-5" numbered="true" toc="default">
      <name>ALTO Calendar specification: Specification: Service Information Resources" anchor="sect-5"><t>
   This Resources</name>
      <t>This section documents extensions to two basic ALTO information
      resources (Filtered Cost Maps and Endpoint Cost Service) to provide
      calendared information services for them.</t>

   <!-- old
    The reference time zone for the provided time values is UTC.  The
    option chosen to express the time format is the HTTP header fields
    format specified in [RFC7231] where, however, timestamps are still
    displayed with the acronym "GMT" rather than "UTC":
   -->

	<t>
   Both

	<t>Both extensions return calendar start time (calendar-start-time, a
	point in time), which MUST <bcp14>MUST</bcp14> be specified as an HTTP
	"Date" header field using the IMF-fixdate format specified in Section 7.1.1.1 of
	<xref target="RFC7231"/>. target="RFC7231" sectionFormat="of" section="7.1.1.1"/>. Note that the
	IMF-fixdate format uses "GMT", not "UTC", to designate the time zone,
	as in this example:</t>

	<t><list hangIndent="17" style="hanging"><t>
<sourcecode><![CDATA[
                 Date: Tue, 15 Nov 2019 08:12:31 GMT</t>

	</list>
	</t>

	<!-- <t>The value of a Calendar time interval size is expressed in seconds.</t> --> GMT
]]></sourcecode>

	<section title="Calendar extensions anchor="sect-5.1" numbered="true" toc="default">
        <name>Calendar Extensions for Filtered Cost Maps (FCM)" anchor="sect-5.1"><t>
   A (FCM)</name>
        <t>A legacy ALTO Client requests and gets Filtered Cost Map responses responses,
	as specified in <xref target="RFC7285"/>.</t> target="RFC7285" format="default"/>.</t>
        <section title="Calendar extensions anchor="sect-5.1.1" numbered="true" toc="default">
          <name>Calendar Extensions in Filtered Cost Map requests" anchor="sect-5.1.1"><t>
   The Requests</name>
          <t>The input parameters of a "legacy" request for a Filtered Cost
	  Map, defined by object ReqFilteredCostMap in section 11.3.2 of <xref target="RFC7285"/>, target="RFC7285"
	  sectionFormat="of" section="11.3.2"/>, are augmented with one
	  additional member. The same augmentation applies to object
	  ReqFilteredCostMap defined in section 4.1.2 of <xref target="RFC8189"/>.</t>

	<t>
   A target="RFC8189"
	  sectionFormat="of" section="4.1.2"/>.</t>
          <t>A Calendar-aware ALTO Client requesting a Calendar on a given Cost
   Type
	  cost type for a Filtered Cost Map resource having Calendar
	  capabilities
   MUST <bcp14>MUST</bcp14> add the following field to its
	  input parameters:</t>

	<t><list hangIndent="23" style="hanging"><t>
<sourcecode><![CDATA[
                       JSONBoolean calendared&lt;1..*&gt;;</t>

	</list>
	</t>

	<t>
   This calendared<1..*>;
]]></sourcecode>
          <t>This field is an array of 1 to N boolean values, where N is the
	  number of requested metrics. N is greater than 1 when the Client and
	  the Server also implement <xref target="RFC8189"/>.  </t> target="RFC8189"
	  format="default"/>.</t>
          <t> Each entry corresponds to the requested metric at the same array
	  position.  Each boolean value indicates whether or not the ALTO
	  Server should provide the values for this cost type as a Calendar.
	  The array MUST <bcp14>MUST</bcp14> contain exactly N boolean values,
	  otherwise, the Server returns an error.</t>

	<t>
   This
          <t>This field MUST NOT <bcp14>MUST NOT</bcp14> be included if no member
	  "calendar-attributes" is specified in this information resource.</t>

	<t>
   If
          <t>If a value of field "calendared" is 'true' for a cost type name
	  for which no Calendar attributes have been specified: specified, an ALTO
	  Server, whether it implements the extensions of this document or
	  only implements <xref target="RFC7285"/>, MUST target="RFC7285" format="default"/>,
	  <bcp14>MUST</bcp14> ignore it and return a response with a single
	  cost value value, as specified in <xref target="RFC7285"/>.</t>

	<t>
   If target="RFC7285"
	  format="default"/>.</t>
          <t>If this field is not present, it MUST <bcp14>MUST</bcp14> be assumed
	  to have only values equal to 'false'.</t>

	<t>
   A
          <t>A Calendar-aware ALTO Client that supports requests for only one
	  cost type at a time and wants to request a Calendar MUST
	  <bcp14>MUST</bcp14> provide an array of 1 element:</t>

	<t><list hangIndent="23" style="hanging"><t>
<sourcecode><![CDATA[
                       "calendared" : [true],</t>

	</list>
	</t>

	<t>
   A [true],
]]></sourcecode>
          <t>A Calendar-aware ALTO Client that supports requests for more than
	  one cost types type at a time, as specified in <xref target="RFC8189"/> MUST target="RFC8189"
	  format="default"/>, <bcp14>MUST</bcp14> provide an array of N values
	  set to 'true' or 'false', depending whether it wants the applicable
	  cost type values as a single or calendared value.</t>
        </section>
        <section title="Calendar extensions anchor="sect-5.1.2" numbered="true" toc="default">
          <name>Calendar Extensions in Filtered Cost Map responses" anchor="sect-5.1.2"><t> Responses</name>
          <t>
   In a calendared ALTO Filtered Cost Map, a cost value between a source
   and a destination is a JSON array of JSON values.  An ALTO Calendar
   values array has a number of values equal to the value of member
   "number-of-intervals" of the Calendar attributes that are indicated
   in the IRD.  These attributes will be conveyed as metadata in the
   Filtered Cost Map response.  Each element of the array is valid for
   the time-interval time interval that matches its array position.</t>
          <t>
   The FCM response conveys metadata metadata, among which:</t>

	<t><list style="symbols"><t>some
          <ul spacing="normal">
            <li>some are not specific to Calendars and ensure compatibility
	    with <xref target="RFC7285"/> target="RFC7285" format="default"/> and <xref target="RFC8189"/></t>

	<t>some
	    target="RFC8189" format="default"/> and</li>
            <li>some are specific to Calendars.</t>

	</list>
	</t>

	<t>
   The non Calendar-specific Calendars.</li>
          </ul>
          <t>The non-Calendar-specific "meta" fields of a calendared Filtered
	  Cost Map response MUST <bcp14>MUST</bcp14> include at least:</t>

	<t><list style="symbols"><t>if
          <ul spacing="normal">
            <li>
              <t>if the ALTO Client requests cost values for one cost type at
	      a
      time only: time, only the "meta" fields specified in <xref target="RFC7285"/>
	      target="RFC7285" format="default"/> for these information
	      service responses:<list style="symbols"><t>"dependent-vtags ",</t>

	<t>"cost-type" field.</t>

	</list>
	</t> responses:</t>
              <ul spacing="normal">
                <li>"dependent-vtags" and</li>
                <li>"cost-type" field.</li>
              </ul>
            </li>
            <li>
              <t>if the ALTO Client implements the Multi-Cost ALTO extension
	      specified in <xref target="RFC8189"/> target="RFC8189" format="default"/> and
	      requests cost values for several cost types at a time: time, the
	      "meta" fields specified in <xref target="RFC8189"/> target="RFC8189"
	      format="default"/> for these information service responses:<list style="symbols"><t>"dependent-vtags ",</t>

	<t>"cost-type" responses:</t>
              <ul spacing="normal">
                <li>"dependent-vtags",</li>
                <li>"cost-type" field with value set to '{}', for backwards
		compatibility with <xref target="RFC7285"/>.</t>

	<t>"multi-cost-types" field.</t>

	</list>
	</t>

	</list>
	</t>

	<t>
   If target="RFC7285" format="default"/>,
		and</li>
                <li>"multi-cost-types" field.</li>
              </ul>
            </li>
          </ul>
          <t>If the Client request does not provide member "calendared" or if
	  it provides it with a value equal to 'false', 'false' for all the requested
	  cost types, then the ALTO Server response is exactly as specified in
	  <xref target="RFC7285"/> target="RFC7285" format="default"/> and <xref target="RFC8189"/>.</t> target="RFC8189"
	  format="default"/>.</t>
          <t>
   If the value of member "calendared" is equal to 'false' for a given
   requested cost type, the ALTO Server MUST <bcp14>MUST</bcp14> return, for this cost type,
   a single cost value as specified in <xref target="RFC7285"/>.</t> target="RFC7285" format="default"/>.</t>
          <t>
   If the value of member "calendared" is equal to 'true' for a given
   requested cost type, the ALTO Server returns, for this cost type, a
   cost value Calendar Calendar, as specified above in this section.  In addition
   to the above cited non Calendar specific non-Calendar-specific "meta" members, the Server
   MUST
   <bcp14>MUST</bcp14> provide a Calendar specific Calendar-specific metadata field.</t>
          <t>
   The Calendar-specific "meta" field that a calendared Filtered Cost
   Map response MUST <bcp14>MUST</bcp14> include is a member called "calendar-response-attributes",
   that
   which describes properties of the Calendar and where:</t>

	<t><list style="symbols">
	<t>member
          <ul spacing="normal">
            <li>member "calendar-response-attributes" is an array of one or
	    more objects of type "CalendarResponseAttributes".</t>

	<t>each "CalendarResponseAttributes",</li>
            <li>each "CalendarResponseAttributes" object in the array is specified
      for one or more cost types for which the value of member
      "calendared", in object ReqFilteredCostMap provided in the Client request,
      is equal to 'true' and for which a Calendar is
      provided for the requested information resource.</t>

	<t>the resource, and</li>
            <li>the "CalendarResponseAttributes" object that applies to a cost
	    type name has a corresponding "CalendarAttributes" object defined
	    for this cost type name in the IRD capabilities of the requested
	    information resource. This object is the entry, entry in the
	    "calendar-attributes" array member of the IRD resource entry, that
	    which includes the name of the requested cost type. This
	    corresponding "CalendarAttributes" object has the same values as
	    object "CalendarResponseAttributes" for members
	    "time-interval-size" and "number-of-intervals". The members of the
	    "CalendarResponseAttributes" object include all the members of the
	    corresponding "CalendarAttributes" object.</t>

	</list>
	</t> object.</li>
          </ul>
          <t>
   The format of member "CalendarResponseAttributes is defined as follows:</t>
          <t>
   CalendarResponseAttributes calendar-response-attributes &lt;1..*&gt;;</t>

	<figure><artwork><![CDATA[
<sourcecode><![CDATA[
object{
  [JSONString cost-type-names <1..*>;]
  JSONString calendar-start-time;
  JSONNumber time-interval-size;
  JSONNumber number-of-intervals;
  [JSONNumber repeated;]
} CalendarResponseAttributes;

Object CalendarResponseAttributes has the following attributes:
]]></artwork>
	</figure>
	<t><list style="symbols">
	<t>"cost-type-names": is an
]]></sourcecode>
          <dl newline="true" spacing="normal">
            <dt>"cost-type-names":</dt>
	    <dd>An array of one or more cost-type-names cost type names to which the value
	    of the other members of CalendarResponseAttributes apply and for
	    which a Calendar has been requested. The value of this member is a
	    subset of the "cost-type-names" member of the abovementioned
	    corresponding "CalendarAttributes" object in the
	    "calendar-attributes" array member in the IRD. This member MUST
	    <bcp14>MUST</bcp14> be present when Cost Calendars are provided
	    for more than one cost type.</t>

	<t>"calendar-start-time": indicates type.</dd>
            <dt>"calendar-start-time":</dt>
	    <dd>Indicates the date at which the first value of the Calendar
	    applies. The value is a string that, as specified in <xref target="sect-5"/>,
	    target="sect-5" format="default"/>, contains an HTTP "Date" header
	    field using the IMF-fixdate format specified in Section 7.1.1.1 of <xref target="RFC7231"/>.
	    target="RFC7231" sectionFormat="of" section="7.1.1.1"/>.  The
	    value provided for attribute "calendar-start-time" SHOULD NOT <bcp14>SHOULD
	    NOT</bcp14> be later than the request date.</t>

	<t>"time-interval-size": as date.</dd>
            <dt>"time-interval-size":</dt>
	    <dd>As specified in <xref target="sect-4.1"/> target="sect-4.1" format="default"/> and
	    with the same value as in the abovementioned corresponding
	    "CalendarAttributes" object.</t>

	<t>"number-of-intervals": as object.</dd>
            <dt>"number-of-intervals":</dt>
	    <dd>As specified in <xref target="sect-4.1"/> target="sect-4.1" format="default"/> and
	    with the same value as in the abovementioned corresponding
	    "CalendarAttributes" object.</t>

	<t>"repeated": is an object.</dd>
            <dt>"repeated":</dt>
	    <dd>An optional field provided for Calendars.  It is an integer
	    N greater or equal to '1' that indicates how many iterations of
	    the Calendar value array starting at the date indicated by
	    "calendar-start-time" have the same values.  The number N includes
	    the iteration provided in the returned response.</t>

	</list>
	</t>

	<t>
   For example: response.</dd>
          </dl>
          <t>For example, suppose the "calendar-start-time" member has value
	  "Mon, 30 Jun 2019 00:00:00 GMT", the "time-interval-size" member has
	  value '3600', the "number-of-intervals" member has value '24' '24', and
	  the value of member "repeated" is equal to '4'.  This means that the
	  Calendar values are the same on Monday, Tuesday, Wednesday Wednesday, and
	  Thursday on a period of 24 hours starting at 00:00:00 GMT.  The ALTO
	  Client thus may use the same Calendar for the next 4 days starting
	  at "calendar-start-time" and will only need to request a new one for
   Friday
	  Friday, July 4th at 00:00:00 GMT.</t>

	<t>
   Attribute
          <t>Attribute "repeated" may take a very high value if a Calendar
	  represents a cyclic value pattern that the Server considers valid
	  for a long period and hence will only update once this period has
	  elapsed or if an unexpected event occurs on the network.  In the
	  latter case, the Client will be notified if it uses the "ALTO
	  Incremental Updates Using Server-Sent Events (SSE)" Service,
	  specified in <xref target="I-D.ietf-alto-incr-update-sse"/>. target="RFC8895" format="default"/>.  To this
	  end, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that ALTO Servers providing
	  ALTO Calendars also provide the "ALTO Incremental Updates Using
	  Server-Sent Events (SSE)" Service that Service, which is specified in <xref target="I-D.ietf-alto-incr-update-sse"/>.
	  target="RFC8895" format="default"/>.  Likewise, ALTO Clients capable
	  of using ALTO Calendars SHOULD <bcp14>SHOULD</bcp14> also use the SSE
	  Service.  See also discussion in <xref target="sect-8"/> target="sect-8"
	  format="default"/> "Operational Considerations".</t>
        </section>
        <section title="Use case anchor="sect-5.1.3" numbered="true" toc="default">
          <name>Use Case and example: Example: FCM with a bandwidth Calendar" anchor="sect-5.1.3"><t>
   An Bandwidth Calendar</name>
          <t>An example of non-real-time information that can be provisioned
	  in a Calendar is the expected path throughput.  While the
	  transmission rate can be measured in real time by end systems, the
	  operator of a data center is in the position of formulating
	  preferences for given
   paths, paths at given time periods to avoid traffic
	  peaks due to diurnal usage patterns.  In this example, we assume
	  that an ALTO Client requests a Calendar of network-provider-defined
	  throughput ratings, ratings as specified in the IRD, IRD to schedule its bulk
	  data transfers as described in the use cases.</t>

	<t>
   In
          <t>In the example IRD, Calendars for cost type name
	  "num-throughputrating" are available for the information resources: resources
	  "filtered-cost-calendar-map" and "endpoint-cost-map-calendar".  The
	  ALTO Client requests a Calendar for "num-throughputrating" via a
	  POST request for a Filtered Cost Map.</t>
          <t>
   We suppose in the present example that the ALTO Client sends its
   request on Tuesday Tuesday, July 1st 2019 at 13:15.  The Server returns
   Calendars with arrays of 12 numbers for each source and destination
   pair.  The values for metric "throughputrating", in this example, are
   assumed to be encoded in 2 digits.</t>

	<figure><artwork><![CDATA[
<sourcecode><![CDATA[
  POST /calendar/costmap/filtered HTTP/1.1
  Host: custom.alto.example.com
  Content-Length: 217
  Content-Type: application/alto-costmapfilter+json
  Accept: application/alto-costmap+json,application/alto-error+json

  {
    "cost-type" : {"cost-mode" : "numerical",
                   "cost-metric" : "throughputrating"},
    "calendared" : [true],
    "pids" : {
      "srcs" : [ "PID1", "PID2" ],
      "dsts" : [ "PID1", "PID2", "PID3" ]
    }
  }

  HTTP/1.1 200 OK
  Content-Length: 1043
  Content-Type: application/alto-costmap+json

  {
    "meta" : {
      "dependent-vtags" : [
        {"resource-id": "my-default-network-map",
         "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
        }
      ],
      "cost-type" : {"cost-mode" : "numerical",
                     "cost-metric" : "throughputrating"},
      "calendar-response-attributes" : [
        {"calendar-start-time" : "Tue, 1 Jul 2019 13:00:00 GMT",
         "time-interval-size" : 7200,
         "number-of-intervals" : 12}
      ]
    },
    "cost-map" : {
      "PID1": { "PID1": [ 1, 12, 14, 18, 14, 14,
                         14, 18, 19, 20, 11, 12],
                "PID2": [13,  4, 15, 16, 17, 18,
                         19, 20, 11, 12, 13, 14],
                "PID3": [20, 20, 18, 14, 12, 12,
                         14, 14, 12, 12, 14, 16] },
      "PID2": { "PID1": [17, 18, 19, 10, 11, 12,
                         13, 14, 15, 16, 17, 18],
                "PID2": [20, 20, 18, 16, 14, 14,
                         14, 16, 16, 16, 14, 16],
                "PID3": [20, 20, 18, 14, 12, 12,
                         14, 14, 12, 12, 14, 16] }
    }
  }
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
      </section>
      <section title="Calendar extensions anchor="sect-5.2" numbered="true" toc="default">
        <name>Calendar Extensions in the Endpoint Cost Service" anchor="sect-5.2"><t>
   This Service</name>
        <t>This document extends the Endpoint Cost Service, as defined in
   {11.5.1} of
	<xref target="RFC7285"/>, target="RFC7285" sectionFormat="of" section="11.5.1"/>, by adding new
	input parameters and
   capabilities, capabilities and by returning JSONArrays instead
	of JSONNumbers as the cost values. The media type {11.5.1.1} (<xref
	target="RFC7285" sectionFormat="of" section="11.5.1.1"/>) and HTTP
	method
   {11.5.1.2} (<xref target="RFC7285" sectionFormat="of"
	section="11.5.1.2"/>) are unchanged.</t>
        <section title="Calendar specific input anchor="sect-5.2.1" numbered="true" toc="default">
          <name>Calendar-Specific Input in Endpoint Cost requests" anchor="sect-5.2.1"><t>
   The Requests</name>
          <t>The extensions to the requests for calendared Endpoint Cost Maps
	  are the same as for the Filtered Cost Map Service, specified in
	  <xref target="sect-5.1.1"/> target="sect-5.1.1" format="default"/> of this
	  document. Likewise, the rules defined around the extensions to ECM
	  requests are the same as those defined in <xref target="sect-5.1.1"/> target="sect-5.1.1"
	  format="default"/> for FCM requests. </t>
          <t>
   The ReqEndpointCostMap object for a calendared ECM request will have
   the following format:</t>

	<figure><artwork><![CDATA[
<sourcecode><![CDATA[
object {
  [CostType cost-type;]
  [CostType multi-cost-types<1..*>;]
  [JSONBoolean calendared<1..*>;]
  EndpointFilter endpoints;
} ReqEndpointCostMap;

object {
  [TypedEndpointAddr srcs<0..*>;]
  [TypedEndpointAddr dsts<0..*>;]
} EndpointFilter;
]]></artwork>
	</figure>
]]></sourcecode>
          <t>Member "cost-type" is optional because, in the ReqEndpointCostMap
	  object definition of this document, it is jointly present with
	  member "multi-cost-types", "multi-cost-types" to ensure compatibility with RFC 8189. <xref
	  target="RFC8189" format="default"/>. In RFC8189, <xref target="RFC8189"
	  format="default"/>, members "cost-type" and "multi-cost-types" are
	  both optional and have to obey the rule specified in section 4.1.2 of 8189 saying that: <xref
	  target="RFC8189" sectionFormat="of" section="4.1.2"/> stating that
	  "the Client MUST <bcp14>MUST</bcp14> specify either "cost-type" or
	  "multi-cost-types" but MUST NOT <bcp14>MUST NOT</bcp14> specify both".</t>
          <t>The interpretation of member "calendared" is the same as for the
	  ReqFilteredCostMap object defined in <xref target="sect-5.1.1"/> target="sect-5.1.1"
	  format="default"/> of this document. The interpretation of the other
	  members is the same as for object ReqEndpointCostMap is defined in
	  <xref target="RFC7285"/> target="RFC7285" format="default"/> and <xref target="RFC8189"/>. target="RFC8189"
	  format="default"/>. The type TypedEndpointAddr is defined in section 10.4.1
of <xref target="RFC7285"/>. </t>
	  target="RFC7285" sectionFormat="of" section="10.4.1"/>.</t>
          <t>For the reasons explained in section <xref target="sect-3.3"/>, target="sect-3.3"
	  format="default"/>, a Calendar-aware ALTO Server does not support
	  constraints. Therefore, member "[constraints]" is not present in the
	  ReqEndpointCostMap object object, and member "constraints" MUST NOT <bcp14>MUST
	  NOT</bcp14> be present in the input parameters of a request for an
	  Endpoint Cost Calendar. If this member is present, the Server MUST
	  <bcp14>MUST</bcp14> ignore it.</t>
        </section>
        <section title="Calendar attributes anchor="sect-5.2.2" numbered="true" toc="default">
          <name>Calendar Attributes in the Endpoint Cost response" anchor="sect-5.2.2"><t>
   The Response</name>
          <t>The "meta" field of a calendared Endpoint Cost response MUST
	  <bcp14>MUST</bcp14> include at least:</t>

	<t><list style="symbols"><t>if
          <ul spacing="normal">
            <li>
              <t>if the ALTO Client supports cost values for one cost type at
	      a time only: only, the "meta" fields specified in {11.5.1.6} of <xref target="RFC7285"/>
	      target="RFC7285" sectionFormat="of" section="11.5.1.6"/> for the
	      Endpoint Cost response:<list style="symbols"><t>"cost-type" field.</t>

	</list>
	</t> response:</t>
              <ul spacing="normal">
                <li>"cost-type" field.</li>
              </ul>
            </li>
            <li>
              <t>if the ALTO Client supports cost values for several cost
	      types at a time, as specified in <xref target="RFC8189"/> : target="RFC8189"
	      format="default"/>, the "meta" fields specified in <xref target="RFC8189"/>
	      target="RFC8189" format="default"/> for the the Endpoint Cost response:
      <list style="symbols">
      <t>"cost-type"
	      response:</t>
              <ul spacing="normal">
                <li>"cost-type" field with value set to '{}', for backwards
		compatibility with <xref target="RFC7285"/>.</t>

	<t>"multi-cost-types" field.</t>

	</list>
	</t>

	</list>
	</t>

	<t>
   If target="RFC7285"
		format="default"/>.</li>
                <li>"multi-cost-types" field.</li>
              </ul>
            </li>
          </ul>
          <t>If the Client request does not provide member "calendared" or if
	  it provides it with a value equal to 'false', for all the requested Cost
   Types,
	  cost types, then the ALTO Server response is exactly as specified in
	  <xref target="RFC7285"/> target="RFC7285" format="default"/> and <xref target="RFC8189"/>.</t>

	<t>
   If target="RFC8189"
	  format="default"/>.</t>
          <t>If the ALTO Client provides member "calendared" in the input
	  parameters with a value equal to 'true' for given requested Cost
   Types, cost
	  types, the "meta" member of a calendared Endpoint Cost response MUST
	  <bcp14>MUST</bcp14> include, for these cost types, an additional
	  member "calendar-response-attributes", the contents of which obey
	  the same rules as for the Filtered Cost Map Service, specified in
	  <xref target="sect-5.1.2"/>. target="sect-5.1.2" format="default"/>.  The Server response
	  is thus changed as follows, with respect to <xref target="RFC7285"/> target="RFC7285"
	  format="default"/> and <xref target="RFC8189"/>:</t>

	<t><list style="symbols"><t>the target="RFC8189"
	  format="default"/>:</t>
          <ul spacing="normal">
            <li>the "meta" member has one additional field
	    "CalendarResponseAttributes", as specified for the Filtered Cost
	    Map Service,</t>

	<t>the Service, and</li>
            <li>the calendared costs are JSONArrays instead of the JSONNumbers
	    format used by legacy ALTO implementations.  All arrays have a
	    number of values equal to 'number-of-intervals'. Each value
	    corresponds to the cost in that interval.</t>

	</list>
	</t>

	<t>
   If interval.</li>
          </ul>
          <t>If the value of member "calendared" is equal to 'false' for a
	  given requested cost type, the ALTO Server MUST <bcp14>MUST</bcp14>
	  return, for this cost type, a single cost value as specified in
	  <xref target="RFC7285"/>.</t> target="RFC7285" format="default"/>.</t>
        </section>
        <section title="Use case anchor="sect-5.2.3" numbered="true" toc="default">
          <name>Use Case and example: Example: ECS with a routingcost Calendar" anchor="sect-5.2.3"><t>
   Let Calendar</name>
          <t>Let us assume an Application Client is located in an end system
	  with limited resources and having has access to the network that is either
	  intermittent or provides an acceptable quality in limited but
	  predictable time periods.  Therefore, it needs to schedule both its
	  resource-greedy networking activities and its ALTO transactions.</t>

	<t>
   The
          <t>The Application Client has the choice to trade content or
	  resources with a set of Endpoints endpoints and needs to decide with which one
	  it will connect and at what time.  For instance, the Endpoints endpoints are
	  spread in different time-zones, time zones or have intermittent access.  In
	  this example, the 'routingcost' is assumed to be time-varying, with
	  values provided as ALTO Calendars.</t>

	<t>
   The
          <t>The ALTO Client associated with the Application Client queries an
	  ALTO Calendar on 'routingcost' and will get the Calendar covering
	  the
   24 hours 24-hour time period "containing" the date and time of the ALTO
	  Client request.</t>
          <t>
   For cost type "num-routingcost", the solicited ALTO Server has
   defined 3 different daily patterns patterns, each represented by a Calendar, Calendar to
   cover the week of Monday Monday, June 30th at 00:00 to Sunday Sunday, July 6th 23:59:</t>

	<t><list style="symbols">
	<t>C1
          <ul spacing="normal">
            <li>C1 for Monday, Tuesday, Wednesday, Thursday, (weekdays)</t>

	<t>C2 and Thursday (weekdays)</li>
            <li>C2 for Saturday, Sunday, (weekend)</t>

	<t>C3 Saturday and Sunday (weekends)</li>
            <li>C3 for Friday (maintenance outage on July 4, 2019 from
	    02:00:00 GMT to 04:00:00 GMT, GMT or a big holiday such as New Year evening).</t>
	</list>
	</t>

	<t>
   In that
	    is widely celebrated and generates a large number of connections).</li>
          </ul>
          <t>In the following example, the ALTO Client sends its request on
   Tuesday
	  Tuesday, July 1st 2019 at 13:15.</t>

	<t>
   The
          <t>The "routingcost" values are assumed to be encoded in 3
	  digits.</t>

	<figure><artwork><![CDATA[
<sourcecode><![CDATA[
POST /calendar/endpointcost/lookup HTTP/1.1
Host: custom.alto.example.com
Content-Length: 304
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json application/alto-endpointcost+json,
        application/alto-error+json

{
  "cost-type" : {"cost-mode" : "numerical",
                 "cost-metric" : "routingcost"},
  "calendared" : [true],
  "endpoints" : {
    "srcs": [ "ipv4:192.0.2.2" ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34",
      "ipv4:203.0.113.45",
      "ipv6:2001:db8::10"
    ]
  }
}

HTTP/1.1 200 OK

Content-Length: 1351
Content-Type: application/alto-endpointcost+json

{
  "meta" : {
    "cost-type" : {"cost-mode" : "numerical",
                   "cost-metric" : "routingcost"},
    "calendar-response-attributes" : [
      {"calendar-start-time" : "Mon, 30 Jun 2019 00:00:00 GMT",
       "time-interval-size" : 3600,
       "number-of-intervals" : 24,
       "repeated": 4
      }
    ]
  },
  "endpoint-cost-map" : {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89"    : [100, 100, 100, 100, 100, 150,
                              200, 300, 300, 300, 300, 250,
                              250, 300, 300, 300, 300, 300,
                              400, 250, 250, 200, 150, 150],
      "ipv4:198.51.100.34" : [ 80,  80,  80,  80, 150, 150,
                              250, 400, 400, 450, 400, 200,
                              200, 350, 400, 400, 400, 350,
                              500, 200, 200, 200, 100, 100],
      "ipv4:203.0.113.45"  : [300, 400, 250, 250, 200, 150,
                              150, 100, 100, 100, 100, 100,
                              100, 100, 100, 100, 100, 150,
                              200, 300, 300, 300, 300, 250],
      "ipv6:2001:db8::10"  : [200, 250, 300, 300, 300, 300,
                              250, 300, 300, 300, 300, 350,
                              300, 400, 250, 150, 100, 100,
                              100, 150, 200, 250, 250, 300]
    }
  }
}
]]></artwork>
	</figure>
	<t>
   When
]]></sourcecode>
          <t>When the Client gets the Calendar for "routingcost", it sees that
	  the "calendar-start-time" is Monday at 00h00 GMT and member
	  "repeated" is equal to '4'.  It understands that the provided values
	  are valid until Thursday included and will only need to get a Calendar update
	  on Friday.</t>
        </section>
        <section title="Use case anchor="sect-5.2.4" numbered="true" toc="default">
          <name>Use Case and example: Example: ECS with a multi-cost Multi-cost Calendar for
	  routingcost and owdelay" anchor="sect-5.2.4"><t>
   In owdelay</name>
          <t>In this example, it is assumed that the ALTO Server implements multi-
   cost
	  multi-cost capabilities, as specified in <xref target="RFC8189"/> target="RFC8189"
	  format="default"/> . That is, an ALTO Client can request and receive
	  values for several cost types in one single transaction.  An
	  illustrating use case is a path selection done on the basis of 2
	  metrics: routing cost routingcost and owdelay.</t>

	<t>
   As
          <t>As in the previous example, the IRD indicates that the ALTO
	  Server provides "routingcost" Calendars in terms of 24 time
	  intervals of 1 hour (3600 seconds) each.</t>

	<t>
   For
          <t>For metric "owdelay", the IRD indicates that the ALTO Server
	  provides Calendars in terms of 12 time intervals interval values lasting each 5
	  minutes (300 seconds).</t>

	<t>
   In seconds) each.</t>
          <t>In the following example transaction, the ALTO Client sends its
	  request on Tuesday Tuesday, July 1st 2019 at 13:15.</t>
          <t>
   This example assumes that the values of metric "owdelay" and
   "routingcost" are encoded in 3 digits.</t>

	<figure><artwork><![CDATA[

<sourcecode><![CDATA[
POST calendar/endpointcost/lookup HTTP/1.1
Host: custom.alto.example.com
Content-Length: 390
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json application/alto-endpointcost+json,
        application/alto-error+json

{
  "cost-type" : {},
  "multi-cost-types" : [
    {"cost-mode" : "numerical", "cost-metric" : "routingcost"},
    {"cost-mode" : "numerical", "cost-metric" : "owdelay"}
  ],
  "calendared" : [true, true],
  "endpoints" : {
    "srcs": [ "ipv4:192.0.2.2" ],
    "dsts": [
      "ipv4:192.0.2.89",
      "ipv4:198.51.100.34",
      "ipv4:203.0.113.45",
      "ipv6:2001:db8::10"
    ]
  }
}

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

{
  "meta" : {
    "multi-cost-types" : [
      {"cost-mode" : "numerical", "cost-metric" : "routingcost"},
      {"cost-mode" : "numerical", "cost-metric" : "owdelay"}
    ],
    "calendar-response-attributes" : [
      {"cost-type-names" : [ "num-routingcost" ],
         "calendar-start-time" : "Mon, 30 Jun 2019 00:00:00 GMT",
         "time-interval-size" : 3600,
         "number-of-intervals" : 24,
         "repeated": 4 },
      {"cost-type-names" : [ "num-owdelay" ],
         "calendar-start-time" : "Tue, 1 Jul 2019 13:00:00 GMT",
         "time-interval-size" : 300,
         "number-of-intervals" : 12}
    ]
  },
  "endpoint-cost-map" : {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89"    : [[100, 100, 100, 100, 100, 150,
                               200, 300, 300, 300, 300, 250,
                               250, 300, 300, 300, 300, 300,
                               400, 250, 250, 200, 150, 150],
                              [ 20, 400,  20,  80,  80,  90,
                               100,  90,  60,  40,  30,  20]],
      "ipv4:198.51.100.34" : [[ 80,  80,  80,  80, 150, 150,
                               250, 400, 400, 450, 400, 200,
                               200, 350, 400, 400, 400, 350,
                               500, 200, 200, 200, 100, 100],
                              [ 20,  20,  50,  30,  30,  30,
                                30,  40,  40,  30,  20,  20]],
      "ipv4:203.0.113.45"  : [[300, 400, 250, 250, 200, 150,
                               150, 100, 100, 100, 100, 100,
                               100, 100, 100, 100, 100, 150,
                               200, 300, 300, 300, 300, 250],
                              [100,  90,  80,  60,  50,  50,
                                40,  40,  60,  90, 100,  80]],
      "ipv6:2001:db8::10"  : [[200, 250, 300, 300, 300, 300,
                               250, 300, 300, 300, 300, 350,
                               300, 400, 250, 150, 100, 100,
                               100, 150, 200, 250, 250, 300],
                              [ 40,  40,  40,  40,  50,  50,
                                50,  20,  10,  15,  30,  40]]
    }
  }
}
]]></artwork>
	</figure>
	<t>
   When
]]></sourcecode>

          <t>When receiving the response, the Client sees that the Calendar
	  values for metric "routingcost" are repeated for 4 iterations.
	  Therefore, in its next requests until the "routingcost" Calendar is
	  expected to change, the Client will only need to request a Calendar
	  for "owdelay".</t>
          <t>
   Without the ALTO Calendar extensions, the ALTO Client would have no
   clue on the dynamicity of the metric value change and would spend
   needless time requesting values at an inappropriate pace.  In
   addition, without the Multi-Cost ALTO capabilities, the ALTO Client
   would duplicate this waste of time as it would need to send one
   request per cost metric.</t>
        </section>
      </section>
    </section>
    <section title="IANA Considerations" anchor="sect-6"><t>
   This anchor="sect-6" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document does not define any new media types or introduce any
   new has no IANA considerations.</t> actions.</t>
    </section>
    <section title="Security Considerations" anchor="sect-7"><t>
   As anchor="sect-7" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>As an extension of the base ALTO protocol <xref target="RFC7285"/>, target="RFC7285"
      format="default"/>, this document fits into the architecture of the base protocol,
      protocol and hence the
   Security Considerations (Section 15) of <xref target="RFC7285"/> security considerations (<xref target="RFC7285"
      sectionFormat="of" section="15"/>) fully apply when this extension is
      provided by an ALTO Server.  For example, the same authenticity and
      integrity considerations (Section 15.1 of
   <xref target="RFC7285"/> (<xref target="RFC7285" sectionFormat="of"
      section="15.1"/>) still fully apply; the same considerations for the
      privacy of ALTO users (Section 15.4 of <xref target="RFC7285"/>) (<xref target="RFC7285" sectionFormat="of"
      section="15.4"/>) also still fully apply.</t>
      <t>
   The calendaring information provided by this extension requires
   additional considerations on three security considerations discussed
   in <xref target="RFC7285"/>: target="RFC7285" format="default"/>: potential undesirable guidance to Clients
   (Section 15.2 of <xref target="RFC7285"/>),
   (<xref target="RFC7285" sectionFormat="of" section="15.2"/>), confidentiality of ALTO information
   (Section 15.2 of <xref target="RFC7285"/>),
   (<xref target="RFC7285" sectionFormat="of" section="15.3"/>), and
   availability of ALTO (Section 15.5
   of <xref target="RFC7285"/>). (<xref target="RFC7285"
   sectionFormat="of" section="15.5"/>).  For example, by providing network information in the
   future in a Calendar, this extension may improve availability of
   ALTO,
   ALTO when the ALTO Server is unavailable but related information is
   already provided in the Calendar.</t>
      <t>
   For confidentiality of ALTO information, an operator should be
   cognizant that this extension may introduce a new risk: risk, a malicious ALTO
   Client may get information for future events that are scheduled
   through Calendaring.  Possessing such information, the malicious Client may use
   it to generate massive connections to the network at times where its load
   is expected to be high.</t>

	<t>
   To
      <t>To mitigate this risk, the operator should address the risk of ALTO
      information being leaked to malicious Clients or third parties. As
      specified in Section 15.3.2 ("Protection Strategies") of <xref target="RFC7285"/>, "Protection Strategies" (<xref target="RFC7285" sectionFormat="of"
      section="15.3.2"/>), the ALTO Server should
      authenticate ALTO Clients and use the Transport Layer Security (TLS)
      protocol so that Man In The Middle man-in-the-middle (MITM) attacks to intercept an ALTO
      Calendar are not possible.
   <xref target="RFC7285"/> "Authentication and Encryption" (<xref target="RFC7285" sectionFormat="of"
      section="8.3.5"/>) ensures the availability of such a solution in its
   Section 8.3.5.  "Authentication and Encryption", which
      solution. It specifies
   that: that "ALTO
      Server implementations as well as ALTO Client implementations
   MUST
      <bcp14>MUST</bcp14> support the "https" URI scheme of <xref target="RFC2818"/>
      target="RFC2818" format="default"/> and Transport Layer Security (TLS)
      of <xref target="RFC5246"/>".</t>

	<t>
   <xref target="RFC8446"/> specifies target="RFC5246" format="default"/>".</t>
      <t>Section <xref target="RFC8446" sectionFormat="bare" section="1"/> of
      TLS 1.3 and writes in its section 1: <xref target="RFC8446"/> states: "While TLS 1.3 is not directly compatible with previous
      versions, all versions of TLS incorporate a versioning mechanism which
      allows Clients and Servers to interoperably negotiate a common version
      if one is supported by both peers". ALTO Clients and Servers SHOULD
      <bcp14>SHOULD</bcp14> support both TLS 1.3 [RFC8446] <xref target="RFC8446"
      format="default"/> and TLS 1.2 [RFC5246], <xref target="RFC5246" format="default"/>
      and MAY <bcp14>MAY</bcp14> support and use newer versions of TLS as long as
      the negotiation process succeeds.
   </t>

   <t>
   The succeeds.</t>
      <t>The operator should be cognizant that the preceding mechanisms do not
      address all security risks. In particular, they will not help in the
      case of “malicious Clients” "malicious Clients" possessing valid authentication
      credentials. The threat here is that legitimate Clients have become
      subverted by an attacker and are now ‘bots’ 'bots' being asked to participate
      in a DDoS attack. The Calendar information now becomes valuable in
      knowing exactly when to perpetrate a DDoS attack. A mechanism mechanism, such as a
      monitoring system that detects abnormal behaviors behaviors, may still be needed.
   </t>

	<t>
   To needed.</t>

      <t>To avoid malicious or erroneous guidance from ALTO information, an
      ALTO Client should be cognizant that using calendaring information can
      have risks: (1) Calendar values, especially in "repeated"
   Calendars Calendars, may
      be only statistical, statistical and (2) future events may change. Hence, a more
      robust ALTO Client should adapt and extend protection strategies
      specified in Section 15.2 of <xref target="RFC7285"/>. target="RFC7285" sectionFormat="of" section="15.2"/>.
      For example, to be notified immediately when a particular ALTO value
      that the Client depends on changes, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14>
      that both the ALTO Client and ALTO Server using this extension support "ALTO
      "Application-Layer Traffic
              Optimization (ALTO) Incremental Updates Using Server-Sent Events(SSE)" Service
              Events (SSE)" <xref target="I-D.ietf-alto-incr-update-sse"/>.</t>
      target="RFC8895" format="default"/>.</t>
      <t>Another risk of erroneous guidance appears when the Server exposes an
      occurrence of a same cost type name in different elements of the
      Calendar objects array associated to an information resource. In this
      case, there is no way for the Client to figure out which Calendar object
      in the array is valid. The specification in this document recommends, in
      this case, that the Client uses the first encountered Calendar object
      occurrence containing the cost type name. However, the Client may want
      to avoid the risks of erroneous guidance associated to the use of
      potentially invalid Calendar values. To this end, as an alternative to
      the recommendation in this document, the Client MAY <bcp14>MAY</bcp14>
      ignore the totality of occurences occurrences of CalendarAttributes objects
      containing the cost type name and query this cost type using <xref target="RFC7285"/>.</t>
      target="RFC7285" format="default"/>.</t>
    </section>
    <section title="Operational Considerations" anchor="sect-8">
      <t>
         It anchor="sect-8" numbered="true" toc="default">
      <name>Operational Considerations</name>
      <t>It is important that both the operator of the network and the
      operator of the applications consider both the feedback aspect and the
      prediction-based (uncertainty) aspect of using the Cost Calendar.
      </t>

      <t>
         First Calendar.</t>
      <t>First, consider the feedback aspect and consider the Cost Calendar as
      a traffic-aware map service (e.g., Google Maps). Using the service
      without considering its own effect, a large fleet can turn a
      not-congested road into a congested one; a large number of individual
      cars each choosing a road with light traffic ("cheap link") can also
      result in congestion or result in a less optimal less-optimal global outcome (e.g.,
      the Braess' Paradox <xref target="Braess-paradox"/>).
      </t>

      <t>
         Next target="BRAESS_PARADOX"
      format="default"/>).</t>
      <t>Next, consider the prediction aspect. Conveying ALTO Cost Calendars
      tends to reduce the on-the-wire data exchange volume compared to
      multiple
         single cost single-cost ALTO transactions. An application using Calendars
      has a set of time-dependent values upon which it can plan its
      connections in advance with no need for the ALTO Client to query
      information at each time. Additionally, the Calendar response attribute
      "repeated", when provided, saves additional data exchanges in that it
      indicates that the ALTO Client does not need to query Calendars during a
      period indicated by this attribute. The preceding is true only when
      "accidents" do not happen.
      </t>

      <t>
         Although happen.</t>
      <t>Although individual network operators and application operators can
      choose their own approaches to address the aforementioned issues, this
      document recommends the following considerations. First, a typical
      approach to reducing instability and handling uncertainty is to ensure
      timely update of information. The SSE Service Service, as discussed in <xref target="sect-7"/>
      target="sect-7" format="default"/>, can handle
         updates, updates if supported by
      both the Server and the Client. Second, when a network operator updates
      the Cost Calendar and when an application reacts to the update, they
      should consider the feedback effects. This is the best approach even
      though there is theoretical analysis <xref target="Selfish-routing-Roughgarden-thesis"/>
      target="SELFISH_RTG_2002" format="default"/> and Internet based
      Internet-based evaluation <xref target="Selfish-routing-Internet-eval"/> target="SELFISH_RTG_2003"
      format="default"/> showing that uncoordinated behaviors do not always
      cause substantial sub-optimal results.
      </t> suboptimal results.</t>
      <t>
         High-resolution intervals may be needed when values change, sometimes
         during very small time intervals but in a significant manner.  A way
         to avoid conveying too many entries is to leverage on the "repeated"
         feature.  A Server can smartly set the Calendar start time and number
         of intervals so as to declare them "repeated" for a large number of
         periods,
         periods until the Calendar values change and are conveyed to
         requesting Clients.
      </t>

	   <t>
	    The
      <t>The newer JSON Data Interchange Format specification <xref target="RFC8259"/>
      target="RFC8259" format="default"/> used in ALTO Calendars replaces the
      older one <xref target="RFC7159"/> target="RFC7159" format="default"/> used in the base
      ALTO protocol <xref target="RFC7285"/>. target="RFC7285" format="default"/>. The newer JSON
      mandates UTF-8 text encoding to improve interoperability. Therefore,
      ALTO Clients and Servers implementations using UTF-{16,32} need to be
      cognizant of the subsequent interoperability risks and
         MUST
      <bcp14>MUST</bcp14> switch to UTF-8 encoding, encoding if they want to
      interoperate with Calendar-aware Servers and Clients.
      </t>

	</section>

	<section title="Acknowledgements" anchor="sect-9"><t>
   The authors would like to thank Fred Baker, Li Geng, Diego Lopez, He
   Peng and Haibin Song for fruitful discussions and feedback on earlier
   draft versions.  Dawn Chan, Kai Gao, Vijay Gurbani, Yichen Qian,
   Jürgen Schönwälder, and Brian Weis and Jensen Zhang provided substantial
   review feedback and suggestions to the protocol design.</t> Clients.</t>
    </section>
  </middle>
  <back>
	<references title="Normative References">
	&RFC2119;
   &RFC7231;
	&RFC7285;
	&RFC8174;
	&RFC8189;
	&RFC8259;
	&RFC5246;
	&RFC8446;
	&I-D.ietf-alto-incr-update-sse;

<displayreference target="I-D.ietf-alto-performance-metrics" to="ALTO_METRICS"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7285.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8189.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<!-- draft-ietf-alto-incr-update-sse-22 -->
<reference anchor="IEEE.754.2008"> anchor="RFC8895" target="https://www.rfc-editor.org/info/rfc8895">
<front>
          <title>Standard for Binary Floating-Point Arithmetic, IEEE Standard 754</title>
<title>Application-Layer Traffic Optimization (ALTO) Incremental Updates Using
Server-Sent Events (SSE)</title>
<author surname="Institute of Electrical and Electronics Engineers"> initials="W" surname="Roome" fullname="Wendy Roome">
<organization/>
</author>
<author initials="Y" surname="Yang" fullname="Y. Yang">
<organization/>
</author>
<date day="" month="August" year="2008"/> month='November' year='2020'/>
</front>
<seriesInfo name="RFC" value="8895"/>
<seriesInfo name="DOI" value="10.17487/RFC8895"/>
</reference>

        <reference anchor="IEEE.754.2019">
          <front>
            <title>IEEE Standard for Floating-Point Arithmetic</title>
            <author>
	      <organization>IEEE</organization>
            </author>
            <date month="June" year="2019"/>
          </front>
	  <seriesInfo name="IEEE" value="754-2019"/>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2019.8766229"/>
        </reference>
      </references>
	<references title="Informative References">

	&RFC2818;

	&RFC5693;
	&RFC6708;
	&RFC7159;

   &I-D.ietf-alto-performance-metrics;
   &I-D.xiang-alto-multidomain-analytics;
      <references>

        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5693.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6708.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7159.xml"/>

<!-- draft-ietf-alto-performance-metrics-09: I-D Exists -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-ietf-alto-performance-metrics-09.xml"/>

        <reference anchor="SENSE-sdn-e2e-net"> anchor="SENSE" target="http://sense.es.net/overview">
          <front>
            <title>SDN for End-to-End Networked Science at the Exascale (SENSE),
          http://sense.es.net/overview</title>

          <author surname="project supported by the Department (SENSE)</title>
            <author>
              <organization>Department of Energy Office of Science Advanced
	      Scientific Computing Research (ASCR) Program">
            <organization/> Program</organization>
            </author>

          <date day="" month="" year=""/>
            <date/>
          </front>
        </reference>

        <reference anchor="Braess-paradox"> anchor="BRAESS_PARADOX">
          <front>
            <title>The Prevalence of Braess' Paradox</title>
            <author initials="R." surname="Steinberg" fullname="Richard Steinberg"/>
            <author initials="W." surname="Zangwill" fullname="Willard I. Zangwill"/>
            <date day="1" month="August" year="1983"/>
          </front>
         <seriesInfo name="Transportation Science" value="Vol. 17
            <refcontent>Transportation Science Vol. 17, No. 3"/> 3</refcontent>
	    <seriesInfo name="DOI" value="10.1287/trsc.17.3.301"/>
        </reference>

        <reference anchor="Unicorn-fgcs"> anchor="UNICORN-FGCS">
          <front>
            <title>Unicorn: Unified resource orchestration for multi-domain,
	    geo-distributed data analytics</title>
            <author initials="Q." surname="Xiang" fullname="Qiao Xiang"/>
            <author initials="T." surname="Wang" fullname="Tony Wang"/>
            <author initials="J." surname="Zhang" fullname="Jensen Zhang"/>
            <author initials="H." surname="Newman" fullname="Harvey Newman"/>
	    <author initials="Y." surname="Yang" fullname="Yang Richard Yang"/>
            <author initials="Y." surname="Liu" fullname="Jace Liu"/>
            <date day="" month="April" month="March" year="2019"/>
          </front>
         <seriesInfo name="Future
            <refcontent>Future Generation of Computer Systems (FGCS)" value="Volume (FGCS), Vol. 93,
	    Pages 188-197"/> 188-197</refcontent>
	    <seriesInfo name="DOI" value="10.1016/j.future.2018.09.048"/>
	    <seriesInfo name="ISSN" value="0167-739X"/>
        </reference>

        <reference anchor="Selfish-routing-Roughgarden-thesis"> anchor="SELFISH_RTG_2002">
          <front>
            <title>Selfish Routing</title>
            <author initials="T." surname="Roughgarden" fullname="Tim Roughgarden"/>
            <date day="1" month="May" year="2002"/>
          </front>
         <seriesInfo name="Dissertation
            <refcontent>Dissertation Thesis, Cornell" value="2002"/> Cornell</refcontent>
        </reference>

        <reference anchor="Selfish-routing-Internet-eval"> anchor="SELFISH_RTG_2003">
          <front>
            <title>Selfish Routing in Internet-LIke Environments</title>
            <author initials="L." surname="Qiu" fullname="Lili Qiu"/>
            <author initials="Y." surname="Yang" fullname="Y. fullname="Yang Richard Yang"/>
            <author initials="Y." surname="Zhang" fullname="Yin Zhang"/>
            <author initials="S." surname="Shenker" fullname="Scott Shenker"/>
            <date day="1" month="August" year="2001"/> year="2003"/>
          </front>
	  <seriesInfo name="Proceedings name="DOI" value="10.1145/863955.863974"/>
            <refcontent>Proceedings of ACM SIGCOMM" value="2001"/> SIGCOMM '03</refcontent>
        </reference>
      </references>
    </references>

    <section anchor="acks" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
   The authors would like to thank <contact fullname="Fred Baker"/>, <contact
   fullname="Li Geng"/>, <contact fullname="Diego Lopez"/>, <contact
   fullname="He Peng"/>, and <contact fullname="Haibin Song"/> for fruitful
   discussions and feedback on earlier draft versions.  <contact
   fullname="Dawn Chan"/>, <contact fullname="Kai Gao"/>, <contact
   fullname="Vijay Gurbani"/>, <contact fullname="Yichen Qian"/>, <contact
   fullname="Jürgen Schönwälder"/>, <contact fullname="Brian Weis"/>, and
   <contact fullname="Jensen Zhang"/> provided substantial review feedback and
   suggestions to the protocol design.</t>
    </section>
  </back>

</rfc>