RFC 8896

Application-Layer Traffic Optimization (ALTO) Cost Calendar

📅 published November 2020, from ietf

Application-Layer Traffic Optimization (ALTO) Cost Calendar 💖

Okay bestie, this is RFC 8896 🦋, a Standards Track document (so it's a real, binding protocol spec, no cap). It was published in November 2020 and it's ISSN 2070-1721 ✨. The authors are S. Randriamasy (Nokia Bell Labs), Y. Yang (Yale University), Q. Wu (Huawei), L. Deng (China Mobile), and N. Schwan (Thales Deutschland) 🫶. It doesn't list anything it obsoletes or updates 💅.

Abstract ✨

This document extends the base ALTO protocol so applications can decide not just 'where' to connect but also 'when' ⏰. That's super useful for bulk data transfers that want to get scheduled for an off-peak hour, for example 🌙. It introduces the ALTO Cost Calendar, where an ALTO Server shows ALTO cost values inside JSON arrays and each value matches a given time interval 📅. The time intervals and other Calendar attributes are specified in the Information Resources Directory and in ALTO Server responses 💜.

Status of This Memo 🎀

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8896.

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🗂️

   1.  Introduction
     1.1.  Some Recent Known Uses
     1.2.  Terminology
   2.  Requirements Language
   3.  Overview of ALTO Cost Calendars and Terminology
     3.1.  ALTO Cost Calendar Overview
     3.2.  ALTO Cost Calendar Information Features
     3.3.  ALTO Calendar Design Characteristics
       3.3.1.  ALTO Cost Calendar for All Cost Modes
       3.3.2.  Compatibility with Legacy ALTO Clients
   4.  ALTO Calendar Specification: IRD Extensions
     4.1.  Calendar Attributes in the IRD Resource Capabilities
     4.2.  Calendars in a Delegate IRD
     4.3.  Example IRD with ALTO Cost Calendars
   5.  ALTO Calendar Specification: Service Information Resources
     5.1.  Calendar Extensions for Filtered Cost Maps (FCM)
       5.1.1.  Calendar Extensions in Filtered Cost Map Requests
       5.1.2.  Calendar Extensions in Filtered Cost Map Responses
       5.1.3.  Use Case and Example: FCM with a Bandwidth Calendar
     5.2.  Calendar Extensions in the Endpoint Cost Service
       5.2.1.  Calendar-Specific Input in Endpoint Cost Requests
       5.2.2.  Calendar Attributes in the Endpoint Cost Response
       5.2.3.  Use Case and Example: ECS with a routingcost Calendar
       5.2.4.  Use Case and Example: ECS with a Multi-cost Calendar
               for routingcost and owdelay
   6.  IANA Considerations
   7.  Security Considerations
   8.  Operational Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction 🧚

The base ALTO protocol in [RFC7285] gives guidance to overlay applications that need to pick one or several hosts from a set of candidates that can provide a desired resource 🎯. That guidance is based on parameters that affect how well data moves between the hosts, like topological distance 🗺️. The goal of ALTO is to boost the Quality of Experience (QoE) in the application while optimizing resource usage in the underlying network infrastructure ✨.

The ALTO protocol in [RFC7285] specifies a network map that groups endpoints into provider-defined network regions, identified by Provider-defined Identifiers (PIDs) 📍. The Cost Map Service, Endpoint Cost Service (ECS), and Endpoint Ranking Service then provide ISP-defined costs and rankings for connections among the specified endpoints and PIDs, and so they give application clients an incentive to connect to ISP-preferred locations, for instance to reduce their costs 💰. For the reasons outlined in the ALTO problem statement [RFC5693] and requirement AR-14 of [RFC6708], ALTO does not disseminate network metrics that change frequently 🙈. Costs can fluctuate for many reasons, like instantaneous traffic load, diurnal patterns of traffic demand, or planned events such as network maintenance, holidays, or highly publicized events 📉. So an ALTO application that wants 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, which is, at best, fragile and 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, by deferring backups or other background traffic to off-peak hours 🌙.

When the ALTO cost value changes are predictable over a certain period of time and the application doesn't need immediate data transfer, it can save time by getting the whole set of cost values over that period in one single ALTO response 🧠. Using this set to schedule data transfers helps optimize network resource usage and QoE 🔥. ALTO Clients and Servers can also minimize their workload by reducing and accordingly scheduling their data exchanges 💪.

This document extends [RFC7285] 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. On top of this functional ALTO enhancement, we expect to further save network and storage resources by gathering multiple cost values for one cost type into one single ALTO Server response 🫶.

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

In the rest of this document, Section 3 provides the design characteristics. Sections 4 and 5 define the formal specifications for the IRD and the information resources. IANA, security considerations, and operational considerations are addressed respectively in Sections 6, 7, and 8 💖.

1.1. Some Recent Known Uses 🌈

A potential use case is implementing smart network services that allow applications to dynamically build end-to-end, virtual networks to satisfy given demands with no manual intervention ✨. For example, data-transfer automation applications may need a network service to determine the availability of bandwidth resources so they can decide when to transfer their data sets 🚚. The SENSE project [SENSE] 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 🦋.

The need for future scheduling of 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 data analytics, see [UNICORN-FGCS] 🌍.

1.2. Terminology 📖

  • ALTO transaction: A request/response exchange between an ALTO Client and an ALTO Server.
  • Client: When used with a capital "C", this term refers to an ALTO Client.
  • Calendar, Cost Calendar, ALTO Calendar: When used with capitalized words, these terms refer to an ALTO Cost Calendar.
  • Calendared: This adjective qualifies information resources providing Cost Calendars and information on costs that are provided in the form of a Cost Calendar.
  • Endpoint (EP): An endpoint is defined as in Section 2.1 of [RFC7285]. 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.
  • ECM: An abbreviation for Endpoint Cost Map.
  • FCM: An abbreviation for Filtered Cost Map.
  • Server: When used with a capital "S", this term refers to an ALTO Server.

2. Requirements Language 🔑

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

When the words appear in lower case, they are to be interpreted with their natural language meanings.

3. Overview of ALTO Cost Calendars and Terminology 🦋

This section gives a high-level overview of the design. It assumes the reader is familiar with the ALTO protocol [RFC7285] and its Multi-Cost ALTO extension [RFC8189] 📚.

3.1. ALTO Cost Calendar Overview ✨

okay so an ALTO Cost Calendar from the ALTO Server gives you 2 info items 💅

  • an array of values for a given metric, where each value is the metric for one time interval, and the value array can sometimes be a cyclic pattern that repeats a certain number of times 🔁
  • attributes that describe the time scope of the Calendar (the size and number of the intervals, plus the date the Calendar starts) so the ALTO Client can read the values properly 🧠

the Calendar is basically a "time table" 🗓️ so you can figure out the best time to schedule data transfers and proactively manage app traffic when you can see stuff coming, like a crowd at a concert or a game, traffic-heavy holidays, or network maintenance 🎟️🎄🛠️ a Calendar can be seen as a synthetic abstraction of, say, real measurements from earlier periods that have had statistics computed on them 📊 but like any schedule, unexpected network incidents can mean the current ALTO Calendar needs an update and a resend to the ALTO Clients that need it 😭 the "ALTO Incremental Updates Using Server-Sent Events (SSE)" Service [RFC8895] can be used to update the Calendar directly when values change, but only if both the Server and the Client support it 🫶

most likely the ALTO Cost Calendar gets used for the Endpoint Cost Service 💖 this assumes you already have a limited set of feasible endpoints for a non-real-time app, those endpoints don't need to be accessed right away, and their access can be scheduled within a given time period ⏰ the Filtered Cost Map Service also works as long as the Map is small enough 🦋

3.2. ALTO Cost Calendar Information Features 🎀

the Calendar attributes show up in the Information Resources Directory (IRD) and in ALTO Server responses 🗂️ the IRD announces attributes that don't have date values in its information resources capabilities, while attributes with time-dependent values come in the "meta" section of Server responses ✨ the ALTO Cost Calendar attributes give you this info:

  • attributes that describe the time scope of the Calendar value array:
    • "time-interval-size": the time interval size that applies to each Calendar value, defined in seconds, and it can cover a wide range of values 🕒
    • "number-of-intervals": how many intervals the Calendar provides 🔢
  • "calendar-start-time": says when the Calendar starts, meaning which date the first value of the Cost Calendar applies to 📅
  • "repeated": an optional attribute saying how many iterations of the provided Calendar will have the same values 🔁 the Server can use it to let the Client schedule its next request, which saves the Client's own workload by cutting down on processing of similar requests 💅

"repeated" can be a super high value if a Calendar is a cyclic value pattern that the Server thinks is valid for a long time 🌙 in that case the Server only updates the Calendar values once that period is over, or if something unexpected happens on the network 🚨 see Section 8 for more on this 🧚

3.3. ALTO Calendar Design Characteristics 💜

this document uses the notations defined in "Notation" (Section 8.2 of [RFC7285]) 📝

the extensions in this document encode requests and responses using JSON [RFC8259] 🎀

in the base protocol [RFC7285], an ALTO cost is specified as a generic JSONValue [RFC8259] so extensions can work 🧩 but that section (Section 11.2.3.6 of [RFC7285]) says:

An implementation of the protocol in this document SHOULD 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.

this document extends the definition of a legacy cost map given in [RFC7285] so a cost entry can be an array of values, with one value per time interval, instead of just one number, when the Cost Calendar functionality is turned on for that cost 🌈 so the implementor of this extension MUST consider that a cost entry is an array of values if this cost has been queried as a Calendar 💀

specifically, an implementation of this extension MUST parse the "number-of-intervals" attribute of the Calendar attributes in an IRD entry that announces a service providing a Cost Calendar for a given cost type 🔍 the implementation then knows that a cost entry of the service will be an array of values, and the expected size of the array is whatever "number-of-intervals" says 🧮 the following rules try to keep the array size the Server announces consistent with the array size the Client actually gets:

  • the size of the array of values conveyed in a Cost Calendar and received by the Client MUST be equal to the value of the "number-of-intervals" attribute indicated in the IRD for the requested cost type 💯
  • when the size of the array the Client receives is different from the expected size, the Client SHOULD ignore the received array 🙈

to realize an ALTO Calendar, this document extends the IRD and the ALTO requests and responses for Cost Calendars ✨

this extension is designed to be lightweight and keep backwards compatibility with base protocol ALTO Clients and with other extensions 🫶 it relies on "Parsing of Unknown Fields" (Section 8.3.7 of [RFC7285]), which says: "Extensions may include additional fields within JSON objects defined in this document. ALTO implementations MUST ignore unknown fields when processing ALTO messages." 🙈

the Calendar-specific capabilities are built into the information resources of the IRD and into the "meta" member of ALTO responses to Cost Calendar requests 🎁 a Calendar and its capabilities are tied to a given information resource, and within that resource, to a given cost type 🎯 this design has a few perks:

  • it does not introduce a new mode 🙅‍♀️
  • it does not introduce new media types 🙅‍♀️
  • it lets an ALTO Server offer, for a cost type, different Calendars with attributes that are specific to each information resource providing a Calendar for that cost type, instead of being globally specific to the cost type 👑

the applicable Calendared information resources are:

  • the Filtered Cost Map and
  • the Endpoint Cost Map 🦋

the ALTO Server gets to pick how often it provides cost Calendars to ALTO Clients ⏱️ it can either provide Calendar updates starting from the request date, or carefully schedule its updates to take advantage of any repetition or periodicity in the Calendar values 🔁

because Calendar attributes are specific to an information resource, a Server can adjust the granularity of the calendared info to keep the volume of exchanged data down 📦 for example, say a Server provides a Calendar for cost type name "routingcost" 🛣️ the Server might offer a Calendar in a Cost Map resource, which can be super voluminous, as an array of 6 intervals that each last 4 hours 🕓 it could also offer a Calendar in an Endpoint Cost Map resource, which is potentially less voluminous, as a finer-grained array of 24 intervals that each last 1 hour 🌸

the ALTO Server does not support constraints on Calendars, as long as the Calendars are requested for numerical values, and there are two main reasons 🙅‍♀️

  • constraints on an array of values can be all kinds of things 🌀 some Clients may refuse a Calendar if even one single value violates a constraint, while other Clients may tolerate Calendars with values that violate constraints, for example at certain times 🕰️ so expressing constraints in a way that covers every possible Client preference is really challenging 😭
  • if constraints were supported, the processing overhead would be massive for the Server, because it would have to parse all the values in the Calendar array before returning a response 🥵

since providing the constraint functionality together with the Calendar functionality isn't feasible for the reasons above, the two features are mutually exclusive 🚫 the lack of constraints on Filtered Cost Map and Endpoint Cost Map Calendars is a divergence from the non-calendared information resources defined in [RFC7285] and extended in [RFC8189], which do support optional constraints 💅

3.3.1. ALTO Cost Calendar for All Cost Modes 🌷

an ALTO Cost Calendar is a great fit for values encoded in the "numerical" mode 🔢 but a Calendar can also represent metrics in other modes that are considered compatible with time-varying values 🌈 for example, types of cost values (like JSONBool) can be calendared too, since the value might be 'true' or 'false' depending on given time periods or something similar 🔀 values represented by strings, like "medium", "high", "low", "blue", and "open", work too 🎨

also note that a Calendar suits time-varying metrics in the "ordinal" mode as well, as long as those values change over time and the ALTO Server provides updates of cost-value-based preferences ⭐

3.3.2. Compatibility with Legacy ALTO Clients 🫧

the ALTO protocol extensions for Cost Calendars were defined so that Calendar-capable ALTO Servers can also provide legacy information resources to legacy ALTO Clients 🤝 meaning a legacy ALTO Client can request resources and get responses as specified in [RFC7285] 💖

a Calendar-aware ALTO Server MUST implement the base protocol specified in [RFC7285] 🛠️

a Calendar-aware ALTO Client MUST implement the base protocol specified in [RFC7285] 🛠️

so, as a consequence, when a metric is available as a Calendar array, it also MUST be available as a single value, as required by [RFC7285] 💅 in this case the Server gives the current value of the metric to either Calendar-aware Clients that aren't interested in future or time-based values, or to Clients that only implement [RFC7285] 🎀

for compatibility with legacy ALTO Clients specified in [RFC7285], calendared information resources are not applicable for full cost maps, and here's why 🙈 a legacy ALTO Client would get a calendared cost map via an HTTP 'GET' command 📥 as specified in Section 8.3.7 of [RFC7285], it will ignore the Calendar attributes indicated in the "meta" of the responses 🙉 so, without info on the Calendar attributes, it can't correctly interpret and process the values of the received array of Calendar cost values 💀

calendared information resources MUST be requested via the Filtered Cost Map Service or the Endpoint Cost Service using a POST method.

4. ALTO Calendar Specification: IRD Extensions 🧚

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 features is provided in Section 4.3 ✨

4.1. Calendar Attributes in the IRD Resource Capabilities ✨

okay bestie, first things first 💅 a Cost Calendar for a given cost type MUST be indicated in the IRD by an object of type CalendarAttributes 🎀. That object lives in the calendar-attributes member of a resource entry, and that member is an array of CalendarAttributes objects. Each CalendarAttributes object lists a set of one or more cost types it applies to 🫶.

Now the drama 🙈 a cost type name MUST NOT appear more than once in the calendar-attributes member of a resource entry. If it does show up twice, that MUST cause the ALTO Client to ignore every occurrence of that name after the first one it finds. The Client SHOULD consider the CalendarAttributes object in the array holding the first encountered occurrence as the valid one for that cost type 👑. Lowkey though, the Client may want to avoid the risks of erroneous guidance that come with potentially invalid Calendar values. If it goes that route, the Client MAY ignore the totality of occurrences of CalendarAttributes objects containing the cost type name and query the cost type using [RFC7285] 🧚.

Here's how the CalendarAttributes object gets encoded in JSON [RFC8259] 💖:

CalendarAttributes calendar-attributes <1..*>;

object{
  JSONString cost-type-names <1..*>;
  JSONNumber time-interval-size;
  JSONNumber number-of-intervals;
} CalendarAttributes;

Let's break down each field 🍓

  • cost-type-names: an array of one or more elements naming the cost types in the IRD entry that the values of time-interval-size and number-of-intervals apply to. 🌈
  • time-interval-size: the duration of one ALTO Calendar time interval, measured in seconds ⏰. The value is a non-negative JSONNumber. Like, 300 and 7200 mean each Calendar value sticks around for 5 minutes and 2 hours respectively 🌸. Since an interval size like 100 ms can be smaller than that unit, the value may be a floating point (like 0.1) ✨. Both ALTO Clients and Servers should be aware of potential precision issues from 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 stay consistent with [RFC7285] on floating point numbers, the Server and the Client SHOULD use IEEE 754 double-precision floating point [IEEE.754.2019] to store this value 💜.
  • number-of-intervals: a strictly positive integer (greater or equal to 1) that tells you how many values the Cost Calendar array has 🦋.

A few more things you need to know, iykyk 👀

  • An ALTO Server SHOULD 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 get it. Main character energy for the Server, honestly 🫶.
  • The cost-type-names attribute is paired with time-interval-size and number-of-intervals because multiple cost types may share the same values for those two attributes. To avoid redundancies, cost type names sharing the same time-interval-size and number-of-intervals values get grouped together in cost-type-names 🧠. In the example IRD provided in Section 4.3, the information resource filtered-cost-map-calendar provides a Calendar for the cost type names num-routingcost, num-throughputrating, and string-servicestatus. The 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 7200 and 12 respectively 🎀.
  • Multiplying time-interval-size by number-of-intervals gives you the duration of the provided Calendar ⏳. For example, an ALTO Server may provide a Calendar for ALTO values changing every 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. Math is literally slaying 🔥.

4.2. Calendars in a Delegate IRD 🦋

It can be super useful to tell apart IRD resources supported by the base ALTO protocol from the ones supported by its extensions 🌸. One way to do this is for a "root" ALTO Server running [RFC7285] resources at a given domain to delegate its "specialized" information resources, like the ones providing Cost Calendars, to another ALTO Server running in a subdomain. The "root" ALTO Server can provide a Calendar-specific resource entry that has a media-type of application/alto-directory+json and that specifies the URI that lets you retrieve the location of a Calendar-aware Server and discover its resources. This option is described in "Delegation Using IRD" (Section 9.2.4 of [RFC7285]) 🧚.

This document gives an example where a "root" ALTO Server runs in a domain called alto.example.com. It delegates the announcement of Calendar 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 💖.

Another perk of delegation is that some cost types for some resources may be way more useful as Cost Calendars, and it makes zero sense to fetch them as a single value 💅. For example, if a cost type has predictable, frequently changing values calendared in short time intervals, such as a minute, it saves time and network resources to track those cost values through a focused delegate Server instead of the more general "root" Server 🥹✨.

4.3. Example IRD with ALTO Cost Calendars 🎀

okay so this section shows off a whole example ALTO Server IRD 💅 and it supports a bunch of cost metrics and cost modes. the star of the show is routingcost in the numerical mode, because [RFC7285] makes that one mandatory, so every Server has to have it ✨

heads up though: the other 3 metrics in here are fictitious, made up just for illustration. they're examples only and should not be used or considered as normative 🙈

the cost type names used in the example IRD are:

  • "num-routingcost": refers to metric routingcost in the numerical mode, as defined in [RFC7285] and registered with IANA 💖
  • "num-owdelay": refers to fictitious performance metric owdelay in the numerical mode, reflecting the one-way packet transmission delay on a path 🦋 a related performance metric is currently under definition in [ALTO_METRICS] 👀
  • "num-throughputrating": refers to fictitious metric throughputrating in the numerical mode, reflecting the provider preference in terms of end-to-end throughput 🚀
  • "string-servicestatus": refers to fictitious metric servicestatus, which contains a string reflecting the availability (defined by the provider) of, for instance, path connectivity 🧚

the example IRD includes 2 specific URIs that provide Calendars:

the design of the Calendar capabilities lets some Calendars with the same cost type name show up in several information resources, each with different Calendar attributes. this happens for Calendars on "num-routingcost", "num-throughputrating", and "string-servicestatus", which are available in both the Filtered Cost Map and the Endpoint Cost Service. the only difference is the time interval sizes for "num-throughputrating" and "string-servicestatus" 🌈

here's the client asking for the IRD:

--- 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

and here's the Server's response, serving up the goods 👑

--- 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
          }
        ]
      }
    }
  }
}

