idnits 2.17.1 draft-li-ack-handling-for-wireless-transports-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([RFC0793]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (October 29, 2019) is 1634 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Congestion Control T. Li, Ed. 3 Internet-Draft K. Zheng, Ed. 4 Intended status: Informational R. Jadhav, Ed. 5 Expires: May 1, 2020 J. Kang 6 Huawei Technologies 7 October 29, 2019 9 Advancing ACK Handling for Wireless Transports 10 draft-li-ack-handling-for-wireless-transports-00 12 Abstract 14 Acknowledgement (ACK) is a basic function and implemented in most of 15 the ordered and reliable transport protocols [RFC0793]. Traditional 16 ACK is designed with high frequency to guarantee correct interaction 17 between sender and receiver. Delayed byte-counting ACK or periodic 18 ACK with large interval are proposed in prior work to reduce ACK 19 intensity. 21 High-throughput transport over wireless local area network (WLAN) 22 becomes a demanding requirement with the emergence of 4K wireless 23 projection, VR/AR-based interactive gaming, and more. However, the 24 interference nature of the wireless medium induces an unavoidable 25 contention between data transport and backward signaling, such as 26 acknowledgement. 28 This document presents the problems caused by high-intensity ACK in 29 WLAN. We also analyze the possibility of ACK optimization in WLAN 30 and the compatibility issues with existing systems. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 1, 2020. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 67 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 68 3. Possibility of ACK Optimization on the Transport Layer . . . 3 69 4. Issues to handle . . . . . . . . . . . . . . . . . . . . . . 5 70 4.1. Issues in loss recovery . . . . . . . . . . . . . . . . . 5 71 4.2. Issues in round-trip timing . . . . . . . . . . . . . . . 5 72 4.3. Issues in send rate control . . . . . . . . . . . . . . . 5 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 77 7.2. Informative References . . . . . . . . . . . . . . . . . 6 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 2. Problem Statement 88 It is well-studied that medium acquisition overhead in WLAN based on 89 the IEEE 802.11 medium access control (MAC) protocol [WL] can 90 severely hamper TCP throughput, and TCP's many small ACKs are one 91 reason [Eugenio][Lynne]. Basically, TCP sends an ACK for every one 92 or two incoming data packets. ACKs share the same medium route with 93 data packets, causing similar medium access overhead despite the much 94 smaller size of the ACKs [Eitan][RFC4341][Mario][Sara][Ruy]. 95 Contentions and collisions, as well as the wasted wireless resources 96 by ACKs, therefore lead to significant throughput decline on the data 97 path. 99 The WLAN bandwidth can be expanded by hardware modifications, such as 100 802.11ac and 802.11ax, in which channel binding is extended, or more 101 spatial streams and high-density modulation are used. However, a 102 faster physical (PHY) rate makes the MAC overhead problem even worse. 103 This is because delay associated with medium acquisition wastes time 104 and a higher PHY rate also proportionally increases ACK intensity for 105 legacy TCP. Consequently, changes to the way of TCP acknowledgement 106 that reduce medium acquisition overheads in WLAN and make a 107 significant difference to throughput would be a relevant 108 contribution. 110 In order to improve transport performance over IEEE 802.11 wireless 111 links, Salameh et al. [Lynne] proposed HACK by changing Wi-Fi MAC to 112 carry TCP ACKs inside link-layer ACKs, this eliminates TCP ACK medium 113 acquisitions and thus improves TCP goodput. On the other hand, the 114 study of delaying more than two ACKs was first carried out by Altman 115 and Jimenez [Eitan], followed by a line of ACK thinning technologies 116 [Ammar][Farzaneh][Hong][Jiwei][RFC4341][RDe][Ruy][Rao] on the 117 transport layer. Among them, some studies reduce ACK intensity by 118 dropping selected ACKs on an intermediate node (e.g., a wireless AP 119 or gateway). Due to asymmetry information, this intermediate 120 management unavoidably makes endpoints in chaos when estimating 121 transport-layer states, thus take untimely actions. Under these 122 circumstances, some studies adopt the end-to-end solutions, which 123 fall into two categories: (1) Byte-counting ACK that sends an ACK for 124 every L (L>=2) incoming full sized packets. (2) Periodic ACK that 125 sends an ACK for each time interval (or send window). However, 126 simply reducing ACK intensity not only disturbs the packet clocking 127 algorithms (e.g., send pattern, send window update and loss 128 detection) and round-trip timing [Jbson], but also impairs the 129 feedback robustness (e.g., more sensitive to ACK loss). The hurdle 130 here is that legacy TCP couples the high ACK intensity with transport 131 controls such as rapid loss detection, accurate round trip timing, 132 and effective send rate control. 134 3. Possibility of ACK Optimization on the Transport Layer 136 ACK intensity can be expressed as ACK frequency (denoted by f) with 137 unit of Hz, i.e., number of ACKs per second. As above, ACK frequency 138 can be reduced in two fundamental ways on the transport layer: 140 1. Byte-counting ACK: ACK frequency is in control by sending an ACK 141 for every L (L>=2) incoming full-sized packets (packet size equals to 142 the maximum segment size (MSS)) [Eitan][RFC4341][Sara][Rao]. The 143 frequency of byte-counting ACK is proportional to data throughput bw: 145 f(b) = bw/L*MSS (1) 147 In general, f(b) can be reduced by setting a large L. However, for a 148 given L, f(b) increases with bw. This means when data throughput is 149 extremely high, the ACK frequency still might be comparatively large. 150 In other words, the intensity of byte-counting ACK is not bounded 151 under bandwidth change. 153 2. Periodic ACK: ACK frequency can be reduced by sending an ACK for 154 each time interval alpha. The frequency of periodic ACK is: 156 f(pack) = 1/alpha (2) 158 The frequency of periodic ACK is decoupled from bw, this means when 159 data throughput is extremely low, the ACK frequency is always as high 160 as that in the case of a high throughput. In other words, the 161 intensity of periodic ACK is not adaptable to bandwidth change, which 162 wastes resources. 164 To summarize, both of the above ways fail to match the number of ACKs 165 to transport's required intensity under different network conditions 166 (e.g, time-varying bit rate). A possible optimization can be 167 combining these two ways, i.e., ACK frequency can be set as f = 168 min{f(b),f(pack)}. Through Equations (1) and (2), we have 170 f = min{bw/L*MSS, 1/alpha} (3) 172 In 2006, Sally Floyd [RFC4341] proposed a tunable transport control 173 variant in which the minimum ACK frequency allowed is twice per send 174 window (i.e., per RTT). In 2007, Sara Landstrom [Sara] has also 175 demonstrated that, in theory, acknowledging data twice per send 176 window should be sufficient to ensure utilization with some 177 modifications to the traditional TCP. Doubling the acknowledgment 178 frequency to four times per send window can produce good performance 179 and it is more robust in practice. Based on this rationale, we set 180 alpha = RTTmin/beta, which means sending beta ACKs per RTTmin. 181 RTTmin is the smallest RTT observed over a long period of time. As a 182 consequence, the frequency can be given as follow: 184 f = min{bw/L*MSS, beta/RTTmin} (4) 186 where beta >= 2 according to Floyd and Landstrom's insights, and sets 187 bw according to the maximum bandwidth estimate. 189 Qualitatively, dynamic ACK interval is possible and feasible that 190 means periodic ACK is applied when bandwidth delay product (bdp) is 191 large (i.e., bdp >= beta*L*MSS), and falls back to byte-counting ACK 192 when bdp is small (i.e., bdp < beta*L*MSS). 194 4. Issues to handle 196 4.1. Issues in loss recovery 198 It is learnt from experiments, compared to per-packet ACK, decreasing 199 ACK frequency can cause feedback delay upon loss event. If ACK is 200 lost or the retransmission is lost again, then the delay doubles. 202 4.2. Issues in round-trip timing 204 Multiple data packets might be received during the ACK interval, 205 generating only one RTT sample among multiple packets is likely to 206 result in biases. For example, a larger minimum RTT estimate and a 207 smaller maximum RTT estimate. In general, the higher the throughput, 208 the larger the biases. 210 4.3. Issues in send rate control 212 A burst of packets can be sent in response to a single delayed ACK. 213 Traditional TCP usually sends micro bursts of one to three packets, 214 which is bounded by L <= 2 according to definition of TCP's delayed 215 ACK. However, the fewer ACKs sent, the larger the bursts of packets 216 released. Send window update requires ACKs to update the largest 217 acknowledged packet and the announcement window (AWND). With a small 218 frequency, ACKs probably delay acknowledging packet receipts and 219 reporting the AWND, resulting in feedback lags and bandwidth under- 220 utilization. 222 5. Security Considerations 224 This document neither strengthens nor weakens TCP's current security 225 properties. 227 6. IANA Considerations 229 This document is the problem statement. This section will be 230 completed when further solution is proposed. 232 7. References 234 7.1. Normative References 236 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 237 RFC 793, DOI 10.17487/RFC0793, September 1981, 238 . 240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels", BCP 14, RFC 2119, 242 DOI 10.17487/RFC2119, March 1997, 243 . 245 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 246 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 247 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 248 2006, . 250 7.2. Informative References 252 [Ammar] Al-Jubari, A. M., "An adaptive delayed acknowledgment 253 strategy to improve tcp performance in multi-hop wireless 254 networks", Springer WPC 69(1):307-333, 2013. 256 [Eitan] Altman, E. and T. Jimenez, "Novel delayed ack techniques 257 for improving tcp performance in multihop wireless 258 networks", In Proceedings of IFIP PWC pages 237-250, 2003. 260 [Eugenio] Magistretti, E., Chintalapudi, K. K., Radunovic, B., and 261 R. Ramjee, "Wifi-nano: Reclaiming wifi efficiency through 262 800 ns slots", In Proceedings of ACM MobiCom pages 37-48, 263 2011. 265 [Farzaneh] 266 Armaghani, F. R., Jamuar, S. S., Khatun, S., and M. F. A, 267 "Performance analysis of tcp with delayed acknowledgments 268 in multi-hop ad-hoc networks", Springer WPC 56(4):791-811, 269 2011. 271 [Hong] Chen, H., Guo, Z., Yao, R. Y., Shen, X., and Y. Li, 272 "Performance analysis of delayed acknowledgment scheme in 273 uwb-based high-rate wpan", IEEE TVT 55(2):606-621, 2006. 275 [Jbson] Jacobson, V., "Congestion avoidance and control", ACM 276 SIGCOMM CCR 18(4):314-329, 1988. 278 [Jiwei] Chen, J., Gerla, M., Lee, Y. Z., and M. Y.Sanadidi, "Tcp 279 with delayed ack for wireless networks", 280 Networks 6(7):1098-1116, 2008. 282 [Lynne] Salameh, L., Zhushi, A., Handley, M., Jamieson, K., and B. 283 Karp, "Hack: Hierarchical acks for efficient wireless 284 medium utilization.", In Proceedings of USENIX ATC pages 285 359-370, 2014. 287 [Mario] Gerla, M., Tang, K., and R. Bagrodia, "Tcp performance in 288 wireless multi-hop networks", In Proceedings of IEEE 289 WMCSA pages 1-10, 1999. 291 [Rao] Rao, K. N., Krishna, Y. K. S., and K.Lakshminadh, 292 "Improving tcp performance with delayed acknowledgments 293 over wireless networks: A receiver side solution", In IET 294 Communication and Computing , 2013. 296 [RDe] Oliveira, R. D. and T. Braun, "A dynamic adaptive 297 acknowledgment strategy for tcp over multihop wireless 298 networks". 300 [Ruy] Oliveira, R. D. and T. Braun, "A smart tcp acknowledgment 301 approach for multihop wireless networks", IEEE 302 TMC 6(2):192-205, 2006. 304 [Sara] Landstrom, S. and L. Larzon, "Reducing the tcp 305 acknowledgment frequency", ACM SIGCOMM CCR 37(3):5-16, 306 2007. 308 [WL] IEEE Standards Association, "Wireless lan medium access 309 control (mac) and physical layer (phy) specifications", 310 2016, . 312 Authors' Addresses 314 Tong Li (editor) 315 Huawei Technologies 316 D2-03,Huawei Industrial Base 317 Longgang District 318 Shenzhen 319 China 321 Email: li.tong@huawei.com 323 Kai Zheng (editor) 324 Huawei Technologies 325 Information Road, Haidian District 326 Beijing 327 China 329 Email: kai.zheng@huawei.com 330 Rahul Arvind Jadhav (editor) 331 Huawei Technologies 332 Kundalahalli Village, Whitefield, 333 Bangalore, Karnataka 560037 334 India 336 Phone: +91-080-49160700 337 Email: rahul.ietf@gmail.com 339 Jiao Kang 340 Huawei Technologies 341 D2-03,Huawei Industrial Base 342 Longgang District 343 Shenzhen 344 China 346 Email: kangjiao@huawei.com