Internet-Draft D. Liu
Intended status: Standards Track Y. Liu
Expires: September 6, 2020 Alibaba Inc.
March 5, 2020

Key Components for Multipath QUIC Traffic Distribution


This document describes several key components for Multipath QUIC traffic distribution. The key components remain compliant with the current Multipath Extensions for QUIC (MP-QUIC) design.

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 September 6, 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

The QUIC connection migration feature, described in more details in [I-D.ietf-quic-transport], enables QUIC to sustain a connection over multiple paths, but still there is a void to specify simultaneous usage of available paths for a single connection. [I-D.deconinck-quic-multipath] describes how to use multiple paths simultaneously for a single QUIC connection, but how to spread packets over multiple paths following a traffic distribution policy, and how to receive packets from multiple paths, are not specified. If not standardized, implementers would still not know how to transmit data over multipath QUIC.

There are several use scenarios about traffic distribution over multipath QUIC. One would be stream media transmission. A typical example is Internet live video broadcasting. It has high requirement on data transmission speed but packet loss rate is lowly prioritized. In this case, multipath QUIC can provide a better utilization of multiple path bandwidth. Another use scenario is highly reliable real-time data transmission, which is sensitive to packet loss. In this case, redundancy data can be transmitted over multipath QUIC. To support the requirements of these use scenarios, multipath QUIC traffic distribution needs to be standardized.

In this document, it focuses on the description of several key components which are necessary to support the implementation of Multipath QUIC traffic distribution. The key components include packet scheduling, congestion control and stream management.

2. Notational Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

3. Packet Scheduling

Given the established multiple QUIC paths, packet scheduling determines which path(s) to deliver packets, how many packets are delivered on a specific QUIC path, which packets are delivered on a specific QUIC path.

Figure 1 illustrates the process of packet scheduling.

                  Path Performance                                       
Original                 |             +-+-+-+              
Data                     V         +-> | | | |   Path 1 
                  +-+-+-+-+-+-+-+  |   +-+-+-+              
+-+-+-+-+         |    Packet   |  |   +-+                   
|    ...|  ->     | Distribution| -+-> | |                   
+-+-+-+-+         +-+-+-+-+-+-+-+  |   +-+                    
                                   |   +-+-+                 
                                   +-> | | |     Path i   

Figure 1: Processing Flow of Data Sending Over Multipath

Since the conditions of each path are different, the different paths need to be measured and selected, in order to pick out paths with better performance, and distribute packets to different paths according to path performance.

There are many traffic distribution mechanisms. Some are based on lowest RTT, while some are based on transmission speed and packet loss rate, which need further evaluation for MPQUIC.

In addition, in scenario where there is large performance difference between multiple QUIC paths, how to select path(s) and how to distribute packets need to be considered. Possible solution could be discarding the path(s) with low performance (packet loss rate is higher than threshold, like 5%), or only transmitting redundancy packets on path(s) with low performance.

4. Stream Management

It is recommended to support the configuration of transmission policies for different QUIC streams. This can be supported by multi priority queue. Figure 2 illustrates the concept of stream management.

       stream                      Multi priority queue
+-+-+-+-+-+-+-+-+      +----------> |               |        
|               |----- |            +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+      |
                       |            +-+-+-+-+-+-+-+-+
      ...              +----------> |               | 
                       +----------> +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+      |                   ...
|               |----- |            +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+      +----------> |               |

Figure 2: Multipath QUIC Stream Management

For example, high priority streams can be delivered first, and even reinjection, while reinjection will not apply for low priority streams.

5. Congestion Control

Congestion control is indispensable for MPQUIC. There can be two options: decoupled congestion control, or coupled congestion control.

For decoupled congestion control, the congestion control policy of each path is decoupled, which is beneficial for maximizing the bandwidth utilization of each path.

6. IANA Considerations

This document makes no request of IANA.

7. Normative References

[I-D.deconinck-quic-multipath] De Coninck, Q. and O. Bonaventure, "Multipath Extensions for QUIC (MP-QUIC)", Internet-Draft draft-deconinck-quic-multipath-03, August 2019.
[I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", Internet-Draft draft-ietf-quic-transport-23, September 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

Authors' Addresses

Qing An Alibaba Inc. EMail: anqing.aq@alibaba-inc.com
Dapeng Liu Alibaba Inc. EMail: max.ldp@alibaba-inc.com
Yanmei Liu Alibaba Inc. EMail: miaoji.lym@alibaba-inc.com