RFC 8189

Multi-Cost Application-Layer Traffic Optimization (ALTO)

📅 published October 2017, from ietf

Multi-Cost Application-Layer Traffic Optimization (ALTO) 💖

Okay bestie, here's the paperwork 📋✨ This is RFC 8189, and it's a Standards Track doc, so it's actually official 💅 It was written by S. Randriamasy and W. Roome (both at Nokia Bell Labs) and N. Schwan (at Thales Deutschland). It came out of the Internet Engineering Task Force (IETF) in October 2017 and has ISSN 2070-1721. Its title block doesn't list any RFCs it obsoletes or updates, so it's not replacing or changing anything else 🦋

Abstract

So ALTO is specified in RFC 7285, and its services hand back different metrics that describe the costs between network endpoints 🌸

This document adds a new service that lets an ALTO Client grab several cost metrics in one request, for an ALTO filtered cost map and an endpoint cost map. 🎀 It also upgrades the constraints so they can filter those maps even harder, by letting an ALTO Client combine tests on several cost metrics with logical operators.

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.

Info about the current status of this document, any errata, and how to give feedback on it lives at https://www.rfc-editor.org/info/rfc8189 🔥

Copyright (c) 2017 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, because 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 they are provided without warranty as described in the Simplified BSD License. 🫶

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
3.  Overview Of Approach  . . . . . . . . . . . . . . . . . . . .   6
  3.1.  Multi-Cost Data Format  . . . . . . . . . . . . . . . . .   6
  3.2.  Compatibility with Legacy ALTO Clients  . . . . . . . . .   7
  3.3.  Filtered Multi-Cost Map Resources . . . . . . . . . . . .   7
  3.4.  Endpoint Cost Service Resources . . . . . . . . . . . . .   8
  3.5.  Full Cost Map Resources . . . . . . . . . . . . . . . . .   8
  3.6.  Extended Constraint Tests . . . . . . . . . . . . . . . .   8
    3.6.1.  Extended Constraint Predicates  . . . . . . . . . . .   9
    3.6.2.  Extended Logical Combination of Predicates  . . . . .   9
    3.6.3.  Testable Cost Types in Constraints  . . . . . . . . .   9
    3.6.4.  Testable Cost Type Names in IRD Capabilities  . . . .  10
    3.6.5.  Legacy ALTO Client Issues . . . . . . . . . . . . . .  10
4.  Protocol Extensions for Multi-Cost ALTO Transactions  . . . .  12
  4.1.  Filtered Cost Map Extensions  . . . . . . . . . . . . . .  12
    4.1.1.  Capabilities  . . . . . . . . . . . . . . . . . . . .  13
    4.1.2.  Accept Input Parameters . . . . . . . . . . . . . . .  14
    4.1.3.  Response  . . . . . . . . . . . . . . . . . . . . . .  17
  4.2.  Endpoint Cost Service Extensions  . . . . . . . . . . . .  17
    4.2.1.  Capabilities  . . . . . . . . . . . . . . . . . . . .  17
    4.2.2.  Accept Input Parameters . . . . . . . . . . . . . . .  18
    4.2.3.  Response  . . . . . . . . . . . . . . . . . . . . . .  19
5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
  5.1.  Information Resource Directory  . . . . . . . . . . . . .  19
  5.2.  Multi-Cost Filtered Cost Map: Example #1  . . . . . . . .  21
  5.3.  Multi-Cost Filtered Cost Map: Example #2  . . . . . . . .  23
  5.4.  Multi-Cost Filtered Cost Map: Example #3  . . . . . . . .  24
  5.5.  Multi-Cost Filtered Cost Map: Example #4  . . . . . . . .  25
  5.6.  Endpoint Cost Service . . . . . . . . . . . . . . . . . .  26
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
7.  Privacy and Security Considerations . . . . . . . . . . . . .  28
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  28
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  28
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  29
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

1. Introduction ✨

IETF defined ALTO services in [RFC7285] to give guidance to overlay applications. Those apps have to pick one or several hosts from a set of candidates that can provide a resource they want 🧚 That guidance is based on things like the topological distance, which affects how well data moves between the hosts. ALTO exists to improve Quality of Experience (QoE) for the application while cutting down resource consumption in the underlying network infrastructure. The ALTO protocol shares a view of the Internet called a Network Map, which is made of provider-defined locations spanning from subnets to several Autonomous Systems (ASes). ALTO can also share the provider-determined costs between Network Map locations, or between groups of individual endpoints. 💅

Current ALTO cost types include things like "hopcount" and the administrative "routingcost", which reflect ISP routing preferences 🌈 Lately, new use cases have stretched ALTO's reach into Content Delivery Networks (CDNs), data centers, and applications that need extra info to pick their endpoints or network locations. So a whole bunch of new cost types that better match what these applications need are expected to be specified 😭

The ALTO protocol [RFC7285], which this document calls the base protocol, limits ALTO cost maps and Endpoint Cost Services to one cost type per ALTO request. 🙈 To get info for several cost types, an ALTO Client has to send several separate requests to the Server.

Here's the big glow-up 🦋 Getting everything in one query/response transaction is way more efficient in terms of Round-Trip Time (RTT), traffic, and processing load on both the ALTO Client and Server. One cost map reporting on N cost types is less bulky than N cost maps with one cost type each, which helps both storing and transmitting those maps. For lots of emerging apps that need info on several cost types, having them gathered in one map saves time too. Consistency is another win: getting values for several cost types in one batch is useful for ALTO Clients that need synchronized ALTO information updates. This document defines how to retrieve multiple cost metrics in a single request for ALTO filtered cost maps and endpoint cost maps. To keep things compatible with legacy ALTO Clients, only the Filtered Cost Map and Endpoint Cost Map Services are extended to return multi-cost values. 🎀

