idnits 2.17.1 draft-li-quic-optimizing-ack-in-wlan-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 date (April 20, 2020) is 1460 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-27 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC T. Li 3 Internet-Draft K. Zheng 4 Intended status: Experimental R. Jadhav 5 Expires: October 22, 2020 J. Kang 6 Huawei Technologies 7 April 20, 2020 9 Optimizing ACK mechanism for QUIC 10 draft-li-quic-optimizing-ack-in-wlan-00 12 Abstract 14 This document analyzes the problems caused by contentions and 15 collisions on wireless medium between data packets and ACKs in WLAN 16 and it proposes an optimized ACK mechanism that can minimize the 17 intensity of ACK Frame in QUIC, improving the performance of 18 transport layer connection. 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 October 22, 2020. 37 Copyright Notice 39 Copyright (c) 2020 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 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 55 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 56 3. ACK Mechanism in Current QUIC . . . . . . . . . . . . . . . . 2 57 4. Optimized ACK Mechanism for QUIC . . . . . . . . . . . . . . 3 58 4.1. Reducing ACK intensity . . . . . . . . . . . . . . . . . 3 59 4.2. OWD-based RTTmin estimation . . . . . . . . . . . . . . . 4 60 4.3. Sender-Side Operation . . . . . . . . . . . . . . . . . . 6 61 4.4. Receiver-side Operation . . . . . . . . . . . . . . . . . 7 62 4.5. Generating ACK . . . . . . . . . . . . . . . . . . . . . 7 63 4.6. Modification to QUIC Protocol . . . . . . . . . . . . . . 7 64 4.6.1. Transport Parameter: ack-intensity-support . . . . . 7 65 4.6.2. ACK-INTENSITY Frame . . . . . . . . . . . . . . . . . 8 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 7.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Requirements Language 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [RFC2119]. 79 2. Problem Statement 81 High-throughput transport over wireless local area network (WLAN) 82 becomes a demanding requirement with the emergence of 4K wireless 83 projection, VR/AR-based interactive gaming, and more. However, the 84 shared nature of the wireless medium induces contention between data 85 transport and backward signaling, such as acknowledgement. ACKs 86 share the same medium route with data packets, causing similar medium 87 access overhead despite the much smaller size of the ACKs. 88 Contentions and collisions, as well as the wasted wireless resources 89 by ACKs, lead to significant throughput decline on the data path. 91 3. ACK Mechanism in Current QUIC 93 [QUIC-TRANSPORT] specifies a simple delayed ACK mechanism that a 94 receiver can send an ACK for every other packet, and for every packet 95 when reordering is observed, or when the max_ack_delay timer expires. 96 However, this ACK mechanism may not match the number of ACKs to the 97 transport's required intensity under different network conditions. 98 For example, when the data throughput of a WLAN transport is 99 extremely high, QUIC will generate a large number of ACKs. In this 100 case, minimizing the ACK intensity of QUIC is not only a win for data 101 throughput improvement but also a win for energy and CPU efficiency. 103 4. Optimized ACK Mechanism for QUIC 105 4.1. Reducing ACK intensity 107 ACK intensity can be quantified by the unit of Hz, i.e., number of 108 ACKs per second. Byte-counting ACK and periodic ACK are two 109 fundamental ways to reduce ACK intensity on the transport layer. 111 1. Byte-counting ACK: ACK intensity is controlled by sending an ACK 112 for every L (L >= 2) incoming full-sized packets, in which the packet 113 size equals to the Max Packet Size (set in the max_packet_size 114 parameter in QUIC). The intensity of byte-counting ACK (f_b) is 115 proportional to data throughput (bw): 117 f_b = bw/L*max_packet_size (1) 119 In general, f_b can be reduced by setting a large value of L. 120 However, for a given L, f_b increases with bw. This means when data 121 throughput is extremely high, the ACK intensity still might be 122 comparatively large. In other words, the intensity of byte-counting 123 ACK changes proportionately with bandwidth. 125 2. Periodic ACK: Byte-counting ACK's unbounded intensity can be 126 attributed to the coupling between ACK sending and packet arrivals. 127 Periodic ACK can decouple ACK intensity from packet arrivals, 128 achieving a bounded ACK intensity when bw is high. The intensity of 129 periodic ACK (f_pack) is: 131 f_pack = 1/alpha (2) 133 Where alpha is the time interval between two ACKs and is a function 134 of RTT. However, when bw is extremely low, the ACK intensity is 135 always as high as that in the case of a high throughput. In other 136 words, the intensity of periodic ACK is unadaptable to bandwidth 137 change, which wastes resources. 139 Combining these two ways, the minimum ACK intensity in a QUIC 140 connection can be set as f_quic = min{f_b,f_pack}. Through Equations 141 (1) and (2), we have 143 f_quic = min{bw/(L*max_packet_size), 1/alpha} (3) 144 We set alpha = RTTmin/beta, which means sending beta ACKs per RTTmin. 145 RTTmin is the minimum RTT observed for a given network path. As a 146 consequence, the minimum ACK intensity in a QUIC connection can be 147 given as follow: 149 f_quic = min{bw/(L*max_packet_size), beta/RTTmin} (4) 151 where beta indicates the number of ACKs per RTT, and L indicates the 152 number of full-sized data packets counted before sending an ACK. To 153 minimize the ACK intensity, a smaller beta or a larger L is expected. 154 Sara Landstrom et al. has given a lower bound of beta in [Sara], 155 i.e., beta >= 2. An upper bound of L can also be derived according 156 to the loss rate on the data path (plr_data) and the ack path 157 (plr_ack), i.e., L <= feedback_info/(plr_data*plr_ack), where 158 feedback_info denotes the amount of information carried by an ACK 160 Qualitatively, periodic ACK is applied when bandwidth-delay product 161 (bdp) is large (i.e., bdp >= beta*L* max_packet_size), and byte- 162 counting ACK is applied when bdp is small (i.e., bdp < beta*L* 163 max_packet_size). 165 In terms of a transport with a large bdp, beta = 2 should be 166 sufficient to ensure utilization, but the large bottleneck buffer 167 (i.e., one bdp) makes it necessary to acknowledge data more often. 168 In general, the minimum send window (SWNDmin) can be roughly 169 estimated as follow: 171 SWNDmin = beta*bdp/(beta-1) (5) 173 Ideally, the bottleneck buffer requirement is decided by the minimum 174 send window, i.e., SWNDmin - bdp. Since doubling the ACK frequency 175 reduces the bottleneck buffer requirement substantially from 1 bdp to 176 0.33 bdp, beta = 4 is RECOMMENDED to provide redundancy [Sara], being 177 more robust in practice. 179 4.2. OWD-based RTTmin estimation 181 In this document, the RTTmin is the minimum RTT samples observed at 182 the sender for a given network path during a period of time, and 183 OWDmin is the minimum OWD samples observed on the same network path 184 during a period of time. 186 When multiple packets carrying departure timestamps are transported 187 between endpoints via the same path, an RTT of this path can be 188 sampled at the sender upon receiving an ACK frame. However, when 189 sending fewer ACK frames, more data packets might be received during 190 the ACK interval, generating only one RTT sample among multiple 191 packets is likely to result in biases. For example, a larger minimum 192 RTT estimate. In general, the higher the throughput, the larger the 193 biases. One alternative way to reduce biases can be that, each ACK 194 frame carries multiple timestamps (as well as ACK delays in 195 [QUIC-RECOVERY] for the sender to generate more RTT samples. 196 However, (1) the overhead is high, which is unacceptable especially 197 under high-bandwidth transport. Also, (2) the number of data packets 198 might be far more than the maximum number of timestamps that an ACK 199 frame is capable to carry. 201 An RTT estimation system contains a sender and a receiver. The 202 sender can hardly generate per-packet RTT samples, which is the root 203 cause of the minimum RTT estimation biases in the case of sending 204 fewer ACKs. When multiple packets carrying departure timestamps are 205 transported between endpoints via the same path , an RTT of this path 206 can be sampled at the sender upon receiving an ACK frame. However, 207 when sending fewer ACK frames, more data packets might be received 208 during the ACK interval, generating only one RTT sample among 209 multiple packets is likely to result in biases. For example, a 210 larger minimum RTT estimate. In general, the higher the throughput, 211 the larger the biases. One alternative way to reduce biases can be 212 that, each ACK frame carries multiple timestamps (as well as ACK 213 delays in [QUIC-RECOVERY]) for the sender to generate more RTT 214 samples. However, (1) the overhead is high, which is unacceptable 215 especially under high-bandwidth transport. Also, (2) the number of 216 data packets might be far more than the maximum number of timestamps 217 that an ACK frame is capable to carry. Since the receiver is capable 218 to monitor per-packet state, the one-way delay (OWD) of each packet 219 can be easily computed according to the departure timestamps (carried 220 in the packet) and the arrival timestamps of each packet. In this 221 case, QUIC SHOULD adopt the OWD-based RTTmin estimation. The 222 rationale is that the variation of OWD reflects the variation of RTT 223 over near-symmetric links. The OWD-based RTTmin estimation requires 224 the sender to record the departure timestamp in each ack-eliciting 225 packet. Meanwhile, at the receiver, the per-packet OWD samples 226 SHOULD be computed upon packet arrivals and a function of computing 227 the minimum OWD SHOULD be newly added. The receiver then generates 228 an ACK frame to the sender, in which the ACK delay and departure 229 timestamp for the packet that achieves the minimum OWD is reported. 230 The ACK delay is defined as the delay incurred between when the 231 packet is received and when the ACK frame is sent. Based on the 232 information reported by the incoming ACK frames and the ACK arrival 233 timestamps, the sender can generate RTT samples and then compute 234 RTTmin accordingly. 236 In this document, RTTmin is used to update the ACK intensity. In 237 general, RTTmin can also be used by other modules. For example, some 238 congestion controllers depends on RTTmin to estimate the congestion 239 window [Neal]. RTTmin is also used by QUIC loss detection to reject 240 implausibly small rtt samples [QUIC-RECOVERY]. 242 4.3. Sender-Side Operation 244 According to Formula (4), the run-time ACK intensity in QUIC are 245 decided by bw, and RTTmin. Generally, the RTTmin and bw are 246 calculated at the sender. 248 Before estimating the RTTmin, the RTT samples should be computed 249 based on the ACK frames collected during a period of time. Assume 250 that a packet is sent by the sender at time t_1 and arrives at time 251 t_3, and the ACK frame is sent at time t_4. The ACK delay can be 252 computed at the receiver. For example, the receiver computes the ACK 253 delay delta_t = t_4 - t_3, and syncs the ACK delay to the sender via 254 an ACK frame. The ACK delay can also be computed at the sender. For 255 example, the receiver directly syncs an ACK frame carrying t_4 and 256 t_3 to the sender, the sender then computes the ACK delay delta_t = 257 t_4 - t_3. 259 The sender therefore computes an RTT sample according to delta_t, 260 t_1, and the arrival time (t_2) of the ACK frame, i.e., RTT_sample = 261 t_2 - t_1 - delta_t. Measuring delta_t at the receiver assures an 262 explicit correction for a more accurate RTT estimate. RTT samples 263 SHOULD be smoothed using exponentially weighted moving average (EWMA) 264 as specified in [RFC6298]. The sender then computes the RTTmin 265 according to these RTT samples during a period of time. 267 The bw estimation can be acquired in a similar manner to BBR [Neal]. 268 Since minimizing the ACK intensity induces excessive ACK delay, the 269 value of bw may be the average value over a long period of time. 270 However, the biases introduced in ACK intensity computation is 271 limited. 273 After computing the f_quic, the sender periodically syncs it to the 274 receiver to update the intensity of ACK Frame by sending a new ACK- 275 INTENSITY frame. 277 The sender SHOULD generate an ACK-INTENSITY frame on a regular basis. 278 For example, when the change of f_quic exceeds a threshold, the ACK- 279 INTENSITY frame should be sent to update the ACK intensity in time. 280 The interval of ACK-INTENSITY frame can also be set according to the 281 update window of RTTmin and bw. 283 4.4. Receiver-side Operation 285 Currently, the QUIC receiver reports ACK delays for only the largest 286 acknowledged packet in an ACK frame, hence an RTT sample is generated 287 using only the largest acknowledged packet in the received ACK frame. 288 For a more accurate RTTmin estimate when sending fewer ACK frames, 289 QUIC SHOULD adopt the OWD-based RTTmin estimation. The OWD-based 290 RTTmin estimation requires the QUIC receiver to filter the departure 291 timestamp for the packet that achieves the minimum OWD during the 292 interval between two ACK frames and report the ACK delay of this 293 packet. Whether redefining the meaning of ACK delay or not, it 294 depends on the negotiation between endpoints of the QUIC connection. 296 Upon packet arrivals, the receiver is capable to generate per-packet 297 OWD samples according to the difference between packet departure 298 timestamp and packet arrival timestamp. The receiver then computes 299 the minimum OWD by comparing the per-packet OWD samples. The OWD 300 estimation does not require clock synchronization here because the 301 relative values are adopted. 303 Afterwards, based on the ACK delay and the departure timestamp 304 corresponding to the packet that achieves the minimum OWD, the sender 305 calculates the RTT of this packet as a minimum RTT sample. 306 Ultimately, the minimum RTT is computed according to these minimum 307 RTT samples. 309 The ACK Delay field SHOULD be carried in the ACK Frame. Other fields 310 carried in the ACK frame have the same meaning as defined in 311 [QUIC-RECOVERY]. 313 The receiver adopts the newly updated ACK intensity once it receives 314 the ACK-INTENSITY frame from the sender. 316 4.5. Generating ACK 318 The newly proposed ACK mechanismSHOULD be applied when there is no 319 out-of-order delivery. When reordering happens, the ACK Frame SHOULD 320 be generated immediately. 322 4.6. Modification to QUIC Protocol 324 4.6.1. Transport Parameter: ack-intensity-support 326 A new field named ack-intensity-support should be added for 327 negotiation between both parties whether starting the dynamic ACK 328 intensity function in QUIC connection. The endpoints sends this 329 parameter during handshakes. Only when both parties agree, ACK 330 intensity refreshment can be adopted. 332 ack-intensity-support (0x XX):This parameter has two values (0 or 1) 333 specifying whether the sending endpoint is willing to adopt ACK 334 intensity refreshment. When the value is set as 1, it means that the 335 sending endpoint want to start ACK intensity refreshment during 336 connection. When the value is set as 0, it means that the sending 337 endpoint does not support this function. 339 4.6.2. ACK-INTENSITY Frame 341 An ACK-INTENSITY frame is shown in Figure 1. 343 0 1 2 3 344 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | 0x XX ... 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Sequence Number(i) ... 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | ACK Intensity (i) ... 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Figure 1: ACK-INTENSITY Frame 355 An ACK-INTENSITY frame contains the following fields: 357 Sequence Number: A variable-length integer indicating the sequence 358 number assigned to the ACK-INTENSITY frame by the sender. 360 ACK Intensity: A variable-length integer indicating the updated 361 f_quic calculated by the sender. 363 ACK-INTENSITY frames are ack-eliciting. However, their loss does not 364 require retransmission. 366 Multiple ACK-INTENSITY frames SHOULD be generated by the sender 367 during a connection to notify the receiver the variation of ACK 368 intensity requirement under network dynamics. 370 5. Security Considerations 372 TBD 374 6. IANA Considerations 376 The value for ack-intensity-support transport parameter and ACK- 377 INTENSITY frame should be allocated. 379 7. References 381 7.1. Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, 385 DOI 10.17487/RFC2119, March 1997, 386 . 388 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 389 "Computing TCP's Retransmission Timer", RFC 6298, 390 DOI 10.17487/RFC6298, June 2011, 391 . 393 7.2. Informative References 395 [Neal] Cardwell, N., Cheng, Y., Gunn, C. S., Yeganeh, S. H., and 396 V. Jacobson, "BBR: Congestion-based congestion control", 397 ACM QUEUE 14(5):20-53, 2016. 399 [QUIC-RECOVERY] 400 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 401 and Congestion Control", draft-ietf-quic-recovery-27 (work 402 in progress), February 2020. 404 [QUIC-TRANSPORT] 405 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 406 Multiplexed and Secure Transport", draft-ietf-quic- 407 transport-27 (work in progress), March 2020. 409 [Sara] Landstrom, S. and L. Larzon, "Reducing the tcp 410 acknowledgment frequency", ACM SIGCOMM CCR 37(3):5-16, 411 2007. 413 Authors' Addresses 415 Tong Li 416 Huawei Technologies 417 D2-03,Huawei Industrial Base 418 Longgang District 419 Shenzhen 420 China 422 Email: li.tong@huawei.com 423 Kai Zheng 424 Huawei Technologies 425 Information Road, Haidian District 426 Beijing 427 China 429 Email: kai.zheng@huawei.com 431 Rahul Arvind Jadhav 432 Huawei Technologies 433 D2-03,Huawei Industrial Base 434 Longgang District 435 Shenzhen 436 China 438 Email: rahul.jadhav@huawei.com 440 Jiao Kang 441 Huawei Technologies 442 D2-03,Huawei Industrial Base 443 Longgang District 444 Shenzhen 445 China 447 Email: kangjiao@huawei.com