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