so for the Filtered Cost Map Service in this IRD:

  • the Calendar for "num-routingcost" and "num-throughputrating" is an array of 12 values, each one covering a time interval of 7200 seconds (2 hours) 🕑
  • the Calendar for "string-servicestatus" is an array of 48 values, each one covering a time interval of 1800 seconds (30 minutes) 🥐

and for the Endpoint Cost Service:

  • the Calendar for "num-routingcost" is an array of 24 values, each one covering a time interval of 3600 seconds (1 hour) ⏰
  • the Calendar for "num-owdelay" is an array of 12 values, each one covering a time interval of 300 seconds (5 minutes) 🎈
  • the Calendar for "num-throughputrating" is an array of 60 values, each one covering a time interval of 60 seconds (1 minute) 💫
  • the Calendar for "string-servicestatus" is an array of 30 values, each one covering a time interval of 120 seconds (2 minutes) 🌟

one thing to notice: "cost-constraints" is present with the value true in both "filtered-cost-map-calendar" and "endpoint-cost-map-calendar". even though a Calendar-aware ALTO Server doesn't support constraints (the reasons are explained in Section 3.3), it MUST support constraints on cost types that are not requested as Calendars but are requested as specified in [RFC7285] and [RFC8189]. so constraints still work for those, no cap 🫶