Along with multi-cost queries, the filtering also has to level up so it can put constraints on multiple metrics. The base protocol lets an ALTO Client give optional constraint tests for a Filtered Cost Map Service or the Endpoint Cost Service, but those tests are limited to the AND combination of comparison tests on the value of the (single) requested cost type. 😤 Meanwhile, apps that care about several metrics and deal with complicated network conditions may need to balance conflicting goals, like routing cost versus network performance. So this document extends the base protocol with constraints that can test multiple metrics and can be combined with logical 'ORs' as well as logical 'ANDs'. That means an app can make requests like: "select solutions with either (moderate "hopcount" AND high "routingcost") OR (higher "hopcount" AND moderate "routingcost")" 👑

Here's how this document is laid out 🍓 Section 2 defines the terminology used in it. Section 3 gives a non-normative overview of the multi-cost extensions, and Section 4 gives the formal definitions. Section 5 has several complete examples. The remaining sections cover IANA, privacy, and security considerations.

1.1. 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. 🌸

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.
  • 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. 🦋
  • Server: When used with a capital "S", this term refers to an ALTO Server.

3. Overview Of Approach 🗺️

This is a non-normative overview of the multi-cost ALTO extensions defined in this document. 💖 It assumes you already know your way around cost map resources in the ALTO protocol [RFC7285].

3.1. Multi-Cost Data Format

Formally, the cost entries in an ALTO cost map can be any type of JSON value [RFC7159] (see the DstCosts object in Section 11.2.3.6 of [RFC7285]). 🤓 However, that section also says that an implementation may assume costs are JSON numbers, unless the implementation is using an extension that signals a different data type.

So this document extends the definition of a cost map to allow a cost to be an array of costs, one per metric, instead of just one number. ✨ Here's an example cost map with the "routingcost" and "hopcount" metrics. It's identical to a regular ALTO cost map, except the values are arrays instead of numbers. The multiple metrics are listed in the member "multi-cost-types", which tells the Client how to map the values in the array to cost metrics. 💅

{
 "meta" : {
   "dependent-vtags" : [ ... ],
   "cost-type" : {},
   "multi-cost-types" : [
     {"cost-mode": "numerical", "cost-metric": "routingcost"},
     {"cost-mode": "numerical", "cost-metric": "hopcount"}
   ]
 }
 "cost-map" : {
   "PID1": { "PID1":[1,0],  "PID2":[5,23],  "PID3":[10,5] },
   ...
 }
}

Also notice the presence of the member "cost-type" : {}, which keeps things backwards compatible with [RFC7285] 🫶

Part 1 of 5 done 🎀 Part 2 picks up with Section 3.2 next, bestie!

3.2. Compatibility with Legacy ALTO Clients ✨

okay so this doc doesn't define any new media types 🙈 instead it glow-ups the ALTO Server's Information Resource Directory (IRD) so legacy Clients just won't request array-valued multi-cost map resources 💅 the whole trick works because ALTO Clients MUST ignore unknown fields (Section 8.3.7 of [RFC7285]) 🫶

3.3. Filtered Multi-Cost Map Resources 🦋

this doc extends the Filtered Cost Map Service so the same resource can return either a single-valued cost map (from [RFC7285]) or an array-valued multi-cost map (from this doc) 🌈 an extended Filtered Cost Map resource gets a new capability called "max-cost-types", and its value is the maximum number of cost types that resource can return for one request. if that capability shows up, it's basically the resource saying "yep, I speak multi-cost" 💜

