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

PANRG                                                        T. Enghardt
Internet-Draft                                                 TU Berlin
Intended status: Informational                           C. Kraehenbuehl
Expires: April 21, 2019                                      ETH Zuerich
                                                        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.

Enghardt & Kraehenbuehl  Expires April 21, 2019                 [Page 1]
Internet-Draft               Path Properties                October 2018

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Domain Properties . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Backbone Properties . . . . . . . . . . . . . . . . . . . . .   3
   4.  Dynamic Properties  . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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.

Enghardt & Kraehenbuehl  Expires April 21, 2019                 [Page 2]
Internet-Draft               Path Properties                October 2018

   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.

Enghardt & Kraehenbuehl  Expires April 21, 2019                 [Page 3]
Internet-Draft               Path Properties                October 2018

   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.

Enghardt & Kraehenbuehl  Expires April 21, 2019                 [Page 4]
Internet-Draft               Path Properties                October 2018

   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.

Enghardt & Kraehenbuehl  Expires April 21, 2019                 [Page 5]
Internet-Draft               Path Properties                October 2018

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",
              draft-irtf-panrg-questions-00 (work in progress), April
              2018.

   [RFC7556]  Anipko, D., Ed., "Multiple Provisioning Domain
              Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
              <https://www.rfc-editor.org/info/rfc7556>.

Acknowledgments

   Thanks to Paul Hoffman for feedback and editorial changes.

Authors' Addresses

   Theresa Enghardt
   TU Berlin

   Email: theresa@inet.tu-berlin.de

   Cyrill Kraehenbuehl
   ETH Zuerich

   Email: cyrill.kraehenbuehl@inf.ethz.ch

Enghardt & Kraehenbuehl  Expires April 21, 2019                 [Page 6]