5. ALTO Calendar Specification: Service Information Resources 🦋

this section documents the extensions to two basic ALTO information resources, Filtered Cost Maps and the Endpoint Cost Service, so they can offer calendared information 💜

both extensions return a calendar start time (calendar-start-time, which is a point in time). this value MUST be specified as an HTTP "Date" header field, using the IMF-fixdate format from Section 7.1.1.1 of [RFC7231]. quick note: IMF-fixdate says "GMT" for the time zone, not "UTC". here's an example 🕰️

Date: Tue, 15 Nov 2019 08:12:31 GMT

5.1. Calendar Extensions for Filtered Cost Maps (FCM) 🌈

a legacy ALTO Client requests Filtered Cost Maps and gets Filtered Cost Map responses, as specified in [RFC7285]. easy peasy 🍓

5.1.1. Calendar Extensions in Filtered Cost Map Requests 💅

the input parameters of a "legacy" Filtered Cost Map request, defined by object ReqFilteredCostMap in Section 11.3.2 of [RFC7285], get augmented with one extra member. the same augmentation applies to object ReqFilteredCostMap as defined in Section 4.1.2 of [RFC8189] ✨

a Calendar-aware ALTO Client that wants a Calendar on a given cost type for a Filtered Cost Map resource with Calendar capabilities MUST add the following field to its input parameters:

