| Internet-Draft | QUIC Multipath Path Selection | June 2021 |
| Dawkins | Expires 4 December 2021 | [Page] |
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.¶
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 4 December 2021.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
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?¶
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.¶
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 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.¶
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.¶
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.¶
"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".¶
(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.¶
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):¶
[I-D.bonaventure-iccrg-schedulers] has also been submitted to the Internet Congestion Control Research Group [ICCRG-charter] in the 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.¶
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.¶
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.¶
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.¶
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.¶
Traffic is sent over the path with the lowest smoothed RTT among all available paths, in order to minimize latency for latency-sensitive flows.¶
Traffic is sent over the first path with a smoothed RTT that meets a certain threshold.¶
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.¶
Priorities are assigned to each path (often by association with network interfaces). Traffic is sent on a highest-priority path until it becomes congested, and then "overflows" onto a lower-priority path.¶
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.¶
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.¶
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.¶
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).¶
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.¶
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.¶
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.¶
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 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.¶
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.¶
This document does not make any request to IANA.¶
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.".¶
Your name could appear here. Please comment and contribute, as per Section 1.4.¶