< draft-enghardt-panrg-path-properties-00.txt   draft-enghardt-panrg-path-properties-01.txt >
PANRG T. Enghardt PANRG T. Enghardt
Internet-Draft TU Berlin Internet-Draft TU Berlin
Intended status: Informational C. Kraehenbuehl Intended status: Informational C. Kraehenbuehl
Expires: April 21, 2019 ETH Zuerich Expires: September 12, 2019 ETH Zuerich
October 18, 2018 March 11, 2019
A Vocabulary of Path Properties A Vocabulary of Path Properties
draft-enghardt-panrg-path-properties-00 draft-enghardt-panrg-path-properties-01
Abstract Abstract
This document defines and categorizes information about Internet This document defines and categorizes information about Internet
paths that an endpoint might have or want to have. This information paths that an entity, such as an endpoint, might have or want to
is expressed as properties of paths between two endpoints. have. This information is expressed as properties of paths between
two endpoints.
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 April 21, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Domain Properties . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Backbone Properties . . . . . . . . . . . . . . . . . . . . . 3 3. Domain Properties . . . . . . . . . . . . . . . . . . . . . . 5
4. Dynamic Properties . . . . . . . . . . . . . . . . . . . . . 4 4. Backbone Properties . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Dynamic Properties . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Informative References . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Because the current Internet provides an IP-based best-effort bit Because the current Internet provides an IP-based best-effort bit
pipe, endpoints have little information about paths to other pipe, endpoints have little information about paths to other
endpoints. A Path Aware Network exposes information about one or endpoints. A Path Aware Network exposes information about one or
multiple paths through the network to endpoints, so that endpoints multiple paths through the network to endpoints or the network
can use this information. 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
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 Such path properties may be relatively dynamic, e.g. current Round
Trip Time, close to the origin, e.g. nature of the access technology 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 on the first hop, or far from the origin, e.g. list of ASes
traversed. traversed.
Usefulness over time is fundamentally different for dynamic and non- Usefulness over time is fundamentally different for dynamic and non-
dynamic properties. The merit of a momentary measurement of a dynamic properties. The merit of a momentary measurement of a
dynamic path property diminishes greatly as time goes on, e.g. the 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, merit of an RTT measurement from a few seconds ago is quite small,
skipping to change at page 3, line 9 skipping to change at page 4, line 16
properties, since most of these properties are defined for a complete 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 path and it is difficult and seldom useful to define them on part of
the path. There are exceptions such as dynamic wireless access the path. There are exceptions such as dynamic wireless access
properties, but these do not justify separation into different properties, but these do not justify separation into different
categories. categories.
This document addresses the first of the questions in Path-Aware This document addresses the first of the questions in Path-Aware
Networking [I-D.irtf-panrg-questions], which is a product of the Networking [I-D.irtf-panrg-questions], which is a product of the
PANRG in the IRTF. PANRG in the IRTF.
2. Domain Properties 2. Terminology
Domain path properties usually relate to the access network within Path element: A path element is a device (including the endpoints),
the first hop or the first few hops. Endpoints can influence domain or link used to connect two devices and transmit information on a
properties for example by switching from a WiFi to a cellular specific layer. Path elements may exist on multiple layers (e.g.,
interface, changing their data plan to increase throughput, or moving the endpoint corresponds to a path element on every layer), may be
closer to a wireless access point which increases the signal hidden on higher layers (e.g., a layer 2 switch in the local
strength. 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).
A large amount of information about domain properties exists. Path segment: A path segment is an ordered set of path elements at
Properties related to configuration can be queried using provisioning the network layer that can be traversed by a packet.
domains (PvDs). A PvD is a consistent set of network configuration
information as defined in [RFC7556], e.g., relating to a local
network interface. This may include source IP address prefixes, IP
addresses of DNS servers, name of an HTTP proxy server, DNS suffixes
associated with the network, or default gateway IP address. As one
PvD is not restricted to one local network interface, a PvD may also
apply to multiple paths.
Access Technology present on the path: The lower layer technology on Path: A path is defined as an ordered set of path elements at the
the first hop, for example, WiFi, Wired Ethernet, or Cellular. network layer between two endpoints. A path can be traversed by a
This can also be more detailed, e.g., further specifying the packet.
Cellular as 2G, 3G, 4G, or 5G technology, or the WiFi as 802.11a,
b, g, n, or ac. These are just examples, this list is not
exhaustive, and there is no common index of identifiers here.
Note that access technologies further along the path may also be
relevant, e.g., a cellular backbone is not only the first hop, and
there may be a DSL line behind the WiFi.
Monetary Cost: This is information related to billing, data caps, Flow: Several packets traversing the same path elements can be
etc. It could be the allowed monthly data cap, the start and end combined into a flow (e.g., all packets sent within a UDP session
of a billing period, the monetary cost per Megabyte sent or which traverse the same path elements). As a special case, a flow
received, etc. can consist of just one packet.
3. Backbone Properties 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).
Backbone path properties relate to non-dynamic path properties that Aggregated Property: A property can be aggregated over a set of path
are not within the endpoint's domain. They are likely to stay elements (e.g., MTU in the network backbone as the minimum MTU of
constant within the lifetime of a connection, since Internet the individual path elements), or over a set of packets (e.g.,
"backbone" routes change infrequently. These properties usually median one-way latency of all packets during the last second), or
change on the timescale of seconds, minutes, or hours, when the route over both (e.g., average time a packets spends in buffers outside
changes. 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.
Even if these properties change, endpoints can neither specify which Measured & Potential Property: A property can be classified by
backbone nodes to use, nor verify data was sent over these nodes. An timescale into a measured property, based on concrete previous and
endpoint can for example choose its access provider, but cannot current measurements, and a potential property, which is a
choose the backbone path to a given destination since the access property with predicted characteristics, possibly including the
provider will make their own policy-based routing decision. 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.
Presence of certain device on the path: Could be the presence of a 3. Domain Properties
certain kind of middlebox, e.g., a proxy, a firewall, a NAT.
Presence of a packet forwarding node or specific Autonomous System on Domain path properties relate to path elements within the first hop
a path: or the first few hops, which are usually in the same administrative
Indicates that traffic goes through a certain node or AS, which domain as an endpoint considering them.
might be relevant for deciding the level of trust this path
provides.
Disjointness: How disjoint a path is from another path. 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.
Path MTU: The end-to-end maximum transmission unit in one packet. 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.
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.
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 Transport Protocols available: Whether a specific transport protocol
can be used to establish a connection over this path. An endpoint can be used to establish a connection over a path or path segment.
may know this because it has cached whether it could successfully An endpoint may cache its knowledge about recent successfully
establish, e.g., a QUIC connection, or an MPTCP subflow. established connections using specific protocols, e.g., a QUIC
connection, or an MPTCP subflow, over a specific path.
Protocol Features available: Whether a specific feature within a Protocol Features available: Whether a specific protocol feature is
protocol is known to work over this path, e.g., ECN, or TCP Fast available over this path, e.g., Explicit Congestion Notification
Open. (ECN), or TCP Fast Open.
4. Dynamic Properties 5. Dynamic Properties
Dynamic Path Properties are expected to change on the timescale of Dynamic path properties relate to a path segment with respect to the
milliseconds. They usually relate to the state of the path, such as transmission of an individual packet or of a flow over this path
the currently available end-to-end bandwidth. Some of these segment. Properties related to a path element which constitutes a
properties may depend only on the first hop or on the access network, single layer 2 domain are abstracted from the used physical and link
some may depend on the entire path. layer technology, similar to [RFC8175].
Typically, Dynamic Properties can only be approximated and sampled, Typically, Dynamic Properties can only be approximated and sampled,
and might be made available in an aggregated form, such as averages and might be made available in an aggregated form, such as averages
or minimums. Dynamic Path Properties can be measured by the endpoint or minimums. Dynamic Path Properties can be measured by the endpoint
itself or somethere in the network. See [ANRW18-Metrics] for a itself or somethere in the network. See [ANRW18-Metrics] for a
discussion of how to measure some dynamic path properties at the discussion of how to measure some dynamic path properties at the
endpoint. endpoint.
These properties may be symmetric or asymmetric. For example, an Some dynamic properties are defined in different directions for the
asymmetric property may be different in the upstream direction and in same path element, e.g., for transmitting and receiving packets.
the downstream direction from the point of view of a particular host.
Available bandwidth: Maximum number of bytes per second that can be
sent or received over this path. This depends on the available
bandwidth at the bottleneck, and on crosstraffic.
Round Trip Time: Time from sending a packet to receiving a response
from the remote endpoint.
Round Trip Time variation: Disparity of Round Trip Time values
either over time or among multiple concurrent connections. A high
RTT variation often indicates congestion.
Packet Loss: Percentage of sent packets that are not received on the Maximum Data Rate (Transmit/Receive): The theoretical maximum data
other end. rate, in bits per second, that can be achieved on a link, path
segment, or path, for receiving or transmitting traffic.
Congestion: Whether there is any indication of congestion on the Current Data Rate (Transmit/Receive): The data rate, in bits per
path. second, at which a link is currently receiving or transmitting
traffic.
Wireless Signal strength: Power level of the wireless signal being Latency: The time delay between sending a packet on a path element
received. Lower signal strength, relative to the same noise and receiving the same packet on a different path element.
floor, is correlated with higher bit error rates and lower
modulation rates.
Wireless Modulation Rate: Modulation bitrate of the wireless signal. Latency variation: The variation of the Latency within a flow.
The modulation rate determines how many bytes are transmitted
within a symbol on the wireless channel. A high modulation rate
leads to a higher possible bitrate, given sufficient signal
strength.
Wireless Channel utilization: Percentage of time during which there Packet Loss: The percentage of packets within a flow which are sent
is a transmission on the wireless medium. A high channel by one path element, but not received by a different path element.
utilization indicates a congested wireless network.
5. Security Considerations Congestion: Whether a protocol feature such as ECN has provided
information that there currently is congestion on a path.
Some of these properties may have security implications for 6. Security Considerations
endpoints. For example, a corporate policy might require to have a
firewall on the path.
For properties provided by the network, their authenticity and If devices are basing policy or path selection decisions on path
correctness may need to be verified by an endpoint. 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.
6. IANA Considerations 7. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
7. Informative References 8. Informative References
[ANRW18-Metrics] [ANRW18-Metrics]
Enghardt, T., Tiesel, P., and A. Feldmann, "Metrics for Enghardt, T., Tiesel, P., and A. Feldmann, "Metrics for
access network selection", Proceedings of the Applied access network selection", Proceedings of the Applied
Networking Research Workshop on - ANRW '18, Networking Research Workshop on - ANRW '18,
DOI 10.1145/3232755.3232764, 2018. DOI 10.1145/3232755.3232764, 2018.
[I-D.irtf-panrg-questions] [I-D.irtf-panrg-questions]
Trammell, B., "Open Questions in Path Aware Networking", Trammell, B., "Open Questions in Path Aware Networking",
draft-irtf-panrg-questions-00 (work in progress), April draft-irtf-panrg-questions-01 (work in progress), October
2018. 2018.
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, Optimization (ALTO) Problem Statement", RFC 5693,
<https://www.rfc-editor.org/info/rfc7556>. 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 Acknowledgments
Thanks to Paul Hoffman for feedback and editorial changes. 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.
Authors' Addresses Authors' Addresses
Theresa Enghardt Theresa Enghardt
TU Berlin TU Berlin
Email: theresa@inet.tu-berlin.de Email: theresa@inet.tu-berlin.de
Cyrill Kraehenbuehl Cyrill Kraehenbuehl
ETH Zuerich ETH Zuerich
 End of changes. 37 change blocks. 
122 lines changed or deleted 248 lines changed or added

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