ALTO Performance Cost
MetricsHuawei101 Software Avenue, Yuhua DistrictNanjingJiangsu210012CHINAbill.wu@huawei.comYale University51 Prospect StNew HavenCT06520USAyry@cs.yale.eduSamsung1700 Alma Drive, Suite 500PlanoTX75075USAyoung.lee@gmail.comHuaweiLeela PalaceBangaloreKarnataka560008INDIAdhruv.ietf@gmail.comNokia Bell LabsRoute de VillejustNozay91460FRANCEsabine.randriamasy@nokia-bell-labs.comTelefonicaMadridSPAINluismiguel.contrerasmurillo@telefonica.com
TSV Area
ALTO Working GroupRFCRequest for CommentsI-DInternet-DraftJavaScript Object Notation, Application-Layer Traffic
OptimizationThe cost metric is a basic concept in Application-Layer Traffic
Optimization (ALTO), and different applications may use different types of
cost metrics. Since the ALTO base protocol (RFC 7285) defines only a
single cost metric (namely, the generic "routingcost" metric), if an
application wants to issue a cost map or an endpoint cost request in order to
identify a resource provider that offers a better delay performance,
the base protocol does not define the cost metric to be used.This document addresses this issue by extending the specification to
provide a variety of network performance
metrics, including network delay, delay variation (jitter), packet loss rate,
hop count, and bandwidth.There are multiple sources (e.g., estimation based on measurements or
service-level agreement) to derive a performance metric. This
document introduces an additional "cost-context" field to the ALTO
"cost-type" field to convey the source of a performance metric.
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 when,
and only when, they appear in all capitals, as shown here.
Application-Layer Traffic Optimization (ALTO) provides a means for network applications to obtain network status information so that the applications can identify efficient application-layer traffic patterns using the networks. The cost metric is a basic concept in realizing ALTO, and the concept is used in both the ALTO cost map service and the
ALTO endpoint cost service in the ALTO base protocol .
Since different applications may use different cost metrics, the ALTO base
protocol introduces an ALTO Cost Metric Registry
(Section 14.2 of ),
as a systematic mechanism to allow different metrics to be specified. For example,
a delay-sensitive application may want to use latency related metrics, and a
bandwidth-sensitive application may want to use bandwidth related metrics. However, the ALTO base protocol has registered only a single cost metric, i.e.,
the generic "routingcost" metric (see Section 14.2 of
); no latency or bandwidth related metrics are defined.This document registers a set of new cost metrics specified in Table 1, to allow
applications to determine "where" to connect based on network performance criteria including delay and bandwidth related metrics. The list of metrics is derived from .
This document follows the guideline defined in Section 14.2 of the ALTO base protocol on registering ALTO cost metrics. Hence, it specifies the identifier, the intended semantics, and the security considerations of each one of the metrics defined in Table 1.
The purpose of this document is to ensure proper usage of the performance
metrics defined in Table 1; it does not claim novelty of the metrics. The
"Origin" column of Table 1 gives an earlier RFC that has defined each metric.
The performance metrics can be classified into two categories: those
derived from the performance of individual packets (i.e., one-way delay, round-trip delay,
delay variation, hop count, and loss rate), and those related to bandwidth
(TCP throughput, residual bandwidth, and maximum reservable bandwidth).
These two categories are defined in
and respectively.
Note that all metrics except round trip delay in Table 1 are
unidirectional; hence, a
client will need to query both directions if needed.
An ALTO server may provide only a subset of the metrics described in
this document. For example, those that
are subject to privacy concerns should not be provided to unauthorized ALTO
clients. Hence, all cost metrics defined in this document are optional
and not all of them need to be exposed to a given application. When an ALTO server
supports a cost metric defined in this document,
it should announce this metric in its information resource directory (IRD) as defined in Section 9.2 of .
specifies that cost values should be assumed by default as JSONNumber. When defining the value representation of each metric in Table 1, this document conforms to this specification, but specifies additional, generic constraints on valid JSONNumbers for each metric. For example, each metric in Table 1 will be specified as non-negative (>= 0); Hop Count is specified to be an integer.
An ALTO server introducing these metrics should consider security issues.
As a generic security consideration on the reliability and trust
in the exposed metric values, applications SHOULD rapidly give up using
ALTO-based guidance if they detect that the exposed information does not preserve
their performance level or even degrades it. This document discusses security considerations
in more detail in .
Following the ALTO base protocol, this document uses JSON to specify
the value type of each defined metric. See for JSON data type
specification.When defining the metrics in Table 1, this document considers the guideline specified
in , which requires that the fine-grained specification of a network performance metric include 6 components:
(i) Metric Name, (ii) Metric Description, (iii) Method of Measurement or Calculation,
(iv) Units of Measurement, (v) Measurement Points, and (vi) Measurement Timing. Requiring that an ALTO server provide precise, fine-grained values for all 6 components for each metric that it exposes may not be feasible or necessary for all ALTO use cases. For example, the method of measurement or calculation can be complex with substantial details that cannot be exposed to or are unnecessary for ALTO clients in many use cases.To address the issue and realize ALTO use cases, for metrics in Table 1, this document defines performance metric
identifiers which can be used in the ALTO protocol with well-defined (i) Metric Name, (ii) Metric Description, (iv) Units of Measurement, and (v) Measurement Points, which are always specified by the specific ALTO services; for example, endpoint cost service is between the two endpoints. Hence, the ALTO performance metric identifiers provide basic metric attributes.To allow the flexibility of allowing an ALTO server to provide fine-grained information such as Method of Measurement or Calculation, according to its policy and use cases, this document introduces context information so that the server can provide these additional details.
The core additional details of a performance metric specify "how" the metric is obtained. This is referred to as the source of the metric. Specifically,
this document
defines three types of coarse-grained metric information sources: "nominal", and "sla" (service level agreement), and "estimation".
For a given type of source, precise interpretation of a performance metric value can depend
on particular measurement and computation parameters. For example, see
Section 3.8 of on items that a more complete measurement-based report should include.
To make it possible to specify the source and the aforementioned parameters, this document introduces
an optional "cost-context" field to the "cost-type" field defined by the ALTO base protocol
(Section 10.7 of ) as the following:
"cost-context" will not be used as a key to distinguish among performance metrics.
Hence, an ALTO information resource MUST NOT announce multiple CostType with the same "cost-metric" and "cost-mode". They must be placed into different information resources.
The "cost-source" field of the "cost-context" field is defined as a string
consisting of only US-ASCII alphanumeric characters (U+0030-U+0039,
U+0041-U+005A, and U+0061-U+007A). The cost-source is used in
this document to indicate a string of this format.This document defines three values for "cost-source": "nominal", "sla",
and "estimation". The "cost-source" field of the "cost-context" field MUST
be one registered in "ALTO Cost Source Registry" (Section 7).
The "nominal" category indicates that the metric value is statically configured by the underlying devices. Not all metrics have reasonable "nominal" values. For example, throughput can have a nominal value, which indicates the configured transmission rate of the devices; latency typically does not have a nominal value.
The "sla" category indicates that the metric value is derived from some commitment which this document refers to as service-level agreement (SLA). Some operators also use terms such as "target" or "committed" values. For an "sla" metric, it is RECOMMENDED that the "parameters" field provides a link to the SLA definition.
The "estimation" category indicates that the metric value is computed through an estimation process. An ALTO server may compute "estimation" values by retrieving
and/or aggregating information from
routing protocols (e.g., ) and traffic measurement management tools (e.g., TWAMP ), with corresponding
operational issues. An illustration of potential information flows used for estimating these metrics is shown in
Figure 1 below. will discuss in more detail the operational issues and how
a network may address them.
There can be multiple choices in deciding the cost-source category. It is the operator of an ALTO server who chooses the category. If a metric does not include a "cost-source" value, the application MUST assume that the value of "cost-source" is the most generic "estimation".
The measurement of a performance metric often yields a set of samples from an observation distribution (), instead of a single value.
A statistical operator is applied to the samples to obtain a value to be reported to
the client. Multiple statistical operators (e.g., min, median, max) are commonly being used.Hence, this document extends the general US-ASCII alphanumeric cost metric strings, formally specified as the CostMetric type defined in Section 10.6 of [RFC7285]; see above in the CostType definition, as follows: A cost metric string consists of a base metric identifier (or base identifier for short) string, followed by an optional statistical operator string, connected by the ASCII character colon (':', U+003A), if the statistical operator string exists. Examples of cost metric strings then include "delay-ow", "delay-ow:min", "delay-ow:p99", where "delay-ow" is the base metric identifier string; "min" and "p99" are example statistical operator strings.The statistical operator string MUST be one of the following:
the instantaneous observation value of the metric from the most recent sample (i.e., the current value).
gives the percentile specified by the number following the letter 'p'. The number MUST be a non-negative JSON integer in the range [0, 100] (i.e., greater than or equal to 0 and less than or equal to 100), followed by an optional decimal part, if a higher precision is needed. The decimal
part should start with the '.' separator (U+002E), and followed by a
sequence of one or more ASCII numbers between '0' and '9'. The total length of the cost metric string MUST NOT exceed 32, as required by [RFC7285]. Assume this number is y and
consider the samples coming from a random
variable X. Then the metric returns x, such that the probability
of X is less than or equal to x, i.e., Prob(X <= x), = y/100.
For example, delay-ow:p99 gives the 99% percentile of observed one-way delay; delay-ow:p99.9 gives the 99.9% percentile. Note that some systems use quantile, which is in the range [0, 1].
When there is a more common form for a given percentile, it is RECOMMENDED that the common form being used; that is, instead of p0, use min; instead of p50, use median; instead of p100, use max.
the minimal value of the observations.
the maximal value of the observations.
the mid-point (i.e., p50) of the observations.
the arithmetic mean value of the observations.
the standard deviation of the observations.
the standard variance of the observations.
If a cost metric string does not have the optional statistical operator string, the statistical operator SHOULD be interpreted as the default statistical operator in the definition of the base metric. If the definition of the base metric does not provide a definition for the default statistical operator, the metric MUST be considered as the median value.
This section introduces ALTO network performance metrics on
one way delay, round trip delay, delay variation, hop count, and packet loss rate. They
measure the "quality of experience" of
the stream of packets sent from a resource provider to a resource consumer. The measures of each individual packet (pkt) can include the delay from the time when the packet enters the network to the time when the packet leaves the network (pkt.delay); the number of network hops that the packet traverses (pkt.hopcount); and whether the packet is dropped before reaching the destination (pkt.dropped). The semantics of the performance metrics defined in this section are that they are
statistics (percentiles) computed from these measures; for example, the x-percentile of the one-way delay is the x-percentile of the set of delays {pkt.delay} for the packets in the stream.The base identifier for this performance metric is "delay-ow".The metric value type is a single 'JSONNumber' type value conforming to the number specification of [RFC8259] Section 6. The unit is expressed in milliseconds. Hence, the number can be a floating point number to express delay that is smaller than milliseconds. The number MUST be non-negative.
Intended Semantics: To specify the spatial and temporal aggregated delay of a stream of
packets from the specified source and the specified destination. The spatial aggregation level is specified in the
query context, e.g., provider-defined identifier (PID) to PID, or endpoint to endpoint, where PID is defined in Section 5.1 of [RFC7285].
Use: This metric could be used as a cost metric
constraint attribute or as a returned cost metric
in the response.Comment: Since the "cost-type" does not include the "cost-source" field, the
values are based on "estimation". Since the identifier does not include the
-<percentile> component, the values will represent median values."nominal": Typically network one-way delay does not have a nominal value.
"sla": Many networks provide delay in their application-level service level agreements. It is RECOMMENDED that the "parameters" field of an "sla" one-way delay metric includes a link (i.e., a field named "link") providing an URI to the specification of SLA details,
if available. This specification can be either free text for possible presentation to the user, or a formal specification. The format of the specification is out of the scope of this document.
"estimation": The exact estimation method is out of the scope of this document. There can be multiple sources to estimate one-way delay. For example, the server may use (by using unidirectional link delay, min/max unidirectional link delay) to estimate the path delay. During estimation, the server should be cognizant of potential issues when computing an end-to-end summary statistic from link statistics. Another example of a source to estimate the delay is through active measurements, for example, the IPPM framework .
It is RECOMMENDED that the "parameters" field of an "estimation" one-way delay metric includes a link (a field named "link") providing an URI to a description of the "estimation" method. This description can be either free text for possible presentation to the user, or a formal specification; see for the specification on fields which should be included. The format of the description is out of the scope of this document.
The base identifier for this performance metric is "delay-rt".
The metric value type is a single 'JSONNumber' type value conforming to the number specification of [RFC8259] Section 6. The number MUST be non-negative. The unit is expressed in milliseconds.Intended Semantics: To
specify spatial and temporal aggregated round-trip delay between
the specified source and specified destination. The spatial aggregation
level is specified
in the query context (e.g., PID to PID, or endpoint to endpoint).
Note that it is possible for a client to query two one-way delays (delay-ow)
and then compute the round-trip delay. The server should be cognizant of the consistency of values.
Use: This metric could be used either as a cost metric
constraint attribute or as a returned cost metric
in the response."nominal": Typically network round-trip delay does not have a nominal value.
"sla": It is RECOMMENDED that the "parameters" field of an "sla" round-trip delay metric includes a link (a field named "link") providing an URI to the specification of SLA details, if available. This specification can be either free text for possible presentation to the user, or a formal specification. The format of the specification is out of the scope of this document.
"estimation": The exact estimation method is out of the scope of this document. It is RECOMMENDED that the "parameters" field of an "estimation" round-trip delay metric includes a link (a field named "link") providing an URI to a description of the "estimation" method; see Section 3.1.4 for related discussions on the link.
The base identifier for this performance metric is "delay-variation".
The metric value type is a single 'JSONNumber' type value conforming to the number specification of [RFC8259] Section 6. The number MUST be non-negative. The unit is expressed in milliseconds.Intended Semantics: To
specify spatial and temporal aggregated delay
variation (also called delay jitter)) with respect to the minimum delay observed on the
stream over the one-way delay from the specified source and destination. The spatial
aggregation level is specified in the query context (e.g., PID to
PID, or endpoint to endpoint).
Note that in statistics, variations are typically evaluated by the distance from samples relative to the mean. In networking context, it is more commonly defined from samples relative to the min. This definition follows the networking convention.
Use: This metric could be used either as a cost metric
constraint attribute or as a returned cost metric
in the response."nominal": Typically network delay variation does not have a nominal value.
"sla": It is RECOMMENDED that the "parameters" field of an "sla" delay variation metric includes a link (a field named "link") providing an URI to the specification of SLA details, if available. This specification can be either free text for possible presentation to the user, or a formal specification. The format of the specification is out of the scope of this document.
"estimation": The exact estimation method is out of the scope of this document. It is RECOMMENDED that the "parameters" field of an "estimation" delay variation metric provides a link ("link") to a description of the "estimation" method. See Section 3.1.4 for related discussions.
The hopcount metric is mentioned in Section 9.2.3 as an
example. This section further clarifies its properties.
The base identifier for this performance metric is "hopcount".
The metric value type is a single 'JSONNumber' type value conforming to the number specification of [RFC8259] Section 6. The number MUST be a non-negative integer (greater than or equal to 0). The value represents the number of hops.Intended Semantics: To
specify the number of hops in the path from the specified source
to the specified destination. The hop count is a basic measurement
of distance in a network and can be exposed as the number of router hops
computed from the routing protocols originating this
information. The spatial
aggregation level is specified in the query context (e.g., PID to
PID, or endpoint to endpoint). Use: This metric could be used as a cost metric
constraint attribute or as a returned cost metric
in the response."nominal": Typically hop count does not have a nominal value.
"sla": Typically hop count does not have an SLA value.
"estimation": The exact estimation method is out of the scope of this document. An example of estimating hopcounts is by importing from IGP routing protocols. It is RECOMMENDED that the "parameters" field of an "estimation" hop count metric provides a link ("link") to a description of the "estimation" method.
The base identifier for this performance metric is "lossrate".
The metric value type is a single 'JSONNumber' type value conforming to the number specification of [RFC8259] Section 6. The number MUST be non-negative. The value represents the percentage of packet losses.Intended Semantics: To
specify spatial and temporal aggregated packet, one-way loss rate from the
specified source and the specified destination. The spatial aggregation level is
specified in the query context (e.g., PID to PID, or endpoint to
endpoint).Use: This metric could be used as a cost metric
constraint attribute or as a returned cost metric
in the response."nominal": Typically packet loss rate does not have a nominal value, although some networks may specify zero losses.
"sla": It is RECOMMENDED that the "parameters" field of an "sla" packet loss rate includes a link (a field named "link") providing an URI to the specification of SLA details, if available. This
specification can be either free text for possible presentation to the user, or a formal
specification. The format of the specification is out of the scope of this document.
"estimation": The exact estimation method is out of the scope of this document. It is RECOMMENDED that the "parameters" field of an "estimation" packet loss rate metric provides a link ("link") to a description of the "estimation" method. See Section 3.1.4 on related discussions such as summing up link metrics to obtain end-to-end metrics.
This section introduces three bandwidth related metrics. Given a specified source to a specified destination, these metrics reflect the volume of traffic that the network can carry from the source to the destination.
The base identifier for this performance metric is "tput".
The metric value
type is a single 'JSONNumber' type value conforming to the number specification of
[RFC8259] Section 6. The number MUST be non-negative. The
unit is bytes per second.Intended Semantics: To give the throughput of a TCP congestion-control conforming flow from the specified
source to the specified destination; see Section 5.1 of
as an example of how TCP throughput is estimated. The spatial aggregation level is specified in the
query context (e.g., PID to PID, or endpoint to endpoint). Use: This metric could be used as a cost metric
constraint attribute or as a returned cost metric
in the response."nominal": Typically TCP throughput does not have a nominal value.
"sla": Typically TCP throughput does not have an SLA value.
"estimation": The exact estimation method is out of the scope of this document. See for a method to estimate TCP throughput.
It is RECOMMENDED that the "parameters" field of an "estimation" TCP throughput metric provides two fields: (1) a congestion-control algorithm name (a field named "congestion-control-alg"); and (2) a link (a field named "link")to a description of the "estimation" method. Note that as TCP congestion control algorithms evolve (e.g., TCP Cubic Congestion Control ), it helps to specify as many details as possible on the congestion control algorithm used. This description can be either free text for possible presentation to the
user, or a formal specification. The semantics are out of the scope of this document.
The base identifier for this performance metric is "bw-residual".The metric
value type is a single 'JSONNumber' type value that is non-negative. The
unit of measurement is bytes per second.Intended Semantics: To
specify spatial and temporal residual bandwidth from the specified
source and the specified destination. The value is calculated by subtracting
tunnel reservations from Maximum Bandwidth (motivated from
[RFC8570], Section 4.5). The spatial aggregation unit is specified in
the query context (e.g., PID to PID, or endpoint to endpoint).
The default statistical operator for residual bandwidth is the current instantaneous sample; that is, the default is assumed to be "cur".Use: This metric could be used either as a cost metric
constraint attribute or as a returned cost metric
in the response."nominal": Typically residual bandwidth does not have a nominal value.
"sla": Typically residual bandwidth does not have an "sla" value.
"estimation": The exact estimation method is out of the scope of this document. It is RECOMMENDED that the "parameters" field of an "estimation" residual bandwidth metric provides a link ("link") to a description of the "estimation" method. See Section 3.1.4 on related discussions. The server should be cognizant of issues when computing end-to-end summary statistics from link statistics. For example, the min of the end-to-end path residual bandwidth is the min of all links on the path.
The base identifier for this performance metric is "bw-maxres".
The metric
value type is a single 'JSONNumber' type value that is non-negative. The
unit of measurement is bytes per second.Intended Semantics: To
specify spatial and temporal maximum reservable bandwidth from the
specified source to the specified destination. The value corresponds to
the maximum bandwidth that can be reserved (motivated from
[RFC3630] Section 2.5.7). The spatial aggregation unit is specified in
the query context (e.g., PID to PID, or endpoint to endpoint).
The default statistical operator for maximum reservable bandwidth is the current instantaneous sample; that is, the default is assumed to be "cur".Use: This metric could be used either as a cost metric
constraint attribute or as a returned cost metric
in the response."nominal": Typically maximum reservable bandwidth does not have a nominal value.
"sla": Typically maximum reservable bandwidth does not have an "sla" value.
"estimation": The exact estimation method is out of the scope of this document. There can be multiple sources to estimate maximum reservable bandwidth. For example, Maximum reservable bandwidth is defined by IS-IS/OSPF TE, and
measures the reservable bandwidth between two directly connected IS-IS neighbors or OSPF
neighbors; see Section 3.5 of . An estimation can also be computed from (by using unidirectional maximum reservable bandwidth). It is RECOMMENDED that the "parameters" field of an "estimation" maximum reservable bandwidth metric provides a link ("link") to a description of the "estimation" method. This description can be
either free text for possible presentation to the user, or a formal specification. The
semantics are out of the scope of this document.
The exact measurement infrastructure, measurement condition, and computation algorithms can vary from different networks, and are outside the scope of this document. Both the ALTO server and the ALTO clients, however, need to be cognizant of the operational issues discussed below. Also, the performance metrics specified in this document are similar, in that they
may use similar data sources and have similar issues in their
calculation. Hence, this document specifies common issues unless one metric has its unique challenges.The addition of the "cost-source" field is to solve a key issue:
An ALTO server needs data sources to compute the cost metrics
described in this document, and an ALTO client needs to know the data sources to better
interpret the values.To avoid too fine-grained information, this document introduces
"cost-source" to indicate only the high-level type of data sources:
"estimation" or "sla", where "estimation" is a type of measurement data source, and
"sla" is a type that is more based on policy.For estimation, for example, the ALTO server may use log servers or the
OAM system as its data source as recommended by . In particular, the cost
metrics defined in this document can be computed using routing systems
as the data sources.
Despite the introduction of the additional cost-context information, the metrics do not have a field to indicate the timestamps of the data used to compute the metrics. To indicate this attribute, the ALTO server SHOULD return HTTP "Last-Modified", to indicate the freshness of the data used to compute the performance metrics.
If the ALTO client obtains updates through an incremental update mechanism
, the client SHOULD assume that the metric is computed using a snapshot at the time that is approximated by the receiving time.
One potential issue introduced by the optional
"cost-source" field is backward compatibility. Consider that an IRD which defines two cost-types
with the same "cost-mode" and "cost-metric", but one with "cost-source" being "estimation" and the other being "sla". Then an ALTO client that is not aware of the extension will not
be able to distinguish between these two types. A similar issue can arise even with a single
cost-type, whose "cost-source" is "sla": an ALTO client that is not aware of this extension will ignore this field and consider the metric estimation.
To address the backward-compatibility issue, if a "cost-metric" is "routingcost" and the metric contains a "cost-context" field, then it MUST be "estimation"; if it is not, the client SHOULD reject the information as invalid.
The metric values exposed by an ALTO server may result from
additional processing on measurements from data sources to compute
exposed metrics. This may involve data processing tasks such as
aggregating the results across multiple systems, removing outliers,
and creating additional statistics. There are two challenges on the
computation of ALTO performance metrics.Performance metrics often depend on configuration parameters, and
exposing such configuration parameters can help an ALTO client to
better understand the exposed metrics. In particular, an ALTO server
may be configured to compute a TE metric (e.g., packet loss rate)
in fixed intervals, say every T seconds. To expose this information,
the ALTO server may provide the client with two pieces of additional
information: (1) when the metrics are last computed, and (2) when the metrics
will be updated (i.e., the validity period of the exposed
metric values). The ALTO server can expose these two pieces of information
by using the HTTP response headers Last-Modified and Expires.An ALTO server may not be able to measure the performance metrics to
be exposed. The basic issue is that the "source" information can often be
link level. For example, routing protocols often measure and report only
per link loss, not end-to-end loss; similarly, routing protocols report
link level available bandwidth, not end-to-end available bandwidth. The ALTO
server then needs to aggregate these data to provide an abstract and unified
view that can be more useful to applications. The server should consider that different metrics may use different aggregation computation. For example, the
end-to-end latency of a path is the sum of the latency of the links on the path;
the end-to-end available bandwidth of a path is the minimum of the available
bandwidth of the links on the path.The properties defined in this document present no security
considerations beyond those in Section 15 of the base ALTO specification
.However, concerns addressed in Sections "15.1 Authenticity and
Integrity of ALTO Information", "15.2 Potential Undesirable Guidance
from Authenticated ALTO Information", and "15.3 Confidentiality of ALTO
Information" remain of utmost importance. Indeed, TE performance is
highly sensitive ISP information; therefore, sharing TE metric values in
numerical mode requires full mutual confidence between the entities
managing the ALTO server and the ALTO client. ALTO servers will most
likely distribute numerical TE performance
to ALTO clients
under strict and formal mutual trust agreements. On the other hand, ALTO
clients must be cognizant on the risks attached to such information that
they would have acquired outside formal conditions of mutual trust.To mitigate confidentiality risks during information transport of TE performance
metrics, the operator should address the risk of ALTO information being leaked to
malicious Clients or third parties, through attacks such as
the person-in-the-middle (PITM) attacks. As specified in "Protection Strategies"
(Section 15.3.2 of ), the ALTO Server should authenticate ALTO
Clients when transmitting an ALTO information
resource containing sensitive TE performance metrics. "Authentication and
Encryption" (Section 8.3.5 of ) specifies that "ALTO Server
implementations as well as ALTO Client implementations MUST support
the "https" URI scheme of and Transport Layer Security (TLS)
of ".
IANA has created and now maintains the "ALTO Cost Metric Registry",
listed in Section 14.2, Table 3 of . This registry is located
at
<https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml#cost-metrics>.
This document requests to add the following entries to “ALTO Cost
Metric Registry”.This document requests the creation of the "ALTO Cost Source Registry".
This registry serves two purposes. First, it ensures uniqueness of
identifiers referring to ALTO cost source types. Second, it provides
references to particular semantics of allocated cost source types to be
applied by both ALTO servers and applications utilizing ALTO clients.A new ALTO cost source can be added after IETF Review , to
ensure that proper documentation regarding the new ALTO cost source
and its security considerations have been provided. The RFC(s) documenting
the new cost source should be detailed enough to provide guidance to both
ALTO service providers and applications utilizing ALTO clients as to
how values of the registered ALTO cost source should be interpreted.
Updates and deletions of ALTO cost source follow the same procedure.Registered ALTO address type identifiers MUST conform to the
syntactical requirements specified in Section 2.1. Identifiers
are to be recorded and displayed as strings.Requests to add a new value to the registry MUST include the
following information:
Identifier: The name of the desired ALTO cost source type.Intended Semantics: ALTO cost source type carry with them semantics to guide
their usage by ALTO clients. Hence, a document
defining a new type should provide guidance to both ALTO service
providers and applications utilizing ALTO clients as to how values
of the registered ALTO endpoint property should be interpreted.Security Considerations: ALTO cost source types expose
information to ALTO clients. ALTO service providers should be
made aware of the security ramifications related to the exposure
of a cost source type.This specification requests registration of the identifiers - "nominal",
"sla", and "estimation" listed in the table below. Semantics for the
these are documented in Section 2.1, and security considerations are
documented in Section 6.The authors of this document would also like to thank Martin Duke for the highly informative, thorough AD reviews and comments. We thank Christian Amsüss, Elwyn Davies, Haizhou Du, Kai Gao, Geng Li, Lili Liu, Danny Alex Lachos Perez, and Brian
Trammell
for the reviews and comments.Performance Metrics Registry, https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtmlProphet: Fast, Accurate Throughput Prediction with Reactive FlowsPrometheus: A Next-Generation Monitoring System