Huawei

jiao_kang2022@163.com

Huawei

No. 207, Jiufeng 3rd Road, East Lake High-tech Development Zone Wuhan China liangqiandeng@huawei.com

Huawei

D2-03,Huawei Industrial Base Shenzhen China dengshangling@huawei.com

China Mobile

32 Xuanwumen West Street, Xicheng District Beijing China liupengyjy@chinamobile.com

Transport Area QUIC quic,one-way delay 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.

Introduction

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.

Overview QUIC basic specifications have been released successively. As an extension of QUIC, multipath QUIC is being formulated. Currently,two multipath QUIC suggestions ( and ) are submitted to QUIC group. This document is based on . 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 , Figure 1 illustrates the architecture of a multipath QUIC connection.

An Example of Uniflow Distribution over a Multipath QUIC Connection | | | | | | | |------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.

RTT measurement Algorithm used in Single-path QUIC |- | | | | 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.

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.

One-way Delays Comparation Algorithm |- |- | | (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.

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.

IANA Considerations Request to IANA will be added later.

Security Considerations Security issues will be considered later in the design.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. Informative References This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. This memo provides information for the Internet community. UCLouvain UCLouvain Alibaba Inc. Alibaba Inc. Private Octopus Inc. Alibaba Inc. ICT-CAS

Additional Stuff This becomes an Appendix.