JSONBoolean calendared<1..*>;

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 [RFC8189] 🧠

each entry lines up with the requested metric at the same array position. each boolean says whether or not the ALTO Server should provide the values for that cost type as a Calendar. the array MUST contain exactly N boolean values, otherwise, the Server returns an error 🚨

this field MUST NOT be included if no member "calendar-attributes" is specified in this information resource 🙅‍♀️

if the calendared value is 'true' for a cost type name that has no Calendar attributes specified, then an ALTO Server, whether it implements this document's extensions or only [RFC7285], MUST ignore it and return a response with a single cost value, as specified in [RFC7285]. ignore-and-carry-on energy 🫠

if this field isn't present, it MUST be assumed to have only values equal to 'false' 🤍

a Calendar-aware ALTO Client that supports requests for only one cost type at a time, and wants a Calendar, MUST provide an array of 1 element:

"calendared" : [true],

and a Calendar-aware ALTO Client that supports requests for more than one cost type at a time, as specified in [RFC8189], MUST provide an array of N values set to 'true' or 'false'. which one it picks depends on whether it wants each applicable cost type value as a single value or as a calendared value 🎀

5.1.2. Calendar Extensions in Filtered Cost Map Responses ✨

okay so bestie, in a calendared ALTO Filtered Cost Map, every cost value between a source and a destination is a JSON array of JSON values 📊. That array has exactly as many values as the number-of-intervals member says, and that number comes from the Calendar attributes listed in the IRD. These attributes get sent back as metadata in the FCM response 🎀. Each element of the array is valid for the time interval that matches its position in the array. Position is everything here 💅

