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