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

This html diff was produced by rfcdiff 1.48.