idnits 2.17.00 (12 Aug 2021) /tmp/idnits16616/draft-kang-quic-oneway-delays-in-multipath-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (24 October 2021) is 202 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'QUIC' is defined on line 229, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 253, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC J. Kang, Ed. 3 Internet-Draft Q. Liang 4 Intended status: Informational Huawei 5 Expires: 27 April 2022 P. Liu 6 China Mobile 7 24 October 2021 9 Comparing One-way Delays in Multipath 10 draft-kang-quic-oneway-delays-in-multipath-00 12 Abstract 14 This document provides a solution for comparing one-way delays in 15 multipath quic. In this solution, through message interaction 16 between data receiver and data sender, the data sender can obtain 17 delay rankings of multiple specified uniflows, providing reference 18 for sending data packets. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 27 April 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 55 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. One-way Delays Comparation in Multipath QUIC . . . . . . . . 4 57 3. Protocol Extension Considerations . . . . . . . . . . . . . . 5 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 6.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 1.1. Requirements Language 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC 2119 [RFC2119]. 74 1.2. Overview 76 QUIC basic specifications have been released successively. As an 77 extension of QUIC, multipath QUIC is being formulated. Currently,two 78 multipath QUIC suggestions ([DECONINCK-MP] and [QUIC-MP-LIU]) are 79 submitted to QUIC group. This document is based on [DECONINCK-MP]. 81 [DECONINCK-MP] proposes a new design, that is, from a user 82 perspective, the (multipath) QUIC is a collection of unidirectional 83 flows ("all-uniflow"). Essentially, (multipath) QUIC consists of 84 multiple client-to-server uniflows and server-to-client uniflows. 85 When sending packets, endpoints perform data transmission scheduling 86 independently. Referring to [DECONINCK-MP], Figure 1 illustrates the 87 architecture of a multipath QUIC connection. 89 +---------+ +---------+ 90 | Client | | Server | 91 +---------+ +---------+ 92 | | | | | | | | 93 +-+ +-+ +-+ +-+ 94 | | | | 95 | | | | 96 | |------CID A - Uniflow ID 1-------->| | 97 | | | | 98 | |------CID B - Uniflow ID 0-------------->| 99 | | | | 100 | |<-----CID C - Uniflow ID 0---------| | 101 | | | | 102 |<-----------CID D - Uniflow ID 1---------| | 103 | | | | 104 | |<-----CID E - Uniflow ID 2---------------| 105 | | | | 106 | | | | 107 | | | | 109 Figure 1: An Example of Uniflow Distribution over a Multipath 110 QUIC Connection 112 In single-path QUIC, RTT is valuable in adjusting packet sending 113 window and congestion prevention and the algorithm of RTT measurement 114 is depicted in the Figure 2. 116 +---------+ +---------+ 117 | Client | | Server | 118 +---------+ +---------+ 119 | | 120 | | 121 T1 |-------------------Tx------------------->|- 122 | | 123 | | Delay 124 | | 125 T2 |<------------------Ty--------------------|- 126 | | 127 | RTT(Tx+Ty)=(T2-T1-Delay) | 128 | | 129 | | 131 Figure 2: RTT measurement Algorithm used in Single-path QUIC 133 In multipath QUIC scenarios, data/control packets and corresponding 134 ACKs are allowed to travel through different physical links to 135 decouple service flows (streams) and links (connections). Packets 136 (including ACKs) of the same stream may be transmitted through 137 different connections. Therefore, minRTT, as the common path 138 selection and scheduling algorithm for QUIC packets cannot be 139 implemented effectively. So, measurement of the minimum one-way 140 delay or calculation of the minimum delay of multiple uniflow in 141 multipath QUIC protocol is important and required. 143 2. One-way Delays Comparation in Multipath QUIC 145 Figure 3 shows the algorithm presented in this document that is used 146 by the data sender to determine the one-way delays of each uniflow or 147 specified uniflows in a test period. 149 +---------+ +---------+ 150 | Client | | Server | 151 +---------+ +---------+ 152 | | | | | | | | 153 +-+ +-+ +-+ +-+ 154 | | | | 155 | | | | 156 T1 | |-------UNICONNECTION_DELAY_REQ------->|- |- 157 | | (CID A, uniflow 0, Tx1) | | 158 | | | | 159 | | |D1 | 160 | | | | 161 | | | |D2 162 T2 | |<------UNICONNECTION_DELAY_RESP-------|- | 163 | | (CID B, uniflow 0, Ty1) | | 164 | | | | 165 T3 |<-------UNICONNECTION_DELAY_RESP(uniflow 1)-------|- 166 | | (CID c, uniflow 1, Ty2) | | 167 | | | | 168 | | | | 169 | |-------UNICONNECTIONS_DELAY_RESULT--------->| 170 | | (CID A, uniflow 1, Tx2) | | 171 | | | | 172 | | | | 173 | | | | 175 Figure 3: One-way Delays Comparation Algorithm 177 For example, the data sender is a server, and the data receiver is a 178 mobile phone client. If the server wants to obtain the one-way delay 179 information of each subflow, the server instructs the client to 180 create a measurement task and the client records the start time. The 181 client sends a delay test frame (UNICONNECTION_DELAY_REQ frame) to 182 the server through a client-to-server subflow. After receiving the 183 delay test frame (UNICONNECTION_DELAY_REQ frame) from the client, the 184 server returns the delay measurement responses 185 (UNICONNECTION_DELAY_RESP frame) on all candidate server-to-client 186 subflows. The client records the arrival time of each delay 187 measurement response (UNICONNECTION_DELAY_RESP frame). Then the 188 client can calculate the delay rankings for these candidate server- 189 to-client uniflows by the formulas below: 191 One-way Delay(uniflow 0): Ty1 = T2-T1-D1-Tx 193 One-way Delay(uniflow 1): Ty2 = T3-T1-D2-Tx 195 If Ty1 is greater than Ty2, uniflow 0's one-way delay is greater than 196 that of uniflow 0. If Ty1 is less than Ty2, uniflow 0's one-way 197 delay is less than that of uniflow 0. 199 Finally, the client sends the measurement result 200 (UNICONNECTIONS_DELAY_RESULT frame) to the server as a reference to 201 select a uniflow for data transmission in this test period. 203 3. Protocol Extension Considerations 205 In this solution, three new frames are introduced to complete the 206 interaction of the test between endpoints: 208 UNICONNECTION_DELAY_REQ Frame: triggering creation of a new 209 measurement task sent from the data sender to the data receiver. 211 UNICONNECTION_DELAY_RESP Frame: delay measurement response frame sent 212 from the data receiver to the data sender. 214 UNICONNECTIONS_DELAY_RESULT Frame: measurement result releasing frame 215 sent from the data receiver to the data sender. 217 4. IANA Considerations 219 Request to IANA will be added later. 221 5. Security Considerations 223 Security issues will be considered later in the design. 225 6. References 227 6.1. Normative References 229 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 230 and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 231 2021, . 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, 236 DOI 10.17487/RFC2119, March 1997, 237 . 239 6.2. Informative References 241 [DECONINCK-MP] 242 De Coninck, Q. and O. Bonaventure, "Multipath Extensions 243 for QUIC (MP-QUIC)", 2021, 244 . 247 [QUIC-MP-LIU] 248 Liu, Y., Ma, Y., Huitema, C., An, Q., and Z. Li, 249 "Multipath Extension for QUIC", 250 . 253 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 254 DOI 10.17487/RFC2629, June 1999, 255 . 257 Appendix A. Additional Stuff 259 This becomes an Appendix. 261 Authors' Addresses 263 Jiao Kang (editor) 264 Huawei 265 D2-03,Huawei Industrial Base 266 Shenzhen 267 China 269 Email: kangjiao@huawei.com 270 Qiandeng Liang 271 Huawei 272 No. 207, Jiufeng 3rd Road, East Lake High-tech Development Zone 273 Wuhan 274 China 276 Email: liangqiandeng@huawei.com 278 Peng Liu 279 China Mobile 280 32 Xuanwumen West Street, Xicheng District 281 Beijing 282 China 284 Email: liupengyjy@chinamobile.com