RFC 9473

A Vocabulary of Path Properties

📅 published September 2023, from ietf

RFC 9473: A Vocabulary of Path Properties 🦋

okay bestie, let's talk about RFC 9473, and yes the title is literally A Vocabulary of Path Properties 💅 It's marked Informational, so it's published for information and isn't a Standards Track spec. It came out in September 2023 through the IRTF (Internet Research Task Force), and the work comes from the Path Aware Networking Research Group (PANRG). The authors are R. Enghardt at Netflix and C. Krähenbühl at ETH Zürich. The ISSN is 2070-1721. Its header doesn't list any RFCs that it obsoletes or updates, so it doesn't replace or change anything else 🌸

Abstract

okay so path properties are the info about the paths your traffic takes across a network and about the services you can use along those paths ✨ In a path-aware network, endpoints and other entities might get some or all of that info 👀 This doc defines path properties and sorts them into categories 🗂️ It also points out several path properties that could be handy for endpoints or other entities, like picking between paths or invoking some of the services on offer 🫶 This document is a product of the Path Aware Networking Research Group (PANRG) 🎀

Status of This Memo

not a Standards Track spec, so this is published purely for info 💜

this is a product of the Internet Research Task Force (IRTF), which shares the results of Internet-related research and development 🔬 Those results might not be suitable for deployment, so be careful 🙈 This RFC represents the consensus of the Path Aware Networking Research Group of the IRTF 🫶 Documents approved for publication by the IRSG are not candidates for any level of Internet Standard, see Section 2 of RFC 7841 💅

for the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9473 🌈

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date this was published 📜 Please read them carefully, because they spell out your rights and restrictions for 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 ✨

okay so the current Internet architecture doesn't explicitly let endpoints discover the forwarding paths through the network, or find out the properties and services tied to those paths 😭 Path-aware networking, as defined in Section 1.1 of [RFC9217], is described as "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 gives a generic definition of path properties, which answers the first of the questions in path-aware networking [RFC9217] 💅

path terms have been used with different meanings in different areas of networking, so first this doc gives a common terminology for paths, path elements, and flows 🧚 Using those terms, it defines path properties 🦋 Then it shares some example use cases for path properties 🍓 Finally, it lists several path properties that could be useful for those use cases 🌟 This list isn't meant to be exhaustive or definitive, so don't treat it as the whole universe 🌌

heads up, this document does not assume that any of the listed path properties are actually available to any entity 👀 How entities can discover and distribute path properties in a trustworthy way is out of scope here 🙅‍♀️

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 whole collection of devices or functions, that plays a role in path-aware networking for particular paths and flows ✨ An entity can be on-path or off-path 🛣️ When it's on the path, it can take part in forwarding the flow, which is what people call "data plane functionality" 📦 On or off the path, an entity can influence how the flow gets forwarded, which is "control plane functionality" like path selection or service invocation 🎛️ An entity that influences forwarding is usually aware of path properties, for example by observing or measuring them, or by learning them from another entity 🧠
  • Node: an on-path entity that processes packets, like sending, receiving, forwarding, or modifying them 🔁 A node can be physical or virtual, like a physical device, a service function provided as a virtual element, or even a single queue inside a switch 🪄 A node can also be an entity made of a collection of devices or functions, like an entire Autonomous System (AS) 🏙️
  • Link: a medium or communication facility that connects two or more nodes ✨ A link lets a node send packets to other nodes 📬 Links can be physical, like a Wi-Fi network connecting an Access Point to stations 📶, or virtual, like a virtual switch connecting two virtual machines hosted on the same physical machine 💻 A link is unidirectional, so bidirectional communication gets modeled as two links between the same nodes, pointing 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 that a packet can be transmitted over, starting and ending with a node 🗺️
    • Paths are unidirectional and time dependent 🕰️ There can be a bunch of different paths from one node to another, and the path your packets take can change over time 🌊 A path definition can be strict, meaning the exact sequence of path elements stays the same, or loose, meaning the start and end node stay the same but the elements in between can vary over time 🎢
    • How a path and its properties get represented can depend on which entity is looking at it 👁️ That's because entities might only partially see the path elements, or their visibility might change over time 🌫️ It can also differ because path elements get treated at different levels of abstraction 🪜 For example, a path can be a sequence of physical nodes and the links between them, or a sequence of logical nodes like a sequence of ASes or an Explicit Route Object (ERO), or it can just be a specific source and destination known to be reachable from that source 📍
    • multicast or broadcast, where one node sends a packet and multiple nodes receive it, is described by multiple paths, one for each combination of sending and receiving node 📡 These paths don't have to be disjoint, which is what the disjointness path property is about, see Section 4 🔗
  • Endpoint: the endpoints of a path are its start and end nodes 🎯 For example, an endpoint can be a host as defined in [RFC1122], which could be a client (like a node running a web browser) or a server (like a node running a web server) 🖥️
  • Reverse Path: the path that a remote node uses in the context of bidirectional communication 🔙
  • Subpath: given a path, a subpath is a sequence of adjacent path elements of that path 🧵
  • Flow: one or multiple packets that the traits of a path or a set of subpaths may be applied to in a functional sense 🌊 For example, a flow can be all packets sent within a TCP session with the same five-tuple between two hosts, or it can be 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 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 sent from one node to another over that subpath ⏱️ So a property is described by a tuple with the path element(s), the flow (or an empty set if no packets are relevant for the property), the name of the property (like maximum data rate), and the value of the property (like 1 Gbps) 🧮
  • Aggregated property: a bunch of values of a property squished into one value, using 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 (like median, sum, or minimum) or logical (like "true if all are true" or "true if at least 50% of values are true"), or it can be any arbitrary function that maps multiple input values to one output value 🧠
  • Observed property: a property that's observed for a specific path element, subpath, or path 👀 It can be observed using measurements, like the one-way delay of one specific packet sent from node to node ⏲️
  • Assessed property: an approximate calculation or assessment of a property's value ✨ An assessed property includes how reliable that calculation or assessment is, and what "reliable" means depends on the property 🔍 For example, a path property based on an approximate calculation might 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 might instead include the likelihood that the property holds 🎲
  • Target property: an objective set for a property over a path element, subpath, or path 🎯 A target property can be set for observed properties, like one-way delay, and also for properties the entity setting the target can't observe, like certain nodes being included on a path 🚦

