idnits 2.17.1 draft-ietf-alto-performance-metrics-28.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 325 has weird spacing: '...tMetric cost...' == Line 328 has weird spacing: '...NString descr...' == Line 332 has weird spacing: '...NString cos...' == Line 333 has weird spacing: '...ONValue par...' -- The document date (21 March 2022) is 760 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: '8570' on line 1161 -- Looks like a reference, but probably isn't: '8571' on line 173 -- Looks like a reference, but probably isn't: '0' on line 440 -- Looks like a reference, but probably isn't: '100' on line 430 -- Looks like a reference, but probably isn't: '1' on line 440 -- Looks like a reference, but probably isn't: '7471' on line 1161 == Missing Reference: 'RFCXXX' is mentioned on line 1517, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1515, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-tcpm-rfc8312bis-07 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-IPPM' ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 8 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: 22 September 2022 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 21 March 2022 16 ALTO Performance Cost Metrics 17 draft-ietf-alto-performance-metrics-28 19 Abstract 21 The cost metric is a basic concept in Application-Layer Traffic 22 Optimization (ALTO), and different applications may use different 23 types of cost metrics. Since the ALTO base protocol (RFC 7285) 24 defines only a single cost metric (namely, the generic "routingcost" 25 metric), if an application wants to issue a cost map or an endpoint 26 cost request in order to identify a resource provider that offers 27 better performance metrics (e.g., lower delay or loss rate), the base 28 protocol does not define the cost metric to be used. 30 This document addresses this issue by extending the specification to 31 provide a variety of network performance metrics, including network 32 delay, delay variation (a.k.a, jitter), packet loss rate, hop count, 33 and bandwidth. 35 There are multiple sources (e.g., estimation based on measurements or 36 service-level agreement) to derive a performance metric. This 37 document introduces an additional "cost-context" field to the ALTO 38 "cost-type" field to convey the source of a performance metric. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on 22 September 2022. 57 Copyright Notice 59 Copyright (c) 2022 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Revised BSD License text as 68 described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Revised BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 75 3. Performance Metric Attributes . . . . . . . . . . . . . . . . 6 76 3.1. Performance Metric Context: "cost-context" . . . . . . . 7 77 3.2. Performance Metric Statistics . . . . . . . . . . . . . . 9 78 4. Packet Performance Metrics . . . . . . . . . . . . . . . . . 11 79 4.1. Cost Metric: One-Way Delay (delay-ow) . . . . . . . . . . 11 80 4.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 11 81 4.1.2. Value Representation . . . . . . . . . . . . . . . . 12 82 4.1.3. Intended Semantics and Use . . . . . . . . . . . . . 12 83 4.1.4. Cost-Context Specification Considerations . . . . . . 14 84 4.2. Cost Metric: Round-trip Delay (delay-rt) . . . . . . . . 16 85 4.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 16 86 4.2.2. Value Representation . . . . . . . . . . . . . . . . 16 87 4.2.3. Intended Semantics and Use . . . . . . . . . . . . . 16 88 4.2.4. Cost-Context Specification Considerations . . . . . . 17 89 4.3. Cost Metric: Delay Variation (delay-variation) . . . . . 18 90 4.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 18 91 4.3.2. Value Representation . . . . . . . . . . . . . . . . 18 92 4.3.3. Intended Semantics and Use . . . . . . . . . . . . . 18 93 4.3.4. Cost-Context Specification Considerations . . . . . . 19 94 4.4. Cost Metric: Loss Rate (lossrate) . . . . . . . . . . . . 20 95 4.4.1. Base Identifier . . . . . . . . . . . . . . . . . . . 20 96 4.4.2. Value Representation . . . . . . . . . . . . . . . . 20 97 4.4.3. Intended Semantics and Use . . . . . . . . . . . . . 20 98 4.4.4. Cost-Context Specification Considerations . . . . . . 21 99 4.5. Cost Metric: Hop Count (hopcount) . . . . . . . . . . . . 22 100 4.5.1. Base Identifier . . . . . . . . . . . . . . . . . . . 22 101 4.5.2. Value Representation . . . . . . . . . . . . . . . . 22 102 4.5.3. Intended Semantics and Use . . . . . . . . . . . . . 22 103 4.5.4. Cost-Context Specification Considerations . . . . . . 23 104 5. Throughput/Bandwidth Performance Metrics . . . . . . . . . . 24 105 5.1. Cost Metric: TCP Throughput (tput) . . . . . . . . . . . 24 106 5.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 24 107 5.1.2. Value Representation . . . . . . . . . . . . . . . . 24 108 5.1.3. Intended Semantics and Use . . . . . . . . . . . . . 24 109 5.1.4. Cost-Context Specification Considerations . . . . . . 25 110 5.2. Cost Metric: Residual Bandwidth (bw-residual) . . . . . . 26 111 5.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 26 112 5.2.2. Value Representation . . . . . . . . . . . . . . . . 26 113 5.2.3. Intended Semantics and Use . . . . . . . . . . . . . 26 114 5.2.4. Cost-Context Specification Considerations . . . . . . 28 115 5.3. Cost Metric: Available Bandwidth (bw-available) . . . . . 28 116 5.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 28 117 5.3.2. Value Representation . . . . . . . . . . . . . . . . 28 118 5.3.3. Intended Semantics and Use . . . . . . . . . . . . . 29 119 5.3.4. Cost-Context Specification Considerations . . . . . . 30 120 6. Operational Considerations . . . . . . . . . . . . . . . . . 30 121 6.1. Source Considerations . . . . . . . . . . . . . . . . . . 31 122 6.2. Metric Timestamp Consideration . . . . . . . . . . . . . 31 123 6.3. Backward Compatibility Considerations . . . . . . . . . . 31 124 6.4. Computation Considerations . . . . . . . . . . . . . . . 32 125 6.4.1. Configuration Parameters Considerations . . . . . . . 32 126 6.4.2. Aggregation Computation Considerations . . . . . . . 32 127 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 128 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 129 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 130 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 131 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 132 10.2. Informative References . . . . . . . . . . . . . . . . . 37 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 135 1. Introduction 137 Application-Layer Traffic Optimization (ALTO) provides a means for 138 network applications to obtain network information so that the 139 applications can identify efficient application-layer traffic 140 patterns using the networks. Cost metrics are used in both the ALTO 141 cost map service and the ALTO endpoint cost service in the ALTO base 142 protocol [RFC7285]. 144 Since different applications may use different cost metrics, the ALTO 145 base protocol introduces an ALTO Cost Metric Registry (Section 14.2 146 of [RFC7285]) as a systematic mechanism to allow different metrics to 147 be specified. For example, a delay-sensitive application may want to 148 use latency related metrics, and a bandwidth-sensitive application 149 may want to use bandwidth related metrics. However, the ALTO base 150 protocol has registered only a single cost metric, i.e., the generic 151 "routingcost" metric (Section 14.2 of [RFC7285]); no latency or 152 bandwidth related metrics are defined in the base protocol. 154 This document registers a set of new cost metrics (Table 1) to allow 155 applications to determine "where" to connect based on network 156 performance criteria including delay and bandwidth related metrics. 158 +--------------------+-------------+--------------------------------+ 159 | Metric | Definition | Semantics Based On | 160 | | in this doc | | 161 +--------------------+-------------+--------------------------------+ 162 | One-way Delay | Section 4.1 | Base: [RFC7471,8570,8571] | 163 | | | sum Unidirectional Delay | 164 | Round-trip Delay | Section 4.2 | Base: Sum of two directions | 165 | | | from above | 166 | Delay Variation | Section 4.3 | Base: [RFC7471,8570,8571] | 167 | | | sum of Unidirectional Delay | 168 | | | Variation | 169 | Loss Rate | Section 4.4 | Base: [RFC7471,8570,8571] | 170 | | | aggr Unidirectional Link Loss | 171 | Residual Bandwidth | Section 5.2 | Base: [RFC7471,8570,8571] | 172 | | | min Unidirectional Residual BW| 173 | Available Bandwidth| Section 5.3 | Base: [RFC7471,8570,8571] | 174 | | | min Unidirectional Avail. BW | 175 | | | | 176 | TCP Throughput | Section 5.1 | [I-D.ietf-tcpm-rfc8312bis] | 177 | | | | 178 | Hop Count | Section 4.5 | [RFC7285] | 179 +--------------------+-------------+--------------------------------+ 180 Table 1. Cost Metrics Defined in this Document. 182 The first 6 metrics listed in Table 1 (i.e., One-way Delay, Round- 183 trip Delay, Delay Variation, Loss Rate, Residual Bandwidth, and 184 Available Bandwidth) are derived from the set of traffic engineering 185 performance metrics commonly defined in OSPF [RFC3630], [RFC7471]; 186 IS-IS [RFC5305], [RFC8570]; and BGP-LS [RFC8571]. Deriving ALTO cost 187 performance metrics from existing network-layer traffic engineering 188 performance metrics, to expose to application-layer traffic 189 optimization, can be a typical mechanism by network operators to 190 deploy ALTO [RFC7971], [FlowDirector]. This document defines the 191 base semantics of these metrics by extending them from link metrics 192 to end-to-end metrics for ALTO. The "Semantics Based On" column 193 specifies at a high level how the end-to-end metric is computed from 194 link metrics; the details will be specified in the following 195 sections. 197 The common metrics Min/Max Unidirectional Delay defined in 198 [RFC8570][RFC8571] and Max Link Bandwidth defined in 199 [RFC3630,RFC5305] are not listed in Table 1 because they can be 200 handled by applying the statistical operators defined in this 201 document. The metrics related with utilized bandwidth and reservable 202 bandwidth (i.e., Max Reservable BW and Unreserved BW defined in 203 [RFC3630,RFC5305]) are outside the scope of this document. 205 The 7th metric (the estimated TCP-flow throughput metric) provides an 206 estimation of the bandwidth of a TCP flow, using TCP throughput 207 modeling, to support use cases of adaptive applications [Prophet], 208 [G2]. Note that other transport-specific metrics can be defined in 209 the future. For example, QUIC-related metrics [RFC9000] can be 210 considered when the methodology to measure such metrics is more 211 mature (e.g., [I-D.corre-quic-throughput-testing]). 213 The 8th metric (the hop count metric) in Table 1 is mentioned in the 214 ALTO base protocol [RFC7285], but not defined, and this document 215 defines it to be complete. 217 These 8 performance metrics can be classified into two categories: 218 those derived from the performance of individual packets (i.e., One- 219 way Delay, Round-trip Delay, Delay Variation, Loss Rate, and Hop 220 Count), and those related to bandwidth/throughput (Residual 221 bandwidth, and Available Bandwidth, and TCP throughput). These two 222 categories are defined in Sections 4 and 5 respectively. Note that 223 all metrics except Round-trip Delay are unidirectional. An ALTO 224 client will need to query both directions if needed. 226 The purpose of this document is to ensure proper usage of these 8 227 performance metrics in the context of ALTO. This document follows 228 the guideline defined in Section 14.2 of the ALTO base protocol 229 [RFC7285] on registering ALTO cost metrics. Hence, it specifies the 230 identifier, the intended semantics, and the security considerations 231 of each one of the metrics specified in Table 1. 233 The definitions of the intended semantics of the metrics tend to be 234 coarse-grained, for guidance only, and they may work well for ALTO. 235 On the other hand, a performance measurement framework, such as the 236 IP Performance Measurement (IPPM) framework, may provide more details 237 in defining a performance metric. This document introduces a 238 mechanism called "cost-context" to provide additional details, when 239 they are available; see Section 3. 241 Following the ALTO base protocol, this document uses JSON to specify 242 the value type of each defined metric. See [RFC8259] for JSON data 243 type specification. In particular, [RFC7285] specifies that cost 244 values should be assumed by default as JSONNumber. When defining the 245 value representation of each metric in Table 1, this document 246 conforms to [RFC7285], but specifies additional, generic constraints 247 on valid JSONNumbers for each metric. For example, each new metric 248 in Table 1 will be specified as non-negative (>= 0); Hop Count is 249 specified to be an integer. 251 An ALTO server may provide only a subset of the metrics described in 252 this document. For example, those that are subject to privacy 253 concerns should not be provided to unauthorized ALTO clients. Hence, 254 all cost metrics defined in this document are optional; not all of 255 them need to be exposed to a given application. When an ALTO server 256 supports a cost metric defined in this document, it announces the 257 metric in its information resource directory (IRD) as defined in 258 Section 9.2 of [RFC7285]. 260 An ALTO server introducing these metrics should consider related 261 security issues. As a generic security consideration on the 262 reliability and trust in the exposed metric values, applications 263 SHOULD rapidly give up using ALTO-based guidance if they detect that 264 the exposed information does not preserve their performance level or 265 even degrades it. Section 7 discusses security considerations in 266 more detail. 268 2. Requirements Language 270 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 271 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 272 "OPTIONAL" in this document are to be interpreted as described in BCP 273 14 [RFC2119][RFC8174] when, and only when, they appear in all 274 capitals, as shown here. 276 3. Performance Metric Attributes 278 The definitions of the metrics in this document are coarse-grained, 279 based on network-layer traffic engineering performance metrics, for 280 guidance only. A fine-grained framework specified in [RFC6390] 281 requires that the fine-grained specification of a network performance 282 metric include 6 components: (i) Metric Name, (ii) Metric 283 Description, (iii) Method of Measurement or Calculation, (iv) Units 284 of Measurement, (v) Measurement Points, and (vi) Measurement Timing. 285 Requiring that an ALTO server provides precise, fine-grained values 286 for all 6 components for each metric that it exposes may not be 287 feasible or necessary for all ALTO use cases. For example, an ALTO 288 server computing its metrics from network-layer traffic-engineering 289 performance metrics may not have information about the method of 290 measurement or calculation (e.g., measured traffic patterns). 292 To address the issue and realize ALTO use cases, for metrics in 293 Table 1, this document defines performance metric identifiers which 294 can be used in the ALTO protocol with well-defined (i) Metric Name, 295 (ii) Metric Description, (iv) Units of Measurement, and (v) 296 Measurement Points, which are always specified by the specific ALTO 297 services; for example, endpoint cost service is between the two 298 endpoints. Hence, the ALTO performance metric identifiers provide 299 basic metric attributes. 301 To allow the flexibility of allowing an ALTO server to provide fine- 302 grained information such as Method of Measurement or Calculation, 303 according to its policy and use cases, this document introduces 304 context information so that the server can provide these additional 305 details. 307 3.1. Performance Metric Context: "cost-context" 309 The core additional details of a performance metric specify "how" the 310 metric is obtained. This is referred to as the source of the metric. 311 Specifically, this document defines three types of coarse-grained 312 metric information sources: "nominal", and "sla" (service level 313 agreement), and "estimation". 315 For a given type of source, precise interpretation of a performance 316 metric value can depend on specific measurement and computation 317 parameters. 319 To make it possible to specify the source and the aforementioned 320 parameters, this document introduces an optional "cost-context" field 321 to the "cost-type" field defined by the ALTO base protocol 322 (Section 10.7 of [RFC7285]) as the following: 324 object { 325 CostMetric cost-metric; 326 CostMode cost-mode; 327 [CostContext cost-context;] 328 [JSONString description;] 329 } CostType; 331 object { 332 JSONString cost-source; 333 [JSONValue parameters;] 334 } CostContext; 336 "cost-context" will not be used as a key to distinguish among 337 performance metrics. Hence, an ALTO information resource MUST NOT 338 announce multiple CostType with the same "cost-metric", "cost-mode" 339 and "cost-context". They must be placed into different information 340 resources. 342 The "cost-source" field of the "cost-context" field is defined as a 343 string consisting of only US-ASCII alphanumeric characters 344 (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A). The cost-source 345 is used in this document to indicate a string of this format. 347 As mentioned above, this document defines three values for "cost- 348 source": "nominal", "sla", and "estimation". The "cost-source" field 349 of the "cost-context" field MUST be one registered in "ALTO Cost 350 Source" registry (Section 8). 352 The "nominal" category indicates that the metric value is statically 353 configured by the underlying devices. Not all metrics have 354 reasonable "nominal" values. For example, throughput can have a 355 nominal value, which indicates the configured transmission rate of 356 the involved devices; latency typically does not have a nominal 357 value. 359 The "sla" category indicates that the metric value is derived from 360 some commitment which this document refers to as service-level 361 agreement (SLA). Some operators also use terms such as "target" or 362 "committed" values. For an "sla" metric, it is RECOMMENDED that the 363 "parameters" field provide a link to the SLA definition. 365 The "estimation" category indicates that the metric value is computed 366 through an estimation process. An ALTO server may compute 367 "estimation" values by retrieving and/or aggregating information from 368 routing protocols (e.g., [RFC7471], [RFC8570], [RFC8571]), traffic 369 measurement management tools (e.g., TWAMP [RFC5357]), and measurement 370 frameworks (e.g., IPPM), with corresponding operational issues. An 371 illustration of potential information flows used for estimating these 372 metrics is shown in Figure 1. Section 6 discusses in more detail the 373 operational issues and how a network may address them. 375 +--------+ +--------+ +--------+ 376 | Client | | Client | | Client | 377 +----^---+ +---^----+ +---^----+ 378 | | | 379 +-----------|-----------+ 380 North-Bound |ALTO protocol 381 Interface (NBI)| 382 | 383 +--+-----+ retrieval +-----------+ 384 | ALTO |<----------------| Routing | 385 | Server | and aggregation| | 386 | |<-------------+ | Protocols | 387 +--------+ | +-----------+ 388 | 389 | +------------+ 390 | |Performance | 391 ---| Monitoring | 392 | Tools | 393 +------------+ 394 Figure 1. A framework to compute estimation to performance metrics 396 There can be multiple choices in deciding the cost-source category. 397 It is the operator of an ALTO server who chooses the category. If a 398 metric does not include a "cost-source" value, the application MUST 399 assume that the value of "cost-source" is the most generic source, 400 i.e., "estimation". 402 3.2. Performance Metric Statistics 404 The measurement of a performance metric often yields a set of samples 405 from an observation distribution ([Prometheus]), instead of a single 406 value. A statistical operator is applied to the samples to obtain a 407 value to be reported to the client. Multiple statistical operators 408 (e.g., min, median, and max) are commonly being used. 410 Hence, this document extends the general US-ASCII alphanumeric cost 411 metric strings, formally specified as the CostMetric type defined in 412 Section 10.6 of [RFC7285], as follows: 414 A cost metric string consists of a base metric identifier (or base 415 identifier for short) string, followed by an optional statistical 416 operator string, connected by the ASCII character colon (':', 417 U+003A), if the statistical operator string exists. The total 418 length of the cost metric string MUST NOT exceed 32, as required 419 by [RFC7285]. 421 The statistical operator string MUST be one of the following: 423 cur: 424 the instantaneous observation value of the metric from the most 425 recent sample (i.e., the current value). 427 percentile, with letter 'p' followed by a number: 428 gives the percentile specified by the number following the letter 429 'p'. The number MUST be a non-negative JSON number in the range 430 [0, 100] (i.e., greater than or equal to 0 and less than or equal 431 to 100), followed by an optional decimal part, if a higher 432 precision is needed. The decimal part should start with the '.' 433 separator (U+002E), and followed by a sequence of one or more 434 ASCII numbers between '0' and '9'. Assume this number is y and 435 consider the samples coming from a random variable X. Then the 436 metric returns x, such that the probability of X is less than or 437 equal to x, i.e., Prob(X <= x), = y/100. For example, delay- 438 ow:p99 gives the 99% percentile of observed one-way delay; delay- 439 ow:p99.9 gives the 99.9% percentile. Note that some systems use 440 quantile, which is in the range [0, 1]. When there is a more 441 common form for a given percentile, it is RECOMMENDED that the 442 common form be used; that is, instead of p0, use min; instead of 443 p50, use median; instead of p100, use max. 445 min: 446 the minimal value of the observations. 448 max: 449 the maximal value of the observations. 451 median: 452 the mid-point (i.e., p50) of the observations. 454 mean: 455 the arithmetic mean value of the observations. 457 stddev: 458 the standard deviation of the observations. 460 stdvar: 461 the standard variance of the observations. 463 Examples of cost metric strings then include "delay-ow", "delay- 464 ow:min", "delay-ow:p99", where "delay-ow" is the base metric 465 identifier string; "min" and "p99" are example statistical operator 466 strings. 468 If a cost metric string does not have the optional statistical 469 operator string, the statistical operator SHOULD be interpreted as 470 the default statistical operator in the definition of the base 471 metric. If the definition of the base metric does not provide a 472 definition for the default statistical operator, the metric MUST be 473 considered as the median value. 475 Note that RFC 7258 limits the overall cost metric identifier to 32 476 characters. The cost metric variants with statistical operator 477 suffixes defined by this document are also subject to the same 478 overall 32-character limit, so certain combinations of (long) base 479 metric identifier and statistical operator will not be representable. 480 If such a situation arises, it could be addressed by defining a new 481 base metric identifier that is an "alias" of the desired base metric, 482 with identical semantics and just a shorter name. 484 4. Packet Performance Metrics 486 This section introduces ALTO network performance metrics on one way 487 delay, round-trip delay, delay variation, packet loss rate, and hop 488 count. They measure the "quality of experience" of the stream of 489 packets sent from a resource provider to a resource consumer. The 490 measures of each individual packet (pkt) can include the delay from 491 the time when the packet enters the network to the time when the 492 packet leaves the network (pkt.delay); whether the packet is dropped 493 before reaching the destination (pkt.dropped); the number of network 494 hops that the packet traverses (pkt.hopcount). The semantics of the 495 performance metrics defined in this section are that they are 496 statistics computed from these measures; for example, the 497 x-percentile of the one-way delay is the x-percentile of the set of 498 delays {pkt.delay} for the packets in the stream. 500 4.1. Cost Metric: One-Way Delay (delay-ow) 502 4.1.1. Base Identifier 504 The base identifier for this performance metric is "delay-ow". 506 4.1.2. Value Representation 508 The metric value type is a single 'JSONNumber' type value conforming 509 to the number specification of Section 6 of [RFC8259]. The unit is 510 expressed in microseconds. Hence, the number can be a floating point 511 number to express delay that is smaller than microseconds. The 512 number MUST be non-negative. 514 4.1.3. Intended Semantics and Use 516 Intended Semantics: To specify the temporal and spatial aggregated 517 delay of a stream of packets from the specified source to the 518 specified destination. The base semantics of the metric is the 519 Unidirectional Delay metric defined in [RFC8571,RFC8570,RFC7471], but 520 instead of specifying the delay for a link, it is the (temporal) 521 aggregation of the link delays from the source to the destination. A 522 non-normative reference definition of end-to-end one-way delay is 523 [RFC7679]. The spatial aggregation level is specified in the query 524 context, e.g., provider-defined identifier (PID) to PID, or endpoint 525 to endpoint, where PID is defined in Section 5.1 of [RFC7285]. 527 Use: This metric could be used as a cost metric constraint attribute 528 or as a returned cost metric in the response. 530 Example 1: Delay value on source-destination endpoint pairs 532 POST /endpointcost/lookup HTTP/1.1 533 Host: alto.example.com 534 Content-Length: 239 535 Content-Type: application/alto-endpointcostparams+json 536 Accept: 537 application/alto-endpointcost+json,application/alto-error+json 539 { 540 "cost-type": { 541 "cost-mode": "numerical", 542 "cost-metric": "delay-ow" 543 }, 544 "endpoints": { 545 "srcs": [ 546 "ipv4:192.0.2.2" 547 ], 548 "dsts": [ 549 "ipv4:192.0.2.89", 550 "ipv4:198.51.100.34" 551 ] 552 } 553 } 554 HTTP/1.1 200 OK 555 Content-Length: 247 556 Content-Type: application/alto-endpointcost+json 558 { 559 "meta": { 560 "cost-type": { 561 "cost-mode": "numerical", 562 "cost-metric": "delay-ow" 563 } 564 }, 565 "endpoint-cost-map": { 566 "ipv4:192.0.2.2": { 567 "ipv4:192.0.2.89": 10, 568 "ipv4:198.51.100.34": 20 569 } 570 } 571 } 573 Note that since the "cost-type" does not include the "cost-source" 574 field, the values are based on "estimation". Since the identifier 575 does not include the statistical operator string component, the 576 values will represent median values. 578 Example 1a below shows an example that is similar to Example 1, but 579 for IPv6. 581 Example 1a: Delay value on source-destination endpoint pairs for IPv6 583 POST /endpointcost/lookup HTTP/1.1 584 Host: alto.example.com 585 Content-Length: 252 586 Content-Type: application/alto-endpointcostparams+json 587 Accept: 588 application/alto-endpointcost+json,application/alto-error+json 590 { 591 "cost-type": { 592 "cost-mode": "numerical", 593 "cost-metric": "delay-ow" 594 }, 595 "endpoints": { 596 "srcs": [ 597 "ipv6:2001:db8:100::1" 598 ], 599 "dsts": [ 600 "ipv6:2001:db8:100::2", 601 "ipv6:2001:db8:100::3" 602 ] 603 } 604 } 606 HTTP/1.1 200 OK 607 Content-Length: 257 608 Content-Type: application/alto-endpointcost+json 610 { 611 "meta": { 612 "cost-type": { 613 "cost-mode": "numerical", 614 "cost-metric": "delay-ow" 615 } 616 }, 617 "endpoint-cost-map": { 618 "ipv6:2001:db8:100::1": { 619 "ipv6:2001:db8:100::2": 10, 620 "ipv6:2001:db8:100::3": 20 621 } 622 } 623 } 625 4.1.4. Cost-Context Specification Considerations 627 "nominal": Typically network one-way delay does not have a nominal 628 value. 630 "sla": Many networks provide delay-related parameters in their 631 application-level SLAs. It is RECOMMENDED that the "parameters" 632 field of an "sla" one-way delay metric include a link (i.e., a field 633 named "link") providing an URI to the specification of SLA details, 634 if available. Such a specification can be either free text for 635 possible presentation to the user, or a formal specification. The 636 format of the specification is out of the scope of this document. 638 "estimation": The exact estimation method is out of the scope of this 639 document. There can be multiple sources to estimate one-way delay. 640 For example, the ALTO server may estimate the end-to-end delay by 641 aggregation of routing protocol link metrics; the server may also 642 estimate the delay using active, end-to-end measurements, for 643 example, using the IPPM framework [RFC2330]. 645 If the estimation is computed by aggregation of routing protocol link 646 metrics (e.g., OSPF [RFC7471], IS-IS [RFC8570], or BGP-LS [RFC8571]) 647 Unidirectional Delay link metrics, it is RECOMMENDED that the 648 "parameters" field of an "estimation" one-way delay metric include 649 the following information: (1) the RFC defining the routing protocol 650 metrics (e.g., https://www.rfc-editor.org/info/rfc7471 for RFC7471 651 derived metrics); (2) configurations of the routing link metrics such 652 as configured intervals; and (3) the aggregation method from link 653 metrics to end-to-end metrics. During aggregation from link metrics 654 to the end-to-end metric, the server should be cognizant of potential 655 issues when computing an end-to-end summary statistic from link 656 statistics. The default end-to-end average one-way delay is the sum 657 of average link one-way delays. If an ALTO server provides the min 658 and max statistical operators for the one-way delay metric, the 659 values can be computed directly from the routing link metrics, as 660 [RFC7471,RFC8570,RFC8571] provide Min/Max Unidirectional Link Delay. 662 If the estimation is from the IPPM measurement framework, it is 663 RECOMMEDED that the "parameters" field of an "estimation" one-way 664 delay metric includes the following information: the URI to the URI 665 field of the IPPM metric defined in the IPPM performance metric 666 [IANA-IPPM] registry (e.g., https://www.iana.org/assignments/ 667 performance-metrics/OWDelay_Active_IP-UDP-Poisson- 668 Payload250B_RFC8912sec7_Seconds_95Percentile). The IPPM metric MUST 669 be one-way delay (i.e., IPPM OWDelay* metrics). The statistical 670 operator of the ALTO metric MUST be consistent with the IPPM 671 statistical property (e.g., 95-th percentile). 673 4.2. Cost Metric: Round-trip Delay (delay-rt) 675 4.2.1. Base Identifier 677 The base identifier for this performance metric is "delay-rt". 679 4.2.2. Value Representation 681 The metric value type is a single 'JSONNumber' type value conforming 682 to the number specification of Section 6 of [RFC8259]. The number 683 MUST be non-negative. The unit is expressed in microseconds. 685 4.2.3. Intended Semantics and Use 687 Intended Semantics: To specify temporal and spatial aggregated round- 688 trip delay between the specified source and specified destination. 689 The base semantics is that it is the sum of one-way delay from the 690 source to the destination and the one-way delay from the destination 691 back to the source, where the one-way delay is defined in 692 Section 4.1. A non-normative reference definition of end-to-end 693 round-trip delay is [RFC2681]. The spatial aggregation level is 694 specified in the query context (e.g., PID to PID, or endpoint to 695 endpoint). 697 Note that it is possible for a client to query two one-way delays 698 (delay-ow) and then compute the round-trip delay. The server should 699 be cognizant of the consistency of values. 701 Use: This metric could be used either as a cost metric constraint 702 attribute or as a returned cost metric in the response. 704 Example 2: Round-trip Delay of source-destination endpoint pairs 706 POST /endpointcost/lookup HTTP/1.1 707 Host: alto.example.com 708 Content-Length: 238 709 Content-Type: application/alto-endpointcostparams+json 710 Accept: 711 application/alto-endpointcost+json,application/alto-error+json 713 { 714 "cost-type": { 715 "cost-mode": "numerical", 716 "cost-metric": "delay-rt" 717 }, 718 "endpoints": { 719 "srcs": [ 720 "ipv4:192.0.2.2" 721 ], 722 "dsts": [ 723 "ipv4:192.0.2.89", 724 "ipv4:198.51.100.34" 725 ] 726 } 727 } 729 HTTP/1.1 200 OK 730 Content-Length: 245 731 Content-Type: application/alto-endpointcost+json 733 { 734 "meta": { 735 "cost-type": { 736 "cost-mode": "numerical", 737 "cost-metric": "delay-rt" 738 } 739 }, 740 "endpoint-cost-map": { 741 "ipv4:192.0.2.2": { 742 "ipv4:192.0.2.89": 4, 743 "ipv4:198.51.100.34": 3 744 } 745 } 746 } 748 4.2.4. Cost-Context Specification Considerations 750 "nominal": Typically network round-trip delay does not have a nominal 751 value. 753 "sla": See the "sla" entry in Section 4.1.4. 755 "estimation": See the "estimation" entry in Section 4.1.4. For 756 estimation by aggregation of routing protocol link metrics, the 757 aggregation should include all links from the source to the 758 destination and then back to the source; for estimation using IPPM, 759 the IPPM metric MUST be round-trip delay (i.e., IPPM RTDelay* 760 metrics). The statistical operator of the ALTO metric MUST be 761 consistent with the IPPM statistical property (e.g., 95-th 762 percentile). 764 4.3. Cost Metric: Delay Variation (delay-variation) 766 4.3.1. Base Identifier 768 The base identifier for this performance metric is "delay-variation". 770 4.3.2. Value Representation 772 The metric value type is a single 'JSONNumber' type value conforming 773 to the number specification of Section 6 of [RFC8259]. The number 774 MUST be non-negative. The unit is expressed in microseconds. 776 4.3.3. Intended Semantics and Use 778 Intended Semantics: To specify temporal and spatial aggregated delay 779 variation (also called delay jitter)) with respect to the minimum 780 delay observed on the stream over the one-way delay from the 781 specified source and destination, where the one-way delay is defined 782 in Section 4.1. A non-normative reference definition of end-to-end 783 one-way delay variation is [RFC3393]. Note that [RFC3393] allows the 784 specification of a generic selection function F to unambiguously 785 define the two packets selected to compute delay variations. This 786 document defines the specific case that F selects as the "first" 787 packet the one with the smallest one-way delay. The spatial 788 aggregation level is specified in the query context (e.g., PID to 789 PID, or endpoint to endpoint). 791 Note that in statistics, variations are typically evaluated by the 792 distance from samples relative to the mean. In networking context, 793 it is more commonly defined from samples relative to the min. This 794 definition follows the networking convention. 796 Use: This metric could be used either as a cost metric constraint 797 attribute or as a returned cost metric in the response. 799 Example 3: Delay variation value on source-destination endpoint pairs 801 POST /endpointcost/lookup HTTP/1.1 802 Host: alto.example.com 803 Content-Length: 245 804 Content-Type: application/alto-endpointcostparams+json 805 Accept: 806 application/alto-endpointcost+json,application/alto-error+json 808 { 809 "cost-type": { 810 "cost-mode": "numerical", 811 "cost-metric": "delay-variation" 812 }, 813 "endpoints": { 814 "srcs": [ 815 "ipv4:192.0.2.2" 816 ], 817 "dsts": [ 818 "ipv4:192.0.2.89", 819 "ipv4:198.51.100.34" 820 ] 821 } 822 } 824 HTTP/1.1 200 OK 825 Content-Length: 252 826 Content-Type: application/alto-endpointcost+json 828 { 829 "meta": { 830 "cost-type": { 831 "cost-mode": "numerical", 832 "cost-metric": "delay-variation" 833 } 834 }, 835 "endpoint-cost-map": { 836 "ipv4:192.0.2.2": { 837 "ipv4:192.0.2.89": 0, 838 "ipv4:198.51.100.34": 1 839 } 840 } 841 } 843 4.3.4. Cost-Context Specification Considerations 845 "nominal": Typically network delay variation does not have a nominal 846 value. 848 "sla": See the "sla" entry in Section 4.1.4. 850 "estimation": See the "estimation" entry in Section 4.1.4. For 851 estimation by aggregation of routing protocol link metrics, the 852 default aggregation of the average of delay variations is the sum of 853 the link delay variations; for estimation using IPPM, the IPPM metric 854 MUST be delay variation (i.e., IPPM OWPDV* metrics). The statistical 855 operator of the ALTO metric MUST be consistent with the IPPM 856 statistical property (e.g., 95-th percentile). 858 4.4. Cost Metric: Loss Rate (lossrate) 860 4.4.1. Base Identifier 862 The base identifier for this performance metric is "lossrate". 864 4.4.2. Value Representation 866 The metric value type is a single 'JSONNumber' type value conforming 867 to the number specification of Section 6 of [RFC8259]. The number 868 MUST be non-negative. The value represents the percentage of packet 869 losses. 871 4.4.3. Intended Semantics and Use 873 Intended Semantics: To specify temporal and spatial aggregated one- 874 way packet loss rate from the specified source and the specified 875 destination. The base semantics of the metric is the Unidirectional 876 Link Loss metric defined in [RFC8571,RFC8570,RFC7471], but instead of 877 specifying the loss for a link, it is the aggregated loss of all 878 links from the source to the destination. The spatial aggregation 879 level is specified in the query context (e.g., PID to PID, or 880 endpoint to endpoint). 882 Use: This metric could be used as a cost metric constraint attribute 883 or as a returned cost metric in the response. 885 Example 5: Loss rate value on source-destination endpoint pairs 887 POST /endpointcost/lookup HTTP/1.1 888 Host: alto.example.com 889 Content-Length: 238 890 Content-Type: application/alto-endpointcostparams+json 891 Accept: 892 application/alto-endpointcost+json,application/alto-error+json 894 { 895 "cost-type": { 896 "cost-mode": "numerical", 897 "cost-metric": "lossrate" 898 }, 899 "endpoints": { 900 "srcs": [ 901 "ipv4:192.0.2.2" 902 ], 903 "dsts": [ 904 "ipv4:192.0.2.89", 905 "ipv4:198.51.100.34" 906 ] 907 } 908 } 910 HTTP/1.1 200 OK 911 Content-Length: 248 912 Content-Type: application/alto-endpointcost+json 914 { 915 "meta": { 916 "cost-type": { 917 "cost-mode": "numerical", 918 "cost-metric": "lossrate" 919 } 920 }, 921 "endpoint-cost-map": { 922 "ipv4:192.0.2.2": { 923 "ipv4:192.0.2.89": 0, 924 "ipv4:198.51.100.34": 0.01 925 } 926 } 927 } 929 4.4.4. Cost-Context Specification Considerations 931 "nominal": Typically packet loss rate does not have a nominal value, 932 although some networks may specify zero losses. 934 "sla": See the "sla" entry in Section 4.1.4.. 936 "estimation": See the "estimation" entry in Section 4.1.4. For 937 estimation by aggregation of routing protocol link metrics, the 938 default aggregation of the average of loss rate is the sum of the 939 link link loss rates. But this default aggregation is valid only if 940 two conditions are met: (1) it is valid only when link loss rates are 941 low, and (2) it assumes that each link's loss events are uncorrelated 942 with every other link's loss events. When loss rates at the links 943 are high but independent, the general formula for aggregating loss 944 assuming each link is independent is to compute end-to-end loss as 945 one minus the product of the success rate for each link. Aggregation 946 when losses at links are correlated can be more complex and the ALTO 947 server should be cognizant of correlated loss rates. For estimation 948 using IPPM, the IPPM metric MUST be packet loss (i.e., IPPM OWLoss* 949 metrics). The statistical operator of the ALTO metric MUST be 950 consistent with the IPPM statistical property (e.g., 95-th 951 percentile). 953 4.5. Cost Metric: Hop Count (hopcount) 955 The hopcount metric is mentioned in Section 9.2.3 of [RFC7285] as an 956 example. This section further clarifies its properties. 958 4.5.1. Base Identifier 960 The base identifier for this performance metric is "hopcount". 962 4.5.2. Value Representation 964 The metric value type is a single 'JSONNumber' type value conforming 965 to the number specification of Section 6 of [RFC8259]. The number 966 MUST be a non-negative integer (greater than or equal to 0). The 967 value represents the number of hops. 969 4.5.3. Intended Semantics and Use 971 Intended Semantics: To specify the number of hops in the path from 972 the specified source to the specified destination. The hop count is 973 a basic measurement of distance in a network and can be exposed as 974 the number of router hops computed from the routing protocols 975 originating this information. A hop, however, may represent other 976 units. The spatial aggregation level is specified in the query 977 context (e.g., PID to PID, or endpoint to endpoint). 979 Use: This metric could be used as a cost metric constraint attribute 980 or as a returned cost metric in the response. 982 Example 4: hopcount value on source-destination endpoint pairs 984 POST /endpointcost/lookup HTTP/1.1 985 Host: alto.example.com 986 Content-Length: 238 987 Content-Type: application/alto-endpointcostparams+json 988 Accept: 989 application/alto-endpointcost+json,application/alto-error+json 991 { 992 "cost-type": { 993 "cost-mode": "numerical", 994 "cost-metric": "hopcount" 995 }, 996 "endpoints": { 997 "srcs": [ 998 "ipv4:192.0.2.2" 999 ], 1000 "dsts": [ 1001 "ipv4:192.0.2.89", 1002 "ipv4:198.51.100.34" 1003 ] 1004 } 1005 } 1007 HTTP/1.1 200 OK 1008 Content-Length: 245 1009 Content-Type: application/alto-endpointcost+json 1011 { 1012 "meta": { 1013 "cost-type": { 1014 "cost-mode": "numerical", 1015 "cost-metric": "hopcount" 1016 } 1017 }, 1018 "endpoint-cost-map": { 1019 "ipv4:192.0.2.2": { 1020 "ipv4:192.0.2.89": 5, 1021 "ipv4:198.51.100.34": 3 1022 } 1023 } 1024 } 1026 4.5.4. Cost-Context Specification Considerations 1028 "nominal": Typically hop count does not have a nominal value. 1030 "sla": Typically hop count does not have an SLA value. 1032 "estimation": The exact estimation method is out of the scope of this 1033 document. An example of estimating hopcounts is by importing from 1034 IGP routing protocols. It is RECOMMENDED that the "parameters" field 1035 of an "estimation" hop count define the meaning of a hop. 1037 5. Throughput/Bandwidth Performance Metrics 1039 This section introduces four throughput/bandwidth related metrics. 1040 Given a specified source to a specified destination, these metrics 1041 reflect the volume of traffic that the network can carry from the 1042 source to the destination. 1044 5.1. Cost Metric: TCP Throughput (tput) 1046 5.1.1. Base Identifier 1048 The base identifier for this performance metric is "tput". 1050 5.1.2. Value Representation 1052 The metric value type is a single 'JSONNumber' type value conforming 1053 to the number specification of Section 6 of [RFC8259]. The number 1054 MUST be non-negative. The unit is bytes per second. 1056 5.1.3. Intended Semantics and Use 1058 Intended Semantics: To give the throughput of a TCP congestion- 1059 control conforming flow from the specified source to the specified 1060 destination. The throughput SHOULD be interpreted as only an 1061 estimation, and the estimation is designed only for bulk flows. 1063 Use: This metric could be used as a cost metric constraint attribute 1064 or as a returned cost metric in the response. 1066 Example 5: TCP throughput value on source-destination endpoint pairs 1068 POST /endpointcost/lookup HTTP/1.1 1069 Host: alto.example.com 1070 Content-Length: 234 1071 Content-Type: application/alto-endpointcostparams+json 1072 Accept: 1073 application/alto-endpointcost+json,application/alto-error+json 1075 { 1076 "cost-type": { 1077 "cost-mode": "numerical", 1078 "cost-metric": "tput" 1079 }, 1080 "endpoints": { 1081 "srcs": [ 1082 "ipv4:192.0.2.2" 1083 ], 1084 "dsts": [ 1085 "ipv4:192.0.2.89", 1086 "ipv4:198.51.100.34" 1087 ] 1088 } 1089 } 1091 HTTP/1.1 200 OK 1092 Content-Length: 251 1093 Content-Type: application/alto-endpointcost+json 1095 { 1096 "meta": { 1097 "cost-type": { 1098 "cost-mode": "numerical", 1099 "cost-metric": "tput" 1100 } 1101 }, 1102 "endpoint-cost-map": { 1103 "ipv4:192.0.2.2": { 1104 "ipv4:192.0.2.89": 256000, 1105 "ipv4:198.51.100.34": 128000 1106 } 1107 } 1108 } 1110 5.1.4. Cost-Context Specification Considerations 1112 "nominal": Typically TCP throughput does not have a nominal value, 1113 and SHOULD NOT be generated. 1115 "sla": Typically TCP throughput does not have an SLA value, and 1116 SHOULD NOT be generated. 1118 "estimation": The exact estimation method is out of the scope of this 1119 document. It is RECOMMENDED that the "parameters" field of an 1120 "estimation" TCP throughput metric include the following information: 1121 (1) the congestion-control algorithm; and (2) the estimation 1122 methodology. To specify (1), it is RECOMMENDED that the "parameters" 1123 field (object) include a field named "congestion-control-algorithm", 1124 which provides a URI for the specification of the algorithm; for 1125 example, for an ALTO server to provide estimation to the throughput 1126 of a Cubic Congestion control flow, its "parameters" includes a field 1127 "congestion-control-algorithm", with value being set to 1128 [I-D.ietf-tcpm-rfc8312bis]; for an ongoing congestion control 1129 algorithm such as BBR, a a link to its specification. To specify 1130 (2), the "parameters" includes as many details as possible; for 1131 example, for TCP Cubic throughout estimation, the "parameters" field 1132 specifies that the throughput is estimated by setting _C_ to 0.4, and 1133 the Equation in Figure 8 of [I-D.ietf-tcpm-rfc8312bis] is applied; as 1134 an alternative, the methodology may be based on the NUM model 1135 [Prophet], or the G2 model [G2]. The exact specification of the 1136 parameters field is out of the scope of this document. 1138 5.2. Cost Metric: Residual Bandwidth (bw-residual) 1140 5.2.1. Base Identifier 1142 The base identifier for this performance metric is "bw-residual". 1144 5.2.2. Value Representation 1146 The metric value type is a single 'JSONNumber' type value that is 1147 non-negative. The unit of measurement is bytes per second. 1149 5.2.3. Intended Semantics and Use 1151 Intended Semantics: To specify temporal and spatial residual 1152 bandwidth from the specified source and the specified destination. 1153 The base semantics of the metric is the Unidirectional Residual 1154 Bandwidth metric defined in [RFC8571,RFC8570,RFC7471], but instead of 1155 specifying the residual bandwidth for a link, it is the residual 1156 bandwidth of the path from the source to the destination. Hence, it 1157 is the minimal residual bandwidth among all links from the source to 1158 the destination. When the max statistical operator is defined for 1159 the metric, it typically provides the minimum of the link capacities 1160 along the path, as the default value of the residual bandwidth of a 1161 link is its link capacity [RFC8571,8570,7471]. The spatial 1162 aggregation unit is specified in the query context (e.g., PID to PID, 1163 or endpoint to endpoint). 1165 The default statistical operator for residual bandwidth is the 1166 current instantaneous sample; that is, the default is assumed to be 1167 "cur". 1169 Use: This metric could be used either as a cost metric constraint 1170 attribute or as a returned cost metric in the response. 1172 Example 7: bw-residual value on source-destination endpoint pairs 1174 POST /endpointcost/lookup HTTP/1.1 1175 Host: alto.example.com 1176 Content-Length: 241 1177 Content-Type: application/alto-endpointcostparams+json 1178 Accept: 1179 application/alto-endpointcost+json,application/alto-error+json 1181 { 1182 "cost-type": { 1183 "cost-mode": "numerical", 1184 "cost-metric": "bw-residual" 1185 }, 1186 "endpoints": { 1187 "srcs": [ 1188 "ipv4:192.0.2.2" 1189 ], 1190 "dsts": [ 1191 "ipv4:192.0.2.89", 1192 "ipv4:198.51.100.34" 1193 ] 1194 } 1195 } 1196 HTTP/1.1 200 OK 1197 Content-Length: 255 1198 Content-Type: application/alto-endpointcost+json 1200 { 1201 "meta": { 1202 "cost-type": { 1203 "cost-mode": "numerical", 1204 "cost-metric": "bw-residual" 1205 } 1206 }, 1207 "endpoint-cost-map": { 1208 "ipv4:192.0.2.2": { 1209 "ipv4:192.0.2.89": 0, 1210 "ipv4:198.51.100.34": 2000 1211 } 1212 } 1213 } 1215 5.2.4. Cost-Context Specification Considerations 1217 "nominal": Typically residual bandwidth does not have a nominal 1218 value. 1220 "sla": Typically residual bandwidth does not have an "sla" value. 1222 "estimation": See the "estimation" entry in Section 4.1.4 on 1223 aggregation of routing protocol link metrics. The current ("cur") 1224 residual bandwidth of a path is the minimal of the residual bandwidth 1225 of all links on the path. 1227 5.3. Cost Metric: Available Bandwidth (bw-available) 1229 5.3.1. Base Identifier 1231 The base identifier for this performance metric is "bw-available". 1233 5.3.2. Value Representation 1235 The metric value type is a single 'JSONNumber' type value that is 1236 non-negative. The unit of measurement is bytes per second. 1238 5.3.3. Intended Semantics and Use 1240 Intended Semantics: To specify temporal and spatial available 1241 bandwidth from the specified source to the specified destination. 1242 The base semantics of the metric is the Unidirectional Available 1243 Bandwidth metric defined in [RFC8571,RFC8570,RFC7471], but instead of 1244 specifying the available bandwidth for a link, it is the available 1245 bandwidth of the path from the source to the destination. Hence, it 1246 is the minimal available bandwidth among all links from the source to 1247 the destination.The spatial aggregation unit is specified in the 1248 query context (e.g., PID to PID, or endpoint to endpoint). 1250 The default statistical operator for available bandwidth is the 1251 current instantaneous sample; that is, the default is assumed to be 1252 "cur". 1254 Use: This metric could be used either as a cost metric constraint 1255 attribute or as a returned cost metric in the response. 1257 Example 8: bw-available value on source-destination endpoint pairs 1259 POST /endpointcost/lookup HTTP/1.1 1260 Host: alto.example.com 1261 Content-Length: 244 1262 Content-Type: application/alto-endpointcostparams+json 1263 Accept: 1264 application/alto-endpointcost+json,application/alto-error+json 1266 { 1267 "cost-type": { 1268 "cost-mode": "numerical", 1269 "cost-metric": "bw-available" 1270 }, 1271 "endpoints": { 1272 "srcs": [ 1273 "ipv4:192.0.2.2" 1274 ], 1275 "dsts": [ 1276 "ipv4:192.0.2.89", 1277 "ipv4:198.51.100.34" 1278 ] 1279 } 1280 } 1281 HTTP/1.1 200 OK 1282 Content-Length: 255 1283 Content-Type: application/alto-endpointcost+json 1285 { 1286 "meta": { 1287 "cost-type": { 1288 "cost-mode": "numerical", 1289 "cost-metric": "bw-available" 1290 } 1291 }, 1292 "endpoint-cost-map": { 1293 "ipv4:192.0.2.2": { 1294 "ipv4:192.0.2.89": 0, 1295 "ipv4:198.51.100.34": 2000 1296 } 1297 } 1298 } 1300 5.3.4. Cost-Context Specification Considerations 1302 "nominal": Typically available bandwidth does not have a nominal 1303 value. 1305 "sla": Typically available bandwidth does not have an "sla" value. 1307 "estimation": See the "estimation" entry in Section 4.1.4 on 1308 aggregation of routing protocol link metrics. The current ("cur") 1309 available bandwidth of a path is the minimum of the available 1310 bandwidth of all links on the path. 1312 6. Operational Considerations 1314 The exact measurement infrastructure, measurement condition, and 1315 computation algorithms can vary from different networks, and are 1316 outside the scope of this document. Both the ALTO server and the 1317 ALTO clients, however, need to be cognizant of the operational issues 1318 discussed in the following sub-sections. 1320 Also, the performance metrics specified in this document are similar, 1321 in that they may use similar data sources and have similar issues in 1322 their calculation. Hence, this document specifies common issues 1323 unless one metric has its unique challenges. 1325 6.1. Source Considerations 1327 The addition of the "cost-source" field is to solve a key issue: An 1328 ALTO server needs data sources to compute the cost metrics described 1329 in this document, and an ALTO client needs to know the data sources 1330 to better interpret the values. 1332 To avoid too fine-grained information, this document introduces 1333 "cost-source" to indicate only the high-level type of data sources: 1334 "estimation", "nominal" or "lsa", where "estimation" is a type of 1335 measurement data source, "nominal" is a type of static configuration, 1336 and "sla" is a type that is more based on policy. 1338 For estimation, for example, the ALTO server may use log servers or 1339 the OAM system as its data source as recommended by [RFC7971]. In 1340 particular, the cost metrics defined in this document can be computed 1341 using routing systems as the data sources. 1343 6.2. Metric Timestamp Consideration 1345 Despite the introduction of the additional cost-context information, 1346 the metrics do not have a field to indicate the timestamps of the 1347 data used to compute the metrics. To indicate this attribute, the 1348 ALTO server SHOULD return HTTP "Last-Modified", to indicate the 1349 freshness of the data used to compute the performance metrics. 1351 If the ALTO client obtains updates through an incremental update 1352 mechanism [RFC8895], the client SHOULD assume that the metric is 1353 computed using a snapshot at the time that is approximated by the 1354 receiving time. 1356 6.3. Backward Compatibility Considerations 1358 One potential issue introduced by the optional "cost-source" field is 1359 backward compatibility. Consider that an IRD which defines two cost- 1360 types with the same "cost-mode" and "cost-metric", but one with 1361 "cost-source" being "estimation" and the other being "sla". Then an 1362 ALTO client that is not aware of the extension will not be able to 1363 distinguish between these two types. A similar issue can arise even 1364 with a single cost-type, whose "cost-source" is "sla": an ALTO client 1365 that is not aware of this extension will ignore this field and 1366 consider the metric estimation. 1368 To address the backward-compatibility issue, if a "cost-metric" is 1369 "routingcost" and the metric contains a "cost-context" field, then it 1370 MUST be "estimation"; if it is not, the client SHOULD reject the 1371 information as invalid. 1373 6.4. Computation Considerations 1375 The metric values exposed by an ALTO server may result from 1376 additional processing on measurements from data sources to compute 1377 exposed metrics. This may involve data processing tasks such as 1378 aggregating the results across multiple systems, removing outliers, 1379 and creating additional statistics. There are two challenges on the 1380 computation of ALTO performance metrics. 1382 6.4.1. Configuration Parameters Considerations 1384 Performance metrics often depend on configuration parameters, and 1385 exposing such configuration parameters can help an ALTO client to 1386 better understand the exposed metrics. In particular, an ALTO server 1387 may be configured to compute a TE metric (e.g., packet loss rate) in 1388 fixed intervals, say every T seconds. To expose this information, 1389 the ALTO server may provide the client with two pieces of additional 1390 information: (1) when the metrics are last computed, and (2) when the 1391 metrics will be updated (i.e., the validity period of the exposed 1392 metric values). The ALTO server can expose these two pieces of 1393 information by using the HTTP response headers Last-Modified and 1394 Expires. 1396 6.4.2. Aggregation Computation Considerations 1398 An ALTO server may not be able to measure the performance metrics to 1399 be exposed. The basic issue is that the "source" information can 1400 often be link level. For example, routing protocols often measure 1401 and report only per link loss, not end-to-end loss; similarly, 1402 routing protocols report link level available bandwidth, not end-to- 1403 end available bandwidth. The ALTO server then needs to aggregate 1404 these data to provide an abstract and unified view that can be more 1405 useful to applications. The server should consider that different 1406 metrics may use different aggregation computation. For example, the 1407 end-to-end latency of a path is the sum of the latency of the links 1408 on the path; the end-to-end available bandwidth of a path is the 1409 minimum of the available bandwidth of the links on the path; in 1410 contrast, aggregating loss values is complicated by the potential for 1411 correlated loss events on different links in the path 1413 7. Security Considerations 1415 The properties defined in this document present no security 1416 considerations beyond those in Section 15 of the base ALTO 1417 specification [RFC7285]. 1419 However, concerns addressed in Sections 15.1, 15.2, and 15.3 of 1420 [RFC7285] remain of utmost importance. Indeed, Traffic Engineering 1421 (TE) performance is highly sensitive ISP information; therefore, 1422 sharing TE metric values in numerical mode requires full mutual 1423 confidence between the entities managing the ALTO server and the ALTO 1424 client. ALTO servers will most likely distribute numerical TE 1425 performance to ALTO clients under strict and formal mutual trust 1426 agreements. On the other hand, ALTO clients must be cognizant on the 1427 risks attached to such information that they would have acquired 1428 outside formal conditions of mutual trust. 1430 To mitigate confidentiality risks during information transport of TE 1431 performance metrics, the operator should address the risk of ALTO 1432 information being leaked to malicious Clients or third parties, 1433 through attacks such as the person-in-the-middle (PITM) attacks. As 1434 specified in "Protection Strategies" (Section 15.3.2 of [RFC7285]), 1435 the ALTO Server should authenticate ALTO Clients when transmitting an 1436 ALTO information resource containing sensitive TE performance 1437 metrics. "Authentication and Encryption" (Section 8.3.5 of 1438 [RFC7285]) specifies that "ALTO Server implementations as well as 1439 ALTO Client implementations MUST support the "https" URI scheme of 1440 [RFC7230] and Transport Layer Security (TLS) of [RFC8446]". 1442 8. IANA Considerations 1444 IANA has created and now maintains the "ALTO Cost Metric" registry, 1445 listed in Section 14.2, Table 3 of [RFC7285]. This registry is 1446 located at . This document requests to add the 1448 following entries to the "ALTO Cost Metric" registry. 1450 +-----------------+----------------------------+ 1451 | Identifier | Intended Semantics | 1452 +-----------------+----------------------------+ 1453 | delay-ow | Section 4.1 of [RFCXXX] | 1454 | delay-rt | Section 4.2 of [RFCXXX] | 1455 | delay-variation | Section 4.3 of [RFCXXX] | 1456 | lossrate | Section 4.4 of [RFCXXX] | 1457 | hopcount | Section 4.5 of [RFCXXX] | 1458 | tput | Section 5.1 of [RFCXXX] | 1459 | bw-residual | Section 5.2 of [RFCXXX] | 1460 | bw-available | Section 5.3 of [RFCXXX] | 1461 +-----------------+----------------------------+ 1463 * [Note to the RFC Editor]: Please replace RFCXXX with the RFC 1464 number assigned to this document. 1466 This document requests the creation of the "ALTO Cost Source" 1467 registry. This registry serves two purposes. First, it ensures 1468 uniqueness of identifiers referring to ALTO cost source types. 1469 Second, it provides references to particular semantics of allocated 1470 cost source types to be applied by both ALTO servers and applications 1471 utilizing ALTO clients. 1473 A new ALTO cost source can be added after IETF Review [RFC8126], to 1474 ensure that proper documentation regarding the new ALTO cost source 1475 and its security considerations have been provided. The RFC(s) 1476 documenting the new cost source should be detailed enough to provide 1477 guidance to both ALTO service providers and applications utilizing 1478 ALTO clients as to how values of the registered ALTO cost source 1479 should be interpreted. Updates and deletions of ALTO cost source 1480 follow the same procedure. 1482 Registered ALTO address type identifiers MUST conform to the 1483 syntactical requirements specified in Section 3.1. Identifiers are 1484 to be recorded and displayed as strings. 1486 Requests to add a new value to the registry MUST include the 1487 following information: 1489 * Identifier: The name of the desired ALTO cost source type. 1491 * Intended Semantics: ALTO cost source type carry with them 1492 semantics to guide their usage by ALTO clients. Hence, a document 1493 defining a new type should provide guidance to both ALTO service 1494 providers and applications utilizing ALTO clients as to how values 1495 of the registered ALTO endpoint property should be interpreted. 1497 * Security Considerations: ALTO cost source types expose information 1498 to ALTO clients. ALTO service providers should be made aware of 1499 the security ramifications related to the exposure of a cost 1500 source type. 1502 This specification requests registration of the identifiers 1503 "nominal", "sla", and "estimation" listed in the table below. 1504 Semantics for the these are documented in Section 3.1, and security 1505 considerations are documented in Section 7. 1507 +------------+----------------------------------+----------------+ 1508 | Identifier | Intended Semantics | Security | 1509 | | | Considerations | 1510 +------------+----------------------------------+----------------+ 1511 | nominal | Values in nominal cases; | Section 7 of | 1512 | | Section 3.1 of [RFCXXX] | [RFCXXX] | 1513 | sla | Values reflecting service level | Section 7 of | 1514 | | agreement; Section 3.1 of | [RFCXXX] | 1515 | | [RFCXXXX] | | 1516 | estimation | Values by estimation; | Section 7 of | 1517 | | Section 3.1 of [RFCXXX] | [RFCXXX] | 1518 +------------+----------------------------------+----------------+ 1520 9. Acknowledgments 1522 The authors of this document would also like to thank Martin Duke for 1523 the highly informative, thorough AD reviews and comments. We thank 1524 Christian Amsuess, Elwyn Davies, Haizhou Du, Kai Gao, Geng Li, Lili 1525 Liu, Danny Alex Lachos Perez, and Brian Trammell for the reviews and 1526 comments. We thank Benjamin Kaduk, Eric Kline, Francesca Palombini, 1527 Lars Eggert, Martin Vigoureux, Murrary Kucherawy, Roman Danyliw, 1528 Zaheduzzaman Sarker, Eric Vyncke for discussions and comments that 1529 improve this document. 1531 10. References 1533 10.1. Normative References 1535 [I-D.ietf-tcpm-rfc8312bis] 1536 Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, "CUBIC 1537 for Fast and Long-Distance Networks", Work in Progress, 1538 Internet-Draft, draft-ietf-tcpm-rfc8312bis-07, 4 March 1539 2022, . 1542 [IANA-IPPM] 1543 IANA, "Performance Metrics Registry, 1544 https://www.iana.org/assignments/performance-metrics/ 1545 performance-metrics.xhtml". 1547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1548 Requirement Levels", BCP 14, RFC 2119, 1549 DOI 10.17487/RFC2119, March 1997, 1550 . 1552 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1553 (TE) Extensions to OSPF Version 2", RFC 3630, 1554 DOI 10.17487/RFC3630, September 2003, 1555 . 1557 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1558 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1559 2008, . 1561 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 1562 Performance Metric Development", BCP 170, RFC 6390, 1563 DOI 10.17487/RFC6390, October 2011, 1564 . 1566 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1567 Protocol (HTTP/1.1): Message Syntax and Routing", 1568 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1569 . 1571 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1572 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1573 "Application-Layer Traffic Optimization (ALTO) Protocol", 1574 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1575 . 1577 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1578 Previdi, "OSPF Traffic Engineering (TE) Metric 1579 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1580 . 1582 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1583 Writing an IANA Considerations Section in RFCs", BCP 26, 1584 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1585 . 1587 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1588 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1589 May 2017, . 1591 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1592 Interchange Format", STD 90, RFC 8259, 1593 DOI 10.17487/RFC8259, December 2017, 1594 . 1596 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1597 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1598 . 1600 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1601 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1602 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1603 2019, . 1605 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 1606 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 1607 IGP Traffic Engineering Performance Metric Extensions", 1608 RFC 8571, DOI 10.17487/RFC8571, March 2019, 1609 . 1611 [RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic 1612 Optimization (ALTO) Incremental Updates Using Server-Sent 1613 Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November 1614 2020, . 1616 10.2. Informative References 1618 [FlowDirector] 1619 Pujol, E., Poese, I., Zerwas, J., Smaragdakis, G., and A. 1620 Feldmann, "Steering Hyper-Giants' Traffic at Scale", ACM 1621 CoNEXT 2020, 2020. 1623 [G2] Ros-Giralt, J., Bohara, A., Yellamraju, S., and et. al., 1624 "On the Bottleneck Structure of Congestion-Controlled 1625 Networks", ACM SIGMETRICS 2019, 2020. 1627 [I-D.corre-quic-throughput-testing] 1628 Corre, K., "Framework for QUIC Throughput Testing", Work 1629 in Progress, Internet-Draft, draft-corre-quic-throughput- 1630 testing-00, 17 September 2021, 1631 . 1634 [Prometheus] 1635 Volz, J. and B. Rabenstein, "Prometheus: A Next-Generation 1636 Monitoring System", 2015. 1638 [Prophet] Gao, K., Zhang, J., and YR. Yang, "Prophet: Fast, Accurate 1639 Throughput Prediction with Reactive Flows", ACM/IEEE 1640 Transactions on Networking July, 2020. 1642 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1643 "Framework for IP Performance Metrics", RFC 2330, 1644 DOI 10.17487/RFC2330, May 1998, 1645 . 1647 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1648 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 1649 September 1999, . 1651 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1652 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1653 DOI 10.17487/RFC3393, November 2002, 1654 . 1656 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1657 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1658 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1659 . 1661 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1662 Ed., "A One-Way Delay Metric for IP Performance Metrics 1663 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 1664 2016, . 1666 [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 1667 S. Previdi, "Application-Layer Traffic Optimization (ALTO) 1668 Deployment Considerations", RFC 7971, 1669 DOI 10.17487/RFC7971, October 2016, 1670 . 1672 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1673 Multiplexed and Secure Transport", RFC 9000, 1674 DOI 10.17487/RFC9000, May 2021, 1675 . 1677 Authors' Addresses 1679 Qin Wu 1680 Huawei 1681 101 Software Avenue, Yuhua District 1682 Nanjing 1683 Jiangsu, 210012 1684 China 1685 Email: bill.wu@huawei.com 1687 Y. Richard Yang 1688 Yale University 1689 51 Prospect St 1690 New Haven, CT 06520 1691 United States of America 1692 Email: yry@cs.yale.edu 1693 Young Lee 1694 Samsung 1695 Email: young.lee@gmail.com 1697 Dhruv Dhody 1698 Huawei 1699 Leela Palace 1700 Bangalore 560008 1701 Karnataka 1702 India 1703 Email: dhruv.ietf@gmail.com 1705 Sabine Randriamasy 1706 Nokia Bell Labs 1707 Route de Villejust 1708 91460 Nozay 1709 France 1710 Email: sabine.randriamasy@nokia-bell-labs.com 1712 Luis Miguel Contreras Murillo 1713 Telefonica 1714 Madrid 1715 Spain 1716 Email: luismiguel.contrerasmurillo@telefonica.com