idnits 2.17.1 draft-ietf-alto-performance-metrics-14.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 : ---------------------------------------------------------------------------- -- 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 (January 13, 2021) is 1170 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) -- Looks like a reference, but probably isn't: '0' on line 365 -- Looks like a reference, but probably isn't: '100' on line 359 -- Looks like a reference, but probably isn't: '1' on line 365 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 5 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: July 17, 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 January 13, 2021 16 ALTO Performance Cost Metrics 17 draft-ietf-alto-performance-metrics-14 19 Abstract 21 Cost metric is a basic concept in Application-Layer Traffic 22 Optimization (ALTO), and different applications may use different 23 cost metrics. Since the ALTO base protocol (RFC 7285) defines only a 24 single cost metric (i.e., the generic "routingcost" metric), if an 25 application wants to issue a cost map or an endpoint cost request to 26 determine the resource provider that offers better delay performance, 27 the base protocol does not define the cost metric to be used. 29 This document addresses the issue by introducing network performance 30 metrics, including network delay, jitter, packet loss rate, hop 31 count, and bandwidth. 33 There are multiple sources (e.g., estimation based on measurements or 34 service-level agreement) to derive a performance metric. This 35 document introduces an additional "cost-context" field to the ALTO 36 "cost-type" field to convey the source of a performance metric. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 42 "OPTIONAL" in this document are to be interpreted as described in BCP 43 14 [RFC2119][RFC8174] when, and only when, they appear in all 44 capitals, as shown here. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on July 17, 2021. 63 Copyright Notice 65 Copyright (c) 2021 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Performance Metric Attributes . . . . . . . . . . . . . . . . 5 82 2.1. Performance Metric Context: cost-context . . . . . . . . 6 83 2.2. Performance Metric Statistics . . . . . . . . . . . . . . 8 84 3. Packet Performance Metrics . . . . . . . . . . . . . . . . . 9 85 3.1. Cost Metric: One-Way Delay (delay-ow) . . . . . . . . . . 10 86 3.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 10 87 3.1.2. Value Representation . . . . . . . . . . . . . . . . 10 88 3.1.3. Intended Semantics and Use . . . . . . . . . . . . . 10 89 3.1.4. Cost-Context Specification Considerations . . . . . . 11 90 3.2. Cost Metric: Round-trip Delay (delay-rt) . . . . . . . . 12 91 3.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 12 92 3.2.2. Value Representation . . . . . . . . . . . . . . . . 12 93 3.2.3. Intended Semantics and Use . . . . . . . . . . . . . 12 94 3.2.4. Cost-Context Specification Considerations . . . . . . 13 95 3.3. Cost Metric: Delay Variation (delay-variation) . . . . . 14 96 3.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 14 97 3.3.2. Value Representation . . . . . . . . . . . . . . . . 14 98 3.3.3. Intended Semantics and Use . . . . . . . . . . . . . 14 99 3.3.4. Cost-Context Specification Considerations . . . . . . 15 100 3.4. Cost Metric: Hop Count (hopcount) . . . . . . . . . . . . 16 101 3.4.1. Base Identifier . . . . . . . . . . . . . . . . . . . 16 102 3.4.2. Value Representation . . . . . . . . . . . . . . . . 16 103 3.4.3. Intended Semantics and Use . . . . . . . . . . . . . 16 104 3.4.4. Cost-Context Specification Considerations . . . . . . 17 105 3.5. Cost Metric: Loss Rate (lossrate) . . . . . . . . . . . . 18 106 3.5.1. Base Identifier . . . . . . . . . . . . . . . . . . . 18 107 3.5.2. Value Representation . . . . . . . . . . . . . . . . 18 108 3.5.3. Intended Semantics and Use . . . . . . . . . . . . . 18 109 3.5.4. Cost-Context Specification Considerations . . . . . . 19 110 4. Bandwidth Performance Metrics . . . . . . . . . . . . . . . . 20 111 4.1. Cost Metric: TCP Throughput (tput) . . . . . . . . . . . 20 112 4.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 20 113 4.1.2. Value Representation . . . . . . . . . . . . . . . . 20 114 4.1.3. Intended Semantics and Use . . . . . . . . . . . . . 20 115 4.1.4. Cost-Context Specification Considerations . . . . . . 21 116 4.2. Cost Metric: Residue Bandwidth (bw-residue) . . . . . . . 22 117 4.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 22 118 4.2.2. Value Representation . . . . . . . . . . . . . . . . 22 119 4.2.3. Intended Semantics and Use . . . . . . . . . . . . . 22 120 4.2.4. Cost-Context Specification Considerations . . . . . . 23 121 4.3. Cost Metric: Maximum Reservable Bandwidth (bw-maxres) . . 24 122 4.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 24 123 4.3.2. Value Representation . . . . . . . . . . . . . . . . 24 124 4.3.3. Intended Semantics and Use . . . . . . . . . . . . . 24 125 4.3.4. Cost-Context Specification Considerations . . . . . . 25 126 5. Operational Considerations . . . . . . . . . . . . . . . . . 26 127 5.1. Source Considerations . . . . . . . . . . . . . . . . . . 26 128 5.2. Metric Timestamp Consideration . . . . . . . . . . . . . 27 129 5.3. Backward Compatibility Considerations . . . . . . . . . . 27 130 5.4. Computation Considerations . . . . . . . . . . . . . . . 27 131 5.4.1. Configuration Parameters Considerations . . . . . . . 27 132 5.4.2. Availability Considerations . . . . . . . . . . . . . 28 133 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 134 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 135 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 136 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 137 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 138 9.2. Informative References . . . . . . . . . . . . . . . . . 30 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 141 1. Introduction 143 Cost Metric is a basic concept in Application-Layer Traffic 144 Optimization (ALTO). It is used in both the ALTO cost map service 145 and the ALTO endpoint cost service in the ALTO base protocol 146 [RFC7285]. 148 Since different applications may use different cost metrics, the ALTO 149 base protocol introduces an ALTO Cost Metric Registry (Section 14.2 150 of [RFC7285]), as a systematic mechanism to allow different metrics 151 to be specified. For example, a delay-sensitive application may want 152 to use latency related metrics, and a bandwidth-sensitive application 153 may want to use bandwidth related metrics. However, the ALTO base 154 protocol has registered only a single cost metric, i.e., the generic 155 "routingcost" metric (see Sec. 14.2 of [RFC7285]); no latency or 156 bandwidth related metrics are defined. 158 This document registers a set of new cost metrics specified in 159 Table 1, to allow applications to determine "where" to connect based 160 on network performance criteria such as delay and bandwidth related 161 metrics. This document follows the guideline defined in Section 14.2 162 of the ALTO base protocol [RFC7285]) on registering ALTO cost 163 metrics. Hence it specifies the identifier, the intended semantics, 164 and the security considerations of each one of the metrics defined in 165 Table 1. 167 +--------------------------+-------------+-------------------+ 168 | Metric | Definition | Origin Example | 169 +--------------------------+-------------+-------------------+ 170 | One-way Delay | Section 3.1 | [RFC7679] | 171 | Round-trip Delay | Section 3.2 | [RFC2681] | 172 | Delay Variation | Section 3.3 | [RFC3393] | 173 | Hop Count | Section 3.4 | [RFC7285] | 174 | Loss Rate | Section 3.5 | [RFC7680] | 175 | | | | 176 | TCP Throughput | Section 4.1 | [RFC6349] | 177 | Residue Bandwidth | Section 4.2 | [RFC8570] | 178 | Max Reservable Bandwidth | Section 4.3 | [RFC5305] | 179 +------------+-----------------------------------------------+ 180 Table 1. Cost Metrics Defined in this Document. 182 The purpose of this document is to ensure proper usage of the 183 performance metrics defined in Table 1; it does not claim novelty of 184 the metrics. The "Origin Example" column of Table 1 gives an example 185 RFC that has defined each metric. 187 The performance metrics can be classified into two categories: those 188 derived from the performance of individual packets (i.e., one-way 189 delay, round-trip delay, delay variation, hop count, and loss rate), 190 and those related with bandwidth (TCP throughput, residue bandwidth, 191 and maximum reservable bandwidth). These two categories are defined 192 in Sections 3 and 4 respectively. Note that all metrics except round 193 trip delay in Table 1 are unidirectional; hence, a client will need 194 to query both directions if needed. 196 An ALTO server may provide only a subset of the metrics described in 197 this document. For example, those that are subject to privacy 198 concerns should not be provided to unauthorized ALTO clients. Hence, 199 all cost metrics defined in this document are optional and not all of 200 them need to be exposed to a given application. When an ALTO server 201 supports a cost metric defined in this document, it should announce 202 this metric in its information resource directory (IRD). 204 [RFC7285] specifies that cost values should be assumed by default as 205 JSONNumber. When defining the value representation of each metric in 206 Table 1, this document conforms to this specification, but specifies 207 additional, generic constraints on valid JSONNumbers for each metric. 208 For example, each metric in Table 1 will be specified as non-negative 209 (>= 0); Hop Count is specified to be an integer. 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 detail 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 endpoints. 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 that defines 245 the metric. 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 that 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 MUST NOT 275 announce multiple CostType with the same "cost-metric" and "cost- 276 mode". They must be placed into different information resources. 278 The "nominal" category indicates that the metric value is statically 279 configured by the underlying devices. Not all metrics have 280 reasonable "nominal" values. For example, throughput can have a 281 nominal value, which indicates the configured transmission rate of 282 the devices; latency typically does not have a nominal value. 284 The "sla" category indicates that the metric value is derived from 285 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 an "sla" metric, it is RECOMMENDED that the 288 "parameters" field provides a link to the SLA definition. 290 The "estimation" category indicates that the metric value is computed 291 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. A framework to compute estimation to performance metrics 320 A particular type of "estimation" is direct "import", which indicates 321 that the metric value is imported directly from a specific existing 322 protocol or system. Specifying "import" as the source instead of the 323 more generic "estimation" may allow better tracking of information 324 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 a large overlap with the set 328 defined in [RFC8571], in the setting of IGP traffic engineering 329 performance metrics for each link (i.e., unidirectional link delay, 330 min/max 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 multiple choices in deciding the cost-source category. 338 It is the operator of an ALTO server who chooses the category. If a 339 metric does not include a "cost-source" value, the application MUST 340 assume that the value of "cost-source" is the most generic 341 "estimation". 343 2.2. Performance Metric Statistics 345 The measurement of a performance metric often yields a set of samples 346 from an observation distribution ([Prometheus]), instead of a single 347 value. This document considers that the samples are aggregated as a 348 statistic when reported. Hence, each performance metric's identifier 349 should indicate the statistic (i.e., an aggregation operation), to 350 become -, where MUST be one of 351 the following: 353 percentile, with letter 'p' followed by a number: 355 gives the p percentile. Specifically, consider the samples coming 356 from a random variable X. The metric returns x, relative to 100, 357 such that the probability of X is less than or equal to x, i.e., 358 Prob(X <= x) = p/100. The number p MUST be a non-negative JSON 359 number in the range [0, 100] (i.e., greater than or equal to 0 and 360 less than or equal to 100). To avoid complex identifiers, the 361 number MUST NOT include the minus or the exp component (Section 6 362 of [RFC8259]). For example, delay-ow-p75 gives the 75% percentile 363 of observed one-way delay; delay-ow-p99.9 gives the 99.9% 364 percentile of delay. Note that some systems use quantile, which 365 is in the range [0, 1]. This document uses percentile to make the 366 identifier easier to read. 368 min: 370 the minimal value of the observations. 372 max: 374 the maximal value of the observations. 376 median: 378 the mid point (i.e., p50) of the observations. 380 mean: 382 the arithmetic mean value of the observations. 384 stddev: 386 the standard deviation of the observations. 388 stdvar: 390 the standard variance of the observations. 392 If a metric has no (and hence no - as well), the metric MUST 393 be considered as the 50 percentile (median). 395 3. Packet Performance Metrics 397 This section introduces ALTO network performance metrics on one way 398 delay, round trip delay, delay variation, hop count, and packet loss 399 rate. They measure the "quality of experience" of the stream of 400 packets sent from a resource provider to a resource consumer. The 401 measures of each individual packet (pkt) can include the delay from 402 the time when the packet enters the network to the time when the 403 packet leaves the network (pkt.delay); the number of network hops 404 that the packet traverses (pkt.hopcount); and whether the packet is 405 dropped before reaching the destination (pkt.dropped). The semantics 406 of the performance metrics defined in this section is that they are 407 statistics (percentiles) computed from these measures; for example, 408 the x-percentile of the one-way delay is the x-percentile of the set 409 of delays {pkt.delay} for the packets in the stream. 411 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 the spatial and temporal aggregated 428 delay of a stream of packets from the specified source and the 429 specified destination. The spatial aggregation level is specified in 430 the query 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 (i.e., a field named 487 "link") to the SLA definition, if available. 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 statistic from link 495 statistics. Another example of an import source is the IPPM 496 framework. For IPPM, it is recommended that "parameters" provides 497 "protocol" as a field and "ippm" as the value; see Section 4 of [I- 498 D.ietf-ippm-initial-registry] for additional fields which can be 499 specified for "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 of 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-variation"}, 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-variation" 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 the number of router hops computed from the routing protocols 711 originating this information. The spatial aggregation level is 712 specified in the query context (e.g., PID to PID, or endpoint to 713 endpoint). 715 Use: This metric could be used as a cost metric constraint attribute 716 or as a returned cost metric in the response. 718 Example 4: hopcount value on source-destination endpoint pairs 720 POST /endpointcost/lookup HTTP/1.1 721 Host: alto.example.com 722 Content-Length: TBA 723 Content-Type: application/alto-endpointcostparams+json 724 Accept: 725 application/alto-endpointcost+json,application/alto-error+json 727 { 728 "cost-type": {"cost-mode" : "numerical", 729 "cost-metric" : "hopcount"}, 730 "endpoints" : { 731 "srcs": [ "ipv4:192.0.2.2" ], 732 "dsts": [ 733 "ipv4:192.0.2.89", 734 "ipv4:198.51.100.34", 735 "ipv6:2000::1:2345:6789:abcd" 736 ] 737 } 738 } 740 HTTP/1.1 200 OK 741 Content-Length: TBA 742 Content-Type: application/alto-endpointcost+json 743 { 744 "meta": { 745 "cost type": { 746 "cost-mode": "numerical", 747 "cost-metric":"hopcount"} 748 } 749 }, 750 "endpoint-cost-map": { 751 "ipv4:192.0.2.2": { 752 "ipv4:192.0.2.89" : 5, 753 "ipv4:198.51.100.34": 3, 754 "ipv6:2000::1:2345:6789:abcd" : 2, 755 } 756 } 757 } 759 3.4.4. Cost-Context Specification Considerations 761 "nominal": Typically hop count does not have a nominal value. 763 "sla": Typically hop count does not have an SLA value. 765 "import": There can be multiple sources to import hop count, such as 766 from IGP routing protocols. 768 "estimation": The exact estimation method is out of the scope of this 769 document. It is RECOMMENDED that the "parameters" field of an 770 "estimation" hop count metric provides a link ("link") to a 771 description of the "estimation" method. 773 3.5. Cost Metric: Loss Rate (lossrate) 775 3.5.1. Base Identifier 777 The base identifier for this performance metric is "lossrate". 779 3.5.2. Value Representation 781 The metric value type is a single 'JSONNumber' type value conforming 782 to the number specification of [RFC8259] Section 6. The number MUST 783 be non-negative. The value represents the percentage of packet 784 losses. 786 3.5.3. Intended Semantics and Use 788 Intended Semantics: To specify spatial and temporal aggregated packet 789 loss rate from the specified source and the specified destination. 790 The spatial aggregation level is specified in the query context 791 (e.g., PID to PID, or endpoint to endpoint). 793 Use: This metric could be used as a cost metric constraint attribute 794 or as a returned cost metric in the response. 796 Example 5: Loss rate value on source-destination endpoint pairs 798 POST /endpointcost/lookup HTTP/1.1 799 Host: alto.example.com 800 Content-Length: TBA 801 Content-Type: application/alto-endpointcostparams+json 802 Accept: 803 application/alto-endpointcost+json,application/alto-error+json 805 { 806 "cost-type": {"cost-mode" : "numerical", 807 "cost-metric" : "lossrate" 808 }, 809 "endpoints" : { 810 "srcs": [ "ipv4:192.0.2.2" ], 811 "dsts": [ 812 "ipv4:192.0.2.89", 813 "ipv4:198.51.100.34", 814 "ipv6:2000::1:2345:6789:abcd" 815 ] 816 } 817 } 819 HTTP/1.1 200 OK 820 Content-Length: TBA 821 Content-Type: application/alto-endpointcost+json 822 { 823 "meta": { 824 "cost-type": { 825 "cost-mode": "numerical", 826 "cost-metric":"lossrate" 827 } 828 }, 829 "endpoint-cost-map": { 830 "ipv4:192.0.2.2": { 831 "ipv4:192.0.2.89" : 0, 832 "ipv4:198.51.100.34": 0, 833 "ipv6:2000::1:2345:6789:abcd" : 0, 834 } 835 } 836 } 838 3.5.4. Cost-Context Specification Considerations 840 "nominal": Typically packet loss rate does not have a nominal value, 841 although some networks may specify zero losses. 843 "sla": It is RECOMMENDED that the "parameters" field of an "sla" 844 packet loss rate provides a link ("link") to the SLA definition. 846 "import": There can be multiple sources to import packet loss rate. 847 If the import is from [RFC8571] (by using unidirectional link loss), 848 it is RECOMMENDED that "parameters" provides "protocol" as a field 849 and "RFC8571" as the value; see Section 3.1.4 for discussions on 850 summing up link metrics to obtain end-to-end metrics. If the import 851 is from the IPPM framework, it is recommended that "parameters" 852 provides "protocol" as a field and "ippm" as the value; see Section 4 853 of [I-D.ietf-ippm-initial-registry] for additional fields which can 854 be specified for "ippm" in "parameters". 856 "estimation": The exact estimation method is out of the scope of this 857 document. It is RECOMMENDED that the "parameters" field of an 858 "estimation" packet loss rate metric provides a link ("link") to a 859 description of the "estimation" method. 861 4. Bandwidth Performance Metrics 863 This section introduces three bandwidth related metrics. Given a 864 specified source to a specified destination, these metrics reflect 865 the volume of traffic that the network can carry from the source to 866 the destination. 868 4.1. Cost Metric: TCP Throughput (tput) 870 4.1.1. Base Identifier 872 The base identifier for this performance metric is "tput". 874 4.1.2. Value Representation 876 The metric value type is a single 'JSONNumber' type value conforming 877 to the number specification of [RFC8259] Section 6. The number MUST 878 be non-negative. The unit is bytes per second. 880 4.1.3. Intended Semantics and Use 882 Intended Semantics: To give the throughput of a TCP flow from the 883 specified source to the specified destination. The spatial 884 aggregation level is specified in the query context (e.g., PID to 885 PID, or endpoint to endpoint). 887 Use: This metric could be used as a cost metric constraint attribute 888 or as a returned cost metric in the response. 890 Example 5: TCP throughput value on source-destination endpoint pairs 892 POST /endpointcost/lookup HTTP/1.1 893 Host: alto.example.com 894 Content-Length: TBA 895 Content-Type: application/alto-endpointcostparams+json 896 Accept: 897 application/alto-endpointcost+json,application/alto-error+json 899 { 900 "cost-type": {"cost-mode" : "numerical", 901 "cost-metric" : "tput"}, 902 "endpoints" : { 903 "srcs": [ "ipv4:192.0.2.2" ], 904 "dsts": [ 905 "ipv4:192.0.2.89", 906 "ipv4:198.51.100.34", 907 "ipv6:2000::1:2345:6789:abcd" 908 ] 909 } 910 } 912 HTTP/1.1 200 OK 913 Content-Length: TBA 914 Content-Type: application/alto-endpointcost+json 915 { 916 "meta": { 917 "cost type": { 918 "cost-mode": "numerical", 919 "cost-metric":"tput" 920 } 921 } 922 "endpoint-cost-map": { 923 "ipv4:192.0.2.2": { 924 "ipv4:192.0.2.89" : 256000, 925 "ipv4:198.51.100.34": 128000, 926 "ipv6:2000::1:2345:6789:abcd" : 428000, 927 } 928 } 930 4.1.4. Cost-Context Specification Considerations 932 "nominal": Typically TCP throughput does not have a nominal value. 934 "sla": Typically TCP throughput does not have an SLA value. 936 "import": Typically there is not a routing protocol through which one 937 can import TCP throughput. If the import is from the IPPM framework, 938 it is recommended that "parameters" provides "protocol" as a field 939 and "ippm" as the value; see Section 4 of [I-D.ietf-ippm-initial- 940 registry] for additional fields which can be specified for "ippm" in 941 "parameters". 943 "estimation": The exact estimation method is out of the scope of this 944 document. See [Prophet] for a method to estimate TCP throughput. It 945 is RECOMMENDED that the "parameters" field of an "estimation" TCP 946 throughput metric provides a link ("link") to a description of the 947 "estimation" method. 949 4.2. Cost Metric: Residue Bandwidth (bw-residue) 951 4.2.1. Base Identifier 953 The base identifier for this performance metric is "bw-residue". 955 4.2.2. Value Representation 957 The metric value type is a single 'JSONNumber' type value that is 958 non-negative. The unit of measurement is bytes per second. 960 4.2.3. Intended Semantics and Use 962 Intended Semantics: To specify spatial and temporal residual 963 bandwidth from the specified source and the specified destination. 964 The value is calculated by subtracting tunnel reservations from 965 Maximum Bandwidth (motivated from [RFC8570], Section 4.5). The 966 spatial aggregation unit is specified in the query context (e.g., PID 967 to PID, or endpoint to endpoint). 969 Use: This metric could be used either as a cost metric constraint 970 attribute or as a returned cost metric in the response. 972 Example 7: bw-residue value on source-destination endpoint pairs 974 POST/ endpointcost/lookup HTTP/1.1 975 Host: alto.example.com 976 Content-Length: TBA 977 Content-Type: application/alto-endpointcostparams+json 978 Accept: 979 application/alto-endpointcost+json,application/alto-error+json 981 { 982 "cost-type": { "cost-mode": "numerical", 983 "cost-metric": "bw-residue"}, 984 "endpoints": { 985 "srcs": [ "ipv4 : 192.0.2.2" ], 986 "dsts": [ 987 "ipv4:192.0.2.89", 988 "ipv4:198.51.100.34", 989 "ipv6:2000::1:2345:6789:abcd" 990 ] 991 } 992 } 994 HTTP/1.1 200 OK 995 Content-Length: TBA 996 Content-Type: application/alto-endpointcost+json 997 { 998 "meta": { 999 "cost-type" { 1000 "cost-mode": "numerical", 1001 "cost-metric": "bw-residue" 1002 } 1003 }, 1004 "endpoint-cost-map" { 1005 "ipv4:192.0.2.2" { 1006 "ipv4:192.0.2.89" : 0, 1007 "ipv4:198.51.100.34": 2000, 1008 "ipv6:2000::1:2345:6789:abcd": 5000, 1009 } 1010 } 1011 } 1013 4.2.4. Cost-Context Specification Considerations 1015 "nominal": Typically residue bandwidth does not have a nominal value. 1017 "sla": Typically residue bandwidth does not have an "sla" value. 1019 "import": There can be multiple sources to import residue bandwidth. 1020 If the import is from [RFC8571] (by using unidirectional residue 1021 bandwidth), it is RECOMMENDED that "parameters" provides "protocol" 1022 as a field and "RFC8571" as the value. The server should be 1023 cognizant of issues when computing end-to-end summary statistics from 1024 link statistics. For example, the min of the end-to-end path residue 1025 bandwidth is the min of all links on the path. 1027 "estimation": The exact estimation method is out of the scope of this 1028 document. It is RECOMMENDED that the "parameters" field of an 1029 "estimation" residue bandwidth metric provides a link ("link") to a 1030 description of the "estimation" method. 1032 4.3. Cost Metric: Maximum Reservable Bandwidth (bw-maxres) 1034 4.3.1. Base Identifier 1036 The base identifier for this performance metric is "bw-maxres". 1038 4.3.2. Value Representation 1040 The metric value type is a single 'JSONNumber' type value that is 1041 non-negative. The unit of measurement is bytes per second. 1043 4.3.3. Intended Semantics and Use 1045 Intended Semantics: To specify spatial and temporal maximum 1046 reservable bandwidth from the specified source to the specified 1047 destination. The value corresponds to the maximum bandwidth that can 1048 be reserved (motivated from [RFC3630] Section 2.5.7). The spatial 1049 aggregation unit is specified in the query context (e.g., PID to PID, 1050 or endpoint to endpoint). 1052 Use: This metric could be used either as a cost metric constraint 1053 attribute or as a returned cost metric in the response. 1055 Example 6: bw-maxres value on source-destination endpoint pairs 1057 POST/ endpointcost/lookup HTTP/1.1 1058 Host: alto.example.com 1059 Content-Length: TBA 1060 Content-Type: application/alto-endpointcostparams+json 1061 Accept: 1062 application/alto-endpointcost+json,application/alto-error+json 1064 { 1065 "cost-type" { "cost-mode": "numerical", 1066 "cost-metric": "bw-maxres"}, 1067 "endpoints": { 1068 "srcs": [ "ipv4 : 192.0.2.2" ], 1069 "dsts": [ 1070 "ipv4:192.0.2.89", 1071 "ipv4:198.51.100.34", 1072 "ipv6:2000::1:2345:6789:abcd" 1073 ] 1074 } 1075 } 1077 HTTP/1.1 200 OK 1078 Content-Length: TBA 1079 Content-Type: application/alto-endpointcost+json 1080 { 1081 "meta": { 1082 "cost-type": { 1083 "cost-mode": "numerical", 1084 "cost-metric": "bw-maxres" 1085 } 1086 }, 1087 "endpoint-cost-map": { 1088 "ipv4:192.0.2.2" { 1089 "ipv4:192.0.2.89" : 0, 1090 "ipv4:198.51.100.34": 2000, 1091 "ipv6:2000::1:2345:6789:abcd": 5000, 1092 } 1093 } 1094 } 1096 4.3.4. Cost-Context Specification Considerations 1098 "nominal": Typically maximum reservable bandwidth does not have a 1099 nominal value. 1101 "sla": Typically maximum reservable bandwidth does not have an "sla" 1102 value. 1104 "import": There can be multiple sources to import maximum reservable 1105 bandwidth. For example, Maximum reservable bandwidth is defined by 1106 IS-IS/OSPF TE, and measures the reservable bandwidth between two 1107 directly connected IS-IS neighbors or OSPF neighbors; see Section 3.5 1108 of [RFC5305]. If the import is from [RFC8571] (by using 1109 unidirectional maximum reservable bandwidth), it is RECOMMENDED that 1110 "parameters" provides "protocol" as a field and "RFC8571" as the 1111 value. 1113 "estimation": The exact estimation method is out of the scope of this 1114 document. It is RECOMMENDED that the "parameters" field of an 1115 "estimation" maximum reservable bandwidth metric provides a link 1116 ("link") to a description of the "estimation" method. 1118 5. Operational Considerations 1120 The exact measurement infrastructure, measurement condition, and 1121 computation algorithms can vary from different networks, and are 1122 outside the scope of this document. Both the ALTO server and the 1123 ALTO clients, however, need to be cognizant of the operational issues 1124 discussed below. 1126 Also, the performance metrics specified in this document are similar, 1127 in that they may use similar data sources and have similar issues in 1128 their calculation. Hence, we specify common issues unless one metric 1129 has its unique challenges. 1131 5.1. Source Considerations 1133 The addition of the "cost-source" field is to solve a key issue: An 1134 ALTO server needs data sources to compute the cost metrics described 1135 in this document, and an ALTO client needs to know the data sources 1136 to better interpret the values. 1138 To avoid too fine-grained information, this document introduces 1139 "cost-source" to indicate only the high-level type of data sources: 1140 "estimation" or "sla", where "estimation" is a type of measurement 1141 data source, and "sla" is a type that is more based on policy. 1143 For estimation, for example, the ALTO server may use log servers or 1144 the OAM system as its data source as recommended by [RFC7971]. In 1145 particular, the cost metrics defined in this document can be computed 1146 using routing systems as the data sources. 1148 5.2. Metric Timestamp Consideration 1150 Despite the introduction of the additional cost-context information, 1151 the metrics do not have a field to indicate the timestamps of the 1152 data used to compute the metrics. To indicate this attribute, the 1153 ALTO server SHOULD return HTTP "Last-Modified", to indicate the 1154 freshness of the data used to compute the performance metrics. 1156 If the ALTO client obtains updates through an incremental update 1157 mechanism [RFC8895]), the client SHOULD assume that the metric is 1158 computed using a snapshot at the time that is approximated by the 1159 receiving 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, whose "cost-source" is "sla": an ALTO client 1170 that is not aware of this extension will ignore this field and 1171 consider the metric 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 measured only 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 using different levels of endpoint granularity, e.g., link endpoints 1206 or session endpoints. The metric specifications may also expose the 1207 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 the ALTO client. 1222 ALTO servers will most likely distribute numerical TE performance to 1223 ALTO clients under strict and formal mutual trust agreements. On the 1224 other hand, ALTO clients must be cognizant on the risks attached to 1225 such information that they would have acquired outside formal 1226 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 This document requests the creation of the "ALTO Cost Source 1250 Registry" with the following currently defined values: 1252 +------------+-----------------------------+ 1253 | Identifier | Intended Semantics | 1254 +------------+-----------------------------+ 1255 | nominal | Values in nominal cases | 1256 | sla | Values reflecting service | 1257 | | level agreement | 1258 | import | Values from a given protocol| 1259 | estimation | Values by estimation | 1260 +------------+-----------------------------+ 1262 8. Acknowledgments 1264 The authors of this document would also like to thank Brian Trammell, 1265 Haizhou Du, Kai Gao, Lili Liu, Geng Li, Danny Alex Lachos Perez for 1266 the reviews and comments. 1268 9. References 1270 9.1. Normative References 1272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1273 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1274 RFC2119, March 1997, . 1277 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 1278 Performance Metric Development", BCP 170, RFC 6390, DOI 1279 10.17487/RFC6390, October 2011, . 1282 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1283 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1284 "Application-Layer Traffic Optimization (ALTO) Protocol", 1285 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1286 . 1288 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1289 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1290 May 2017, . 1292 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1293 Interchange Format", STD 90, RFC 8259, DOI 10.17487/ 1294 RFC8259, December 2017, . 1297 [RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic 1298 Optimization (ALTO) Incremental Updates Using Server-Sent 1299 Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November 1300 2020, . 1302 9.2. Informative References 1304 [I-D.ietf-ippm-initial-registry] 1305 Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, 1306 "Initial Performance Metrics Registry Entries", draft- 1307 ietf-ippm-initial-registry-16 (work in progress), March 1308 2020. 1310 [Prometheus] 1311 Volz, J. and B. Rabenstein, "Prometheus: A Next-Generation 1312 Monitoring System", 2015. 1314 [Prophet] Gao, K., Zhang, J., and YR. Yang, "Prophet: Fast, Accurate 1315 Throughput Prediction with Reactive Flows", ACM/IEEE 1316 Transactions on Networking July, 2020. 1318 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1319 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1320 September 1999, . 1322 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1323 Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 1324 10.17487/RFC3393, November 2002, . 1327 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1328 (TE) Extensions to OSPF Version 2", RFC 3630, DOI 1329 10.17487/RFC3630, September 2003, . 1332 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1333 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1334 2008, . 1336 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1337 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1338 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1339 . 1341 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 1342 "Framework for TCP Throughput Testing", RFC 6349, DOI 1343 10.17487/RFC6349, August 2011, . 1346 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1347 Ed., "A One-Way Delay Metric for IP Performance Metrics 1348 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 1349 2016, . 1351 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1352 Ed., "A One-Way Loss Metric for IP Performance Metrics 1353 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1354 2016, . 1356 [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 1357 S. Previdi, "Application-Layer Traffic Optimization (ALTO) 1358 Deployment Considerations", RFC 7971, DOI 10.17487/ 1359 RFC7971, October 2016, . 1362 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1363 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1364 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1365 2019, . 1367 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 1368 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 1369 IGP Traffic Engineering Performance Metric Extensions", 1370 RFC 8571, DOI 10.17487/RFC8571, March 2019, 1371 . 1373 Authors' Addresses 1375 Qin Wu 1376 Huawei 1377 101 Software Avenue, Yuhua District 1378 Nanjing, Jiangsu 210012 1379 CHINA 1381 Email: bill.wu@huawei.com 1383 Y. Richard Yang 1384 Yale University 1385 51 Prospect St 1386 New Haven, CT 06520 1387 USA 1389 Email: yry@cs.yale.edu 1391 Young Lee 1392 Samsung 1393 1700 Alma Drive, Suite 500 1394 Plano, TX 75075 1395 USA 1397 Email: young.lee@gmail.com 1399 Dhruv Dhody 1400 Huawei 1401 Leela Palace 1402 Bangalore, Karnataka 560008 1403 INDIA 1405 Email: dhruv.ietf@gmail.com 1407 Sabine Randriamasy 1408 Nokia Bell Labs 1409 Route de Villejust 1410 Nozay 91460 1411 FRANCE 1413 Email: sabine.randriamasy@nokia-bell-labs.com 1414 Luis Miguel Contreras Murillo 1415 Telefonica 1416 Madrid 1417 SPAIN 1419 Email: luismiguel.contrerasmurillo@telefonica.com