idnits 2.17.1 draft-enghardt-panrg-path-properties-01.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 (March 11, 2019) is 1867 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-01 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: September 12, 2019 ETH Zuerich 6 March 11, 2019 8 A Vocabulary of Path Properties 9 draft-enghardt-panrg-path-properties-01 11 Abstract 13 This document defines and categorizes information about Internet 14 paths that an entity, such as an endpoint, might have or want to 15 have. This information is expressed as properties of paths between 16 two endpoints. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 12, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Domain Properties . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Backbone Properties . . . . . . . . . . . . . . . . . . . . . 6 56 5. Dynamic Properties . . . . . . . . . . . . . . . . . . . . . 7 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 59 8. Informative References . . . . . . . . . . . . . . . . . . . 8 60 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 63 1. Introduction 65 Because the current Internet provides an IP-based best-effort bit 66 pipe, endpoints have little information about paths to other 67 endpoints. A Path Aware Network exposes information about one or 68 multiple paths through the network to endpoints or the network 69 infrastructure. 71 It is impossible to provide an exhaustive list of path properties, as 72 with every new technology and protocol, novel properties might become 73 relevant. In this document, we specify a set of path properties 74 which might be useful in the following use cases: Traffic policies, 75 network monitoring, and path selection. 77 o Traffic policies: Entities such as network operators or end users 78 may want to define traffic policies leveraging path awareness. 79 Such policies can allow or disallow sending traffic over specific 80 networks or nodes, select an appropriate protocol depending on the 81 capabilities of the on-path devices, or adjust protocol parameters 82 to an existing path. An example of a traffic policy is a video 83 streaming application choosing an (initial) video quality based on 84 the achievable data rate, or the monetary cost of the link using a 85 volume-based or flat-rate cost model. Another example is an 86 enterprise network where all traffic has to go through a firewall, 87 in which case the endpoint needs to be aware of on-path firewalls. 89 o Network monitoring: Network operators can use path properties 90 (e.g., measured by on-path devices), to observe Quality of Service 91 (QoS) characteristics of recent end-user traffic, and identify 92 potential problems with their network early on, before the end- 93 user complains. 95 o Path selection: In some cases, entities can choose to use a 96 certain path (or subset of paths) from a set of paths to achieve a 97 specific goal. As the possible benefits of a well chosen path 98 varies based on the goal, as a baseline, a path selection 99 algorithm should aim to not perform worse than the default case 100 most of the time. Depending on the goal, an entity may prefer 101 paths with different properties, e.g., retrieving a small webpage 102 as quickly as possible requires low latency paths, or retrieving a 103 large file in a peer-to-peer network requires paths with high 104 achievable data rate. Additionally, there may be trade-offs 105 between path properties (e.g., latency and data rate), and 106 entities may influence these trade-offs with their choices. A 107 network (e.g., an AS) can adjust its path selection for internal 108 or external routing based on the path properties. In BGP, the 109 Multi Exit Discriminator (MED) attribute decides which path to 110 choose if other attributes are equal; in a path aware network, 111 instead of using this single MED value, other properties such as 112 maximum or available/expected data rate could additionally be used 113 to improve load balancing. An endpoint might be able to select 114 between a set of paths, either if there are several paths to the 115 same destination (e.g., if the endpoint is a mobile device with 116 two wireless interfaces, both providing a path), or if there are 117 several destinations, and thus several paths, providing the same 118 service (e.g., Application-Layer Traffic Optimization (ALTO) 119 [RFC5693], an application layer peer-to-peer protocol allowing 120 endpoints a better-than-random peer selection). Care needs to be 121 taken when selecting paths based on path properties, as path 122 properties that were previously measured may have become outdated 123 and, thus, useless to predict the path properties of packets sent 124 now. 126 Such path properties may be relatively dynamic, e.g. current Round 127 Trip Time, close to the origin, e.g. nature of the access technology 128 on the first hop, or far from the origin, e.g. list of ASes 129 traversed. 131 Usefulness over time is fundamentally different for dynamic and non- 132 dynamic properties. The merit of a momentary measurement of a 133 dynamic path property diminishes greatly as time goes on, e.g. the 134 merit of an RTT measurement from a few seconds ago is quite small, 135 while a non-dynamic path property might stay relevant, e.g. a NAT can 136 be assumed to stay on a path during the lifetime of a connection, as 137 the removal of the NAT would break the connection. 139 Non-dynamic properties are further separated into (local) domain 140 properties related to the first few hops of the connection, and 141 backbone properties related to the remaining hops. Domain properties 142 expose a high amount of information to endpoints and strongly 143 influence the connection behavior while there is little influence and 144 information about backbone properties. 146 Dynamic properties are not separated into domain and backbone 147 properties, since most of these properties are defined for a complete 148 path and it is difficult and seldom useful to define them on part of 149 the path. There are exceptions such as dynamic wireless access 150 properties, but these do not justify separation into different 151 categories. 153 This document addresses the first of the questions in Path-Aware 154 Networking [I-D.irtf-panrg-questions], which is a product of the 155 PANRG in the IRTF. 157 2. Terminology 159 Path element: A path element is a device (including the endpoints), 160 or link used to connect two devices and transmit information on a 161 specific layer. Path elements may exist on multiple layers (e.g., 162 the endpoint corresponds to a path element on every layer), may be 163 hidden on higher layers (e.g., a layer 2 switch in the local 164 network), or a path element may be an aggregation of several path 165 elements on a lower layer (e.g., the link connecting the endpoints 166 on the transport layer being an aggregation of all network layer 167 path elements). 169 Path segment: A path segment is an ordered set of path elements at 170 the network layer that can be traversed by a packet. 172 Path: A path is defined as an ordered set of path elements at the 173 network layer between two endpoints. A path can be traversed by a 174 packet. 176 Flow: Several packets traversing the same path elements can be 177 combined into a flow (e.g., all packets sent within a UDP session 178 which traverse the same path elements). As a special case, a flow 179 can consist of just one packet. 181 Property: A property describes a trait of a set of path elements 182 (e.g., capacity of a link, is device X a firewall, one-way maximum 183 data rate which is the minimum of all links' maximum data rates), 184 or a trait of a flow being sent on a set of path elements (e.g., 185 RTT, one-way delay). A property is thus described by a tuple 186 containing the ordered set of path elements, the set of packets 187 traversing the path (the flow) or an empty set if no packets are 188 relevant for the property, the name of the trait (e.g., maximum 189 data rate), and the value of the trait (e.g., 100mbps). 191 Aggregated Property: A property can be aggregated over a set of path 192 elements (e.g., MTU in the network backbone as the minimum MTU of 193 the individual path elements), or over a set of packets (e.g., 194 median one-way latency of all packets during the last second), or 195 over both (e.g., average time a packets spends in buffers outside 196 the local network). Aggregation can be numerical (average, sum, 197 min, ...), logical (true if all are true, true if at least X are 198 true, ...), or an arbitrary function which maps a set of input 199 properties to an output property. 201 Measured & Potential Property: A property can be classified by 202 timescale into a measured property, based on concrete previous and 203 current measurements, and a potential property, which is a 204 property with predicted characteristics, possibly including the 205 reliability of such predictions. An example of a potential 206 property with a high reliability is the maximum data rate of an 207 ethernet link in the local network during the next day, while a 208 potential property with a lower reliability is the expected one- 209 way latency of packets sent to an endpoint on the other side of 210 the planet during the next second. The notion of reliability 211 depends on the property, it might be the confidence level and 212 interval for numerical properties or the likelihood that a 213 property holds for non-numerical properties. 215 3. Domain Properties 217 Domain path properties relate to path elements within the first hop 218 or the first few hops, which are usually in the same administrative 219 domain as an endpoint considering them. 221 Due to the potential physical proximity and pre-existing trust or 222 contractual relationships between endpoints and path elements within 223 the same domain, domain properties may be more accessible to the 224 endpoint than other properties. 226 Furthermore, endpoints may be able to influence both which domain 227 they are in and which path elements in this domain to connect to, and 228 they may be able to influence the properties of path elements within 229 this domain. For example, a user might select between multiple 230 potential adjacent path elements by selecting between multiple 231 available WiFi Access Points. Or when connected to an Access Point, 232 the user may move closer to enable their device to use a different 233 access technology, potentially increasing the data rate available to 234 the device. Another example is a user changing their data plan to 235 reduce the Monetary Cost to transmit a given amount of data across a 236 network. 238 Access Technology: The physical or link layer technology used for 239 transmitting or receiving a flow on one or multiple path elements 240 in the same domain. The Access Technology may be given in an 241 abstract way, e.g., as a WiFi, Wired Ethernet, or Cellular link. 243 It may also be given as a specific technology, e.g., as a 2G, 3G, 244 4G, or 5G cellular link, or an 802.11a, b, g, n, or ac WiFi link. 245 Other path elements relevant to the access technology may include 246 on-path devices, such as elements of a cellular backbone network. 247 Note that there is no common registry of possible values for this 248 property. 250 Monetary Cost: The price to be paid to transmit a specific flow 251 across a path segment. 253 4. Backbone Properties 255 Backbone path properties relate to path elements not within the same 256 domain as an endpoint considering them, thus, in the backbone from 257 the endpoint's point of view. 259 Typically, backbone properties are less accessible to an endpoint 260 than domain properties, due to the potential increased distance and 261 the lack of pre-existing trust or contractual relationship. 263 Additionally, endpoints are less likely to be able to influence which 264 path elements form their path in the backbone, as well as their 265 properties. 267 Some path properties relate to the entire path, part of which often 268 lies outside of an endpoint's domain. Thus, such properties are 269 listed as Backbone Properties. 271 Presence of a certain network function on the path: Indicates that a 272 certain path element performs a certain network function on a 273 flow, e.g., whether the path element acts as a proxy, as a 274 firewall, or performs Network Address Translation (NAT). This 275 path element may be either in the same domain as the endpoint or 276 in a different domain, i.e., the backbone. 278 Administrative Entity: The administrative entity, e.g., the AS, to 279 which a path element or path segment belongs. 281 Disjointness: For a set of two paths, the number of shared path 282 elements can be a measure of intersection (e.g., Jaccard 283 coefficient, which is the number of shared elements divided by the 284 total number of elements). Conversely, the number of non-shared 285 path elements can be a measure of disjointness (e.g., 1 - Jaccard 286 coefficient). A multipath protocol might use disjointness of 287 paths as a metric to reduce the number of single points of 288 failure. 290 Path MTU: The maximum size, in octets, of an IP packet that can be 291 transmitted without fragmentation on a path segment. 293 Transport Protocols available: Whether a specific transport protocol 294 can be used to establish a connection over a path or path segment. 295 An endpoint may cache its knowledge about recent successfully 296 established connections using specific protocols, e.g., a QUIC 297 connection, or an MPTCP subflow, over a specific path. 299 Protocol Features available: Whether a specific protocol feature is 300 available over this path, e.g., Explicit Congestion Notification 301 (ECN), or TCP Fast Open. 303 5. Dynamic Properties 305 Dynamic path properties relate to a path segment with respect to the 306 transmission of an individual packet or of a flow over this path 307 segment. Properties related to a path element which constitutes a 308 single layer 2 domain are abstracted from the used physical and link 309 layer technology, similar to [RFC8175]. 311 Typically, Dynamic Properties can only be approximated and sampled, 312 and might be made available in an aggregated form, such as averages 313 or minimums. Dynamic Path Properties can be measured by the endpoint 314 itself or somethere in the network. See [ANRW18-Metrics] for a 315 discussion of how to measure some dynamic path properties at the 316 endpoint. 318 Some dynamic properties are defined in different directions for the 319 same path element, e.g., for transmitting and receiving packets. 321 Maximum Data Rate (Transmit/Receive): The theoretical maximum data 322 rate, in bits per second, that can be achieved on a link, path 323 segment, or path, for receiving or transmitting traffic. 325 Current Data Rate (Transmit/Receive): The data rate, in bits per 326 second, at which a link is currently receiving or transmitting 327 traffic. 329 Latency: The time delay between sending a packet on a path element 330 and receiving the same packet on a different path element. 332 Latency variation: The variation of the Latency within a flow. 334 Packet Loss: The percentage of packets within a flow which are sent 335 by one path element, but not received by a different path element. 337 Congestion: Whether a protocol feature such as ECN has provided 338 information that there currently is congestion on a path. 340 6. Security Considerations 342 If devices are basing policy or path selection decisions on path 343 properties, they need to rely on the accuracy of path properties that 344 other devices communicate to them. In order to be able to trust such 345 path properties, devices may need to establish a trust relationship 346 or be able to verify the authenticity, integrity, and correctness of 347 path properties received from another device. 349 7. IANA Considerations 351 This document has no IANA actions. 353 8. Informative References 355 [ANRW18-Metrics] 356 Enghardt, T., Tiesel, P., and A. Feldmann, "Metrics for 357 access network selection", Proceedings of the Applied 358 Networking Research Workshop on - ANRW '18, 359 DOI 10.1145/3232755.3232764, 2018. 361 [I-D.irtf-panrg-questions] 362 Trammell, B., "Open Questions in Path Aware Networking", 363 draft-irtf-panrg-questions-01 (work in progress), October 364 2018. 366 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 367 Optimization (ALTO) Problem Statement", RFC 5693, 368 DOI 10.17487/RFC5693, October 2009, 369 . 371 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 372 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 373 DOI 10.17487/RFC8175, June 2017, 374 . 376 Acknowledgments 378 Thanks to the Path-Aware Networking Research Group for the discussion 379 and feedback. Thanks to Adrian Perrig for the feedback. Thanks to 380 Paul Hoffman for the editorial changes. 382 Authors' Addresses 384 Theresa Enghardt 385 TU Berlin 387 Email: theresa@inet.tu-berlin.de 389 Cyrill Kraehenbuehl 390 ETH Zuerich 392 Email: cyrill.kraehenbuehl@inf.ethz.ch