Enabling application policy-awareness in Multipath QUIC
draft-an-multipath-quic-application-policy-00

Abstract

This document describes an application policy-awareness method for Multipath QUIC, to enable taking applications’ demands into account when managing paths or scheduling packets in Multipath QUIC.

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 January 7, 2021.

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. Notational Conventions
• 3. What is Application Policy-awareness in Multipath QUIC
• 4. Per-connection Policy
• 5. Per-stream Intent
• 6. IANA Considerations
• 7. Informative References
• Authors' Addresses

1. Introduction

The availability of multiple network interfaces in devices enables the use of multiple paths between two end points for robust and (possibly) fast data delivery. Multi-path TCP (MPTCP) was designed to leverage off such an availability. It has been adopted by operating systems and ISPs. A major design principle of MPTCP is that it must be usable by applications through existing SOCKET APIs. That said, it shields the underlying multiple paths for the applications, which may be not even aware the use of multiple path transmission. While this implements the backward compatibility with TCP, it also leaves the applications out of the control loop of the transport. Nevertheless, applications may have completely different QoE requirements---the interactive applications are delay sensitive, while the video streaming are more throughput sensitive. There is thus a trend of cross-layer design that tries to take applications’ demands into account when managing paths or scheduling packets in MPTCP [MP-DASH][WN][AD-MPTCP][SMAPP].

We thus advocate the idea of application policy awareness in multi-path transport, which is to separate the ‘control plane’ from the `data plane’ like in software defined networking. The ‘control plane’ takes applications’ high-level demands (a.k.a intent) as input to generate the corresponding policies, which later are deployed on the ‘data plane’. The ‘data plane’ maps users policies to the ‘actions’, which control the path management, packet scheduling and other functionalities that the transport implements. For instance, the ‘actions’ for path management may include “backup”, “full mesh” and “ndiffports”, while the ‘actions’ for packet scheduling may designate whether ECF [ECF] or DEMS [BSC] is used for path selection, and may also impose a traffic split ratio among paths. Each connection then can have a customized multipath transport.

Since MPTCP is implemented in OS kernel, it is not easy for application providers to incorporate the above idea into MPTCP to improve the applications’ performance. QUIC, on the other hand, implements a UDP-based transport, which enables the transport to be bundled into applications and quickly deployed in end users’ devices. MPQUIC extends QUIC to multipath scenarios. Nevertheless, the basic MPQUIC [MPQUIC-Design] acts much like MPTCP, except it uses QUIC (as opposed to TCP). That said, the current MPQUIC implementation does not support application policy-aware transport.

A straight solution for MPQUIC to enable the interaction between applications and transport is to let applications to access/change every single logic of the packet scheduling and path management, or export callback functions as in [SMAPP]. This however will result in a complex mix between applications and transport because of limited abstraction. And perhaps more importantly, it requires application developers to understand the details of the underlying transport.

This document describes an application policy-awareness method for Multipath QUIC, to enable taking applications’ demands into account when managing paths or scheduling packets in Multipath QUIC. The method remains compliant with the current Multipath Extensions for QUIC [I-D.deconinck-quic-multipath] design.

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. What is Application Policy-awareness in Multipath QUIC

We advocate a more practical alternative (See Figure 1), where 1). the `control plane’ provides primitives to applications to express their policies (intent); 2). the `data plane’ abstracts execution models for application policies and generates the corresponding composed `actions’.

            per-stream intent                   per-conn policy
 Control e.g. stream prioirity      e.g. path preference, path mode,
 Plane                                        deadline-aware etc
            |                                        |
 -----------|----------------------------------------|-------------
            V                                        V
 Data  +--------+ -                      +------------------------+
 Plane |        |  |                     |                        |
       +--------+  |                     |                +-----+ |
                   |                     |             +->| ... | |
       +--------+  |                     |             |  +-----+ |
       |        |  |                     |             |  +-----+ |
       +--------+  |                     |             +->| ... | |
                   |                     |             |  +-----+ |
       +--------+  | +----------+ chunks |+----------+ |          |
       |        |  ->|  stream  |------->||  packet  |-+    ...   |
       +--------+  | |scheduling|        ||scheduling| |          |
          ...      | +----------+        |+----------+ |  +-----+ |
       +--------+  |                     |             +->| ... | |
       |        |  |                     |             |  +-----+ |
       +--------+  |                     |             |  +-----+ |
                   |                     |             +->| ... | |
       +--------+  |                     |                +-----+ |
       |        |  |                     |           path manager |
       +--------+ -                      +------------------------+
         streams
         
                  