here's a little IRD fragment that defines an extended Filtered Cost Map resource:

      "filtered-multicost-map" : {
        "uri" : "http://alto.example.com/multi/costmap/filtered",
        "media-type" : "application/alto-costmap+json",
        "accepts" : "application/alto-costmapfilter+json",
        "uses" : [ "my-default-network-map" ],
        "capabilities" : {
          "max-cost-types" : 2,
          "cost-type-names" : [ "num-routingcost",
                                "num-hopcount" ],
          ...
        }

a legacy ALTO Client just ignores "max-cost-types" 🙈 it sends a request with the input parameter "cost-type" to describe the metric it wants (as defined in [RFC7285]), and the ALTO Server hands back a single-valued legacy cost map. no drama, no cap.

BUT a multi-cost-aware ALTO Client will clock that this resource supports the multi-cost extensions 👀 and it can send a POST request with the new input parameter "multi-cost-types", whose value is an array of cost types. because the request has "multi-cost-types" (instead of the "cost-type" parameter from the base protocol), the Server realizes the Client gets the extensions in this doc too, so it responds with a multi-cost map where the costs come in the order listed in "multi-cost-types" ✨ iconic behavior honestly 🔥

3.4. Endpoint Cost Service Resources 🧚

okay so [RFC7285] says that "The Endpoint Cost Service allows an ALTO server to return costs directly amongst endpoints" 💅 whereas the Filtered Cost Map Service returns costs between Provider-defined Identifiers (PIDs) 🌸 this doc uses the technique from Section 3.3 to extend the Endpoint Cost Service too, so it can return array-valued costs to ALTO Clients who are also in on these extensions 💖

3.5. Full Cost Map Resources 🍓

[RFC7285] says a filtered cost map has to return the entire cost map if the ALTO Client leaves out the source and destination PIDs (Section 11.3.2.3 of [RFC7285]) 👑 so a multi-cost-aware ALTO Client can use an extended Filtered Cost Map resource to grab a full multi-cost map. galaxy brain 🧠✨

full cost map resources are GET-mode requests 🫧 the response for a full cost map with multiple cost types would include a "meta" field, and that would include a "cost-type" field listing several values, one for each cost type in the cost map. a legacy ALTO Client wouldn't be able to understand that list 😭 and it also couldn't interpret the cost values array you get from a full multi-cost map. rip legacy clients 🥲

3.6. Extended Constraint Tests 🎀

[RFC7285] defines a simple constraint test capability for the Filtered Cost Map and Endpoint Cost Services ✨ if a resource supports constraints, the Server limits the response to costs that satisfy a list of simple predicates the ALTO Client gives it. for example, if the ALTO Client sends these constraints:

        "constraints": ["ge 10", "le 20"]

then the Server only returns costs in the range [10,20] 🌈

to make constraint tests actually useful with multi-cost requests, a few extensions are needed 💅

3.6.1. Extended Constraint Predicates 💜

first up, a multi-cost request involves more than one cost metric, so the simple predicates have to be extended to say which metric they're testing 🔍 so the predicate syntax becomes [##] op value, where ## is the index of a cost metric in this multi-cost request.

3.6.2. Extended Logical Combination of Predicates 🦋

second, once there are multiple cost metrics in play, a plain "AND" of simple predicates is no longer enough 😤 Clients need to be able to express "OR" tests too 🙌 so we add a new field to the Client request called "or-constraints". its value is an array of arrays of simple predicates, and it represents the OR of ANDs of those predicates 💖

so the following request tells the Server to limit its response to cost points with "routingcost" <= 100 AND "hopcount" <= 2, OR else "routingcost" <= 10 AND "hopcount" <= 6 🫶

      {
        "multi-cost-types": [
            {"cost-metric": "routingcost", "cost-mode": "numerical"},
            {"cost-metric": "hopcount",    "cost-mode": "numerical"}
        ],
        "or-constraints": [
            ["[0] le 100", "[1] le 2"],
            ["[0] le 10",  "[1] le 6"]
        ],
        "pids": {...}
      }

note that a "constraints" parameter holding the array of predicates [P1, P2, ...] is the same as an "or-constraints" parameter with one array inside, like [[P1, P2, ...]]. so a Client is allowed to use "constraints" or "or-constraints", but not both 🚫

3.6.3. Testable Cost Types in Constraints 🌸

finally, a Client might want to test a cost type whose actual value it doesn't care about, as long as it passes the tests 👀 for example, a Client may want the value of the cost metric "routingcost" for all PID pairs that satisfy constraints on the metric "hopcount", without needing the actual value of "hopcount" ✨

to make that work, we add a specific parameter named "testable-cost-types", which does not contain the same cost types as the parameter "multi-cost-types" 🧚 the Client can only express constraints on cost types listed in "testable-cost-types" 💅

so the following request tells the Server to return just "routingcost" for those source and destination pairs where "hopcount" is <= 6 🍓

      {
        "multi-cost-types": [
            {"cost-metric": "routingcost", "cost-mode": "numerical"},
        ],
        "testable-cost-types": [
            {"cost-metric": "hopcount", "cost-mode": "numerical"},
        ],
        "constraints": ["[0] le 6"],
        "pids": {...}
      }

3.6.4. Testable Cost Type Names in IRD Capabilities 🌈

in [RFC7285], when a resource's "constraints" capability is true, the Server accepts constraints on every cost type listed in the "cost-type-names" capability 💅 but some ALTO Servers might not want to allow constraint tests on all of their cost metrics 🙈 so the multi-cost ALTO protocol extension defines a new capability field called "testable-cost-type-names". just like "cost-type-names", it's an array of cost type names 🫶 if it's present, that resource only allows constraint tests on the cost types in that list. and "testable-cost-type-names" must be a subset of "cost-type-names" 🔥

3.6.5. Legacy ALTO Client Issues 😭

a multi-cost-aware Client will recognize the "testable-cost-type-names" field and honor those restrictions ✨ a legacy Client won't, though 💀 so when "constraints" has the value 'true', a legacy Client might send a request with a constraint test on any of the cost types listed in "cost-type-names" 😬

to dodge that problem, the "testable-cost-type-names" and "cost-constraints" fields are mutually exclusive (a resource may define one or the other capability, but MUST NOT define both) 🚫 so a resource that doesn't allow constraint tests on all cost metrics will set "testable-cost-type-names" to the testable metrics, and will set "cost-constraints" to 'false' 🦋 a multi-cost-aware Client will recognize "testable-cost-type-names" and realize its existence means the resource does allow (limited) constraint tests, while a legacy Client will think that resource doesn't allow constraint tests at all 👀 if you want legacy Clients to be able to use constraint tests, the ALTO Server can define an additional resource with "cost-constraints" set to 'true' and "cost-type-names" set to the metrics that can be tested 💖

in the IRD example below, the resource "filtered-cost-map-extended" provides values for three metrics: "num-routingcost", "num-hopcount", and "num-bwscore" 🌸 its capability "testable-cost-type-names" says the Server only allows constraints on "routingcost" and "hopcount". a multi-cost-capable Client will see this and limit its constraint tests to those metrics ✨ and because the capability "cost-constraints" is false (by default), a legacy Client won't use constraint tests on this resource at all 🙈

the second resource, "filtered-multicost-map", is similar to the first, except all the metrics it returns are testable 🧚 so it sets "cost-constraints" to 'true' and doesn't set the "testable-cost-type-names" field 💅 a legacy Client that needs a constraint test will use this resource instead of the first one 🍓 and a multi-cost-aware Client that doesn't need to retrieve the "num-bwscore" metric can use either resource 🌈

note that if a multi-cost Server specifies a "filtered-cost-map-extended", it will most likely not specify a "filtered-multicost-map" if the capabilities of the latter are covered by the capabilities of the former, unless the "filtered-multicost-map" resource is also intended for legacy Clients 👑

   "filtered-cost-map-extended" : {
      "uri" : "http://alto.example.com/multi/extn/costmap/filtered",
      "media-type" : "application/alto-costmap+json",
      "accepts" : "application/alto-costmapfilter+json",
      "uses" : [ "my-default-network-map" ],
      "capabilities" : {
         "max-cost-types" : 3,
         "cost-type-names" : [ "num-routingcost",
                               "num-hopcount",
                               "num-bwscore"],
         "testable-cost-type-names" : [ "num-routingcost",
                                        "num-hopcount" ]
      }
   },

   "filtered-multicost-map" : {
      "uri" : "http://alto.example.com/multi/costmap/filtered",
      "media-type" : "application/alto-costmap+json",
      "accepts" : "application/alto-costmapfilter+json",
      "uses" : [ "my-default-network-map" ],
      "capabilities" : {
        "cost-constraints" : true,
        "max-cost-types" : 2,
        "cost-type-names" : [ "num-routingcost",
                              "num-hopcount"],
      }
   }

4. Protocol Extensions for Multi-Cost ALTO Transactions 🎀

okay this is the part where we get formal 🤓 this section specifies the extensions to [RFC7285] that support multi-cost ALTO transactions 💜

this doc uses the notation rules from Section 8.2 of [RFC7285] 📝 in particular, an optional field is enclosed in [ ]. in the definitions, the JSON names of the fields are case sensitive 🔠 an array is shown by two numbers in angle brackets, <m..n>, where m is the minimal number of values and n is the maximum 🌸 and when this document uses * for n, it means there's no upper bound ♾️

4.1. Filtered Cost Map Extensions 🎀

okay so this doc is about to level up Filtered Cost Maps (the ones from Section 11.3.2 of [RFC7285]) 💅 we're adding new input parameters and capabilities, and the cost values come back as JSONArrays instead of plain JSONNumbers. iconic, honestly 🦋

The media type, HTTP method, and "uses" specs (Sections 11.3.2.1, 11.3.2.2, and 11.3.2.5 of [RFC7285], respectively) stay exactly the same, so nothing new to learn there ✨

4.1.1. Capabilities

okay the filtered cost map capabilities get two new members 🌸

  • max-cost-types
  • testable-cost-type-names

so max-cost-types tells you whether this resource understands the multi-cost stuff, and testable-cost-type-names lets the resource limit constraint tests to just some of the cost types 🧚 with these two extra members, the FilteredCostMapCapabilities object from Section 11.3.2.4 of [RFC7285] looks like this:

object {
   JSONString cost-type-names<1..*>;
   [JSONBool cost-constraints;]
   [JSONNumber max-cost-types;]
   [JSONString testable-cost-type-names<1..*>;]
} FilteredCostMapCapabilities;
  • cost-type-names: same as Section 11.3.2.4 of [RFC7285], no changes 🍓
  • cost-constraints: also same as Section 11.3.2.4 of [RFC7285]. so if cost-constraints is true, the resource MUST accept constraint tests on any cost type in cost-type-names. bestie, also note that when cost-constraints is true, the testable-cost-type-names capability MUST NOT be present 😭
  • max-cost-types: if it's there with a value N greater than 0, the resource gets the multi-cost extensions in this doc and can return a multi-cost map with any combo of N or fewer cost types from cost-type-names. if it's omitted, the default is 0 💜
  • testable-cost-type-names: if it's present, constraint tests are allowed, but only on the names in this array. each name in testable-cost-type-names MUST also be in cost-type-names. and if testable-cost-type-names is present, the cost-constraints capability MUST NOT be true 👑

this capability is useful when a Server can't or won't do constraint tests on every cost type (see Section 3.6.4) ✨ and testable-cost-type-names and cost-constraints are mutually exclusive, so legacy Clients can't sneak in constraint tests on cost types that can't be tested (see Section 3.6.5). not me being protective of the legacy clients 🙈

4.1.2. Accept Input Parameters

the ReqFilteredCostMap object from Section 11.3.2.3 of [RFC7285] gets glow-ups too 🌈

object {
   [CostType cost-type;]
   [CostType multi-cost-types<1..*>;]
   [CostType testable-cost-types<1..*>;]
   [JSONString constraints<0..*>;]
   [JSONString or-constraints<1..*><1..*>;]
   [PIDFilter pids];
} ReqFilteredCostMap;
  • cost-type: same as Section 11.3.2.3 of [RFC7285], but with one extra rule: the Client MUST specify either cost-type or multi-cost-types, but MUST NOT specify both. so this field is optional now. when a Client does a single cost request like in [RFC7285], it MUST use cost-type 💖
  • multi-cost-types: if it's there, the ALTO Server MUST return array-valued costs for the cost types in this list. for each entry, the cost-metric and cost-mode fields MUST match one of the supported cost types listed in cost-type-names in this resource's capabilities field (Section 4.1.1). the Client MUST NOT use this field unless this resource's max-cost-types capability exists and is greater than 0. this field MUST NOT have more than max-cost-types cost types. and yep, the Client MUST specify either cost-type or multi-cost-types but MUST NOT specify both 🔥

note that if multi-cost-types has just one cost type, the values in the cost map will be arrays with one value. 🧚

  • testable-cost-types: a list of cost types for extended constraint tests (the constraints and or-constraints params). these must either be a subset of testable-cost-type-names from the capabilities (Section 4.1.1), or, if the resource's cost-constraints capability is true, a subset of cost-type-names.

if testable-cost-types is omitted, it's assumed to have the cost types in multi-cost-types or cost-type.

this is super useful when a Client wants to test a cost type whose actual value doesn't matter, as long as it passes the tests. like, a Client might want the cost metric routingcost only for PID pairs whose hopcount is less than 10. the exact hop count doesn't matter 🦋

  • constraints: if this resource's max-cost-types capability (Section 4.1.1) is 0 (or isn't defined), this parameter works like Section 11.3.2.3 of [RFC7285]: an array of constraint tests joined by a logical AND. in this case, it MUST NOT be specified unless the resource's cost-constraints capability is true.

