idnits 2.17.1 draft-enghardt-panrg-path-properties-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2018) is 2017 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-irtf-panrg-questions-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANRG T. Enghardt 3 Internet-Draft TU Berlin 4 Intended status: Informational C. Kraehenbuehl 5 Expires: April 21, 2019 ETH Zuerich 6 October 18, 2018 8 A Vocabulary of Path Properties 9 draft-enghardt-panrg-path-properties-00 11 Abstract 13 This document defines and categorizes information about Internet 14 paths that an endpoint might have or want to have. This information 15 is expressed as properties of paths between two endpoints. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 21, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Domain Properties . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Backbone Properties . . . . . . . . . . . . . . . . . . . . . 3 54 4. Dynamic Properties . . . . . . . . . . . . . . . . . . . . . 4 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 7. Informative References . . . . . . . . . . . . . . . . . . . 6 58 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 61 1. Introduction 63 Because the current Internet provides an IP-based best-effort bit 64 pipe, endpoints have little information about paths to other 65 endpoints. A Path Aware Network exposes information about one or 66 multiple paths through the network to endpoints, so that endpoints 67 can use this information. 69 Such path properties may be relatively dynamic, e.g. current Round 70 Trip Time, close to the origin, e.g. nature of the access technology 71 on the first hop, or far from the origin, e.g. list of ASes 72 traversed. 74 Usefulness over time is fundamentally different for dynamic and non- 75 dynamic properties. The merit of a momentary measurement of a 76 dynamic path property diminishes greatly as time goes on, e.g. the 77 merit of an RTT measurement from a few seconds ago is quite small, 78 while a non-dynamic path property might stay relevant, e.g. a NAT can 79 be assumed to stay on a path during the lifetime of a connection, as 80 the removal of the NAT would break the connection. 82 Non-dynamic properties are further separated into (local) domain 83 properties related to the first few hops of the connection, and 84 backbone properties related to the remaining hops. Domain properties 85 expose a high amount of information to endpoints and strongly 86 influence the connection behavior while there is little influence and 87 information about backbone properties. 89 Dynamic properties are not separated into domain and backbone 90 properties, since most of these properties are defined for a complete 91 path and it is difficult and seldom useful to define them on part of 92 the path. There are exceptions such as dynamic wireless access 93 properties, but these do not justify separation into different 94 categories. 96 This document addresses the first of the questions in Path-Aware 97 Networking [I-D.irtf-panrg-questions], which is a product of the 98 PANRG in the IRTF. 100 2. Domain Properties 102 Domain path properties usually relate to the access network within 103 the first hop or the first few hops. Endpoints can influence domain 104 properties for example by switching from a WiFi to a cellular 105 interface, changing their data plan to increase throughput, or moving 106 closer to a wireless access point which increases the signal 107 strength. 109 A large amount of information about domain properties exists. 110 Properties related to configuration can be queried using provisioning 111 domains (PvDs). A PvD is a consistent set of network configuration 112 information as defined in [RFC7556], e.g., relating to a local 113 network interface. This may include source IP address prefixes, IP 114 addresses of DNS servers, name of an HTTP proxy server, DNS suffixes 115 associated with the network, or default gateway IP address. As one 116 PvD is not restricted to one local network interface, a PvD may also 117 apply to multiple paths. 119 Access Technology present on the path: The lower layer technology on 120 the first hop, for example, WiFi, Wired Ethernet, or Cellular. 121 This can also be more detailed, e.g., further specifying the 122 Cellular as 2G, 3G, 4G, or 5G technology, or the WiFi as 802.11a, 123 b, g, n, or ac. These are just examples, this list is not 124 exhaustive, and there is no common index of identifiers here. 125 Note that access technologies further along the path may also be 126 relevant, e.g., a cellular backbone is not only the first hop, and 127 there may be a DSL line behind the WiFi. 129 Monetary Cost: This is information related to billing, data caps, 130 etc. It could be the allowed monthly data cap, the start and end 131 of a billing period, the monetary cost per Megabyte sent or 132 received, etc. 134 3. Backbone Properties 136 Backbone path properties relate to non-dynamic path properties that 137 are not within the endpoint's domain. They are likely to stay 138 constant within the lifetime of a connection, since Internet 139 "backbone" routes change infrequently. These properties usually 140 change on the timescale of seconds, minutes, or hours, when the route 141 changes. 143 Even if these properties change, endpoints can neither specify which 144 backbone nodes to use, nor verify data was sent over these nodes. An 145 endpoint can for example choose its access provider, but cannot 146 choose the backbone path to a given destination since the access 147 provider will make their own policy-based routing decision. 149 Presence of certain device on the path: Could be the presence of a 150 certain kind of middlebox, e.g., a proxy, a firewall, a NAT. 152 Presence of a packet forwarding node or specific Autonomous System on 153 a path: 154 Indicates that traffic goes through a certain node or AS, which 155 might be relevant for deciding the level of trust this path 156 provides. 158 Disjointness: How disjoint a path is from another path. 160 Path MTU: The end-to-end maximum transmission unit in one packet. 162 Transport Protocols available: Whether a specific transport protocol 163 can be used to establish a connection over this path. An endpoint 164 may know this because it has cached whether it could successfully 165 establish, e.g., a QUIC connection, or an MPTCP subflow. 167 Protocol Features available: Whether a specific feature within a 168 protocol is known to work over this path, e.g., ECN, or TCP Fast 169 Open. 171 4. Dynamic Properties 173 Dynamic Path Properties are expected to change on the timescale of 174 milliseconds. They usually relate to the state of the path, such as 175 the currently available end-to-end bandwidth. Some of these 176 properties may depend only on the first hop or on the access network, 177 some may depend on the entire path. 179 Typically, Dynamic Properties can only be approximated and sampled, 180 and might be made available in an aggregated form, such as averages 181 or minimums. Dynamic Path Properties can be measured by the endpoint 182 itself or somethere in the network. See [ANRW18-Metrics] for a 183 discussion of how to measure some dynamic path properties at the 184 endpoint. 186 These properties may be symmetric or asymmetric. For example, an 187 asymmetric property may be different in the upstream direction and in 188 the downstream direction from the point of view of a particular host. 190 Available bandwidth: Maximum number of bytes per second that can be 191 sent or received over this path. This depends on the available 192 bandwidth at the bottleneck, and on crosstraffic. 194 Round Trip Time: Time from sending a packet to receiving a response 195 from the remote endpoint. 197 Round Trip Time variation: Disparity of Round Trip Time values 198 either over time or among multiple concurrent connections. A high 199 RTT variation often indicates congestion. 201 Packet Loss: Percentage of sent packets that are not received on the 202 other end. 204 Congestion: Whether there is any indication of congestion on the 205 path. 207 Wireless Signal strength: Power level of the wireless signal being 208 received. Lower signal strength, relative to the same noise 209 floor, is correlated with higher bit error rates and lower 210 modulation rates. 212 Wireless Modulation Rate: Modulation bitrate of the wireless signal. 213 The modulation rate determines how many bytes are transmitted 214 within a symbol on the wireless channel. A high modulation rate 215 leads to a higher possible bitrate, given sufficient signal 216 strength. 218 Wireless Channel utilization: Percentage of time during which there 219 is a transmission on the wireless medium. A high channel 220 utilization indicates a congested wireless network. 222 5. Security Considerations 224 Some of these properties may have security implications for 225 endpoints. For example, a corporate policy might require to have a 226 firewall on the path. 228 For properties provided by the network, their authenticity and 229 correctness may need to be verified by an endpoint. 231 6. IANA Considerations 233 This document has no IANA actions. 235 7. Informative References 237 [ANRW18-Metrics] 238 Enghardt, T., Tiesel, P., and A. Feldmann, "Metrics for 239 access network selection", Proceedings of the Applied 240 Networking Research Workshop on - ANRW '18, 241 DOI 10.1145/3232755.3232764, 2018. 243 [I-D.irtf-panrg-questions] 244 Trammell, B., "Open Questions in Path Aware Networking", 245 draft-irtf-panrg-questions-00 (work in progress), April 246 2018. 248 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 249 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 250 . 252 Acknowledgments 254 Thanks to Paul Hoffman for feedback and editorial changes. 256 Authors' Addresses 258 Theresa Enghardt 259 TU Berlin 261 Email: theresa@inet.tu-berlin.de 263 Cyrill Kraehenbuehl 264 ETH Zuerich 266 Email: cyrill.kraehenbuehl@inf.ethz.ch