idnits 2.17.1 draft-enghardt-panrg-path-properties-03.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 (November 04, 2019) is 1636 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-tcpm-converters-13 == Outdated reference: A later version (-12) exists of draft-irtf-panrg-questions-03 Summary: 0 errors (**), 0 flaws (~~), 3 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: May 7, 2020 ETH Zuerich 6 November 04, 2019 8 A Vocabulary of Path Properties 9 draft-enghardt-panrg-path-properties-03 11 Abstract 13 Path properties express information about paths across a network and 14 the services provided via such paths. In a path-aware network, path 15 properties may be fully or partially available to entities such as 16 hosts. This document defines and categorizes path properties. 17 Furthermore, the document specifies several path properties which 18 might be useful to hosts or other entities. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 7, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Use Cases for Path Properties . . . . . . . . . . . . . . . . 4 57 3.1. Performance Monitoring and Enhancement . . . . . . . . . 4 58 3.2. Path Selection . . . . . . . . . . . . . . . . . . . . . 4 59 3.3. Traffic Configuration . . . . . . . . . . . . . . . . . . 5 60 4. Examples of Path Properties . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. Informative References . . . . . . . . . . . . . . . . . . . 8 64 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 In the current Internet architecture, hosts generally do not have 70 information about forwarding paths through the network and about 71 services associated with these paths. A path-aware network, as 72 introduced in [I-D.irtf-panrg-questions], exposes information about 73 paths to hosts or to other entities. This document defines such 74 information as path properties, addressing the first of the questions 75 in path-aware networking [I-D.irtf-panrg-questions]. 77 As terms related to paths have different meanings in different areas 78 of networking, first, this document provides a common terminology to 79 define paths, path elements, and path properties. Then, this 80 document provides some examples for use cases for path properties. 81 Finally, the document lists several path properties that may be 82 useful for the mentioned use cases. 84 2. Terminology 86 Node: An entity which processes packets, e.g., sends, receives, 87 forwards, or modifies them. A node may be physical or virtual, 88 e.g., a machine or a service function. A node may also be the 89 collection of multiple entities which, as a collection, processes 90 packets, e.g., an entire Autonomous System (AS). 92 Host: A node that generally executes application programs on behalf 93 of user(s), employing network and/or Internet communication 94 services in support of this function, as defined in [RFC1122]. 96 Link: A medium or communication facility that connects two or more 97 nodes with each other. A link enables a node to send packets to 98 other nodes. Links can be physical, e.g., a WiFi network which 99 connects an Access Point to stations, or virtual, e.g., a virtual 100 switch which connects two virtual machines hosted on the same 101 physical machine. A link is unidirectional and bidirectional 102 communication can be modeled as two links between the same nodes 103 in opposite directions. 105 Path element: Either a node or a link. 107 Path: A sequence of adjacent path elements over which a packet can 108 be transmitted, starting and ending with a node. Paths are time- 109 dependent, i.e., the sequence of path elements over which packets 110 are sent from one node to another may change frequently. A path 111 is defined between two nodes. For multicast or broadcast, a 112 packet may be sent by one node and received by multiple nodes. In 113 this case, the packet is sent over multiple paths at once, one 114 path for each combination of sending and receiving node. Note 115 that an entity may have only partial visibility of the path 116 elements that comprise a path, and entities may treat path 117 elements at different levels of abstraction. 119 Subpath: Given a path, a subpath is a sequence of adjacent path 120 elements of this path. 122 Flow: An entity made of packets to which the traits of a path or set 123 of subpaths may be applied in a functional sense. For example, a 124 flow can consist of all packets sent within a TCP session with the 125 same five-tuple between two hosts, or it can consist of all 126 packets sent on the same physical link. 128 Property: A trait of one or a sequence of path elements, or a trait 129 of a flow with respect to one or a sequence of path elements. An 130 example of a link property is the maximum data rate that can be 131 sent over the link. An example of a node property is the 132 administrative domain that the node belongs to. An example of a 133 property of a flow with respect to a subpath is the aggregated 134 one-way delay of the flow being sent from one node to another node 135 over this subpath. A property is thus described by a tuple 136 containing the path element(s), the flow or an empty set if no 137 packets are relevant for the property, the name of the property 138 (e.g., maximum data rate), and the value of the property (e.g., 139 1Gbps). 141 Aggregated property: A collection of multiple values of a property 142 into a single value, according to a function. A property can be 143 aggregated over multiple path elements (i.e., a path), e.g., the 144 MTU of a path as the minimum MTU of all links on the path, over 145 multiple packets (i.e., a flow), e.g., the median one-way latency 146 of all packets between two nodes, or over both, e.g., the mean of 147 the queueing delays of a flow on all nodes along a path. The 148 aggregation function can be numerical, e.g., median, sum, minimum, 149 it can be logical, e.g., "true if all are true", "true if at least 150 50\% of values are true", or an arbitrary function which maps 151 multiple input values to an output value. 153 Observed property: A property that is observed for a specific path 154 element or path, e.g., using measurements. For example, the one- 155 way delay of a specific packet transmitted from one node to 156 another node can be measured. 158 Assessed property: An approximate calculation or assessment of the 159 value of a property. An assessed property includes the 160 reliability of the calculation or assessment. The notion of 161 reliability depends on the property. For example, a path property 162 based on an approximate calculation may describe the expected 163 median one-way latency of packets sent on a path within the next 164 second, including the confidence level and interval. A non- 165 numerical assessment may instead include the likelihood that the 166 property holds. 168 3. Use Cases for Path Properties 170 When a path-aware network exposes path properties to hosts or other 171 entities, these entities may use this information to achieve 172 different goals. This section lists several use cases for path 173 properties. Note that this is not an exhaustive list, as with every 174 new technology and protocol, novel use cases may emerge, and new path 175 properties may become relevant. 177 3.1. Performance Monitoring and Enhancement 179 Network operators can observe path properties (e.g., measured by on- 180 path devices), to monitor Quality of Service (QoS) characteristics of 181 recent end-user traffic on a path or subpath through their network. 182 Such properties may help identify potential performance problems or 183 trigger countermeasures to enhance performance. 185 3.2. Path Selection 187 Entities can choose what traffic to send over which path or subset of 188 paths. Entities may select their paths to fulfill a specific goal, 189 e.g., related to security or performance. As an example of security- 190 related path selection, an entity may allow or disallow sending 191 traffic over paths involving specific networks or nodes to enforce 192 traffic policies. In an enterprise network where all traffic has to 193 go through a specific firewall, a path-aware host can implement this 194 policy using path selection, in which case the host needs to be aware 195 of paths involving that firewall. As an example of performance- 196 related path selection, an entity may prefer paths with performance 197 properties that best match its traffic, e.g., retrieving a small 198 webpage as quickly as possible over a path with short One-Way Delays 199 in both directions, or retrieving a large file over a path with high 200 Link Capacities on all links. Note, there may be trade-offs between 201 path properties (e.g., One-Way Delay and Link Capacity), and entities 202 may influence these trade-offs with their choices. As a baseline, a 203 path selection algorithm should aim to not perform worse than the 204 default case most of the time. 206 Path selection can be done both by hosts and by entities within the 207 network: A network (e.g., an AS) can adjust its path selection for 208 internal or external routing based on the path properties. In BGP, 209 the Multi Exit Discriminator (MED) attribute decides which path to 210 choose if other attributes are equal; in a path aware network, 211 instead of using this single MED value, other properties such as 212 maximum or available/expected data rate could additionally be used to 213 improve load balancing. A host might be able to select between a set 214 of paths, either if there are several paths to the same destination 215 (e.g., if the host is a mobile device with two wireless interfaces, 216 both providing a path), or if there are several destinations, and 217 thus several paths, providing the same service (e.g., Application- 218 Layer Traffic Optimization (ALTO) [RFC5693], an application layer 219 peer-to-peer protocol allowing hosts a better-than-random peer 220 selection). Care needs to be taken when selecting paths based on 221 path properties, as path properties that were previously measured may 222 have become outdated and, thus, useless to predict the path 223 properties of packets sent now. 225 3.3. Traffic Configuration 227 When sending traffic over a specific path, entities can adjust this 228 traffic based on the properties of the path. For example, an entity 229 may select an appropriate protocol depending on the capabilities of 230 the on-path devices, or adjust protocol parameters to an existing 231 path. An example of traffic configuration is a video streaming 232 application choosing an (initial) video quality based on the 233 achievable data rate, or the monetary cost to send data across a 234 network, eventually on a given path, using a volume-based or flat- 235 rate cost model. 237 Conversely, the selection of a protocol may influence the devices 238 that will be involved in a path. For example, a 0-RTT Transport 239 Converter [I-D.ietf-tcpm-converters] will be involved in a path only 240 when invoked by a host; such invocation will lead to the use of MPTCP 241 or TCPinc capabilities while such use is not supported via the 242 default forwarding path. Another example of traffic policies is a 243 connection which may be composed of multiple streams; each stream 244 with specific service requirements. A host may decide to invoke a 245 given service function (e.g., transcoding) only for some streams 246 while others are not processed by that service function. 248 4. Examples of Path Properties 250 This Section gives some examples of Path Properties which may be 251 useful, e.g., for the use cases described in Section 3. 253 Path properties may be relatively dynamic, e.g., the one-way delay of 254 a packet sent over a specific path, or non-dynamic, e.g., the MTU of 255 an ethernet link which only changes infrequently. Usefulness over 256 time differs depending on how dynamic a property is: The merit of a 257 momentary measurement of a dynamic path property diminishes greatly 258 as time goes on, e.g. the merit of an RTT measurement from a few 259 seconds ago is quite small, while a non-dynamic path property might 260 stay relevant for a longer period of time, e.g. a NAT typically stays 261 on a specific path during the lifetime of a connection involving 262 packets sent over this path. 264 From the point of view of a host, path properties may relate to path 265 elements close to the host, i.e., within the first few hops, or they 266 may include path elements far from the host, e.g. list of ASes 267 traversed. The visibility of path properties to a specific entity 268 may depend on factors such as the physical or network distance or the 269 existence of trust or contractual relationships between the entity 270 and the path element(s). 272 Furthermore, entities may or may not be able to influence the path 273 elements on their path and their path properties. For example, a 274 user might select between multiple potential adjacent links by 275 selecting between multiple available WiFi Access Points. Or when 276 connected to an Access Point, the user may move closer to enable 277 their device to use a different access technology, potentially 278 increasing the data rate available to the device. Another example is 279 a user changing their data plan to reduce the Monetary Cost to 280 transmit a given amount of data across a network. 282 Access Technology: The physical or link layer technology used for 283 transmitting or receiving a flow on one or multiple path elements. 284 The Access Technology may be given in an abstract way, e.g., as a 285 WiFi, Wired Ethernet, or Cellular link. It may also be given as a 286 specific technology, e.g., as a 2G, 3G, 4G, or 5G cellular link, 287 or an 802.11a, b, g, n, or ac WiFi link. Other path elements 288 relevant to the access technology may include on-path devices, 289 such as elements of a cellular backbone network. Note that there 290 is no common registry of possible values for this property. 292 Monetary Cost: The price to be paid to transmit a specific flow 293 across a network to which one or multiple path elements belong. 295 Service function: A service function that a path element applies to 296 a flow, see [RFC7665]. Examples of abstract service functions 297 include firewalls, Network Address Translation (NAT), and TCP 298 optimizers. 300 Administrative Domain: The administrative domain, e.g., the ICP 301 area, AS, or Service provider network to which a path element or 302 subpath belongs. 304 Disjointness: For a set of two paths, the number of shared path 305 elements can be a measure of intersection (e.g., Jaccard 306 coefficient, which is the number of shared elements divided by the 307 total number of elements). Conversely, the number of non-shared 308 path elements can be a measure of disjointness (e.g., 1 - Jaccard 309 coefficient). A multipath protocol might use disjointness of 310 paths as a metric to reduce the number of single points of 311 failure. 313 Path MTU: The maximum size, in octets, of an IP packet that can be 314 transmitted without fragmentation on a subpath. 316 Transport Protocols available: Whether a specific transport protocol 317 can be used to establish a connection over a path or subpath. A 318 host may cache its knowledge about recent successfully established 319 connections using specific protocols, e.g., a QUIC connection, or 320 an MPTCP subflow. 322 Protocol Features available: Whether a specific protocol feature is 323 available over a path or subpath, e.g., Explicit Congestion 324 Notification (ECN), or TCP Fast Open. 326 Some path properties express the performance of the transmission of a 327 packet or flow over a link or subpath. Such transmission performance 328 properties can be measured or approximated, e.g., by hosts or by path 329 elements on the path. They might be made available in an aggregated 330 form, such as averages or minimums. See [ANRW18-Metrics] for a 331 discussion of how to measure some transmission performance properties 332 at the host. Properties related to a path element which constitutes 333 a single layer 2 domain are abstracted from the used physical and 334 link layer technology, similar to [RFC8175]. 336 Link Capacity: The link capacity is the maximum data rate at which 337 data that was sent over a link can correctly be received at the 338 node adjacent to the link. This property is analogous to the link 339 capacity defined in [RFC5136] but not restricted to IP-layer 340 traffic. 342 Link Usage: The link usage is the actual data rate at which data 343 that was sent over a link is correctly received at the node 344 adjacent to the link. This property is analogous to the link 345 usage defined in [RFC5136] but not restricted to IP-layer traffic. 347 One-Way Delay: The one-way delay is the delay between a node sending 348 a packet and another node on the same path receiving the packet. 349 This property is analogous to the one-way delay defined in 350 [RFC7679] but not restricted to IP-layer traffic. 352 One-Way Delay Variation: The variation of the one-way delays within 353 a flow. This property is similar to the one-way delay variation 354 defined in [RFC3393] but not restricted to IP-layer traffic and 355 defined for packets on the same flow instead of packets sent 356 between a source and destination IP address. 358 One-Way Packet Loss: Packets sent by a node but not received by 359 another node on the same path after a certain time interval are 360 considered lost. This property is analogous to the one-way loss 361 defined in [RFC7680] but not restricted to IP-layer traffic. 362 Metrics such as loss patterns [RFC3357] and loss episodes 363 [RFC6534] can be expressed as aggregated properties. 365 5. Security Considerations 367 If nodes are basing policy or path selection decisions on path 368 properties, they need to rely on the accuracy of path properties that 369 other devices communicate to them. In order to be able to trust such 370 path properties, nodes may need to establish a trust relationship or 371 be able to verify the authenticity, integrity, and correctness of 372 path properties received from another node. 374 6. IANA Considerations 376 This document has no IANA actions. 378 7. Informative References 380 [ANRW18-Metrics] 381 Enghardt, T., Tiesel, P., and A. Feldmann, "Metrics for 382 access network selection", Proceedings of the Applied 383 Networking Research Workshop on - ANRW '18, 384 DOI 10.1145/3232755.3232764, 2018. 386 [I-D.ietf-tcpm-converters] 387 Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., 388 and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- 389 tcpm-converters-13 (work in progress), October 2019. 391 [I-D.irtf-panrg-questions] 392 Trammell, B., "Current Open Questions in Path Aware 393 Networking", draft-irtf-panrg-questions-03 (work in 394 progress), October 2019. 396 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 397 Communication Layers", STD 3, RFC 1122, 398 DOI 10.17487/RFC1122, October 1989, 399 . 401 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 402 Metrics", RFC 3357, DOI 10.17487/RFC3357, August 2002, 403 . 405 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 406 Metric for IP Performance Metrics (IPPM)", RFC 3393, 407 DOI 10.17487/RFC3393, November 2002, 408 . 410 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 411 RFC 5136, DOI 10.17487/RFC5136, February 2008, 412 . 414 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 415 Optimization (ALTO) Problem Statement", RFC 5693, 416 DOI 10.17487/RFC5693, October 2009, 417 . 419 [RFC6534] Duffield, N., Morton, A., and J. Sommers, "Loss Episode 420 Metrics for IP Performance Metrics (IPPM)", RFC 6534, 421 DOI 10.17487/RFC6534, May 2012, 422 . 424 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 425 Chaining (SFC) Architecture", RFC 7665, 426 DOI 10.17487/RFC7665, October 2015, 427 . 429 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 430 Ed., "A One-Way Delay Metric for IP Performance Metrics 431 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 432 2016, . 434 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 435 Ed., "A One-Way Loss Metric for IP Performance Metrics 436 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 437 2016, . 439 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 440 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 441 DOI 10.17487/RFC8175, June 2017, 442 . 444 Acknowledgments 446 Thanks to the Path-Aware Networking Research Group for the discussion 447 and feedback. Specifically, thanks to Mohamed Boudacair for the 448 detailed review and various text suggestions, thanks to Brian 449 Trammell for suggesting the flow definition, and thanks to Adrian 450 Perrig and Matthias Rost for the detailed feedback. Thanks to Paul 451 Hoffman for the editorial changes. 453 Authors' Addresses 455 Theresa Enghardt 456 TU Berlin 458 Email: theresa@inet.tu-berlin.de 460 Cyrill Kraehenbuehl 461 ETH Zuerich 463 Email: cyrill.kraehenbuehl@inf.ethz.ch