idnits 2.17.1 draft-enghardt-panrg-path-properties-02.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 (July 08, 2019) is 1752 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-02 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: January 9, 2020 ETH Zuerich 6 July 08, 2019 8 A Vocabulary of Path Properties 9 draft-enghardt-panrg-path-properties-02 11 Abstract 13 This document defines and categorizes information about Internet 14 paths that an entity, such as a host, might have or want to have. 15 This information is expressed as properties of paths between two 16 hosts. 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 January 9, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 63 1. Introduction 65 Because the current Internet provides an IP-based best-effort bit 66 pipe, hosts have little information about paths to other hosts. A 67 Path Aware Network exposes information about one or multiple paths 68 through the network to hosts or the network infrastructure. 70 It is impossible to provide an exhaustive list of path properties, as 71 with every new technology and protocol, novel properties might become 72 relevant. In this document, we specify a set of path properties 73 which might be useful in the following use cases: Traffic policies, 74 network monitoring, and path selection. 76 o Traffic policies: Entities such as network operators or end users 77 may want to define traffic policies leveraging path awareness. 78 Such policies can allow or disallow sending traffic over specific 79 networks or nodes, select an appropriate protocol depending on the 80 capabilities of the on-path devices, or adjust protocol parameters 81 to an existing path. An example of a traffic policy is a video 82 streaming application choosing an (initial) video quality based on 83 the achievable data rate, or the monetary cost of the link using a 84 volume-based or flat-rate cost model. Another example is an 85 enterprise network where all traffic has to go through a firewall, 86 in which case the host needs to be aware of on-path firewalls. 88 o Network monitoring: Network operators can use path properties 89 (e.g., measured by on-path devices), to observe Quality of Service 90 (QoS) characteristics of recent end-user traffic, and identify 91 potential problems with their network early on, before the end- 92 user complains. 94 o Path selection: In some cases, entities can choose to use a 95 certain path (or subset of paths) from a set of paths to achieve a 96 specific goal. As the possible benefits of a well chosen path 97 varies based on the goal, as a baseline, a path selection 98 algorithm should aim to not perform worse than the default case 99 most of the time. Depending on the goal, an entity may prefer 100 paths with different properties, e.g., retrieving a small webpage 101 as quickly as possible requires low latency paths, or retrieving a 102 large file in a peer-to-peer network requires paths with high 103 achievable data rate. Additionally, there may be trade-offs 104 between path properties (e.g., latency and data rate), and 105 entities may influence these trade-offs with their choices. A 106 network (e.g., an AS) can adjust its path selection for internal 107 or external routing based on the path properties. In BGP, the 108 Multi Exit Discriminator (MED) attribute decides which path to 109 choose if other attributes are equal; in a path aware network, 110 instead of using this single MED value, other properties such as 111 maximum or available/expected data rate could additionally be used 112 to improve load balancing. A host might be able to select between 113 a set of paths, either if there are several paths to the same 114 destination (e.g., if the host is a mobile device with two 115 wireless interfaces, both providing a path), or if there are 116 several destinations, and thus several paths, providing the same 117 service (e.g., Application-Layer Traffic Optimization (ALTO) 118 [RFC5693], an application layer peer-to-peer protocol allowing 119 hosts a better-than-random peer selection). Care needs to be 120 taken when selecting paths based on path properties, as path 121 properties that were previously measured may have become outdated 122 and, thus, useless to predict the path properties of packets sent 123 now. 125 Such path properties may be relatively dynamic, e.g. current Round 126 Trip Time, close to the origin, e.g. nature of the access technology 127 on the first hop, or far from the origin, e.g. list of ASes 128 traversed. 130 Usefulness over time is fundamentally different for dynamic and non- 131 dynamic properties. The merit of a momentary measurement of a 132 dynamic path property diminishes greatly as time goes on, e.g. the 133 merit of an RTT measurement from a few seconds ago is quite small, 134 while a non-dynamic path property might stay relevant, e.g. a NAT can 135 be assumed to stay on a path during the lifetime of a connection, as 136 the removal of the NAT would break the connection. 138 Non-dynamic properties are further separated into (local) domain 139 properties related to the first few hops of the connection, and 140 backbone properties related to the remaining hops. Domain properties 141 expose a high amount of information to hosts and strongly influence 142 the connection behavior while there is little influence and 143 information about backbone properties. 145 Dynamic properties are not separated into domain and backbone 146 properties, since most of these properties are defined for a complete 147 path and it is difficult and seldom useful to define them on part of 148 the path. There are exceptions such as dynamic wireless access 149 properties, but these do not justify separation into different 150 categories. 152 This document addresses the first of the questions in Path-Aware 153 Networking [I-D.irtf-panrg-questions], which is a product of the 154 PANRG in the IRTF. 156 2. Terminology 158 Node: An entity which processes packets, e.g., sends, receives, 159 forwards, or modifies them. 161 Host: A node that processes packets that are explicitly addressed to 162 itself. 164 Router: A node that processes packets that are not explicitly 165 addressed to itself. 167 Link: A medium or communication facility that connects two or more 168 nodes with each other and enables them to exchange packets. A 169 link can be physical, e.g., a WiFi network which connects an 170 Access Point to stations, or virtual, e.g., a virtual switch which 171 connects two virtual machines hosted on the same physical machine. 173 Path element: Either a node or a link. 175 Path: A sequence of adjacent path elements, alternating between 176 nodes and links, starting and ending with a host. A path can be 177 viewed as an abstraction on a specific layer, omitting lower layer 178 path elements. For example, a router implementing IPv6 may be a 179 path element on a path when considering the network layer. If 180 this router does not implement transport layer functionality, it 181 is hidden when a higher layer, such as the transport or 182 application layer, is considered. In the case of multicast or 183 broadcast, a single packet may be sent over multiple paths at once 184 - one path for each combination of sending and receiving host. 186 Subpath: Given a path, a subpath is a sequence of adjacent path 187 elements of this path, starting and ending with a node. 189 Flow: One or multiple packets which are traversing the same subpath 190 or path. For example, a flow can consist of all packets sent 191 within a TCP session with the same five-tuple between two hosts, 192 or it can consist of all packets sent on the same physical link. 194 Property: A trait of one or a sequence of path elements, or a trait 195 of a flow with respect to one or a sequence of path elements. An 196 example of a link property is the maximum data rate that can be 197 sent over the link. An example of a node property is the 198 administrative domain that the node belongs to. An example of a 199 property of a flow with respect to a subpath is the aggregated 200 one-way delay of the flow being sent from one node to another node 201 over a subpath. A property is thus described by a tuple 202 containing the sequence of path elements, the flow or an empty set 203 if no packets are relevant for the property, the name of the 204 property (e.g., maximum data rate), and the value of the property 205 (e.g., 1Gbps). 207 Aggregated property: A collection of multiple values of a property 208 into a single value, according to a function. A property can be 209 aggregated over multiple path elements (i.e., a path), e.g., the 210 MTU of a path as the minimum MTU of all links on the path, over 211 multiple packets (i.e., a flow), e.g., the median one-way latency 212 of all packets between two nodes, or over both, e.g., the mean of 213 the queueing delays of a flow on all nodes along a path. The 214 aggregation function can be numerical, e.g., median, sum, minimum, 215 it can be logical, e.g., "true if all are true", "true if at least 216 50\% of values are true", or an arbitrary function which maps 217 multiple input values to an output value. 219 Measured property: A property that is observed for a specific path 220 element or path, e.g., using measurements. For example, the one- 221 way delay of a specific packet can be measured. 223 Estimated property: An approximate calculation or judgment of the 224 value of a property. For example, an estimated property may 225 describe the expected median one-way latency of packets sent on a 226 path within the next second. An estimated property includes the 227 reliability of the estimate. The notion of reliability depends on 228 the property. For example, it may be the confidence level and 229 interval for numerical properties or the likelihood that a 230 property holds for non-numerical properties. 232 3. Domain Properties 234 Domain path properties relate to path elements within the first hop 235 or the first few hops, which are usually in the same administrative 236 domain as a host considering them. 238 Due to the potential physical proximity and pre-existing trust or 239 contractual relationships between hosts and path elements within the 240 same domain, domain properties may be more accessible to the host 241 than other properties. 243 Furthermore, hosts may be able to influence both which domain they 244 are in and which path elements in this domain to connect to, and they 245 may be able to influence the properties of path elements within this 246 domain. For example, a user might select between multiple potential 247 adjacent links by selecting between multiple available WiFi Access 248 Points. Or when connected to an Access Point, the user may move 249 closer to enable their device to use a different access technology, 250 potentially increasing the data rate available to the device. 251 Another example is a user changing their data plan to reduce the 252 Monetary Cost to transmit a given amount of data across a network. 254 Access Technology: The physical or link layer technology used for 255 transmitting or receiving a flow on one or multiple path elements 256 in the same domain. The Access Technology may be given in an 257 abstract way, e.g., as a WiFi, Wired Ethernet, or Cellular link. 258 It may also be given as a specific technology, e.g., as a 2G, 3G, 259 4G, or 5G cellular link, or an 802.11a, b, g, n, or ac WiFi link. 260 Other path elements relevant to the access technology may include 261 on-path devices, such as elements of a cellular backbone network. 262 Note that there is no common registry of possible values for this 263 property. 265 Monetary Cost: The price to be paid to transmit a specific flow 266 across a subpath. 268 4. Backbone Properties 270 Backbone path properties relate to path elements not within the same 271 domain as a host considering them, thus, in the backbone from the 272 host's point of view. 274 Typically, backbone properties are less accessible to a host than 275 domain properties, due to the potential increased distance and the 276 lack of pre-existing trust or contractual relationship. 278 Additionally, hosts are less likely to be able to influence which 279 path elements form their path in the backbone, as well as their 280 properties. 282 Some path properties relate to the entire path or to subpaths, part 283 of which often lies outside of a host's domain. Thus, such 284 properties are listed as Backbone Properties. 286 Presence of a certain network function on the path: Indicates that a 287 node performs a certain network function on a flow, e.g., whether 288 the node acts as a proxy, as a firewall, or performs Network 289 Address Translation (NAT). This node may be either in the same 290 domain as the host or in a different domain, i.e., the backbone. 292 Administrative Entity: The administrative entity, e.g., the AS, to 293 which a path element or subpath belongs. 295 Disjointness: For a set of two paths, the number of shared path 296 elements can be a measure of intersection (e.g., Jaccard 297 coefficient, which is the number of shared elements divided by the 298 total number of elements). Conversely, the number of non-shared 299 path elements can be a measure of disjointness (e.g., 1 - Jaccard 300 coefficient). A multipath protocol might use disjointness of 301 paths as a metric to reduce the number of single points of 302 failure. 304 Path MTU: The maximum size, in octets, of an IP packet that can be 305 transmitted without fragmentation on a subpath. 307 Transport Protocols available: Whether a specific transport protocol 308 can be used to establish a connection over a path or subpath. A 309 host may cache its knowledge about recent successfully established 310 connections using specific protocols, e.g., a QUIC connection, or 311 an MPTCP subflow. 313 Protocol Features available: Whether a specific protocol feature is 314 available over a path or subpath, e.g., Explicit Congestion 315 Notification (ECN), or TCP Fast Open. 317 5. Dynamic Properties 319 Dynamic path properties relate to the transmission of an individual 320 packet or of a flow over a subpath. Properties related to a path 321 element which constitutes a single layer 2 domain are abstracted from 322 the used physical and link layer technology, similar to [RFC8175]. 324 Typically, Dynamic Properties can be measured or approximated, and 325 might be made available in an aggregated form, such as averages or 326 minimums. Dynamic Path Properties can be measured by the host itself 327 or by a different entity. See [ANRW18-Metrics] for a discussion of 328 how to measure some dynamic path properties at the host. 330 Some dynamic properties are defined in different directions for the 331 same path element, e.g., for transmitting and receiving packets. 333 Maximum Data Rate (Transmit/Receive): The theoretical maximum data 334 rate, in bits per second, that can be achieved on a link, subpath, 335 or path, for receiving or transmitting traffic. 337 Current Data Rate (Transmit/Receive): The data rate, in bits per 338 second, at which a link is currently receiving or transmitting 339 traffic. 341 Latency: The time delay between a node sending a packet and a 342 different node on the same path receiving the same packet. 344 Latency variation: The variation of the latency within a flow. 346 Packet Loss: The percentage of packets within a flow which are sent 347 by one node, but not received by a different node. 349 Congestion: Whether a protocol feature such as ECN has provided 350 information that there currently is congestion on a path. 352 6. Security Considerations 354 If nodes are basing policy or path selection decisions on path 355 properties, they need to rely on the accuracy of path properties that 356 other devices communicate to them. In order to be able to trust such 357 path properties, nodes may need to establish a trust relationship or 358 be able to verify the authenticity, integrity, and correctness of 359 path properties received from another node. 361 7. IANA Considerations 363 This document has no IANA actions. 365 8. Informative References 367 [ANRW18-Metrics] 368 Enghardt, T., Tiesel, P., and A. Feldmann, "Metrics for 369 access network selection", Proceedings of the Applied 370 Networking Research Workshop on - ANRW '18, 371 DOI 10.1145/3232755.3232764, 2018. 373 [I-D.irtf-panrg-questions] 374 Trammell, B., "Open Questions in Path Aware Networking", 375 draft-irtf-panrg-questions-02 (work in progress), May 376 2019. 378 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 379 Optimization (ALTO) Problem Statement", RFC 5693, 380 DOI 10.17487/RFC5693, October 2009, 381 . 383 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 384 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 385 DOI 10.17487/RFC8175, June 2017, 386 . 388 Acknowledgments 390 Thanks to the Path-Aware Networking Research Group for the discussion 391 and feedback. Thanks to Adrian Perrig and Matthias Rost for the 392 feedback. Thanks to Paul Hoffman for the editorial changes. 394 Authors' Addresses 396 Theresa Enghardt 397 TU Berlin 399 Email: theresa@inet.tu-berlin.de 401 Cyrill Kraehenbuehl 402 ETH Zuerich 404 Email: cyrill.kraehenbuehl@inf.ethz.ch