2.1. Terminology Usage for Specific Technologies ✨

okay so the terms we just went over are meant to be super general 💅 they work for path-aware tech that exists right now AND stuff that hasn't been invented yet 🔮 which is so iconic. so a technology can pick its own path elements and path properties at whatever level of abstraction it wants 🦋

for example, a technology might say path elements are IP routers, like in source routing [RFC1940] 🛣️ or it might look at path elements on a different layer of the Internet architecture [RFC1122] 🧱 or treat them as a bunch of entities that aren't tied to one layer at all, like an AS or ERO 🌈

and even inside ONE path-aware technology, the definitions can shift depending on where you're using them 🫶 like, the endpoints could be the communicating hosts if you're talking transport layer, ASes that hold those hosts if you're talking routing, or specific applications if you're at the application layer. it's the same word doing different jobs, bestie 💜

3. Use Cases for Path Properties 🎀

okay so when a path-aware network shows its path properties to endpoints or other entities, those entities can use that info to chase different goals 🎯 this section is a little list of use cases 📝

and heads up, this is NOT the full list 🙈 new tech and protocols always bring new use cases, and new path properties might pop up too 🌸 plus, for any given technology, different entities might see and control different path elements and path properties, and think about them at different levels of abstraction 🧚 so a new technology might pull off an existing use case with different path elements, or at a different level of abstraction entirely. it's giving flexibility 💖

3.1. Path Selection 🛤️

so nodes might be able to send flows over one path (or a subset of paths) out of several possible ones, and an entity might be able to nudge which path(s) get picked 👑 path selection makes sense when there are several paths to the same destination (like a mobile device with two wireless interfaces, each providing a path 📱📶) or when there are several destinations, and therefore several paths, offering the same service (like Application-Layer Traffic Optimization (ALTO) [RFC5693], an application-layer peer-to-peer protocol that gives endpoints a better-than-random peer selection 🤝). entities can say what they're aiming for by specifying target properties for their paths, like stuff about performance or security 🎯 then paths that best meet those target properties can get selected. the entity can pick from all the available paths itself, or it can hand the target properties to the network and trust the network to choose good paths 🫶

target properties about network performance usually refer to observed properties, like one-way delay, one-way packet loss, and link capacity 📊 entities then select paths by comparing their target property with the assessed property of the available paths, and they go with whichever paths best match the application requirements ✨ for these performance-related target properties, the observed property is kinda like a Service Level Indicator (SLI), and the assessed property is kinda like a Service Level Objective (SLO) for IETF Network Slices [NETWORK-SLICES] 💅 as an example strategy, an entity might pick a path with a short one-way delay for a small delay-sensitive query 🏃‍♀️, but pick a path with high link capacities on all links for grabbing a big file 📦

it's also possible for an entity to set target properties it can't (directly) observe 👀 this is kinda like Service Level Expectations (SLEs) for IETF Network Slices [NETWORK-SLICES] 🧐 this could apply to security-related target properties (like requiring that ALL enterprise traffic goes through one specific firewall 🔥) and to path selection (like enforcing traffic policies by allowing or disallowing flows over paths that go through specific networks or nodes 🚧)

