idnits 2.17.1 draft-dawkins-quic-multipath-questions-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 (January 17, 2021) is 1194 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 (-07) exists of draft-deconinck-quic-multipath-06 == 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-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-33 == Outdated reference: A later version (-04) exists of draft-liu-multipath-quic-02 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 4 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 17, 2021 5 Expires: July 21, 2021 7 Questions for Multiple Paths In QUIC 8 draft-dawkins-quic-multipath-questions-01 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, and so had different 26 assumptions about how applications might use QUIC over multiple 27 paths. 29 This document is intended to capture questions that have come up in 30 discussions, with some suggested answers, to inform further 31 discussion in the working group. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 21, 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. A 2500-year Side Trip . . . . . . . . . . . . . . . . . . 3 69 1.2. Back to the Introduction . . . . . . . . . . . . . . . . 4 70 1.3. Notes for Readers . . . . . . . . . . . . . . . . . . . . 4 71 1.4. Contribution and Discussion Venues for this draft. . . . 5 72 2. Metaquestions About QUIC Multipath . . . . . . . . . . . . . 5 73 2.1. MQ-Need Do We Need Multipath in QUIC? . . . . . . . . . . 5 74 2.2. MQ-Have Do We Already Have Multipath in QUIC? . . . . . . 6 75 3. Questions about Multipath in QUIC . . . . . . . . . . . . . . 6 76 3.1. Q-HowMany Is There One "Multipath"? . . . . . . . . . . . 6 77 3.2. Q-Transport Do Transport Protocols Need to Support 78 Multipath? . . . . . . . . . . . . . . . . . . . . . . . 7 79 3.3. Q-HTTP3 Does Multipath for QUIC Imply Multipath for 80 HTTP/3-QUIC? . . . . . . . . . . . . . . . . . . . . . . 8 81 3.4. Q-Symmetric Do Applications Need Symmetric Multipath 82 QUIC? . . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 3.5. Q-Reorder What are the Expectations about Reordering? . . 9 84 3.6. Q-CB How Will We Measure the Benefits and Costs of 85 Multipath? . . . . . . . . . . . . . . . . . . . . . . . 10 86 3.7. Q-Goals What Are the Goals for using Multiple Paths? . . 10 87 3.8. Q-API What are the API Considerations for Multipath? . . 11 88 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 90 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 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, which continued on the QUIC working group 111 mailing list and at IETF 109 [QUIC-IETF-109-minutes], it became 112 obvious that people had a variety of ideas about how multiple paths 113 would be used, because they weren't looking at the same use cases, 114 and so had different assumptions about how QUIC applications might 115 use multiple paths. 117 This document is intended to capture questions that have come up in 118 discussions, with some suggested answers, to inform further 119 discussion in the working group. 121 1.1. A 2500-year Side Trip 123 The story that might have been titled "The People Unable to See and 124 the Elephant" [Elephant-By-Touch] in 2021, is from the Indian 125 subcontinent, and is at least 2500 years old (it is recorded in the 126 Buddhist text Udana 6.4 [Udana-6-4]). The story, which has spread 127 widely throughout the world, is about people unable to see, who are 128 brought before the king, and shown an elephant - but they only 129 touched the part of the elephant they were each standing in front of, 130 and then began to argue about what an elephant was like (in 131 [Udana-6-4]. Their descriptions were that "an elephant is like" a 132 jar, a basket, a plowshare, the pole of a plow, a granary, a post, a 133 mortar, a pestle, or a broom. 135 None were completely wrong (they had their hands on the part of the 136 elephant they were right about), but none were completely right, 137 either (an elephant was more than the parts they hand their hands 138 on). And the king pointed to the monks of different sects who had 139 been arguing about the teachings of the Buddha, and said, "they keep 140 on arguing, quarreling, and disputing, wounding one another with 141 weapons of the mouth, saying, 'The teaching is like this, it's not 142 like that. The teaching is not like that, it's like this.'" 144 1.2. Back to the Introduction 146 Let us turn our attention from "describing an elephant", to 147 "describing what multiple paths in QUIC might mean", 149 o the QUIC working group virtual interim meeting minutes on 150 multipath at [QUIC-interim-20-10-minutes], which include pointers 151 to the video recording from the meeting, pointers to each 152 presentation given, questions and answers after each presentation, 154 o discussion that continued following the virtual interim meeting 155 the QUIC working group mailing list, and 157 o discussion during the QUIC working group session at IETF 109 158 [QUIC-IETF-109-minutes]. 160 We are not unable to see the parts of QUIC over multiple paths that 161 we have touched, but we can't agree on the shape of multipath for 162 QUIC without understanding what other people are touching. 164 1.3. Notes for Readers 166 It cannot be emphasized enough that multiple proposals for "QUIC 167 multipath" have been submitted to the IETF (at a minimum, 168 [I-D.deconinck-quic-multipath], [I-D.an-multipath-quic] and 169 [I-D.an-multipath-quic-application-policy], [I-D.liu-multipath-quic], 170 and [I-D.huitema-quic-mpath-option]). In this document, "QUIC 171 multipath" means only "QUIC using multiple paths", and draws from the 172 discussion in the QUIC working group mailing list, some of which has 173 been guided by one or more of the current proposals. 175 This document does reuse some terminology from [I-D.dawkins-quic- 176 what-to-do-with-multipath}}, especially "Traffic Switching" and 177 "Traffic Splitting", which are summarized in Section 3.2. 179 This document is an informational Internet-Draft, not adopted by any 180 IETF working group, and does not carry any special status within the 181 IETF. 183 Please note well that this document reflects the author's current 184 understanding of working group discussions. It is likely that there 185 are more questions than currently included in the document, and it is 186 even more likely that some of the suggested answers are incomplete or 187 (unlike the people in Section 1.1) completely wrong. Contributions 188 that add or improve questions and answers, or suggest improvements 189 and clarifications, are welcomed, as described in Section 1.4. 191 1.4. Contribution and Discussion Venues for this draft. 193 (Note to RFC Editor - if this document ever reaches you, please 194 remove this section) 196 This document is under development in the Github repository at 197 https://github.com/SpencerDawkins/draft-dawkins-quic-multipath- 198 questions. Readers are invited to open issues and send pull requests 199 with contributed text for this document, but since the document is 200 intended to guide discussion for the QUIC working group, substantial 201 discussion of this document should take place on the QUIC working 202 group mailing list (quic@ietf.org). Subscription and archive details 203 are at https://www.ietf.org/mailman/listinfo/quic. 205 2. Metaquestions About QUIC Multipath 207 We've had considerable discussion about the details of multipath 208 implementation in QUIC, but it's worth starting out with a couple of 209 metaquestions: 211 o Do we need multipath in QUIC? (see Section 2.1) 213 o Do we already have multipath in QUIC? (see Section 2.2) 215 2.1. MQ-Need Do We Need Multipath in QUIC? 217 The most compelling explanation of the point of view that we don't 218 need multipath is likely the [Chromium-Multipath] presentation given 219 at [QUIC-interim-20-10]. The short summary of this presentation was 220 that Google had included multipath in planning for their gQUIC 221 implementation, but subsequently stopped working on this, choosing 222 instead to focus on making connection migration work, given that this 223 was what customers were asking for. 225 As of the date of [QUIC-interim-20-10], few if any implementations 226 were using connection migration, which was defined in 227 [I-D.ietf-quic-transport]. So there was a well-supported point of 228 view that the right thing to do was to get deployment experience with 229 connection migration, and then see what use cases remain that could 230 not be supported using connection migration. 232 Suggested answer to MQ-01: "Maybe". 234 2.2. MQ-Have Do We Already Have Multipath in QUIC? 236 We noted in discussions that [I-D.ietf-quic-transport] allows an 237 implementation to open two or more connections on different paths, 238 verify the paths, and even probe to ensure that a path is still valid 239 before migrating from one connection to another. When an 240 implementation does this proactively, there is no connection 241 establishment delay when the implementation migrates from one path to 242 another. So it's a reasonable question to ask, "do we already have 243 multipath support in QUIC?" 245 For some applications, yes, but this is highly application-dependent. 247 The key point in discussion was that this level of support allows 248 rapid migration from one path to another (what 249 [I-D.dawkins-quic-what-to-do-with-multipath] calls "traffic 250 switching"}, but does not allow sustained simultaneous use of 251 multiple paths (what [I-D.dawkins-quic-what-to-do-with-multipath] 252 calls "traffic splitting"). 254 Even for traffic switching, the QUIC implementation does not know the 255 capacity of the path that the connection migrates to, and must learn 256 it, and this means that a successful connection migration can lead to 257 a detectable difference in performance if the migrated-from 258 connection was carrying a significant amount of traffic. 260 Suggested answer to MQ-02: "For applications that perform traffic 261 switching, possibly so. For applications that perform traffic 262 splitting, no". 264 3. Questions about Multipath in QUIC 266 Once discussion moves beyond the metaquestions in Section 2, 267 questions remain. 269 Please note that this document only includes high-level questions. 270 There have also been discussions about topics like whether a single 271 sequence number space is shared across paths, etc. These questions 272 aren't included in this document, even though they're important. 274 3.1. Q-HowMany Is There One "Multipath"? 276 Based on mailing list discussion, the answer is almost certainly 277 "No". "Multipath" is at best an umbrella term covering a variety of 278 use cases that can make use of multiple paths in a variety of ways, 279 to accomplish a variety of goals. Some examples are listed in 280 Section 3.7. 282 If an application can use connections over multiple paths 283 independently from each other, the application could possibly make 284 use of multiple paths, without any "multipath" support in QUIC at 285 all. But this is highly application-dependent. 287 We noted that there are many strategies for using multiple paths 288 (some, but certainly not all, described in 289 [I-D.dawkins-quic-what-to-do-with-multipath]). It's worth also 290 noting that these strategies may not have much in common with each 291 other. There are use cases that expect to move from path to path, 292 depending on the relative financial costs of those paths. Other use 293 cases expect to move from path to path depending on the measured RTT 294 of each path, picking a path with the lowest measured RTT. Still 295 others may expect to use multiple paths for a single connection, if 296 the measured path characteristics are "sufficiently similar" to each 297 other. 299 Suggested answer to Q-HowMany: "It's not clear that one multipath 300 scheduler can support all of these use cases". 302 3.2. Q-Transport Do Transport Protocols Need to Support Multipath? 304 This question seems to revolve around two sub-questions: 306 o Whether we can identify use cases with enough in common with each 307 other to reuse a single scheduler, whether or not there are other 308 use cases that need different schedulers. 310 From a code reuse perspective, we note that multipath is complicated 311 enough to get right that depending on applications to get multipath 312 right isn't desirable, although it's unavoidable. One reason QUIC 313 was originally chartered to do multipath was because we noticed that 314 both TCP [RFC0793] and SCTP [RFC4960] were retrofitted with support 315 for some aspects of multipath operation ([RFC8684] added multipath 316 support for TCP, and [RFC5061] added fast failover to another path 317 for SCTP). 319 o Whether we think there are enough use cases that don't rely on 320 application-specific awareness to make scheduling decisions. 322 We have been successful when we've included Traffic Switching in 323 transport protocols, but we've only been successful including Traffic 324 Splitting in transport protocols when relevant path characteristics 325 have been similar between various paths, and the use case involved 326 traffic that didn't require the transport to distinguish between 327 different types of application-level information when selecting an 328 appropriate path. If an application wants to send some types of 329 video frames over one path and other types over a different path, 330 that's not going to be easy to do using a general-purpose transport 331 mechanism. And while the Internet is more than the World Wide Web, 332 we noted that the World Wide Web has been moving away from bulk 333 transfers for some time, so that user-perceived latency matters much 334 more than bandwidth utilization. 336 Suggested answer to Q-Transport: "Maybe. But it's important to have 337 realistic expectations. We will likely end up with multiple 338 schedulers, and we may very well end up with applications that can't 339 use any of the schedulers we describe, and have to handle multiple 340 paths on their own". 342 3.3. Q-HTTP3 Does Multipath for QUIC Imply Multipath for HTTP/3-QUIC? 344 [QUIC-charter] has focused on supporting HTTP since the working group 345 was chartered in 2016. Although it is certainly possible for 346 applications to use [I-D.ietf-quic-transport] as their interface to 347 the QUIC protocol, that's not what most applications we have 348 implementation and deployment experience with have used, and the 349 recent discussions in the MASQUE working group [MASQUE-charter] has 350 pointed towards reusing HTTP/3, even for a tunneling and proxying 351 application that may not make much use of HTTP beyond connection set- 352 up. Some use cases include tunneling, so are reasonable candidates 353 to use HTTP/3 to set up MASQUE tunnels anyway. 355 Suggested answer to Q-HTTP3: "Probably so, especially if the goal is 356 to provide a multipath capability for QUIC without duplicating 357 testing that has already been carried out at scale for HTTP/3". 359 3.4. Q-Symmetric Do Applications Need Symmetric Multipath QUIC? 361 The QUIC transport protocol is so closely tied to HTTP/3 that both 362 [I-D.ietf-quic-transport] and [I-D.ietf-quic-http] were specified in 363 the same working group ([QUIC-charter]), and one result of this close 364 relationship is that QUIC is an asymmetric client-server transport 365 protocol, not a symmetric "host to host" transport protocol. Each 366 connection is initiated by a client endpoint, sending to a server 367 endpoint. 369 This is a very reasonable architecture, for a transport protocol 370 targeting use by HTTP, a client-server application protocol, and this 371 fits well into the current Internet architecture, which (for better 372 or worse) includes middleboxes that enforce this directionality. 373 These middleboxes include firewalls that force communications to be 374 initiated from "inside" a network perimeter, which works fine when 375 the goal is to provide clients "inside" access to servers "outside", 376 and Network Address Translators often enforce similar restrictions, 377 so that a packet arriving at the NAT from an unassigned address 378 "inside" the network will be bound to an address "outside" the 379 network, but a packet arriving from an unassigned address "outside" 380 the network will simply be dropped. 382 If HTTP/3 is the driving use case for QUIC multipath, the client- 383 server nature of the QUIC transport protocol is fine. If the goal is 384 to support other applications, especially bidirectional application 385 protocols, we need to think about this in more detail. 387 We noted that QUIC connection migration isn't entirely client-server 388 - a server can send the client a preferred_address transport 389 parameter during the initial handshake. This capability is limited, 390 in that it can only happen once, early in the life of a connection, 391 and the client might not actually migrate to the preferred address. 392 Even if the server does want to migrate the connection, often the 393 client must be the one to initiate that communication because of the 394 previously noted middlebox constraints. 396 Suggested answer for Q-Symmetric: "Need a clearer understanding of 397 the applications that will make use of QUIC multipath, in order to 398 know this". 400 3.5. Q-Reorder What are the Expectations about Reordering? 402 We've had at least two starting points for people in these 403 discussions - one that expects traffic to be delivered in-order to 404 applications, and one that expects applications to handle their own 405 out-of-order delivery, since the sending application needs to track 406 what's actually being delivered, including being delivered 407 significantly out of order, in order to select a path more 408 effectively. 410 For latency-sensitive applications, it's likely that out-of-order 411 delivery across paths is something the application would want to be 412 aware of. And it's worth noting that we're chatting about the 413 desirability of reliable streams, versus partially reliable streams, 414 versus datagrams, in at least a couple of use cases, and partial 415 reliability isn't part of streams in [I-D.ietf-quic-transport], so if 416 we think partially reliable streams are the right answer, there's 417 still some specification work to do. 419 It's also worth mentioning that repair strategies for reordering 420 across multiple paths may be closer to research than to engineering. 421 Some helpful perspectives are provided in 422 [I-D.amend-iccrg-multipath-reordering]. 424 Suggested answer for Q-Reorder: "Answer unclear". 426 3.6. Q-CB How Will We Measure the Benefits and Costs of Multipath? 428 This has come up most often in private conversations, but I've heard 429 concerns about our ability to measure whether we are making the best 430 use of multiple paths at scale, in a reproducible way. 432 It seems obvious that this question is important, and while it may be 433 early in the process to expect a detailed answer, this question is 434 recorded in this document so that we don't lose track of it. 436 Suggested answer for Q-CB: "Please check back later". 438 3.7. Q-Goals What Are the Goals for using Multiple Paths? 440 At least one point of view is that different use cases have different 441 goals. Some goals that were shared in the QUIC multipath virtual 442 interim ((QUIC-interim-20-10}} include 444 o to migrate from one path to another, possibly because a path has 445 stopped working, or because a "better" path becomes available. 447 o using all available bandwidth between two endpoints, across 448 multiple paths. 450 o minimizing latency for the best possible user experience, 451 especially for page loads on the Web. 453 o maximizing reliability of specific traffic, by transmitting the 454 same traffic on multiple paths, either at all times or at specific 455 times, such as "when radio signals are fading". 457 Other goals certainly exist, including goals described in 458 [I-D.an-multipath-quic-application-policy] and 459 [I-D.bonaventure-iccrg-schedulers], and it's likely that even this 460 set doesn't include all possible strategies. It's also worth noting 461 that few of the presentations given at [QUIC-interim-20-10] shared a 462 common set of even two or three strategies. 464 Note that actual use cases may be more nuanced about their goals - 465 for instance, sending low-latency traffic over the lowest-latency 466 path, and then using all remaining available bandwidth across all 467 paths for other traffic. 469 It will be very helpful if we can look for a small number of simple 470 concepts that would allow a small number of schedulers to meet most 471 application requirements. The alternative - adding schedulers every 472 time someone thinks of a new strategy - is too painful to 473 contemplate. 475 Suggested answer for Q-Goals: "We sure hope we can narrow the set of 476 goals down to something manageable". 478 3.8. Q-API What are the API Considerations for Multipath? 480 We've noted a number of times that the most useful features of 481 protocols won't be used if there is no way for an application to use 482 them. 484 HTTP/2 stream priorities [RFC7540] was mentioned frequently, but 485 other features were mentioned. 487 We need a better understanding of the goals (see Section 3.7 to 488 answer this question, but it's included in this document so we don't 489 forget it. 491 Suggested answer for Q-API: "Please check back later". 493 4. IANA Considerations 495 This document does not make any request to IANA. 497 5. Security Considerations 499 QUIC-specific security considerations are discussed in Section 21 of 500 [I-D.ietf-quic-transport]. 502 Section 6 of [I-D.ietf-quic-datagram] discusses security 503 considerations specific to the use of the Unreliable Datagram 504 Extension to QUIC. 506 Some multipath QUIC-specific security considerations can be found in 507 Section 8 of the individual draft [I-D.deconinck-quic-multipath]. 508 The other QUIC multipath proposals named in Section 1.3 have "to be 509 determined" security considerations sections, which is not unusual 510 for individual Internet-Drafts. 512 6. Acknowledgements 514 I'd like to thank Lars Eggert and Lucas Pardue, the QUIC working 515 group chairs, who called the QUIC virtual interim meeting on 516 multipath. 518 I'd also like to thank the presenters at the QUIC virtual interim, 519 who put together valuable presentations on short notice. 521 Mikkel Fahnoee Joergensen, Lars Eggert, and Mike Bishop provided 522 thoughts about symmetrical multipath QUIC that informed Section 3.4. 524 Christian Huitema made a plea for sanity about the number of goals 525 for multipath QUIC, that is now included in Section 3.7. 527 Many thanks to (your name could easily appear here) for reviews and 528 comments. 530 I've been through the QUIC working group archives on multipath 531 discussions, along with the minutes from [QUIC-interim-20-10] and 532 IETF 109 [QUIC-IETF-109-minutes], and too many people have commented 533 in those venues for me to list them all. My apologies for that, but 534 thank you all for contributing. 536 And it's worth noting that the story described in Section 1.1 537 included the people who were trying to describe the elephant beating 538 other people who disagreed with their description. Thanks for not 539 going there in the QUIC working group. 541 7. Informative References 543 [Chromium-Multipath] 544 Fan Yang/Jana Iyengar, ., "Multipath in Chromium", October 545 2020, . 548 [Elephant-By-Touch] 549 "Wikipedia Page for Blind men and an elephant", December 550 2020, 551 . 553 [I-D.amend-iccrg-multipath-reordering] 554 Amend, M. and D. Hugo, "Multipath sequence maintenance", 555 draft-amend-iccrg-multipath-reordering-01 (work in 556 progress), November 2020. 558 [I-D.an-multipath-quic] 559 An, Q., Liu, Y., Ma, Y., and Z. Li, "Multipath Extension 560 for QUIC", draft-an-multipath-quic-00 (work in progress), 561 October 2020. 563 [I-D.an-multipath-quic-application-policy] 564 An, Q., Li, Z., and Y. Liu, "Enabling application policy- 565 awareness in Multipath QUIC", draft-an-multipath-quic- 566 application-policy-00 (work in progress), July 2020. 568 [I-D.bonaventure-iccrg-schedulers] 569 Bonaventure, O., Piraux, M., Coninck, Q., Baerts, M., 570 Paasch, C., and M. Amend, "Multipath schedulers", draft- 571 bonaventure-iccrg-schedulers-01 (work in progress), 572 September 2020. 574 [I-D.dawkins-quic-what-to-do-with-multipath] 575 Dawkins, S., "What To Do With Multiple Active Paths in 576 QUIC", draft-dawkins-quic-what-to-do-with-multipath-03 577 (work in progress), January 2021. 579 [I-D.deconinck-quic-multipath] 580 Coninck, Q. and O. Bonaventure, "Multipath Extensions for 581 QUIC (MP-QUIC)", draft-deconinck-quic-multipath-06 (work 582 in progress), November 2020. 584 [I-D.huitema-quic-mpath-option] 585 Huitema, C., "QUIC Multipath Negotiation Option", draft- 586 huitema-quic-mpath-option-00 (work in progress), October 587 2020. 589 [I-D.ietf-quic-datagram] 590 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 591 Datagram Extension to QUIC", draft-ietf-quic-datagram-01 592 (work in progress), August 2020. 594 [I-D.ietf-quic-http] 595 Bishop, M., "Hypertext Transfer Protocol Version 3 596 (HTTP/3)", draft-ietf-quic-http-33 (work in progress), 597 December 2020. 599 [I-D.ietf-quic-transport] 600 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 601 and Secure Transport", draft-ietf-quic-transport-34 (work 602 in progress), January 2021. 604 [I-D.liu-multipath-quic] 605 Liu, Y., Ma, Y., Huitema, C., An, Q., and Z. Li, 606 "Multipath Extension for QUIC", draft-liu-multipath- 607 quic-02 (work in progress), December 2020. 609 [MASQUE-charter] 610 "IETF MASQUE Working Group Charter", June 2020, 611 . 613 [QUIC-charter] 614 "IETF QUIC Working Group Charter", n.d., 615 . 617 [QUIC-IETF-109-minutes] 618 "IETF QUIC Working Group IETF 109 Meeting - November 2020 619 - Minutes", n.d., 620 . 622 [QUIC-interim-20-10] 623 "IETF QUIC Working Group Virtual Interim Meeting - October 624 2020", October 2020, . 627 [QUIC-interim-20-10-minutes] 628 "IETF QUIC Working Group Virtual Interim Meeting - October 629 2020 - Minutes", n.d., . 632 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 633 RFC 793, DOI 10.17487/RFC0793, September 1981, 634 . 636 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 637 RFC 4960, DOI 10.17487/RFC4960, September 2007, 638 . 640 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 641 Kozuka, "Stream Control Transmission Protocol (SCTP) 642 Dynamic Address Reconfiguration", RFC 5061, 643 DOI 10.17487/RFC5061, September 2007, 644 . 646 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 647 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 648 DOI 10.17487/RFC7540, May 2015, 649 . 651 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 652 Paasch, "TCP Extensions for Multipath Operation with 653 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 654 2020, . 656 [Udana-6-4] 657 "Udana 6:4 Sectarians (1) (Tittha Sutta)", December 2020, 658 . 660 Author's Address 661 Spencer Dawkins (editor) 662 Tencent America 664 Email: spencerdawkins.ietf@gmail.com