idnits 2.17.1 draft-ietf-alto-performance-metrics-15.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 (February 3, 2021) is 1178 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 368 -- Looks like a reference, but probably isn't: '100' on line 362 -- Looks like a reference, but probably isn't: '1' on line 368 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: August 7, 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 February 3, 2021 16 ALTO Performance Cost Metrics 17 draft-ietf-alto-performance-metrics-15 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 August 7, 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 . . . . . . 12 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 . . . . . . 14 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 . . . . . . 16 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 . . . . . . 18 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: Residual Bandwidth (bw-residual) . . . . . . 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 | Residual 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, residual 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 352 ::= [ '-' ] 354 where MUST be one of the following: 356 percentile, with letter 'p' followed by a number: 358 gives the p percentile. Specifically, consider the samples coming 359 from a random variable X. The metric returns x, relative to 100, 360 such that the probability of X is less than or equal to x, i.e., 361 Prob(X <= x) = p/100. The number p MUST be a non-negative JSON 362 number in the range [0, 100] (i.e., greater than or equal to 0 and 363 less than or equal to 100). To avoid complex identifiers, the 364 number MUST NOT include the minus or the exp component (Section 6 365 of [RFC8259]). For example, delay-ow-p75 gives the 75% percentile 366 of observed one-way delay; delay-ow-p99.9 gives the 99.9% 367 percentile of delay. Note that some systems use quantile, which 368 is in the range [0, 1]. This document uses percentile to make the 369 identifier easier to read. 371 min: 373 the minimal value of the observations. 375 max: 377 the maximal value of the observations. 379 median: 381 the mid point (i.e., p50) of the observations. 383 mean: 385 the arithmetic mean value of the observations. 387 stddev: 389 the standard deviation of the observations. 391 stdvar: 393 the standard variance of the observations. 395 If a metric has no (i.e., does not include 396 '-' ), the metric MUST be considered as the 50 percentile 397 (median). 399 3. Packet Performance Metrics 401 This section introduces ALTO network performance metrics on one way 402 delay, round trip delay, delay variation, hop count, and packet loss 403 rate. They measure the "quality of experience" of the stream of 404 packets sent from a resource provider to a resource consumer. The 405 measures of each individual packet (pkt) can include the delay from 406 the time when the packet enters the network to the time when the 407 packet leaves the network (pkt.delay); the number of network hops 408 that the packet traverses (pkt.hopcount); and whether the packet is 409 dropped before reaching the destination (pkt.dropped). The semantics 410 of the performance metrics defined in this section is that they are 411 statistics (percentiles) computed from these measures; for example, 412 the x-percentile of the one-way delay is the x-percentile of the set 413 of delays {pkt.delay} for the packets in the stream. 415 3.1. Cost Metric: One-Way Delay (delay-ow) 417 3.1.1. Base Identifier 419 The base identifier for this performance metric is "delay-ow". 421 3.1.2. Value Representation 423 The metric value type is a single 'JSONNumber' type value conforming 424 to the number specification of [RFC8259] Section 6. The unit is 425 expressed in milliseconds. Hence, the number can be a floating point 426 number to express delay that is smaller than milliseconds. The 427 number MUST be non-negative. 429 3.1.3. Intended Semantics and Use 431 Intended Semantics: To specify the spatial and temporal aggregated 432 delay of a stream of packets from the specified source and the 433 specified destination. The spatial aggregation level is specified in 434 the query context (e.g., PID to PID, or endpoint to endpoint). 436 Use: This metric could be used as a cost metric constraint attribute 437 or as a returned cost metric in the response. 439 Example 1: Delay value on source-destination endpoint pairs 441 POST /endpointcost/lookup HTTP/1.1 442 Host: alto.example.com 443 Content-Length: TBA 444 Content-Type: application/alto-endpointcostparams+json 445 Accept: 446 application/alto-endpointcost+json,application/alto-error+json 448 { 449 "cost-type": {"cost-mode" : "numerical", 450 "cost-metric" : "delay-ow"}, 451 "endpoints" : { 452 "srcs": [ "ipv4:192.0.2.2" ], 453 "dsts": [ 454 "ipv4:192.0.2.89", 455 "ipv4:198.51.100.34", 456 "ipv6:2001:db8::1234:5678" 457 ] 458 } 459 } 461 HTTP/1.1 200 OK 462 Content-Length: TBA 463 Content-Type: application/alto-endpointcost+json 464 { 465 "meta" :{ 466 "cost-type": {"cost-mode" : "numerical", 467 "cost-metric" : "delay-ow" 468 } 469 }, 470 "endpoint-cost-map" : { 471 "ipv4:192.0.2.2": { 472 "ipv4:192.0.2.89" : 10, 473 "ipv4:198.51.100.34" : 20, 474 "ipv6:2001:db8::1234:5678" : 30, 475 } 476 } 477 } 479 Comment: Since the "cost-type" does not include the "cost-source" 480 field, the values are based on "estimation". Since the identifier 481 does not include the - component, the values will 482 represent median values. 484 3.1.4. Cost-Context Specification Considerations 486 "nominal": Typically network one-way delay does not have a nominal 487 value. 489 "sla": Many networks provide delay in their application-level service 490 level agreements. It is RECOMMENDED that the "parameters" field of 491 an "sla" one-way delay metric provides a link (i.e., a field named 492 "link") to the SLA definition, if available. 494 "import": There can be multiple sources to import one-way delay. For 495 example, if the import is from [RFC8571] (by using unidirectional 496 link delay, min/max unidirectional link delay), it is RECOMMENDED 497 that "parameters" provides "protocol" as a field and "RFC8571" as the 498 value. During import, the server should be cognizant of potential 499 issues when computing an end-to-end summary statistic from link 500 statistics. Another example of an import source is the IPPM 501 framework. For IPPM, it is recommended that "parameters" provides 502 "protocol" as a field and "ippm" as the value; see Section 4 of [I- 503 D.ietf-ippm-initial-registry] for additional fields which can be 504 specified for "ippm" in "parameters". 506 "estimation": The exact estimation method is out of the scope of this 507 document. It is RECOMMENDED that the "parameters" field of an 508 "estimation" one-way delay metric provides a link ("link") to a 509 description of the "estimation" method. 511 3.2. Cost Metric: Round-trip Delay (delay-rt) 513 3.2.1. Base Identifier 515 The base identifier for this performance metric is "delay-rt". 517 3.2.2. Value Representation 519 The metric value type is a single 'JSONNumber' type value conforming 520 to the number specification of [RFC8259] Section 6. The number MUST 521 be non-negative. The unit is expressed in milliseconds. 523 3.2.3. Intended Semantics and Use 525 Intended Semantics: To specify spatial and temporal aggregated round- 526 trip delay between the specified source and specified destination. 527 The spatial aggregation level is specified in the query context 528 (e.g., PID to PID, or endpoint to endpoint). 530 Note that it is possible for a client to query two one-way delays and 531 then compute the round-trip delay. The server should be cognizant of 532 the consistency of values. 534 Use: This metric could be used either as a cost metric constraint 535 attribute or as a returned cost metric in the response. 537 Example 2: Round-trip Delay of source-destination endpoint pairs 539 POST /endpointcost/lookup HTTP/1.1 540 Host: alto.example.com 541 Content-Length: TBA 542 Content-Type: application/alto-endpointcostparams+json 543 Accept: 544 application/alto-endpointcost+json,application/alto-error+json 546 { 547 "cost-type": {"cost-mode" : "numerical", 548 "cost-metric" : "delay-rt"}, 549 "endpoints" : { 550 "srcs": [ "ipv4:192.0.2.2" ], 551 "dsts": [ 552 "ipv4:192.0.2.89", 553 "ipv4:198.51.100.34", 554 "ipv6:2001:db8::1234:5678" 555 ] 556 } 557 } 559 HTTP/1.1 200 OK 560 Content-Length: TBA 561 Content-Type: application/alto-endpointcost+json 562 { 563 "meta" :{ 564 "cost-type": {"cost-mode" : "numerical", 565 "cost-metric" : "delay-rt" 566 } 567 }, 568 "endpoint-cost-map" : { 569 "ipv4:192.0.2.2": { 570 "ipv4:192.0.2.89" : 4, 571 "ipv4:198.51.100.34" : 3, 572 "ipv6:2001:db8::1234:5678" : 2, 573 } 574 } 575 } 577 3.2.4. Cost-Context Specification Considerations 579 "nominal": Typically network round-trip delay does not have a nominal 580 value. 582 "sla": It is RECOMMENDED that the "parameters" field of an "sla" 583 round-trip delay metric provides a link ("link") to the SLA 584 definition. 586 "import": There can be multiple sources to import round-trip delay. 587 If the import is from [RFC8571] (by using unidirectional link delay, 588 min/max unidirectional link delay), it is RECOMMENDED that 589 "parameters" provides "protocol" as a field and "RFC8571" as the 590 value; see Section 3.1.4 for discussions on summing up link metrics 591 to obtain end-to-end metrics. If the import is from the IPPM 592 framework, it is recommended that "parameters" provides "protocol" as 593 a field and "ippm" as the value; see Section 4 of [I-D.ietf-ippm- 594 initial-registry] for additional fields which can be specified for 595 "ippm" in "parameters". 597 "estimation": The exact estimation method is out of the scope of this 598 document. It is RECOMMENDED that the "parameters" field of an 599 "estimation" round-trip delay metric provides a link ("link") to a 600 description of the "estimation" method. 602 3.3. Cost Metric: Delay Variation (delay-variation) 604 3.3.1. Base Identifier 606 The base identifier for this performance metric is "delay-variation". 608 3.3.2. Value Representation 610 The metric value type is a single 'JSONNumber' type value conforming 611 to the number specification of [RFC8259] Section 6. The number MUST 612 be non-negative. The unit is expressed in milliseconds. 614 3.3.3. Intended Semantics and Use 616 Intended Semantics: To specify spatial and temporal aggregated delay 617 variation (also called delay jitter)) with respect to the minimum 618 delay observed on the stream over the specified source and 619 destination. The spatial aggregation level is specified in the query 620 context (e.g., PID to PID, or endpoint to endpoint). 622 Note that in statistics, variations are typically evaluated by the 623 distance from samples relative to the mean. In networking context, 624 it is more commonly defined from samples relative to the min. This 625 definition follows the networking convention. 627 Use: This metric could be used either as a cost metric constraint 628 attribute or as a returned cost metric in the response. 630 Example 3: Delay variation value on source-destination endpoint pairs 632 POST /endpointcost/lookup HTTP/1.1 633 Host: alto.example.com 634 Content-Length: TBA 635 Content-Type: application/alto-endpointcostparams+json 636 Accept: 637 application/alto-endpointcost+json,application/alto-error+json 639 { 640 "cost-type": {"cost-mode" : "numerical", 641 "cost-metric" : "delay-variation"}, 642 "endpoints" : { 643 "srcs": [ "ipv4:192.0.2.2" ], 644 "dsts": [ 645 "ipv4:192.0.2.89", 646 "ipv4:198.51.100.34", 647 "ipv6:2001:db8::1234:5678" 648 ] 649 } 650 } 651 HTTP/1.1 200 OK 652 Content-Length: TBA 653 Content-Type: application/alto-endpointcost+json 654 { 655 "meta": { 656 "cost type": { 657 "cost-mode": "numerical", 658 "cost-metric":"delay-variation" 659 } 660 }, 661 "endpoint-cost-map": { 662 "ipv4:192.0.2.2": { 663 "ipv4:192.0.2.89" : 0 664 "ipv4:198.51.100.34" : 1 665 "ipv6:2001:db8::1234:5678" : 5 666 } 667 } 668 } 670 3.3.4. Cost-Context Specification Considerations 672 "nominal": Typically network delay variation does not have a nominal 673 value. 675 "sla": It is RECOMMENDED that the "parameters" field of an "sla" 676 delay variation metric provides a link ("link") to the SLA 677 definition. 679 "import": There can be multiple sources to import delay variation. 680 If the import is from [RFC8571] (by using unidirectional delay 681 variation), it is RECOMMENDED that "parameters" provides "protocol" 682 as a field and "RFC8571" as the value; see Section 3.1.4 for 683 discussions on summing up link metrics to obtain end-to-end metrics. 684 If the import is from the IPPM framework, it is recommended that 685 "parameters" provides "protocol" as a field and "ippm" as the value; 686 see Section 4 of [I-D.ietf-ippm-initial-registry] for additional 687 fields which can be specified for "ippm" in "parameters". 689 "estimation": The exact estimation method is out of the scope of this 690 document. It is RECOMMENDED that the "parameters" field of an 691 "estimation" delay variation metric provides a link ("link") to a 692 description of the "estimation" method. 694 3.4. Cost Metric: Hop Count (hopcount) 696 The metric hopcount is mentioned in [RFC7285] Section 9.2.3 as an 697 example. This section further clarifies its properties. 699 3.4.1. Base Identifier 701 The base identifier for this performance metric is "hopcount". 703 3.4.2. Value Representation 705 The metric value type is a single 'JSONNumber' type value conforming 706 to the number specification of [RFC8259] Section 6. The number MUST 707 be a non-negative integer (greater than or equal to 0). The value 708 represents the number of hops. 710 3.4.3. Intended Semantics and Use 712 Intended Semantics: To specify the number of hops in the path from 713 the specified source to the specified destination. The hop count is 714 a basic measurement of distance in a network and can be exposed as 715 the number of router hops computed from the routing protocols 716 originating this information. The spatial aggregation level is 717 specified in the query context (e.g., PID to PID, or endpoint to 718 endpoint). 720 Use: This metric could be used as a cost metric constraint attribute 721 or as a returned cost metric in the response. 723 Example 4: hopcount value on source-destination endpoint pairs 725 POST /endpointcost/lookup HTTP/1.1 726 Host: alto.example.com 727 Content-Length: TBA 728 Content-Type: application/alto-endpointcostparams+json 729 Accept: 730 application/alto-endpointcost+json,application/alto-error+json 732 { 733 "cost-type": {"cost-mode" : "numerical", 734 "cost-metric" : "hopcount"}, 735 "endpoints" : { 736 "srcs": [ "ipv4:192.0.2.2" ], 737 "dsts": [ 738 "ipv4:192.0.2.89", 739 "ipv4:198.51.100.34", 740 "ipv6:2001:db8::1234:5678" 741 ] 742 } 743 } 745 HTTP/1.1 200 OK 746 Content-Length: TBA 747 Content-Type: application/alto-endpointcost+json 748 { 749 "meta": { 750 "cost type": { 751 "cost-mode": "numerical", 752 "cost-metric":"hopcount"} 753 } 754 }, 755 "endpoint-cost-map": { 756 "ipv4:192.0.2.2": { 757 "ipv4:192.0.2.89" : 5, 758 "ipv4:198.51.100.34": 3, 759 "ipv6:2001:db8::1234:5678" : 2, 760 } 761 } 762 } 764 3.4.4. Cost-Context Specification Considerations 766 "nominal": Typically hop count does not have a nominal value. 768 "sla": Typically hop count does not have an SLA value. 770 "import": There can be multiple sources to import hop count, such as 771 from IGP routing protocols. 773 "estimation": The exact estimation method is out of the scope of this 774 document. It is RECOMMENDED that the "parameters" field of an 775 "estimation" hop count metric provides a link ("link") to a 776 description of the "estimation" method. 778 3.5. Cost Metric: Loss Rate (lossrate) 780 3.5.1. Base Identifier 782 The base identifier for this performance metric is "lossrate". 784 3.5.2. Value Representation 786 The metric value type is a single 'JSONNumber' type value conforming 787 to the number specification of [RFC8259] Section 6. The number MUST 788 be non-negative. The value represents the percentage of packet 789 losses. 791 3.5.3. Intended Semantics and Use 793 Intended Semantics: To specify spatial and temporal aggregated packet 794 loss rate from the specified source and the specified destination. 795 The spatial aggregation level is specified in the query context 796 (e.g., PID to PID, or endpoint to endpoint). 798 Use: This metric could be used as a cost metric constraint attribute 799 or as a returned cost metric in the response. 801 Example 5: Loss rate value on source-destination endpoint pairs 803 POST /endpointcost/lookup HTTP/1.1 804 Host: alto.example.com 805 Content-Length: TBA 806 Content-Type: application/alto-endpointcostparams+json 807 Accept: 808 application/alto-endpointcost+json,application/alto-error+json 810 { 811 "cost-type": {"cost-mode" : "numerical", 812 "cost-metric" : "lossrate" 813 }, 814 "endpoints" : { 815 "srcs": [ "ipv4:192.0.2.2" ], 816 "dsts": [ 817 "ipv4:192.0.2.89", 818 "ipv4:198.51.100.34", 819 "ipv6:2001:db8::1234:5678" 820 ] 821 } 822 } 824 HTTP/1.1 200 OK 825 Content-Length: TBA 826 Content-Type: application/alto-endpointcost+json 827 { 828 "meta": { 829 "cost-type": { 830 "cost-mode": "numerical", 831 "cost-metric":"lossrate" 832 } 833 }, 834 "endpoint-cost-map": { 835 "ipv4:192.0.2.2": { 836 "ipv4:192.0.2.89" : 0, 837 "ipv4:198.51.100.34": 0, 838 "ipv6:2001:db8::1234:5678" : 0, 839 } 840 } 841 } 843 3.5.4. Cost-Context Specification Considerations 845 "nominal": Typically packet loss rate does not have a nominal value, 846 although some networks may specify zero losses. 848 "sla": It is RECOMMENDED that the "parameters" field of an "sla" 849 packet loss rate provides a link ("link") to the SLA definition. 851 "import": There can be multiple sources to import packet loss rate. 852 If the import is from [RFC8571] (by using unidirectional link loss), 853 it is RECOMMENDED that "parameters" provides "protocol" as a field 854 and "RFC8571" as the value; see Section 3.1.4 for discussions on 855 summing up link metrics to obtain end-to-end metrics. If the import 856 is from the IPPM framework, it is recommended that "parameters" 857 provides "protocol" as a field and "ippm" as the value; see Section 4 858 of [I-D.ietf-ippm-initial-registry] for additional fields which can 859 be specified for "ippm" in "parameters". 861 "estimation": The exact estimation method is out of the scope of this 862 document. It is RECOMMENDED that the "parameters" field of an 863 "estimation" packet loss rate metric provides a link ("link") to a 864 description of the "estimation" method. 866 4. Bandwidth Performance Metrics 868 This section introduces three bandwidth related metrics. Given a 869 specified source to a specified destination, these metrics reflect 870 the volume of traffic that the network can carry from the source to 871 the destination. 873 4.1. Cost Metric: TCP Throughput (tput) 875 4.1.1. Base Identifier 877 The base identifier for this performance metric is "tput". 879 4.1.2. Value Representation 881 The metric value type is a single 'JSONNumber' type value conforming 882 to the number specification of [RFC8259] Section 6. The number MUST 883 be non-negative. The unit is bytes per second. 885 4.1.3. Intended Semantics and Use 887 Intended Semantics: To give the throughput of a TCP flow from the 888 specified source to the specified destination. The spatial 889 aggregation level is specified in the query context (e.g., PID to 890 PID, or endpoint to endpoint). 892 Use: This metric could be used as a cost metric constraint attribute 893 or as a returned cost metric in the response. 895 Example 5: TCP throughput value on source-destination endpoint pairs 897 POST /endpointcost/lookup HTTP/1.1 898 Host: alto.example.com 899 Content-Length: TBA 900 Content-Type: application/alto-endpointcostparams+json 901 Accept: 902 application/alto-endpointcost+json,application/alto-error+json 904 { 905 "cost-type": {"cost-mode" : "numerical", 906 "cost-metric" : "tput"}, 907 "endpoints" : { 908 "srcs": [ "ipv4:192.0.2.2" ], 909 "dsts": [ 910 "ipv4:192.0.2.89", 911 "ipv4:198.51.100.34", 912 "ipv6:2001:db8::1234:5678" 913 ] 914 } 915 } 917 HTTP/1.1 200 OK 918 Content-Length: TBA 919 Content-Type: application/alto-endpointcost+json 920 { 921 "meta": { 922 "cost type": { 923 "cost-mode": "numerical", 924 "cost-metric":"tput" 925 } 926 } 927 "endpoint-cost-map": { 928 "ipv4:192.0.2.2": { 929 "ipv4:192.0.2.89" : 256000, 930 "ipv4:198.51.100.34": 128000, 931 "ipv6:2001:db8::1234:5678" : 428000, 932 } 933 } 935 4.1.4. Cost-Context Specification Considerations 937 "nominal": Typically TCP throughput does not have a nominal value. 939 "sla": Typically TCP throughput does not have an SLA value. 941 "import": Typically there is not a routing protocol through which one 942 can import TCP throughput. If the import is from the IPPM framework, 943 it is recommended that "parameters" provides "protocol" as a field 944 and "ippm" as the value; see Section 4 of [I-D.ietf-ippm-initial- 945 registry] for additional fields which can be specified for "ippm" in 946 "parameters". 948 "estimation": The exact estimation method is out of the scope of this 949 document. See [Prophet] for a method to estimate TCP throughput. It 950 is RECOMMENDED that the "parameters" field of an "estimation" TCP 951 throughput metric provides a link ("link") to a description of the 952 "estimation" method. 954 4.2. Cost Metric: Residual Bandwidth (bw-residual) 956 4.2.1. Base Identifier 958 The base identifier for this performance metric is "bw-residual". 960 4.2.2. Value Representation 962 The metric value type is a single 'JSONNumber' type value that is 963 non-negative. The unit of measurement is bytes per second. 965 4.2.3. Intended Semantics and Use 967 Intended Semantics: To specify spatial and temporal residual 968 bandwidth from the specified source and the specified destination. 969 The value is calculated by subtracting tunnel reservations from 970 Maximum Bandwidth (motivated from [RFC8570], Section 4.5). The 971 spatial aggregation unit is specified in the query context (e.g., PID 972 to PID, or endpoint to endpoint). 974 Use: This metric could be used either as a cost metric constraint 975 attribute or as a returned cost metric in the response. 977 Example 7: bw-residual value on source-destination endpoint pairs 979 POST/ endpointcost/lookup HTTP/1.1 980 Host: alto.example.com 981 Content-Length: TBA 982 Content-Type: application/alto-endpointcostparams+json 983 Accept: 984 application/alto-endpointcost+json,application/alto-error+json 986 { 987 "cost-type": { "cost-mode": "numerical", 988 "cost-metric": "bw-residual"}, 989 "endpoints": { 990 "srcs": [ "ipv4 : 192.0.2.2" ], 991 "dsts": [ 992 "ipv4:192.0.2.89", 993 "ipv4:198.51.100.34", 994 "ipv6:2001:db8::1234:5678" 995 ] 996 } 997 } 999 HTTP/1.1 200 OK 1000 Content-Length: TBA 1001 Content-Type: application/alto-endpointcost+json 1002 { 1003 "meta": { 1004 "cost-type" { 1005 "cost-mode": "numerical", 1006 "cost-metric": "bw-residual" 1007 } 1008 }, 1009 "endpoint-cost-map" { 1010 "ipv4:192.0.2.2" { 1011 "ipv4:192.0.2.89" : 0, 1012 "ipv4:198.51.100.34": 2000, 1013 "ipv6:2001:db8::1234:5678" : 5000, 1014 } 1015 } 1016 } 1018 4.2.4. Cost-Context Specification Considerations 1020 "nominal": Typically residual bandwidth does not have a nominal 1021 value. 1023 "sla": Typically residual bandwidth does not have an "sla" value. 1025 "import": There can be multiple sources to import residual bandwidth. 1026 If the import is from [RFC8571] (by using unidirectional residual 1027 bandwidth), it is RECOMMENDED that "parameters" provides "protocol" 1028 as a field and "RFC8571" as the value. The server should be 1029 cognizant of issues when computing end-to-end summary statistics from 1030 link statistics. For example, the min of the end-to-end path 1031 residual bandwidth is the min of all links on the path. 1033 "estimation": The exact estimation method is out of the scope of this 1034 document. It is RECOMMENDED that the "parameters" field of an 1035 "estimation" residual bandwidth metric provides a link ("link") to a 1036 description of the "estimation" method. 1038 4.3. Cost Metric: Maximum Reservable Bandwidth (bw-maxres) 1040 4.3.1. Base Identifier 1042 The base identifier for this performance metric is "bw-maxres". 1044 4.3.2. Value Representation 1046 The metric value type is a single 'JSONNumber' type value that is 1047 non-negative. The unit of measurement is bytes per second. 1049 4.3.3. Intended Semantics and Use 1051 Intended Semantics: To specify spatial and temporal maximum 1052 reservable bandwidth from the specified source to the specified 1053 destination. The value corresponds to the maximum bandwidth that can 1054 be reserved (motivated from [RFC3630] Section 2.5.7). The spatial 1055 aggregation unit is specified in the query context (e.g., PID to PID, 1056 or endpoint to endpoint). 1058 Use: This metric could be used either as a cost metric constraint 1059 attribute or as a returned cost metric in the response. 1061 Example 6: bw-maxres value on source-destination endpoint pairs 1063 POST/ endpointcost/lookup HTTP/1.1 1064 Host: alto.example.com 1065 Content-Length: TBA 1066 Content-Type: application/alto-endpointcostparams+json 1067 Accept: 1068 application/alto-endpointcost+json,application/alto-error+json 1070 { 1071 "cost-type" { "cost-mode": "numerical", 1072 "cost-metric": "bw-maxres"}, 1073 "endpoints": { 1074 "srcs": [ "ipv4 : 192.0.2.2" ], 1075 "dsts": [ 1076 "ipv4:192.0.2.89", 1077 "ipv4:198.51.100.34", 1078 "ipv6:2001:db8::1234:5678" 1079 ] 1080 } 1081 } 1083 HTTP/1.1 200 OK 1084 Content-Length: TBA 1085 Content-Type: application/alto-endpointcost+json 1086 { 1087 "meta": { 1088 "cost-type": { 1089 "cost-mode": "numerical", 1090 "cost-metric": "bw-maxres" 1091 } 1092 }, 1093 "endpoint-cost-map": { 1094 "ipv4:192.0.2.2" { 1095 "ipv4:192.0.2.89" : 0, 1096 "ipv4:198.51.100.34": 2000, 1097 "ipv6:2001:db8::1234:5678" : 5000, 1098 } 1099 } 1100 } 1102 4.3.4. Cost-Context Specification Considerations 1104 "nominal": Typically maximum reservable bandwidth does not have a 1105 nominal value. 1107 "sla": Typically maximum reservable bandwidth does not have an "sla" 1108 value. 1110 "import": There can be multiple sources to import maximum reservable 1111 bandwidth. For example, Maximum reservable bandwidth is defined by 1112 IS-IS/OSPF TE, and measures the reservable bandwidth between two 1113 directly connected IS-IS neighbors or OSPF neighbors; see Section 3.5 1114 of [RFC5305]. If the import is from [RFC8571] (by using 1115 unidirectional maximum reservable bandwidth), it is RECOMMENDED that 1116 "parameters" provides "protocol" as a field and "RFC8571" as the 1117 value. 1119 "estimation": The exact estimation method is out of the scope of this 1120 document. It is RECOMMENDED that the "parameters" field of an 1121 "estimation" maximum reservable bandwidth metric provides a link 1122 ("link") to a description of the "estimation" method. 1124 5. Operational Considerations 1126 The exact measurement infrastructure, measurement condition, and 1127 computation algorithms can vary from different networks, and are 1128 outside the scope of this document. Both the ALTO server and the 1129 ALTO clients, however, need to be cognizant of the operational issues 1130 discussed below. 1132 Also, the performance metrics specified in this document are similar, 1133 in that they may use similar data sources and have similar issues in 1134 their calculation. Hence, we specify common issues unless one metric 1135 has its unique challenges. 1137 5.1. Source Considerations 1139 The addition of the "cost-source" field is to solve a key issue: An 1140 ALTO server needs data sources to compute the cost metrics described 1141 in this document, and an ALTO client needs to know the data sources 1142 to better interpret the values. 1144 To avoid too fine-grained information, this document introduces 1145 "cost-source" to indicate only the high-level type of data sources: 1146 "estimation" or "sla", where "estimation" is a type of measurement 1147 data source, and "sla" is a type that is more based on policy. 1149 For estimation, for example, the ALTO server may use log servers or 1150 the OAM system as its data source as recommended by [RFC7971]. In 1151 particular, the cost metrics defined in this document can be computed 1152 using routing systems as the data sources. 1154 5.2. Metric Timestamp Consideration 1156 Despite the introduction of the additional cost-context information, 1157 the metrics do not have a field to indicate the timestamps of the 1158 data used to compute the metrics. To indicate this attribute, the 1159 ALTO server SHOULD return HTTP "Last-Modified", to indicate the 1160 freshness of the data used to compute the performance metrics. 1162 If the ALTO client obtains updates through an incremental update 1163 mechanism [RFC8895]), the client SHOULD assume that the metric is 1164 computed using a snapshot at the time that is approximated by the 1165 receiving time. 1167 5.3. Backward Compatibility Considerations 1169 One potential issue introduced by the optional "cost-source" field is 1170 backward compatibility. Consider that an IRD which defines two cost- 1171 types with the same "cost-mode" and "cost-metric", but one with 1172 "cost-source" being "estimation" and the other being "sla". Then an 1173 ALTO client that is not aware of the extension will not be able to 1174 distinguish between these two types. A similar issue can arise even 1175 with a single cost-type, whose "cost-source" is "sla": an ALTO client 1176 that is not aware of this extension will ignore this field and 1177 consider the metric estimation. 1179 To address this issue, the only defined "routingcost" metric can be 1180 only "estimation". 1182 5.4. Computation Considerations 1184 The metric values exposed by an ALTO server may result from 1185 additional processing on measurements from data sources to compute 1186 exposed metrics. This may involve data processing tasks such as 1187 aggregating the results across multiple systems, removing outliers, 1188 and creating additional statistics. There are two challenges on the 1189 computation of ALTO performance metrics. 1191 5.4.1. Configuration Parameters Considerations 1193 Performance metrics often depend on configuration parameters. For 1194 example, the value of packet loss rate depends on the measurement 1195 interval and varies over time. To handle this issue, an ALTO server 1196 may collect data on time periods covering the previous and current 1197 time or only collect data on present time. The ALTO server may 1198 further aggregate these data to provide an abstract and unified view 1199 that can be more useful to applications. To make the ALTO client 1200 better understand how to use these performance data, the ALTO server 1201 may provide the client with the validity period of the exposed metric 1202 values. 1204 5.4.2. Availability Considerations 1206 Applications value information relating to bandwidth availability, 1207 whereas bandwidth related metrics can often be measured only at the 1208 link level. This document specifies a set of link-level bandwidth 1209 related values that may be exposed as such by an ALTO server. The 1210 server may also expose other metrics derived from their aggregation, 1211 using different levels of endpoint granularity, e.g., link endpoints 1212 or session endpoints. The metric specifications may also expose the 1213 utilized aggregation laws. 1215 6. Security Considerations 1217 The properties defined in this document present no security 1218 considerations beyond those in Section 15 of the base ALTO 1219 specification [RFC7285]. 1221 However, concerns addressed in Sections "15.1 Authenticity and 1222 Integrity of ALTO Information", "15.2 Potential Undesirable Guidance 1223 from Authenticated ALTO Information", and "15.3 Confidentiality of 1224 ALTO Information" remain of utmost importance. Indeed, TE 1225 performance is a highly sensitive ISP information; therefore, sharing 1226 TE metric values in numerical mode requires full mutual confidence 1227 between the entities managing the ALTO server and the ALTO client. 1228 ALTO servers will most likely distribute numerical TE performance to 1229 ALTO clients under strict and formal mutual trust agreements. On the 1230 other hand, ALTO clients must be cognizant on the risks attached to 1231 such information that they would have acquired outside formal 1232 conditions of mutual trust. 1234 7. IANA Considerations 1236 IANA has created and now maintains the "ALTO Cost Metric Registry", 1237 listed in Section 14.2, Table 3 of [RFC7285]. This registry is 1238 located at . This document requests to add the 1240 following entries to "ALTO Cost Metric Registry". 1242 +-----------------+--------------------+ 1243 | Identifier | Intended Semantics | 1244 +-----------------+--------------------+ 1245 | delay-ow | See Section 3.1 | 1246 | delay-rt | See Section 3.2 | 1247 | delay-variation | See Section 3.3 | 1248 | hopcount | See Section 3.4 | 1249 | lossrate | See Section 3.5 | 1250 | tput | See Section 4.1 | 1251 | bw-residual | See Section 4.2 | 1252 | bw-maxres | See Section 4.3 | 1253 +-----------------+--------------------+ 1255 This document requests the creation of the "ALTO Cost Source 1256 Registry" with the following currently defined values: 1258 +------------+-----------------------------+ 1259 | Identifier | Intended Semantics | 1260 +------------+-----------------------------+ 1261 | nominal | Values in nominal cases | 1262 | sla | Values reflecting service | 1263 | | level agreement | 1264 | import | Values from a given protocol| 1265 | estimation | Values by estimation | 1266 +------------+-----------------------------+ 1268 8. Acknowledgments 1270 The authors of this document would also like to thank Brian Trammell, 1271 Haizhou Du, Kai Gao, Lili Liu, Geng Li, Danny Alex Lachos Perez for 1272 the reviews and comments. 1274 9. References 1276 9.1. Normative References 1278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1279 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1280 RFC2119, March 1997, . 1283 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 1284 Performance Metric Development", BCP 170, RFC 6390, DOI 1285 10.17487/RFC6390, October 2011, . 1288 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1289 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1290 "Application-Layer Traffic Optimization (ALTO) Protocol", 1291 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1292 . 1294 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1295 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1296 May 2017, . 1298 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1299 Interchange Format", STD 90, RFC 8259, DOI 10.17487/ 1300 RFC8259, December 2017, . 1303 [RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic 1304 Optimization (ALTO) Incremental Updates Using Server-Sent 1305 Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November 1306 2020, . 1308 9.2. Informative References 1310 [I-D.ietf-ippm-initial-registry] 1311 Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, 1312 "Initial Performance Metrics Registry Entries", draft- 1313 ietf-ippm-initial-registry-16 (work in progress), March 1314 2020. 1316 [Prometheus] 1317 Volz, J. and B. Rabenstein, "Prometheus: A Next-Generation 1318 Monitoring System", 2015. 1320 [Prophet] Gao, K., Zhang, J., and YR. Yang, "Prophet: Fast, Accurate 1321 Throughput Prediction with Reactive Flows", ACM/IEEE 1322 Transactions on Networking July, 2020. 1324 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1325 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1326 September 1999, . 1328 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1329 Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 1330 10.17487/RFC3393, November 2002, . 1333 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1334 (TE) Extensions to OSPF Version 2", RFC 3630, DOI 1335 10.17487/RFC3630, September 2003, . 1338 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1339 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1340 2008, . 1342 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1343 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1344 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1345 . 1347 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 1348 "Framework for TCP Throughput Testing", RFC 6349, DOI 1349 10.17487/RFC6349, August 2011, . 1352 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1353 Ed., "A One-Way Delay Metric for IP Performance Metrics 1354 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 1355 2016, . 1357 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1358 Ed., "A One-Way Loss Metric for IP Performance Metrics 1359 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1360 2016, . 1362 [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 1363 S. Previdi, "Application-Layer Traffic Optimization (ALTO) 1364 Deployment Considerations", RFC 7971, DOI 10.17487/ 1365 RFC7971, October 2016, . 1368 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1369 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1370 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1371 2019, . 1373 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 1374 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 1375 IGP Traffic Engineering Performance Metric Extensions", 1376 RFC 8571, DOI 10.17487/RFC8571, March 2019, 1377 . 1379 Authors' Addresses 1381 Qin Wu 1382 Huawei 1383 101 Software Avenue, Yuhua District 1384 Nanjing, Jiangsu 210012 1385 CHINA 1387 Email: bill.wu@huawei.com 1389 Y. Richard Yang 1390 Yale University 1391 51 Prospect St 1392 New Haven, CT 06520 1393 USA 1395 Email: yry@cs.yale.edu 1397 Young Lee 1398 Samsung 1399 1700 Alma Drive, Suite 500 1400 Plano, TX 75075 1401 USA 1403 Email: young.lee@gmail.com 1405 Dhruv Dhody 1406 Huawei 1407 Leela Palace 1408 Bangalore, Karnataka 560008 1409 INDIA 1411 Email: dhruv.ietf@gmail.com 1413 Sabine Randriamasy 1414 Nokia Bell Labs 1415 Route de Villejust 1416 Nozay 91460 1417 FRANCE 1419 Email: sabine.randriamasy@nokia-bell-labs.com 1420 Luis Miguel Contreras Murillo 1421 Telefonica 1422 Madrid 1423 SPAIN 1425 Email: luismiguel.contrerasmurillo@telefonica.com