The FCM response carries a bunch of metadata, and it comes in two flavors:

  • some of it has nothing to do with Calendars, and it's there so everything stays compatible with [RFC7285] and [RFC8189] 🫶
  • some of it is Calendar-specific 🦋

Let's talk about the non-Calendar stuff first. The non-Calendar-specific "meta" fields of a calendared Filtered Cost Map response MUST include at least:

  • if the ALTO Client asks for cost values for one cost type at a time, then only the "meta" fields that [RFC7285] specifies for these information service responses:
    • "dependent-vtags" and
    • the "cost-type" field.
  • if the ALTO Client implements the Multi-Cost ALTO extension from [RFC8189] and asks for cost values for several cost types at once, then the "meta" fields that [RFC8189] specifies for these information service responses:
    • "dependent-vtags",
    • the "cost-type" field with its value set to '{}', for backwards compatibility with [RFC7285], and
    • the "multi-cost-types" field.

If the Client request does not provide the "calendared" member, or if it provides it with the value 'false' for all the requested cost types, then the ALTO Server response is exactly as specified in [RFC7285] and [RFC8189]. Totally normal, no drama 🌸

If the value of "calendared" is 'false' for a given requested cost type, then the ALTO Server MUST return, for that cost type, a single cost value as specified in [RFC7285] 🍓

If the value of "calendared" is 'true' for a given requested cost type, then the ALTO Server returns, for that cost type, a cost value Calendar, as specified above in this section 🗓️ On top of the non-Calendar "meta" members we just went over, the Server MUST provide a Calendar-specific metadata field. Obsessed with how strict this is, honestly 😭

Now the Calendar-specific "meta" field. A calendared Filtered Cost Map response MUST include a member called "calendar-response-attributes", which describes the properties of the Calendar. Here's how it works:

  • "calendar-response-attributes" is an array of one or more objects of type "CalendarResponseAttributes" 👑
  • each "CalendarResponseAttributes" object in the array is specified for one or more cost types. Those are cost types where "calendared", in the ReqFilteredCostMap object of the Client request, is 'true', and where a Calendar is provided for the requested information resource 🌈
  • the "CalendarResponseAttributes" object that applies to a cost type name has a matching "CalendarAttributes" object defined for that cost type name in the IRD capabilities of the requested information resource. That matching object is the entry in the "calendar-attributes" array member of the IRD resource entry that includes the name of the requested cost type. The matching "CalendarAttributes" object has the same values as the "CalendarResponseAttributes" object for the "time-interval-size" and "number-of-intervals" members. The "CalendarResponseAttributes" object includes all the members of the matching "CalendarAttributes" object too 💖

The format of member "CalendarResponseAttributes is defined as follows:

CalendarResponseAttributes calendar-response-attributes <1..*>;

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:

"cost-type-names": : An array of one or more cost type names that the other members of CalendarResponseAttributes apply to, and for which a Calendar has been requested. The value of this member is a subset of the "cost-type-names" member of the matching "CalendarAttributes" object in the "calendar-attributes" array member in the IRD. This member MUST be present when Cost Calendars are provided for more than one cost type 🧚

"calendar-start-time": : Tells you the date when the first value of the Calendar applies. The value is a string that, as specified in Section 5, contains an HTTP "Date" header field using the IMF-fixdate format from Section 7.1.1.1 of [RFC7231]. The value given for "calendar-start-time" SHOULD NOT be later than the request date ⏰

"time-interval-size": : Same as Section 4.1, with the same value as in the matching "CalendarAttributes" object 📏

"number-of-intervals": : Same as Section 4.1, with the same value as in the matching "CalendarAttributes" object 🔢

"repeated": : An optional field for Calendars. It's an integer N that is greater than or equal to '1', and it tells you how many iterations of the Calendar value array, starting at the date given by "calendar-start-time", have the same values. The number N includes the iteration in the returned response 🔁

Let's do an example, because examples are everything 🧁 Say the "calendar-start-time" member is "Mon, 30 Jun 2019 00:00:00 GMT", the "time-interval-size" member is '3600', the "number-of-intervals" member is '24', and the value of "repeated" is '4'. That means the Calendar values are the same on Monday, Tuesday, Wednesday, and Thursday, over a 24-hour period starting at 00:00:00 GMT. The ALTO Client can use the same Calendar for the next 4 days starting at "calendar-start-time", and it only needs to request a new one for Friday, July 4th at 00:00:00 GMT 🎉

Okay, so "repeated" can get really, really big 📈 That happens when a Calendar shows a cyclic value pattern that the Server thinks is valid for a long time, so it'll only update once that period is over, or if something unexpected happens on the network 🚨 In that second case, the Client gets notified if it uses the "ALTO Incremental Updates Using Server-Sent Events (SSE)" Service from [RFC8895]. Which is why it is RECOMMENDED that ALTO Servers providing ALTO Calendars also provide the "ALTO Incremental Updates Using Server-Sent Events (SSE)" Service, which is specified in [RFC8895]. Likewise, ALTO Clients that can use ALTO Calendars SHOULD also use the SSE Service. Also check out Section 8, "Operational Considerations", for more on this 💜

5.1.3. Use Case and Example: FCM with a Bandwidth Calendar 🚀

Here's a good one for non-real-time information that can go into a Calendar: expected path throughput 🛣️ Sure, end systems can measure transmission rate in real time, but the operator of a data center is the one who can set preferences for specific paths during specific time periods, so traffic peaks from daily usage patterns don't wreck everything 🌅 In this example, we assume an ALTO Client asks for a Calendar of network-provider-defined throughput ratings, as listed in the IRD, so it can schedule its bulk data transfers like we talked about in the use cases 📅

In the example IRD, Calendars for the cost type name "num-throughputrating" are available for the information resources "filtered-cost-calendar-map" and "endpoint-cost-map-calendar". The ALTO Client requests a Calendar for "num-throughputrating" with a POST request for a Filtered Cost Map 💌

