Skip to main content

What To Do With Multiple Active Paths in QUIC
draft-dawkins-quic-what-to-do-with-multipath-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Spencer Dawkins
Last updated 2020-11-02
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dawkins-quic-what-to-do-with-multipath-00
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, <https://github.com/quicwg/wg-materials/blob/master/
              interim-20-10/MPQUIC%20use%20cases.pdf>.

   [Apple-Multipath]
              Christoph Paasch, ., "Multipath transports at Apple",
              October 2020, <https://github.com/quicwg/wg-
              materials/blob/master/interim-20-10/
              Multipath%20transports%20at%20Apple.pdf>.

   [Chromium-Multipath]
              Fan Yang/Jana Iyengar, ., "Multipath in Chromium", October
              2020, <https://github.com/quicwg/wg-materials/blob/master/
              interim-20-10/Multipath%20in%20Chromium.pdf>.

   [Hybrid-Access-Multipath]
              Olivier Bonaventure, ., "Hybrid access networks and
              requirements on MPQUIC", October 2020,
              <https://github.com/quicwg/wg-materials/blob/master/
              interim-20-10/Hybrid%20access%20networks%20and%20requireme
              nts%20on%20MPQUIC.pdf>.

   [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,
              <https://github.com/quicwg/wg-materials/blob/master/
              interim-20-10/Multipath%20in%203GPP%20ATSSS.pdf>.

   [QUIC-charter]
              "IETF QUIC Working Group Charter", n.d.,
              <https://datatracker.ietf.org/wg/quic/about/>.

   [QUIC-interim-20-10]
              "IETF QUIC Working Group Virtual Interim Meeting - October
              2020", October 2020, <https://github.com/quicwg/wg-
              materials/tree/master/interim-20-10>.

   [QUIC-interim-20-10-minutes]
              "IETF QUIC Working Group Virtual Interim Meeting - October
              2020 - Minutes", October 2020, <https://github.com/quicwg/
              wg-materials/tree/master/interim-20-10>.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <https://www.rfc-editor.org/info/rfc793>.

   [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, <https://www.rfc-editor.org/info/rfc8684>.

   [Sat-Terr-Multipath]
              Joerg Deutschmann, ., "Satellite/Terrestrial Multipath
              Communication", October 2020, <https://github.com/quicwg/
              wg-materials/blob/master/interim-20-10/Satellite-
              terrestrial%20multipath%20communication.pdf>.

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, <https://www.3gpp.org/ftp/Specs/
              archive/23_series/23.501/>.

Author's Address

   Spencer Dawkins (editor)
   Tencent America

   Email: spencerdawkins.ietf@gmail.com

Dawkins                    Expires May 5, 2021                 [Page 10]