if this resource's max-cost-types capability is greater than 0, then this param is an array of extended constraint predicates (defined below) joined by a logical AND. in this case, it MAY be specified if the resource allows constraint tests (its cost-constraints capability is true, or its testable-cost-type-names capability isn't empty).

this parameter MUST NOT be specified if the or-constraints parameter is specified. 💀

an extended constraint predicate is two or three things separated by white space: (1) an optional cost type index like [#] (default [0]), (2) a required operator, and (3) a required target value. the operator and target value work like Section 11.3.2.3 of [RFC7285]. the cost type index, i, picks the cost type to test. if the testable-cost-types param is present, the test applies to the i'th cost type in testable-cost-types, starting at index 0. otherwise, if multi-cost-types is present, the test applies to the i'th cost type in that array. if neither is present, the test applies to the cost type in the cost-type param, and in that case the index MUST be 0. no matter how the tested cost type gets picked, it MUST be in the resource's testable-cost-type-names capability or, if that's not there, in cost-type-names 🫶

for example, say multi-cost-types has the single element routingcost, testable-cost-types has the single element hopcount, and constraints has the single element [0] le 5. that's the same as the database query "SELECT and provide routingcost WHERE hopcount <= 5" 🌸

the index is optional, so a constraint test from Section 11.3.2.3 of [RFC7285], like le 10, is the same as [0] le 10. so legacy constraint tests are also legal extended constraint tests ✨

also, a constraints param with an array of extended predicates [P1, P2, ...] is the same as an or-constraints param (defined below) with the value [[P1, P2, ...]] 🧠

  • or-constraints: a JSONArray of JSONArrays of JSONStrings, where each string is an extended constraint predicate. the "or-constraint" tests are read as the logical OR of ANDs of predicates. so the ALTO Server should return a cost point only if it satisfies all the constraints in any one of the sub-arrays. 👑

this parameter MAY be specified if this resource's max-cost-types capability is defined with a value greater than 0 (Section 4.1.1) and the resource allows constraint tests (its cost-constraints capability is true, or its testable-cost-type-names capability isn't empty). otherwise, this parameter MUST NOT be specified.

