To return to this issue, I suggest we unify them, so that we have Cost
Types -- period. The "Mode" becomes a property of the Cost Type. So if a
server provides numerical & ordinal routingcosts, it provides *two*
separate Cost Types, say "routingcost" and "routingcost-ord".
I believe the result will simplify both clients and servers, and make it
easier for servers to introduce additional cost types.
My suggestion is to extend the Information Resource Directory with a list
of definitions for each Cost Type the server supports. Each Cost Type
definition would give the name of the Cost Type, the mode, and other
attributes. Currently the Information Resource Directory is a dictionary
with one item, "resources". So I propose adding a second item named
"cost-types," whose value is a list of cost-type definitions, as in
"cost-types" : [
{
"name" : "routingcost",
"value" : "number",
"mode" : "numerical",
"measures" : "delay",
"description" : "Standard routing cost",
}, {
"name" : "hopcount",
"value" : "number",
"mode" : "numerical",
"measures" : "hops",
"description" : "Simple hop count",
}, {
"name" : "routingcost-ord",
"value" : "number",
"mode" : "ordinal",
"measures" : "delay",
"description" : "Ordinal routing cost",
}
]
Then pretty much delete every reference to a field named "cost-mode".
To get the ball rolling, I've attached proposed replacements for
Section 5.1. Cost Attributes
Section 6.7.2. Encoding Section 6.7.3. Example
If those don't survive the list server, let me know and I'll put them up
on a web server.
If y'all like this idea, I'd be happy to help with the editing.
- Wendy Roome
>Date: Mon, 28 Jan 2013 23:08:23 +0000
>From: "Reinaldo Penno (repenno)" <[email protected]>
>Subject: [alto] ALTO Protocol Outstanding Issue II: Unifying cost-mode
> and cost-type to a single type
>
>Discussion II: Unifying cost-mode and cost-type to a single type
>
>e.g., routingcost-num and routingcost-ord
>
>Having a single type simples the protocol since there is just one
>parameter when indicating cost. But it will impact current
>implementations and might loose flexibility.
>
>Proposal: Leave it as is.
>
>Thanks,
>
>Reinaldo
5.1. Cost Attributes
An ALTO server provides one or more distinct Cost Types. Each Cost Type
has attributes, including but not limited to:
* Name: a name used to identify the Cost Type;
* Value: the JSON type of the value.
* Measures: what quantity this Cost Type measures;
* Mode: identifies how the costs should be interpreted.
Certain queries for Cost Maps allow the ALTO Client to select the
desired Cost Type.
5.1.1 Name
The Name attribute is a string used to identify a Cost Type in request
and response messages.
5.1.2 Value
The Value attribute is the JSON type for values of this Cost Type.
Currently only floating-point "number" values are recognized. Extensions
may allow additional types.
5.1.3 Measures
The Measures attribute indicates of the underlying property from which
this Cost Type is derived. For example, an ALTO Server could define
costs representing air-miles, hop-counts, delays, generic routing costs,
or even monetary expenses.
5.1.4. Mode
The Mode attribute indicates how costs should be interpreted.
Specifically, the Mode attribute indicates whether returned costs should
be interpreted as numerical values or ordinal rankings.
It is important to communicate such information to ALTO Clients, as
certain operations may not be valid on certain costs returned by an ALTO
Server. For example, it is possible for an ALTO Server to return a set
of IP addresses with costs indicating a ranking of the IP addresses.
Arithmetic operations that would make sense for numerical values, do not
make sense for ordinal rankings. ALTO Clients may handle such costs
differently.
ALTO Clients SHOULD be cognizant of operations when a desired cost mode
is not supported. For example, an ALTO Client desiring numerical costs
may adjust behavior if only the ordinal Cost Mode is available.
Alternatively, an ALTO Client desiring ordinal costs may construct
ordinal costs given numerical values if only the numerical Cost Mode is
available.
5.1.4.1. Cost Mode: numerical
This mode indicates that it is safe to perform numerical operations
(e.g. normalization or computing ratios for weighted load-balancing) on
the returned costs. The values are floating-point numbers.
5.1.4.2. Cost Mode: ordinal
This mode indicates that the costs values in a Cost Map are a ranking
(relative to all other values in the Cost Map), with lower values
indicating a higher preference. The values are non-negative integers.
Ordinal cost values in a Cost Map need not be unique nor contiguous. In
particular, it is possible that two entries in a map have an identical
rank (ordinal cost value). This document does not specify any behavior
by an ALTO Client in this case; an ALTO Client may decide to break ties
by random selection, other application knowledge, or some other means.
It is important to note that the values in the Cost Map provided with
the ordinal Cost Mode are not necessarily the actual cost known to the
ALTO Server.
5.1.5 Predefined Cost Types
5.1.5.1 Cost Type: routingcost
An ALTO Server MUST define a Cost Type named 'routingcost'. This Cost
Type conveys a generic measure for the cost of routing traffic from a
source to a destination. Lower values indicate a higher preference for
traffic to be sent from a source to a destination.
Note that an ISP may internally compute routing cost using any method it
chooses (e.g., air-miles or hop-count) as long as it conforms to these
semantics.
The Mode for 'routingcost' may be 'numerical' or 'ordinal', at the
server's discretion.
An ALTO Server MUST support at least one of ânumericalâ and âordinalâ
costs. ALTO Clients SHOULD be cognizant of operations when a desired
cost mode is not supported. For example, an ALTO Client desiring
numerical costs may adjust behavior if only the ordinal Cost Mode is
available. Alternatively, an ALTO Client desiring ordinal costs may
construct ordinal costs given numerical values if only the numerical
Cost Mode is available.
5.1.5.2 Cost Type: hopcount
An ALTO Server MAY define a Cost Type named 'hopcount'. If so, that Cost
Type MUST be based on the number of hops.
The Mode for 'hopcount' may be 'numerical' or 'ordinal', at the server's
discretion.
6.7.2. Encoding
An Information Resource Directory is a JSON object of type
InfoResourceDirectory:
object {
...
} Capabilities;
object {
JSONString uri;
JSONString media-types<1..*>;
JSONString accepts<0..*>; [OPTIONAL]
Capabilities capabilities; [OPTIONAL]
} ResourceEntry;
object {
JSONString name;
JSONString measures;
JSONString value; [OPTIONAL]
JSONString mode; [OPTIONAL]
JSONString description; [OPTIONAL]
JSONString uri; [OPTIONAL]
} CostTypeEntry;
object {
ResourceEntry resources<0..*>;
CostTypeEntry cost-types<0..*>;
} InfoResourceDirectory;
where the "resources" and "cost-types" arrays indicate a list of
Information Resources and Cost Types provided by an ALTO Server. Note
that the list of available resources is enclosed in a JSON object for
extensibility; future protocol versions may specify additional members
in the InfoResourceDirectory object.
Any URI endpoint indicated in an Information Resource Directory MAY
provide a response to an OPTIONS request that is in the format of an
Information Resource Directory response. This provides ALTO Clients a
means to discover resources and capabilities offered by that URI
endpoint. ALTO Servers that reply with an HTTP 300 status code
("Multiple Choices") SHOULD use the Information Resource Directory
format in the reply.
Each ResourceEntry in the directory specifies:
uri A URI at which the ALTO Server provides one or more Information
Resources, or an Information Resource Directory indicating
additional Information Resources. URIs can be relative and MUST be
resolved according to section 5 of [RFC3986], using the URI of the
Resource Directory as the base URI.
media-types The list of all media types of Information Resources (see
Section 6.4.3) available via GET or POST requests to the corresponding
URI or URIs discoverable via the URI.
accepts The list of all media types of input parameters (see Section
6.4.2) accepted by POST requests to the corresponding URI or URIs
discoverable via the URI. If this member is not present, it MUST be
assumed to be an empty array.
capabilities A JSON Object enumerating capabilities of an ALTO
Server in providing the Information Resource at the corresponding
URI and Information Resources discoverable via the URI. If this
member is not present, it MUST be assumed to be an empty object. If
a capability for one of the offered Information Resources is not
explicitly listed here, an ALTO Client may either issue an OPTIONS
HTTP request to the corresponding URI to determine if the capability
is supported, or assume its default value documented in this
specification or an extension document describing the capability. If
an entry has an empty list for "accepts", then the corresponding URI
MUST support GET requests. If an entry has a non-empty list for
"accepts", then the corresponding URI MUST support POST requests. If
an ALTO Server wishes to support both GET and POST on a single URI,
it MUST specify two entries in the Information Resource Directory.
The ALTO Server MUST define a CostTypeEntry for every cost type that is
supports. An ALTO Server MAY define Cost Types which it does not
currently support. Each CostTypeEntry in the directory specifies:
name The name of this Cost Type.
measures What this Cost Type measures. Values are "delay", "hops",
"distance", "money", and "other." Future versions of the protocol,
or extensions, may define additional choices.
value The JSON type of the values for this Cost Type. Currently the
only choice is "number", for a JSON number. This attribute is
optional; the default is "number." Future versions of the protocol,
or extensions, may define additional choices.
mode The cost mode "numerical" or "ordinal." The default is
"numerical."
description A free-form description of the Cost Type. "description"
is optional, but it is recommended that an ALTO Server provide
either "description" or "uri."
uri The URI of a detailed, and possibly multi-lingual, description
of this cost type. "uri" is optional, but it is recommended that an
ALTO Server provide either "uri" or "description."
Future versions of the protocol, or extensions, may define additional
items.
6.7.3. Example
The following is an example Information Resource Directory returned by
an ALTO Server. The server supports three Cost Types: the required type
"routingcost", a "hopcount" cost, and an ordinal routing cost called
"routingcost-ord." The server does not provide a ordinal version of hop
count.
In this example, the ALTO Server provides additional Network and Cost
Maps via a separate subdomain, "custom.alto.example.com". The maps
available via this subdomain are Filtered Network and Cost Maps as well
as a pre-generated map for the ordinal "routingcost-ord" Cost Type.
An ALTO Client can discover the maps available by
"custom.alto.example.com" by successfully performing an OPTIONS request
to "http://custom.alto.example.com/maps";.
In this example, the ALTO server provides the Endpoint Cost Service for
all three Cost Types.
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: ----
Content-Type: application/alto-directory+json
{
"resources" : [
{
"uri" : "/networkmap",
"media-types" : [ "application/alto-networkmap+json" ]
}, {
"uri" : "/costmap/num/routingcost",
"media-types" : [ "application/alto-costmap+json" ],
"capabilities" : {
"cost-types" : [ "routingcost" ]
}
}, {
"uri" : "/costmap/num/hopcount",
"media-types" : [ "application/alto-costmap+json" ],
"capabilities" : {
"cost-types" : [ "hopcount" ]
}
}, {
"uri" : "http://custom.alto.example.com/maps";,
"media-types" : [
"application/alto-networkmap+json",
"application/alto-costmap+json"
],
"accepts" : [
"application/alto-networkmapfilter+json",
"application/alto-costmapfilter+json"
]
}, {
"uri" : "/endpointprop/lookup",
"media-types" : [ "application/alto-endpointprop+json" ],
"accepts" : [ "application/alto-endpointpropparams+json" ],
"capabilities" : {
"prop-types" : [ "pid" ]
}
}, {
"uri" : "/endpointcost/lookup",
"media-types" : [ "application/alto-endpointcost+json" ],
"accepts" : [ "application/alto-endpointcostparams+json" ],
"capabilities" : {
"cost-constraints" : true,
"cost-types" : [ "routingcost", "hopcount", "routingcost-ord" ]
}
}
],
"cost-types" : [
{
"name" : "routingcost",
"value" : "number",
"mode" : "numerical",
"measures" : "delay",
"description" : "Standard routing cost",
}, {
"name" : "hopcount",
"value" : "number",
"mode" : "numerical",
"measures" : "hops",
"description" : "Standard hop count",
}, {
"name" : "routingcost-ord",
"value" : "number",
"mode" : "ordinal",
"measures" : "delay",
"description" : "Ordinal routing cost",
}
]
}
OPTIONS /maps HTTP/1.1
Host: custom.alto.example.com
Accept: application/alto-directory+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: ----
Content-Type: application/alto-directory+json
{
"resources" : [
{
"uri" : "/networkmap/filtered",
"media-types" : [ "application/alto-networkmap+json" ],
"accepts" : [ "application/alto-networkmapfilter+json" ]
}, {
"uri" : "/costmap/filtered",
"media-types" : [ "application/alto-costmap+json" ],
"accepts" : [ "application/alto-costmapfilter+json" ],
"capabilities" : {
"cost-constraints" : true,
"cost-types" : [ "routingcost", "hopcount", "routingcost-ord" ]
}
}, {
"uri" : "/ord/routingcost",
"media-types" : [ "application/alto-costmap+json" ],
"capabilities" : {
"cost-types" : [ "routingcost-ord" ]
}
}
],
"cost-types" : [
{
"name" : "routingcost",
"value" : "number",
"mode" : "numerical",
"measures" : "delay",
"description" : "Standard routing cost",
}, {
"name" : "hopcount",
"value" : "number",
"mode" : "numerical",
"measures" : "hops",
"description" : "Standard hop count",
}, {
"name" : "routingcost-ord",
"value" : "number",
"mode" : "ordinal",
"measures" : "delay",
"description" : "Ordinal routing cost",
}
]
}
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
