idnits 2.17.1 draft-ietf-alto-performance-metrics-11.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 242 has weird spacing: '...tMetric cost...' == Line 245 has weird spacing: '...NString descr...' == Line 249 has weird spacing: '...NString cos...' == Line 250 has weird spacing: '...ONValue par...' -- The document date (June 11, 2020) is 1386 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 1115, but not defined == Missing Reference: 'RFC7680' is mentioned on line 1115, but not defined == Missing Reference: 'RFC8571' is mentioned on line 1076, but not defined == Missing Reference: 'I-D.ietf-ippm-initial-registry' is mentioned on line 821, but not defined == Missing Reference: 'RFC3630' is mentioned on line 1115, but not defined == Missing Reference: 'RFC3784' is mentioned on line 1115, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) == Missing Reference: 'RFC7471' is mentioned on line 1115, but not defined == Missing Reference: 'RFC7752' is mentioned on line 1116, but not defined ** Obsolete undefined reference: RFC 7752 (Obsoleted by RFC 9552) == Missing Reference: 'I-D.ietf-idr-te-pm-bgp' is mentioned on line 1116, but not defined == Missing Reference: 'ALTO SSE' is mentioned on line 1129, but not defined == Unused Reference: 'RFC2679' is defined on line 1250, but no explicit reference was found in the text == Unused Reference: 'RFC6390' is defined on line 1296, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Downref: Normative reference to an Informational RFC: RFC 6349 ** Obsolete normative reference: RFC 7810 (Obsoleted by RFC 8570) Summary: 7 errors (**), 0 flaws (~~), 17 warnings (==), 2 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: December 13, 2020 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 June 11, 2020 16 ALTO Performance Cost Metrics 17 draft-ietf-alto-performance-metrics-11 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 December 13, 2020. 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 . . . . . . . . 5 91 2.2. Performance Metric Statistics . . . . . . . . . . . . . . 7 92 3. Packet Performance Metrics . . . . . . . . . . . . . . . . . 8 93 3.1. Cost Metric: One-Way Delay (delay-ow) . . . . . . . . . . 9 94 3.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 9 95 3.1.2. Value Representation . . . . . . . . . . . . . . . . 9 96 3.1.3. Intended Semantics and Use . . . . . . . . . . . . . 9 97 3.1.4. Cost-Context Specification Considerations . . . . . . 11 98 3.2. Cost Metric: Round-trip Delay (delay-rt) . . . . . . . . 11 99 3.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 11 100 3.2.2. Value Representation . . . . . . . . . . . . . . . . 11 101 3.2.3. Intended Semantics and Use . . . . . . . . . . . . . 11 102 3.2.4. Cost-Context Specification Considerations . . . . . . 13 103 3.3. Cost Metric: Delay Variation (delay-variation) . . . . . 13 104 3.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 13 105 3.3.2. Value Representation . . . . . . . . . . . . . . . . 13 106 3.3.3. Intended Semantics and Use . . . . . . . . . . . . . 13 107 3.3.4. Cost-Context Specification Considerations . . . . . . 15 108 3.4. Cost Metric: Hop Count (hopcount) . . . . . . . . . . . . 15 109 3.4.1. Base Identifier . . . . . . . . . . . . . . . . . . . 15 110 3.4.2. Value Representation . . . . . . . . . . . . . . . . 15 111 3.4.3. Intended Semantics and Use . . . . . . . . . . . . . 15 112 3.4.4. Cost-Context Specification Considerations . . . . . . 17 113 3.5. Cost Metric: Loss Rate (lossrate) . . . . . . . . . . . . 17 114 3.5.1. Base Identifier . . . . . . . . . . . . . . . . . . . 17 115 3.5.2. Value Representation . . . . . . . . . . . . . . . . 17 116 3.5.3. Intended Semantics and Use . . . . . . . . . . . . . 17 117 3.5.4. Cost-Context Specification Considerations . . . . . . 18 118 4. Bandwidth Performance Metrics . . . . . . . . . . . . . . . . 19 119 4.1. Cost Metric: TCP Throughput (tput) . . . . . . . . . . . 19 120 4.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 19 121 4.1.2. Value Representation . . . . . . . . . . . . . . . . 19 122 4.1.3. Intended Semantics and Use . . . . . . . . . . . . . 19 123 4.1.4. Cost-Context Specification Considerations . . . . . . 20 124 4.2. Cost Metric: Residue Bandwidth . . . . . . . . . . . . . 21 125 4.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 21 126 4.2.2. Value Representation . . . . . . . . . . . . . . . . 21 127 4.2.3. Intended Semantics and Use . . . . . . . . . . . . . 21 128 4.2.4. Cost-Context Specification Considerations . . . . . . 22 129 4.3. Cost Metric: Maximum Reservable Bandwidth . . . . . . . . 23 130 4.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 23 131 4.3.2. Value Representation . . . . . . . . . . . . . . . . 23 132 4.3.3. Intended Semantics and Use . . . . . . . . . . . . . 23 133 4.3.4. Cost-Context Specification Considerations . . . . . . 24 134 5. Operational Considerations . . . . . . . . . . . . . . . . . 25 135 5.1. Source Considerations . . . . . . . . . . . . . . . . . . 25 136 5.2. Metric Timestamp Consideration . . . . . . . . . . . . . 26 137 5.3. Backward Compatibility Considerations . . . . . . . . . . 26 138 5.4. Computation Considerations . . . . . . . . . . . . . . . 26 139 5.4.1. Configuration Parameters Considerations . . . . . . . 26 140 5.4.2. Availability Considerations . . . . . . . . . . . . . 27 141 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 142 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 143 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 144 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 145 9.1. Normative References . . . . . . . . . . . . . . . . . . 28 146 9.2. Informative References . . . . . . . . . . . . . . . . . 29 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 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 one single cost metric, i.e., the 163 generic "routingcost" metric; no latency or bandwidth related metrics 164 are 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. For each performance metric, the Origin column of 192 Table 1 gives an earlier RFC which has defined the metric. We can 193 rough classify the performance metrics into two categories: those 194 derived from the performance of individual packets (i.e., one-way 195 delay, round-trip delay, delay variation, hop count, and loss rate), 196 and those related with bandwidth (TCP throughput, residue bandwidth 197 and max reservable bandwidth). These two categories are defined in 198 Section 3 and Section 4 respectively. Note that all metrics except 199 round trip delay are unidirectional. Hence, a client will need to 200 query both directions if needed. 202 An ALTO server may provide only a subset of the metrics described in 203 this document. For example, those that are subject to privacy 204 concerns should not be provided to unauthorized ALTO clients. Hence, 205 all cost metrics defined in this document are optional and not all of 206 them need to be exposed to a given application. When an ALTO server 207 supports a cost metric defined in this document, it should announce 208 this metric in its information resource directory (IRD). 210 An ALTO server introducing these metrics should consider security 211 issues. As a generic security consideration on the reliability and 212 trust in the exposed metric values, applications SHOULD rapidly give 213 up using ALTO-based guidance if they detect that the exposed 214 information does not preserve their performance level or even 215 degrades it. This document discusses security considerations in more 216 details in Section 6. 218 Following the ALTO base protocol, this document uses JSON to specify 219 the value type of each defined metric. See [RFC8259] for JSON data 220 type specification. 222 2. Performance Metric Attributes 224 2.1. Performance Metric Context: cost-context 226 The semantics of a performance metric depends on the source of the 227 information. Specifically, this document defines four information 228 sources when defining performance metrics: "nominal", and "sla" 229 (service level agreement), "import", and "estimation". 231 Even given the source, precise interpretation of a performance metric 232 value, if needed, depends on an additional set of measurement and 233 computation parameters. For example, see Section 3.8 of [RFC7679] on 234 items which a more complete measurement-based report should include. 236 To make it possible to specify both the source and the additional 237 parameters, this document introduces an optional "cost-context" field 238 to the "cost-type" field defined by the ALTO base protocol 239 (Section 10.7 of [RFC7285]) as the following: 241 object { 242 CostMetric cost-metric; 243 CostMode cost-mode; 244 [CostContext cost-context;] 245 [JSONString description;] 246 } CostType; 248 object { 249 JSONString cost-source; 250 [JSONValue parameters;] 251 } CostContext; 253 The "cost-source" field of the "cost-context" field MUST be one of 254 four category values: "nominal", "sla", "import", and "estimation". 255 "cost-context" will not be used as a key to distinguish among 256 performance metrics. Hence, an ALTO information resource SHOULD NOT 257 announce multiple CostType with the same "cost-metric" and "cost- 258 mode". They can be placed into different information resources. 260 The "nominal" category indicates that the value of the metric is 261 statically configured by the underlying devices. Not all metrics 262 have reasonable "nominal" values. For example, throughput can have a 263 nominal value, which indicates the configured transmission rate of 264 the devices; latency typically do not have a nominal value. 266 The "sla" category indicates that the value of the metric is derived 267 from some commitment which this document refers to as service-level 268 agreement (SLA). Some operators also use terms such as "target" or 269 "committed" values. For a "sla" metric, it is RECOMMENDED that the 270 "parameters" field provides a link to the SLA definition. 272 The "import" category indicates that the value of the metric is 273 derived from importing from a specific existing protocol or system. 274 For an "import" metric, it is RECOMMENDED that the "parameters" field 275 provides details to the system from which raw data is imported. In 276 particular, one may notice that the set of end-to-end metrics defined 277 in Table 1 has large overlap with the set defined in [RFC8571], in 278 the setting of IGP traffic engineering performance metrics for each 279 link (i.e., unidirectional link delay, min/max unidirectional link 280 delay, unidirectional delay variation, unidirectional link loss, 281 unidirectional residual bandwidth, unidirectional available 282 bandwidth, unidirectional utilized bandwidth). Hence, an ALTO server 283 may use "import" to indicate that its end-to-end metrics are computed 284 from link metrics imported from [RFC8571]. 286 The "estimation" category indicates that the value of the metric is 287 computed through an estimation process. An ALTO server may compute 288 "estimation" values by retrieving and/or aggregating information from 289 routing protocols (e.g., [RFC8571]) and traffic measurement 290 management tools (e.g., TWAMP), with corresponding operational 291 issues. A potential architecture on estimating these metrics is 292 shown in Figure 1 below. Section 5 will discuss in more detail the 293 operational issues and how a network may address them. 295 +--------+ +--------+ +--------+ 296 | Client | | Client | | Client | 297 +----^---+ +---^----+ +---^----+ 298 | | | 299 +-----------|-----------+ 300 NBI |ALTO protocol 301 | 302 | 303 +--+-----+ retrieval +-----------+ 304 | ALTO |<----------------| Routing | 305 | Server | and aggregation| | 306 | |<-------------+ | Protocols | 307 +--------+ | +----------+ 308 | 309 | +-----------+ 310 | |Management | 311 ---| | 312 | Tool | 313 +-----------+ 314 Figure 1. Potential framework to compute estimation to performance metrics 316 There can be overlap in deciding the cost-source category. It is the 317 operator of an ALTO server who chooses the category. If a metric 318 does not include a "cost-source" value, the application MUST assume 319 that the value of "cost-source" is "estimation". 321 2.2. Performance Metric Statistics 323 Even with a specified cost context, a performance metric may be 324 observed with values from an observation distribution. To address 325 this issue, this document allows each performance metric's identifier 326 to indicate a summary statistics of the distribution, to become 327 -, where MUST be one of the 328 following: 330 letter p followed by a number: 332 the value represents the percentile: less than or equal to number 333 percent of observations are lower than the value (for example, 334 delay-ow-p75 gives the value that 75% of observed one-way delays 335 will be less or equal to it). To avoid complex identifiers, the 336 number MUST be a JSON number (Section 6 of [RFC8259]) without the 337 minus or the exp component. 339 max: 341 the maximal value of the observation distribution. 343 min: 345 the minimal value of the observation distribution. 347 median: 349 the mid point of the observation distribution. 351 mean: 353 the arithmetic mean value of the observations. 355 stand-deviation: 357 the standard deviation of the observations. 359 If a metric has no (and hence no - as well), the metric is the 360 50 percentile (median). Since this scheme is common for all metrics 361 defined in this document, below we only specify the base identifier. 363 3. Packet Performance Metrics 365 This section introduces ALTO network performance metrics including 366 one way delay, round trip delay, delay variation, hop count, and 367 packet loss rate. They measure the "quality of experience" of the 368 stream of packets sent from a resource provider to a resource 369 consumer. The measures of each individual packet (pkt) can include 370 the delay from the time that the packet enters the network to the 371 time that the packet leaves the network (pkt.delay); the number of 372 network hops that the packet traverses (pkt.hopcount); and whether 373 the packet is dropped before reaching destination (pkt.dropped). The 374 semantics of the performance metrics defined in this section is that 375 they are statistics (percentiles) computed from these measures; for 376 example, the x-percentile of the one-way delay is the x-percentile of 377 the set of delays {pkt.delay} for the packets in the stream. 379 3.1. Cost Metric: One-Way Delay (delay-ow) 381 3.1.1. Base Identifier 383 The base identifier for this performance metric is "delay-ow". 385 3.1.2. Value Representation 387 The metric value type is a single 'JSONNumber' type value conforming 388 to the number specification of [RFC8259] Section 6. The unit is 389 expressed in milliseconds. Hence, the number can be a floating point 390 number to express delay that is smaller than milliseconds. The 391 number MUST be non-negative. 393 3.1.3. Intended Semantics and Use 395 Intended Semantics: To specify spatial and temporal aggregated delay 396 of a stream of packets from the specified source and the specified 397 destination. The spatial aggregation level is specified in the query 398 context (e.g., PID to PID, or endpoint to endpoint). 400 Use: This metric could be used as a cost metric constraint attribute 401 or as a returned cost metric in the response. 403 Example 1: Delay value on source-destination endpoint pairs 405 POST /endpointcost/lookup HTTP/1.1 406 Host: alto.example.com 407 Content-Length: TBA 408 Content-Type: application/alto-endpointcostparams+json 409 Accept: 410 application/alto-endpointcost+json,application/alto-error+json 412 { 413 "cost-type": {"cost-mode" : "numerical", 414 "cost-metric" : "delay-ow"}, 415 "endpoints" : { 416 "srcs": [ "ipv4:192.0.2.2" ], 417 "dsts": [ 418 "ipv4:192.0.2.89", 419 "ipv4:198.51.100.34", 420 "ipv6:2000::1:2345:6789:abcd" 421 ] 422 } 423 } 425 HTTP/1.1 200 OK 426 Content-Length: TBA 427 Content-Type: application/alto-endpointcost+json 428 { 429 "meta" :{ 430 "cost-type": {"cost-mode" : "numerical", 431 "cost-metric" : "delay-ow" 432 } 433 }, 434 "endpoint-cost-map" : { 435 "ipv4:192.0.2.2": { 436 "ipv4:192.0.2.89" : 10, 437 "ipv4:198.51.100.34" : 20, 438 "ipv6:2000::1:2345:6789:abcd" : 30, 439 } 440 } 441 } 443 Comment: Since the "cost-type" does not include the "cost-source" 444 field, the values are based on "estimation". Since the identifier 445 does not include the - component, the values will 446 represent median values. 448 3.1.4. Cost-Context Specification Considerations 450 "nominal": Typically network one-way delay does not have a nominal 451 value. 453 "sla": Many networks provide delay in their application-level service 454 level agreements. It is RECOMMENDED that the "parameters" field of 455 an "sla" one-way delay metric provides a link ("link") to the SLA 456 definition. 458 "import": There can be multiple sources to import one-way delay. For 459 example, if the import is from [RFC8571] (by using unidirectional 460 link delay, min/max unidirectional link delay), it is RECOMMENDED 461 that "parameters" provides "protocol" as a field and "RFC8571" as the 462 value. During import, the server should be cognizant of potential 463 issues when computing an end-to-end summary statistics from a link 464 statistics. Another example import source is the IPPM framework. 465 For IPPM, it is recommended that "parameters" provides "protocol" as 466 a field and "ippm" as the value; see Section 4 of [I-D.ietf-ippm- 467 initial-registry] for additional fields which can be specified for 468 "ippm" in "parameters". 470 "estimation": The exact estimation method is out of the scope of this 471 document. It is RECOMMENDED that the "parameters" field of an 472 "estimation" one-way delay metric provides a link ("link") to a 473 description of the "estimation" method. 475 3.2. Cost Metric: Round-trip Delay (delay-rt) 477 3.2.1. Base Identifier 479 The base identifier for this performance metric is "delay-rt". 481 3.2.2. Value Representation 483 The metric value type is a single 'JSONNumber' type value conforming 484 to the number specification of [RFC8259] Section 6. The number MUST 485 be non-negative. The unit is expressed in milliseconds. 487 3.2.3. Intended Semantics and Use 489 Intended Semantics: To specify spatial and temporal aggregated round- 490 trip delay between the specified source and specified destination. 491 The spatial aggregation level is specified in the query context 492 (e.g., PID to PID, or endpoint to endpoint). 494 Note that it is possible for a client to query two one-way delays and 495 then compute the round-trip delay. The server should be cognizant of 496 the consistency of values. 498 Use: This metric could be used either as a cost metric constraint 499 attribute or as a returned cost metric in the response. 501 Example 2: Round-trip Delay value on source-destination endpoint pairs 503 POST /endpointcost/lookup HTTP/1.1 504 Host: alto.example.com 505 Content-Length: TBA 506 Content-Type: application/alto-endpointcostparams+json 507 Accept: 508 application/alto-endpointcost+json,application/alto-error+json 510 { 511 "cost-type": {"cost-mode" : "numerical", 512 "cost-metric" : "delay-rt"}, 513 "endpoints" : { 514 "srcs": [ "ipv4:192.0.2.2" ], 515 "dsts": [ 516 "ipv4:192.0.2.89", 517 "ipv4:198.51.100.34", 518 "ipv6:2000::1:2345:6789:abcd" 519 ] 520 } 521 } 523 HTTP/1.1 200 OK 524 Content-Length: TBA 525 Content-Type: application/alto-endpointcost+json 526 { 527 "meta" :{ 528 "cost-type": {"cost-mode" : "numerical", 529 "cost-metric" : "delay-rt" 530 } 531 }, 532 "endpoint-cost-map" : { 533 "ipv4:192.0.2.2": { 534 "ipv4:192.0.2.89" : 4, 535 "ipv4:198.51.100.34" : 3, 536 "ipv6:2000::1:2345:6789:abcd" : 2, 537 } 538 } 539 } 541 3.2.4. Cost-Context Specification Considerations 543 "nominal": Typically network round-trip delay does not have a nominal 544 value. 546 "sla": It is RECOMMENDED that the "parameters" field of an "sla" 547 round-trip delay metric provides a link ("link") to the SLA 548 definition. 550 "import": There can be multiple sources to import round-trip delay. 551 If the import is from [RFC8571] (by using unidirectional link delay, 552 min/max unidirectional link delay), it is RECOMMENDED that 553 "parameters" provides "protocol" as a field and "RFC8571" as the 554 value; see Section 3.1.4 for discussions on summing up link metrics 555 to obtain end-to-end metrics. If the import is from the IPPM 556 framework, it is recommended that "parameters" provides "protocol" as 557 a field and "ippm" as the value; see Section 4 of [I-D.ietf-ippm- 558 initial-registry] for additional fields which can be specified for 559 "ippm" in "parameters". 561 "estimation": The exact estimation method is out of the scope of this 562 document. It is RECOMMENDED that the "parameters" field of an 563 "estimation" round-trip delay metric provides a link ("link") to a 564 description of the "estimation" method. 566 3.3. Cost Metric: Delay Variation (delay-variation) 568 3.3.1. Base Identifier 570 The base identifier for this performance metric is "delay-variation". 572 3.3.2. Value Representation 574 The metric value type is a single 'JSONNumber' type value conforming 575 to the number specification of [RFC8259] Section 6. The number MUST 576 be non-negative. The unit is expressed in milliseconds. 578 3.3.3. Intended Semantics and Use 580 Intended Semantics: To specify spatial and temporal aggregated delay 581 variation (also called delay jitter)) with respect to the minimum 582 delay observed on the stream over the specified source and 583 destination. The spatial aggregation level is specified in the query 584 context (e.g., PID to PID, or endpoint to endpoint). 586 Note that in statistics, variations are typically evaluated by the 587 distance from samples relative to the mean. In networking context, 588 it is more commonly defined from samples relative to the min. This 589 definition follows the networking convention. 591 Use: This metric could be used either as a cost metric constraint 592 attribute or as a returned cost metric in the response. 594 Example 3: Delay variation value on source-destination endpoint pairs 596 POST /endpointcost/lookup HTTP/1.1 597 Host: alto.example.com 598 Content-Length: TBA 599 Content-Type: application/alto-endpointcostparams+json 600 Accept: 601 application/alto-endpointcost+json,application/alto-error+json 603 { 604 "cost-type": {"cost-mode" : "numerical", 605 "cost-metric" : "delay-var"}, 606 "endpoints" : { 607 "srcs": [ "ipv4:192.0.2.2" ], 608 "dsts": [ 609 "ipv4:192.0.2.89", 610 "ipv4:198.51.100.34", 611 "ipv6:2000::1:2345:6789:abcd" 612 ] 613 } 614 } 615 HTTP/1.1 200 OK 616 Content-Length: TBA 617 Content-Type: application/alto-endpointcost+json 618 { 619 "meta": { 620 "cost type": { 621 "cost-mode": "numerical", 622 "cost-metric":"delay-var" 623 } 624 }, 625 "endpoint-cost-map": { 626 "ipv4:192.0.2.2": { 627 "ipv4:192.0.2.89" : 0 628 "ipv4:198.51.100.34" : 1 629 "ipv6:2000::1:2345:6789:abcd" : 5 630 } 631 } 632 } 634 3.3.4. Cost-Context Specification Considerations 636 "nominal": Typically network delay variation does not have a nominal 637 value. 639 "sla": It is RECOMMENDED that the "parameters" field of an "sla" 640 delay variation metric provides a link ("link") to the SLA 641 definition. 643 "import": There can be multiple sources to import delay variation. 644 If the import is from [RFC8571] (by using unidirectional delay 645 variation), it is RECOMMENDED that "parameters" provides "protocol" 646 as a field and "RFC8571" as the value; see Section 3.1.4 for 647 discussions on summing up link metrics to obtain end-to-end metrics. 648 If the import is from the IPPM framework, it is recommended that 649 "parameters" provides "protocol" as a field and "ippm" as the value; 650 see Section 4 of [I-D.ietf-ippm-initial-registry] for additional 651 fields which can be specified for "ippm" in "parameters". 653 "estimation": The exact estimation method is out of the scope of this 654 document. It is RECOMMENDED that the "parameters" field of an 655 "estimation" delay variation metric provides a link ("link") to a 656 description of the "estimation" method. 658 3.4. Cost Metric: Hop Count (hopcount) 660 The metric hopcount is mentioned in [RFC7285] Section 9.2.3 as an 661 example. This section further clarifies its properties. 663 3.4.1. Base Identifier 665 The base identifier for this performance metric is "hopcount". 667 3.4.2. Value Representation 669 The metric value type is a single 'JSONNumber' type value conforming 670 to the number specification of [RFC8259] Section 6. The number MUST 671 be a non-negative integer (greater than or equal to 0). The value 672 represents the number of hops. 674 3.4.3. Intended Semantics and Use 676 Intended Semantics: To specify the number of hops in the path from 677 the specified source to the specified destination. The hop count is 678 a basic measurement of distance in a network and can be exposed as 679 router hops, in direct relation to the routing protocols originating 680 this information. The spatial aggregation level is specified in the 681 query context (e.g., PID to PID, or endpoint to endpoint). 683 Use: This metric could be used as a cost metric constraint attribute 684 or as a returned cost metric in the response. 686 Example 4: hopcount value on source-destination endpoint pairs 688 POST /endpointcost/lookup HTTP/1.1 689 Host: alto.example.com 690 Content-Length: TBA 691 Content-Type: application/alto-endpointcostparams+json 692 Accept: 693 application/alto-endpointcost+json,application/alto-error+json 695 { 696 "cost-type": {"cost-mode" : "numerical", 697 "cost-metric" : "hopcount"}, 698 "endpoints" : { 699 "srcs": [ "ipv4:192.0.2.2" ], 700 "dsts": [ 701 "ipv4:192.0.2.89", 702 "ipv4:198.51.100.34", 703 "ipv6:2000::1:2345:6789:abcd" 704 ] 705 } 706 } 708 HTTP/1.1 200 OK 709 Content-Length: TBA 710 Content-Type: application/alto-endpointcost+json 711 { 712 "meta": { 713 "cost type": { 714 "cost-mode": "numerical", 715 "cost-metric":"hopcount"} 716 } 717 }, 718 "endpoint-cost-map": { 719 "ipv4:192.0.2.2": { 720 "ipv4:192.0.2.89" : 5, 721 "ipv4:198.51.100.34": 3, 722 "ipv6:2000::1:2345:6789:abcd" : 2, 723 } 724 } 725 } 727 3.4.4. Cost-Context Specification Considerations 729 "nominal": Typically hop count does not have a nominal value. 731 "sla": Typically hop count does not have an SLA value. 733 "import": There can be multiple sources to import hop count such as 734 IGP routing protocols. 736 "estimation": The exact estimation method is out of the scope of this 737 document. It is RECOMMENDED that the "parameters" field of an 738 "estimation" hop count metric provides a link ("link") to a 739 description of the "estimation" method. 741 3.5. Cost Metric: Loss Rate (lossrate) 743 3.5.1. Base Identifier 745 The base identifier for this performance metric is "lossrate". 747 3.5.2. Value Representation 749 The metric value type is a single 'JSONNumber' type value conforming 750 to the number specification of [RFC8259] Section 6. The number MUST 751 be non-negative. The value represents the percentage of packet 752 losses. 754 3.5.3. Intended Semantics and Use 756 Intended Semantics: To specify spatial and temporal aggregated packet 757 loss rate from the specified source and the specified destination. 758 The spatial aggregation level is specified in the query context 759 (e.g., PID to PID, or endpoint to endpoint). 761 Use: This metric could be used as a cost metric constraint attribute 762 or as a returned cost metric in the response. 764 Example 5: Loss rate value on source-destination endpoint pairs 766 POST /endpointcost/lookup HTTP/1.1 767 Host: alto.example.com 768 Content-Length: TBA 769 Content-Type: application/alto-endpointcostparams+json 770 Accept: 771 application/alto-endpointcost+json,application/alto-error+json 773 { 774 "cost-type": {"cost-mode" : "numerical", 775 "cost-metric" : "lossrate" 776 }, 777 "endpoints" : { 778 "srcs": [ "ipv4:192.0.2.2" ], 779 "dsts": [ 780 "ipv4:192.0.2.89", 781 "ipv4:198.51.100.34", 782 "ipv6:2000::1:2345:6789:abcd" 783 ] 784 } 785 } 787 HTTP/1.1 200 OK 788 Content-Length: TBA 789 Content-Type: application/alto-endpointcost+json 790 { 791 "meta": { 792 "cost-type": { 793 "cost-mode": "numerical", 794 "cost-metric":"lossrate" 795 } 796 }, 797 "endpoint-cost-map": { 798 "ipv4:192.0.2.2": { 799 "ipv4:192.0.2.89" : 0, 800 "ipv4:198.51.100.34": 0, 801 "ipv6:2000::1:2345:6789:abcd" : 0, 802 } 803 } 804 } 806 3.5.4. Cost-Context Specification Considerations 808 "nominal": Typically packet loss rate does not have a nominal value, 809 although some networks may specify zero losses. 811 "sla": It is RECOMMENDED that the "parameters" field of an "sla" 812 packet loss rate provides a link ("link") to the SLA definition. 814 "import": There can be multiple sources to import packet loss rate. 815 If the import is from [RFC8571] (by using unidirectional link loss), 816 it is RECOMMENDED that "parameters" provides "protocol" as a field 817 and "RFC8571" as the value; see Section 3.1.4 for discussions on 818 summing up link metrics to obtain end-to-end metrics. If the import 819 is from the IPPM framework, it is recommended that "parameters" 820 provides "protocol" as a field and "ippm" as the value; see Section 4 821 of [I-D.ietf-ippm-initial-registry] for additional fields which can 822 be specified for "ippm" in "parameters". 824 "estimation": The exact estimation method is out of the scope of this 825 document. It is RECOMMENDED that the "parameters" field of an 826 "estimation" packet loss rate metric provides a link ("link") to a 827 description of the "estimation" method. 829 4. Bandwidth Performance Metrics 831 This section introduces three bandwidth related metrics. Given a 832 specified source to a specified destination, these metrics reflect 833 the volume of traffic that the network can carry from the source to 834 the destination. 836 4.1. Cost Metric: TCP Throughput (tput) 838 4.1.1. Base Identifier 840 The base identifier for this performance metric is "tput". 842 4.1.2. Value Representation 844 The metric value type is a single 'JSONNumber' type value conforming 845 to the number specification of [RFC8259] Section 6. The number MUST 846 be non-negative. The unit is bytes per second. 848 4.1.3. Intended Semantics and Use 850 Intended Semantics: To give the throughput of a TCP flow from the 851 specified source to the specified destination. The spatial 852 aggregation level is specified in the query context (e.g., PID to 853 PID, or endpoint to endpoint). 855 Use: This metric could be used as a cost metric constraint attribute 856 or as a returned cost metric in the response. 858 Example 5: TCP throughput value on source-destination endpoint pairs 860 POST /endpointcost/lookup HTTP/1.1 861 Host: alto.example.com 862 Content-Length: TBA 863 Content-Type: application/alto-endpointcostparams+json 864 Accept: 865 application/alto-endpointcost+json,application/alto-error+json 867 { 868 "cost-type": {"cost-mode" : "numerical", 869 "cost-metric" : "tput"}, 870 "endpoints" : { 871 "srcs": [ "ipv4:192.0.2.2" ], 872 "dsts": [ 873 "ipv4:192.0.2.89", 874 "ipv4:198.51.100.34", 875 "ipv6:2000::1:2345:6789:abcd" 876 ] 877 } 878 } 880 HTTP/1.1 200 OK 881 Content-Length: TBA 882 Content-Type: application/alto-endpointcost+json 883 { 884 "meta": { 885 "cost type": { 886 "cost-mode": "numerical", 887 "cost-metric":"tput" 888 } 889 } 890 "endpoint-cost-map": { 891 "ipv4:192.0.2.2": { 892 "ipv4:192.0.2.89" : 256000, 893 "ipv4:198.51.100.34": 128000, 894 "ipv6:2000::1:2345:6789:abcd" : 428000, 895 } 896 } 898 4.1.4. Cost-Context Specification Considerations 900 "nominal": Typically TCP throughput does not have a nominal value. 902 "sla": Typically TCP throughput does not have an SLA value. 904 "import": Typically there is not a routing protocol through which one 905 can import TCP throughput. If the import is from the IPPM framework, 906 it is recommended that "parameters" provides "protocol" as a field 907 and "ippm" as the value; see Section 4 of [I-D.ietf-ippm-initial- 908 registry] for additional fields which can be specified for "ippm" in 909 "parameters". 911 "estimation": The exact estimation method is out of the scope of this 912 document. See [ProphetINFOCOM18] for a method to estimate TCP 913 throughput. It is RECOMMENDED that the "parameters" field of an 914 "estimation" TCP throughput metric provides a link ("link") to a 915 description of the "estimation" method. 917 4.2. Cost Metric: Residue Bandwidth 919 4.2.1. Base Identifier 921 The base identifier for this performance metric is "bw-residue". 923 4.2.2. Value Representation 925 The metric value type is a single 'JSONNumber' type value that is 926 non-negative. The unit of measurement is bytes per second. 928 4.2.3. Intended Semantics and Use 930 Intended Semantics: To specify spatial and temporal residual 931 bandwidth from the specified source and the specified destination. 932 The value is calculated by subtracting tunnel reservations from 933 Maximum Bandwidth (motivated from [RFC7810], Section 4.5.). The 934 spatial aggregation unit is specified in the query context (e.g., PID 935 to PID, or endpoint to endpoint). 937 Use: This metric could be used either as a cost metric constraint 938 attribute or as a returned cost metric in the response. 940 Example 7: bw-residue value on source-destination endpoint pairs 942 POST/ endpointcost/lookup HTTP/1.1 943 Host: alto.example.com 944 Content-Length: TBA 945 Content-Type: application/alto-endpointcostparams+json 946 Accept: 947 application/alto-endpointcost+json,application/alto-error+json 949 { 950 "cost-type": { "cost-mode": "numerical", 951 "cost-metric": "bw-residue"}, 952 "endpoints": { 953 "srcs": [ "ipv4 : 192.0.2.2" ], 954 "dsts": [ 955 "ipv4:192.0.2.89", 956 "ipv4:198.51.100.34", 957 "ipv6:2000::1:2345:6789:abcd" 958 ] 959 } 960 } 962 HTTP/1.1 200 OK 963 Content-Length: TBA 964 Content-Type: application/alto-endpointcost+json 965 { 966 "meta": { 967 "cost-type" { 968 "cost-mode": "numerical", 969 "cost-metric": "bw-residue" 970 } 971 }, 972 "endpoint-cost-map" { 973 "ipv4:192.0.2.2" { 974 "ipv4:192.0.2.89" : 0, 975 "ipv4:198.51.100.34": 2000, 976 "ipv6:2000::1:2345:6789:abcd": 5000, 977 } 978 } 979 } 981 4.2.4. Cost-Context Specification Considerations 983 "nominal": Typically residue bandwidth does not have a nominal value. 985 "sla": Typically residue bandwidth does not have an "sla" value. 987 "import": There can be multiple sources to import residue bandwidth. 988 If the import is from [RFC8571] (by using unidirectional residue 989 bandwidth), it is RECOMMENDED that "parameters" provides "protocol" 990 as a field and "RFC8571" as the value. The server should be 991 cognizant of issues when computing end-to-end summary statistics from 992 link statistics. For example, the min of the end-to-end path residue 993 bandwidth is the min of all links on the path. 995 "estimation": The exact estimation method is out of the scope of this 996 document. It is RECOMMENDED that the "parameters" field of an 997 "estimation" residue bandwidth metric provides a link ("link") to a 998 description of the "estimation" method. 1000 4.3. Cost Metric: Maximum Reservable Bandwidth 1002 4.3.1. Base Identifier 1004 The base identifier for this performance metric is "bw-maxres". 1006 4.3.2. Value Representation 1008 The metric value type is a single 'JSONNumber' type value that is 1009 non-negative. The unit of measurement is bytes per second. 1011 4.3.3. Intended Semantics and Use 1013 Intended Semantics: To specify spatial and temporal maximum 1014 reservable bandwidth from the specified source to the specified 1015 destination. The value is corresponding to the maximum bandwidth 1016 that can be reserved (motivated from RFC 3630 Sec. 2.5.7.). The 1017 spatial aggregation unit is specified in the query context (e.g., PID 1018 to PID, or endpoint to endpoint). 1020 Use: This metric could be used either as a cost metric constraint 1021 attribute or as a returned cost metric in the response. 1023 Example 6: bw-maxres value on source-destination endpoint pairs 1025 POST/ endpointcost/lookup HTTP/1.1 1026 Host: alto.example.com 1027 Content-Length: TBA 1028 Content-Type: application/alto-endpointcostparams+json 1029 Accept: 1030 application/alto-endpointcost+json,application/alto-error+json 1032 { 1033 "cost-type" { "cost-mode": "numerical", 1034 "cost-metric": "bw-maxres"}, 1035 "endpoints": { 1036 "srcs": [ "ipv4 : 192.0.2.2" ], 1037 "dsts": [ 1038 "ipv4:192.0.2.89", 1039 "ipv4:198.51.100.34", 1040 "ipv6:2000::1:2345:6789:abcd" 1041 ] 1042 } 1043 } 1045 HTTP/1.1 200 OK 1046 Content-Length: TBA 1047 Content-Type: application/alto-endpointcost+json 1048 { 1049 "meta": { 1050 "cost-type": { 1051 "cost-mode": "numerical", 1052 "cost-metric": "bw-maxres" 1053 } 1054 }, 1055 "endpoint-cost-map": { 1056 "ipv4:192.0.2.2" { 1057 "ipv4:192.0.2.89" : 0, 1058 "ipv4:198.51.100.34": 2000, 1059 "ipv6:2000::1:2345:6789:abcd": 5000, 1060 } 1061 } 1062 } 1064 4.3.4. Cost-Context Specification Considerations 1066 "nominal": Typically maximum reservable bandwidth does not have a 1067 nominal value. 1069 "sla": Typically maximum reservable bandwidth does not have an "sla" 1070 value. 1072 "import": There can be multiple sources to import maximum reservable 1073 bandwidth. For example, Maximum reservable bandwidth is defined by 1074 IS-IS/OSPF TE, and measures the reservable bandwidth between two 1075 directly connected IS-IS neighbors or OSPF neighbors; see Section 3.5 1076 of [RFC5305]. If the import is from [RFC8571] (by using 1077 unidirectional maximum reservable bandwidth), it is RECOMMENDED that 1078 "parameters" provides "protocol" as a field and "RFC8571" as the 1079 value. 1081 "estimation": The exact estimation method is out of the scope of this 1082 document. It is RECOMMENDED that the "parameters" field of an 1083 "estimation" maximum reservable bandwidth metric provides a link 1084 ("link") to a description of the "estimation" method. 1086 5. Operational Considerations 1088 The exact measurement infrastructure, measurement condition and 1089 computation algorithms can vary from different networks, and are 1090 outside the scope of this document. Both the ALTO server and the 1091 ALTO clients, however, need to be cognizant of the operational issues 1092 discussed below. 1094 Also, the performance metrics specified in this document are similar, 1095 in that they may use similar data sources and have similar issues in 1096 their calculation. Hence, we specify common issues unless one metric 1097 has its unique challenges. 1099 5.1. Source Considerations 1101 The addition of the "cost-source" field is to solve a key issue: An 1102 ALTO server needs data sources to compute the cost metrics described 1103 in this document and an ALTO client needs to know the data sources to 1104 better interpret the values. 1106 To avoid too fine-grained information, this document introduces 1107 "cost-source" to indicate only the high-level type of data sources: 1108 "estimation" or "sla", where "estimation" is a type of measurement 1109 data source and "sla" is a type that is more based on policy. 1111 For estimation, for example, the ALTO server may use log servers or 1112 the OAM system as its data source [RFC7971]. In particular, the cost 1113 metrics defined in this document can be computed using routing 1114 systems as the data sources. Mechanisms defined in [RFC2681], 1115 [RFC3393], [RFC7679], [RFC7680], [RFC3630], [RFC3784], [RFC7471], 1116 [RFC7810], [RFC7752] and [I-D.ietf-idr-te-pm-bgp] that allow an ALTO 1117 Server to retrieve and derive the necessary information to compute 1118 the metrics that we describe in this document. 1120 5.2. Metric Timestamp Consideration 1122 Despite the introduction of the additional cost-context information, 1123 there is no built-in field to indicate the timestamps of the data 1124 used to compute a metric. To indicate this attribute, the ALTO 1125 server SHOULD return HTTP "Last-Modified", to indicate the freshness 1126 of the data used to compute the performance metrics. 1128 If the ALTO client obtains updates through an incremental update 1129 mechanism (e.g., [ALTO SSE]), the client SHOULD assume that the 1130 metric is computed using a snapshot at the time that is approximated 1131 by the receiving time. 1133 5.3. Backward Compatibility Considerations 1135 One potential issue introduced by the optional "cost-source" field is 1136 backward compatibility. Consider that an IRD which defines two cost- 1137 types with the same "cost-mode" and "cost-metric", but one with 1138 "cost-source" being "estimation" and the other being "sla". Then an 1139 ALTO client that is not aware of the extension will not be able to 1140 distinguish between these two types. A similar issue can arise even 1141 with a single cost-type which has "cost-source" being "sla", but the 1142 backward client will ignore this field and consider the metric 1143 estimation. 1145 To address this issue, the only defined "routingcost" metric can be 1146 ONLY "estimation". 1148 5.4. Computation Considerations 1150 The metric values exposed by an ALTO server may result from 1151 additional processing on measurements from data sources to compute 1152 exposed metrics. This may involve data processing tasks such as 1153 aggregating the results across multiple systems, removing outliers, 1154 and creating additional statistics. There are two challenges on the 1155 computation of ALTO performance metrics. 1157 5.4.1. Configuration Parameters Considerations 1159 Performance metrics often depend on configuration parameters. For 1160 example, the value of packet loss rate depends on the measurement 1161 interval and varies over time. To handle this issue, an ALTO server 1162 may collect data on time periods covering the previous and current 1163 time or only collect data on present time. The ALTO server may 1164 further aggregate these data to provide an abstract and unified view 1165 that can be more useful to applications. To make the ALTO client 1166 better understand how to use these performance data, the ALTO server 1167 may provide the client with the validity period of the exposed metric 1168 values. 1170 5.4.2. Availability Considerations 1172 Applications value information relating to bandwidth availability 1173 whereas bandwidth related metrics can often be only measured at the 1174 link level. This document specifies a set of link-level bandwidth 1175 related values that may be exposed as such by an ALTO server. The 1176 server may also expose other metrics derived from their aggregation 1177 and having different levels of endpoint granularity, e.g., link 1178 endpoints or session endpoints. The metric specifications may also 1179 expose the utilized aggregation laws. 1181 6. Security Considerations 1183 The properties defined in this document present no security 1184 considerations beyond those in Section 15 of the base ALTO 1185 specification [RFC7285]. 1187 However concerns addressed in Sections "15.1 Authenticity and 1188 Integrity of ALTO Information", "15.2 Potential Undesirable Guidance 1189 from Authenticated ALTO Information" and "15.3 Confidentiality of 1190 ALTO Information" remain of utmost importance. Indeed, TE 1191 performance is a highly sensitive ISP information, therefore, sharing 1192 TE metric values in numerical mode requires full mutual confidence 1193 between the entities managing the ALTO Server and Client. Numerical 1194 TE performance information will most likely be distributed by ALTO 1195 Servers to Clients under strict and formal mutual trust agreements. 1196 On the other hand, ALTO Clients must be cognizant on the risks 1197 attached to such information that they would have acquired outside 1198 formal conditions of mutual trust. 1200 7. IANA Considerations 1202 IANA has created and now maintains the "ALTO Cost Metric Registry", 1203 listed in Section 14.2, Table 3 of [RFC7285]. This registry is 1204 located at . This document requests to add the 1206 following entries to "ALTO Cost Metric Registry". 1208 +------------+--------------------+ 1209 | Identifier | Intended Semantics | 1210 +------------+--------------------+ 1211 | delay-ow | See Section 3.1 | 1212 | delay-rt | See Section 3.2 | 1213 | delay-var | See Section 3.3 | 1214 | hopcount | See Section 3.4 | 1215 | lossrate | See Section 3.5 | 1216 | tput | See Section 4.1 | 1217 | bw-residue | See Section 4.2 | 1218 | bw-maxres | See Section 4.3 | 1219 +------------+--------------------+ 1221 This document requests the creation of the "ALTO Cost Source 1222 Registry" with the following currently defined values: 1224 +------------+-----------------------------+ 1225 | Identifier | Intended Semantics | 1226 +------------+-----------------------------+ 1227 | nominal | Values in nominal cases | 1228 | sla | Values reflecting service | 1229 | | level agreement | 1230 | import | Values from a given protocol| 1231 | estimation | Values by estimation | 1232 +------------+-----------------------------+ 1234 8. Acknowledgments 1236 The authors of this document would also like to thank Brian Trammell, 1237 Haizhou Du, Kai Gao, Lili Liu, Geng Li, Danny Alex Lachos Perez for 1238 the reviews and comments. Young Lee is an author of an earlier 1239 version of the document. 1241 9. References 1243 9.1. Normative References 1245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1246 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1247 RFC2119, March 1997, . 1250 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1251 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 1252 September 1999, . 1254 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1255 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1256 September 1999, . 1258 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1259 Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 1260 10.17487/RFC3393, November 2002, . 1263 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1264 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1265 2008, . 1267 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 1268 "Framework for TCP Throughput Testing", RFC 6349, DOI 1269 10.17487/RFC6349, August 2011, . 1272 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1273 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1274 "Application-Layer Traffic Optimization (ALTO) Protocol", 1275 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1276 . 1278 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1279 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1280 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1281 . 1283 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1284 Interchange Format", STD 90, RFC 8259, DOI 10.17487/ 1285 RFC8259, December 2017, . 1288 9.2. Informative References 1290 [ProphetINFOCOM18] 1291 Gao, K., Zhang, J., and YR. Yang, "Prophet: Fast, Accurate 1292 Throughput Prediction with Reactive Flows", IEEE INFOCOM 1293 2018 - IEEE Conference on Computer Communications 16-19 1294 April 2018, 2018. 1296 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 1297 Performance Metric Development", BCP 170, RFC 6390, DOI 1298 10.17487/RFC6390, October 2011, . 1301 [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 1302 S. Previdi, "Application-Layer Traffic Optimization (ALTO) 1303 Deployment Considerations", RFC 7971, DOI 10.17487/ 1304 RFC7971, October 2016, . 1307 Authors' Addresses 1309 Qin Wu 1310 Huawei 1311 101 Software Avenue, Yuhua District 1312 Nanjing, Jiangsu 210012 1313 China 1315 Email: bill.wu@huawei.com 1317 Y. Richard Yang 1318 Yale University 1319 51 Prospect St 1320 New Haven, CT 06520 1321 USA 1323 Email: yry@cs.yale.edu 1325 Young Lee 1326 Samsung 1327 1700 Alma Drive, Suite 500 1328 Plano, TX 75075 1329 USA 1331 Email: leeyoung@huawei.com 1333 Dhruv Dhody 1334 Huawei 1335 Leela Palace 1336 Bangalore, Karnataka 560008 1337 INDIA 1339 Email: dhruv.ietf@gmail.com 1340 Sabine Randriamasy 1341 Nokia Bell Labs 1342 Route de Villejust 1343 Nozay 91460 1344 FRANCE 1346 Email: sabine.randriamasy@nokia-bell-labs.com 1348 Luis Miguel Contreras Murillo 1349 Telefonica 1351 Email: luismiguel.contrerasmurillo@telefonica.com