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 RFC 7285. 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.

• 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 and
• 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.

• attributes to describe the time scope of the Calendar value array:
  • "time-interval-size": the applicable time interval size for each Calendar value, defined in seconds, that can cover a wide range of values.
  • "number-of-intervals": the number of intervals provided in the Calendar.
• "calendar-start-time": specifying when the Calendar starts; that is, to which date the first value of the Cost Calendar is applicable.
• "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.

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

• it does not introduce a new mode,
• it does not introduce new media types, and
• 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.

• the Filtered Cost Map and
• the Endpoint Cost Map.

• Constraints on an array of values may be various. For instance, some Clients may refuse Calendars with one single value violating a constraint, whereas other ones may tolerate Calendars with values violating constraints, for example, at given times. Therefore, expressing constraints in a way that covers all possible Client preferences is challenging.
• If constraints were to be supported, the processing overhead would be substantial for the Server as it would have to parse all the values of the Calendar array before returning a response.

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

"cost-type-names":

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.

"time-interval-size":

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 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 [RFC 7285] on the use of 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 indicates the number of values of the Cost Calendar array.

• 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 obtain it.
• 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 Section 4.3, the information resource "filtered-cost-map-calendar" provides a Calendar for cost type names "num-routingcost", "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.
• 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" equal to 5 minutes. If "number-of-intervals" has the value 12, then the duration of the provided Calendar is 1 hour.

"num-routingcost":

Refers to metric "routingcost" in the numerical mode, as defined in [RFC 7285] and registered with IANA.

"num-owdelay":

Refers to fictitious performance metric "owdelay" in the "numerical" mode to reflect 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 to reflect the provider preference in terms of end-to-end throughput.

"string-servicestatus":

Refers to fictitious metric "servicestatus" containing a string to reflect the availability, defined by the provider, of, for instance, path connectivity.

"https://custom.alto.example.com/calendar/costmap/filtered":

A Filtered Cost Map in which Calendar capabilities are indicated for cost type names "num-routingcost", "num-throughputrating", and "string-servicestatus" and

"https://custom.alto.example.com/calendar/endpointcost/lookup":

An Endpoint Cost Map in which Calendar capabilities are indicated for cost type names "num-routingcost", "num-owdelay", "num-throughputrating", and "string-servicestatus".

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

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

• the Calendar for "num-routingcost" is an array of 24 values, each provided on a time interval lasting 3600 seconds (1 hour),
• the Calendar for "num-owdelay" is an array of 12 values, each provided on a time interval lasting 300 seconds (5 minutes),
• the Calendar for "num-throughputrating" is an array of 60 values, each provided on a time interval lasting 60 seconds (1 minute), and
• the Calendar for "string-servicestatus" is an array of 30 values, each provided on a time interval lasting 120 seconds (2 minutes).

• some are not specific to Calendars and ensure compatibility with [RFC 7285] and [RFC 8189] and
• some are specific to Calendars.

• if the ALTO Client requests cost values for one cost type at a time, only the "meta" fields specified in [RFC 7285] for these information service responses:
  • "dependent-vtags" and
  • "cost-type" field.
• if the ALTO Client implements the Multi-Cost ALTO extension specified in [RFC 8189] and requests cost values for several cost types at a time, the "meta" fields specified in [RFC 8189] for these information service responses:
  • "dependent-vtags",
  • "cost-type" field with value set to '{}', for backwards compatibility with [RFC 7285], and
  • "multi-cost-types" field.

• member "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 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, and
• 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 in the "calendar-attributes" array member of the IRD resource entry, 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.

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 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 be present when Cost Calendars are provided for more than one cost type.

"calendar-start-time":

Indicates the date at which 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 specified in Section 7.1.1.1 of RFC 7231. The value provided for attribute "calendar-start-time" SHOULD NOT be later than the request date.

"time-interval-size":

As specified in Section 4.1 and with the same value as in the abovementioned corresponding "CalendarAttributes" object.

"number-of-intervals":

As specified in Section 4.1 and with the same value as in the abovementioned corresponding "CalendarAttributes" object.

"repeated":

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.

• if the ALTO Client supports cost values for one cost type at a time only, the "meta" fields specified in Section 11.5.1.6 of RFC 7285 for the Endpoint Cost response:
  • "cost-type" field.
• if the ALTO Client supports cost values for several cost types at a time, as specified in [RFC 8189], the "meta" fields specified in [RFC 8189] for the Endpoint Cost response:
  • "cost-type" field with value set to '{}', for backwards compatibility with [RFC 7285].
  • "multi-cost-types" field.

• the "meta" member has one additional field "CalendarResponseAttributes", as specified for the Filtered Cost Map Service, and
• 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.

• 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).

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

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

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

S. Bradner, "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]

T. Dierks, 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]

R. Fielding, and J. Reschke, "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]

R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. Roome, S. Shalunov, 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]

B. Leiba, "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]

S. Randriamasy, W. Roome, 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]

T. Bray, "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]

E. Rescorla, "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]

W Roome, 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>.

[ALTO_METRICS]

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

[BRAESS_PARADOX]

R. Steinberg, and W. Zangwill, "The Prevalence of Braess' Paradox", DOI 10.1287/trsc.17.3.301, August 1983,
<https://doi.org/10.1287/trsc.17.3.301>.

[RFC2818]

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

[RFC5693]

J. Seedorf, 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]

S. Kiesel, S. Previdi, M. Stiemerling, R. Woundy, 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]

T. Bray, "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]

T. Roughgarden, "Selfish Routing", May 2002.

[SELFISH_RTG_2003]

L. Qiu, Y. Yang, Y. Zhang, and S. Shenker, "Selfish Routing in Internet-Like Environments", 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]

Q. Xiang, T. Wang, J. Zhang, H. Newman, Y. Yang, and Y. Liu, "Unicorn: Unified resource orchestration for multi-domain, geo-distributed data analytics", DOI 10.1016/j.future.2018.09.048, ISSN 0167-739X, March 2019,
<https://doi.org/10.1016/j.future.2018.09.048>.

Sabine Randriamasy

Y. Richard Yang

Qin Wu

Lingli Deng

Nico Schwan