idnits 2.17.1 draft-irtf-panrg-path-properties-03.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 -- The document date (July 09, 2021) is 1016 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-14 == Outdated reference: A later version (-28) exists of draft-ietf-alto-performance-metrics-15 == Outdated reference: A later version (-12) exists of draft-irtf-panrg-questions-09 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANRG T. Enghardt 3 Internet-Draft Netflix 4 Intended status: Informational C. Kraehenbuehl 5 Expires: January 10, 2022 ETH Zuerich 6 July 09, 2021 8 A Vocabulary of Path Properties 9 draft-irtf-panrg-path-properties-03 11 Abstract 13 Path properties express information about paths across a network and 14 the services provided via such paths. In a path-aware network, path 15 properties may be fully or partially available to entities such as 16 hosts. This document defines and categorizes path properties. 17 Furthermore, the document specifies several path properties which 18 might be useful to hosts or other entities, e.g., for selecting 19 between paths or for invoking some of the provided services. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 10, 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Terminology usage for specific technologies . . . . . . . 5 58 3. Use Cases for Path Properties . . . . . . . . . . . . . . . . 5 59 3.1. Path Selection . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Protocol Selection . . . . . . . . . . . . . . . . . . . 6 61 3.3. Service Invocation . . . . . . . . . . . . . . . . . . . 7 62 4. Examples of Path Properties . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 7. Informative References . . . . . . . . . . . . . . . . . . . 10 66 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 69 1. Introduction 71 The current Internet architecture does not explicitly support 72 endpoint discovery of forwarding paths through the network as well as 73 the discovery of properties and services associated with these paths. 74 Path-aware networking, as defined in Section 1.1 of 75 [I-D.irtf-panrg-questions], describes "endpoint discovery of the 76 properties of paths they use for communication across an 77 internetwork, and endpoint reaction to these properties that affects 78 routing and/or data transfer". This document provides a generic 79 definition of path properties, addressing the first of the questions 80 in path-aware networking [I-D.irtf-panrg-questions]. 82 As terms related to paths have been used with different meanings in 83 different areas of networking, first, this document provides a common 84 terminology to define paths, path elements, and flows. Based on 85 these terms, the document defines path properties. Then, this 86 document provides some examples of use cases for path properties. 87 Finally, the document lists several path properties that may be 88 useful for the mentioned use cases. 90 Note that this document does not assume that any of the listed path 91 properties are actually available to any entity. The question of how 92 entities can discover and distribute path properties in a trustworthy 93 way is out of scope for this document. 95 2. Terminology 97 Entity: A physical or virtual device or function, or a collection of 98 devices or functions, which can, for example, process packets, 99 measure path properties, or access information about paths. With 100 respect to a given communication, an entity may be on the data 101 plane or control plane, and it may be on-path or off-path. 103 Node: An entity which processes packets, e.g., sends, receives, 104 forwards, or modifies them. A node may be physical or virtual, 105 e.g., a physical device, a service function provided as a virtual 106 element, or even a single queue within a switch. A node may also 107 be an entity which consists of a collection of devices or 108 functions, e.g., an entire Autonomous System (AS). 110 Host: A node that generally executes application programs on behalf 111 of user(s), employing network and/or Internet communication 112 services in support of this function, as defined in [RFC1122]. 113 Note that hosts include both client nodes (e.g., running a web 114 browser) and server nodes (e.g., running a web server). 116 Link: A medium or communication facility that connects two or more 117 nodes with each other. A link enables a node to send packets to 118 other nodes. Links can be physical, e.g., a Wi-Fi network which 119 connects an Access Point to stations, or virtual, e.g., a virtual 120 switch which connects two virtual machines hosted on the same 121 physical machine. A link is unidirectional. As such, 122 bidirectional communication can be modeled as two links between 123 the same nodes in opposite directions. 125 Path element: Either a node or a link. For example, a path element 126 can be an Abstract Network Element (ANE) as defined in 127 [I-D.ietf-alto-path-vector]. 129 Path: A sequence of adjacent path elements over which a packet can 130 be transmitted, starting and ending with a node. A path is 131 unidirectional. Paths are time-dependent, i.e., the sequence of 132 path elements over which packets are sent from one node to another 133 may change. A path is defined between two nodes. For multicast 134 or broadcast, a packet may be sent by one node and received by 135 multiple nodes. In this case, the packet is sent over multiple 136 paths at once, one path for each combination of sending and 137 receiving node; these paths do not have to be disjoint. Note that 138 an entity may have only partial visibility of the path elements 139 that comprise a path and visibility may change over time. 140 Different entities may have different visibility of a path and/or 141 treat path elements at different levels of abstraction. For 142 example, a path may be given as a sequence of physical nodes and 143 the links connecting these nodes, or it may be given as a sequence 144 of logical nodes such as a sequence of ASes or an Explicit Route 145 Object (ERO). Similarly, the representation of a path and its 146 properties, as it is known to a specific entity, may be more 147 complex and include details about the physical layer technology, 148 or it may be more abstract and only consist of a specific source 149 and destination which is known to be reachable from that source. 151 Reverse Path: The path that is used by a remote node in the context 152 of bidirectional communication. 154 Subpath: Given a path, a subpath is a sequence of adjacent path 155 elements of this path. 157 Flow: One or multiple packets to which the traits of a path or set 158 of subpaths may be applied in a functional sense. For example, a 159 flow can consist of all packets sent within a TCP session with the 160 same five-tuple between two hosts, or it can consist of all 161 packets sent on the same physical link. 163 Property: A trait of one or a sequence of path elements, or a trait 164 of a flow with respect to one or a sequence of path elements. An 165 example of a link property is the maximum data rate that can be 166 sent over the link. An example of a node property is the 167 administrative domain that the node belongs to. An example of a 168 property of a flow with respect to a subpath is the aggregated 169 one-way delay of the flow being sent from one node to another node 170 over this subpath. A property is thus described by a tuple 171 containing the path element(s), the flow or an empty set if no 172 packets are relevant for the property, the name of the property 173 (e.g., maximum data rate), and the value of the property (e.g., 174 1Gbps). 176 Aggregated property: A collection of multiple values of a property 177 into a single value, according to a function. A property can be 178 aggregated over multiple path elements (i.e., a subpath), e.g., 179 the MTU of a path as the minimum MTU of all links on the path, 180 over multiple packets (i.e., a flow), e.g., the median one-way 181 latency of all packets between two nodes, or over both, e.g., the 182 mean of the queueing delays of a flow on all nodes along a path. 183 The aggregation function can be numerical, e.g., median, sum, 184 minimum, it can be logical, e.g., "true if all are true", "true if 185 at least 50\% of values are true", or an arbitrary function which 186 maps multiple input values to an output value. 188 Observed property: A property that is observed for a specific path 189 element, subpath, or path, e.g., using measurements. For example, 190 the one-way delay of a specific packet transmitted from one node 191 to another node can be measured. 193 Assessed property: An approximate calculation or assessment of the 194 value of a property. An assessed property includes the 195 reliability of the calculation or assessment. The notion of 196 reliability depends on the property. For example, a path property 197 based on an approximate calculation may describe the expected 198 median one-way latency of packets sent on a path within the next 199 second, including the confidence level and interval. A non- 200 numerical assessment may instead include the likelihood that the 201 property holds. 203 2.1. Terminology usage for specific technologies 205 The terminology defined in this document is intended to be general 206 and applicable to existing and future path-aware technologies. Using 207 this terminology, a path-aware technology can define and consider 208 specific path elements and path properties on a specific level of 209 abstraction. For instance, a technology may define path elements as 210 IP routers, e.g., in source routing ([RFC1940]). Alternatively, it 211 may consider path elements on a different layer of the Internet 212 Architecture ([RFC1122]) or as a collection of entities not tied to a 213 specific layer, such as an AS or an ERO. 215 3. Use Cases for Path Properties 217 When a path-aware network exposes path properties to hosts or other 218 entities, these entities may use this information to achieve 219 different goals. This section lists several use cases for path 220 properties. 222 Note that this is not an exhaustive list, as with every new 223 technology and protocol, novel use cases may emerge, and new path 224 properties may become relevant. Moreover, for any particular 225 technology, entities may have visibility of and control over 226 different path elements and path properties, and consider them on 227 different levels of abstraction. Therefore, a new technology may 228 implement an existing use case related to different path elements or 229 on a different level of abstraction. 231 3.1. Path Selection 233 Nodes may be able to send flows via one (or a subset) out of multiple 234 possible paths, and an entity may be able to influence the decision 235 which path(s) to use. Path Selection may be feasible if there are 236 several paths to the same destination (e.g., in case of a mobile 237 device with two wireless interfaces, both providing a path), or if 238 there are several destinations, and thus several paths, providing the 239 same service (e.g., Application-Layer Traffic Optimization (ALTO) 240 [RFC5693], an application layer peer-to-peer protocol allowing hosts 241 a better-than-random peer selection). Care needs to be taken when 242 selecting paths based on path properties, as path properties that 243 were previously measured may not be helpful in predicting current or 244 future path properties and such path selection may lead to unintended 245 feedback loops. 247 Entities may select their paths to fulfill a specific goal, e.g., 248 related to security or performance. As an example of security- 249 related path selection, an entity may allow or disallow sending flows 250 over paths involving specific networks or nodes to enforce traffic 251 policies. In an enterprise network where all traffic has to go 252 through a specific firewall, a path-aware entity can implement this 253 policy using path selection. As an example of performance-related 254 path selection, an entity may prefer paths with performance 255 properties that best match application requirements. For example, 256 for sending a small delay sensitive query, the entity may select a 257 path with a short One-Way Delay, while for retrieving a large file, 258 it may select a path with high Link Capacities on all links. Note, 259 there may be trade-offs between path properties (e.g., One-Way Delay 260 and Link Capacity), and entities may influence these trade-offs with 261 their choices. As a baseline, a path selection algorithm should aim 262 to not perform worse than the default case most of the time. 264 Path selection can be done either by the communicating node(s) or by 265 other entities within the network: A network (e.g., an AS) can adjust 266 its path selection for internal or external routing based on path 267 properties. In BGP, the Multi Exit Discriminator (MED) attribute is 268 used in the decision-making process to select which path to choose 269 among those having the same AS PATH length and origin [RFC4271]; in a 270 path-aware network, instead of using this single MED value, other 271 properties such as Link Capacity or Link Usage could additionally be 272 used to improve load balancing or performance 273 [I-D.ietf-idr-performance-routing]. 275 3.2. Protocol Selection 277 Before sending data over a specific path, an entity may select an 278 appropriate protocol or configure protocol parameters depending on 279 path properties. A host may cache state on whether a path allows the 280 use of QUIC [I-D.ietf-quic-transport] and if so, first attempt to 281 connect using QUIC before falling back to another protocol when 282 connecting over this path again. A video streaming application may 283 choose an (initial) video quality based on the achievable data rate 284 or the monetary cost of sending data (e.g., volume-base or flat-rate 285 cost model). 287 3.3. Service Invocation 289 In addition to path or protocol selection, an entity may choose to 290 invoke additional functions in the context of Service Function 291 Chaining [RFC7665], which may influence what nodes are on the path. 292 For example, a 0-RTT Transport Converter [I-D.ietf-tcpm-converters] 293 will be involved in a path only when invoked by a host; such 294 invocation will lead to the use of MPTCP or TCPinc capabilities while 295 such use is not supported via the default forwarding path. Another 296 example is a connection which is composed of multiple streams where 297 each stream has specific service requirements. A host may decide to 298 invoke a given service function (e.g., transcoding) only for some 299 streams while others are not processed by that service function. 301 4. Examples of Path Properties 303 This Section gives some examples of path properties which may be 304 useful, e.g., for the use cases described in Section 3. 306 Within the context of any particular technology, available path 307 properties may differ as entities have insight into and are able to 308 influence different path elements and path properties. For example, 309 a host may have some visibility into path elements that are on a low 310 level of abstraction and close, e.g., individual nodes within the 311 first few hops, or it may have visibility into path elements that are 312 far away and/or on a higher level of abstraction, e.g., the list of 313 ASes traversed. This visibility may depend on factors such as the 314 physical or network distance or the existence of trust or contractual 315 relationships between the host and the path element(s). 317 Path properties may be relatively dynamic, e.g., the one-way delay of 318 a packet sent over a specific path, or non-dynamic, e.g., the MTU of 319 an Ethernet link which only changes infrequently. Usefulness over 320 time differs depending on how dynamic a property is: The merit of a 321 momentary measurement of a dynamic path property diminishes greatly 322 as time goes on, e.g. the merit of an RTT measurement from a few 323 seconds ago is quite small, while a non-dynamic path property might 324 stay relevant for a longer period of time, e.g. a NAT typically stays 325 on a specific path during the lifetime of a connection involving 326 packets sent over this path. 328 Access Technology: The physical or link layer technology used for 329 transmitting or receiving a flow on one or multiple path elements. 330 If known, the Access Technology may be given as an abstract link 331 type, e.g., as Wi-Fi, Wired Ethernet, or Cellular. It may also be 332 given as a specific technology used on a link, e.g., 2G, 3G, 4G, 333 or 5G cellular, or 802.11a, b, g, n, or ac Wi-Fi. Other path 334 elements relevant to the access technology may include nodes 335 related to processing packets on the physical or link layer, such 336 as elements of a cellular backbone network. Note that there is no 337 common registry of possible values for this property. 339 Monetary Cost: The price to be paid to transmit or receive a 340 specific flow across a network to which one or multiple path 341 elements belong. 343 Service function: A service function that a path element applies to 344 a flow, see [RFC7665]. Examples of abstract service functions 345 include firewalls, Network Address Translation (NAT), and TCP 346 optimizers. Some stateful service functions, such as NAT, need to 347 observe the same flow in both directions, e.g., by being an 348 element of both the path and the reverse path. 350 Transparency: When a node performs an action on a flow, the node is 351 transparent to the flow with respect to some (meta-)information if 352 the node performs this action independently of the given 353 (meta-)information. (Meta-)information can for example be the 354 existence of a protocol (header) in a packet or the content of a 355 protocol header, payload, or both. Actions can for example be 356 blocking packets or reading and modifying (other protocol) headers 357 or payloads. An IP router could be transparent to transport 358 protocol headers such as TCP/UDP but not transparent to IP headers 359 since its forwarding behavior depends on the IP headers. A 360 firewall that only allows outgoing TCP connections by blocking all 361 incoming TCP SYN packets regardless of their IP address is 362 transparent to IP but not to TCP headers. Finally, a NAT that 363 actively modifies IP and TCP/UDP headers based on their content is 364 not transparent to either IP or TCP/UDP headers. Note that 365 according to this definition, a node that modifies packets in 366 accordance with the hosts, such as a transparent HTTP proxy, as 367 defined in [RFC2616], and a node listening and reacting to 368 implicit or explicit signals, see [RFC8558], are not considered 369 transparent. 371 Administrative Domain: The administrative domain, e.g., the IGP 372 area, AS, or Service provider network to which a path element 373 belongs. 375 Disjointness: For a set of two paths or subpaths, the number of 376 shared path elements can be a measure of intersection (e.g., 377 Jaccard coefficient, which is the number of shared elements 378 divided by the total number of elements). Conversely, the number 379 of non-shared path elements can be a measure of disjointness 380 (e.g., 1 - Jaccard coefficient). A multipath protocol might use 381 disjointness as a metric to reduce the number of single points of 382 failure. 384 Symmetric Path: Two paths are symmetric if the path and its reverse 385 path consist of the same path elements on the same level of 386 abstraction, but in reverse order. For example, a path which 387 consists of layer 3 switches and links between them and a reverse 388 path with the same path elements but in reverse order are 389 considered "routing" symmetric, as the same path elements on the 390 same level of abstraction (IP forwarding) are traversed in the 391 opposite direction. 393 Path MTU: The maximum size, in octets, of an IP packet that can be 394 transmitted without fragmentation. 396 Transport Protocols available: Whether a specific transport protocol 397 can be used to establish a connection over a path or subpath, 398 e.g., whether the path is QUIC-capable or MPTCP-capable, based on 399 cached knowledge. 401 Protocol Features available: Whether a specific protocol feature is 402 available over a path or subpath, e.g., Explicit Congestion 403 Notification (ECN), or TCP Fast Open. 405 Some path properties express the performance of the transmission of a 406 packet or flow over a link or subpath. Such transmission performance 407 properties can be measured or approximated, e.g., by hosts or by path 408 elements on the path, or they may be available as cost metrics, see 409 [I-D.ietf-alto-performance-metrics]. Transmission performance 410 properties may be made available in an aggregated form, such as 411 averages or minimums. Properties related to a path element which 412 constitutes a single layer 2 domain are abstracted from the used 413 physical and link layer technology, similar to [RFC8175]. 415 Link Capacity: The link capacity is the maximum data rate at which 416 data that was sent over a link can correctly be received at the 417 node adjacent to the link. This property is analogous to the link 418 capacity defined in [RFC5136] but not restricted to IP-layer 419 traffic. 421 Link Usage: The link usage is the actual data rate at which data 422 that was sent over a link is correctly received at the node 423 adjacent to the link. This property is analogous to the link 424 usage defined in [RFC5136] but not restricted to IP-layer traffic. 426 One-Way Delay: The one-way delay is the delay between a node sending 427 a packet and another node on the same path receiving the packet. 428 This property is analogous to the one-way delay defined in 429 [RFC7679] but not restricted to IP-layer traffic. 431 One-Way Delay Variation: The variation of the one-way delays within 432 a flow. This property is similar to the one-way delay variation 433 defined in [RFC3393] but not restricted to IP-layer traffic and 434 defined for packets on the same flow instead of packets sent 435 between a source and destination IP address. 437 One-Way Packet Loss: Packets sent by a node but not received by 438 another node on the same path after a certain time interval are 439 considered lost. This property is analogous to the one-way loss 440 defined in [RFC7680] but not restricted to IP-layer traffic. 441 Metrics such as loss patterns [RFC3357] and loss episodes 442 [RFC6534] can be expressed as aggregated properties. 444 5. Security Considerations 446 If nodes are basing policy or path selection decisions on path 447 properties, they need to rely on the accuracy of path properties that 448 other devices communicate to them. In order to be able to trust such 449 path properties, nodes may need to establish a trust relationship or 450 be able to verify the authenticity, integrity, and correctness of 451 path properties received from another node. 453 Security related properties such as confidentiality and integrity 454 protection of payloads are difficult to characterize since they are 455 only meaningful with respect to a threat model which depends on the 456 use case, application, environment, and other factors. Likewise, 457 properties for trust relations between nodes cannot be meaningfully 458 defined without a concrete threat model, and defining a threat model 459 is out of scope for this draft. Properties related to 460 confidentiality, integrity, and trust are orthogonal to the path 461 terminology and path properties defined in this document. Such 462 properties are tied to the communicating nodes and the protocols they 463 use (e.g., client and server using HTTPS, or client and remote 464 network node using VPN) while the path is typically oblivious to 465 them. Intuitively, the path describes what function the network 466 applies to packets, while confidentiality, integrity, and trust 467 describe what function the communicating parties apply to packets. 469 6. IANA Considerations 471 This document has no IANA actions. 473 7. Informative References 475 [I-D.ietf-alto-path-vector] 476 Gao, K., Lee, Y., Randriamasy, S., Yang, Y. R., and J. J. 477 Zhang, "ALTO Extension: Path Vector", draft-ietf-alto- 478 path-vector-14 (work in progress), February 2021. 480 [I-D.ietf-alto-performance-metrics] 481 Wu, Q., Yang, Y. R., Lee, Y., Dhody, D., Randriamasy, S., 482 and L. M. Contreras, "ALTO Performance Cost Metrics", 483 draft-ietf-alto-performance-metrics-15 (work in progress), 484 February 2021. 486 [I-D.ietf-idr-performance-routing] 487 Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C. 488 Jacquenet, "Performance-based BGP Routing Mechanism", 489 draft-ietf-idr-performance-routing-03 (work in progress), 490 December 2020. 492 [I-D.ietf-quic-transport] 493 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 494 and Secure Transport", draft-ietf-quic-transport-34 (work 495 in progress), January 2021. 497 [I-D.ietf-tcpm-converters] 498 Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., 499 and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- 500 tcpm-converters-19 (work in progress), March 2020. 502 [I-D.irtf-panrg-questions] 503 Trammell, B., "Current Open Questions in Path Aware 504 Networking", draft-irtf-panrg-questions-09 (work in 505 progress), April 2021. 507 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 508 Communication Layers", STD 3, RFC 1122, 509 DOI 10.17487/RFC1122, October 1989, 510 . 512 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 513 Zappala, "Source Demand Routing: Packet Format and 514 Forwarding Specification (Version 1)", RFC 1940, 515 DOI 10.17487/RFC1940, May 1996, 516 . 518 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 519 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 520 Transfer Protocol -- HTTP/1.1", RFC 2616, 521 DOI 10.17487/RFC2616, June 1999, 522 . 524 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 525 Metrics", RFC 3357, DOI 10.17487/RFC3357, August 2002, 526 . 528 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 529 Metric for IP Performance Metrics (IPPM)", RFC 3393, 530 DOI 10.17487/RFC3393, November 2002, 531 . 533 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 534 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 535 DOI 10.17487/RFC4271, January 2006, 536 . 538 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 539 RFC 5136, DOI 10.17487/RFC5136, February 2008, 540 . 542 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 543 Optimization (ALTO) Problem Statement", RFC 5693, 544 DOI 10.17487/RFC5693, October 2009, 545 . 547 [RFC6534] Duffield, N., Morton, A., and J. Sommers, "Loss Episode 548 Metrics for IP Performance Metrics (IPPM)", RFC 6534, 549 DOI 10.17487/RFC6534, May 2012, 550 . 552 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 553 Chaining (SFC) Architecture", RFC 7665, 554 DOI 10.17487/RFC7665, October 2015, 555 . 557 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 558 Ed., "A One-Way Delay Metric for IP Performance Metrics 559 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 560 2016, . 562 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 563 Ed., "A One-Way Loss Metric for IP Performance Metrics 564 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 565 2016, . 567 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 568 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 569 DOI 10.17487/RFC8175, June 2017, 570 . 572 [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", 573 RFC 8558, DOI 10.17487/RFC8558, April 2019, 574 . 576 Acknowledgments 578 Thanks to the Path-Aware Networking Research Group for the discussion 579 and feedback. Specifically, thanks to Mohamed Boudacair for the 580 detailed review and various text suggestions, thanks to Brian 581 Trammell for suggesting the flow definition, and thanks to Adrian 582 Perrig and Matthias Rost for the detailed feedback. Thanks to Paul 583 Hoffman for the editorial changes. 585 Authors' Addresses 587 Theresa Enghardt 588 Netflix 590 Email: ietf@tenghardt.net 592 Cyrill Kraehenbuehl 593 ETH Zuerich 595 Email: cyrill.kraehenbuehl@inf.ethz.ch