idnits 2.17.1 draft-dawkins-quic-what-to-do-with-multipath-00.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 (November 01, 2020) is 1272 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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-32 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 November 01, 2020 5 Expires: May 5, 2021 7 What To Do With Multiple Active Paths in QUIC 8 draft-dawkins-quic-what-to-do-with-multipath-00 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 May 5, 2021. 47 Copyright Notice 49 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Notes for Readers . . . . . . . . . . . . . . . . . . . . 3 66 1.2. Contribution and Discussion Venues for this draft. . . . 3 67 2. Multicast Modes of Operation . . . . . . . . . . . . . . . . 4 68 2.1. Reference Architecture . . . . . . . . . . . . . . . . . 4 69 2.2. Forwarding When Multiple Paths Are Available . . . . . . 4 70 2.2.1. Traffic Steering . . . . . . . . . . . . . . . . . . 4 71 2.2.2. Traffic Switching . . . . . . . . . . . . . . . . . . 5 72 2.2.3. Traffic Splitting . . . . . . . . . . . . . . . . . . 5 73 2.2.4. Traffic Steering, Traffic Switching, and Traffic 74 Splitting in the Core QUIC Transport Protocol . . . . 5 75 2.3. Forwarding Strategies with Multiple Paths . . . . . . . . 5 76 2.3.1. Bandwidth Aggregation . . . . . . . . . . . . . . . . 6 77 2.3.2. Trading Latency Versus Bandwidth . . . . . . . . . . 6 78 2.3.3. RTT Difference . . . . . . . . . . . . . . . . . . . 6 79 2.3.4. Active-Standby . . . . . . . . . . . . . . . . . . . 6 80 2.3.5. Load-Balancing . . . . . . . . . . . . . . . . . . . 7 81 2.3.6. Priority-based . . . . . . . . . . . . . . . . . . . 7 82 2.3.7. Redundant . . . . . . . . . . . . . . . . . . . . . . 7 83 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 84 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 85 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 86 6. Document History . . . . . . . . . . . . . . . . . . . . . . 8 87 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 The IETF QUIC working group has been chartered to produce extensions 93 that would "enable ... multipath capabilities" ([QUIC-charter]) since 94 the working group was formed in 2016, but because multipath was an 95 extension, work on multipath, and the other extensions named in the 96 charter, waited while work proceeded on the core QUIC protocol 97 specifications ([I-D.ietf-quic-transport] and related 98 specifications). 100 After the QUIC working group chairs requested publication for the 101 core QUIC protocol specifications, they scheduled a virtual interim 102 meeting ([QUIC-interim-20-10]) to understand the use cases that 103 various groups inside and outside the IETF were envisioning for 104 multipath with QUIC. 106 As part of that discussion, it became obvious that people had a 107 variety of ideas about how multiple paths would be used, because they 108 weren't looking at the same use cases. 110 This document is intended to capture that variety of ideas, to inform 111 further discussion in the working group. 113 For more details, please see the QUIC working group meeting minutes, 114 at [QUIC-interim-20-10-minutes], which include pointers to the video 115 recording from the meeting, pointers to each presentation given, 116 questions and answers after each presentation, and overall discussion 117 following the presentations. 119 1.1. Notes for Readers 121 This document is an informational Internet-Draft, not adopted by any 122 IETF working group, and does not carry any special status within the 123 IETF. 125 It reflects the author's understanding, and contributions that 126 include improvements and clarifications are welcomed, as described in 127 Section 1.2. 129 1.2. Contribution and Discussion Venues for this draft. 131 (Note to RFC Editor - if this document ever reaches you, please 132 remove this section) 134 This document is under development in the Github repository at 135 https://github.com/SpencerDawkins/draft-dawkins-quic-what-to-do-with- 136 multipath. Readers are invited to open issues and send pull requests 137 with contributed text for this document. 139 Substantial discussion of this document should take place on the QUIC 140 working group mailing list (quic@ietf.org). Subscription and archive 141 details are at https://www.ietf.org/mailman/listinfo/quic. 143 2. Multicast Modes of Operation 145 For the purposes of this document, it's enough to consider two QUIC 146 endpoints (QUIC Host X and QUIC Host Y) with two disjoint paths 147 between them (Access Net A and Access Net B), as shown in Figure 1. 149 2.1. Reference Architecture 151 ------------ 152 / \ 153 +-------| Access Net A |--+ 154 | \ / | 155 | ------------ | 156 +---+--+ | +------+ 157 | QUIC | +--------| QUIC | 158 } Host | | Host | 159 | X | +--------| Y | 160 +---+--+ | +------+ 161 | ------------ | 162 | / \ | 163 +-------| Access Net B |--+ 164 \ / 165 ------------ 167 Figure 1: Simplified Reference Architecture for QUIC Multipath 168 Operation 170 More than two paths are certainly possible - for example, two hosts 171 that are connected by a satellite uplink/downlink path, and two 172 different landline paths from different network providers. But I 173 believe this simplified architecture is sufficient for discussion 174 purposes. 176 2.2. Forwarding When Multiple Paths Are Available 178 This section uses terminology from 3GPP ATSSS {Access Traffic 179 Steering, Switch and Splitting, [TS23501]) to describe three 180 different patterns of packer forwarding that are applicable when 181 multiple disjoint paths are available. Note that these terms 182 describe concepts that are not ATSSS-specific, and could apply to any 183 multipath environment. If terminology more accessible to IETF QUIC 184 working group participants presents itself, I'll change it. 186 2.2.1. Traffic Steering 188 When a sending host has more than one path available, a sending host 189 will select a path to begin forwarding packets on. This can be 190 described as Traffic Steering. 192 2.2.2. Traffic Switching 194 When a sending host has more than one path available and is using a 195 single path, the sending host can stop using this path, and start 196 using another path. This can be described as Traffic Switching. 198 2.2.3. Traffic Splitting 200 When a sending host has more than one path available, the sending 201 host may wish to use both paths simultaneously. This can be 202 described as Traffic Splitting. 204 2.2.4. Traffic Steering, Traffic Switching, and Traffic Splitting in 205 the Core QUIC Transport Protocol 207 [I-D.ietf-quic-transport] and related specifications support the 208 selection and use of multiple paths between QUIC endpoints, as long 209 as only one path is in active use at any given time. 210 [I-D.ietf-quic-transport] and related specifications do not support 211 forwarding traffic for a single connection on multiple paths between 212 QUIC endpoints simultaneously. 214 This level of support for multipath allows Traffic Steering - the 215 selection of a specific path - and Traffic Switching - migration of 216 traffic from one path to another, using QUIC connection migration. 217 It does not allow "Traffic Splitting - the use of simultaneous paths 218 for a single connection, except for unordered datagram traffic 219 [I-D.ietf-quic-datagram]. 221 One important output from the QUIC interim meeting was the 222 recognition that "Traffic Switching" can be accomplished with much 223 more agility than some participants recognized - if you open and 224 validate two or more connections, no additional setup or signaling is 225 required for a sender to switch paths - that can begin with the next 226 packet queued for transmission. 228 2.3. Forwarding Strategies with Multiple Paths 230 During the QUIC virtual interim meeting, various presenters described 231 various forwarding strategies that they have used in the past 232 (especially with TCP [RFC0793] and Multipath TCP [RFC8684]). and that 233 they expected to use in the future with some multipath QUIC 234 extension. 236 This section is an attempt to identify commonalities and gaps that 237 may inform work on future multipath extensions for QUIC. 239 All of these forwarding strategies build on Traffic Steering - 240 opening one or more connections, and then proceeding to use one 241 connection, switch to another connection, or split traffic across 242 paths. For this reason, Traffic Steering isn't mentioned in the rest 243 of this section. 245 2.3.1. Bandwidth Aggregation 247 Some environment allow the use of multiple paths simultaneously for 248 significant periods of time, because none of the paths are metered, 249 so using all of the bandwidth on all of the paths simultaneously 250 makes sense. Traffic Splitting is required to support this strategy. 251 [Alibaba-MPQUIC] mentioned this strategy at the QUIC Interim Meeting. 253 2.3.2. Trading Latency Versus Bandwidth 255 Some applications require low latency, and others don't. So using a 256 network path with lower latency for some connections, and using a 257 different network path with higher bandwidth available for others. 258 allows this strategy. Traffic Switching is sufficient for this, if 259 measured path characteristics change enough to justify changing 260 paths. [Chromium-Multipath] mentioned this strategy at the QUIC 261 Interim Meeting. [Apple-Multipath] is actually switching paths at 262 sub-RTT rates. 264 2.3.3. RTT Difference 266 Not all multipath environments include paths with significant 267 differences between path characteristics, but several do. If two or 268 more paths have characteristics that are "sufficiently close" - for 269 example, they may have path RTTs that are equivalent, from the 270 application's point of view - a sender may wish to use both paths as 271 long as that's the case, and then adopt another forwarding strategy 272 when measured path characteristics diverge. Traffic Splitting is 273 required to support this strategy. [Apple-Multipath], 274 [Sat-Terr-Multipath].[Hybrid-Access-Multipath], and 275 [Multipath-3GPP-ATSSS] all mentioned this strategy at the QUIC 276 Interim Meeting. 278 2.3.4. Active-Standby 280 The traffic associated with a specific flow will be forwarded via a 281 specific path (the 'active path') and switched to another path 282 (called 'standby path') when the active access is unavailable. 283 Traffic Switching is sufficient to support this strategy. 284 [Multipath-3GPP-ATSSS] mentioned this strategy at the QUIC Interim 285 meeting. 287 2.3.5. Load-Balancing 289 The traffic associated with a specific connection will be distributed 290 among the available paths following a distribution ratio (e.g., 30% 291 via a first access, 70% via a second access). This distribution 292 ratio may be static, or may be adjusted over time, based on measured 293 path characteristics. Traffic Splitting is required to support this 294 strategy. [Multipath-3GPP-ATSSS] mentioned this strategy at the QUIC 295 Interim meeting. 297 2.3.6. Priority-based 299 Paths are assigned priority levels that indicate which path will be 300 used first. Concretely, the traffic associated with the matching 301 flow will be steered on the path with a high priority till congestion 302 is detected, then the overflow will be forwarded over a low priority 303 access. Traffic Splitting is required to support this strategy. 304 [Multipath-3GPP-ATSSS] mentioned this strategy at the QUIC Interim 305 meeting. 307 2.3.7. Redundant 309 Traffic is replicated over two or more paths to increase the 310 probability that the traffic will arrive at the other host undamaged 311 and usable. Redundant traffic may be used for all packets in a 312 connection, or may only be used when measured network conditions 313 indicate it should be used. Traffic Splitting is required to support 314 this strategy. [Multipath-3GPP-ATSSS] mentioned this strategy at the 315 QUIC Interim meeting. 317 3. IANA Considerations 319 This document does not make any request to IANA. 321 4. Security Considerations 323 QUIC-specific security considerations are discussed in Section 21 of 324 [I-D.ietf-quic-transport]. 326 Section 6 of [I-D.ietf-quic-datagram] discusses security 327 considerations specific to the use of the Unreliable Datagram 328 Extension to QUIC. 330 Some multipath QUIC-specific security considerations can be found in 331 Section 8 of the individual draft [I-D.deconinck-quic-multipath]. 333 5. Acknowledgements 335 I'd like to thank Lars Eggert and Lucas Pardue, the QUIC working 336 group chairs, who called the QUIC virtual interim meeting on 337 multipath. 339 I'd also like to thank the presenters at the QUIC virtual interim, 340 who put together valuable presentations on short notice. 342 Many thanks to (your name could easily appear here) for reviews and 343 comments. 345 6. Document History 347 (Note to RFC Editor - if this document ever reaches you, please 348 remove this section) 350 Version -00: initial submission 352 7. Normative References 354 [Alibaba-MPQUIC] 355 Yanmei Lei / Yunfei Ma, ., "MPQIIC Use Cases", October 356 2020, . 359 [Apple-Multipath] 360 Christoph Paasch, ., "Multipath transports at Apple", 361 October 2020, . 365 [Chromium-Multipath] 366 Fan Yang/Jana Iyengar, ., "Multipath in Chromium", October 367 2020, . 370 [Hybrid-Access-Multipath] 371 Olivier Bonaventure, ., "Hybrid access networks and 372 requirements on MPQUIC", October 2020, 373 . 377 [I-D.deconinck-quic-multipath] 378 Coninck, Q. and O. Bonaventure, "Multipath Extensions for 379 QUIC (MP-QUIC)", draft-deconinck-quic-multipath-06 (work 380 in progress), November 2020. 382 [I-D.ietf-quic-datagram] 383 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 384 Datagram Extension to QUIC", draft-ietf-quic-datagram-01 385 (work in progress), August 2020. 387 [I-D.ietf-quic-transport] 388 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 389 and Secure Transport", draft-ietf-quic-transport-32 (work 390 in progress), October 2020. 392 [Multipath-3GPP-ATSSS] 393 Spencer Dawkins / Mirja Kuehlewind / Florin Baboescu / 394 Hannu Flinck, ., "Multipath in 3GPP ATSSS", October 2020, 395 . 398 [QUIC-charter] 399 "IETF QUIC Working Group Charter", n.d., 400 . 402 [QUIC-interim-20-10] 403 "IETF QUIC Working Group Virtual Interim Meeting - October 404 2020", October 2020, . 407 [QUIC-interim-20-10-minutes] 408 "IETF QUIC Working Group Virtual Interim Meeting - October 409 2020 - Minutes", October 2020, . 412 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 413 RFC 793, DOI 10.17487/RFC0793, September 1981, 414 . 416 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 417 Paasch, "TCP Extensions for Multipath Operation with 418 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 419 2020, . 421 [Sat-Terr-Multipath] 422 Joerg Deutschmann, ., "Satellite/Terrestrial Multipath 423 Communication", October 2020, . 427 [TS23501] 3GPP (3rd Generation Partnership Project), ., "Technical 428 Specification Group Services and System Aspects; System 429 Architecture for the 5G System; Stage 2 (Release 16)", 430 2019, . 433 Author's Address 435 Spencer Dawkins (editor) 436 Tencent America 438 Email: spencerdawkins.ietf@gmail.com