PANRG T. Enghardt
Internet-Draft TU Berlin
Intended status: Informational C. Kraehenbuehl
Expires: September 12, 2019 ETH Zuerich
March 11, 2019
A Vocabulary of Path Properties
draft-enghardt-panrg-path-properties-01
Abstract
This document defines and categorizes information about Internet
paths that an entity, such as an endpoint, might have or want to
have. This information is expressed as properties of paths between
two endpoints.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Enghardt & KraehenbuehlExpires September 12, 2019 [Page 1]
Internet-Draft Path Properties March 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Domain Properties . . . . . . . . . . . . . . . . . . . . . . 5
4. Backbone Properties . . . . . . . . . . . . . . . . . . . . . 6
5. Dynamic Properties . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Because the current Internet provides an IP-based best-effort bit
pipe, endpoints have little information about paths to other
endpoints. A Path Aware Network exposes information about one or
multiple paths through the network to endpoints or the network
infrastructure.
It is impossible to provide an exhaustive list of path properties, as
with every new technology and protocol, novel properties might become
relevant. In this document, we specify a set of path properties
which might be useful in the following use cases: Traffic policies,
network monitoring, and path selection.
o Traffic policies: Entities such as network operators or end users
may want to define traffic policies leveraging path awareness.
Such policies can allow or disallow sending traffic over specific
networks or nodes, select an appropriate protocol depending on the
capabilities of the on-path devices, or adjust protocol parameters
to an existing path. An example of a traffic policy is a video
streaming application choosing an (initial) video quality based on
the achievable data rate, or the monetary cost of the link using a
volume-based or flat-rate cost model. Another example is an
enterprise network where all traffic has to go through a firewall,
in which case the endpoint needs to be aware of on-path firewalls.
o Network monitoring: Network operators can use path properties
(e.g., measured by on-path devices), to observe Quality of Service
(QoS) characteristics of recent end-user traffic, and identify
potential problems with their network early on, before the end-
user complains.
o Path selection: In some cases, entities can choose to use a
certain path (or subset of paths) from a set of paths to achieve a
specific goal. As the possible benefits of a well chosen path
Enghardt & KraehenbuehlExpires September 12, 2019 [Page 2]
Internet-Draft Path Properties March 2019
varies based on the goal, as a baseline, a path selection
algorithm should aim to not perform worse than the default case
most of the time. Depending on the goal, an entity may prefer
paths with different properties, e.g., retrieving a small webpage
as quickly as possible requires low latency paths, or retrieving a
large file in a peer-to-peer network requires paths with high
achievable data rate. Additionally, there may be trade-offs
between path properties (e.g., latency and data rate), and
entities may influence these trade-offs with their choices. A
network (e.g., an AS) can adjust its path selection for internal
or external routing based on the path properties. In BGP, the
Multi Exit Discriminator (MED) attribute decides which path to
choose if other attributes are equal; in a path aware network,
instead of using this single MED value, other properties such as
maximum or available/expected data rate could additionally be used
to improve load balancing. An endpoint might be able to select
between a set of paths, either if there are several paths to the
same destination (e.g., if the endpoint is a mobile device with
two wireless interfaces, both providing a path), or if there are
several destinations, and thus several paths, providing the same
service (e.g., Application-Layer Traffic Optimization (ALTO)
[RFC5693], an application layer peer-to-peer protocol allowing
endpoints a better-than-random peer selection). Care needs to be
taken when selecting paths based on path properties, as path
properties that were previously measured may have become outdated
and, thus, useless to predict the path properties of packets sent
now.
Such path properties may be relatively dynamic, e.g. current Round
Trip Time, close to the origin, e.g. nature of the access technology
on the first hop, or far from the origin, e.g. list of ASes
traversed.
Usefulness over time is fundamentally different for dynamic and non-
dynamic properties. The merit of a momentary measurement of a
dynamic path property diminishes greatly 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 stay relevant, e.g. a NAT can
be assumed to stay on a path during the lifetime of a connection, as
the removal of the NAT would break the connection.
Non-dynamic properties are further separated into (local) domain
properties related to the first few hops of the connection, and
backbone properties related to the remaining hops. Domain properties
expose a high amount of information to endpoints and strongly
influence the connection behavior while there is little influence and
information about backbone properties.
Enghardt & KraehenbuehlExpires September 12, 2019 [Page 3]
Internet-Draft Path Properties March 2019
Dynamic properties are not separated into domain and backbone
properties, since most of these properties are defined for a complete
path and it is difficult and seldom useful to define them on part of
the path. There are exceptions such as dynamic wireless access
properties, but these do not justify separation into different
categories.
This document addresses the first of the questions in Path-Aware
Networking [I-D.irtf-panrg-questions], which is a product of the
PANRG in the IRTF.
2. Terminology
Path element: A path element is a device (including the endpoints),
or link used to connect two devices and transmit information on a
specific layer. Path elements may exist on multiple layers (e.g.,
the endpoint corresponds to a path element on every layer), may be
hidden on higher layers (e.g., a layer 2 switch in the local
network), or a path element may be an aggregation of several path
elements on a lower layer (e.g., the link connecting the endpoints
on the transport layer being an aggregation of all network layer
path elements).
Path segment: A path segment is an ordered set of path elements at
the network layer that can be traversed by a packet.
Path: A path is defined as an ordered set of path elements at the
network layer between two endpoints. A path can be traversed by a
packet.
Flow: Several packets traversing the same path elements can be
combined into a flow (e.g., all packets sent within a UDP session
which traverse the same path elements). As a special case, a flow
can consist of just one packet.
Property: A property describes a trait of a set of path elements
(e.g., capacity of a link, is device X a firewall, one-way maximum
data rate which is the minimum of all links' maximum data rates),
or a trait of a flow being sent on a set of path elements (e.g.,
RTT, one-way delay). A property is thus described by a tuple
containing the ordered set of path elements, the set of packets
traversing the path (the flow) or an empty set if no packets are
relevant for the property, the name of the trait (e.g., maximum
data rate), and the value of the trait (e.g., 100mbps).
Aggregated Property: A property can be aggregated over a set of path
elements (e.g., MTU in the network backbone as the minimum MTU of
the individual path elements), or over a set of packets (e.g.,
Enghardt & KraehenbuehlExpires September 12, 2019 [Page 4]
Internet-Draft Path Properties March 2019
median one-way latency of all packets during the last second), or
over both (e.g., average time a packets spends in buffers outside
the local network). Aggregation can be numerical (average, sum,
min, ...), logical (true if all are true, true if at least X are
true, ...), or an arbitrary function which maps a set of input
properties to an output property.
Measured & Potential Property: A property can be classified by
timescale into a measured property, based on concrete previous and
current measurements, and a potential property, which is a
property with predicted characteristics, possibly including the
reliability of such predictions. An example of a potential
property with a high reliability is the maximum data rate of an
ethernet link in the local network during the next day, while a
potential property with a lower reliability is the expected one-
way latency of packets sent to an endpoint on the other side of
the planet during the next second. The notion of reliability
depends on the property, it might be the confidence level and
interval for numerical properties or the likelihood that a
property holds for non-numerical properties.
3. Domain Properties
Domain path properties relate to path elements within the first hop
or the first few hops, which are usually in the same administrative
domain as an endpoint considering them.
Due to the potential physical proximity and pre-existing trust or
contractual relationships between endpoints and path elements within
the same domain, domain properties may be more accessible to the
endpoint than other properties.
Furthermore, endpoints may be able to influence both which domain
they are in and which path elements in this domain to connect to, and
they may be able to influence the properties of path elements within
this domain. For example, a user might select between multiple
potential adjacent path elements by selecting between multiple
available WiFi Access Points. Or when connected to an Access Point,
the user may move closer to enable their device to use a different
access technology, potentially increasing the data rate available to
the device. Another example is a user changing their data plan to
reduce the Monetary Cost to transmit a given amount of data across a
network.
Access Technology: The physical or link layer technology used for
transmitting or receiving a flow on one or multiple path elements
in the same domain. The Access Technology may be given in an
abstract way, e.g., as a WiFi, Wired Ethernet, or Cellular link.
Enghardt & KraehenbuehlExpires September 12, 2019 [Page 5]
Internet-Draft Path Properties March 2019
It may also be given as a specific technology, e.g., as a 2G, 3G,
4G, or 5G cellular link, or an 802.11a, b, g, n, or ac WiFi link.
Other path elements relevant to the access technology may include
on-path devices, such as elements of a cellular backbone network.
Note that there is no common registry of possible values for this
property.
Monetary Cost: The price to be paid to transmit a specific flow
across a path segment.
4. Backbone Properties
Backbone path properties relate to path elements not within the same
domain as an endpoint considering them, thus, in the backbone from
the endpoint's point of view.
Typically, backbone properties are less accessible to an endpoint
than domain properties, due to the potential increased distance and
the lack of pre-existing trust or contractual relationship.
Additionally, endpoints are less likely to be able to influence which
path elements form their path in the backbone, as well as their
properties.
Some path properties relate to the entire path, part of which often
lies outside of an endpoint's domain. Thus, such properties are
listed as Backbone Properties.
Presence of a certain network function on the path: Indicates that a
certain path element performs a certain network function on a
flow, e.g., whether the path element acts as a proxy, as a
firewall, or performs Network Address Translation (NAT). This
path element may be either in the same domain as the endpoint or
in a different domain, i.e., the backbone.
Administrative Entity: The administrative entity, e.g., the AS, to
which a path element or path segment belongs.
Disjointness: For a set of two paths, the number of shared path
elements can be a measure of intersection (e.g., Jaccard
coefficient, which is the number of shared elements divided by the
total number of elements). Conversely, the number of non-shared
path elements can be a measure of disjointness (e.g., 1 - Jaccard
coefficient). A multipath protocol might use disjointness of
paths as a metric to reduce the number of single points of
failure.
Enghardt & KraehenbuehlExpires September 12, 2019 [Page 6]
Internet-Draft Path Properties March 2019
Path MTU: The maximum size, in octets, of an IP packet that can be
transmitted without fragmentation on a path segment.
Transport Protocols available: Whether a specific transport protocol
can be used to establish a connection over a path or path segment.
An endpoint may cache its knowledge about recent successfully
established connections using specific protocols, e.g., a QUIC
connection, or an MPTCP subflow, over a specific path.
Protocol Features available: Whether a specific protocol feature is
available over this path, e.g., Explicit Congestion Notification
(ECN), or TCP Fast Open.
5. Dynamic Properties
Dynamic path properties relate to a path segment with respect to the
transmission of an individual packet or of a flow over this path
segment. Properties related to a path element which constitutes a
single layer 2 domain are abstracted from the used physical and link
layer technology, similar to [RFC8175].
Typically, Dynamic Properties can only be approximated and sampled,
and might be made available in an aggregated form, such as averages
or minimums. Dynamic Path Properties can be measured by the endpoint
itself or somethere in the network. See [ANRW18-Metrics] for a
discussion of how to measure some dynamic path properties at the
endpoint.
Some dynamic properties are defined in different directions for the
same path element, e.g., for transmitting and receiving packets.
Maximum Data Rate (Transmit/Receive): The theoretical maximum data
rate, in bits per second, that can be achieved on a link, path
segment, or path, for receiving or transmitting traffic.
Current Data Rate (Transmit/Receive): The data rate, in bits per
second, at which a link is currently receiving or transmitting
traffic.
Latency: The time delay between sending a packet on a path element
and receiving the same packet on a different path element.
Latency variation: The variation of the Latency within a flow.
Packet Loss: The percentage of packets within a flow which are sent
by one path element, but not received by a different path element.
Enghardt & KraehenbuehlExpires September 12, 2019 [Page 7]
Internet-Draft Path Properties March 2019
Congestion: Whether a protocol feature such as ECN has provided
information that there currently is congestion on a path.
6. Security Considerations
If devices are basing policy or path selection decisions on path
properties, they need to rely on the accuracy of path properties that
other devices communicate to them. In order to be able to trust such
path properties, devices may need to establish a trust relationship
or be able to verify the authenticity, integrity, and correctness of
path properties received from another device.
7. IANA Considerations
This document has no IANA actions.
8. Informative References
[ANRW18-Metrics]
Enghardt, T., Tiesel, P., and A. Feldmann, "Metrics for
access network selection", Proceedings of the Applied
Networking Research Workshop on - ANRW '18,
DOI 10.1145/3232755.3232764, 2018.
[I-D.irtf-panrg-questions]
Trammell, B., "Open Questions in Path Aware Networking",
draft-irtf-panrg-questions-01 (work in progress), October
2018.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
DOI 10.17487/RFC5693, October 2009,
<https://www.rfc-editor.org/info/rfc5693>.
[RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B.
Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175,
DOI 10.17487/RFC8175, June 2017,
<https://www.rfc-editor.org/info/rfc8175>.
Acknowledgments
Thanks to the Path-Aware Networking Research Group for the discussion
and feedback. Thanks to Adrian Perrig for the feedback. Thanks to
Paul Hoffman for the editorial changes.
Enghardt & KraehenbuehlExpires September 12, 2019 [Page 8]
Internet-Draft Path Properties March 2019
Authors' Addresses
Theresa Enghardt
TU Berlin
Email: theresa@inet.tu-berlin.de
Cyrill Kraehenbuehl
ETH Zuerich
Email: cyrill.kraehenbuehl@inf.ethz.ch
Enghardt & KraehenbuehlExpires September 12, 2019 [Page 9]