Figure 1: Application Policy Awareness in Multi-path QUIC framework

4. Per-connection Policy

An application imposes per-connection policy through the primitives provided by the control plane. Some examples of policies are path preference (e.g. a Wi-Fi path is preferred twice than a cellular path), path model (e.g. full mesh, ndiffports, backup). The packet scheduling component and the path manager at the data plane will act based on these indications for path selection and data transmission. We assume the policies are ‘soft’---the policies are not a must. Instead, the data plane will follow the policies as much as possible.

Let us take real-time interaction applications as an example to illustrate the basic idea. The applications are indeed delay sensitive but data volume is often low. 3 types of policies may be used by different applications, as shown in Table 1 where we assume only two paths are available (Wi-Fi and Cellular)

The first type of policies would like to use two paths equally, and because the applications are delay sensitive, the actions will be ‘full redundant’ for the packet scheduling---two paths send the same data. The second type of policies, on the other hand, would like to use the Wi-Fi interface (possibly because of data charge) if possible. But if two paths have to be activated at the same time due to the lower performance of Wi-Fi, then the two paths are with same the preference. So, the corresponding actions will be will be ‘full redundant’ for the packet scheduling, and the path management component will monitor the performance of the active interface and activate the backup one if the performance is lower than a threshold for a short period of time (e.g. 5 seconds). The third type of policies would like to use the two interfaces at the same time, but Wi-Fi is preferred twice as the cellular one. The actions will take this into consideration, and implement partial redundant transmission over the cellular Interface.

Likewise, we can define a mapping between the policies of different types of applications and the actions in the data plane. We leave the design of such a mapping to the designers.

TODO: Add design of such a mapping.

5. Per-stream Intent

Per-stream intent is a unique feature provided by (MP)QUIC---it is implemented through the multiple streams in QUIC. Streams can be associated with priorities to implement applications intent. For instance, objects in a web page may be dependent on others and thus have different priorities [MPQUIC-Scheduler]. A priority-aware packet scheduling algorithm will improve the performance notably.

 High priority  /\  +---------+
                ||  |         |
                ||  +---------+
                ||  +---------+
                ||  |         |
                ||  +---------+
                ||     ...          User-defined priority
                ||  +---------+
 Low priority   ||  |         |
                ||  +---------+
 -----------------------------------------------------------
 High priority  /\  +---------+
                ||  |         |
                ||  +---------+
                ||  +---------+
                ||  |         |
                ||  +---------+
                ||     ...          Default priority
                ||  +---------+
 Low priority   ||  |         |
                ||  +---------+

Figure 2: Stream priority

We envision a priority management scheme of two separated priority ranges (see Figure 2). The user-defined priority ranges are those streams that the applications explicitly designate the priorities, where the default priority ranges include the streams with no priority values set by the applications. Only when the streams in the user-defined ranges have no data sent, the data in the streams in the default priority ranges can be sent. In the same range, one can use the weighted round robin for scheduling---the higher-priority streams get more quantum for data sending in each round. One can also dynamically set/change the priorities of the streams in the default priority ranges to enable short stream first if needed.

We list in Table 2 some applications that can be benefited from the above priority-aware stream management scheme.

TODO: Add priority management solution.

6. IANA Considerations

This document makes no request of IANA.

7. Informative References

Authors' Addresses