< draft-irtf-panrg-path-properties-04.txt   draft-irtf-panrg-path-properties-05.txt >
PANRG T. Enghardt PANRG T. Enghardt
Internet-Draft Netflix Internet-Draft Netflix
Intended status: Informational C. Kraehenbuehl Intended status: Informational C. Krähenbühl
Expires: 28 April 2022 ETH Zuerich Expires: 8 September 2022 ETH Zürich
25 October 2021 7 March 2022
A Vocabulary of Path Properties A Vocabulary of Path Properties
draft-irtf-panrg-path-properties-04 draft-irtf-panrg-path-properties-05
Abstract Abstract
Path properties express information about paths across a network and Path properties express information about paths across a network and
the services provided via such paths. In a path-aware network, path the services provided via such paths. In a path-aware network, path
properties may be fully or partially available to entities such as properties may be fully or partially available to entities such as
hosts. This document defines and categorizes path properties. endpoints. This document defines and categorizes path properties.
Furthermore, the document specifies several path properties which Furthermore, the document specifies several path properties which
might be useful to hosts or other entities, e.g., for selecting might be useful to endpoints or other entities, e.g., for selecting
between paths or for invoking some of the provided services. between paths or for invoking some of the provided services.
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 April 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology usage for specific technologies . . . . . . . 5 2.1. Terminology usage for specific technologies . . . . . . . 5
3. Use Cases for Path Properties . . . . . . . . . . . . . . . . 5 3. Use Cases for Path Properties . . . . . . . . . . . . . . . . 6
3.1. Path Selection . . . . . . . . . . . . . . . . . . . . . 6 3.1. Path Selection . . . . . . . . . . . . . . . . . . . . . 6
3.2. Protocol Selection . . . . . . . . . . . . . . . . . . . 7 3.2. Protocol Selection . . . . . . . . . . . . . . . . . . . 7
3.3. Service Invocation . . . . . . . . . . . . . . . . . . . 7 3.3. Service Invocation . . . . . . . . . . . . . . . . . . . 7
4. Examples of Path Properties . . . . . . . . . . . . . . . . . 7 4. Examples of Path Properties . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Informative References . . . . . . . . . . . . . . . . . . . 11 7. Informative References . . . . . . . . . . . . . . . . . . . 12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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 as well as endpoint discovery of forwarding paths through the network as well as
the discovery of properties and services associated with these paths. the discovery of properties and services associated with these paths.
Path-aware networking, as defined in Section 1.1 of Path-aware networking, as defined in Section 1.1 of
[I-D.irtf-panrg-questions], describes "endpoint discovery of the [I-D.irtf-panrg-questions], describes "endpoint discovery of the
properties of paths they use for communication across an properties of paths they use for communication across an
skipping to change at page 3, line 31 skipping to change at page 3, line 39
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 which 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 which consists of a collection of devices or
functions, e.g., an entire Autonomous System (AS). functions, e.g., an entire Autonomous System (AS).
Host: A node that generally executes application programs on behalf
of user(s), employing network and/or Internet communication
services in support of this function, as defined in [RFC1122].
Note that hosts include both client nodes (e.g., running a web
browser) and server nodes (e.g., running a web server).
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 which
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 which 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
skipping to change at page 4, line 25 skipping to change at page 4, line 25
treat path elements at different levels of abstraction. For treat path elements at different levels of abstraction. For
example, a path may be given as a sequence of physical nodes and example, a path may be given as a sequence of physical nodes and
the links connecting these nodes, or it may be given as a sequence the links connecting these nodes, or it may be given as a sequence
of logical nodes such as a sequence of ASes or an Explicit Route of logical nodes such as a sequence of ASes or an Explicit Route
Object (ERO). Similarly, the representation of a path and its Object (ERO). Similarly, the representation of a path and its
properties, as it is known to a specific entity, may be more properties, as it is known to a specific entity, may be more
complex and include details about the physical layer technology, complex and include details about the physical layer technology,
or it may be more abstract and only consist of a specific source or it may be more abstract and only consist of a specific source
and destination which is known to be reachable from that source. and destination which is known to be reachable from that source.
Endpoint: The endpoints of a path are the first and the last node on
the path. For example, an endpoint can be a host as defined in
[RFC1122], which can be a client (e.g., a node running a web
browser) or a server (e.g., a node running a web server).
Reverse Path: The path that is used by a remote node in the context 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
elements of this path. elements of this path.
Flow: One or multiple packets to which the traits of a path or set Flow: One or multiple packets to which the traits of a path or set
of subpaths may be applied in a functional sense. For example, a of subpaths may be applied in a functional sense. For example, a
flow can consist of all packets sent within a TCP session with the flow can consist of all packets sent within a TCP session with the
same five-tuple between two hosts, or it can consist of all same five-tuple between two hosts, or it can consist of all
skipping to change at page 5, line 40 skipping to change at page 6, line 5
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 consider path elements on a different layer of the Internet may 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. specific layer, such as an AS or an ERO. Even within a single path-
aware technology, specific definitions might differ depending on the
context in which they are used. For example, the endpoints might be
the communicating hosts in the context of the transport layer, ASes
that contain the hosts in the context of routing, or specific
applications in the context of the application layer.
3. Use Cases for Path Properties 3. Use Cases for Path Properties
When a path-aware network exposes path properties to hosts or other When a path-aware network exposes path properties to endpoints or
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
skipping to change at page 6, line 19 skipping to change at page 6, line 37
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 which path(s) to use. Path Selection may be feasible if there are
several paths to the same destination (e.g., in case of a mobile 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 hosts [RFC5693], an application layer peer-to-peer protocol allowing
a better-than-random peer selection). Care needs to be taken when endpoints a better-than-random peer selection). Care needs to be
selecting paths based on path properties, as path properties that taken when selecting paths based on path properties, as path
were previously measured may not be helpful in predicting current or properties that were previously measured may not be helpful in
future path properties and such path selection may lead to unintended predicting current or future path properties and such path selection
feedback loops. may lead to unintended feedback loops.
Entities may select their paths to fulfill a specific goal, e.g., Entities may select their paths to fulfill a specific goal, e.g.,
related to security or performance. As an example of security- related to security or performance. As an example of security-
related path selection, an entity may allow or disallow sending flows related path selection, an entity may allow or disallow sending flows
over paths involving specific networks or nodes to enforce traffic over paths involving specific networks or nodes to enforce traffic
policies. In an enterprise network where all traffic has to go policies. In an enterprise network where all traffic has to go
through a specific firewall, a path-aware entity can implement this through a specific firewall, a path-aware entity can implement this
policy using path selection. As an example of performance-related policy using path selection. As an example of performance-related
path selection, an entity may prefer paths with performance path selection, an entity may prefer paths with performance
properties that best match application requirements. For example, properties that best match application requirements. For example,
skipping to change at page 7, line 20 skipping to change at page 7, line 28
among those having the same AS PATH length and origin [RFC4271]; in a among those having the same AS PATH length and origin [RFC4271]; in a
path-aware network, instead of using this single MED value, other path-aware network, instead of using this single MED value, other
properties such as Link Capacity or Link Usage could additionally be properties such as Link Capacity or Link Usage could additionally be
used to improve load balancing or performance used to improve load balancing or performance
[I-D.ietf-idr-performance-routing]. [I-D.ietf-idr-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. A host may cache state on whether a path allows the path properties. For example, an endpoint may cache state on whether
use of QUIC [I-D.ietf-quic-transport] and if so, first attempt to a path allows the use of QUIC [I-D.ietf-quic-transport] and if so,
connect using QUIC before falling back to another protocol when first attempt to connect using QUIC before falling back to another
connecting over this path again. A video streaming application may protocol when connecting over this path again. A video streaming
choose an (initial) video quality based on the achievable data rate application may choose an (initial) video quality based on the
or the monetary cost of sending data (e.g., volume-base or flat-rate achievable data rate or the monetary cost of sending data (e.g.,
cost model). volume-base or flat-rate 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 what nodes are on the path.
For example, a 0-RTT Transport Converter [I-D.ietf-tcpm-converters] For example, a 0-RTT Transport Converter [I-D.ietf-tcpm-converters]
will be involved in a path only when invoked by a host; such will be involved in a path only when invoked by an endpoint; such
invocation will lead to the use of MPTCP or TCPinc capabilities while invocation will lead to the use of MPTCP or TCPinc capabilities while
such use is not supported via the default forwarding path. Another such use is not supported via the default forwarding path. Another
example is a connection which is composed of multiple streams where example is a connection which is composed of multiple streams where
each stream has specific service requirements. A host may decide to each stream has specific service requirements. An endpoint may
invoke a given service function (e.g., transcoding) only for some decide to invoke a given service function (e.g., transcoding) only
streams while others are not processed by that service function. for some streams while others are not processed by 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 which 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,
a host may have some visibility into path elements that are on a low an endpoint may have some visibility into path elements that are on a
level of abstraction and close, e.g., individual nodes within the low level of abstraction and close, e.g., individual nodes within the
first few hops, or it may have visibility into path elements that are first few hops, or it may have visibility into path elements that are
far away and/or on a higher level of abstraction, e.g., the list of far away and/or on a higher level of abstraction, e.g., the list of
ASes traversed. This visibility may depend on factors such as the ASes traversed. This visibility may depend on factors such as the
physical or network distance or the existence of trust or contractual physical or network distance or the existence of trust or contractual
relationships between the host and the path element(s). relationships between the endpoint and the path element(s). A path
property can be defined relative to individual path elements, a
sequence of path elements, or "end-to-end", i.e., relative to a path
that comprises of two endpoints and a single virtual link connecting
them.
Path properties may be relatively dynamic, e.g., the one-way delay of 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 which 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
momentary measurement of a dynamic path property diminishes greatly momentary measurement of a dynamic path property diminishes greatly
as time goes on, e.g. the merit of an RTT measurement from a few as time goes on, e.g. the merit of an RTT measurement from a few
seconds ago is quite small, while a non-dynamic path property might seconds ago is quite small, while a non-dynamic path property might
stay relevant for a longer period of time, e.g. a NAT typically stays stay relevant for a longer period of time, e.g. a NAT typically stays
on a specific path during the lifetime of a connection involving on a specific path during the lifetime of a connection involving
skipping to change at page 9, line 13 skipping to change at page 9, line 29
(impacted) by M or if the output of f is constant for arbitrary (impacted) by M or if the output of f is constant for arbitrary
values of M, then the node is considered to be transparent. An IP values of M, then the node is considered to be transparent. An IP
router could be transparent to transport protocol headers such as router could be transparent to transport protocol headers such as
TCP/UDP but not transparent to IP headers since its forwarding TCP/UDP but not transparent to IP headers since its forwarding
behavior depends on the IP headers. A firewall that only allows behavior depends on the IP headers. A firewall that only allows
outgoing TCP connections by blocking all incoming TCP SYN packets outgoing TCP connections by blocking all incoming TCP SYN packets
regardless of their IP address is transparent to IP but not to TCP regardless of their IP address is transparent to IP but not to TCP
headers. Finally, a NAT that actively modifies IP and TCP/UDP headers. Finally, a NAT that actively modifies IP and TCP/UDP
headers based on their content is not transparent to either IP or headers based on their content is not transparent to either IP or
TCP/UDP headers. Note that according to this definition, a node TCP/UDP headers. Note that according to this definition, a node
that modifies packets in accordance with the hosts, such as a that modifies packets in accordance with the endpoints, such as a
transparent HTTP proxy, as defined in [RFC2616], and a node transparent HTTP proxy, as defined in [RFC2616], and a node
listening and reacting to implicit or explicit signals, see listening and reacting to implicit or explicit signals, see
[RFC8558], are not considered transparent. [RFC8558], are not considered transparent.
Administrative Domain: The administrative domain, e.g., the IGP Administrative Domain: The identity of an individual or an
area, AS, or Service provider network to which a path element organization that owns a path element (or several path elements).
belongs. Examples of administrative domains are an IGP area, an AS, or a
service provider network.
Routing Domain Identifier: An identifier indicating the routing
domain of a path element. Path elements in the same routing
domain are in the same administrative domain and use a common
routing protocol to communicate with each other. An example of a
routing domain identifier is the globally unique autonomous system
number (ASN) as defined in [RFC1930].
Disjointness: For a set of two paths or subpaths, the number of 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. failure.
skipping to change at page 10, line 7 skipping to change at page 10, line 35
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
cached knowledge. cached knowledge.
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 measured or approximated, e.g., by hosts or by path properties can be measured or approximated, e.g., by endpoints or by
elements on the path, or they may be available as cost metrics, see path elements on the path, or they may be available as cost metrics,
[I-D.ietf-alto-performance-metrics]. Transmission performance see [I-D.ietf-alto-performance-metrics]. Transmission performance
properties may be made available in an aggregated form, such as properties may be made available in an aggregated form, such as
averages or minimums. Properties related to a path element which averages or minimums. Properties related to a path element which
constitutes a single layer 2 domain are abstracted from the used constitutes a single layer 2 domain are abstracted from the used
physical and link layer technology, similar to [RFC8175]. physical and link layer technology, 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] but not restricted to IP-layer capacity defined in [RFC5136] but not restricted to IP-layer
traffic. traffic.
skipping to change at page 11, line 29 skipping to change at page 12, line 13
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] [I-D.ietf-alto-path-vector]
Gao, K., Lee, Y., Randriamasy, S., Yang, Y. R., and J. J. Gao, K., Lee, Y., Randriamasy, S., Yang, Y. R., and J. J.
Zhang, "ALTO Extension: Path Vector", Work in Progress, Zhang, "An ALTO Extension: Path Vector", Work in Progress,
Internet-Draft, draft-ietf-alto-path-vector-18, 18 October Internet-Draft, draft-ietf-alto-path-vector-24, 7 March
2021, <https://www.ietf.org/archive/id/draft-ietf-alto- 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
path-vector-18.txt>. alto-path-vector-24>.
[I-D.ietf-alto-performance-metrics] [I-D.ietf-alto-performance-metrics]
Wu, Q., Yang, Y. R., Lee, Y., Dhody, D., Randriamasy, S., Wu, Q., Yang, Y. R., Lee, Y., Dhody, D., Randriamasy, S.,
and L. M. C. Murillo, "ALTO Performance Cost Metrics", and L. M. C. Murillo, "ALTO Performance Cost Metrics",
Work in Progress, Internet-Draft, draft-ietf-alto- Work in Progress, Internet-Draft, draft-ietf-alto-
performance-metrics-19, 23 October 2021, performance-metrics-26, 2 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-alto- <https://datatracker.ietf.org/doc/html/draft-ietf-alto-
performance-metrics-19.txt>. performance-metrics-26>.
[I-D.ietf-idr-performance-routing] [I-D.ietf-idr-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, 22 December 2020,
<https://www.ietf.org/archive/id/draft-ietf-idr- <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
performance-routing-03.txt>. performance-routing-03>.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft, and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-34, 14 January 2021, draft-ietf-quic-transport-34, 14 January 2021,
<https://www.ietf.org/archive/id/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
transport-34.txt>. transport-34>.
[I-D.ietf-tcpm-converters] [I-D.ietf-tcpm-converters]
Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S.,
and B. Hesmans, "0-RTT TCP Convert Protocol", Work in and B. Hesmans, "0-RTT TCP Convert Protocol", Work in
Progress, Internet-Draft, draft-ietf-tcpm-converters-19, Progress, Internet-Draft, draft-ietf-tcpm-converters-19,
22 March 2020, <https://www.ietf.org/archive/id/draft- 22 March 2020, <https://datatracker.ietf.org/doc/html/
ietf-tcpm-converters-19.txt>. draft-ietf-tcpm-converters-19>.
[I-D.irtf-panrg-questions] [I-D.irtf-panrg-questions]
Trammell, B., "Current Open Questions in Path Aware Trammell, B., "Current Open Questions in Path Aware
Networking", Work in Progress, Internet-Draft, draft-irtf- Networking", Work in Progress, Internet-Draft, draft-irtf-
panrg-questions-10, 11 October 2021, panrg-questions-12, 25 January 2022,
<https://www.ietf.org/archive/id/draft-irtf-panrg- <https://datatracker.ietf.org/doc/html/draft-irtf-panrg-
questions-10.txt>. questions-12>.
[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/info/rfc1122>. <https://www.rfc-editor.org/rfc/rfc1122>.
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996,
<https://www.rfc-editor.org/rfc/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/info/rfc1940>. <https://www.rfc-editor.org/rfc/rfc1940>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>. <https://www.rfc-editor.org/rfc/rfc2616>.
[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/info/rfc3357>. <https://www.rfc-editor.org/rfc/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/info/rfc3393>. <https://www.rfc-editor.org/rfc/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/info/rfc4271>. <https://www.rfc-editor.org/rfc/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/info/rfc5136>. <https://www.rfc-editor.org/rfc/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/info/rfc5693>. <https://www.rfc-editor.org/rfc/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/info/rfc6534>. <https://www.rfc-editor.org/rfc/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/info/rfc7665>. <https://www.rfc-editor.org/rfc/rfc7665>.
[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/info/rfc7679>. 2016, <https://www.rfc-editor.org/rfc/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/info/rfc7680>. 2016, <https://www.rfc-editor.org/rfc/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/info/rfc8175>. <https://www.rfc-editor.org/rfc/rfc8175>.
[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/info/rfc8558>. <https://www.rfc-editor.org/rfc/rfc8558>.
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 Boudacair for the and feedback. Specifically, thanks to Mohamed Boudacair for the
detailed review and various text suggestions, thanks to Brian detailed review and various text suggestions, thanks to Brian
Trammell for suggesting the flow definition, and thanks to Adrian Trammell for suggesting the flow definition, thanks to Adrian Perrig
Perrig and Matthias Rost for the detailed feedback. Thanks to Paul and Matthias Rost for the detailed feedback, thanks to Paul Hoffman
Hoffman for the editorial changes. for the editorial changes, thanks to Luis M. Contreras and Jake
Holland for the reviews, and thanks to Spencer Dawkins for the
comments and suggestions.
Authors' Addresses Authors' Addresses
Theresa Enghardt Theresa Enghardt
Netflix Netflix
Email: ietf@tenghardt.net Email: ietf@tenghardt.net
Cyrill Kraehenbuehl Cyrill Krähenbühl
ETH Zuerich ETH Zürich
Email: cyrill.kraehenbuehl@inf.ethz.ch Email: cyrill.kraehenbuehl@inf.ethz.ch
 End of changes. 47 change blocks. 
91 lines changed or deleted 124 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/