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
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.
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 (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.
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.
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.
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.
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.
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.
This document has no IANA actions.
[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. |
Thanks to Paul Hoffman for feedback and editorial changes.