this parameter MUST NOT be specified if the constraints parameter is specified.

this parameter MUST NOT contain any empty array of AND predicates. an empty array would be the same as a constraint that's always true, and an OR combo including that would always be true too, so it'd be useless 🙄

for example, say multi-cost-types has the two elements routingcost and bandwidthscore, testable-cost-types has the two elements routingcost and hopcount, and or-constraints has the two elements ["[0] le 100", "[1] le 2"] and ["[0] le 10", "[1] le 6"]. that's the same as saying: "SELECT and provide routingcost and bandwidthscore WHERE ("routingcost" <= 100 AND "hopcount" <= 2) OR ("routingcost" <= 10 AND "hopcount" <= 6)" 🦋

note that if max-cost-types has a value greater than 0, a Client MAY use the or-constraints parameter together with the cost-type parameter. so if the Client and Server both know about the extensions in this doc, a Client MAY use an "OR" test for a single-valued cost request. galaxy brain moment ✨

  • pids: same as Section 11.3.2.3 of [RFC7285] 🍓

4.1.3. Response

if the Client sends the cost-type input param, the response is exactly what Section 11.2.3.6 of [RFC7285] describes 💅 but if the Client gives multi-cost-types instead, the response changes like this:

  • in meta, the cost-type field gets ignored by the receiver and set to {}. instead, a multi-cost-types field gets added with the same value as the multi-cost-types input param.
  • the costs are JSONArrays instead of JSONNumbers. all the arrays have the same cardinality as the multi-cost-types input param, and they hold the cost type values in that same order. if a cost type isn't available for a particular source and destination, the ALTO Server MUST use the JSON null value for that array element. if none of the cost types are available for a source and destination, the ALTO Server MAY omit that entry for that pair 🧚

4.2. Endpoint Cost Service Extensions 🌈

the Endpoint Cost Service (Section 11.5.1 of [RFC7285]) is getting the same kind of upgrade 💖 new input params and capabilities, and JSONArrays instead of JSONNumbers for the cost values.

