idnits 2.17.1 draft-dawkins-quic-what-to-do-with-multipath-02.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 20, 2020) is 1252 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 (-10) exists of draft-ietf-quic-datagram-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-32 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 6 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 November 20, 2020 5 Expires: May 24, 2021 7 What To Do With Multiple Active Paths in QUIC 8 draft-dawkins-quic-what-to-do-with-multipath-02 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 24, 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 87 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 89 6. Document History . . . . . . . . . . . . . . . . . . . . . . 11 90 7. Informative References . . . . . . . . . . . . . . . . . . . 11 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 93 1. Introduction 95 The IETF QUIC working group has been chartered to produce extensions 96 that would "enable ... multipath capabilities" ([QUIC-charter]) since 97 the working group was formed in 2016, but because multipath was an 98 extension, work on multipath, and the other extensions named in the 99 charter, waited while work proceeded on the core QUIC protocol 100 specifications ([I-D.ietf-quic-transport] and related 101 specifications). 103 After the QUIC working group chairs requested publication for the 104 core QUIC protocol specifications, they scheduled a virtual interim 105 meeting ([QUIC-interim-20-10]) to understand the use cases that 106 various groups inside and outside the IETF were envisioning for 107 multipath with QUIC. 109 As part of that discussion, it became obvious that people had a 110 variety of ideas about how multiple paths would be used, because they 111 weren't looking at the same use cases. From an architectural point 112 of view, two main multipath scenarios emerged. The first scenario 113 was envisioned by people who were focused on end-to-end service, and 114 the second scenario was envisioned by people who expected some sort 115 of (explicit) intermediary, such as a transport proxy or tunnel 116 endpoint, between the ultimate endpoints. 118 This document is intended to capture that variety of ideas, to inform 119 further discussion in the working group. 121 For more details, please see the QUIC working group meeting minutes, 122 at [QUIC-interim-20-10-minutes], which include pointers to the video 123 recording from the meeting, pointers to each presentation given, 124 questions and answers after each presentation, and overall discussion 125 following the presentations. 127 1.1. Other Voices 129 This document grew out of discussions in the QUIC working group, but 130 there are other efforts working on multipath in both the IETF and the 131 IRTF, and their work includes mentions of strategies for using 132 multiple paths. I'll add this work as I find it, if that work is 133 proposing a strategy that hasn't been mentioned in the QUIC 134 discussion. In particular, strategies named in 135 [I-D.bonaventure-iccrg-schedulers] have been included in Section 2.3, 136 in the current version of the draft. 138 1.2. Notes for Readers 140 This document is an informational Internet-Draft, not adopted by any 141 IETF working group, and does not carry any special status within the 142 IETF. 144 It reflects the author's understanding, and contributions that 145 include improvements and clarifications are welcomed, as described in 146 Section 1.3. 148 1.3. Contribution and Discussion Venues for this draft. 150 (Note to RFC Editor - if this document ever reaches you, please 151 remove this section) 153 This document is under development in the Github repository at 154 https://github.com/SpencerDawkins/draft-dawkins-quic-what-to-do-with- 155 multipath. Readers are invited to open issues and send pull requests 156 with contributed text for this document. 158 Substantial discussion of this document should take place on the QUIC 159 working group mailing list (quic@ietf.org). Subscription and archive 160 details are at https://www.ietf.org/mailman/listinfo/quic. 162 2. Multipath Modes of Operation 164 For the purposes of this document, it's enough to consider two QUIC 165 endpoints (QUIC Host X and QUIC Host Y) with two disjoint paths 166 between them (Access Net A and Access Net B), as shown in Figure 1. 168 2.1. Reference Architecture 169 ------------ 170 / \ 171 +-------| Access Net A |--+ 172 | \ / | 173 | ------------ | 174 +---+--+ | +------+ 175 | QUIC | +--------| QUIC | 176 } Host | | Host | 177 | X | +--------| Y | 178 +---+--+ | +------+ 179 | ------------ | 180 | / \ | 181 +-------| Access Net B |--+ 182 \ / 183 ------------ 185 Figure 1: Simplified Reference Architecture for QUIC Multipath 186 Operation 188 Some use cases limit themselves to two paths - for example, the use 189 case described in [I-D.bonaventure-quic-atsss-overview] is limited to 190 one 5G 3GPP access network and one non-3GPP access network. More 191 than two paths are certainly possible - for example, two hosts that 192 are connected by a satellite path, and two different landline paths 193 from different network providers for redundancy. But I believe this 194 simplified architecture is sufficient for discussion purposes. 196 Please note: as mentioned in Section 1, some readers will be thinking 197 of an end-to-end QUIC connection between QUIC Host X and QUIC Host Y 198 in Figure 1, while other readers will be thinking of QUIC Host Y as 199 some sort of (explicit) transport proxy or tunnel endpoint, e.g. 200 [I-D.bonaventure-quic-atsss-overview]. This document is only focused 201 on the multiple paths between QUIC Host X and QUIC Host Y, in order 202 to talk about classes of sending and strategies for sending over 203 multiple paths. However, it might be that further implications arose 204 from the motivation of end-to-end multipath or intermediary 205 multipath. In particular the latter will additionally require, 206 according to [I-D.bonaventure-quic-atsss-overview], QUIC datagram 207 (unreliable transport) and tunneling support. While multipath 208 traffic distribution strategies play a central role in multipath 209 transport, multipath re-ordering strategies become additionally 210 important for multipath over unreliable network protocols. Possible 211 strategies to solve this are described in 212 [I-D.amend-iccrg-multipath-reordering]. Another complexitiy, not in 213 scope of this document, is the interaction between multipath 214 scheduling and QUIC stream traffic scheduling. 216 2.2. Sending When Multiple Paths Are Available 218 This section uses terminology from 3GPP ATSSS {Access Traffic 219 Steering, Switch and Splitting, [TS23501]) to describe three 220 different classes of packet sending that could be used when multiple 221 disjoint paths are available. Note that these terms describe 222 concepts that are not ATSSS-specific, and could apply to any 223 multipath environment. If terminology more accessible to IETF QUIC 224 working group participants presents itself, I'll change it. 226 Please note that the relationship between "flows", "packets", and 227 "datagrams" isn't entirely clear yet. In [TS23501], a "flow" is 228 defined as "a set of packets that share an ordering constraint", 229 which maps reasonably well onto TCP bytestreams and correspondingly 230 onto MP-TCP bytestreams, but the core QUIC transport mechanism 231 [I-D.ietf-quic-transport] provides multiple bytesteams in a single 232 connection, and leveraging QUIC streams seems to be a use case 233 enabler, whether for redundantly sending overlapping ranges, for 234 efficiently striping non-overlapping ranges for bandwidth, or for 235 strict ordering. 237 Further, with the QUIC datagram extension [I-D.ietf-quic-datagram], 238 DATAGRAM frames can be carried in a QUIC connection, but are not part 239 of a stream and do not interact with in-order delivery within a 240 stream. 242 2.2.1. Traffic Steering 244 When a sending host has a new "flow", and has more than one path 245 available, a sending host will select a path to begin sending packets 246 on. This can be described as Traffic Steering. 248 Note that the selection of a path is "per-flow". Different flows may 249 be steered onto different paths, but each flow will be sent on a 250 single path. 252 The choice of a path can be based on a number of factors - for 253 instance, whether the path will be used for bulk transfer, or whether 254 an unmetered path is available. Those factors are important, but for 255 this document, the point is that a path is selected. 257 2.2.2. Traffic Switching 259 When a sending host has more than one path available and is sending a 260 flow on a single path, the sending host can stop using this path for 261 this flow, and start using another path. This can be described as 262 Traffic Switching. 264 Note that the selection of another path is also per-flow. A sender 265 can switch a flow onto a different path, without switching any other 266 flows to that path. 268 2.2.3. Traffic Splitting 270 When a sending host has more than one path available, the sending 271 host may wish to use multiple paths simultaneously for a single flow. 272 This can be described as Traffic Splitting. 274 Note that splitting a flow onto multiple paths means that the sending 275 decision would be made on a packet-by-packet basis. No guarantee of 276 packet ordering across paths is assumed. 278 Note that splitting a flow onto multiple paths, packet by packet, 279 means that any ordering constraint must be provided by an upper layer 280 metchanism. In [TS23501], Multipath TCP [RFC8684] is used to provide 281 that ordering constraint. 283 2.2.4. Traffic Steering, Traffic Switching, and Traffic Splitting in 284 the Core QUIC Transport Protocol and Datagram Extension 286 [I-D.ietf-quic-transport] and related specifications support the 287 selection and use of multiple paths for a connection between QUIC 288 endpoints, as long as only one path is in active use at any given 289 time. [I-D.ietf-quic-transport] and related specifications do not 290 support sending traffic for a single connection on multiple paths 291 between QUIC endpoints simultaneously. 293 This level of support for multipath allows Traffic Steering - the 294 selection of a specific path - and Traffic Switching - migration of 295 traffic from one path to another, using QUIC connection migration. 296 It does not allow "Traffic Splitting" - the use of simultaneous paths 297 for a single connection. 299 One important output from the QUIC interim meeting was the 300 recognition that some participants view "Traffic Switching" as 301 something like "protection switching" from an active path to a 302 standby path, that doesn't happen often, while other participants 303 view QUIC connection migration as a way of responding frequently to 304 changing path conditions. This will be an important part of the 305 conversation about multipath QUIC. 307 If a QUIC endpoint opens and validates two or more connections, no 308 additional setup or signaling is required for a sender to switch 309 paths - that can begin with the next packet queued for transmission. 310 This would allow "Traffic Splitting" for unordered QUIC DATAGRAMs 312 [I-D.ietf-quic-datagram], with an upper-layer mechanism providing 313 flow ordering if that is needed. 315 2.3. Sending Strategies with Multiple Paths 317 During the QUIC virtual interim meeting, various presenters described 318 various sending strategies that they have used in the past 319 (especially with TCP [RFC0793] and Multipath TCP [RFC8684]). and that 320 they expected to use in the future with some multipath QUIC 321 extension. 323 This section is an attempt to identify commonalities and gaps that 324 may inform work on future multipath extensions for QUIC. 326 All of these sending strategies build on Traffic Steering - opening 327 one or more connections for a new flow, and then proceeding to use 328 one connection, switch to another connection, or split traffic across 329 paths. For this reason, Traffic Steering isn't mentioned in the rest 330 of this section. 332 2.3.1. Active-Standby 334 The traffic associated with a specific flow will be sent via a 335 specific path (the 'active path') and switched to another path 336 (called 'standby path') when the active access is unavailable. 337 Traffic Switching is sufficient to support this strategy. 338 [Alibaba-MPQUIC] and [Multipath-3GPP-ATSSS] mentioned this strategy 339 at the QUIC Interim meeting. 341 2.3.2. Trading Latency Versus Bandwidth 343 Some applications require low latency, and others don't. So using a 344 network path with lower latency for some connections, and using a 345 different network path with higher bandwidth available for others. 346 allows this strategy. Traffic Switching is sufficient for this, if 347 measured path characteristics change enough to justify changing 348 paths. [Chromium-Multipath] mentioned this strategy at the QUIC 349 Interim Meeting. [Apple-Multipath] is actually switching paths at 350 sub-RTT rates. 352 2.3.3. Bandwidth Aggregation/Load Balancing 354 Some environments allow the use of multiple paths simultaneously for 355 significant periods of time, because none of the paths are metered, 356 so using all of the bandwidth on all of the paths simultaneously 357 makes sense for bulk transfers. Traffic Splitting is required to 358 support this strategy. [Alibaba-MPQUIC], [Hybrid-Access-Multipath], 359 [Sat-Terr-Multipath], and [Multipath-3GPP-ATSSS] all mentioned this 360 strategy at the QUIC Interim Meeting. 361 [I-D.bonaventure-iccrg-schedulers] mentions this strategy as "Round- 362 Robin" (not recommended) and "Weighted Round-Robin". 364 2.3.4. Round-Trip-Time Thresholds, Minimum RTT Difference, and RTT 365 Equivalence 367 Not all multipath environments include paths with significant 368 differences between path characteristics, but several do. 370 A sender might select the first available path with a smoothed round- 371 trip-time below a certain threshold. The goal is to keep the RTT of 372 the multipath connection to a small value and avoid having the whole 373 connection impacted by "bad" paths. 374 [I-D.bonaventure-iccrg-schedulers] mentions this strategy as "Round- 375 Trip-Time Threshold". 377 A sender might select the path with the lowest RTT among all 378 available paths, in order to minimize latency for latency-sensitive 379 flows. [I-D.bonaventure-iccrg-schedulers] mentions this strategy as 380 "Lowest Round-Trip-Time First". 382 If two or more paths have characteristics that are "sufficiently 383 close" - for example, they may have path RTTs that are equivalent, 384 from the application's point of view - a sender may wish to use both 385 paths as long as that's the case, and then adopt another sending 386 strategy when measured path characteristics diverge. Traffic 387 Splitting is required to support this strategy. [Apple-Multipath], 388 [Sat-Terr-Multipath].[Hybrid-Access-Multipath], and 389 [Multipath-3GPP-ATSSS] all mentioned this strategy at the QUIC 390 Interim Meeting. 392 2.3.5. Priority-based 394 Paths are assigned priority levels that indicate which path will be 395 used first. Concretely, the traffic associated with the matching 396 flow will be steered on the path with a high priority till congestion 397 is detected, then the overflow will be sent over a low priority 398 access. Traffic Splitting is required to support this strategy. 399 [Multipath-3GPP-ATSSS] mentioned this strategy at the QUIC Interim 400 meeting. 402 2.3.6. Redundant 404 Traffic is replicated over two or more paths to increase the 405 probability that the traffic will arrive at the other host undamaged 406 and usable. Redundant traffic may be used for all packets in a 407 connection, or may only be used when measured network conditions 408 indicate it should be used. Traffic Splitting is required to support 409 this strategy. [Apple-Multipath] and [Multipath-3GPP-ATSSS] 410 mentioned this strategy at the QUIC Interim meeting. 412 2.3.7. Combinations of Strategies 414 As [I-D.bonaventure-iccrg-schedulers] points out, a scheduler can use 415 a combination of strategies in sending decisions. For example, a 416 scheduler might use load-balancing over three paths, but when one of 417 the paths becomes unavailable, might switch to the two paths that are 418 still available. 420 3. IANA Considerations 422 This document does not make any request to IANA. 424 4. Security Considerations 426 QUIC-specific security considerations are discussed in Section 21 of 427 [I-D.ietf-quic-transport]. 429 Section 6 of [I-D.ietf-quic-datagram] discusses security 430 considerations specific to the use of the Unreliable Datagram 431 Extension to QUIC. 433 Some multipath QUIC-specific security considerations can be found in 434 Section 8 of the individual draft [I-D.deconinck-quic-multipath]. 436 5. Acknowledgements 438 I'd like to thank Lars Eggert and Lucas Pardue, the QUIC working 439 group chairs, who called the QUIC virtual interim meeting on 440 multipath. 442 I'd also like to thank the presenters at the QUIC virtual interim, 443 who put together valuable presentations on short notice. 445 Thanks to David Allan, for comments resulting in the clarification of 446 Traffic Steering, Traffic Switching, and Traffic Splitting when these 447 concepts are used in contexts outside 3GPP. 449 Thanks again to Lucas, for providing comments resulting in several 450 clarifications on the mapping of Traffic Splitting onto QUIC protocol 451 operation. 453 Thanks to Markus Amend, for providing contributions and spotting a 454 whopper of a typo! 455 Many thanks to (your name could easily appear here) for reviews and 456 comments. 458 6. Document History 460 (Note to RFC Editor - if this document ever reaches you, please 461 remove this section) 463 Version -00: initial submission 465 Version -01: updated for IETF 109 QUIC working group session 467 Version -02: Updated to add details about end-to-end and tunneling 468 usages 470 7. Informative References 472 [Alibaba-MPQUIC] 473 Yanmei Lei / Yunfei Ma, ., "MPQIIC Use Cases", October 474 2020, . 477 [Apple-Multipath] 478 Christoph Paasch, ., "Multipath transports at Apple", 479 October 2020, . 483 [Chromium-Multipath] 484 Fan Yang/Jana Iyengar, ., "Multipath in Chromium", October 485 2020, . 488 [Hybrid-Access-Multipath] 489 Olivier Bonaventure, ., "Hybrid access networks and 490 requirements on MPQUIC", October 2020, 491 . 495 [I-D.amend-iccrg-multipath-reordering] 496 Amend, M. and D. Hugo, "Multipath sequence maintenance", 497 draft-amend-iccrg-multipath-reordering-01 (work in 498 progress), November 2020. 500 [I-D.bonaventure-iccrg-schedulers] 501 Bonaventure, O., Piraux, M., Coninck, Q., Baerts, M., 502 Paasch, C., and M. Amend, "Multipath schedulers", draft- 503 bonaventure-iccrg-schedulers-01 (work in progress), 504 September 2020. 506 [I-D.bonaventure-quic-atsss-overview] 507 Boucadair, M., Bonaventure, O., Piraux, M., Coninck, Q., 508 Dawkins, S., Kuehlewind, M., Amend, M., Kassler, A., An, 509 Q., Keukeleire, N., and S. Seo, "3GPP Access Traffic 510 Steering Switching and Splitting (ATSSS) - Overview for 511 IETF Participants", draft-bonaventure-quic-atsss- 512 overview-00 (work in progress), May 2020. 514 [I-D.deconinck-quic-multipath] 515 Coninck, Q. and O. Bonaventure, "Multipath Extensions for 516 QUIC (MP-QUIC)", draft-deconinck-quic-multipath-06 (work 517 in progress), November 2020. 519 [I-D.ietf-quic-datagram] 520 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 521 Datagram Extension to QUIC", draft-ietf-quic-datagram-01 522 (work in progress), August 2020. 524 [I-D.ietf-quic-transport] 525 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 526 and Secure Transport", draft-ietf-quic-transport-32 (work 527 in progress), October 2020. 529 [Multipath-3GPP-ATSSS] 530 Spencer Dawkins / Mirja Kuehlewind / Florin Baboescu / 531 Hannu Flinck, ., "Multipath in 3GPP ATSSS", October 2020, 532 . 535 [QUIC-charter] 536 "IETF QUIC Working Group Charter", n.d., 537 . 539 [QUIC-interim-20-10] 540 "IETF QUIC Working Group Virtual Interim Meeting - October 541 2020", October 2020, . 544 [QUIC-interim-20-10-minutes] 545 "IETF QUIC Working Group Virtual Interim Meeting - October 546 2020 - Minutes", October 2020, . 549 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 550 RFC 793, DOI 10.17487/RFC0793, September 1981, 551 . 553 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 554 Paasch, "TCP Extensions for Multipath Operation with 555 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 556 2020, . 558 [Sat-Terr-Multipath] 559 Joerg Deutschmann, ., "Satellite/Terrestrial Multipath 560 Communication", October 2020, . 564 [TS23501] 3GPP (3rd Generation Partnership Project), ., "Technical 565 Specification Group Services and System Aspects; System 566 Architecture for the 5G System; Stage 2 (Release 16)", 567 2019, . 570 Author's Address 572 Spencer Dawkins (editor) 573 Tencent America 575 Email: spencerdawkins.ietf@gmail.com