⚠️ bestie, be careful when you pick paths based on observed path properties! path properties measured in the past might not help predict the current or future ones 😬 and that kind of path selection can lead to unintended feedback loops 🌀 also, path properties can trade off against each other (like one-way delay vs. link capacity), and entities can influence those trade-offs with their choices 🎚️ and path selection can affect fairness 🥺 like, if multiple entities are trying to hit their target properties using the same network resources at the same time, one entity's choices can change the conditions on the path that another entity's flows experience 😭

as a baseline, a path-selection algorithm should aim to do a better job of meeting the target properties, and therefore accommodating the user's requirements, than the default case of not selecting a path most of the time 📈 it's giving "don't be worse than doing nothing" energy 💀

path selection can be done by the communicating node(s) OR by other entities inside the network 🏠 a network (like an AS) can adjust its path selection for internal or external routing based on path properties 🗺️ in BGP, the Multi-Exit Discriminator (MED) attribute gets used in the decision-making process to pick which path to take among those with the same AS path length and origin [RFC4271] 🔢 but in a path-aware network, instead of relying on that single MED value, other properties like link capacity or link usage could also be used to improve load balancing or performance [PERFORMANCE-ROUTING] ⚖️✨

3.2. Protocol Selection 🧩

before sending data over a specific path, an entity might pick an appropriate protocol or configure protocol parameters depending on path properties 🔧 for example, an endpoint might cache state if a path allows the use of QUIC [RFC9000] 💾 and if it does, it can try connecting with QUIC first, then fall back to another protocol next time it connects over that same path 🔁 a video-streaming app might choose its (initial) video quality based on the achievable data rate or the monetary cost of sending data (like a volume-based or flat-rate cost model) 🎬💸

3.3. Service Invocation 🪄

on top of path or protocol selection, an entity might choose to invoke additional functions in the context of Service Function Chaining [RFC7665], which can influence which nodes end up on the path 🔗 for example, a 0-RTT Transport Converter [RFC8803] only gets involved in a path when an endpoint invokes it 🙌 that invocation leads to the use of Multipath TCP (MPTCP) [RFC8684] or tcpcrypt [RFC8548] capabilities, while that use isn't supported via the default forwarding path 🚫 another example is a connection made up of multiple streams, where each stream has its own specific service requirements 🌊 an endpoint might decide to invoke a given service function (like transcoding) for only some streams, while others skip that service function entirely 🎞️💅

4. Examples of Path Properties ✨

Okay bestie, this section gives some examples of path properties 💅 that could be super useful for the use cases in Section 3 🫶.

Path properties depend on who's looking. Visibility changes by technology, because entities can see into and influence different path elements and properties. An endpoint might see things that are close and low-level, like individual nodes within the first few hops 👀, or things that are far away and higher-level, like the list of ASes traversed 🌍. What's visible can depend on physical or network distance, or on whether there are 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," which means relative to a path that has two endpoints and a single virtual link connecting them 🧚.

Some properties are super dynamic, and some are not. A dynamic one is the one-way delay of a packet sent over a specific path 💨. A non-dynamic one is the MTU of an Ethernet link that only changes infrequently 🌸. How useful a property is over time depends on how dynamic it is. A momentarily observed dynamic property can get stale fast 💀. The observed one-way delay can change on timescales shorter than the one-way delay between the measurement point and an entity making a decision, like path selection, so the measurement might already be outdated by the time it reaches that decision-maker 😭. That's why consumers of dynamic path properties need to be careful. Aggregate them appropriately, or apply a dampening function to their changes to avoid oscillation 🌊. On the flip side, the observed value of a less dynamic property can stay relevant for way longer. A NAT, for example, 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 it's known, the access technology can be given as an abstract link type, like Wi-Fi, wired Ethernet, or cellular. It can also be given as a specific technology used on a link, like 3GPP cellular or 802.11 Wireless Local Area Network (WLAN) 🛜. Other path elements related to the access technology can include nodes that process packets on the physical or link layer, like elements of a cellular core network 🏗️. Note that there is no common registry of possible values for this property, so it's a bit of a free-for-all 🙈.

Monetary Cost: The price to be paid to transmit or receive a specific flow across a network that one or multiple path elements belong to 💸.

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, like NAT, need to observe the same flow in both directions, for example 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 be, for example, the existence of a protocol (header) in a packet, or the content of a protocol header, payload, or both. A can be things like blocking packets, or reading and modifying (other protocol) headers or payloads. Transparency can be modeled using a function f, which takes F and M as input 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 transparent ✅.

