idnits 2.17.1 draft-dawkins-quic-what-to-do-with-multipath-03.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 (January 06, 2021) is 1206 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-amend-iccrg-multipath-reordering-01 == Outdated reference: A later version (-02) exists of draft-bonaventure-iccrg-schedulers-01 == Outdated reference: A later version (-01) exists of draft-dawkins-quic-multipath-questions-00 == Outdated reference: A later version (-07) exists of draft-deconinck-quic-multipath-06 == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-33 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC Working Group S. Dawkins, Ed. 3 Internet-Draft Tencent America 4 Intended status: Informational January 06, 2021 5 Expires: July 10, 2021 7 What To Do With Multiple Active Paths in QUIC 8 draft-dawkins-quic-what-to-do-with-multipath-03 10 Abstract 12 The IETF QUIC working group has been chartered to produce extensions 13 that would "enable ... multipath capabilities" since the working 14 group was formed in 2016, but because multipath was an extension, 15 work on multipath, and the other extensions named in the charter, 16 waited while work proceeded on the core QUIC protocol specifications. 18 After the QUIC working group chairs requested publication for the 19 core QUIC protocol specifications, they scheduled a virtual interim 20 meeting to understand the use cases that various groups inside and 21 outside the IETF were envisioning for multipath with QUIC. 23 As part of that discussion, it became obvious that people had a 24 variety of ideas about how multiple paths would be used, because they 25 weren't looking at the same use cases. 27 This document is intended to capture that variety of ideas, to inform 28 further discussion in the working group. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 10, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Other Voices . . . . . . . . . . . . . . . . . . . . . . 3 66 1.2. Notes for Readers . . . . . . . . . . . . . . . . . . . . 4 67 1.3. Contribution and Discussion Venues for this draft. . . . 4 68 2. Multipath Modes of Operation . . . . . . . . . . . . . . . . 4 69 2.1. Reference Architecture . . . . . . . . . . . . . . . . . 4 70 2.2. Sending When Multiple Paths Are Available . . . . . . . . 6 71 2.2.1. Traffic Steering . . . . . . . . . . . . . . . . . . 6 72 2.2.2. Traffic Switching . . . . . . . . . . . . . . . . . . 6 73 2.2.3. Traffic Splitting . . . . . . . . . . . . . . . . . . 7 74 2.2.4. Traffic Steering, Traffic Switching, and Traffic 75 Splitting in the Core QUIC Transport Protocol and 76 Datagram Extension . . . . . . . . . . . . . . . . . 7 77 2.3. Sending Strategies with Multiple Paths . . . . . . . . . 8 78 2.3.1. Active-Standby . . . . . . . . . . . . . . . . . . . 8 79 2.3.2. Trading Latency Versus Bandwidth . . . . . . . . . . 8 80 2.3.3. Bandwidth Aggregation/Load Balancing . . . . . . . . 8 81 2.3.4. Round-Trip-Time Thresholds, Minimum RTT Difference, 82 and RTT Equivalence . . . . . . . . . . . . . . . . . 9 83 2.3.5. Priority-based . . . . . . . . . . . . . . . . . . . 9 84 2.3.6. Redundant . . . . . . . . . . . . . . . . . . . . . . 9 85 2.3.7. Combinations of Strategies . . . . . . . . . . . . . 10 86 2.4. Unified Field Theory of Path Selection . . . . . . . . . 10 87 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 88 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 89 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 90 6. Document History . . . . . . . . . . . . . . . . . . . . . . 12 91 7. Informative References . . . . . . . . . . . . . . . . . . . 12 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 The IETF QUIC working group has been chartered to produce extensions 97 that would "enable ... multipath capabilities" ([QUIC-charter]) since 98 the working group was formed in 2016, but because multipath was an 99 extension, work on multipath, and the other extensions named in the 100 charter, waited while work proceeded on the core QUIC protocol 101 specifications ([I-D.ietf-quic-transport] and related 102 specifications). 104 After the QUIC working group chairs requested publication for the 105 core QUIC protocol specifications, they scheduled a virtual interim 106 meeting ([QUIC-interim-20-10]) to understand the use cases that 107 various groups inside and outside the IETF were envisioning for 108 multipath with QUIC. 110 As part of that discussion, it became obvious that people had a 111 variety of ideas about how multiple paths would be used, because they 112 weren't looking at the same use cases. From an architectural point 113 of view, two main multipath scenarios emerged. The first scenario 114 was envisioned by people who were focused on end-to-end service, and 115 the second scenario was envisioned by people who expected some sort 116 of (explicit) intermediary, such as a transport proxy or tunnel 117 endpoint, between the ultimate endpoints. 119 This document is intended to capture that variety of ideas, to inform 120 further discussion in the working group. 122 For more details, please see the QUIC working group meeting minutes, 123 at [QUIC-interim-20-10-minutes], which include pointers to the video 124 recording from the meeting, pointers to each presentation given, 125 questions and answers after each presentation, and overall discussion 126 following the presentations. 128 1.1. Other Voices 130 This document grew out of discussions in the QUIC working group, but 131 there are other efforts working on multipath in both the IETF and the 132 IRTF, and their work includes mentions of strategies for using 133 multiple paths. I'll add this work as I find it, if that work is 134 proposing a strategy that hasn't been mentioned in the QUIC 135 discussion. In particular, strategies named in 136 [I-D.bonaventure-iccrg-schedulers] have been included in Section 2.3, 137 in the current version of the draft. 139 1.2. Notes for Readers 141 This document is an informational Internet-Draft, not adopted by any 142 IETF working group, and does not carry any special status within the 143 IETF. 145 It reflects the author's understanding, and contributions that 146 include improvements and clarifications are welcomed, as described in 147 Section 1.3. 149 1.3. Contribution and Discussion Venues for this draft. 151 (Note to RFC Editor - if this document ever reaches you, please 152 remove this section) 154 This document is under development in the Github repository at 155 https://github.com/SpencerDawkins/draft-dawkins-quic-what-to-do-with- 156 multipath. Readers are invited to open issues and send pull requests 157 with contributed text for this document. 159 Substantial discussion of this document should take place on the QUIC 160 working group mailing list (quic@ietf.org). Subscription and archive 161 details are at https://www.ietf.org/mailman/listinfo/quic. 163 2. Multipath Modes of Operation 165 For the purposes of this document, it's enough to consider two QUIC 166 endpoints (QUIC Host X and QUIC Host Y) with two disjoint paths 167 between them (Access Net A and Access Net B), as shown in Figure 1. 169 2.1. Reference Architecture 170 ------------ 171 / \ 172 +-------| Access Net A |--+ 173 | \ / | 174 | ------------ | 175 +---+--+ | +------+ 176 | QUIC | +--------| QUIC | 177 } Host | | Host | 178 | X | +--------| Y | 179 +---+--+ | +------+ 180 | ------------ | 181 | / \ | 182 +-------| Access Net B |--+ 183 \ / 184 ------------ 186 Figure 1: Simplified Reference Architecture for QUIC Multipath 187 Operation 189 Some use cases limit themselves to two paths - for example, the use 190 case described in [I-D.bonaventure-quic-atsss-overview] is limited to 191 one 5G 3GPP access network and one non-3GPP access network. More 192 than two paths are certainly possible - for example, two hosts that 193 are connected by a satellite path, and two different landline paths 194 from different network providers for redundancy. But I believe this 195 simplified architecture is sufficient for discussion purposes. 197 Please note: as mentioned in Section 1, some readers will be thinking 198 of an end-to-end QUIC connection between QUIC Host X and QUIC Host Y 199 in Figure 1, while other readers will be thinking of QUIC Host Y as 200 some sort of (explicit) transport proxy or tunnel endpoint, e.g. 201 [I-D.bonaventure-quic-atsss-overview]. This document is only focused 202 on the multiple paths between QUIC Host X and QUIC Host Y, in order 203 to talk about classes of sending and strategies for sending over 204 multiple paths. However, it might be that further implications arose 205 from the motivation of end-to-end multipath or intermediary 206 multipath. In particular the latter will additionally require, 207 according to [I-D.bonaventure-quic-atsss-overview], QUIC datagram 208 (unreliable transport) and tunneling support. While multipath 209 traffic distribution strategies play a central role in multipath 210 transport, multipath re-ordering strategies become additionally 211 important for multipath over unreliable network protocols. Possible 212 strategies to solve this are described in 213 [I-D.amend-iccrg-multipath-reordering]. Another complexitiy, not in 214 scope of this document, is the interaction between multipath 215 scheduling and QUIC stream traffic scheduling. 217 2.2. Sending When Multiple Paths Are Available 219 This section uses terminology from 3GPP ATSSS {Access Traffic 220 Steering, Switch and Splitting, [TS23501]) to describe three 221 different classes of packet sending that could be used when multiple 222 disjoint paths are available. Note that these terms describe 223 concepts that are not ATSSS-specific, and could apply to any 224 multipath environment. If terminology more accessible to IETF QUIC 225 working group participants presents itself, I'll change it. 227 Please note that the relationship between "flows", "packets", and 228 "datagrams" isn't entirely clear yet. In [TS23501], a "flow" is 229 defined as "a set of packets that share an ordering constraint", 230 which maps reasonably well onto TCP bytestreams and correspondingly 231 onto MP-TCP bytestreams, but the core QUIC transport mechanism 232 [I-D.ietf-quic-transport] provides multiple bytesteams in a single 233 connection, and leveraging QUIC streams seems to be a use case 234 enabler, whether for redundantly sending overlapping ranges, for 235 efficiently striping non-overlapping ranges for bandwidth, or for 236 strict ordering. 238 Further, with the QUIC datagram extension [I-D.ietf-quic-datagram], 239 DATAGRAM frames can be carried in a QUIC connection, but are not part 240 of a stream and do not interact with in-order delivery within a 241 stream. 243 2.2.1. Traffic Steering 245 When a sending host has a new "flow", and has more than one path 246 available, a sending host will select a path to begin sending packets 247 on. This can be described as Traffic Steering. 249 Note that the selection of a path is "per-flow". Different flows may 250 be steered onto different paths, but each flow will be sent on a 251 single path. 253 The choice of a path can be based on a number of factors - for 254 instance, whether the path will be used for bulk transfer, or whether 255 an unmetered path is available. Those factors are important, but for 256 this document, the point is that a path is selected. 258 2.2.2. Traffic Switching 260 When a sending host has more than one path available and is sending a 261 flow on a single path, the sending host can stop using this path for 262 this flow, and start using another path. This can be described as 263 Traffic Switching. 265 Note that the selection of another path is also per-flow. A sender 266 can switch a flow onto a different path, without switching any other 267 flows to that path. 269 2.2.3. Traffic Splitting 271 When a sending host has more than one path available, the sending 272 host may wish to use multiple paths simultaneously for a single flow. 273 This can be described as Traffic Splitting. 275 Note that splitting a flow onto multiple paths means that the sending 276 decision would be made on a packet-by-packet basis. No guarantee of 277 packet ordering across paths is assumed. 279 Note that splitting a flow onto multiple paths, packet by packet, 280 means that any ordering constraint must be provided by an upper layer 281 metchanism. In [TS23501], Multipath TCP [RFC8684] is used to provide 282 that ordering constraint. 284 2.2.4. Traffic Steering, Traffic Switching, and Traffic Splitting in 285 the Core QUIC Transport Protocol and Datagram Extension 287 [I-D.ietf-quic-transport] and related specifications support the 288 selection and use of multiple paths for a connection between QUIC 289 endpoints, as long as only one path is in active use at any given 290 time. [I-D.ietf-quic-transport] and related specifications do not 291 support sending traffic for a single connection on multiple paths 292 between QUIC endpoints simultaneously. 294 This level of support for multipath allows Traffic Steering - the 295 selection of a specific path - and Traffic Switching - migration of 296 traffic from one path to another, using QUIC connection migration. 297 It does not allow "Traffic Splitting" - the use of simultaneous paths 298 for a single connection. 300 One important output from the QUIC interim meeting was the 301 recognition that some participants view "Traffic Switching" as 302 something like "protection switching" from an active path to a 303 standby path, that doesn't happen often, while other participants 304 view QUIC connection migration as a way of responding frequently to 305 changing path conditions. This will be an important part of the 306 conversation about multipath QUIC. 308 If a QUIC endpoint opens and validates two or more connections, no 309 additional setup or signaling is required for a sender to switch 310 paths - that can begin with the next packet queued for transmission. 311 This would allow "Traffic Splitting" for unordered QUIC DATAGRAMs 313 [I-D.ietf-quic-datagram], with an upper-layer mechanism providing 314 flow ordering if that is needed. 316 2.3. Sending Strategies with Multiple Paths 318 During the QUIC virtual interim meeting, various presenters described 319 various sending strategies that they have used in the past 320 (especially with TCP [RFC0793] and Multipath TCP [RFC8684]). and that 321 they expected to use in the future with some multipath QUIC 322 extension. 324 This section is an attempt to identify commonalities and gaps that 325 may inform work on future multipath extensions for QUIC. 327 All of these sending strategies build on Traffic Steering - opening 328 one or more connections for a new flow, and then proceeding to use 329 one connection, switch to another connection, or split traffic across 330 paths. For this reason, Traffic Steering isn't mentioned in the rest 331 of this section. 333 2.3.1. Active-Standby 335 The traffic associated with a specific flow will be sent via a 336 specific path (the 'active path') and switched to another path 337 (called 'standby path') when the active access is unavailable. 338 Traffic Switching is sufficient to support this strategy. 339 [Alibaba-MPQUIC] and [Multipath-3GPP-ATSSS] mentioned this strategy 340 at the QUIC Interim meeting. 342 2.3.2. Trading Latency Versus Bandwidth 344 Some applications require low latency, and others don't. So using a 345 network path with lower latency for some connections, and using a 346 different network path with higher bandwidth available for others. 347 allows this strategy. Traffic Switching is sufficient for this, if 348 measured path characteristics change enough to justify changing 349 paths. [Chromium-Multipath] mentioned this strategy at the QUIC 350 Interim Meeting. [Apple-Multipath] and [Sat-Terr-Multipath] are 351 actually switching paths at sub-RTT rates. 353 2.3.3. Bandwidth Aggregation/Load Balancing 355 Some environments allow the use of multiple paths simultaneously for 356 significant periods of time, because none of the paths are metered, 357 so using all of the bandwidth on all of the paths simultaneously 358 makes sense for bulk transfers. Traffic Splitting is required to 359 support this strategy. [Alibaba-MPQUIC], [Hybrid-Access-Multipath], 360 [Sat-Terr-Multipath], and [Multipath-3GPP-ATSSS] all mentioned this 361 strategy at the QUIC Interim Meeting. 362 [I-D.bonaventure-iccrg-schedulers] mentions this strategy as "Round- 363 Robin" (not recommended) and "Weighted Round-Robin". 365 2.3.4. Round-Trip-Time Thresholds, Minimum RTT Difference, and RTT 366 Equivalence 368 Not all multipath environments include paths with significant 369 differences between path characteristics, but several do. 371 A sender might select the first available path with a smoothed round- 372 trip-time below a certain threshold. The goal is to keep the RTT of 373 the multipath connection to a small value and avoid having the whole 374 connection impacted by "bad" paths. 375 [I-D.bonaventure-iccrg-schedulers] mentions this strategy as "Round- 376 Trip-Time Threshold". 378 A sender might select the path with the lowest RTT among all 379 available paths, in order to minimize latency for latency-sensitive 380 flows. [I-D.bonaventure-iccrg-schedulers] mentions this strategy as 381 "Lowest Round-Trip-Time First". 383 If two or more paths have characteristics that are "sufficiently 384 close" - for example, they may have path RTTs that are equivalent, 385 from the application's point of view - a sender may wish to use both 386 paths as long as that's the case, and then adopt another sending 387 strategy when measured path characteristics diverge. Traffic 388 Splitting is required to support this strategy. [Apple-Multipath], 389 [Sat-Terr-Multipath].[Hybrid-Access-Multipath], and 390 [Multipath-3GPP-ATSSS] all mentioned this strategy at the QUIC 391 Interim Meeting. 393 2.3.5. Priority-based 395 Paths are assigned priority levels that indicate which path will be 396 used first. Concretely, the traffic associated with the matching 397 flow will be steered on the path with a high priority till congestion 398 is detected, then the overflow will be sent over a low priority 399 access. Traffic Splitting is required to support this strategy. 400 [Multipath-3GPP-ATSSS] mentioned this strategy at the QUIC Interim 401 meeting. 403 2.3.6. Redundant 405 Traffic is replicated over two or more paths to increase the 406 probability that the traffic will arrive at the other host undamaged 407 and usable. Redundant traffic may be used for all packets in a 408 connection, or may only be used when measured network conditions 409 indicate it should be used. Traffic Splitting is required to support 410 this strategy. [Apple-Multipath] and [Multipath-3GPP-ATSSS] 411 mentioned this strategy at the QUIC Interim meeting, and Yunfei Ma 412 confirmed in e-mail that [Alibaba-MPQUIC] also uses this strategy. 414 2.3.7. Combinations of Strategies 416 As [I-D.bonaventure-iccrg-schedulers] points out, a scheduler can use 417 a combination of strategies in sending decisions. For example, a 418 scheduler might use load-balancing over three paths, but when one of 419 the paths becomes unavailable, might switch to the two paths that are 420 still available. 422 As Lucas Pardue pointed out in e-mail, some strategies may 423 differentiate between "control plane" and "data plane" path 424 selection. For example, an application might send stream data over 425 one or more paths, but might send ACK traffic or retransmissions over 426 a specific path, especially if the path characteristics vary 427 significantly, as would be the case for satellite uplink/downlink 428 stations connected by both higher-bandwidth Low Earth Orbit satellite 429 paths and lower-bandwidth cellular or landline paths. 431 2.4. Unified Field Theory of Path Selection 433 The strategies in Section 2.3 don't include all possible strategies, 434 and it's worth noting that few of the presentations given at 435 [QUIC-interim-20-10] shared a common set of even two or three 436 strategies. Even [Multipath-3GPP-ATSSS] omitted some strategies 437 under consideration in 3GPP because they were closely tied to 5G 438 network architecture components. 440 It will be very helpful if we can look for a small number of simple 441 concepts that would allow a small number of schedulers to meet most 442 application requirements. The alternative - adding schedulers every 443 time someone thinks of a new strategy - is too painful to 444 contemplate. 446 3. IANA Considerations 448 This document does not make any request to IANA. 450 4. Security Considerations 452 QUIC-specific security considerations are discussed in Section 21 of 453 [I-D.ietf-quic-transport]. 455 Section 6 of [I-D.ietf-quic-datagram] discusses security 456 considerations specific to the use of the Unreliable Datagram 457 Extension to QUIC. 459 Some multipath QUIC-specific security considerations can be found in 460 Section 8 of the individual draft [I-D.deconinck-quic-multipath]. 462 5. Acknowledgements 464 I'd like to thank Lars Eggert and Lucas Pardue, the QUIC working 465 group chairs, who called the QUIC virtual interim meeting on 466 multipath. 468 I'd also like to thank the presenters at the QUIC virtual interim, 469 who put together valuable presentations on short notice. 471 Thanks to David Allan, for comments resulting in the clarification of 472 Traffic Steering, Traffic Switching, and Traffic Splitting when these 473 concepts are used in contexts outside 3GPP. 475 Thanks again to Lucas, for providing comments resulting in several 476 clarifications on the mapping of Traffic Splitting onto QUIC protocol 477 operation, and for providing comments about control plane/data plane 478 considerations. 480 Thanks to Markus Amend, for providing contributions and spotting a 481 whopper of a typo. 483 Thanks to Yunfei Ma for reviewing my characterization of 484 [Alibaba-MPQUIC]. 486 Thanks to Joerg Deutschmann for reviewing my characterization of 487 [Sat-Terr-Multipath]. 489 Thanks to Christian Huitema for suggesting that we try to simplify 490 the large and growing number of strategies described in Section 2.3 491 into a few simple concepts. This question should come up in QUIC 492 working group discussion of multipath, and will be added to 493 [I-D.dawkins-quic-multipath-questions] so the author doesn't forget 494 that. 496 Many thanks to (your name could easily appear here) for reviews and 497 comments. 499 6. Document History 501 (Note to RFC Editor - if this document ever reaches you, please 502 remove this section) 504 Version -00: initial submission 506 Version -01: updated for IETF 109 QUIC working group session 508 Version -02: Updated to add details about end-to-end and tunneling 509 usages 511 7. Informative References 513 [Alibaba-MPQUIC] 514 Yanmei Lei / Yunfei Ma, ., "MPQIIC Use Cases", October 515 2020, . 518 [Apple-Multipath] 519 Christoph Paasch, ., "Multipath transports at Apple", 520 October 2020, . 524 [Chromium-Multipath] 525 Fan Yang/Jana Iyengar, ., "Multipath in Chromium", October 526 2020, . 529 [Hybrid-Access-Multipath] 530 Olivier Bonaventure, ., "Hybrid access networks and 531 requirements on MPQUIC", October 2020, 532 . 536 [I-D.amend-iccrg-multipath-reordering] 537 Amend, M. and D. Hugo, "Multipath sequence maintenance", 538 draft-amend-iccrg-multipath-reordering-01 (work in 539 progress), November 2020. 541 [I-D.bonaventure-iccrg-schedulers] 542 Bonaventure, O., Piraux, M., Coninck, Q., Baerts, M., 543 Paasch, C., and M. Amend, "Multipath schedulers", draft- 544 bonaventure-iccrg-schedulers-01 (work in progress), 545 September 2020. 547 [I-D.bonaventure-quic-atsss-overview] 548 Boucadair, M., Bonaventure, O., Piraux, M., Coninck, Q., 549 Dawkins, S., Kuehlewind, M., Amend, M., Kassler, A., An, 550 Q., Keukeleire, N., and S. Seo, "3GPP Access Traffic 551 Steering Switching and Splitting (ATSSS) - Overview for 552 IETF Participants", draft-bonaventure-quic-atsss- 553 overview-00 (work in progress), May 2020. 555 [I-D.dawkins-quic-multipath-questions] 556 Dawkins, S., "Questions for Multiple Paths In QUIC", 557 draft-dawkins-quic-multipath-questions-00 (work in 558 progress), December 2020. 560 [I-D.deconinck-quic-multipath] 561 Coninck, Q. and O. Bonaventure, "Multipath Extensions for 562 QUIC (MP-QUIC)", draft-deconinck-quic-multipath-06 (work 563 in progress), November 2020. 565 [I-D.ietf-quic-datagram] 566 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 567 Datagram Extension to QUIC", draft-ietf-quic-datagram-01 568 (work in progress), August 2020. 570 [I-D.ietf-quic-transport] 571 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 572 and Secure Transport", draft-ietf-quic-transport-33 (work 573 in progress), December 2020. 575 [Multipath-3GPP-ATSSS] 576 Spencer Dawkins / Mirja Kuehlewind / Florin Baboescu / 577 Hannu Flinck, ., "Multipath in 3GPP ATSSS", October 2020, 578 . 581 [QUIC-charter] 582 "IETF QUIC Working Group Charter", n.d., 583 . 585 [QUIC-interim-20-10] 586 "IETF QUIC Working Group Virtual Interim Meeting - October 587 2020", October 2020, . 590 [QUIC-interim-20-10-minutes] 591 "IETF QUIC Working Group Virtual Interim Meeting - October 592 2020 - Minutes", October 2020, . 595 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 596 RFC 793, DOI 10.17487/RFC0793, September 1981, 597 . 599 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 600 Paasch, "TCP Extensions for Multipath Operation with 601 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 602 2020, . 604 [Sat-Terr-Multipath] 605 Joerg Deutschmann, ., "Satellite/Terrestrial Multipath 606 Communication", October 2020, . 610 [TS23501] 3GPP (3rd Generation Partnership Project), ., "Technical 611 Specification Group Services and System Aspects; System 612 Architecture for the 5G System; Stage 2 (Release 16)", 613 2019, . 616 Author's Address 618 Spencer Dawkins (editor) 619 Tencent America 621 Email: spencerdawkins.ietf@gmail.com