idnits 2.17.1 draft-dawkins-quic-multipath-selection-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 (June 02, 2021) is 1052 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-bonaventure-iccrg-schedulers-01 == Outdated reference: A later version (-01) exists of draft-huitema-quic-mpath-option-00 == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-02 == Outdated reference: A later version (-04) exists of draft-liu-multipath-quic-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC Working Group S. Dawkins 3 Internet-Draft Tencent America LLC 4 Intended status: Informational June 02, 2021 5 Expires: December 4, 2021 7 Path Selection for Multiple Paths In QUIC 8 draft-dawkins-quic-multipath-selection-01 10 Abstract 12 In QUIC working group discussions about proposals to use multiple 13 paths, an obvious question came up - given multiple paths, how does 14 QUIC select paths to send packets over? 16 The answer to that question may inform decisions in the QUIC working 17 group about the scope of any multipath extensions considered for 18 experimentation and adoption. 20 This document is intended to summarize aspects of path selection from 21 those contributions and conversations. 23 It is recognized that path selection is not the only important open 24 question about QUIC Multipath, but other open questions are out of 25 scope for this document. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 4, 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Why We Should Look at Path Selection Strategies Now . . . 3 63 1.2. Notes for Readers . . . . . . . . . . . . . . . . . . . . 4 64 1.3. Minimal Terminology . . . . . . . . . . . . . . . . . . . 4 65 1.4. Contribution and Discussion Venues for this draft. . . . 5 66 2. Background for this document . . . . . . . . . . . . . . . . 5 67 3. Overview of Proposed Path Selection Strategies . . . . . . . 6 68 3.1. Active-Standby . . . . . . . . . . . . . . . . . . . . . 7 69 3.2. Latency Versus Bandwidth . . . . . . . . . . . . . . . . 7 70 3.3. Bandwidth Aggregation/Load Balancing . . . . . . . . . . 7 71 3.4. Minimum RTT Difference . . . . . . . . . . . . . . . . . 7 72 3.5. Round-Trip-Time Thresholds . . . . . . . . . . . . . . . 7 73 3.6. RTT Equivalence . . . . . . . . . . . . . . . . . . . . . 7 74 3.7. Priority-based . . . . . . . . . . . . . . . . . . . . . 7 75 3.8. Redundant . . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.9. Control Plane Versus Data Plane . . . . . . . . . . . . . 8 77 3.10. Combinations of Strategies . . . . . . . . . . . . . . . 8 78 4. Implications for QUIC Multipath . . . . . . . . . . . . . . . 8 79 4.1. Selecting a Single Path Among Multiple Validated Paths 80 ("Traffic Switching") . . . . . . . . . . . . . . . . . . 8 81 4.2. Selecting Multiple Active Paths ("Traffic Splitting") . . 9 82 4.3. Arbitrary Combinations . . . . . . . . . . . . . . . . . 9 83 5. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 87 9. Informative References . . . . . . . . . . . . . . . . . . . 10 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 In QUIC working group [QUIC-charter] discussions about proposals to 93 use multiple paths, an obvious question came up - given multiple 94 paths, how does QUIC select paths to send packets over? 95 The answer to that question may inform decisions in the QUIC working 96 group about the scope of any multipath extensions considered for 97 experimentation and adoption. 99 This document is intended to summarize aspects of path selection from 100 those contributions and conversations. 102 It is recognized that path selection is not the only important open 103 question about QUIC Multipath, but other open questions are out of 104 scope for this document. 106 1.1. Why We Should Look at Path Selection Strategies Now 108 One of the first questions that's come up in discussions about 109 multiple paths for QUIC has been about path selection. As soon as an 110 implementation has multiple paths available, it must decide how to 111 use these paths. The [RFC9000] answer, relying on connection 112 migration, is "if you have multiple paths available, you can validate 113 more than one connection at a time, but you only send on one 114 connection at a time, and you migrate to another connection when you 115 decide sending on the current connection is no longer appropriate. 116 How you decide to migrate to another connection is up to you". 118 That has been a fine answer for many of the implementers who have 119 worked on the first version of QUIC, and have deployed it in their 120 networks. For other implementers, targeting other use cases and 121 other networking environments, it may not be sufficient. 123 To take only one example, one of several presentations at 124 [QUIC-interim-20-10] described aspects of 3GPP Access Traffic 125 Steering, Switch and Splitting support (ATSSS), which contained four 126 "Steering Modes" as part of Rel-16 in 2019 [TS23501], each of which 127 corresponding roughly to a path selection strategy described in 128 Section 3 of this document. A study on "ATSSS Phase 2" [TR23700-93] 129 included four more Steering Modes for Rel-17, expected to be 130 finalized in mid-2021, and none of these eight (so far) Steering 131 Modes are based on QUIC - they are based on Multipath TCP ([RFC8684] 132 or simple IP packet forwarding. And if that were not enough, a 133 proposal for a study on "ATSSS Phase 3" [S2-2104599] was provided to 134 the SA2 145-e meeting in May 2021. Some of the ATSSS strategies rely 135 in 5G network internals and don't translate to the broader Internet, 136 but most do translate, and 3GPP participants certainly aren't the 137 only people thinking about path selection strategies. 139 Since the various proposals presented at [QUIC-interim-20-10] were 140 developed in isolation from each other, the path selection strategies 141 that they reflect may be similar between proposals, but not quite the 142 same, and none of the proposals presented had more than two 143 strategies in common with any other proposal. 145 Given the number of path selection strategies being considered, 146 implemented, and even deployed in any number of venues, and the 147 potential for combinatorial explosion as described in Section 3.10, 148 it seems that identifying common aspects of path selection 149 strategies, sooner rather than later, is important. 151 1.2. Notes for Readers 153 This document is an informational Internet-Draft, not adopted by any 154 IETF working group, and does not carry any special status within the 155 IETF. 157 Please note well that this document reflects the author's current 158 understanding of past working group discussions and proposals. 159 Contributions that add or improve considerations are welcomed, as 160 described in Section 1.4. 162 1.3. Minimal Terminology 164 In this document, "QUIC multipath" is only used as shorthand for 165 "QUIC using multiple paths". It does not refer to a specific 166 proposal. 168 In this document, "path selection strategy" means the policy that a 169 QUIC sender uses to guide its choice between multiple interfaces of a 170 QUIC connection for "the next packet". 172 This document adopts three terms, stolen from [TS23501], that seemed 173 helpful in previous discussions about multipath in the QUIC working 174 group. 176 o Traffic Steering - selecting an initial path (in [RFC9000], this 177 would be "validating a connection, and then using it". Although 178 an [RFC9000] client can validate multiple connections, the client 179 will only use one validated connection at a time. 181 o Traffic Switching - selecting a different validated path (in 182 [RFC9000], this is something like "migrating to a new validated 183 connection", although whether connection migration as defined in 184 [RFC9000]) would be sufficient is discussed in Section 4). 186 o Traffic Splitting - using multiple validated paths simultaneously 187 (this would almost certainly require an extension beyond 188 connection migration as defined in [RFC9000]). 190 "Traffic Steering" does not require any extension to [RFC9000], and 191 is not discussed further in this document. The focus will be on 192 "Traffic Switching" and "Traffic Splitting". 194 1.4. Contribution and Discussion Venues for this draft. 196 (Note to RFC Editor - if this document ever reaches you, please 197 remove this section) 199 This document is under development in the Github repository at 200 https://github.com/SpencerDawkins/quic-multipath-selection. 202 Readers are invited to open issues and send pull requests with 203 contributed text for this document, but since the document is 204 intended to guide discussion for the QUIC working group, substantial 205 discussion of this document should take place on the QUIC working 206 group mailing list (quic@ietf.org). Mailing list subscription and 207 archive details are at https://www.ietf.org/mailman/listinfo/quic. 209 2. Background for this document 211 A number of individual draft proposals for "QUIC over multiple paths" 212 have been submitted to the IETF QUIC and INTAREA working groups, 213 dating back as far as 2017. The author thinks that the complete list 214 is as follows (and reminders for proposals he missed are welcomed): 216 o [I-D.an-multipath-quic] 218 o [I-D.an-multipath-quic-application-policy] 220 o [I-D.an-multipath-quic-traffic-distribution] 222 o [I-D.chan-quic-owl] 224 o [I-D.deconinck-quic-multipath] 226 o [I-D.deconinck-quic-multipath], 228 o [I-D.huitema-quic-mpath-req] 230 o [I-D.huitema-quic-mpath-option]) 232 o [I-D.liu-multipath-quic] 234 o [I-D.piraux-intarea-quic-tunnel-session] 236 [I-D.bonaventure-iccrg-schedulers] has also been submitted to the 237 Internet Congestion Control Research Group [ICCRG-charter] in the 238 Internet Research Task Force. It contains specific proposals for 239 implementing some multipath schedulers, and includes some discussion 240 of path selection relevant to this document. 242 One point of confusion in QUIC working group discussions was that the 243 various proposals (also using Multipath TCP [RFC8684], so not all 244 proposals were QUIC-specific) discussed in working group meetings and 245 on the QUIC mailing list were from various proponents who weren't 246 solving the same problem. This meant that no two of the use cases 247 presented at the QUIC working group virtual interim on QUIC Multipath 248 [QUIC-interim-20-10] were relying on the same strategies. 250 It seemed useful to collect the path selection strategies described 251 in those proposals, to look for common elements, and to write them 252 down in one place, to allow more focused discussion. 253 [I-D.dawkins-quic-what-to-do-with-multipath] was intended to 254 summarize, at a high level, various proposals for the use of 255 multipath capabilities in QUIC, both inside the IETF and outside the 256 IETF, in order to identify elements that were common across 257 proposals. This draft tries to describe the impact of these various 258 strategies on potential QUIC Multipath extensions. 260 One element that is certainly worth considering is whether the path 261 selection strategies that have been proposed can be satisfied using a 262 small number of "building block" strategies. 264 3. Overview of Proposed Path Selection Strategies 266 The following strategies were discussed at [QUIC-interim-20-10], and 267 afterwards on the QUIC mailing list. These are summarized in this 268 section, are described in more detail in 269 [I-D.dawkins-quic-what-to-do-with-multipath], and are attributed to 270 various proposals in that document. 272 o Active-Standby - described in Section 3.1 274 o Latency Versus Bandwidth - described in Section 3.2 276 o Bandwidth Aggregation/Load Balancing - described in Section 3.3 278 o Minimum RTT Difference - described in Section 3.4 280 o Round-Trip-Time Thresholds - described in Section 3.5 282 o RTT Equivalence - described in Section 3.6 284 o Priority-based - described in Section 3.7 285 o Redundant - described in Section 3.8 287 o Control Plane Versus Data Plane - described in Section 3.9 289 o Combinations of Strategies - described in Section 3.10 291 3.1. Active-Standby 293 The traffic associated with a specific flow will be sent via a 294 specific path (the 'active path') and switched to another path 295 (called 'standby path') when the active access is unavailable. 297 3.2. Latency Versus Bandwidth 299 Some traffic might be sent over a network path with lower latency and 300 other traffic might be sent over a different network path with higher 301 bandwidth. 303 3.3. Bandwidth Aggregation/Load Balancing 305 Traffic is sent using all available paths simultaneously, so that all 306 available bandwidth is utilized, likely based on something like 307 weighted round-robin path selection. This strategy is often used for 308 bulk transfers. 310 3.4. Minimum RTT Difference 312 Traffic is sent over the path with the lowest smoothed RTT among all 313 available paths, in order to minimize latency for latency-sensitive 314 flows. 316 3.5. Round-Trip-Time Thresholds 318 Traffic is sent over the first path with a smoothed RTT that meets a 319 certain threshold. 321 3.6. RTT Equivalence 323 When multiple paths each have sufficiently similar smoothed RTTs, 324 traffic is sent over all of these paths. This is similar to 325 "Bandwidth Aggregation/Load Balancing", with the additional 326 qualification that not all available paths are used for this traffic. 328 3.7. Priority-based 330 Priorities are assigned to each path (often by association with 331 network interfaces). Traffic is sent on a highest-priority path 332 until it becomes congested, and then "overflows" onto a lower- 333 priority path. 335 3.8. Redundant 337 Traffic is replicated over two or more paths. This strategy could be 338 used continuously, but is more commonly used when measured network 339 conditions indicate that redundant sending may be necessary to 340 increase the likelihood that at least one copy of each packet will 341 arrive at the receiver. 343 3.9. Control Plane Versus Data Plane 345 An application might stream media over one or more available paths 346 (based on one of the other strategies named in this section), but 347 might send ACK traffic or retransmission over a path specifically 348 chosen for that purpose. This is more likely to be beneficial if the 349 path characteristics differ significantly between available paths - 350 for example, satellite uplink/downlink stations connected by both 351 higher-bandwidth Low Earth Orbit satellite paths and lower-bandwidth 352 cellular or landline paths. 354 3.10. Combinations of Strategies 356 In addition to the strategies described above, it is also possible to 357 combine these strategies. For example, a scheduler might use load- 358 balancing over three paths, but when one of the paths becomes 359 unavailable, the scheduler might switch to the two paths that are 360 still available, in a way similar to Active-Standby. This is very 361 much an example chosen at random - potentially, there are many 362 combinations that could be useful. 364 4. Implications for QUIC Multipath 366 This section summarizes potential implications for "Multipath QUIC" 367 of path selection strategies described in Section 3, dividing them 368 between "Traffic Switching" (Section 4.1) and "Traffic Splitting" 369 (Section 4.2). 371 4.1. Selecting a Single Path Among Multiple Validated Paths ("Traffic 372 Switching") 374 If a sender using Active-Standby (described in Section 3.1) does not 375 perform frequent path switching, it can likely be supported using 376 connection migration as defined in [RFC9000] without change. 378 o The caveat here is that connection migration can include the also- 379 implicit assumption that an endpoint can free up resources 380 associated with the previously-active path. If connection 381 migration happens often enough, the endpoint may spend 382 considerable time "thrashing" between allocating resources and 383 quickly freeing them. Of course, if a sender is frequently 384 selecting a new path for connection migration, this probably 385 degenerates into one of the other path selection strategies. 387 Some path selection strategies could be supported by a mechanism as 388 simple as the one proposed in [I-D.huitema-quic-mpath-option], which 389 replaces "the implicit signaling of path migration through data 390 transmission, by means of a new PATH_OPTION frame" (this isn't 391 intended to imply the proposal is simple, only the explicit 392 signaling), if the receiver uses this option to notify the sender of 393 the preferred path. For example, Minimum RTT Difference (described 394 in Section 3.4) and Round-Trip-Time Thresholds (described in 395 Section 3.5) likely fall into this category. 397 Some path selection strategies are exploiting a relatively long-lived 398 difference between paths - for example, Latency Versus Bandwidth 399 (described in Section 3.2), Priority-based (described in 400 Section 3.7), and Control Plane Versus Data Plane (described in 401 Section 3.9) may fall into this category. One might wonder why these 402 senders would need to use a single "multipath connection", rather 403 than multiple [RFC9000] connections, for these cases, but if there is 404 a reason to use a single multipath connection, a mechanism similar to 405 the one proposed in [I-D.huitema-quic-mpath-option] could also be 406 used in these cases. 408 4.2. Selecting Multiple Active Paths ("Traffic Splitting") 410 Some path selection strategies are treating more than one path as a 411 set of active paths, whether the sender is performing "Traffic 412 Splitting" (as defined in Section 1.3)), as is the case for Bandwidth 413 Aggregation/Load Balancing (described in Section 3.3) and RTT 414 Equivalence (described in Section 3.6), or simply transmitting the 415 same packet across multiple paths, as is the case for Redundant 416 (described in Section 3.8). 418 For these cases, a more complex mechanism is likely required. 420 4.3. Arbitrary Combinations 422 Because it is simple enough to imagine various combinations of 423 strategies (as described in Section 3.10), it seems important to 424 understand what basic building blocks are required in order to 425 support the strategies that seem common across a variety of use 426 cases, because interactions between strategies may have significant 427 implications for QUIC Multipath that might not arise when considering 428 strategies in isolation. 430 This seems especially important because existing proposals for QUIC 431 Multipath don't use the same vocabulary to describe path selection 432 strategies, so implementations may not behave in the same way, even 433 if they are each using a strategy that seems to be common. 435 5. Next Steps 437 If this discussion is useful, it may also be useful to take the next 438 step, and identify potential building blocks that can be used to 439 construct the path selection strategies described in Section 4.1 and 440 Section 4.2. 442 6. IANA Considerations 444 This document does not make any request to IANA. 446 7. Security Considerations 448 QUIC-specific security considerations are discussed in Section 21 of 449 [RFC9000]. 451 Section 6 of [I-D.ietf-quic-datagram] discusses security 452 considerations specific to the use of the Unreliable Datagram 453 Extension to QUIC. 455 Some "Multipath QUIC"-specific security considerations can be found 456 in the corresponding section of [I-D.deconinck-quic-multipath]. 458 Having said that, it may be best to repeat the security 459 considerations section from [I-D.huitema-quic-mpath-option]: "TBD. 460 There are probably ways to abuse this.". 462 8. Acknowledgments 464 Your name could appear here. Please comment and contribute, as per 465 Section 1.4. 467 9. Informative References 469 [I-D.an-multipath-quic] 470 An, Q., Liu, Y., Ma, Y., and Z. Li, "Multipath Extension 471 for QUIC", draft-an-multipath-quic-00 (work in progress), 472 October 2020. 474 [I-D.an-multipath-quic-application-policy] 475 An, Q., Li, Z., and Y. Liu, "Enabling application policy- 476 awareness in Multipath QUIC", draft-an-multipath-quic- 477 application-policy-00 (work in progress), July 2020. 479 [I-D.an-multipath-quic-traffic-distribution] 480 An, Q., Liu, D., and Y. Liu, "Key Components for Multipath 481 QUIC Traffic Distribution", draft-an-multipath-quic- 482 traffic-distribution-00 (work in progress), March 2020. 484 [I-D.bonaventure-iccrg-schedulers] 485 Bonaventure, O., Piraux, M., Coninck, Q. D., Baerts, M., 486 Paasch, C., and M. Amend, "Multipath schedulers", draft- 487 bonaventure-iccrg-schedulers-01 (work in progress), 488 September 2020. 490 [I-D.chan-quic-owl] 491 Chan, H. A., Wei, A., Song, F., and H. Zhang, "One Way 492 Latency Considerations for Multipath in QUIC", draft-chan- 493 quic-owl-01 (work in progress), March 2017. 495 [I-D.dawkins-quic-what-to-do-with-multipath] 496 Dawkins, S., "What To Do With Multiple Active Paths in 497 QUIC", draft-dawkins-quic-what-to-do-with-multipath-03 498 (work in progress), January 2021. 500 [I-D.deconinck-quic-multipath] 501 Coninck, Q. D. and O. Bonaventure, "Multipath Extensions 502 for QUIC (MP-QUIC)", draft-deconinck-quic-multipath-07 503 (work in progress), May 2021. 505 [I-D.huitema-quic-mpath-option] 506 Huitema, C., "QUIC Multipath Negotiation Option", draft- 507 huitema-quic-mpath-option-00 (work in progress), October 508 2020. 510 [I-D.huitema-quic-mpath-req] 511 Huitema, C., "QUIC Multipath Requirements", draft-huitema- 512 quic-mpath-req-01 (work in progress), January 2018. 514 [I-D.ietf-quic-datagram] 515 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 516 Datagram Extension to QUIC", draft-ietf-quic-datagram-02 517 (work in progress), February 2021. 519 [I-D.liu-multipath-quic] 520 Liu, Y., Ma, Y., Huitema, C., An, Q., and Z. Li, 521 "Multipath Extension for QUIC", draft-liu-multipath- 522 quic-03 (work in progress), March 2021. 524 [I-D.piraux-intarea-quic-tunnel-session] 525 Piraux, M., Bonaventure, O., and A. Masputra, "Session 526 mode for multiple QUIC Tunnels", draft-piraux-intarea- 527 quic-tunnel-session-00 (work in progress), November 2020. 529 [ICCRG-charter] 530 "IRTF Internet Congestion Control Research Group Charter", 531 n.d., . 533 [QUIC-charter] 534 "IETF QUIC Working Group Charter", n.d., 535 . 537 [QUIC-interim-20-10] 538 "IETF QUIC Working Group Virtual Interim Meeting - October 539 2020", October 2020, . 542 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 543 Paasch, "TCP Extensions for Multipath Operation with 544 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 545 2020, . 547 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 548 Multiplexed and Secure Transport", RFC 9000, 549 DOI 10.17487/RFC9000, May 2021, 550 . 552 [S2-2104599] 553 Lenovo, Motorola Mobility, ., "Study on Access Traffic 554 Steering, Switching and Splitting support in the 5G system 555 architecture; Phase 3", 2021, 556 . 559 [TR23700-93] 560 3GPP (3rd Generation Partnership Project), ., "Technical 561 Specification Group Services and System Aspects; Study on 562 access traffic steering, switch and splitting support in 563 the 5G System (5GS) architecture; Phase 2 (Release 17)", 564 2021, . 567 [TS23501] 3GPP (3rd Generation Partnership Project), ., "Technical 568 Specification Group Services and System Aspects; System 569 Architecture for the 5G System; Stage 2 (Release 16)", 570 2019, . 573 Author's Address 575 Spencer Dawkins 576 Tencent America LLC 578 Email: spencerdawkins.ietf@gmail.com