QUIC Working Group S. Dawkins, Ed. Internet-Draft Tencent America Intended status: Informational November 01, 2020 Expires: May 5, 2021 What To Do With Multiple Active Paths in QUIC draft-dawkins-quic-what-to-do-with-multipath-00 Abstract The IETF QUIC working group has been chartered to produce extensions that would "enable ... multipath capabilities" since the working group was formed in 2016, but because multipath was an extension, work on multipath, and the other extensions named in the charter, waited while work proceeded on the core QUIC protocol specifications. After the QUIC working group chairs requested publication for the core QUIC protocol specifications, they scheduled a virtual interim meeting to understand the use cases that various groups inside and outside the IETF were envisioning for multipath with QUIC. As part of that discussion, it became obvious that people had a variety of ideas about how multiple paths would be used, because they weren't looking at the same use cases. This document is intended to capture that variety of ideas, to inform further discussion in the working group. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 5, 2021. Dawkins Expires May 5, 2021 [Page 1] Internet-Draft What To Do With QUIC Multipath November 2020 Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Notes for Readers . . . . . . . . . . . . . . . . . . . . 3 1.2. Contribution and Discussion Venues for this draft. . . . 3 2. Multicast Modes of Operation . . . . . . . . . . . . . . . . 4 2.1. Reference Architecture . . . . . . . . . . . . . . . . . 4 2.2. Forwarding When Multiple Paths Are Available . . . . . . 4 2.2.1. Traffic Steering . . . . . . . . . . . . . . . . . . 4 2.2.2. Traffic Switching . . . . . . . . . . . . . . . . . . 5 2.2.3. Traffic Splitting . . . . . . . . . . . . . . . . . . 5 2.2.4. Traffic Steering, Traffic Switching, and Traffic Splitting in the Core QUIC Transport Protocol . . . . 5 2.3. Forwarding Strategies with Multiple Paths . . . . . . . . 5 2.3.1. Bandwidth Aggregation . . . . . . . . . . . . . . . . 6 2.3.2. Trading Latency Versus Bandwidth . . . . . . . . . . 6 2.3.3. RTT Difference . . . . . . . . . . . . . . . . . . . 6 2.3.4. Active-Standby . . . . . . . . . . . . . . . . . . . 6 2.3.5. Load-Balancing . . . . . . . . . . . . . . . . . . . 7 2.3.6. Priority-based . . . . . . . . . . . . . . . . . . . 7 2.3.7. Redundant . . . . . . . . . . . . . . . . . . . . . . 7 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Document History . . . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The IETF QUIC working group has been chartered to produce extensions that would "enable ... multipath capabilities" ([QUIC-charter]) since the working group was formed in 2016, but because multipath was an Dawkins Expires May 5, 2021 [Page 2] Internet-Draft What To Do With QUIC Multipath November 2020 extension, work on multipath, and the other extensions named in the charter, waited while work proceeded on the core QUIC protocol specifications ([I-D.ietf-quic-transport] and related specifications). After the QUIC working group chairs requested publication for the core QUIC protocol specifications, they scheduled a virtual interim meeting ([QUIC-interim-20-10]) to understand the use cases that various groups inside and outside the IETF were envisioning for multipath with QUIC. As part of that discussion, it became obvious that people had a variety of ideas about how multiple paths would be used, because they weren't looking at the same use cases. This document is intended to capture that variety of ideas, to inform further discussion in the working group. For more details, please see the QUIC working group meeting minutes, at [QUIC-interim-20-10-minutes], which include pointers to the video recording from the meeting, pointers to each presentation given, questions and answers after each presentation, and overall discussion following the presentations. 1.1. Notes for Readers This document is an informational Internet-Draft, not adopted by any IETF working group, and does not carry any special status within the IETF. It reflects the author's understanding, and contributions that include improvements and clarifications are welcomed, as described in Section 1.2. 1.2. Contribution and Discussion Venues for this draft. (Note to RFC Editor - if this document ever reaches you, please remove this section) This document is under development in the Github repository at https://github.com/SpencerDawkins/draft-dawkins-quic-what-to-do-with- multipath. Readers are invited to open issues and send pull requests with contributed text for this document. Substantial discussion of this document should take place on the QUIC working group mailing list (quic@ietf.org). Subscription and archive details are at https://www.ietf.org/mailman/listinfo/quic. Dawkins Expires May 5, 2021 [Page 3] Internet-Draft What To Do With QUIC Multipath November 2020 2. Multicast Modes of Operation For the purposes of this document, it's enough to consider two QUIC endpoints (QUIC Host X and QUIC Host Y) with two disjoint paths between them (Access Net A and Access Net B), as shown in Figure 1. 2.1. Reference Architecture ------------ / \ +-------| Access Net A |--+ | \ / | | ------------ | +---+--+ | +------+ | QUIC | +--------| QUIC | } Host | | Host | | X | +--------| Y | +---+--+ | +------+ | ------------ | | / \ | +-------| Access Net B |--+ \ / ------------ Figure 1: Simplified Reference Architecture for QUIC Multipath Operation More than two paths are certainly possible - for example, two hosts that are connected by a satellite uplink/downlink path, and two different landline paths from different network providers. But I believe this simplified architecture is sufficient for discussion purposes. 2.2. Forwarding When Multiple Paths Are Available This section uses terminology from 3GPP ATSSS {Access Traffic Steering, Switch and Splitting, [TS23501]) to describe three different patterns of packer forwarding that are applicable when multiple disjoint paths are available. Note that these terms describe concepts that are not ATSSS-specific, and could apply to any multipath environment. If terminology more accessible to IETF QUIC working group participants presents itself, I'll change it. 2.2.1. Traffic Steering When a sending host has more than one path available, a sending host will select a path to begin forwarding packets on. This can be described as Traffic Steering. Dawkins Expires May 5, 2021 [Page 4] Internet-Draft What To Do With QUIC Multipath November 2020 2.2.2. Traffic Switching When a sending host has more than one path available and is using a single path, the sending host can stop using this path, and start using another path. This can be described as Traffic Switching. 2.2.3. Traffic Splitting When a sending host has more than one path available, the sending host may wish to use both paths simultaneously. This can be described as Traffic Splitting. 2.2.4. Traffic Steering, Traffic Switching, and Traffic Splitting in the Core QUIC Transport Protocol [I-D.ietf-quic-transport] and related specifications support the selection and use of multiple paths between QUIC endpoints, as long as only one path is in active use at any given time. [I-D.ietf-quic-transport] and related specifications do not support forwarding traffic for a single connection on multiple paths between QUIC endpoints simultaneously. This level of support for multipath allows Traffic Steering - the selection of a specific path - and Traffic Switching - migration of traffic from one path to another, using QUIC connection migration. It does not allow "Traffic Splitting - the use of simultaneous paths for a single connection, except for unordered datagram traffic [I-D.ietf-quic-datagram]. One important output from the QUIC interim meeting was the recognition that "Traffic Switching" can be accomplished with much more agility than some participants recognized - if you open and validate two or more connections, no additional setup or signaling is required for a sender to switch paths - that can begin with the next packet queued for transmission. 2.3. Forwarding Strategies with Multiple Paths During the QUIC virtual interim meeting, various presenters described various forwarding strategies that they have used in the past (especially with TCP [RFC0793] and Multipath TCP [RFC8684]). and that they expected to use in the future with some multipath QUIC extension. This section is an attempt to identify commonalities and gaps that may inform work on future multipath extensions for QUIC. Dawkins Expires May 5, 2021 [Page 5] Internet-Draft What To Do With QUIC Multipath November 2020 All of these forwarding strategies build on Traffic Steering - opening one or more connections, and then proceeding to use one connection, switch to another connection, or split traffic across paths. For this reason, Traffic Steering isn't mentioned in the rest of this section. 2.3.1. Bandwidth Aggregation Some environment allow the use of multiple paths simultaneously for significant periods of time, because none of the paths are metered, so using all of the bandwidth on all of the paths simultaneously makes sense. Traffic Splitting is required to support this strategy. [Alibaba-MPQUIC] mentioned this strategy at the QUIC Interim Meeting. 2.3.2. Trading Latency Versus Bandwidth Some applications require low latency, and others don't. So using a network path with lower latency for some connections, and using a different network path with higher bandwidth available for others. allows this strategy. Traffic Switching is sufficient for this, if measured path characteristics change enough to justify changing paths. [Chromium-Multipath] mentioned this strategy at the QUIC Interim Meeting. [Apple-Multipath] is actually switching paths at sub-RTT rates. 2.3.3. RTT Difference Not all multipath environments include paths with significant differences between path characteristics, but several do. If two or more paths have characteristics that are "sufficiently close" - for example, they may have path RTTs that are equivalent, from the application's point of view - a sender may wish to use both paths as long as that's the case, and then adopt another forwarding strategy when measured path characteristics diverge. Traffic Splitting is required to support this strategy. [Apple-Multipath], [Sat-Terr-Multipath].[Hybrid-Access-Multipath], and [Multipath-3GPP-ATSSS] all mentioned this strategy at the QUIC Interim Meeting. 2.3.4. Active-Standby The traffic associated with a specific flow will be forwarded via a specific path (the 'active path') and switched to another path (called 'standby path') when the active access is unavailable. Traffic Switching is sufficient to support this strategy. [Multipath-3GPP-ATSSS] mentioned this strategy at the QUIC Interim meeting. Dawkins Expires May 5, 2021 [Page 6] Internet-Draft What To Do With QUIC Multipath November 2020 2.3.5. Load-Balancing The traffic associated with a specific connection will be distributed among the available paths following a distribution ratio (e.g., 30% via a first access, 70% via a second access). This distribution ratio may be static, or may be adjusted over time, based on measured path characteristics. Traffic Splitting is required to support this strategy. [Multipath-3GPP-ATSSS] mentioned this strategy at the QUIC Interim meeting. 2.3.6. Priority-based Paths are assigned priority levels that indicate which path will be used first. Concretely, the traffic associated with the matching flow will be steered on the path with a high priority till congestion is detected, then the overflow will be forwarded over a low priority access. Traffic Splitting is required to support this strategy. [Multipath-3GPP-ATSSS] mentioned this strategy at the QUIC Interim meeting. 2.3.7. Redundant Traffic is replicated over two or more paths to increase the probability that the traffic will arrive at the other host undamaged and usable. Redundant traffic may be used for all packets in a connection, or may only be used when measured network conditions indicate it should be used. Traffic Splitting is required to support this strategy. [Multipath-3GPP-ATSSS] mentioned this strategy at the QUIC Interim meeting. 3. IANA Considerations This document does not make any request to IANA. 4. Security Considerations QUIC-specific security considerations are discussed in Section 21 of [I-D.ietf-quic-transport]. Section 6 of [I-D.ietf-quic-datagram] discusses security considerations specific to the use of the Unreliable Datagram Extension to QUIC. Some multipath QUIC-specific security considerations can be found in Section 8 of the individual draft [I-D.deconinck-quic-multipath]. Dawkins Expires May 5, 2021 [Page 7] Internet-Draft What To Do With QUIC Multipath November 2020 5. Acknowledgements I'd like to thank Lars Eggert and Lucas Pardue, the QUIC working group chairs, who called the QUIC virtual interim meeting on multipath. I'd also like to thank the presenters at the QUIC virtual interim, who put together valuable presentations on short notice. Many thanks to (your name could easily appear here) for reviews and comments. 6. Document History (Note to RFC Editor - if this document ever reaches you, please remove this section) Version -00: initial submission 7. Normative References [Alibaba-MPQUIC] Yanmei Lei / Yunfei Ma, ., "MPQIIC Use Cases", October 2020, . [Apple-Multipath] Christoph Paasch, ., "Multipath transports at Apple", October 2020, . [Chromium-Multipath] Fan Yang/Jana Iyengar, ., "Multipath in Chromium", October 2020, . [Hybrid-Access-Multipath] Olivier Bonaventure, ., "Hybrid access networks and requirements on MPQUIC", October 2020, . [I-D.deconinck-quic-multipath] Coninck, Q. and O. Bonaventure, "Multipath Extensions for QUIC (MP-QUIC)", draft-deconinck-quic-multipath-06 (work in progress), November 2020. Dawkins Expires May 5, 2021 [Page 8] Internet-Draft What To Do With QUIC Multipath November 2020 [I-D.ietf-quic-datagram] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", draft-ietf-quic-datagram-01 (work in progress), August 2020. [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic-transport-32 (work in progress), October 2020. [Multipath-3GPP-ATSSS] Spencer Dawkins / Mirja Kuehlewind / Florin Baboescu / Hannu Flinck, ., "Multipath in 3GPP ATSSS", October 2020, . [QUIC-charter] "IETF QUIC Working Group Charter", n.d., . [QUIC-interim-20-10] "IETF QUIC Working Group Virtual Interim Meeting - October 2020", October 2020, . [QUIC-interim-20-10-minutes] "IETF QUIC Working Group Virtual Interim Meeting - October 2020 - Minutes", October 2020, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, . [Sat-Terr-Multipath] Joerg Deutschmann, ., "Satellite/Terrestrial Multipath Communication", October 2020, . Dawkins Expires May 5, 2021 [Page 9] Internet-Draft What To Do With QUIC Multipath November 2020 [TS23501] 3GPP (3rd Generation Partnership Project), ., "Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2 (Release 16)", 2019, . Author's Address Spencer Dawkins (editor) Tencent America Email: spencerdawkins.ietf@gmail.com Dawkins Expires May 5, 2021 [Page 10]