the media type, HTTP method, and "uses" specs (Sections 11.5.1.1, 11.5.1.2, and 11.5.1.5 of [RFC7285], respectively) are unchanged, so we're chillin 🫶

4.2.1. Capabilities

the Endpoint Cost Service capability extensions are exactly the same as the Filtered Cost Map ones (see Section 4.1.1) 👑 no need to learn it twice, bestie ✨

4.2.2. Accept Input Parameters ✨

okay so the ReqEndpointCostMap object from Section 11.5.1.3 of [RFC7285] is getting a full glow-up 💅 here's the new look:

object {
   [CostType cost-type;]
   [CostType multi-cost-types<1..*>;]
   [CostType testable-cost-types<1..*>;]
   [JSONString constraints<0..*>;]
   [JSONString or-constraints<1..*><1..*>;]
   EndpointFilter endpoints;
} ReqEndpointCostMap;
  • cost-type: same as Section 11.5.1.3 of [RFC7285], but with one extra rule 🫶 the Client MUST specify either "cost-type" or "multi-cost-types" but MUST NOT specify both. pick one, bestie!
  • multi-cost-types: if it's there, the ALTO Server MUST return array-valued costs for the cost types in this list ✨ for each entry, the "cost-metric" and "cost-mode" fields MUST match one of the supported cost types listed in this resource's "capabilities" field (Section 4.2.1). the Client MUST NOT use this field unless this resource's "max-cost-types" capability exists and has a value greater than 0 🙈 this field MUST NOT have more than "max-cost-types" cost types. and yep, the Client MUST specify either "cost-type" or "multi-cost-types" but MUST NOT specify both, same rule as above 💀

Heads up, this one's a little plot twist 🌸 if "multi-cost-types" has only one cost type, the values in the cost map are still arrays, just with one value each.

  • testable-cost-types, constraints, or-constraints: defined the same way as the matching input parameters for an extended filtered cost map (Section 4.1.2) 🦋
  • endpoints: as defined in Section 11.5.1.3 of [RFC7285] 💜

4.2.3. Response 🎀

the Endpoint Cost Service response is basically the cousin of the Filtered Cost Map response (Section 4.1.3), so the extensions look pretty similar 🧚 if the Client sends "cost-type", the response is exactly what Section 11.5.1.6 of [RFC7285] says, no changes. but if the Client sends "multi-cost-types" instead, here's what changes:

  • In "meta", the value of field "cost-type" will be ignored by the receiver and set to {}. Instead, the field "multi-cost-types" is added, with the same value as the "multi-cost-types" input parameter.
  • The costs are JSONArrays instead of JSONNumbers. All arrays have the same cardinality as the "multi-cost-types" input parameter and contain the cost type values in that order. If a cost type is not available for a particular source and destination, the ALTO Server MUST use the JSON "null" value for that array element. If none of the cost types are available for a particular source and destination, the ALTO Server MAY omit the entry for that source and destination 🌈

5. Examples ✨

this part shows off multi-cost ALTO transactions 💖 it uses cost metrics, on top of the mandatory legacy "routingcost", that are deliberately irrelevant and not registered with IANA 🙈

5.1. Information Resource Directory 🗂️

this is an ALTO Server's Information Resource Directory. Besides the network and cost map resources, it defines two Filtered Cost Maps and an Endpoint Cost Service, and they all understand the multi-cost extensions 🌈

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


HTTP/1.1 200 OK
Content-Length: 2704
Content-Type: application/alto-directory+json
{
  "meta" : {
    "default-alto-network-map" : "my-default-network-map",
    "cost-types" : {
      "num-routing" : {
        "cost-mode" : "numerical",
        "cost-metric" : "routingcost"
      },
      "num-shoesize" : {
        "cost-mode" : "numerical",
        "cost-metric" : "shoesize"
      },
      "num-scenery" : {
        "cost-mode" : "numerical",
        "cost-metric" : "sceneryrate"
      }
    }
  },
  "resources" : {
    "my-default-network-map" : {
      "uri" : "http://alto.example.com/networkmap",
      "media-type" : "application/alto-networkmap+json"
    },
    "numerical-routing-cost-map" : {
      "uri" : "http://alto.example.com/costmap/num-routing",
      "media-type" : "application/alto-costmap+json",
      "uses" : [ "my-default-network-map" ],
      "capabilities" : {
        "cost-type-names" : [ "num-routing" ]
      }
    },
    "numerical-shoesize-cost-map" : {
      "uri" : "http://alto.example.com/costmap/num-shoesize",
      "media-type" : "application/alto-costmap+json",
      "uses" : [ "my-default-network-map" ],
      "capabilities" : {
        "cost-type-names" : [ "num-shoesize" ]
      }
    },
    "filtered-multicost-map" : {
      "uri" : "http://alto.example.com/multi/costmap/filtered",
      "media-type" : "application/alto-costmap+json",
      "accepts" : "application/alto-costmapfilter+json",
      "uses" : [ "my-default-network-map" ],
      "capabilities" : {
        "cost-constraints" : true,
        "max-cost-types" : 2,
        "cost-type-names" : [ "num-routingcost",

                              "num-shoesize" ]
      }
    },
    "filtered-cost-map-extended" : {
      "uri" : "http://alto.example.com/multi/extn/costmap/filtered",
      "media-type" : "application/alto-costmap+json",
      "accepts" : "application/alto-costmapfilter+json",
      "uses" : [ "my-default-network-map" ],
      "capabilities" : {
        "max-cost-types" : 3,
        "cost-type-names" : [ "num-routingcost",
                              "num-shoesize",
                              "num-scenery"],
        "testable-cost-type-names" : [ "num-routingcost",
                                       "num-shoesize" ]
      }
    },
    "endpoint-multicost-map" : {
      "uri" : "http://alto.example.com/multi/endpointcost/lookup",
      "media-type" : "application/alto-endpointcost+json",
      "accepts" : "application/alto-endpointcostparams+json",
      "uses" : [ "my-default-network-map" ],
      "capabilities" : {
        "cost-constraints" : true,
        "max-cost-types" : 2,
        "cost-type-names" : [ "num-routingcost",
                              "num-shoesize" ]
      }
    }
  }
}

