idnits 2.17.1 draft-ietf-alto-performance-metrics-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC2119], [RFC7285]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 260 has weird spacing: '...tMetric cost...' == Line 263 has weird spacing: '...NString descr...' == Line 267 has weird spacing: '...NString cos...' == Line 268 has weird spacing: '...ONValue par...' -- The document date (July 12, 2020) is 1384 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC7679' is mentioned on line 251, but not defined == Missing Reference: 'RFC8571' is mentioned on line 1107, but not defined -- Looks like a reference, but probably isn't: '0' on line 364 -- Looks like a reference, but probably isn't: '100' on line 358 -- Looks like a reference, but probably isn't: '1' on line 364 == Missing Reference: 'I-D.ietf-ippm-initial-registry' is mentioned on line 852, but not defined == Missing Reference: 'RFC3630' is mentioned on line 1047, but not defined == Missing Reference: 'ALTO SSE' is mentioned on line 1157, but not defined == Unused Reference: 'RFC2679' is defined on line 1312, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7971 -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO Working Group Q. Wu 3 Internet-Draft Huawei 4 Intended status: Standards Track Y. Yang 5 Expires: January 13, 2021 Yale University 6 Y. Lee 7 Samsung 8 D. Dhody 9 Huawei 10 S. Randriamasy 11 Nokia Bell Labs 12 L. Contreras 13 Telefonica 14 July 12, 2020 16 ALTO Performance Cost Metrics 17 draft-ietf-alto-performance-metrics-12 19 Abstract 21 Cost metric is a basic concept in Application-Layer Traffic 22 Optimization (ALTO), and is used in basic ALTO services including 23 both the cost map service and the endpoint cost service. 25 Different applications may use different cost metrics, but the ALTO 26 base protocol [RFC7285] defines only a single cost metric, i.e., the 27 generic "routingcost" metric; see Sec. 14.2 of [RFC7285]. Hence, if 28 the ALTO client of an application wants to issue a cost map or an 29 endpoint cost request to determine the resource provider that offers 30 better delay performance (i.e., low-delay) to a resource consumer, 31 the base protocol does not define the cost metric to be used. 33 This document addresses the issue by introducing network performance 34 metrics, including network delay, jitter, packet loss rate, hop 35 count, and bandwidth. The ALTO server may derive and aggregate such 36 performance metrics from routing protocols such as BGP-LS, OSPF-TE 37 and ISIS-TE, or from end-to-end traffic management tools, and then 38 expose the information to allow applications to determine "where" to 39 connect based on network performance criteria. 41 There are multiple sources to derive the performance metrics. For 42 example, whether the metric reported is an estimation based on 43 measurements or it is a service-level agreement (SLA) can define the 44 meaning of the performance metric. Hence, an application may need 45 additional contextual information beyond the metric value. This 46 document introduces an additional "cost-context" field to the ALTO 47 "cost-type" field to convey such information. 49 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", 50 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 51 and "OPTIONAL" in this document are to be interpreted as described in 52 [RFC2119]. 54 Status of This Memo 56 This Internet-Draft is submitted in full conformance with the 57 provisions of BCP 78 and BCP 79. 59 Internet-Drafts are working documents of the Internet Engineering 60 Task Force (IETF). Note that other groups may also distribute 61 working documents as Internet-Drafts. The list of current Internet- 62 Drafts is at http://datatracker.ietf.org/drafts/current/. 64 Internet-Drafts are draft documents valid for a maximum of six months 65 and may be updated, replaced, or obsoleted by other documents at any 66 time. It is inappropriate to use Internet-Drafts as reference 67 material or to cite them other than as "work in progress." 69 This Internet-Draft will expire on January 13, 2021. 71 Copyright Notice 73 Copyright (c) 2020 IETF Trust and the persons identified as the 74 document authors. All rights reserved. 76 This document is subject to BCP 78 and the IETF Trust's Legal 77 Provisions Relating to IETF Documents 78 (http://trustee.ietf.org/license-info) in effect on the date of 79 publication of this document. Please review these documents 80 carefully, as they describe your rights and restrictions with respect 81 to this document. Code Components extracted from this document must 82 include Simplified BSD License text as described in Section 4.e of 83 the Trust Legal Provisions and are provided without warranty as 84 described in the Simplified BSD License. 86 Table of Contents 88 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 89 2. Performance Metric Attributes . . . . . . . . . . . . . . . . 5 90 2.1. Performance Metric Context: cost-context . . . . . . . . 6 91 2.2. Performance Metric Statistics . . . . . . . . . . . . . . 8 92 3. Packet Performance Metrics . . . . . . . . . . . . . . . . . 9 93 3.1. Cost Metric: One-Way Delay (delay-ow) . . . . . . . . . . 9 94 3.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 10 95 3.1.2. Value Representation . . . . . . . . . . . . . . . . 10 96 3.1.3. Intended Semantics and Use . . . . . . . . . . . . . 10 97 3.1.4. Cost-Context Specification Considerations . . . . . . 11 98 3.2. Cost Metric: Round-trip Delay (delay-rt) . . . . . . . . 12 99 3.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 12 100 3.2.2. Value Representation . . . . . . . . . . . . . . . . 12 101 3.2.3. Intended Semantics and Use . . . . . . . . . . . . . 12 102 3.2.4. Cost-Context Specification Considerations . . . . . . 13 103 3.3. Cost Metric: Delay Variation (delay-variation) . . . . . 14 104 3.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 14 105 3.3.2. Value Representation . . . . . . . . . . . . . . . . 14 106 3.3.3. Intended Semantics and Use . . . . . . . . . . . . . 14 107 3.3.4. Cost-Context Specification Considerations . . . . . . 15 108 3.4. Cost Metric: Hop Count (hopcount) . . . . . . . . . . . . 16 109 3.4.1. Base Identifier . . . . . . . . . . . . . . . . . . . 16 110 3.4.2. Value Representation . . . . . . . . . . . . . . . . 16 111 3.4.3. Intended Semantics and Use . . . . . . . . . . . . . 16 112 3.4.4. Cost-Context Specification Considerations . . . . . . 17 113 3.5. Cost Metric: Loss Rate (lossrate) . . . . . . . . . . . . 18 114 3.5.1. Base Identifier . . . . . . . . . . . . . . . . . . . 18 115 3.5.2. Value Representation . . . . . . . . . . . . . . . . 18 116 3.5.3. Intended Semantics and Use . . . . . . . . . . . . . 18 117 3.5.4. Cost-Context Specification Considerations . . . . . . 19 118 4. Bandwidth Performance Metrics . . . . . . . . . . . . . . . . 20 119 4.1. Cost Metric: TCP Throughput (tput) . . . . . . . . . . . 20 120 4.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 20 121 4.1.2. Value Representation . . . . . . . . . . . . . . . . 20 122 4.1.3. Intended Semantics and Use . . . . . . . . . . . . . 20 123 4.1.4. Cost-Context Specification Considerations . . . . . . 21 124 4.2. Cost Metric: Residue Bandwidth (bw-residue) . . . . . . . 22 125 4.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 22 126 4.2.2. Value Representation . . . . . . . . . . . . . . . . 22 127 4.2.3. Intended Semantics and Use . . . . . . . . . . . . . 22 128 4.2.4. Cost-Context Specification Considerations . . . . . . 23 129 4.3. Cost Metric: Maximum Reservable Bandwidth (bw-maxres) . . 24 130 4.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 24 131 4.3.2. Value Representation . . . . . . . . . . . . . . . . 24 132 4.3.3. Intended Semantics and Use . . . . . . . . . . . . . 24 133 4.3.4. Cost-Context Specification Considerations . . . . . . 25 134 5. Operational Considerations . . . . . . . . . . . . . . . . . 26 135 5.1. Source Considerations . . . . . . . . . . . . . . . . . . 26 136 5.2. Metric Timestamp Consideration . . . . . . . . . . . . . 27 137 5.3. Backward Compatibility Considerations . . . . . . . . . . 27 138 5.4. Computation Considerations . . . . . . . . . . . . . . . 27 139 5.4.1. Configuration Parameters Considerations . . . . . . . 27 140 5.4.2. Availability Considerations . . . . . . . . . . . . . 28 141 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 142 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 143 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 144 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 145 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 146 9.2. Informative References . . . . . . . . . . . . . . . . . 30 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 149 1. Introduction 151 Cost Metric is a basic concept in Application-Layer Traffic 152 Optimization (ALTO). It is used in both the ALTO cost map service 153 and the ALTO endpoint cost service in the ALTO base protocol 154 [RFC7285]. 156 Since different applications may use different cost metrics, the ALTO 157 base protocol introduces an ALTO Cost Metric Registry (Section 14.2 158 of [RFC7285]), as a systematic mechanism to allow different metrics 159 to be specified. For example, a delay-sensitive application may want 160 to use latency related metrics, and a bandwidth-sensitive application 161 may want to use bandwidth related metrics. The ALTO base protocol, 162 however, has registered only a single cost metric, i.e., the generic 163 "routingcost" metric; no latency or bandwidth related metrics are 164 defined. 166 This document registers a set of new cost metrics specified in 167 Table 1, to allow applications to better determine "where" to connect 168 based on network performance criteria. This document follows the 169 guideline defined in Section 14.2 of the ALTO base protocol 170 [RFC7285]) on registering ALTO cost metrics. Hence it specifies the 171 identifier, the intended semantics, and the security considerations 172 of each one of the metrics defined in Table 1. 174 +--------------------------+-------------+-------------------+ 175 | Metric | Definition | Origin Example | 176 +--------------------------+-------------+-------------------+ 177 | One-way Delay | Section 3.1 | [RFC7679] | 178 | Round-trip Delay | Section 3.2 | [RFC2681] | 179 | Delay Variation | Section 3.3 | [RFC3393] | 180 | Hop Count | Section 3.4 | [RFC7285] | 181 | Loss Rate | Section 3.5 | [RFC7680] | 182 | | | | 183 | TCP Throughput | Section 4.1 | [RFC6349] | 184 | Residue Bandwidth | Section 4.2 | [RFC7810] | 185 | Max Reservable Bandwidth | Section 4.3 | [RFC5305] | 186 +------------+-----------------------------------------------+ 187 Table 1. Cost Metrics Defined in this Document. 189 The purpose of this document is to ensure proper usage of the 190 performance metrics defined in Table 1; it does not claim novelty of 191 the metrics. The Origin column of Table 1 gives the RFC which 192 defines each metric. 194 We can rough classify the performance metrics into two categories: 195 those derived from the performance of individual packets (i.e., one- 196 way delay, round-trip delay, delay variation, hop count, and loss 197 rate), and those related with bandwidth (TCP throughput, residue 198 bandwidth and max reservable bandwidth). These two categories are 199 defined in Section 3 and Section 4 respectively. Note that all 200 metrics except round trip delay are unidirectional. Hence, a client 201 will need to query both directions if needed. 203 An ALTO server may provide only a subset of the metrics described in 204 this document. For example, those that are subject to privacy 205 concerns should not be provided to unauthorized ALTO clients. Hence, 206 all cost metrics defined in this document are optional and not all of 207 them need to be exposed to a given application. When an ALTO server 208 supports a cost metric defined in this document, it should announce 209 this metric in its information resource directory (IRD). 211 An ALTO server introducing these metrics should consider security 212 issues. As a generic security consideration on the reliability and 213 trust in the exposed metric values, applications SHOULD rapidly give 214 up using ALTO-based guidance if they detect that the exposed 215 information does not preserve their performance level or even 216 degrades it. This document discusses security considerations in more 217 details in Section 6. 219 Following the ALTO base protocol, this document uses JSON to specify 220 the value type of each defined metric. See [RFC8259] for JSON data 221 type specification. 223 2. Performance Metric Attributes 225 When defining the metrics in Table 1, this document considers the 226 guidelines specified in [RFC6390], which requires fine-grained 227 specification of (i) Metric Name, (ii) Metric Description, (iii) 228 Method of Measurement or Calculation, (iv) Units of Measurement, (v) 229 Measurement Points, and (vi) Measurement Timing. In particular, for 230 each metric, this document defines (i) Metric Name, (ii) Metric 231 Description, and (iv) Units of Measurement. The Measurement Points 232 are always specified by the specific ALTO services; for example, 233 endpoint cost service is between the two end points. 235 On the other hand, to be able to use coarse-grained information such 236 as routing system information (e.g., [RFC8571]), which may not 237 provide fine-grained information such as (iii) Method of Measurement 238 or Calculation and (vi) Measurement Timing, this document provides 239 context information to indicate the source of information and hence 240 available metric details. 242 2.1. Performance Metric Context: cost-context 244 The details of a performance metric depend on the source of the 245 information. Specifically, this document defines four types of 246 information sources: "nominal", and "sla" (service level agreement), 247 "import", and "estimation". 249 For a given type of source, precise interpretation of a performance 250 metric value can depend on particular measurement and computation 251 parameters. For example, see Section 3.8 of [RFC7679] on items which 252 a more complete measurement-based report should include. 254 To make it possible to specify the source and the aforementioned 255 parameters, this document introduces an optional "cost-context" field 256 to the "cost-type" field defined by the ALTO base protocol 257 (Section 10.7 of [RFC7285]) as the following: 259 object { 260 CostMetric cost-metric; 261 CostMode cost-mode; 262 [CostContext cost-context;] 263 [JSONString description;] 264 } CostType; 266 object { 267 JSONString cost-source; 268 [JSONValue parameters;] 269 } CostContext; 271 The "cost-source" field of the "cost-context" field MUST be one of 272 four category values: "nominal", "sla", "import", and "estimation". 273 "cost-context" will not be used as a key to distinguish among 274 performance metrics. Hence, an ALTO information resource SHOULD NOT 275 announce multiple CostType with the same "cost-metric" and "cost- 276 mode". They can be placed into different information resources. 278 The "nominal" category indicates that the value of the metric is 279 statically configured by the underlying devices. Not all metrics 280 have reasonable "nominal" values. For example, throughput can have a 281 nominal value, which indicates the configured transmission rate of 282 the devices; latency typically do not have a nominal value. 284 The "sla" category indicates that the value of the metric is derived 285 from some commitment which this document refers to as service-level 286 agreement (SLA). Some operators also use terms such as "target" or 287 "committed" values. For a "sla" metric, it is RECOMMENDED that the 288 "parameters" field provides a link to the SLA definition. 290 The "estimation" category indicates that the value of the metric is 291 computed through an estimation process. An ALTO server may compute 292 "estimation" values by retrieving and/or aggregating information from 293 routing protocols (e.g., [RFC8571]) and traffic measurement 294 management tools (e.g., TWAMP [RFC5357]), with corresponding 295 operational issues. A potential architecture on estimating these 296 metrics is shown in Figure 1 below. Section 5 will discuss in more 297 detail the operational issues and how a network may address them. 299 +--------+ +--------+ +--------+ 300 | Client | | Client | | Client | 301 +----^---+ +---^----+ +---^----+ 302 | | | 303 +-----------|-----------+ 304 NBI |ALTO protocol 305 | 306 | 307 +--+-----+ retrieval +-----------+ 308 | ALTO |<----------------| Routing | 309 | Server | and aggregation| | 310 | |<-------------+ | Protocols | 311 +--------+ | +----------+ 312 | 313 | +-----------+ 314 | |Management | 315 ---| | 316 | Tool | 317 +-----------+ 318 Figure 1. Potential framework to compute estimation to performance metrics 320 A particular type of "estimation is direct "import", which indicates 321 that the value of the metric is imported directly from a specific 322 existing protocol or system. Specifying "import" as source instead 323 of the more generic "estimation" may allow better tracing of 324 information flow. For an "import" metric, it is RECOMMENDED that the 325 "parameters" field provides details to the system from which raw data 326 is imported. In particular, one may notice that the set of end-to- 327 end metrics defined in Table 1 has large overlap with the set defined 328 in [RFC8571], in the setting of IGP traffic engineering performance 329 metrics for each link (i.e., unidirectional link delay, min/max 330 unidirectional link delay, unidirectional delay variation, 331 unidirectional link loss, unidirectional residual bandwidth, 332 unidirectional available bandwidth, unidirectional utilized 333 bandwidth). Hence, an ALTO server may use "import" to indicate that 334 its end-to-end metrics are computed from link metrics imported from 335 [RFC8571]. 337 There can be overlap in deciding the cost-source category. It is the 338 operator of an ALTO server who chooses the category. If a metric 339 does not include a "cost-source" value, the application MUST assume 340 that the value of "cost-source" is the most generic "estimation". 342 2.2. Performance Metric Statistics 344 The measurement of a performance metric often yields a set of samples 345 from an observation distribution ([Prometheus], instead of a single 346 value. This document considers that the samples are aggregated as a 347 statistic when reported. Hence, each performance metric's identifier 348 should indicate the statistic (i.e., an aggregation operation), to 349 become -, where MUST be one of 350 the following: 352 percentile, with letter p followed by a number p: 354 gives the p percentile. Specifically, consider the samples coming 355 from a random variable X. The metric returns x, relative to 100, 356 such that the probability of X is less than or equal to x, i.e., 357 Prob(X <= x) = p/100. The number p MUST be a non-negative JSON 358 number in the range [0, 100] (i.e., greater than or equal to 0 and 359 less than or equal to 100). To avoid complex identifiers, the 360 number MUST NOT include the minus or the exp component (Section 6 361 of [RFC8259]). For example, delay-ow-p75 gives the 75% percentile 362 of observed one-way delay; delay-ow-p99.9 gives the 99.9% 363 percentile of delay. Note that some systems use quantile, which 364 is in the range [0, 1]. This document uses percentile to make the 365 identifier easier to read. 367 min: 369 the minimal value of the observation distribution. 371 max: 373 the maximal value of the observations. 375 median: 377 the mid point (i.e., p50) of the observation distribution. 379 mean: 381 the arithmetic mean value of the observations. 383 stddev: 385 the standard deviation of the observations. 387 stdvar: 389 the standard variance of the observations. 391 If a metric has no (and hence no - as well), the metric MUST 392 be considered as the 50 percentile (median). Since this scheme is 393 common for all metrics defined in this document, below we only 394 specify the base identifier. 396 3. Packet Performance Metrics 398 This section introduces ALTO network performance metrics including 399 one way delay, round trip delay, delay variation, hop count, and 400 packet loss rate. They measure the "quality of experience" of the 401 stream of packets sent from a resource provider to a resource 402 consumer. The measures of each individual packet (pkt) can include 403 the delay from the time that the packet enters the network to the 404 time that the packet leaves the network (pkt.delay); the number of 405 network hops that the packet traverses (pkt.hopcount); and whether 406 the packet is dropped before reaching destination (pkt.dropped). The 407 semantics of the performance metrics defined in this section is that 408 they are statistics (percentiles) computed from these measures; for 409 example, the x-percentile of the one-way delay is the x-percentile of 410 the set of delays {pkt.delay} for the packets in the stream. 412 3.1. Cost Metric: One-Way Delay (delay-ow) 413 3.1.1. Base Identifier 415 The base identifier for this performance metric is "delay-ow". 417 3.1.2. Value Representation 419 The metric value type is a single 'JSONNumber' type value conforming 420 to the number specification of [RFC8259] Section 6. The unit is 421 expressed in milliseconds. Hence, the number can be a floating point 422 number to express delay that is smaller than milliseconds. The 423 number MUST be non-negative. 425 3.1.3. Intended Semantics and Use 427 Intended Semantics: To specify spatial and temporal aggregated delay 428 of a stream of packets from the specified source and the specified 429 destination. The spatial aggregation level is specified in the query 430 context (e.g., PID to PID, or endpoint to endpoint). 432 Use: This metric could be used as a cost metric constraint attribute 433 or as a returned cost metric in the response. 435 Example 1: Delay value on source-destination endpoint pairs 437 POST /endpointcost/lookup HTTP/1.1 438 Host: alto.example.com 439 Content-Length: TBA 440 Content-Type: application/alto-endpointcostparams+json 441 Accept: 442 application/alto-endpointcost+json,application/alto-error+json 444 { 445 "cost-type": {"cost-mode" : "numerical", 446 "cost-metric" : "delay-ow"}, 447 "endpoints" : { 448 "srcs": [ "ipv4:192.0.2.2" ], 449 "dsts": [ 450 "ipv4:192.0.2.89", 451 "ipv4:198.51.100.34", 452 "ipv6:2000::1:2345:6789:abcd" 453 ] 454 } 455 } 456 HTTP/1.1 200 OK 457 Content-Length: TBA 458 Content-Type: application/alto-endpointcost+json 459 { 460 "meta" :{ 461 "cost-type": {"cost-mode" : "numerical", 462 "cost-metric" : "delay-ow" 463 } 464 }, 465 "endpoint-cost-map" : { 466 "ipv4:192.0.2.2": { 467 "ipv4:192.0.2.89" : 10, 468 "ipv4:198.51.100.34" : 20, 469 "ipv6:2000::1:2345:6789:abcd" : 30, 470 } 471 } 472 } 474 Comment: Since the "cost-type" does not include the "cost-source" 475 field, the values are based on "estimation". Since the identifier 476 does not include the - component, the values will 477 represent median values. 479 3.1.4. Cost-Context Specification Considerations 481 "nominal": Typically network one-way delay does not have a nominal 482 value. 484 "sla": Many networks provide delay in their application-level service 485 level agreements. It is RECOMMENDED that the "parameters" field of 486 an "sla" one-way delay metric provides a link ("link") to the SLA 487 definition. 489 "import": There can be multiple sources to import one-way delay. For 490 example, if the import is from [RFC8571] (by using unidirectional 491 link delay, min/max unidirectional link delay), it is RECOMMENDED 492 that "parameters" provides "protocol" as a field and "RFC8571" as the 493 value. During import, the server should be cognizant of potential 494 issues when computing an end-to-end summary statistics from a link 495 statistics. Another example import source is the IPPM framework. 496 For IPPM, it is recommended that "parameters" provides "protocol" as 497 a field and "ippm" as the value; see Section 4 of [I-D.ietf-ippm- 498 initial-registry] for additional fields which can be specified for 499 "ippm" in "parameters". 501 "estimation": The exact estimation method is out of the scope of this 502 document. It is RECOMMENDED that the "parameters" field of an 503 "estimation" one-way delay metric provides a link ("link") to a 504 description of the "estimation" method. 506 3.2. Cost Metric: Round-trip Delay (delay-rt) 508 3.2.1. Base Identifier 510 The base identifier for this performance metric is "delay-rt". 512 3.2.2. Value Representation 514 The metric value type is a single 'JSONNumber' type value conforming 515 to the number specification of [RFC8259] Section 6. The number MUST 516 be non-negative. The unit is expressed in milliseconds. 518 3.2.3. Intended Semantics and Use 520 Intended Semantics: To specify spatial and temporal aggregated round- 521 trip delay between the specified source and specified destination. 522 The spatial aggregation level is specified in the query context 523 (e.g., PID to PID, or endpoint to endpoint). 525 Note that it is possible for a client to query two one-way delays and 526 then compute the round-trip delay. The server should be cognizant of 527 the consistency of values. 529 Use: This metric could be used either as a cost metric constraint 530 attribute or as a returned cost metric in the response. 532 Example 2: Round-trip Delay value on source-destination endpoint pairs 534 POST /endpointcost/lookup HTTP/1.1 535 Host: alto.example.com 536 Content-Length: TBA 537 Content-Type: application/alto-endpointcostparams+json 538 Accept: 539 application/alto-endpointcost+json,application/alto-error+json 541 { 542 "cost-type": {"cost-mode" : "numerical", 543 "cost-metric" : "delay-rt"}, 544 "endpoints" : { 545 "srcs": [ "ipv4:192.0.2.2" ], 546 "dsts": [ 547 "ipv4:192.0.2.89", 548 "ipv4:198.51.100.34", 549 "ipv6:2000::1:2345:6789:abcd" 550 ] 551 } 552 } 554 HTTP/1.1 200 OK 555 Content-Length: TBA 556 Content-Type: application/alto-endpointcost+json 557 { 558 "meta" :{ 559 "cost-type": {"cost-mode" : "numerical", 560 "cost-metric" : "delay-rt" 561 } 562 }, 563 "endpoint-cost-map" : { 564 "ipv4:192.0.2.2": { 565 "ipv4:192.0.2.89" : 4, 566 "ipv4:198.51.100.34" : 3, 567 "ipv6:2000::1:2345:6789:abcd" : 2, 568 } 569 } 570 } 572 3.2.4. Cost-Context Specification Considerations 574 "nominal": Typically network round-trip delay does not have a nominal 575 value. 577 "sla": It is RECOMMENDED that the "parameters" field of an "sla" 578 round-trip delay metric provides a link ("link") to the SLA 579 definition. 581 "import": There can be multiple sources to import round-trip delay. 582 If the import is from [RFC8571] (by using unidirectional link delay, 583 min/max unidirectional link delay), it is RECOMMENDED that 584 "parameters" provides "protocol" as a field and "RFC8571" as the 585 value; see Section 3.1.4 for discussions on summing up link metrics 586 to obtain end-to-end metrics. If the import is from the IPPM 587 framework, it is recommended that "parameters" provides "protocol" as 588 a field and "ippm" as the value; see Section 4 of [I-D.ietf-ippm- 589 initial-registry] for additional fields which can be specified for 590 "ippm" in "parameters". 592 "estimation": The exact estimation method is out of the scope of this 593 document. It is RECOMMENDED that the "parameters" field of an 594 "estimation" round-trip delay metric provides a link ("link") to a 595 description of the "estimation" method. 597 3.3. Cost Metric: Delay Variation (delay-variation) 599 3.3.1. Base Identifier 601 The base identifier for this performance metric is "delay-variation". 603 3.3.2. Value Representation 605 The metric value type is a single 'JSONNumber' type value conforming 606 to the number specification of [RFC8259] Section 6. The number MUST 607 be non-negative. The unit is expressed in milliseconds. 609 3.3.3. Intended Semantics and Use 611 Intended Semantics: To specify spatial and temporal aggregated delay 612 variation (also called delay jitter)) with respect to the minimum 613 delay observed on the stream over the specified source and 614 destination. The spatial aggregation level is specified in the query 615 context (e.g., PID to PID, or endpoint to endpoint). 617 Note that in statistics, variations are typically evaluated by the 618 distance from samples relative to the mean. In networking context, 619 it is more commonly defined from samples relative to the min. This 620 definition follows the networking convention. 622 Use: This metric could be used either as a cost metric constraint 623 attribute or as a returned cost metric in the response. 625 Example 3: Delay variation value on source-destination endpoint pairs 627 POST /endpointcost/lookup HTTP/1.1 628 Host: alto.example.com 629 Content-Length: TBA 630 Content-Type: application/alto-endpointcostparams+json 631 Accept: 632 application/alto-endpointcost+json,application/alto-error+json 634 { 635 "cost-type": {"cost-mode" : "numerical", 636 "cost-metric" : "delay-var"}, 637 "endpoints" : { 638 "srcs": [ "ipv4:192.0.2.2" ], 639 "dsts": [ 640 "ipv4:192.0.2.89", 641 "ipv4:198.51.100.34", 642 "ipv6:2000::1:2345:6789:abcd" 643 ] 644 } 645 } 646 HTTP/1.1 200 OK 647 Content-Length: TBA 648 Content-Type: application/alto-endpointcost+json 649 { 650 "meta": { 651 "cost type": { 652 "cost-mode": "numerical", 653 "cost-metric":"delay-var" 654 } 655 }, 656 "endpoint-cost-map": { 657 "ipv4:192.0.2.2": { 658 "ipv4:192.0.2.89" : 0 659 "ipv4:198.51.100.34" : 1 660 "ipv6:2000::1:2345:6789:abcd" : 5 661 } 662 } 663 } 665 3.3.4. Cost-Context Specification Considerations 667 "nominal": Typically network delay variation does not have a nominal 668 value. 670 "sla": It is RECOMMENDED that the "parameters" field of an "sla" 671 delay variation metric provides a link ("link") to the SLA 672 definition. 674 "import": There can be multiple sources to import delay variation. 675 If the import is from [RFC8571] (by using unidirectional delay 676 variation), it is RECOMMENDED that "parameters" provides "protocol" 677 as a field and "RFC8571" as the value; see Section 3.1.4 for 678 discussions on summing up link metrics to obtain end-to-end metrics. 679 If the import is from the IPPM framework, it is recommended that 680 "parameters" provides "protocol" as a field and "ippm" as the value; 681 see Section 4 of [I-D.ietf-ippm-initial-registry] for additional 682 fields which can be specified for "ippm" in "parameters". 684 "estimation": The exact estimation method is out of the scope of this 685 document. It is RECOMMENDED that the "parameters" field of an 686 "estimation" delay variation metric provides a link ("link") to a 687 description of the "estimation" method. 689 3.4. Cost Metric: Hop Count (hopcount) 691 The metric hopcount is mentioned in [RFC7285] Section 9.2.3 as an 692 example. This section further clarifies its properties. 694 3.4.1. Base Identifier 696 The base identifier for this performance metric is "hopcount". 698 3.4.2. Value Representation 700 The metric value type is a single 'JSONNumber' type value conforming 701 to the number specification of [RFC8259] Section 6. The number MUST 702 be a non-negative integer (greater than or equal to 0). The value 703 represents the number of hops. 705 3.4.3. Intended Semantics and Use 707 Intended Semantics: To specify the number of hops in the path from 708 the specified source to the specified destination. The hop count is 709 a basic measurement of distance in a network and can be exposed as 710 router hops, in direct relation to the routing protocols originating 711 this information. The spatial aggregation level is specified in the 712 query context (e.g., PID to PID, or endpoint to endpoint). 714 Use: This metric could be used as a cost metric constraint attribute 715 or as a returned cost metric in the response. 717 Example 4: hopcount value on source-destination endpoint pairs 719 POST /endpointcost/lookup HTTP/1.1 720 Host: alto.example.com 721 Content-Length: TBA 722 Content-Type: application/alto-endpointcostparams+json 723 Accept: 724 application/alto-endpointcost+json,application/alto-error+json 726 { 727 "cost-type": {"cost-mode" : "numerical", 728 "cost-metric" : "hopcount"}, 729 "endpoints" : { 730 "srcs": [ "ipv4:192.0.2.2" ], 731 "dsts": [ 732 "ipv4:192.0.2.89", 733 "ipv4:198.51.100.34", 734 "ipv6:2000::1:2345:6789:abcd" 735 ] 736 } 737 } 739 HTTP/1.1 200 OK 740 Content-Length: TBA 741 Content-Type: application/alto-endpointcost+json 742 { 743 "meta": { 744 "cost type": { 745 "cost-mode": "numerical", 746 "cost-metric":"hopcount"} 747 } 748 }, 749 "endpoint-cost-map": { 750 "ipv4:192.0.2.2": { 751 "ipv4:192.0.2.89" : 5, 752 "ipv4:198.51.100.34": 3, 753 "ipv6:2000::1:2345:6789:abcd" : 2, 754 } 755 } 756 } 758 3.4.4. Cost-Context Specification Considerations 760 "nominal": Typically hop count does not have a nominal value. 762 "sla": Typically hop count does not have an SLA value. 764 "import": There can be multiple sources to import hop count such as 765 IGP routing protocols. 767 "estimation": The exact estimation method is out of the scope of this 768 document. It is RECOMMENDED that the "parameters" field of an 769 "estimation" hop count metric provides a link ("link") to a 770 description of the "estimation" method. 772 3.5. Cost Metric: Loss Rate (lossrate) 774 3.5.1. Base Identifier 776 The base identifier for this performance metric is "lossrate". 778 3.5.2. Value Representation 780 The metric value type is a single 'JSONNumber' type value conforming 781 to the number specification of [RFC8259] Section 6. The number MUST 782 be non-negative. The value represents the percentage of packet 783 losses. 785 3.5.3. Intended Semantics and Use 787 Intended Semantics: To specify spatial and temporal aggregated packet 788 loss rate from the specified source and the specified destination. 789 The spatial aggregation level is specified in the query context 790 (e.g., PID to PID, or endpoint to endpoint). 792 Use: This metric could be used as a cost metric constraint attribute 793 or as a returned cost metric in the response. 795 Example 5: Loss rate value on source-destination endpoint pairs 797 POST /endpointcost/lookup HTTP/1.1 798 Host: alto.example.com 799 Content-Length: TBA 800 Content-Type: application/alto-endpointcostparams+json 801 Accept: 802 application/alto-endpointcost+json,application/alto-error+json 804 { 805 "cost-type": {"cost-mode" : "numerical", 806 "cost-metric" : "lossrate" 807 }, 808 "endpoints" : { 809 "srcs": [ "ipv4:192.0.2.2" ], 810 "dsts": [ 811 "ipv4:192.0.2.89", 812 "ipv4:198.51.100.34", 813 "ipv6:2000::1:2345:6789:abcd" 814 ] 815 } 816 } 818 HTTP/1.1 200 OK 819 Content-Length: TBA 820 Content-Type: application/alto-endpointcost+json 821 { 822 "meta": { 823 "cost-type": { 824 "cost-mode": "numerical", 825 "cost-metric":"lossrate" 826 } 827 }, 828 "endpoint-cost-map": { 829 "ipv4:192.0.2.2": { 830 "ipv4:192.0.2.89" : 0, 831 "ipv4:198.51.100.34": 0, 832 "ipv6:2000::1:2345:6789:abcd" : 0, 833 } 834 } 835 } 837 3.5.4. Cost-Context Specification Considerations 839 "nominal": Typically packet loss rate does not have a nominal value, 840 although some networks may specify zero losses. 842 "sla": It is RECOMMENDED that the "parameters" field of an "sla" 843 packet loss rate provides a link ("link") to the SLA definition. 845 "import": There can be multiple sources to import packet loss rate. 846 If the import is from [RFC8571] (by using unidirectional link loss), 847 it is RECOMMENDED that "parameters" provides "protocol" as a field 848 and "RFC8571" as the value; see Section 3.1.4 for discussions on 849 summing up link metrics to obtain end-to-end metrics. If the import 850 is from the IPPM framework, it is recommended that "parameters" 851 provides "protocol" as a field and "ippm" as the value; see Section 4 852 of [I-D.ietf-ippm-initial-registry] for additional fields which can 853 be specified for "ippm" in "parameters". 855 "estimation": The exact estimation method is out of the scope of this 856 document. It is RECOMMENDED that the "parameters" field of an 857 "estimation" packet loss rate metric provides a link ("link") to a 858 description of the "estimation" method. 860 4. Bandwidth Performance Metrics 862 This section introduces three bandwidth related metrics. Given a 863 specified source to a specified destination, these metrics reflect 864 the volume of traffic that the network can carry from the source to 865 the destination. 867 4.1. Cost Metric: TCP Throughput (tput) 869 4.1.1. Base Identifier 871 The base identifier for this performance metric is "tput". 873 4.1.2. Value Representation 875 The metric value type is a single 'JSONNumber' type value conforming 876 to the number specification of [RFC8259] Section 6. The number MUST 877 be non-negative. The unit is bytes per second. 879 4.1.3. Intended Semantics and Use 881 Intended Semantics: To give the throughput of a TCP flow from the 882 specified source to the specified destination. The spatial 883 aggregation level is specified in the query context (e.g., PID to 884 PID, or endpoint to endpoint). 886 Use: This metric could be used as a cost metric constraint attribute 887 or as a returned cost metric in the response. 889 Example 5: TCP throughput value on source-destination endpoint pairs 891 POST /endpointcost/lookup HTTP/1.1 892 Host: alto.example.com 893 Content-Length: TBA 894 Content-Type: application/alto-endpointcostparams+json 895 Accept: 896 application/alto-endpointcost+json,application/alto-error+json 898 { 899 "cost-type": {"cost-mode" : "numerical", 900 "cost-metric" : "tput"}, 901 "endpoints" : { 902 "srcs": [ "ipv4:192.0.2.2" ], 903 "dsts": [ 904 "ipv4:192.0.2.89", 905 "ipv4:198.51.100.34", 906 "ipv6:2000::1:2345:6789:abcd" 907 ] 908 } 909 } 911 HTTP/1.1 200 OK 912 Content-Length: TBA 913 Content-Type: application/alto-endpointcost+json 914 { 915 "meta": { 916 "cost type": { 917 "cost-mode": "numerical", 918 "cost-metric":"tput" 919 } 920 } 921 "endpoint-cost-map": { 922 "ipv4:192.0.2.2": { 923 "ipv4:192.0.2.89" : 256000, 924 "ipv4:198.51.100.34": 128000, 925 "ipv6:2000::1:2345:6789:abcd" : 428000, 926 } 927 } 929 4.1.4. Cost-Context Specification Considerations 931 "nominal": Typically TCP throughput does not have a nominal value. 933 "sla": Typically TCP throughput does not have an SLA value. 935 "import": Typically there is not a routing protocol through which one 936 can import TCP throughput. If the import is from the IPPM framework, 937 it is recommended that "parameters" provides "protocol" as a field 938 and "ippm" as the value; see Section 4 of [I-D.ietf-ippm-initial- 939 registry] for additional fields which can be specified for "ippm" in 940 "parameters". 942 "estimation": The exact estimation method is out of the scope of this 943 document. See [Prophet] for a method to estimate TCP throughput. It 944 is RECOMMENDED that the "parameters" field of an "estimation" TCP 945 throughput metric provides a link ("link") to a description of the 946 "estimation" method. 948 4.2. Cost Metric: Residue Bandwidth (bw-residue) 950 4.2.1. Base Identifier 952 The base identifier for this performance metric is "bw-residue". 954 4.2.2. Value Representation 956 The metric value type is a single 'JSONNumber' type value that is 957 non-negative. The unit of measurement is bytes per second. 959 4.2.3. Intended Semantics and Use 961 Intended Semantics: To specify spatial and temporal residual 962 bandwidth from the specified source and the specified destination. 963 The value is calculated by subtracting tunnel reservations from 964 Maximum Bandwidth (motivated from [RFC7810], Section 4.5). The 965 spatial aggregation unit is specified in the query context (e.g., PID 966 to PID, or endpoint to endpoint). 968 Use: This metric could be used either as a cost metric constraint 969 attribute or as a returned cost metric in the response. 971 Example 7: bw-residue value on source-destination endpoint pairs 973 POST/ endpointcost/lookup HTTP/1.1 974 Host: alto.example.com 975 Content-Length: TBA 976 Content-Type: application/alto-endpointcostparams+json 977 Accept: 978 application/alto-endpointcost+json,application/alto-error+json 980 { 981 "cost-type": { "cost-mode": "numerical", 982 "cost-metric": "bw-residue"}, 983 "endpoints": { 984 "srcs": [ "ipv4 : 192.0.2.2" ], 985 "dsts": [ 986 "ipv4:192.0.2.89", 987 "ipv4:198.51.100.34", 988 "ipv6:2000::1:2345:6789:abcd" 989 ] 990 } 991 } 993 HTTP/1.1 200 OK 994 Content-Length: TBA 995 Content-Type: application/alto-endpointcost+json 996 { 997 "meta": { 998 "cost-type" { 999 "cost-mode": "numerical", 1000 "cost-metric": "bw-residue" 1001 } 1002 }, 1003 "endpoint-cost-map" { 1004 "ipv4:192.0.2.2" { 1005 "ipv4:192.0.2.89" : 0, 1006 "ipv4:198.51.100.34": 2000, 1007 "ipv6:2000::1:2345:6789:abcd": 5000, 1008 } 1009 } 1010 } 1012 4.2.4. Cost-Context Specification Considerations 1014 "nominal": Typically residue bandwidth does not have a nominal value. 1016 "sla": Typically residue bandwidth does not have an "sla" value. 1018 "import": There can be multiple sources to import residue bandwidth. 1019 If the import is from [RFC8571] (by using unidirectional residue 1020 bandwidth), it is RECOMMENDED that "parameters" provides "protocol" 1021 as a field and "RFC8571" as the value. The server should be 1022 cognizant of issues when computing end-to-end summary statistics from 1023 link statistics. For example, the min of the end-to-end path residue 1024 bandwidth is the min of all links on the path. 1026 "estimation": The exact estimation method is out of the scope of this 1027 document. It is RECOMMENDED that the "parameters" field of an 1028 "estimation" residue bandwidth metric provides a link ("link") to a 1029 description of the "estimation" method. 1031 4.3. Cost Metric: Maximum Reservable Bandwidth (bw-maxres) 1033 4.3.1. Base Identifier 1035 The base identifier for this performance metric is "bw-maxres". 1037 4.3.2. Value Representation 1039 The metric value type is a single 'JSONNumber' type value that is 1040 non-negative. The unit of measurement is bytes per second. 1042 4.3.3. Intended Semantics and Use 1044 Intended Semantics: To specify spatial and temporal maximum 1045 reservable bandwidth from the specified source to the specified 1046 destination. The value is corresponding to the maximum bandwidth 1047 that can be reserved (motivated from [RFC3630] Section 2.5.7). The 1048 spatial aggregation unit is specified in the query context (e.g., PID 1049 to PID, or endpoint to endpoint). 1051 Use: This metric could be used either as a cost metric constraint 1052 attribute or as a returned cost metric in the response. 1054 Example 6: bw-maxres value on source-destination endpoint pairs 1056 POST/ endpointcost/lookup HTTP/1.1 1057 Host: alto.example.com 1058 Content-Length: TBA 1059 Content-Type: application/alto-endpointcostparams+json 1060 Accept: 1061 application/alto-endpointcost+json,application/alto-error+json 1063 { 1064 "cost-type" { "cost-mode": "numerical", 1065 "cost-metric": "bw-maxres"}, 1066 "endpoints": { 1067 "srcs": [ "ipv4 : 192.0.2.2" ], 1068 "dsts": [ 1069 "ipv4:192.0.2.89", 1070 "ipv4:198.51.100.34", 1071 "ipv6:2000::1:2345:6789:abcd" 1072 ] 1073 } 1074 } 1076 HTTP/1.1 200 OK 1077 Content-Length: TBA 1078 Content-Type: application/alto-endpointcost+json 1079 { 1080 "meta": { 1081 "cost-type": { 1082 "cost-mode": "numerical", 1083 "cost-metric": "bw-maxres" 1084 } 1085 }, 1086 "endpoint-cost-map": { 1087 "ipv4:192.0.2.2" { 1088 "ipv4:192.0.2.89" : 0, 1089 "ipv4:198.51.100.34": 2000, 1090 "ipv6:2000::1:2345:6789:abcd": 5000, 1091 } 1092 } 1093 } 1095 4.3.4. Cost-Context Specification Considerations 1097 "nominal": Typically maximum reservable bandwidth does not have a 1098 nominal value. 1100 "sla": Typically maximum reservable bandwidth does not have an "sla" 1101 value. 1103 "import": There can be multiple sources to import maximum reservable 1104 bandwidth. For example, Maximum reservable bandwidth is defined by 1105 IS-IS/OSPF TE, and measures the reservable bandwidth between two 1106 directly connected IS-IS neighbors or OSPF neighbors; see Section 3.5 1107 of [RFC5305]. If the import is from [RFC8571] (by using 1108 unidirectional maximum reservable bandwidth), it is RECOMMENDED that 1109 "parameters" provides "protocol" as a field and "RFC8571" as the 1110 value. 1112 "estimation": The exact estimation method is out of the scope of this 1113 document. It is RECOMMENDED that the "parameters" field of an 1114 "estimation" maximum reservable bandwidth metric provides a link 1115 ("link") to a description of the "estimation" method. 1117 5. Operational Considerations 1119 The exact measurement infrastructure, measurement condition and 1120 computation algorithms can vary from different networks, and are 1121 outside the scope of this document. Both the ALTO server and the 1122 ALTO clients, however, need to be cognizant of the operational issues 1123 discussed below. 1125 Also, the performance metrics specified in this document are similar, 1126 in that they may use similar data sources and have similar issues in 1127 their calculation. Hence, we specify common issues unless one metric 1128 has its unique challenges. 1130 5.1. Source Considerations 1132 The addition of the "cost-source" field is to solve a key issue: An 1133 ALTO server needs data sources to compute the cost metrics described 1134 in this document and an ALTO client needs to know the data sources to 1135 better interpret the values. 1137 To avoid too fine-grained information, this document introduces 1138 "cost-source" to indicate only the high-level type of data sources: 1139 "estimation" or "sla", where "estimation" is a type of measurement 1140 data source and "sla" is a type that is more based on policy. 1142 For estimation, for example, the ALTO server may use log servers or 1143 the OAM system as its data source as recommended by [RFC7971]. In 1144 particular, the cost metrics defined in this document can be computed 1145 using routing systems as the data sources. 1147 5.2. Metric Timestamp Consideration 1149 Despite the introduction of the additional cost-context information, 1150 there is not a built-in field to indicate the timestamps of the data 1151 used to compute a metric. To indicate this attribute, the ALTO 1152 server SHOULD return HTTP "Last-Modified", to indicate the freshness 1153 of the data used to compute the performance metrics. 1155 If the ALTO client obtains updates through an incremental update 1156 mechanism (e.g., RFC editor: Fix the RFC number when available. 1157 [ALTO SSE]), the client SHOULD assume that the metric is computed 1158 using a snapshot at the time that is approximated by the receiving 1159 time. 1161 5.3. Backward Compatibility Considerations 1163 One potential issue introduced by the optional "cost-source" field is 1164 backward compatibility. Consider that an IRD which defines two cost- 1165 types with the same "cost-mode" and "cost-metric", but one with 1166 "cost-source" being "estimation" and the other being "sla". Then an 1167 ALTO client that is not aware of the extension will not be able to 1168 distinguish between these two types. A similar issue can arise even 1169 with a single cost-type which has "cost-source" being "sla", but the 1170 backward client will ignore this field and consider the metric 1171 estimation. 1173 To address this issue, the only defined "routingcost" metric can be 1174 ONLY "estimation". 1176 5.4. Computation Considerations 1178 The metric values exposed by an ALTO server may result from 1179 additional processing on measurements from data sources to compute 1180 exposed metrics. This may involve data processing tasks such as 1181 aggregating the results across multiple systems, removing outliers, 1182 and creating additional statistics. There are two challenges on the 1183 computation of ALTO performance metrics. 1185 5.4.1. Configuration Parameters Considerations 1187 Performance metrics often depend on configuration parameters. For 1188 example, the value of packet loss rate depends on the measurement 1189 interval and varies over time. To handle this issue, an ALTO server 1190 may collect data on time periods covering the previous and current 1191 time or only collect data on present time. The ALTO server may 1192 further aggregate these data to provide an abstract and unified view 1193 that can be more useful to applications. To make the ALTO client 1194 better understand how to use these performance data, the ALTO server 1195 may provide the client with the validity period of the exposed metric 1196 values. 1198 5.4.2. Availability Considerations 1200 Applications value information relating to bandwidth availability 1201 whereas bandwidth related metrics can often be only measured at the 1202 link level. This document specifies a set of link-level bandwidth 1203 related values that may be exposed as such by an ALTO server. The 1204 server may also expose other metrics derived from their aggregation 1205 and having different levels of endpoint granularity, e.g., link 1206 endpoints or session endpoints. The metric specifications may also 1207 expose the utilized aggregation laws. 1209 6. Security Considerations 1211 The properties defined in this document present no security 1212 considerations beyond those in Section 15 of the base ALTO 1213 specification [RFC7285]. 1215 However concerns addressed in Sections "15.1 Authenticity and 1216 Integrity of ALTO Information", "15.2 Potential Undesirable Guidance 1217 from Authenticated ALTO Information" and "15.3 Confidentiality of 1218 ALTO Information" remain of utmost importance. Indeed, TE 1219 performance is a highly sensitive ISP information, therefore, sharing 1220 TE metric values in numerical mode requires full mutual confidence 1221 between the entities managing the ALTO Server and Client. Numerical 1222 TE performance information will most likely be distributed by ALTO 1223 Servers to Clients under strict and formal mutual trust agreements. 1224 On the other hand, ALTO Clients must be cognizant on the risks 1225 attached to such information that they would have acquired outside 1226 formal conditions of mutual trust. 1228 7. IANA Considerations 1230 IANA has created and now maintains the "ALTO Cost Metric Registry", 1231 listed in Section 14.2, Table 3 of [RFC7285]. This registry is 1232 located at . This document requests to add the 1234 following entries to "ALTO Cost Metric Registry". 1236 +-----------------+--------------------+ 1237 | Identifier | Intended Semantics | 1238 +-----------------+--------------------+ 1239 | delay-ow | See Section 3.1 | 1240 | delay-rt | See Section 3.2 | 1241 | delay-variation | See Section 3.3 | 1242 | hopcount | See Section 3.4 | 1243 | lossrate | See Section 3.5 | 1244 | tput | See Section 4.1 | 1245 | bw-residue | See Section 4.2 | 1246 | bw-maxres | See Section 4.3 | 1247 +------------+--------------------+ 1249 Since he This document requests the creation of the "ALTO Cost Source 1250 Registry" with the following currently defined values: 1252 This document requests the creation of the "ALTO Cost Source 1253 Registry" with the following currently defined values: 1255 +------------+-----------------------------+ 1256 | Identifier | Intended Semantics | 1257 +------------+-----------------------------+ 1258 | nominal | Values in nominal cases | 1259 | sla | Values reflecting service | 1260 | | level agreement | 1261 | import | Values from a given protocol| 1262 | estimation | Values by estimation | 1263 +------------+-----------------------------+ 1265 8. Acknowledgments 1267 The authors of this document would also like to thank Brian Trammell, 1268 Haizhou Du, Kai Gao, Lili Liu, Geng Li, Danny Alex Lachos Perez for 1269 the reviews and comments. 1271 9. References 1273 9.1. Normative References 1275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1276 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1277 RFC2119, March 1997, . 1280 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 1281 Performance Metric Development", BCP 170, RFC 6390, DOI 1282 10.17487/RFC6390, October 2011, . 1285 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1286 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1287 "Application-Layer Traffic Optimization (ALTO) Protocol", 1288 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1289 . 1291 [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 1292 S. Previdi, "Application-Layer Traffic Optimization (ALTO) 1293 Deployment Considerations", RFC 7971, DOI 10.17487/ 1294 RFC7971, October 2016, . 1297 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1298 Interchange Format", STD 90, RFC 8259, DOI 10.17487/ 1299 RFC8259, December 2017, . 1302 9.2. Informative References 1304 [Prometheus] 1305 Volz, J. and B. Rabenstein, "Prometheus: A Next-Generation 1306 Monitoring System", 2015. 1308 [Prophet] Gao, K., Zhang, J., and YR. Yang, "Prophet: Fast, Accurate 1309 Throughput Prediction with Reactive Flows", ACM/IEEE 1310 Transactions on Networking July, 2020. 1312 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1313 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 1314 September 1999, . 1316 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1317 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1318 September 1999, . 1320 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1321 Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 1322 10.17487/RFC3393, November 2002, . 1325 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1326 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1327 2008, . 1329 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1330 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1331 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1332 . 1334 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 1335 "Framework for TCP Throughput Testing", RFC 6349, DOI 1336 10.17487/RFC6349, August 2011, . 1339 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1340 Ed., "A One-Way Loss Metric for IP Performance Metrics 1341 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1342 2016, . 1344 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1345 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1346 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1347 . 1349 Authors' Addresses 1351 Qin Wu 1352 Huawei 1353 101 Software Avenue, Yuhua District 1354 Nanjing, Jiangsu 210012 1355 CHINA 1357 Email: bill.wu@huawei.com 1359 Y. Richard Yang 1360 Yale University 1361 51 Prospect St 1362 New Haven, CT 06520 1363 USA 1365 Email: yry@cs.yale.edu 1367 Young Lee 1368 Samsung 1369 1700 Alma Drive, Suite 500 1370 Plano, TX 75075 1371 USA 1373 Email: young.lee@gmail.com 1374 Dhruv Dhody 1375 Huawei 1376 Leela Palace 1377 Bangalore, Karnataka 560008 1378 INDIA 1380 Email: dhruv.ietf@gmail.com 1382 Sabine Randriamasy 1383 Nokia Bell Labs 1384 Route de Villejust 1385 Nozay 91460 1386 FRANCE 1388 Email: sabine.randriamasy@nokia-bell-labs.com 1390 Luis Miguel Contreras Murillo 1391 Telefonica 1392 Madrid 1393 SPAIN 1395 Email: luismiguel.contrerasmurillo@telefonica.com