Here's how that plays out. 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 🧱. And 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 under this definition, a node that modifies packets in accordance with the endpoints, such as a transparent HTTP proxy as defined in [RFC9110], is not considered transparent. Same goes for a node listening and reacting to implicit or explicit signals, see [RFC8558] 🙅‍♀️.

Transparency only applies to nodes, not links. A link can't modify packets or do any other actions on them by itself, so it doesn't count 🔗. For example, if the content of a packet gets altered when it's forwarded over a Generic Routing Encapsulation (GRE) tunnel [RFC2784] [RFC7676], then per this document, the software instances that terminate the tunnel are the nodes where the actions are performed, and the transparency definition applies to those 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 that indicates 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 talk to 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. The Jaccard coefficient is a great example of this, and it's the number of shared elements divided by the total number of elements 🤓. Flip it around, and the number of non-shared path elements can be a measure of disjointness, like 1 - Jaccard coefficient 🧩. A multipath protocol might use disjointness as a metric to reduce the number of single points of failure 🛡️. Also, because paths can be defined at different levels of abstraction, two paths might be disjoint at one level but not at 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, just in reverse order 🪞. For example, a path made of layer 3 switches and the links between them, plus a reverse path with those same path elements in reverse order, is considered "routing" symmetric, since 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 the path is defined or modeled on. If there are two parallel physical links between two nodes, modeling them as separate links may result in a flow using asymmetric paths. Modeling them as a single virtual link may result in symmetric paths, e.g., if the difference between the two physical links doesn't matter 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. This is 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 transmitting a packet or flow over a link or subpath. These transmission performance properties can be observed or assessed by endpoints or by path elements on the path. They can also be available as cost metrics, see [RFC9439] 📊. They might be shared in an aggregated form, like averages or minimums 🧮. Properties related to a path element that makes up a single layer 2 domain are abstracted from the physical- and link-layer technology used, similar to [RFC8175] 🪄.

Link Capacity: The maximum data rate at which data sent over a link can be correctly received at the node adjacent to the link 🚰. This property is analogous to the link capacity defined in [RFC5136] and [RFC9097], but it isn't restricted to IP-layer traffic 💜.

Link Usage: The actual data rate at which data 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 it isn't restricted to IP-layer traffic either 🌈.

One-Way Delay: The delay between a node sending a packet and another node on the same path receiving it ⏱️. This property is analogous to the one-way delay defined in [RFC7679], but it isn't 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]. The difference is that it isn't restricted to IP-layer traffic, and it's defined for packets on the same flow instead of packets sent between a source and destination IP address 🙌.

One-Way Packet Loss: Packets that a node sends but that another node on the same path doesn't receive after a certain time interval are considered lost 😤. This property is analogous to the one-way loss defined in [RFC7680], but it isn't restricted to IP-layer traffic. Metrics like loss patterns [RFC3357] and loss episodes [RFC6534] can be expressed as aggregated properties 📉.

5. Security Considerations ✨

Okay bestie, this part is super important 🔒. If entities are making policy or path-selection decisions based on path properties, they need to rely on the accuracy of the path properties that other devices send them 📡. To actually trust those properties, entities may need to set up a trust relationship, or be able to independently verify the authenticity, integrity, and correctness of path properties received from another entity 🫶.

Now, the privacy side is a whole vibe 🙈. Entities that reveal their target path properties to the network can hurt their own privacy. For example, if the target property leaks personal info about a user, like their identity or which (type of) application they're using, that info could let network operators block or reprioritize traffic for certain users and/or applications 💀. On the flip side, if privacy-enhancing technologies, like MASQUE proxies [RFC9298], are used on a path, the path may only be partially visible to any single entity 🦋. That can lowkey reduce how useful path-aware technologies are over that path 😭.

The need for, and possible definition of, security- and privacy-related path properties (like confidentiality and integrity protection of payloads) is still being talked about and researched, see [RFC9049] and [RFC9217] 🧠. Since the discussion isn't mature enough yet, these are out of scope for this document 🙅‍♀️. One thing that comes up in this context is that security-related properties are hard to pin down, since they only mean something with respect to a threat model. That threat model depends on the use case, application, environment, and other factors 🌸. Same deal for trust relations between entities: they can't 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 ✨. They're tied to the communicating nodes and the protocols they use (like a client and server using HTTPS, or a client and remote network node using a VPN service), plus extra context like keying material and who has access to that context 🔐. The path, as defined here, is typically oblivious to all of that 🫠. 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

Here's the full reading list, bestie 📚 (all the details, no cuts):

Acknowledgments

Huge thanks to the Path Aware Networking Research Group for the discussion and feedback 🎀. Special shoutout 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 🌈

📦 where this page comes from