| Internet-Draft | Abbreviated Title | October 2021 |
| Kang, et al. | Expires 27 April 2022 | [Page] |
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.¶
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 (c) 2021 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.¶
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].¶
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---------------|
| | | |
| | | |
| | | |
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) |
| |
| |
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.¶
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) | |
| | | |
| | | |
| | | |
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.¶
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.¶
Request to IANA will be added later.¶
Security issues will be considered later in the design.¶
This becomes an Appendix.¶