Let's say the ALTO Client sends its request on Tuesday, July 1st 2019 at 13:15. The Server returns Calendars with arrays of 12 numbers for each source and destination pair. In this example, the values for the metric "throughputrating" are encoded in 2 digits 🔟

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] }
  }
}

5.2. Calendar Extensions in the Endpoint Cost Service 🧁

This document extends the Endpoint Cost Service, as defined in Section 11.5.1 of [RFC7285], by adding new input parameters and capabilities, and by returning JSONArrays instead of JSONNumbers as the cost values. The media type (Section 11.5.1.1 of [RFC7285]) and HTTP method (Section 11.5.1.2 of [RFC7285]) are unchanged 💅

5.2.1. Calendar-Specific Input in Endpoint Cost Requests ✨

okay so the extensions for calendared Endpoint Cost Map requests are the same as the ones for the Filtered Cost Map Service 🎀 (you can check Section 5.1.1 of this document for the details). The rules around ECM request extensions also match the FCM ones in Section 5.1.1, so no new drama, bestie 💅

The ReqEndpointCostMap object for a calendared ECM request looks like this 👀

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

object {
  [TypedEndpointAddr srcs<0..*>;]
  [TypedEndpointAddr dsts<0..*>;]
} EndpointFilter;

So cost-type is optional here, but that's only because it's paired with multi-cost-types to keep things compatible with [RFC8189] 🫶 In [RFC8189], both cost-type and multi-cost-types are optional too, but they follow the rule from Section 4.1.2 of [RFC8189] that says "the Client MUST specify either "cost-type" or "multi-cost-types" but MUST NOT specify both". No double-dipping allowed, periodt 🙅‍♀️

The calendared member works the same way as in the ReqFilteredCostMap object from Section 5.1.1 of this document. The other members work exactly like they do in the ReqEndpointCostMap object defined in [RFC7285] and [RFC8189]. And the TypedEndpointAddr type comes from Section 10.4.1 of [RFC7285] ✨

Now the big constraint moment 😤 For the reasons explained in Section 3.3, a Calendar-aware ALTO Server does not support constraints. So the [constraints] member is not in the ReqEndpointCostMap object at all, and constraints MUST NOT show up in the input parameters of a request for an Endpoint Cost Calendar. If it does show up anyway, the Server MUST ignore it. Not my problem, bestie 💀

5.2.2. Calendar Attributes in the Endpoint Cost Response

the meta field of a calendared Endpoint Cost response has to include at least one of these, depending on what the Client can handle 🌸

  • if the ALTO Client supports cost values for one cost type at a time only, then the meta fields from Section 11.5.1.6 of [RFC7285] for the Endpoint Cost response MUST be included:
    • cost-type field.
  • if the ALTO Client supports cost values for several cost types at a time, as specified in [RFC8189], then the meta fields from [RFC8189] for the Endpoint Cost response MUST be included:
    • cost-type field with value set to {}, for backwards compatibility with [RFC7285].
    • multi-cost-types field.

If the Client request doesn't provide calendared at all, or it provides it with a value equal to false for all the requested cost types, then the ALTO Server response is exactly what [RFC7285] and [RFC8189] describe. Boring but stable, which I respect 🧚

If the ALTO Client gives calendared a value equal to true for certain requested cost types, then the meta member of a calendared Endpoint Cost response MUST include an extra member called calendar-response-attributes for those cost types. Its contents follow the same rules as the Filtered Cost Map Service in Section 5.1.2. So the response changes a bit compared to [RFC7285] and [RFC8189] 🦋

  • the meta member gets one extra field, CalendarResponseAttributes, just like the Filtered Cost Map Service, and
  • the calendared costs come back as JSONArrays instead of the JSONNumbers that legacy ALTO implementations use. Every array has a number of values equal to number-of-intervals, and each value is the cost for that interval 📊

If calendared is equal to false for a given requested cost type, the ALTO Server MUST return a single cost value for that cost type, as specified in [RFC7285]. Simple and clean ✨

5.2.3. Use Case and Example: ECS with a routingcost Calendar

Picture this 🎬 An Application Client lives in an end system with limited resources, and its network access is either on-and-off or only decent during certain predictable windows. So it has to schedule both its resource-hungry networking stuff and its ALTO transactions. Main character planning energy, honestly 👑

The Application Client can trade content or resources with a bunch of endpoints, and it needs to figure out which one to connect to and when. The endpoints might be spread across different time zones or have spotty access, so timing matters a lot. In this example, 'routingcost' is time-varying, and its values come as ALTO Calendars 🌈

The ALTO Client attached to the Application Client asks for an ALTO Calendar on 'routingcost'. It gets back the Calendar that covers the 24-hour period "containing" the date and time of the request 🗓️

For cost type "num-routingcost", the ALTO Server has come up with 3 daily patterns, and each one is a Calendar covering the week from Monday, June 30th at 00:00 to Sunday, July 6th 23:59:

  • C1 for Monday, Tuesday, Wednesday, and Thursday (weekdays)
  • C2 for Saturday and Sunday (weekends)
  • C3 for Friday (maintenance outage on July 4, 2019 from 02:00:00 GMT to 04:00:00 GMT or a big holiday that is widely celebrated and generates a large number of connections).

In the example below, the ALTO Client sends its request on Tuesday, July 1st 2019 at 13:15 ⏰

The "routingcost" values are encoded in 3 digits 🔢

Here's the request 💌

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

{
  "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"
    ]
  }
}

And here's the response 🎀

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]
    }
  }
}

When the Client gets the Calendar for "routingcost", it checks that the calendar-start-time is Monday at 00h00 GMT and that repeated is equal to 4. That tells it the values stay valid until Thursday, so it only needs to grab a Calendar update on Friday 🗓️💖

5.2.4. Use Case and Example: ECS with a Multi-cost Calendar for routingcost and owdelay 🦋

Okay so in this example, the ALTO Server has multi-cost capabilities, as specified in [RFC8189] 💅. That means an ALTO Client can ask for values of several cost types in one single transaction and get them all back at once. Iconic, honestly. The use case is path selection based on 2 metrics: routingcost and owdelay ✨.

