QUIC Working Group S. Dawkins Internet-Draft Tencent America LLC Intended status: Informational June 02, 2021 Expires: December 4, 2021 Path Selection for Multiple Paths In QUIC draft-dawkins-quic-multipath-selection-01 Abstract In QUIC working group discussions about proposals to use multiple paths, an obvious question came up - given multiple paths, how does QUIC select paths to send packets over? The answer to that question may inform decisions in the QUIC working group about the scope of any multipath extensions considered for experimentation and adoption. This document is intended to summarize aspects of path selection from those contributions and conversations. It is recognized that path selection is not the only important open question about QUIC Multipath, but other open questions are out of scope for this document. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 4, 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. Dawkins Expires December 4, 2021 [Page 1] Internet-Draft QUIC Multipath Path Selection June 2021 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Why We Should Look at Path Selection Strategies Now . . . 3 1.2. Notes for Readers . . . . . . . . . . . . . . . . . . . . 4 1.3. Minimal Terminology . . . . . . . . . . . . . . . . . . . 4 1.4. Contribution and Discussion Venues for this draft. . . . 5 2. Background for this document . . . . . . . . . . . . . . . . 5 3. Overview of Proposed Path Selection Strategies . . . . . . . 6 3.1. Active-Standby . . . . . . . . . . . . . . . . . . . . . 7 3.2. Latency Versus Bandwidth . . . . . . . . . . . . . . . . 7 3.3. Bandwidth Aggregation/Load Balancing . . . . . . . . . . 7 3.4. Minimum RTT Difference . . . . . . . . . . . . . . . . . 7 3.5. Round-Trip-Time Thresholds . . . . . . . . . . . . . . . 7 3.6. RTT Equivalence . . . . . . . . . . . . . . . . . . . . . 7 3.7. Priority-based . . . . . . . . . . . . . . . . . . . . . 7 3.8. Redundant . . . . . . . . . . . . . . . . . . . . . . . . 8 3.9. Control Plane Versus Data Plane . . . . . . . . . . . . . 8 3.10. Combinations of Strategies . . . . . . . . . . . . . . . 8 4. Implications for QUIC Multipath . . . . . . . . . . . . . . . 8 4.1. Selecting a Single Path Among Multiple Validated Paths ("Traffic Switching") . . . . . . . . . . . . . . . . . . 8 4.2. Selecting Multiple Active Paths ("Traffic Splitting") . . 9 4.3. Arbitrary Combinations . . . . . . . . . . . . . . . . . 9 5. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. Informative References . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction In QUIC working group [QUIC-charter] discussions about proposals to use multiple paths, an obvious question came up - given multiple paths, how does QUIC select paths to send packets over? Dawkins Expires December 4, 2021 [Page 2] Internet-Draft QUIC Multipath Path Selection June 2021 The answer to that question may inform decisions in the QUIC working group about the scope of any multipath extensions considered for experimentation and adoption. This document is intended to summarize aspects of path selection from those contributions and conversations. It is recognized that path selection is not the only important open question about QUIC Multipath, but other open questions are out of scope for this document. 1.1. Why We Should Look at Path Selection Strategies Now One of the first questions that's come up in discussions about multiple paths for QUIC has been about path selection. As soon as an implementation has multiple paths available, it must decide how to use these paths. The [RFC9000] answer, relying on connection migration, is "if you have multiple paths available, you can validate more than one connection at a time, but you only send on one connection at a time, and you migrate to another connection when you decide sending on the current connection is no longer appropriate. How you decide to migrate to another connection is up to you". That has been a fine answer for many of the implementers who have worked on the first version of QUIC, and have deployed it in their networks. For other implementers, targeting other use cases and other networking environments, it may not be sufficient. To take only one example, one of several presentations at [QUIC-interim-20-10] described aspects of 3GPP Access Traffic Steering, Switch and Splitting support (ATSSS), which contained four "Steering Modes" as part of Rel-16 in 2019 [TS23501], each of which corresponding roughly to a path selection strategy described in Section 3 of this document. A study on "ATSSS Phase 2" [TR23700-93] included four more Steering Modes for Rel-17, expected to be finalized in mid-2021, and none of these eight (so far) Steering Modes are based on QUIC - they are based on Multipath TCP ([RFC8684] or simple IP packet forwarding. And if that were not enough, a proposal for a study on "ATSSS Phase 3" [S2-2104599] was provided to the SA2 145-e meeting in May 2021. Some of the ATSSS strategies rely in 5G network internals and don't translate to the broader Internet, but most do translate, and 3GPP participants certainly aren't the only people thinking about path selection strategies. Since the various proposals presented at [QUIC-interim-20-10] were developed in isolation from each other, the path selection strategies that they reflect may be similar between proposals, but not quite the Dawkins Expires December 4, 2021 [Page 3] Internet-Draft QUIC Multipath Path Selection June 2021 same, and none of the proposals presented had more than two strategies in common with any other proposal. Given the number of path selection strategies being considered, implemented, and even deployed in any number of venues, and the potential for combinatorial explosion as described in Section 3.10, it seems that identifying common aspects of path selection strategies, sooner rather than later, is important. 1.2. Notes for Readers This document is an informational Internet-Draft, not adopted by any IETF working group, and does not carry any special status within the IETF. Please note well that this document reflects the author's current understanding of past working group discussions and proposals. Contributions that add or improve considerations are welcomed, as described in Section 1.4. 1.3. Minimal Terminology In this document, "QUIC multipath" is only used as shorthand for "QUIC using multiple paths". It does not refer to a specific proposal. In this document, "path selection strategy" means the policy that a QUIC sender uses to guide its choice between multiple interfaces of a QUIC connection for "the next packet". This document adopts three terms, stolen from [TS23501], that seemed helpful in previous discussions about multipath in the QUIC working group. o Traffic Steering - selecting an initial path (in [RFC9000], this would be "validating a connection, and then using it". Although an [RFC9000] client can validate multiple connections, the client will only use one validated connection at a time. o Traffic Switching - selecting a different validated path (in [RFC9000], this is something like "migrating to a new validated connection", although whether connection migration as defined in [RFC9000]) would be sufficient is discussed in Section 4). o Traffic Splitting - using multiple validated paths simultaneously (this would almost certainly require an extension beyond connection migration as defined in [RFC9000]). Dawkins Expires December 4, 2021 [Page 4] Internet-Draft QUIC Multipath Path Selection June 2021 "Traffic Steering" does not require any extension to [RFC9000], and is not discussed further in this document. The focus will be on "Traffic Switching" and "Traffic Splitting". 1.4. Contribution and Discussion Venues for this draft. (Note to RFC Editor - if this document ever reaches you, please remove this section) This document is under development in the Github repository at https://github.com/SpencerDawkins/quic-multipath-selection. Readers are invited to open issues and send pull requests with contributed text for this document, but since the document is intended to guide discussion for the QUIC working group, substantial discussion of this document should take place on the QUIC working group mailing list (quic@ietf.org). Mailing list subscription and archive details are at https://www.ietf.org/mailman/listinfo/quic. 2. Background for this document A number of individual draft proposals for "QUIC over multiple paths" have been submitted to the IETF QUIC and INTAREA working groups, dating back as far as 2017. The author thinks that the complete list is as follows (and reminders for proposals he missed are welcomed): o [I-D.an-multipath-quic] o [I-D.an-multipath-quic-application-policy] o [I-D.an-multipath-quic-traffic-distribution] o [I-D.chan-quic-owl] o [I-D.deconinck-quic-multipath] o [I-D.deconinck-quic-multipath], o [I-D.huitema-quic-mpath-req] o [I-D.huitema-quic-mpath-option]) o [I-D.liu-multipath-quic] o [I-D.piraux-intarea-quic-tunnel-session] [I-D.bonaventure-iccrg-schedulers] has also been submitted to the Internet Congestion Control Research Group [ICCRG-charter] in the Dawkins Expires December 4, 2021 [Page 5] Internet-Draft QUIC Multipath Path Selection June 2021 Internet Research Task Force. It contains specific proposals for implementing some multipath schedulers, and includes some discussion of path selection relevant to this document. One point of confusion in QUIC working group discussions was that the various proposals (also using Multipath TCP [RFC8684], so not all proposals were QUIC-specific) discussed in working group meetings and on the QUIC mailing list were from various proponents who weren't solving the same problem. This meant that no two of the use cases presented at the QUIC working group virtual interim on QUIC Multipath [QUIC-interim-20-10] were relying on the same strategies. It seemed useful to collect the path selection strategies described in those proposals, to look for common elements, and to write them down in one place, to allow more focused discussion. [I-D.dawkins-quic-what-to-do-with-multipath] was intended to summarize, at a high level, various proposals for the use of multipath capabilities in QUIC, both inside the IETF and outside the IETF, in order to identify elements that were common across proposals. This draft tries to describe the impact of these various strategies on potential QUIC Multipath extensions. One element that is certainly worth considering is whether the path selection strategies that have been proposed can be satisfied using a small number of "building block" strategies. 3. Overview of Proposed Path Selection Strategies The following strategies were discussed at [QUIC-interim-20-10], and afterwards on the QUIC mailing list. These are summarized in this section, are described in more detail in [I-D.dawkins-quic-what-to-do-with-multipath], and are attributed to various proposals in that document. o Active-Standby - described in Section 3.1 o Latency Versus Bandwidth - described in Section 3.2 o Bandwidth Aggregation/Load Balancing - described in Section 3.3 o Minimum RTT Difference - described in Section 3.4 o Round-Trip-Time Thresholds - described in Section 3.5 o RTT Equivalence - described in Section 3.6 o Priority-based - described in Section 3.7 Dawkins Expires December 4, 2021 [Page 6] Internet-Draft QUIC Multipath Path Selection June 2021 o Redundant - described in Section 3.8 o Control Plane Versus Data Plane - described in Section 3.9 o Combinations of Strategies - described in Section 3.10 3.1. Active-Standby The traffic associated with a specific flow will be sent via a specific path (the 'active path') and switched to another path (called 'standby path') when the active access is unavailable. 3.2. Latency Versus Bandwidth Some traffic might be sent over a network path with lower latency and other traffic might be sent over a different network path with higher bandwidth. 3.3. Bandwidth Aggregation/Load Balancing Traffic is sent using all available paths simultaneously, so that all available bandwidth is utilized, likely based on something like weighted round-robin path selection. This strategy is often used for bulk transfers. 3.4. Minimum RTT Difference Traffic is sent over the path with the lowest smoothed RTT among all available paths, in order to minimize latency for latency-sensitive flows. 3.5. Round-Trip-Time Thresholds Traffic is sent over the first path with a smoothed RTT that meets a certain threshold. 3.6. RTT Equivalence When multiple paths each have sufficiently similar smoothed RTTs, traffic is sent over all of these paths. This is similar to "Bandwidth Aggregation/Load Balancing", with the additional qualification that not all available paths are used for this traffic. 3.7. Priority-based Priorities are assigned to each path (often by association with network interfaces). Traffic is sent on a highest-priority path Dawkins Expires December 4, 2021 [Page 7] Internet-Draft QUIC Multipath Path Selection June 2021 until it becomes congested, and then "overflows" onto a lower- priority path. 3.8. Redundant Traffic is replicated over two or more paths. This strategy could be used continuously, but is more commonly used when measured network conditions indicate that redundant sending may be necessary to increase the likelihood that at least one copy of each packet will arrive at the receiver. 3.9. Control Plane Versus Data Plane An application might stream media over one or more available paths (based on one of the other strategies named in this section), but might send ACK traffic or retransmission over a path specifically chosen for that purpose. This is more likely to be beneficial if the path characteristics differ significantly between available paths - for example, satellite uplink/downlink stations connected by both higher-bandwidth Low Earth Orbit satellite paths and lower-bandwidth cellular or landline paths. 3.10. Combinations of Strategies In addition to the strategies described above, it is also possible to combine these strategies. For example, a scheduler might use load- balancing over three paths, but when one of the paths becomes unavailable, the scheduler might switch to the two paths that are still available, in a way similar to Active-Standby. This is very much an example chosen at random - potentially, there are many combinations that could be useful. 4. Implications for QUIC Multipath This section summarizes potential implications for "Multipath QUIC" of path selection strategies described in Section 3, dividing them between "Traffic Switching" (Section 4.1) and "Traffic Splitting" (Section 4.2). 4.1. Selecting a Single Path Among Multiple Validated Paths ("Traffic Switching") If a sender using Active-Standby (described in Section 3.1) does not perform frequent path switching, it can likely be supported using connection migration as defined in [RFC9000] without change. o The caveat here is that connection migration can include the also- implicit assumption that an endpoint can free up resources Dawkins Expires December 4, 2021 [Page 8] Internet-Draft QUIC Multipath Path Selection June 2021 associated with the previously-active path. If connection migration happens often enough, the endpoint may spend considerable time "thrashing" between allocating resources and quickly freeing them. Of course, if a sender is frequently selecting a new path for connection migration, this probably degenerates into one of the other path selection strategies. Some path selection strategies could be supported by a mechanism as simple as the one proposed in [I-D.huitema-quic-mpath-option], which replaces "the implicit signaling of path migration through data transmission, by means of a new PATH_OPTION frame" (this isn't intended to imply the proposal is simple, only the explicit signaling), if the receiver uses this option to notify the sender of the preferred path. For example, Minimum RTT Difference (described in Section 3.4) and Round-Trip-Time Thresholds (described in Section 3.5) likely fall into this category. Some path selection strategies are exploiting a relatively long-lived difference between paths - for example, Latency Versus Bandwidth (described in Section 3.2), Priority-based (described in Section 3.7), and Control Plane Versus Data Plane (described in Section 3.9) may fall into this category. One might wonder why these senders would need to use a single "multipath connection", rather than multiple [RFC9000] connections, for these cases, but if there is a reason to use a single multipath connection, a mechanism similar to the one proposed in [I-D.huitema-quic-mpath-option] could also be used in these cases. 4.2. Selecting Multiple Active Paths ("Traffic Splitting") Some path selection strategies are treating more than one path as a set of active paths, whether the sender is performing "Traffic Splitting" (as defined in Section 1.3)), as is the case for Bandwidth Aggregation/Load Balancing (described in Section 3.3) and RTT Equivalence (described in Section 3.6), or simply transmitting the same packet across multiple paths, as is the case for Redundant (described in Section 3.8). For these cases, a more complex mechanism is likely required. 4.3. Arbitrary Combinations Because it is simple enough to imagine various combinations of strategies (as described in Section 3.10), it seems important to understand what basic building blocks are required in order to support the strategies that seem common across a variety of use cases, because interactions between strategies may have significant Dawkins Expires December 4, 2021 [Page 9] Internet-Draft QUIC Multipath Path Selection June 2021 implications for QUIC Multipath that might not arise when considering strategies in isolation. This seems especially important because existing proposals for QUIC Multipath don't use the same vocabulary to describe path selection strategies, so implementations may not behave in the same way, even if they are each using a strategy that seems to be common. 5. Next Steps If this discussion is useful, it may also be useful to take the next step, and identify potential building blocks that can be used to construct the path selection strategies described in Section 4.1 and Section 4.2. 6. IANA Considerations This document does not make any request to IANA. 7. Security Considerations QUIC-specific security considerations are discussed in Section 21 of [RFC9000]. Section 6 of [I-D.ietf-quic-datagram] discusses security considerations specific to the use of the Unreliable Datagram Extension to QUIC. Some "Multipath QUIC"-specific security considerations can be found in the corresponding section of [I-D.deconinck-quic-multipath]. Having said that, it may be best to repeat the security considerations section from [I-D.huitema-quic-mpath-option]: "TBD. There are probably ways to abuse this.". 8. Acknowledgments Your name could appear here. Please comment and contribute, as per Section 1.4. 9. Informative References [I-D.an-multipath-quic] An, Q., Liu, Y., Ma, Y., and Z. Li, "Multipath Extension for QUIC", draft-an-multipath-quic-00 (work in progress), October 2020. Dawkins Expires December 4, 2021 [Page 10] Internet-Draft QUIC Multipath Path Selection June 2021 [I-D.an-multipath-quic-application-policy] An, Q., Li, Z., and Y. Liu, "Enabling application policy- awareness in Multipath QUIC", draft-an-multipath-quic- application-policy-00 (work in progress), July 2020. [I-D.an-multipath-quic-traffic-distribution] An, Q., Liu, D., and Y. Liu, "Key Components for Multipath QUIC Traffic Distribution", draft-an-multipath-quic- traffic-distribution-00 (work in progress), March 2020. [I-D.bonaventure-iccrg-schedulers] Bonaventure, O., Piraux, M., Coninck, Q. D., Baerts, M., Paasch, C., and M. Amend, "Multipath schedulers", draft- bonaventure-iccrg-schedulers-01 (work in progress), September 2020. [I-D.chan-quic-owl] Chan, H. A., Wei, A., Song, F., and H. Zhang, "One Way Latency Considerations for Multipath in QUIC", draft-chan- quic-owl-01 (work in progress), March 2017. [I-D.dawkins-quic-what-to-do-with-multipath] Dawkins, S., "What To Do With Multiple Active Paths in QUIC", draft-dawkins-quic-what-to-do-with-multipath-03 (work in progress), January 2021. [I-D.deconinck-quic-multipath] Coninck, Q. D. and O. Bonaventure, "Multipath Extensions for QUIC (MP-QUIC)", draft-deconinck-quic-multipath-07 (work in progress), May 2021. [I-D.huitema-quic-mpath-option] Huitema, C., "QUIC Multipath Negotiation Option", draft- huitema-quic-mpath-option-00 (work in progress), October 2020. [I-D.huitema-quic-mpath-req] Huitema, C., "QUIC Multipath Requirements", draft-huitema- quic-mpath-req-01 (work in progress), January 2018. [I-D.ietf-quic-datagram] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", draft-ietf-quic-datagram-02 (work in progress), February 2021. Dawkins Expires December 4, 2021 [Page 11] Internet-Draft QUIC Multipath Path Selection June 2021 [I-D.liu-multipath-quic] Liu, Y., Ma, Y., Huitema, C., An, Q., and Z. Li, "Multipath Extension for QUIC", draft-liu-multipath- quic-03 (work in progress), March 2021. [I-D.piraux-intarea-quic-tunnel-session] Piraux, M., Bonaventure, O., and A. Masputra, "Session mode for multiple QUIC Tunnels", draft-piraux-intarea- quic-tunnel-session-00 (work in progress), November 2020. [ICCRG-charter] "IRTF Internet Congestion Control Research Group Charter", n.d., . [QUIC-charter] "IETF QUIC Working Group Charter", n.d., . [QUIC-interim-20-10] "IETF QUIC Working Group Virtual Interim Meeting - October 2020", October 2020, . [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [S2-2104599] Lenovo, Motorola Mobility, ., "Study on Access Traffic Steering, Switching and Splitting support in the 5G system architecture; Phase 3", 2021, . [TR23700-93] 3GPP (3rd Generation Partnership Project), ., "Technical Specification Group Services and System Aspects; Study on access traffic steering, switch and splitting support in the 5G System (5GS) architecture; Phase 2 (Release 17)", 2021, . Dawkins Expires December 4, 2021 [Page 12] Internet-Draft QUIC Multipath Path Selection June 2021 [TS23501] 3GPP (3rd Generation Partnership Project), ., "Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2 (Release 16)", 2019, . Author's Address Spencer Dawkins Tencent America LLC Email: spencerdawkins.ietf@gmail.com Dawkins Expires December 4, 2021 [Page 13]