Internet-Draft Abbreviated Title June 2022
Kang, et al. Expires 18 December 2022 [Page]
Workgroup:
QUIC
Internet-Draft:
draft-kang-quic-oneway-delays-in-multipath-01
Published:
Intended Status:
Informational
Expires:
Authors:
J. Kang
Huawei
Q. Liang
Huawei
S. Deng, Ed.
Huawei
P. Liu
China Mobile

Comparing One-way Delays in Multipath

Abstract

This document provides a solution for comparing one-way delays in multipath quic. In this solution, through message interaction between data receiver and data sender, the data sender can obtain delay rankings of multiple specified uniflows, providing reference for sending data packets.

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 18 December 2022.

Table of Contents

1. Introduction

1.1. Requirements Language

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 RFC 2119 [RFC2119].

1.2. Overview

QUIC basic specifications have been released successively. As an extension of QUIC, multipath QUIC is being formulated. Currently,two multipath QUIC suggestions ([DECONINCK-MP] and [QUIC-MP-LIU]) are submitted to QUIC group. This document is based on [DECONINCK-MP].

[DECONINCK-MP] proposes a new design, that is, from a user perspective, the (multipath) QUIC is a collection of unidirectional flows ("all-uniflow"). Essentially, (multipath) QUIC consists of multiple client-to-server uniflows and server-to-client uniflows. When sending packets, endpoints perform data transmission scheduling independently. Referring to [DECONINCK-MP], Figure 1 illustrates the architecture of a multipath QUIC connection.

       +---------+                               +---------+
       |  Client |                               |  Server |
       +---------+                               +---------+
        | |   | |                                 | |   | |
        +-+   +-+                                 +-+   +-+
         |     |                                   |     |
         |     |                                   |     |
         |     |------CID A - Uniflow ID 1-------->|     |
         |     |                                   |     |
         |     |------CID B - Uniflow ID 0-------------->|
         |     |                                   |     |
         |     |<-----CID C - Uniflow ID 0---------|     |
         |     |                                   |     |
         |<-----------CID D - Uniflow ID 1---------|     |
         |     |                                   |     |
         |     |<-----CID E - Uniflow ID 2---------------|
         |     |                                   |     |
         |     |                                   |     |
         |     |                                   |     |
Figure 1: An Example of Uniflow Distribution over a Multipath QUIC Connection

In single-path QUIC, RTT is valuable in adjusting packet sending window and congestion prevention and the algorithm of RTT measurement is depicted in the Figure 2.

       +---------+                               +---------+
       |  Client |                               |  Server |
       +---------+                               +---------+
            |                                         |
            |                                         |
        T1  |-------------------Tx------------------->|-
            |                                         |
            |                                         | Delay
            |                                         |
        T2  |<------------------Ty--------------------|-
            |                                         |
            |       RTT(Tx+Ty)=(T2-T1-Delay)          |
            |                                         |
            |                                         |

Figure 2: RTT measurement Algorithm used in Single-path QUIC

In multipath QUIC scenarios, data/control packets and corresponding ACKs are allowed to travel through different physical links to decouple service flows (streams) and links (connections). Packets (including ACKs) of the same stream may be transmitted through different connections. Therefore, minRTT, as the common path selection and scheduling algorithm for QUIC packets cannot be implemented effectively. So, measurement of the minimum one-way delay or calculation of the minimum delay of multiple uniflow in multipath QUIC protocol is important and required.

2. One-way Delays Comparation in Multipath QUIC

Figure 3 shows the algorithm presented in this document that is used by the data sender to determine the one-way delays of each uniflow or specified uniflows in a test period.

   +---------+                                  +---------+
   |  Client |                                  |  Server |
   +---------+                                  +---------+
    | |   | |                                    | |   | |
    +-+   +-+                                    +-+   +-+
     |     |                                      |     |
     |     |                                      |     |
T1   |     |-------UNICONNECTION_DELAY_REQ------->|-    |-
     |     |       (CID A, uniflow 0, Tx1)        |     |
     |     |                                      |     |
     |     |                                      |D1   |
     |     |                                      |     |
     |     |                                      |     |D2
T2   |     |<------UNICONNECTION_DELAY_RESP-------|-    |
     |     |       (CID B, uniflow 0, Ty1)        |     |
     |     |                                      |     |
T3   |<-------UNICONNECTION_DELAY_RESP(uniflow 1)-------|-
     |     |       (CID c, uniflow 1, Ty2)        |     |
     |     |                                      |     |
     |     |                                      |     |
     |     |-------UNICONNECTIONS_DELAY_RESULT--------->|
     |     |        (CID A, uniflow 1, Tx2)       |     |
     |     |                                      |     |
     |     |                                      |     |
     |     |                                      |     |
Figure 3: One-way Delays Comparation Algorithm

For example, the data sender is a server, and the data receiver is a mobile phone client. If the server wants to obtain the one-way delay information of each subflow, the server instructs the client to create a measurement task and the client records the start time. The client sends a delay test frame (UNICONNECTION_DELAY_REQ frame) to the server through a client-to-server subflow. After receiving the delay test frame (UNICONNECTION_DELAY_REQ frame) from the client, the server returns the delay measurement responses (UNICONNECTION_DELAY_RESP frame) on all candidate server-to-client subflows. The client records the arrival time of each delay measurement response (UNICONNECTION_DELAY_RESP frame). Then the client can calculate the delay rankings for these candidate server-to-client uniflows by the formulas below:

One-way Delay(uniflow 0): Ty1 = T2-T1-D1-Tx

One-way Delay(uniflow 1): Ty2 = T3-T1-D2-Tx

If Ty1 is greater than Ty2, uniflow 0's one-way delay is greater than that of uniflow 0. If Ty1 is less than Ty2, uniflow 0's one-way delay is less than that of uniflow 0.

Finally, the client sends the measurement result (UNICONNECTIONS_DELAY_RESULT frame) to the server as a reference to select a uniflow for data transmission in this test period.

3. Protocol Extension Considerations

In this solution, three new frames are introduced to complete the interaction of the test between endpoints:

UNICONNECTION_DELAY_REQ Frame: triggering creation of a new measurement task sent from the data sender to the data receiver.

UNICONNECTION_DELAY_RESP Frame: delay measurement response frame sent from the data receiver to the data sender.

UNICONNECTIONS_DELAY_RESULT Frame: measurement result releasing frame sent from the data receiver to the data sender.

4. IANA Considerations

Request to IANA will be added later.

5. Security Considerations

Security issues will be considered later in the design.

6. References

6.1. Normative References

[QUIC]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.

6.2. Informative References

[DECONINCK-MP]
De Coninck, Q. and O. Bonaventure, "Multipath Extensions for QUIC (MP-QUIC)", , <https://datatracker.ietf.org/doc/draft-deconinck-quic-multipath/>.
[QUIC-MP-LIU]
Liu, Y., Ma, Y., Huitema, C., An, Q., and Z. Li, "Multipath Extension for QUIC", <https://datatracker.ietf.org/doc/draft-liu-multipath-quic/>.
[RFC2629]
Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 10.17487/RFC2629, , <https://www.rfc-editor.org/info/rfc2629>.

Appendix A. Additional Stuff

This becomes an Appendix.

Authors' Addresses

Jiao Kang
Huawei
Qiandeng Liang
Huawei
No. 207, Jiufeng 3rd Road, East Lake High-tech Development Zone
Wuhan
China
Shangling Deng (editor)
Huawei
D2-03,Huawei Industrial Base
Shenzhen
China
Peng Liu
China Mobile
32 Xuanwumen West Street, Xicheng District
Beijing
China