Same as the last example, the IRD says the ALTO Server gives "routingcost" Calendars in 24 time intervals of 1 hour (3600 seconds) each ⏰.

For the "owdelay" metric, the IRD says the ALTO Server gives Calendars in 12 time interval values lasting 5 minutes (300 seconds) each 🌈.

In the following example transaction, the ALTO Client sends its request on Tuesday, July 1st 2019 at 13:15 🎀.

This example assumes that the values of metric "owdelay" and "routingcost" are encoded in 3 digits 🔢.

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

{
  "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]]
    }
  }
}

When the Client gets the response, it spots that the Calendar values for metric "routingcost" are repeated for 4 iterations 🔁. So in its next requests, until the "routingcost" Calendar is expected to change, the Client only needs to ask for a Calendar for "owdelay". Smart, right? 🧠

Without the ALTO Calendar extensions, the ALTO Client would have no clue how dynamic the metric value changes are 😩. It would spend needless time requesting values at an inappropriate pace. Plus, without the Multi-Cost ALTO capabilities, the Client would repeat this waste of time, because it would need to send one request per cost metric 🙃.

6. IANA Considerations 🌸

This document has no IANA actions 🤷‍♀️.

7. Security Considerations 🔐

Okay, this part is super important, so pay attention bestie 🫶. As an extension of the base ALTO protocol [RFC7285], this document fits into the architecture of the base protocol. That means the security considerations (Section 15 of [RFC7285]) fully apply when an ALTO Server provides this extension 💜. For example, the same authenticity and integrity considerations (Section 15.1 of [RFC7285]) still fully apply, and so do the same considerations for the privacy of ALTO users (Section 15.4 of [RFC7285]) 🔒.

The calendaring info this extension provides needs extra thought on three security considerations discussed in [RFC7285] 😬: potential undesirable guidance to Clients (Section 15.2 of [RFC7285]), confidentiality of ALTO information (Section 15.3 of [RFC7285]), and availability of ALTO (Section 15.5 of [RFC7285]). The good news is that this extension might actually improve availability. For example, if the ALTO Server is unavailable but the related info is already in a Calendar, the Client can still use it in the future 🛟.

For confidentiality of ALTO information, an operator should know that this extension may bring in a new risk 🚨. A malicious ALTO Client may get information about future events that are scheduled through Calendaring. With that info, the malicious Client could generate massive connections to the network at times when the load is expected to be high. Yikes 💀.

To handle this risk, the operator should deal with the chance of ALTO information leaking to malicious Clients or third parties 🕵️‍♀️. As specified in "Protection Strategies" (Section 15.3.2 of [RFC7285]), the ALTO Server should authenticate ALTO Clients and use the Transport Layer Security (TLS) protocol, so that man-in-the-middle (MITM) attacks to intercept an ALTO Calendar are not possible. "Authentication and Encryption" (Section 8.3.5 of [RFC7285]) makes sure this solution stays available. It says that "ALTO Server implementations as well as ALTO Client implementations MUST support the "https" URI scheme of [RFC2818] and Transport Layer Security (TLS) of [RFC5246]" 🔐✨.

