diff options
Diffstat (limited to 'doc/rfc/rfc9473.txt')
| -rw-r--r-- | doc/rfc/rfc9473.txt | 759 |
1 files changed, 759 insertions, 0 deletions
diff --git a/doc/rfc/rfc9473.txt b/doc/rfc/rfc9473.txt new file mode 100644 index 0000000..f069206 --- /dev/null +++ b/doc/rfc/rfc9473.txt @@ -0,0 +1,759 @@ + + + + +Internet Research Task Force (IRTF) R. Enghardt +Request for Comments: 9473 Netflix +Category: Informational C. Krähenbühl +ISSN: 2070-1721 ETH Zürich + September 2023 + + + A Vocabulary of Path Properties + +Abstract + + Path properties express information about paths across a network and + the services provided via such paths. In a path-aware network, path + properties may be fully or partially available to entities such as + endpoints. This document defines and categorizes path properties. + Furthermore, the document identifies several path properties that + might be useful to endpoints or other entities, e.g., for selecting + between paths or for invoking some of the provided services. This + document is a product of the Path Aware Networking Research Group + (PANRG). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Research Task Force + (IRTF). The IRTF publishes the results of Internet-related research + and development activities. These results might not be suitable for + deployment. This RFC represents the consensus of the Path Aware + Networking Research Group of the Internet Research Task Force (IRTF). + Documents approved for publication by the IRSG are not candidates for + any level of Internet Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9473. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction + 2. Terminology + 2.1. Terminology Usage for Specific Technologies + 3. Use Cases for Path Properties + 3.1. Path Selection + 3.2. Protocol Selection + 3.3. Service Invocation + 4. Examples of Path Properties + 5. Security Considerations + 6. IANA Considerations + 7. Informative References + Acknowledgments + Authors' Addresses + +1. Introduction + + The current Internet architecture does not explicitly support + endpoint discovery of forwarding paths through the network nor the + discovery of properties and services associated with these paths. + Path-aware networking, as defined in Section 1.1 of [RFC9217], + describes "endpoint discovery of the properties of paths they use for + communication across an internetwork, and endpoint reaction to these + properties that affects routing and/or data transfer". This document + provides a generic definition of path properties, addressing the + first of the questions in path-aware networking [RFC9217]. + + As terms related to paths have been used with different meanings in + different areas of networking, first, this document provides a common + terminology to define paths, path elements, and flows. Based on + these terms, the document defines path properties. Then, this + document provides some examples of use cases for path properties. + Finally, the document lists several path properties that may be + useful for the mentioned use cases. This list is intended to be + neither exhaustive nor definitive. + + Note that this document does not assume that any of the listed path + properties are actually available to any entity. The question of how + entities can discover and distribute path properties in a trustworthy + way is out of scope for this document. + + This document represents the consensus of the Path Aware Networking + Research Group (PANRG). + +2. Terminology + + Entity: A physical or virtual device or function, or a collection of + devices or functions, that plays a role related to path-aware + networking for particular paths and flows. An entity can be on- + path or off-path. On the path, an entity may participate in + forwarding the flow, i.e., what may be called "data plane + functionality". On or off the path, an entity may influence + aspects of how the flow is forwarded, i.e., what may be called + "control plane functionality", such as path selection or service + invocation. An entity influencing forwarding aspects is usually + aware of path properties, e.g., by observing or measuring them or + by learning them from another entity. + + Node: An on-path entity that processes packets, e.g., sends, + receives, forwards, or modifies them. A node may be physical or + virtual, e.g., a physical device, a service function provided as a + virtual element, or even a single queue within a switch. A node + may also be an entity that consists of a collection of devices or + functions, e.g., an entire Autonomous System (AS). + + Link: A medium or communication facility that connects two or more + nodes with each other. A link enables a node to send packets to + other nodes. Links can be physical, e.g., a Wi-Fi network that + connects an Access Point to stations, or virtual, e.g., a virtual + switch that connects two virtual machines hosted on the same + physical machine. A link is unidirectional. As such, + bidirectional communication can be modeled as two links between + the same nodes in opposite directions. + + Path element: Either a node or a link. For example, a path element + can be an Abstract Network Element (ANE) as defined in [RFC9275]. + + Path: A sequence of adjacent path elements over which a packet can + be transmitted, starting and ending with a node. + + Paths are unidirectional and time dependent, i.e., there can be a + variety of paths from one node to another, and the path over which + packets are transmitted may change. A path definition can be + strict (i.e., the exact sequence of path elements remains the + same) or loose (i.e., the start and end node remain the same, but + the path elements between them may vary over time). + + The representation of a path and its properties may depend on the + entity considering the path. On the one hand, the representation + may differ due to entities having partial visibility of path + elements comprising a path or their visibility changing over time. + On the other hand, the representation may differ due to treating + path elements at different levels of abstraction. For example, a + path may be given as a sequence of physical nodes and the links + connecting these nodes, be given as a sequence of logical nodes + such as a sequence of ASes or an Explicit Route Object (ERO), or + only consist of a specific source and destination that is known to + be reachable from that source. + + A multicast or broadcast setting where a packet is sent by one + node and received by multiple nodes is described by multiple paths + over which the packet is sent, one path for each combination of + sending and receiving node; these paths do not have to be disjoint + as defined by the disjointness path property, see Section 4. + + Endpoint: The endpoints of a path are the start and end node of the + path. For example, an endpoint can be a host as defined in + [RFC1122], which can be a client (e.g., a node running a web + browser) or a server (e.g., a node running a web server). + + Reverse Path: The path that is used by a remote node in the context + of bidirectional communication. + + Subpath: Given a path, a subpath is a sequence of adjacent path + elements of this path. + + Flow: One or multiple packets to which the traits of a path or set + of subpaths may be applied in a functional sense. For example, a + flow can consist of all packets sent within a TCP session with the + same five-tuple between two hosts, or it can consist of all + packets sent on the same physical link. + + Property: A trait of one or a sequence of path elements, or a trait + of a flow with respect to one or a sequence of path elements. An + example of a link property is the maximum data rate that can be + sent over the link. An example of a node property is the + administrative domain that the node belongs to. An example of a + property of a flow with respect to a subpath is the aggregated + one-way delay of the flow being sent from one node to another node + over this subpath. A property is thus described by a tuple + containing the path element(s), the flow or an empty set if no + packets are relevant for the property, the name of the property + (e.g., maximum data rate), and the value of the property (e.g., 1 + Gbps). + + Aggregated property: A collection of multiple values of a property + into a single value, according to a function. A property can be + aggregated over: + + * multiple path elements (i.e., a subpath), for example, the MTU + of a path as the minimum MTU of all links on the path, + + * multiple packets (i.e., a flow), for example, the median one- + way latency of all packets between two nodes, + + * or both path elements and packets, for example, the mean of the + queueing delays of a flow on all nodes along a path. + + The aggregation function can be numerical (e.g., median, sum, + minimum) or logical (e.g., "true if all are true", "true if at + least 50% of values are true"), or it can be an arbitrary function + that maps multiple input values to an output value. + + Observed property: A property that is observed for a specific path + element, subpath, or path. A property may be observed using + measurements, for example, the one-way delay of a specific packet + transmitted from node to node. + + Assessed property: An approximate calculation or assessment of the + value of a property. An assessed property includes the + reliability of the calculation or assessment. The notion of + reliability depends on the property. For example, a path property + based on an approximate calculation may describe the expected + median one-way latency of packets sent on a path within the next + second, including the confidence level and interval. A non- + numerical assessment may instead include the likelihood that the + property holds. + + Target property: An objective that is set for a property over a path + element, subpath, or path. Note that a target property can be set + for observed properties, such as one-way delay, and also for + properties that cannot be observed by the entity setting the + target, such as inclusion of certain nodes on a path. + +2.1. Terminology Usage for Specific Technologies + + The terminology defined in this document is intended to be general + and applicable to existing and future path-aware technologies. Using + this terminology, a path-aware technology can define and consider + specific path elements and path properties on a specific level of + abstraction. For instance, a technology may define path elements as + IP routers, e.g., in source routing [RFC1940]. Alternatively, it may + consider path elements on a different layer of the Internet + architecture [RFC1122] or as a collection of entities not tied to a + specific layer, such as an AS or ERO. Even within a single path- + aware technology, specific definitions might differ depending on the + context in which they are used. For example, the endpoints might be + the communicating hosts in the context of the transport layer, ASes + that contain the hosts in the context of routing, or specific + applications in the context of the application layer. + +3. Use Cases for Path Properties + + When a path-aware network exposes path properties to endpoints or + other entities, these entities may use this information to achieve + different goals. This section lists several use cases for path + properties. + + Note that this is not an exhaustive list; as with every new + technology and protocol, novel use cases may emerge, and new path + properties may become relevant. Moreover, for any particular + technology, entities may have visibility of and control over + different path elements and path properties and consider them on + different levels of abstraction. Therefore, a new technology may + implement an existing use case related to different path elements or + on a different level of abstraction. + +3.1. Path Selection + + Nodes may be able to send flows via one (or a subset) out of multiple + possible paths, and an entity may be able to influence the decision + about which path(s) to use. Path selection may be feasible if there + are several paths to the same destination (e.g., in case of a mobile + device with two wireless interfaces, both providing a path) or if + there are several destinations, and thus several paths, providing the + same service (e.g., Application-Layer Traffic Optimization (ALTO) + [RFC5693], an application layer peer-to-peer protocol allowing + endpoints a better-than-random peer selection). Entities can express + their intent to achieve a specific goal by specifying target + properties for their paths, e.g., related to performance or security. + Then, paths can be selected that best meet the target properties, + e.g., the entity can select these paths from all available paths or + express the target properties to the network and rely on the network + to select appropriate paths. + + Target properties relating to network performance typically refer to + observed properties, such as one-way delay, one-way packet loss, and + link capacity. Entities then select paths based on their target + property and the assessed property of the available paths that best + match the application requirements. For such performance-related + target properties, the observed property is similar to a Service + Level Indicator (SLI), and the assessed property is similar to a + Service Level Objective (SLO) for IETF Network Slices + [NETWORK-SLICES]. As an example path-selection strategy, an entity + may select a path with a short one-way delay for sending a small + delay-sensitive query, while it may select a path with high link + capacities on all links for retrieving a large file. + + It is also possible for an entity to set target properties that it + cannot (directly) observe, similar to Service Level Expectations + (SLEs) for IETF Network Slices [NETWORK-SLICES]. This may apply to + security-related target properties (e.g., to mandate that all + enterprise traffic goes through a specific firewall) and path + selection (e.g., to enforce traffic policies by allowing or + disallowing sending flows over paths that involve specific networks + or nodes). + + Care needs to be taken when selecting paths based on observed path + properties, as path properties that were previously measured may not + be helpful in predicting current or future path properties, and such + path selection may lead to unintended feedback loops. Also, there + may be trade-offs between path properties (e.g., one-way delay and + link capacity), and entities may influence these trade-offs with + their choices. Finally, path selection may impact fairness. For + example, if multiple entities concurrently attempt to meet their + target properties using the same network resources, one entity's + choices may influence the conditions on the path as experienced by + flows of another entity. + + As a baseline, a path-selection algorithm should aim to do a better + job of meeting the target properties, and consequently accommodating + the user's requirements, than the default case of not selecting a + path most of the time. + + Path selection can be done either by the communicating node(s) or by + other entities within the network. A network (e.g., an AS) can + adjust its path selection for internal or external routing based on + path properties. In BGP, the Multi-Exit Discriminator (MED) + attribute is used in the decision-making process to select which path + to choose among those having the same AS path length and origin + [RFC4271]; in a path-aware network, instead of using this single MED + value, other properties such as link capacity or link usage could + additionally be used to improve load balancing or performance + [PERFORMANCE-ROUTING]. + +3.2. Protocol Selection + + Before sending data over a specific path, an entity may select an + appropriate protocol or configure protocol parameters depending on + path properties. For example, an endpoint may cache state if a path + allows the use of QUIC [RFC9000]; if so, it may first attempt to + connect using QUIC before falling back to another protocol when + connecting over this path again. A video-streaming application may + choose an (initial) video quality based on the achievable data rate + or the monetary cost of sending data (e.g., volume-based or flat-rate + cost model). + +3.3. Service Invocation + + In addition to path or protocol selection, an entity may choose to + invoke additional functions in the context of Service Function + Chaining [RFC7665], which may influence which nodes are on the path. + For example, a 0-RTT Transport Converter [RFC8803] will be involved + in a path only when invoked by an endpoint; such invocation will lead + to the use of Multipath TCP (MPTCP) [RFC8684] or tcpcrypt [RFC8548] + capabilities, while such use is not supported via the default + forwarding path. Another example is a connection that is composed of + multiple streams where each stream has specific service requirements. + An endpoint may decide to invoke a given service function (e.g., + transcoding) only for some streams while others are not processed by + that service function. + +4. Examples of Path Properties + + This section gives some examples of path properties that may be + useful, e.g., for the use cases described in Section 3. + + Within the context of any particular technology, available path + properties may differ as entities have insight into and are able to + influence different path elements and path properties. For example, + an endpoint may have some visibility into path elements that are + close and on a low level of abstraction (e.g., individual nodes + within the first few hops), or it may have visibility into path + elements that are far away and/or on a higher level of abstraction + (e.g., the list of ASes traversed). This visibility may depend on + factors such as the physical or network distance or the existence of + trust or contractual relationships between the endpoint and the path + element(s). A path property can be defined relative to individual + path elements, a sequence of path elements, or "end-to-end", i.e., + relative to a path that comprises of two endpoints and a single + virtual link connecting them. + + Path properties may be relatively dynamic, e.g., the one-way delay of + a packet sent over a specific path, or non-dynamic, e.g., the MTU of + an Ethernet link that only changes infrequently. Usefulness over + time differs depending on how dynamic a property is: the merit of a + momentarily observed dynamic path property may diminish greatly as + time goes on, e.g., it is possible for the observed values of one-way + delay to change on timescales that are shorter than the one-way delay + between the measurement point and an entity making a decision such as + path selection, which may cause the measurement to be outdated when + it reaches the decision-making entity. Therefore, consumers of + dynamic path properties need to apply caution when using them, e.g., + by aggregating them appropriately or applying a dampening function to + their changes to avoid oscillation. In contrast, the observed value + of a less dynamic path property might stay relevant for a longer + period of time, e.g., a NAT typically stays on a particular path + during the lifetime of a connection involving packets sent over this + path. + + Access Technology: The physical- or link-layer technology used for + transmitting or receiving a flow on one or multiple path elements. + If known, the access technology may be given as an abstract link + type, e.g., as Wi-Fi, wired Ethernet, or cellular. It may also be + given as a specific technology used on a link, e.g., 3GPP cellular + or 802.11 Wireless Local Area Network (WLAN). Other path elements + relevant to the access technology may include nodes related to + processing packets on the physical or link layer, such as elements + of a cellular core network. Note that there is no common registry + of possible values for this property. + + Monetary Cost: The price to be paid to transmit or receive a + specific flow across a network to which one or multiple path + elements belong. + + Service Function: A service function that a path element applies to + a flow, see [RFC7665]. Examples of abstract service functions + include firewalls, Network Address Translation (NAT), and TCP + Performance Enhancing Proxies. Some stateful service functions, + such as NAT, need to observe the same flow in both directions, + e.g., by being an element of both the path and the reverse path. + + Transparency: When a node performs an action A on a flow F, the node + is transparent to F with respect to some (meta-)information M if + the node performs A independently of M. M can, for example, be + the existence of a protocol (header) in a packet or the content of + a protocol header, payload, or both. For example, A can be + blocking packets or reading and modifying (other protocol) headers + or payloads. Transparency can be modeled using a function f, + which takes as input F and M and outputs the action taken by the + node. If a taint analysis shows that the output of f is not + tainted (impacted) by M, or if the output of f is constant for + arbitrary values of M, then the node is considered to be + transparent. An IP router could be transparent to transport + protocol headers such as TCP/UDP but not transparent to IP headers + since its forwarding behavior depends on the IP headers. A + firewall that only allows outgoing TCP connections by blocking all + incoming TCP SYN packets regardless of their IP address is + transparent to IP but not to TCP headers. Finally, a NAT that + actively modifies IP and TCP/UDP headers based on their content is + not transparent to either IP or TCP/UDP headers. Note that + according to this definition, a node that modifies packets in + accordance with the endpoints, such as a transparent HTTP proxy, + as defined in [RFC9110], and a node listening and reacting to + implicit or explicit signals, see [RFC8558], are not considered + transparent. + + Transparency only applies to nodes and not to links, as a link + cannot modify or perform any other actions on the packets by + itself. For example, if the content of a packet is altered when + forwarded over a Generic Routing Encapsulation (GRE) tunnel + [RFC2784] [RFC7676], per this document the software instances that + terminate the tunnel are considered nodes over which the actions + are performed; thus, the transparency definition applies to these + nodes. + + Administrative Domain: The identity of an individual or an + organization that controls access to a path element (or several + path elements). Examples of administrative domains are an IGP + area, an AS, or a service provider network. + + Routing Domain Identifier: An identifier indicating the routing + domain of a path element. Path elements in the same routing + domain are in the same administrative domain and use a common + routing protocol to communicate with each other. An example of a + routing domain identifier is the globally unique Autonomous System + Number (ASN) as defined in [RFC1930]. + + Disjointness: For a set of two paths or subpaths, the number of + shared path elements can be a measure of intersection (e.g., + Jaccard coefficient, which is the number of shared elements + divided by the total number of elements). Conversely, the number + of non-shared path elements can be a measure of disjointness + (e.g., 1 - Jaccard coefficient). A multipath protocol might use + disjointness as a metric to reduce the number of single points of + failure. As paths can be defined at different levels of + abstraction, two paths may be disjoint at one level of abstraction + but not on another. + + Symmetric Path: Two paths are symmetric if the path and its reverse + path consist of the same path elements on the same level of + abstraction, but in reverse order. For example, a path that + consists of layer 3 switches and links between them and a reverse + path with the same path elements but in reverse order are + considered "routing" symmetric, as the same path elements on the + same level of abstraction (IP forwarding) are traversed in the + opposite direction. Symmetry can depend on the level of + abstraction on which the path is defined or modeled. If there are + two parallel physical links between two nodes, modeling them as + separate links may result in a flow using asymmetric paths, and + modeling them as a single virtual link may result in symmetric + paths, e.g., if the difference between the two physical links is + irrelevant in a particular context. + + Path MTU: The maximum size, in octets, of a packet or frame that can + be transmitted without fragmentation. + + Transport Protocols available: Whether a specific transport protocol + can be used to establish a connection over a path or subpath, + e.g., whether the path is QUIC-capable or MPTCP-capable, based on + input such as policy, cached knowledge, or probing results. + + Protocol Features available: Whether a specific protocol feature is + available over a path or subpath, e.g., Explicit Congestion + Notification (ECN) or TCP Fast Open. + + Some path properties express the performance of the transmission of a + packet or flow over a link or subpath. Such transmission performance + properties can be observed or assessed, e.g., by endpoints or by path + elements on the path, or they may be available as cost metrics, see + [RFC9439]. Transmission performance properties may be made available + in an aggregated form, such as averages or minimums. Properties + related to a path element that constitutes a single layer 2 domain + are abstracted from the used physical- and link-layer technology, + similar to [RFC8175]. + + Link Capacity: The link capacity is the maximum data rate at which + data that was sent over a link can correctly be received at the + node adjacent to the link. This property is analogous to the link + capacity defined in [RFC5136] and [RFC9097] but is not restricted + to IP-layer traffic. + + Link Usage: The link usage is the actual data rate at which data + that was sent over a link is correctly received at the node + adjacent to the link. This property is analogous to the link + usage defined in [RFC5136] and [RFC9097] but is not restricted to + IP-layer traffic. + + One-Way Delay: The one-way delay is the delay between a node sending + a packet and another node on the same path receiving the packet. + This property is analogous to the one-way delay defined in + [RFC7679] but is not restricted to IP-layer traffic. + + One-Way Delay Variation: The variation of the one-way delays within + a flow. This property is similar to the one-way delay variation + defined in [RFC3393], but it is not restricted to IP-layer traffic + and it is defined for packets on the same flow instead of packets + sent between a source and destination IP address. + + One-Way Packet Loss: Packets sent by a node but not received by + another node on the same path after a certain time interval are + considered lost. This property is analogous to the one-way loss + defined in [RFC7680] but is not restricted to IP-layer traffic. + Metrics such as loss patterns [RFC3357] and loss episodes + [RFC6534] can be expressed as aggregated properties. + +5. Security Considerations + + If entities are basing policy or path-selection decisions on path + properties, they need to rely on the accuracy of path properties that + other devices communicate to them. In order to be able to trust such + path properties, entities may need to establish a trust relationship + or be able to independently verify the authenticity, integrity, and + correctness of path properties received from another entity. + + Entities that reveal their target path properties to the network can + negatively impact their own privacy, e.g., if the target property + leaks personal information about a user, such as their identity or + which (type of) application is used. Such information could then + allow network operators to block or reprioritize traffic for certain + users and/or applications. Conversely, if privacy-enhancing + technologies, e.g., MASQUE proxies [RFC9298], are used on a path, the + path may only be partially visible to any single entity. This may + diminish the usefulness of path-aware technologies over this path. + + The need for, and potential definition of, security- and privacy- + related path properties, such as confidentiality and integrity + protection of payloads, are the subject of ongoing discussion and + research, for example, see [RFC9049] and [RFC9217]. As the + discussion of such properties is not mature enough, they are out of + scope for this document. One aspect discussed in this context is + that security-related properties are difficult to characterize since + they are only meaningful with respect to a threat model that depends + on the use case, application, environment, and other factors. + Likewise, properties for trust relations between entities cannot be + meaningfully defined without a concrete threat model, and defining a + threat model is out of scope for this document. Properties related + to confidentiality, integrity, and trust seem to be orthogonal to the + path terminology and path properties defined in this document, since + they are tied to the communicating nodes and the protocols they use + (e.g., client and server using HTTPS, or client and remote network + node using a VPN service) as well as additional context, such as + keying material and who has access to such a context. In contrast, + the path as defined in this document is typically oblivious to these + aspects. Intuitively, the path describes what function the network + applies to packets, while confidentiality, integrity, and trust + describe what function the communicating parties apply to packets. + +6. IANA Considerations + + This document has no IANA actions. + +7. Informative References + + [NETWORK-SLICES] + Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, + K., Contreras, L. M., and J. Tantsura, "A Framework for + Network Slices in Networks Built from IETF Technologies", + Work in Progress, Internet-Draft, draft-ietf-teas-ietf- + network-slices-24, 25 August 2023, + <https://datatracker.ietf.org/doc/html/draft-ietf-teas- + ietf-network-slices-24>. + + [PERFORMANCE-ROUTING] + Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C. + Jacquenet, "Performance-based BGP Routing Mechanism", Work + in Progress, Internet-Draft, draft-ietf-idr-performance- + routing-03, 21 December 2020, + <https://datatracker.ietf.org/doc/html/draft-ietf-idr- + performance-routing-03>. + + [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, + DOI 10.17487/RFC1122, October 1989, + <https://www.rfc-editor.org/info/rfc1122>. + + [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, + selection, and registration of an Autonomous System (AS)", + BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, + <https://www.rfc-editor.org/info/rfc1930>. + + [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. + Zappala, "Source Demand Routing: Packet Format and + Forwarding Specification (Version 1)", RFC 1940, + DOI 10.17487/RFC1940, May 1996, + <https://www.rfc-editor.org/info/rfc1940>. + + [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. + Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, + DOI 10.17487/RFC2784, March 2000, + <https://www.rfc-editor.org/info/rfc2784>. + + [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample + Metrics", RFC 3357, DOI 10.17487/RFC3357, August 2002, + <https://www.rfc-editor.org/info/rfc3357>. + + [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation + Metric for IP Performance Metrics (IPPM)", RFC 3393, + DOI 10.17487/RFC3393, November 2002, + <https://www.rfc-editor.org/info/rfc3393>. + + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + DOI 10.17487/RFC4271, January 2006, + <https://www.rfc-editor.org/info/rfc4271>. + + [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", + RFC 5136, DOI 10.17487/RFC5136, February 2008, + <https://www.rfc-editor.org/info/rfc5136>. + + [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic + Optimization (ALTO) Problem Statement", RFC 5693, + DOI 10.17487/RFC5693, October 2009, + <https://www.rfc-editor.org/info/rfc5693>. + + [RFC6534] Duffield, N., Morton, A., and J. Sommers, "Loss Episode + Metrics for IP Performance Metrics (IPPM)", RFC 6534, + DOI 10.17487/RFC6534, May 2012, + <https://www.rfc-editor.org/info/rfc6534>. + + [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function + Chaining (SFC) Architecture", RFC 7665, + DOI 10.17487/RFC7665, October 2015, + <https://www.rfc-editor.org/info/rfc7665>. + + [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support + for Generic Routing Encapsulation (GRE)", RFC 7676, + DOI 10.17487/RFC7676, October 2015, + <https://www.rfc-editor.org/info/rfc7676>. + + [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, + Ed., "A One-Way Delay Metric for IP Performance Metrics + (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January + 2016, <https://www.rfc-editor.org/info/rfc7679>. + + [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, + Ed., "A One-Way Loss Metric for IP Performance Metrics + (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January + 2016, <https://www.rfc-editor.org/info/rfc7680>. + + [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. + Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, + DOI 10.17487/RFC8175, June 2017, + <https://www.rfc-editor.org/info/rfc8175>. + + [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, + Q., and E. Smith, "Cryptographic Protection of TCP Streams + (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, + <https://www.rfc-editor.org/info/rfc8548>. + + [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", + RFC 8558, DOI 10.17487/RFC8558, April 2019, + <https://www.rfc-editor.org/info/rfc8558>. + + [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. + Paasch, "TCP Extensions for Multipath Operation with + Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March + 2020, <https://www.rfc-editor.org/info/rfc8684>. + + [RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S., + Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol", + RFC 8803, DOI 10.17487/RFC8803, July 2020, + <https://www.rfc-editor.org/info/rfc8803>. + + [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based + Multiplexed and Secure Transport", RFC 9000, + DOI 10.17487/RFC9000, May 2021, + <https://www.rfc-editor.org/info/rfc9000>. + + [RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to + Deployment (A Bestiary of Roads Not Taken)", RFC 9049, + DOI 10.17487/RFC9049, June 2021, + <https://www.rfc-editor.org/info/rfc9049>. + + [RFC9097] Morton, A., Geib, R., and L. Ciavattone, "Metrics and + Methods for One-Way IP Capacity", RFC 9097, + DOI 10.17487/RFC9097, November 2021, + <https://www.rfc-editor.org/info/rfc9097>. + + [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "HTTP Semantics", STD 97, RFC 9110, + DOI 10.17487/RFC9110, June 2022, + <https://www.rfc-editor.org/info/rfc9110>. + + [RFC9217] Trammell, B., "Current Open Questions in Path-Aware + Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022, + <https://www.rfc-editor.org/info/rfc9217>. + + [RFC9275] Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang, + "An Extension for Application-Layer Traffic Optimization + (ALTO): Path Vector", RFC 9275, DOI 10.17487/RFC9275, + September 2022, <https://www.rfc-editor.org/info/rfc9275>. + + [RFC9298] Schinazi, D., "Proxying UDP in HTTP", RFC 9298, + DOI 10.17487/RFC9298, August 2022, + <https://www.rfc-editor.org/info/rfc9298>. + + [RFC9439] Wu, Q., Yang, Y., Lee, Y., Dhody, D., Randriamasy, S., and + L. Contreras, "Application-Layer Traffic Optimization + (ALTO) Performance Cost Metrics", RFC 9439, + DOI 10.17487/RFC9439, August 2023, + <https://www.rfc-editor.org/info/rfc9439>. + +Acknowledgments + + Thanks to the Path Aware Networking Research Group for the discussion + and feedback. Specifically, thanks to Mohamed Boucadair for the + detailed review, various text suggestions, and shepherding; thanks to + Brian Trammell for suggesting the flow definition; and thanks to Luis + M. Contreras, Spencer Dawkins, Paul Hoffman, Jake Holland, Colin + Perkins, Adrian Perrig, and Matthias Rost for the reviews, comments, + and suggestions. Many thanks to Dave Oran for his careful IRSG + review. + +Authors' Addresses + + Reese Enghardt + Netflix + Email: ietf@tenghardt.net + + + Cyrill Krähenbühl + ETH Zürich + Email: cyrill.kraehenbuehl@inf.ethz.ch |