idnits 2.17.1 draft-irtf-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 (March 07, 2020) is 1511 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-ietf-idr-performance-routing-02 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 == Outdated reference: A later version (-19) exists of draft-ietf-tcpm-converters-18 == Outdated reference: A later version (-12) exists of draft-irtf-panrg-questions-04 Summary: 0 errors (**), 0 flaws (~~), 5 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 8, 2020 ETH Zuerich 6 March 07, 2020 8 A Vocabulary of Path Properties 9 draft-irtf-panrg-path-properties-00 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, e.g., for selecting 19 between paths or for invoking some of the provided services. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 8, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Use Cases for Path Properties . . . . . . . . . . . . . . . . 5 58 3.1. Path Selection . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Protocol Selection . . . . . . . . . . . . . . . . . . . 6 60 3.3. Service Invocation . . . . . . . . . . . . . . . . . . . 6 61 4. Examples of Path Properties . . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 7. Informative References . . . . . . . . . . . . . . . . . . . 10 65 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 In the current Internet architecture, hosts generally do not have 71 information about forwarding paths through the network and about 72 services associated with these paths. A path-aware network, as 73 introduced in [I-D.irtf-panrg-questions], exposes information about 74 paths to hosts or to other entities. This document defines such 75 information as path properties, addressing the first of the questions 76 in path-aware networking [I-D.irtf-panrg-questions]. 78 As terms related to paths have different meanings in different areas 79 of networking, first, this document provides a common terminology to 80 define paths, path elements, and path properties. Then, this 81 document provides some examples for use cases for path properties. 82 Finally, the document lists several path properties that may be 83 useful for the mentioned use cases. 85 Note that this document does not assume that any of the listed path 86 properties are actually available to any entity. The question of how 87 entities can discover and distribute path properties in a trustworthy 88 way is out of scope for this document. 90 2. Terminology 92 Node: An entity which processes packets, e.g., sends, receives, 93 forwards, or modifies them. A node may be physical or virtual, 94 e.g., a physical device or a service function provided as a 95 virtual element. A node may also be the collection of multiple 96 entities which, as a collection, processes packets, e.g., an 97 entire Autonomous System (AS). 99 Host: A node that generally executes application programs on behalf 100 of user(s), employing network and/or Internet communication 101 services in support of this function, as defined in [RFC1122]. 103 Link: A medium or communication facility that connects two or more 104 nodes with each other. A link enables a node to send packets to 105 other nodes. Links can be physical, e.g., a Wi-Fi network which 106 connects an Access Point to stations, or virtual, e.g., a virtual 107 switch which connects two virtual machines hosted on the same 108 physical machine. A link is unidirectional. As such, 109 bidirectional communication can be modeled as two links between 110 the same nodes in opposite directions. 112 Path element: Either a node or a link. 114 Path: A sequence of adjacent path elements over which a packet can 115 be transmitted, starting and ending with a node. A path is 116 unidirectional. Paths are time-dependent, i.e., the sequence of 117 path elements over which packets are sent from one node to another 118 may change. A path is defined between two nodes. For multicast 119 or broadcast, a packet may be sent by one node and received by 120 multiple nodes. In this case, the packet is sent over multiple 121 paths at once, one path for each combination of sending and 122 receiving node; these paths do not have to be disjoint. Note that 123 an entity may have only partial visibility of the path elements 124 that comprise a path and visibility may change over time. 125 Different entities may have different visibility of a path and/or 126 treat path elements at different levels of abstraction. For 127 example, a path may be given as a sequence of physical nodes and 128 the links connecting these nodes, or it may be given as a sequence 129 of logical nodes such as a sequence of ASes or an Explicit Route 130 Object (ERO). Similarly, the representation of a path and its 131 properties, as it is known to a specific entity, may be more 132 complex and include details about the physical layer technology, 133 or it may be more abstract and only consist of a specific source 134 and destination which is known to be reachable from that source. 136 Reverse Path: The path that is used by a remote node in the context 137 of bidirectional communication. 139 Subpath: Given a path, a subpath is a sequence of adjacent path 140 elements of this path. 142 Flow: An entity made of packets to which the traits of a path or set 143 of subpaths may be applied in a functional sense. For example, a 144 flow can consist of all packets sent within a TCP session with the 145 same five-tuple between two hosts, or it can consist of all 146 packets sent on the same physical link. 148 Property: A trait of one or a sequence of path elements, or a trait 149 of a flow with respect to one or a sequence of path elements. An 150 example of a link property is the maximum data rate that can be 151 sent over the link. An example of a node property is the 152 administrative domain that the node belongs to. An example of a 153 property of a flow with respect to a subpath is the aggregated 154 one-way delay of the flow being sent from one node to another node 155 over this subpath. A property is thus described by a tuple 156 containing the path element(s), the flow or an empty set if no 157 packets are relevant for the property, the name of the property 158 (e.g., maximum data rate), and the value of the property (e.g., 159 1Gbps). 161 Aggregated property: A collection of multiple values of a property 162 into a single value, according to a function. A property can be 163 aggregated over multiple path elements (i.e., a subpath), e.g., 164 the MTU of a path as the minimum MTU of all links on the path, 165 over multiple packets (i.e., a flow), e.g., the median one-way 166 latency of all packets between two nodes, or over both, e.g., the 167 mean of the queueing delays of a flow on all nodes along a path. 168 The aggregation function can be numerical, e.g., median, sum, 169 minimum, it can be logical, e.g., "true if all are true", "true if 170 at least 50\% of values are true", or an arbitrary function which 171 maps multiple input values to an output value. 173 Observed property: A property that is observed for a specific path 174 element, subpath, or path, e.g., using measurements. For example, 175 the one-way delay of a specific packet transmitted from one node 176 to another node can be measured. 178 Assessed property: An approximate calculation or assessment of the 179 value of a property. An assessed property includes the 180 reliability of the calculation or assessment. The notion of 181 reliability depends on the property. For example, a path property 182 based on an approximate calculation may describe the expected 183 median one-way latency of packets sent on a path within the next 184 second, including the confidence level and interval. A non- 185 numerical assessment may instead include the likelihood that the 186 property holds. 188 3. Use Cases for Path Properties 190 When a path-aware network exposes path properties to hosts or other 191 entities, these entities may use this information to achieve 192 different goals. This section lists several use cases for path 193 properties. Note that this is not an exhaustive list, as with every 194 new technology and protocol, novel use cases may emerge, and new path 195 properties may become relevant. 197 3.1. Path Selection 199 Entities can choose what traffic to send over which path or subset of 200 paths. A node might be able to select between a set of paths, either 201 if there are several paths to the same destination (e.g., in case of 202 a mobile device with two wireless interfaces, both providing a path), 203 or if there are several destinations, and thus several paths, 204 providing the same service (e.g., Application-Layer Traffic 205 Optimization (ALTO) [RFC5693], an application layer peer-to-peer 206 protocol allowing hosts a better-than-random peer selection). Care 207 needs to be taken when selecting paths based on path properties, as 208 path properties that were previously measured may not be helpful in 209 predicting current or future path properties and such path selection 210 may lead to unintended feedback loops. 212 Entities may select their paths to fulfill a specific goal, e.g., 213 related to security or performance. As an example of security- 214 related path selection, an entity may allow or disallow sending 215 traffic over paths involving specific networks or nodes to enforce 216 traffic policies. In an enterprise network where all traffic has to 217 go through a specific firewall, a path-aware host can implement this 218 policy using path selection, in which case the host needs to be aware 219 of paths involving that firewall. As an example of performance- 220 related path selection, an entity may prefer paths with performance 221 properties that best match its traffic requirements. For example, 222 for sending a small delay sensitive query, a host may select a path 223 with a short One-Way Delay, while for retrieving a large file, it may 224 select a path with high Link Capacities on all links. Note, there 225 may be trade-offs between path properties (e.g., One-Way Delay and 226 Link Capacity), and entities may influence these trade-offs with 227 their choices. As a baseline, a path selection algorithm should aim 228 to not perform worse than the default case most of the time. 230 Path selection can be done both by hosts and by entities within the 231 network: A network (e.g., an AS) can adjust its path selection for 232 internal or external routing based on path properties. In BGP, the 233 Multi Exit Discriminator (MED) attribute is used in the decision- 234 making process to select which path to choose among those having the 235 same AS PATH length and origin [RFC4271]; in a path aware network, 236 instead of using this single MED value, other properties such as Link 237 Capacity or Link Usage could additionally be used to improve load 238 balancing or performance [I-D.ietf-idr-performance-routing]. 240 3.2. Protocol Selection 242 When sending traffic over a specific path, an entity may select an 243 appropriate protocol or configure protocol parameters depending on 244 path properties. A host may cache state on whether a path allows the 245 use of QUIC [I-D.ietf-quic-transport] and if so, first attempt to 246 connect using QUIC before falling back to another protocol when 247 connecting over this path again. A video streaming application may 248 choose an (initial) video quality based on the achievable data rate 249 or the monetary cost of sending data (e.g., volume-base or flat-rate 250 cost model). 252 3.3. Service Invocation 254 Conversely to path or protocol selection, in addition to selecting a 255 protocol to use over a specific adjacent path element, an entity may 256 choose to invoke additional functions influencing the nodes to be 257 involved in the path. For example, a 0-RTT Transport Converter 258 [I-D.ietf-tcpm-converters] will be involved in a path only when 259 invoked by a host; such invocation will lead to the use of MPTCP or 260 TCPinc capabilities while such use is not supported via the default 261 forwarding path. Another example is a connection which is composed 262 of multiple streams where each stream has specific service 263 requirements. A host may decide to invoke a given service function 264 (e.g., transcoding) only for some streams while others are not 265 processed by that service function. 267 4. Examples of Path Properties 269 This Section gives some examples of path properties which may be 270 useful, e.g., for the use cases described in Section 3. 272 Path properties may be relatively dynamic, e.g., the one-way delay of 273 a packet sent over a specific path, or non-dynamic, e.g., the MTU of 274 an Ethernet link which only changes infrequently. Usefulness over 275 time differs depending on how dynamic a property is: The merit of a 276 momentary measurement of a dynamic path property diminishes greatly 277 as time goes on, e.g. the merit of an RTT measurement from a few 278 seconds ago is quite small, while a non-dynamic path property might 279 stay relevant for a longer period of time, e.g. a NAT typically stays 280 on a specific path during the lifetime of a connection involving 281 packets sent over this path. 283 From the point of view of a host, path properties may relate to path 284 elements close to the host, i.e., within the first few hops, or they 285 may include path elements far from the host, e.g., list of ASes 286 traversed. The visibility of path properties to a specific entity 287 may depend on factors such as the physical or network distance or the 288 existence of trust or contractual relationships between the entity 289 and the path element(s). 291 Furthermore, entities may or may not be able to influence the path 292 elements on their path and their path properties. For example, a 293 user might select between multiple potential adjacent links by 294 selecting between multiple available Wi-Fi Access Points. Or when 295 connected to an Access Point, the user may move closer to enable 296 their device to use a different access technology, potentially 297 increasing the data rate available to the device. Another example is 298 a user changing their data plan to reduce the Monetary Cost to 299 transmit or receive a given amount of data across a network. 301 Access Technology: The physical or link layer technology used for 302 transmitting or receiving a flow on one or multiple path elements. 303 If known, the Access Technology may be given as an abstract link 304 type, e.g., as Wi-Fi, Wired Ethernet, or Cellular. It may also be 305 given as a specific technology used on a link, e.g., 2G, 3G, 4G, 306 or 5G cellular, or 802.11a, b, g, n, or ac Wi-Fi. Other path 307 elements relevant to the access technology may include nodes 308 related to processing packets on the physical or link layer, such 309 as elements of a cellular backbone network. Note that there is no 310 common registry of possible values for this property. 312 Monetary Cost: The price to be paid to transmit or receive a 313 specific flow across a network to which one or multiple path 314 elements belong. 316 Service function: A service function that a path element applies to 317 a flow, see [RFC7665]. Examples of abstract service functions 318 include firewalls, Network Address Translation (NAT), and TCP 319 optimizers. Some stateful service functions, such as NAT, require 320 the same instance to be involved in both directions, i.e., on the 321 path and the reverse path. 323 Transparency: A node is transparent with respect to a protocol if it 324 does not modify headers of this protocol and it processes packets 325 independently of protocol-specific meta-information. An IP router 326 could be transparent for transport protocols such as TCP and UDP, 327 in contrast to a NAT that actively modifies TCP and UDP header 328 information. 330 Administrative Domain: The administrative domain, e.g., the IGP 331 area, AS, or Service provider network to which a path element 332 belongs. 334 Disjointness: For a set of two paths or subpaths, the number of 335 shared path elements can be a measure of intersection (e.g., 336 Jaccard coefficient, which is the number of shared elements 337 divided by the total number of elements). Conversely, the number 338 of non-shared path elements can be a measure of disjointness 339 (e.g., 1 - Jaccard coefficient). A multipath protocol might use 340 disjointness as a metric to reduce the number of single points of 341 failure. 343 Symmetric Path: Two paths are symmetric if a path and its reverse 344 path consist of the same path elements, but in reverse order, 345 i.e., the paths have a Jaccard coefficient of one. 347 Path MTU: The maximum size, in octets, of an IP packet that can be 348 transmitted without fragmentation. 350 Transport Protocols available: Whether a specific transport protocol 351 can be used to establish a connection over a path or subpath, 352 e.g., whether the path is QUIC-capable or MPTCP-capable, based on 353 cached knowledge. 355 Protocol Features available: Whether a specific protocol feature is 356 available over a path or subpath, e.g., Explicit Congestion 357 Notification (ECN), or TCP Fast Open. 359 Some path properties express the performance of the transmission of a 360 packet or flow over a link or subpath. Such transmission performance 361 properties can be measured or approximated, e.g., by hosts or by path 362 elements on the path. They might be made available in an aggregated 363 form, such as averages or minimums. See [ANRW18-Metrics] for a 364 discussion of how to measure some transmission performance properties 365 at the host. Properties related to a path element which constitutes 366 a single layer 2 domain are abstracted from the used physical and 367 link layer technology, similar to [RFC8175]. 369 Link Capacity: The link capacity is the maximum data rate at which 370 data that was sent over a link can correctly be received at the 371 node adjacent to the link. This property is analogous to the link 372 capacity defined in [RFC5136] but not restricted to IP-layer 373 traffic. 375 Link Usage: The link usage is the actual data rate at which data 376 that was sent over a link is correctly received at the node 377 adjacent to the link. This property is analogous to the link 378 usage defined in [RFC5136] but not restricted to IP-layer traffic. 380 One-Way Delay: The one-way delay is the delay between a node sending 381 a packet and another node on the same path receiving the packet. 382 This property is analogous to the one-way delay defined in 383 [RFC7679] but not restricted to IP-layer traffic. 385 One-Way Delay Variation: The variation of the one-way delays within 386 a flow. This property is similar to the one-way delay variation 387 defined in [RFC3393] but not restricted to IP-layer traffic and 388 defined for packets on the same flow instead of packets sent 389 between a source and destination IP address. 391 One-Way Packet Loss: Packets sent by a node but not received by 392 another node on the same path after a certain time interval are 393 considered lost. This property is analogous to the one-way loss 394 defined in [RFC7680] but not restricted to IP-layer traffic. 395 Metrics such as loss patterns [RFC3357] and loss episodes 396 [RFC6534] can be expressed as aggregated properties. 398 5. Security Considerations 400 If nodes are basing policy or path selection decisions on path 401 properties, they need to rely on the accuracy of path properties that 402 other devices communicate to them. In order to be able to trust such 403 path properties, nodes may need to establish a trust relationship or 404 be able to verify the authenticity, integrity, and correctness of 405 path properties received from another node. 407 Security related properties such as confidentiality and integrity 408 protection of payloads are difficult to characterize since they are 409 only meaningful with respect to a threat model which depends on the 410 use case, application, environment, and other factors. Such 411 properties are orthogonal to the path terminology and path properties 412 defined in this document, as they are tied to the communicating 413 entities and protocols used (e.g., client and server using HTTPS, or 414 client and remote network node using VPN) and the path is typically 415 oblivious to these properties. Intuitively, the path describes what 416 function the network applies to packets, while confidentiality and 417 integrity describe what function the communicating parties apply to 418 packets. 420 6. IANA Considerations 422 This document has no IANA actions. 424 7. Informative References 426 [ANRW18-Metrics] 427 Enghardt, T., Tiesel, P., and A. Feldmann, "Metrics for 428 access network selection", Proceedings of the Applied 429 Networking Research Workshop on - ANRW '18, 430 DOI 10.1145/3232755.3232764, 2018. 432 [I-D.ietf-idr-performance-routing] 433 Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C. 434 Jacquenet, "Performance-based BGP Routing Mechanism", 435 draft-ietf-idr-performance-routing-02 (work in progress), 436 October 2019. 438 [I-D.ietf-quic-transport] 439 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 440 and Secure Transport", draft-ietf-quic-transport-27 (work 441 in progress), February 2020. 443 [I-D.ietf-tcpm-converters] 444 Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., 445 and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- 446 tcpm-converters-18 (work in progress), March 2020. 448 [I-D.irtf-panrg-questions] 449 Trammell, B., "Current Open Questions in Path Aware 450 Networking", draft-irtf-panrg-questions-04 (work in 451 progress), December 2019. 453 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 454 Communication Layers", STD 3, RFC 1122, 455 DOI 10.17487/RFC1122, October 1989, 456 . 458 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 459 Metrics", RFC 3357, DOI 10.17487/RFC3357, August 2002, 460 . 462 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 463 Metric for IP Performance Metrics (IPPM)", RFC 3393, 464 DOI 10.17487/RFC3393, November 2002, 465 . 467 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 468 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 469 DOI 10.17487/RFC4271, January 2006, 470 . 472 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 473 RFC 5136, DOI 10.17487/RFC5136, February 2008, 474 . 476 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 477 Optimization (ALTO) Problem Statement", RFC 5693, 478 DOI 10.17487/RFC5693, October 2009, 479 . 481 [RFC6534] Duffield, N., Morton, A., and J. Sommers, "Loss Episode 482 Metrics for IP Performance Metrics (IPPM)", RFC 6534, 483 DOI 10.17487/RFC6534, May 2012, 484 . 486 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 487 Chaining (SFC) Architecture", RFC 7665, 488 DOI 10.17487/RFC7665, October 2015, 489 . 491 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 492 Ed., "A One-Way Delay Metric for IP Performance Metrics 493 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 494 2016, . 496 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 497 Ed., "A One-Way Loss Metric for IP Performance Metrics 498 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 499 2016, . 501 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 502 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 503 DOI 10.17487/RFC8175, June 2017, 504 . 506 Acknowledgments 508 Thanks to the Path-Aware Networking Research Group for the discussion 509 and feedback. Specifically, thanks to Mohamed Boudacair for the 510 detailed review and various text suggestions, thanks to Brian 511 Trammell for suggesting the flow definition, and thanks to Adrian 512 Perrig and Matthias Rost for the detailed feedback. Thanks to Paul 513 Hoffman for the editorial changes. 515 Authors' Addresses 516 Theresa Enghardt 517 TU Berlin 519 Email: ietf@tenghardt.net 521 Cyrill Kraehenbuehl 522 ETH Zuerich 524 Email: cyrill.kraehenbuehl@inf.ethz.ch