Section 1 of TLS 1.3 [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 support both TLS 1.3 [RFC8446] and TLS 1.2 [RFC5246], and they MAY support and use newer versions of TLS as long as the negotiation process succeeds 🤝.

The operator should know that the mechanisms above do not cover all security risks 🙈. In particular, they will not help in the case of "malicious Clients" that have valid authentication credentials. The threat here is that legitimate Clients have been subverted by an attacker and are now 'bots' being asked to join a DDoS attack 🤖. The Calendar info then becomes super valuable, because it tells the attacker exactly when to strike. A mechanism, like a monitoring system that detects abnormal behaviors, may still be needed 👀.

To avoid malicious or erroneous guidance from ALTO information, an ALTO Client should know that using calendaring info can come with risks: (1) Calendar values, especially in "repeated" Calendars, may be only statistical, and (2) future events may change 📉. So a more robust ALTO Client should adapt and extend the protection strategies specified in Section 15.2 of [RFC7285] 💪. For example, to be notified immediately when a particular ALTO value that the Client depends on changes, it is RECOMMENDED that both the ALTO Client and ALTO Server using this extension support "Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)" [RFC8895] 📣.

Another risk of erroneous guidance shows up when the Server exposes an occurrence of the same cost type name in different elements of the Calendar objects array associated with an information resource 🙀. In this case, there is no way for the Client to figure out which Calendar object in the array is valid. This document recommends that, in this case, 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 from potentially invalid Calendar values. To do this, as an alternative to the recommendation in this document, the Client MAY ignore the totality of occurrences of CalendarAttributes objects containing the cost type name, and query this cost type using [RFC7285] 🫧.

8. Operational Considerations ✨

okay bestie, both the network operator AND the app operator need to think about the feedback aspect and the prediction (uncertainty) aspect when they use the Cost Calendar 🫶

First, the feedback aspect. Think of the Cost Calendar like a traffic-aware map service (aka Google Maps 🗺️). If you use it without thinking about its own effect, a huge fleet can turn a road that wasn't congested into a congested one 😭 And when tons of individual cars all pick the road with light traffic (the "cheap link"), that can cause congestion too, or just a worse outcome overall. Braess' Paradox [BRAESS_PARADOX] is literally the receipts for this 💀

Next, the prediction aspect. Sending ALTO Cost Calendars usually means less data going over the wire than doing a bunch of single-cost ALTO transactions, which is so efficient 💅 An app using Calendars already has a set of time-dependent values, so it can plan its connections ahead of time without asking for info at every single moment. Also, the Calendar response attribute "repeated" (when it's included) saves even more back-and-forth, because it tells the ALTO Client it doesn't need to query Calendars during the period that attribute describes. BUT this whole glow-up only works if "accidents" don't happen 🙈 so keep that in mind!

Network operators and app operators can totally pick their own ways to handle all this, but this document recommends a few things 🌸 First, a super common move for reducing instability and handling uncertainty is keeping the info updated in a timely way. The SSE Service (see Section 7) can handle updates if both the Server and the Client support it. Second, when a network operator updates the Cost Calendar, and when an app reacts to that update, they should think about the feedback effects. Yes, there's theory [SELFISH_RTG_2002] and Internet-based evaluation [SELFISH_RTG_2003] showing that uncoordinated behavior doesn't always lead to a seriously suboptimal result, but this is still the best approach, so don't gamble on it 🎰

High-resolution intervals might be needed when values change, sometimes in really tiny time windows but in a big way ⚡ One way to avoid stuffing in way too many entries is to use the "repeated" feature 🧠 A Server can smartly set the Calendar start time and the number of intervals so they can be declared "repeated" for a large number of periods, until the Calendar values change and get sent out to the requesting Clients.

Also, the newer JSON Data Interchange Format spec [RFC8259], which ALTO Calendars use, replaces the older one [RFC7159] that the base ALTO protocol [RFC7285] used. The newer JSON requires UTF-8 text encoding so everything is more interoperable 🌈 So if your ALTO Client or Server implementation uses UTF-{16,32}, you need to be aware of the interoperability risks, and you MUST switch to UTF-8 if you want to talk to Calendar-aware Servers and Clients. No exceptions, bestie 🙅‍♀️

9. References 🎀

9.1. Normative References 💜

[IEEE.754.2019]
           IEEE, "IEEE Standard for Floating-Point Arithmetic",
           IEEE 754-2019, DOI 10.1109/IEEESTD.2019.8766229, June
           2019, <https://doi.org/10.1109/IEEESTD.2019.8766229>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
           (TLS) Protocol Version 1.2", RFC 5246,
           DOI 10.17487/RFC5246, August 2008,
           <https://www.rfc-editor.org/info/rfc5246>.

[RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
           Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
           DOI 10.17487/RFC7231, June 2014,
           <https://www.rfc-editor.org/info/rfc7231>.

[RFC7285]  Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
           Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
           "Application-Layer Traffic Optimization (ALTO) Protocol",
           RFC 7285, DOI 10.17487/RFC7285, September 2014,
           <https://www.rfc-editor.org/info/rfc7285>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8189]  Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost
           Application-Layer Traffic Optimization (ALTO)", RFC 8189,
           DOI 10.17487/RFC8189, October 2017,
           <https://www.rfc-editor.org/info/rfc8189>.

[RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
           Interchange Format", STD 90, RFC 8259,
           DOI 10.17487/RFC8259, December 2017,
           <https://www.rfc-editor.org/info/rfc8259>.

[RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
           Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
           <https://www.rfc-editor.org/info/rfc8446>.

[RFC8895]  Roome, W. and Y. Yang, "Application-Layer Traffic
           Optimization (ALTO) Incremental Updates Using Server-Sent
           Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November
           2020, <https://www.rfc-editor.org/info/rfc8895>.

9.2. Informative References 🦋

[ALTO_METRICS]
           Wu, Q., Yang, Y. R., Dhody, D., Randriamasy, S., and L. M.
           Contreras, "ALTO Performance Cost Metrics", Work in
           Progress, Internet-Draft, draft-ietf-alto-performance-
           metrics-09, 9 March 2020, <https://tools.ietf.org/html/
           draft-ietf-alto-performance-metrics-09>.

[BRAESS_PARADOX]
           Steinberg, R. and W. Zangwill, "The Prevalence of Braess'
           Paradox", Transportation Science Vol. 17, No. 3,
           DOI 10.1287/trsc.17.3.301, 1 August 1983,
           <https://doi.org/10.1287/trsc.17.3.301>.

[RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
           DOI 10.17487/RFC2818, May 2000,
           <https://www.rfc-editor.org/info/rfc2818>.

[RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
           Optimization (ALTO) Problem Statement", RFC 5693,
           DOI 10.17487/RFC5693, October 2009,
           <https://www.rfc-editor.org/info/rfc5693>.

[RFC6708]  Kiesel, S., Ed., Previdi, S., Stiemerling, M., Woundy, R.,
           and Y. Yang, "Application-Layer Traffic Optimization
           (ALTO) Requirements", RFC 6708, DOI 10.17487/RFC6708,
           September 2012, <https://www.rfc-editor.org/info/rfc6708>.

[RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
           Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
           2014, <https://www.rfc-editor.org/info/rfc7159>.

[SELFISH_RTG_2002]
           Roughgarden, T., "Selfish Routing", Dissertation Thesis,
           Cornell, May 2002.

[SELFISH_RTG_2003]
           Qiu, L., Yang, Y., Zhang, Y., and S. Shenker, "Selfish
           Routing in Internet-Like Environments", Proceedings of
           SIGCOMM '03, DOI 10.1145/863955.863974, August 2003,
           <https://doi.org/10.1145/863955.863974>.

[SENSE]    Department of Energy Office of Science Advanced Scientific
           Computing Research (ASCR) Program, "SDN for End-to-End
           Networked Science at the Exascale (SENSE)",
           <http://sense.es.net/overview>.

[UNICORN-FGCS]
           Xiang, Q., Wang, T., Zhang, J., Newman, H., Yang, Y., and
           Y. Liu, "Unicorn: Unified resource orchestration for
           multi-domain, geo-distributed data analytics", Future
           Generation Computer Systems (FGCS), Vol. 93, Pages
           188-197, DOI 10.1016/j.future.2018.09.048, ISSN 0167-739X,
           March 2019,
           <https://doi.org/10.1016/j.future.2018.09.048>.

Acknowledgments 🌷

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, Brian Weis, and Jensen Zhang gave substantial review feedback and suggestions to the protocol design, and they are absolutely iconic for it 👑

Authors' Addresses 📮

Sabine Randriamasy
Nokia Bell Labs
Route de Villejust
91460 Nozay
France

Email: Sabine.Randriamasy@nokia-bell-labs.com


Y. Richard Yang
Yale University
51 Prospect St.
New Haven, CT 06520
United States of America

Email: yry@cs.yale.edu


Qin Wu
Huawei
Yuhua District
101 Software Avenue
Nanjing
Jiangsu, 210012
China

Email: sunseawq@huawei.com


Lingli Deng
China Mobile
China

Email: denglingli@chinamobile.com


Nico Schwan
Thales Deutschland
Lorenzstrasse 10
70435 Stuttgart
Germany

Email: nico.schwan@thalesgroup.com
📦 where this page comes from