QUIC                                                        J. Kang, Ed.
Internet-Draft                                                  Q. Liang
Intended status: Informational                                    Huawei
Expires: 27 April 2022                                            P. Liu
                                                            China Mobile
                                                         24 October 2021


                 Comparing One-way Delays in Multipath
             draft-kang-quic-oneway-delays-in-multipath-00

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 27 April 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Kang, et al.              Expires 27 April 2022                 [Page 1]


Internet-Draft              Abbreviated Title               October 2021


   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.  Requirements Language . . . . . . . . . . . . . . . . . .   2
     1.2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  One-way Delays Comparation in Multipath QUIC  . . . . . . . .   4
   3.  Protocol Extension Considerations . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Additional Stuff . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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.





Kang, et al.              Expires 27 April 2022                 [Page 2]


Internet-Draft              Abbreviated Title               October 2021


          +---------+                               +---------+
          |  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



Kang, et al.              Expires 27 April 2022                 [Page 3]


Internet-Draft              Abbreviated Title               October 2021


   (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



Kang, et al.              Expires 27 April 2022                 [Page 4]


Internet-Draft              Abbreviated Title               October 2021


   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







Kang, et al.              Expires 27 April 2022                 [Page 5]


Internet-Draft              Abbreviated Title               October 2021


   [QUIC]     Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May
              2021, <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, March 1997,
              <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)", 2021,
              <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, June 1999,
              <https://www.rfc-editor.org/info/rfc2629>.

Appendix A.  Additional Stuff

   This becomes an Appendix.

Authors' Addresses

   Jiao Kang (editor)
   Huawei
   D2-03,Huawei Industrial Base
   Shenzhen
   China

   Email: kangjiao@huawei.com










Kang, et al.              Expires 27 April 2022                 [Page 6]


Internet-Draft              Abbreviated Title               October 2021


   Qiandeng Liang
   Huawei
   No. 207, Jiufeng 3rd Road, East Lake High-tech Development Zone
   Wuhan
   China

   Email: liangqiandeng@huawei.com


   Peng Liu
   China Mobile
   32 Xuanwumen West Street, Xicheng District
   Beijing
   China

   Email: liupengyjy@chinamobile.com



































Kang, et al.              Expires 27 April 2022                 [Page 7]