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