Comparing One-way Delays in MultipathHuaweijiao_kang2022@163.comHuaweiNo. 207, Jiufeng 3rd Road, East Lake High-tech Development ZoneWuhanChinaliangqiandeng@huawei.comHuaweiD2-03,Huawei Industrial BaseShenzhenChinadengshangling@huawei.comChina Mobile32 Xuanwumen West Street, Xicheng DistrictBeijingChinaliupengyjy@chinamobile.com
Transport Area
QUICquic,one-way delayThis 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.IntroductionRequirements LanguageThe 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.OverviewQUIC 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.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.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 QUICFigure 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. 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-TxOne-way Delay(uniflow 1): Ty2 = T3-T1-D2-TxIf 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 ConsiderationsIn 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 ConsiderationsRequest to IANA will be added later.Security ConsiderationsSecurity issues will be considered later in the design.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn 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.QUIC: A UDP-Based Multiplexed and Secure TransportThis 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 ReferencesWriting I-Ds and RFCs using XMLThis 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.Multipath Extensions for QUIC (MP-QUIC)UCLouvainUCLouvainMultipath Extension for QUICAlibaba Inc.Alibaba Inc.Private Octopus Inc.Alibaba Inc.ICT-CASAdditional StuffThis becomes an Appendix.