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