5.2. Multi-Cost Filtered Cost Map: Example #1

this is a simple multi-cost ALTO transaction 🍓 the ALTO Server provides two cost types, "routingcost" and "shoesize", both in "numerical" mode. The Client wants the entire multi-cost map. The Server doesn't know the value of "routingcost" between PID2 and PID3, so it hence returns the value 'null' for "routingcost" between PID2 and PID3 💀

POST /multi/costmap/filtered" HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json
Content-Type: application/alto-costmapfilter+json
Content-Length: 206

{
  "multi-cost-types": [
    {"cost-mode": "numerical", "cost-metric": "routingcost"},
    {"cost-mode": "numerical", "cost-metric": "shoesize"}
  ],
  "pids" : {
    "srcs" : [ ],
    "dsts" : [ ]
  }
}


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

{
 "meta" : {
   "dependent-vtags" : [
     {"resource-id": "my-default-network-map",
      "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
     }
   ],
   "cost-type" : {},
   "multi-cost-types" : [
     {"cost-mode": "numerical", "cost-metric": "routingcost"},
     {"cost-mode": "numerical", "cost-metric": "shoesize"}
   ]
 }
 "cost-map" : {
   "PID1": { "PID1":[1,0],   "PID2":[4,3],    "PID3":[10,2]   },
   "PID2": { "PID1":[15,5],  "PID2":[1,0],    "PID3":[null,9] },
   "PID3": { "PID1":[20,12], "PID2":[null,1], "PID3":[1,0]    }
 }
}

5.3. Multi-Cost Filtered Cost Map: Example #2

this one uses constraints to restrict the returned source/destination PID pairs to those with "routingcost" between 5 and 10, or "shoesize" equal to 0 🎯

POST /multi/costmap/filtered HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json
Content-Type: application/alto-costmapfilter+json
Content-Length: 333

{
  "multi-cost-types" : [
    {"cost-mode": "numerical", "cost-metric": "routingcost"},
    {"cost-mode": "numerical", "cost-metric": "shoesize"}
  ],
  "or-constraints" : [ ["[0] ge 5", "[0] le 10"],
                       ["[1] eq 0"] ]
  "pids" : {
    "srcs" : [ "PID1", "PID2" ],
    "dsts" : [ "PID1", "PID2", "PID3" ]
  }
}


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

{
  "meta" : {
    "dependent-vtags" : [
      {"resource-id": "my-default-network-map",
       "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
      }
    ],
    "cost-type" : {},
    "multi-cost-types" : [
      {"cost-mode": "numerical", "cost-metric": "routingcost"},
      {"cost-mode": "numerical", "cost-metric": "shoesize"}
    ]
  }
  "cost-map" : {
    "PID1": { "PID1": [1,0], "PID3": [10,5] },
    "PID2": { "PID2": [1,0]                 }
  }
}

5.4. Multi-Cost Filtered Cost Map: Example #3

this example uses extended constraints to limit the response to cost points with ("routingcost" <= 10 AND "shoesize" <= 2), OR else ("routingcost" <= 3 AND "shoesize" <= 6). Unlike the previous example, the Client is only interested in the "routingcost" cost type, and uses the "cost-type" parameter instead of "multi-cost-types" to tell the Server to return scalar costs instead of array costs 🧚

In this example, "[0]" means the constraint applies to "routingcost" because that is the first cost type in the "testable-cost-types" parameter. (If "testable-cost-types" is omitted, it is assumed to be the same as "multi-cost-types".) The choice of using an index to refer to cost types aims at minimizing the length of the expression of constraints, especially for those combining several OR and AND expressions. It was also the shortest path from the constraints design in [RFC7285] 💅

POST /multi/multicostmap/filtered HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json
Content-Type: application/alto-costmapfilter+json
Content-Length: 390

{
  "cost-type" : {
    "cost-mode": "numerical", "cost-metric": "routingcost"
  },
  "testable-cost-types" : [
    {"cost-mode": "numerical", "cost-metric": "routingcost"},
    {"cost-mode": "numerical", "cost-metric": "shoesize"}
  ],
  "or-constraints": [
         ["[0] le 10", "[1] le 2"],
         ["[0] le 3",  "[1] le 6"]
  ],
  "pids" : {
    "srcs" : [ ],
    "dsts" : [ ]
  }
}
HTTP/1.1 200 OK
Content-Type: application/alto-costmap+json
Content-Length: 368

{
  "meta" : {
    "dependent-vtags" : [
      {"resource-id": "my-default-network-map",
       "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
      }
    ],
    "cost-type" : {
      "cost-mode": "numerical", "cost-metric": "routingcost"
    }
  }
  "cost-map" : {
    "PID1": { "PID1": 1, "PID3": 10 },
    "PID2": { "PID2": 1 },
    "PID3": { "PID3": 1 }
  }
}

