PANRG T. Enghardt
Internet-Draft TU Berlin
Intended status: Informational C. Krähenbühl
Expires: April 21, 2019 ETH Zürich
October 18, 2018

A Vocabulary of Path Properties
draft-enghardt-panrg-path-properties-00

Abstract

This document defines and categorizes information about Internet paths that 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 April 21, 2019.

Copyright Notice

Copyright (c) 2018 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.


Table of Contents

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, so that endpoints can use this information.

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.

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. Domain Properties

Domain path properties usually relate to the access network within the first hop or the first few hops. Endpoints can influence domain properties for example by switching from a WiFi to a cellular interface, changing their data plan to increase throughput, or moving closer to a wireless access point which increases the signal strength.

A large amount of information about domain properties exists. Properties related to configuration can be queried using provisioning 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 the first hop, for example, WiFi, Wired Ethernet, or Cellular. This can also be more detailed, e.g., further specifying the 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, etc. It could be the allowed monthly data cap, the start and end of a billing period, the monetary cost per Megabyte sent or received, etc.

3. Backbone Properties

Backbone path properties relate to non-dynamic path properties that are not within the endpoint’s domain. They are likely to stay constant within the lifetime of a connection, since Internet “backbone” routes change infrequently. These properties usually change on the timescale of seconds, minutes, or hours, when the route changes.

Even if these properties change, endpoints can neither specify which backbone nodes to use, nor verify data was sent over these nodes. An endpoint can for example choose its access provider, but cannot choose the backbone path to a given destination since the access provider will make their own policy-based routing decision.

Presence of certain device on the path:
Could be the presence of a certain kind of middlebox, e.g., a proxy, a firewall, a NAT.
Presence of a packet forwarding node or specific Autonomous System on a path:
Indicates that traffic goes through a certain node or AS, which might be relevant for deciding the level of trust this path provides.
Disjointness:
How disjoint a path is from another path.
Path MTU:
The end-to-end maximum transmission unit in one packet.
Transport Protocols available:
Whether a specific transport protocol can be used to establish a connection over this path. An endpoint may know this because it has cached whether it could successfully establish, e.g., a QUIC connection, or an MPTCP subflow.
Protocol Features available:
Whether a specific feature within a protocol is known to work over this path, e.g., ECN, or TCP Fast Open.

4. Dynamic Properties

Dynamic Path Properties are expected to change on the timescale of milliseconds. They usually relate to the state of the path, such as the currently available end-to-end bandwidth. Some of these properties may depend only on the first hop or on the access network, some may depend on the entire path.

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.

These properties may be symmetric or asymmetric. For example, an asymmetric property may be different in the upstream direction and in 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 other end.
Congestion:
Whether there is any indication of congestion on the path.
Wireless Signal strength:
Power level of the wireless signal being received. Lower signal strength, relative to the same noise floor, is correlated with higher bit error rates and lower modulation rates.
Wireless Modulation Rate:
Modulation bitrate of the wireless signal. 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 is a transmission on the wireless medium. A high channel utilization indicates a congested wireless network.

5. Security Considerations

Some of these properties may have security implications for endpoints. For example, a corporate policy might require to have a firewall on the path.

For properties provided by the network, their authenticity and correctness may need to be verified by an endpoint.

6. IANA Considerations

This document has no IANA actions.

7. 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", Internet-Draft draft-irtf-panrg-questions-00, April 2018.
[RFC7556] Anipko, D., "Multiple Provisioning Domain Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015.

Acknowledgments

Thanks to Paul Hoffman for feedback and editorial changes.

Authors' Addresses

Theresa Enghardt TU Berlin EMail: theresa@inet.tu-berlin.de
Cyrill Krähenbühl ETH Zürich EMail: cyrill.kraehenbuehl@inf.ethz.ch