5.5. Multi-Cost Filtered Cost Map: Example #4

okay so this one is giving extended constraints 💅 It limits the response to cost points where ("routingcost" <= 10 AND "shoesize" <= 2), OR else ("routingcost" <= 3 AND "shoesize" <= 6). The Client only cares about "routingcost" and "sceneryrate" here, and doesn't want the "shoesize" metric back 🎀

POST /multi/extn/costmap/filtered HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json
Content-Type: application/alto-costmapfilter+json
Content-Length: 461

{
  "multi-cost-types" : [
    {"cost-mode": "numerical", "cost-metric": "routingcost"},
    {"cost-mode": "numerical", "cost-metric": "sceneryrate"}
  ],
  "testable-cost-types" : [
    {"cost-mode": "numerical", "cost-metric": "routingcost"},
    {"cost-mode": "numerical", "cost-metric": "shoesize"}
  ],
  "or-constraints": [
         ["[0] le 10", "[1] le 2"],
         ["[0] le 3",  "[1] le 6"]
  ],
  "pids" : {
    "srcs" : [ ],
    "dsts" : [ ]
  }
}
HTTP/1.1 200 OK
Content-Type: application/alto-costmap+json
Content-Length: 481

{
  "meta" : {
    "dependent-vtags" : [
      {"resource-id": "my-default-network-map",
       "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
      }
    ],
    "cost-type" : {},
    "multi-cost-types" : [
      {"cost-mode": "numerical", "cost-metric": "routingcost"},
      {"cost-mode": "numerical", "cost-metric": "sceneryrate"}
    ]
  }
  "cost-map" : {
    "PID1": { "PID1": [1,16] "PID3": [10,19] },
    "PID2": { "PID2": [1,8] },
    "PID3": { "PID3": [1,19] }
  }
}

5.6. Endpoint Cost Service

this one uses the Endpoint Cost Service to grab the "routingcost" and "shoesize" for selected endpoints 🦋 The response gets filtered to costs with either low "shoesize" and reasonable "routingcost" ("shoesize" <= 2 AND "routingcost" <= 10), OR else low "routingcost" and reasonable "shoesize" ("routingcost" <= 3 AND "shoesize" <= 6). it's giving main character energy ✨

POST /multi/endpointcost/lookup HTTP/1.1
Host: alto.example.com
Accept: application/alto-endpointcost+json,
        application/alto-error+json

Content-Type: application/alto-endpoincostparams+json
Content-Length: 455

{
  "multi-cost-types" : [
    {"cost-mode": "numerical", "cost-metric": "routingcost"},
    {"cost-mode": "numerical", "cost-metric": "shoesize"}
  ],
  "or-constraints": [
         ["[0] le 10", "[1] le 2"],
         ["[0] le 3",  "[1] le 6"]
  ],
  "endpoints" : {
    "srcs": [ "ipv4:192.0.2.2", "ipv6:2001:db8::1:0 ],
    "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: 419
Content-Type: application/alto-endpointcost+json

{
  "meta" : {
    "multi-cost-types" : [
      {"cost-mode": "numerical", "cost-metric": "routingcost"},
      {"cost-mode": "numerical", "cost-metric": "shoesize"}
    ]
  }
  "endpoint-cost-map" : {
    "ipv4:192.0.2.2": {
      "ipv4:192.0.2.89":    [15, 5],
      "ipv4:203.0.113.45":  [4, 23]
    }
    "ipv6:2001:db8::1:0": {
      "ipv4:198.51.100.34": [16, 5],
      "ipv6:2001:db8::10":  [10, 2]
    }
  }
}

6. IANA Considerations 🌸

this doc doesn't define any new media types or bring in any new IANA considerations, so there's nothing new to register here 🧚

7. Privacy and Security Considerations 💀

okay, serious moment 🫶 This document doesn't introduce any privacy or security issues that aren't already in the ALTO protocol. Bestie, the multi-cost thing actually tends to reduce the amount of data going over the wire compared to making a bunch of single-cost ALTO requests, which is lowkey iconic ✨ The risk from massive multi-cost requests is also kept in check, because multi-cost constraints filter the ALTO Server's responses, so those responses end up smaller too.

BUT, and this is important 😭 queries for multiple metrics are a stronger fingerprinting signal than queries for a single metric. So implementations of this protocol may leak more information about the ALTO Client than they would with a series of individual queries. Though, ngl, in many cases it'd already be possible to link those queries using the source IP address or other existing information 🙈

8. References

8.1. Normative References

8.2. Informative References

Acknowledgements 🙏

the authors wanted to thank Richard Alimi, Fred Baker, Dhruv Dhodi, Vijay Gurbani, Dave Mac Dysan, Young Lee, and Richard Yang for the fruitful discussions and feedback on this document and the earlier draft versions 💖 Gao Kai, Hans Seidel, Richard Yang, Qiao Xiang, and Wang Xin also gave substantial review feedback and suggestions on the protocol design. legends, all of them 👑

Authors' Addresses 💜

Sabine Randriamasy

Nokia Bell Labs
Route de Villejust
Nozay  91460
France

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

Wendy Roome

Nokia Bell Labs
124 Burlington Rd
Murray Hill, NJ  07974
United States of America

Email: ietf@wdroome.com

Nico Schwan

Thales Deutschland
Lorenzstrasse 10
Stuttgart  70435
Germany

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