Internet Congestion Control T. Li, Ed. Internet-Draft K. Zheng, Ed. Intended status: Informational R. Jadhav, Ed. Expires: May 1, 2020 J. Kang Huawei Technologies October 29, 2019 Advancing ACK Handling for Wireless Transports draft-li-ack-handling-for-wireless-transports-00 Abstract Acknowledgement (ACK) is a basic function and implemented in most of the ordered and reliable transport protocols [RFC0793]. Traditional ACK is designed with high frequency to guarantee correct interaction between sender and receiver. Delayed byte-counting ACK or periodic ACK with large interval are proposed in prior work to reduce ACK intensity. High-throughput transport over wireless local area network (WLAN) becomes a demanding requirement with the emergence of 4K wireless projection, VR/AR-based interactive gaming, and more. However, the interference nature of the wireless medium induces an unavoidable contention between data transport and backward signaling, such as acknowledgement. This document presents the problems caused by high-intensity ACK in WLAN. We also analyze the possibility of ACK optimization in WLAN and the compatibility issues with existing systems. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 1, 2020. Li, et al. Expires May 1, 2020 [Page 1] Internet-Draft ACK for wireless October 2019 Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 3. Possibility of ACK Optimization on the Transport Layer . . . 3 4. Issues to handle . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Issues in loss recovery . . . . . . . . . . . . . . . . . 5 4.2. Issues in round-trip timing . . . . . . . . . . . . . . . 5 4.3. Issues in send rate control . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. 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 [RFC2119]. 2. Problem Statement It is well-studied that medium acquisition overhead in WLAN based on the IEEE 802.11 medium access control (MAC) protocol [WL] can severely hamper TCP throughput, and TCP's many small ACKs are one reason [Eugenio][Lynne]. Basically, TCP sends an ACK for every one or two incoming data packets. ACKs share the same medium route with data packets, causing similar medium access overhead despite the much smaller size of the ACKs [Eitan][RFC4341][Mario][Sara][Ruy]. Contentions and collisions, as well as the wasted wireless resources Li, et al. Expires May 1, 2020 [Page 2] Internet-Draft ACK for wireless October 2019 by ACKs, therefore lead to significant throughput decline on the data path. The WLAN bandwidth can be expanded by hardware modifications, such as 802.11ac and 802.11ax, in which channel binding is extended, or more spatial streams and high-density modulation are used. However, a faster physical (PHY) rate makes the MAC overhead problem even worse. This is because delay associated with medium acquisition wastes time and a higher PHY rate also proportionally increases ACK intensity for legacy TCP. Consequently, changes to the way of TCP acknowledgement that reduce medium acquisition overheads in WLAN and make a significant difference to throughput would be a relevant contribution. In order to improve transport performance over IEEE 802.11 wireless links, Salameh et al. [Lynne] proposed HACK by changing Wi-Fi MAC to carry TCP ACKs inside link-layer ACKs, this eliminates TCP ACK medium acquisitions and thus improves TCP goodput. On the other hand, the study of delaying more than two ACKs was first carried out by Altman and Jimenez [Eitan], followed by a line of ACK thinning technologies [Ammar][Farzaneh][Hong][Jiwei][RFC4341][RDe][Ruy][Rao] on the transport layer. Among them, some studies reduce ACK intensity by dropping selected ACKs on an intermediate node (e.g., a wireless AP or gateway). Due to asymmetry information, this intermediate management unavoidably makes endpoints in chaos when estimating transport-layer states, thus take untimely actions. Under these circumstances, some studies adopt the end-to-end solutions, which fall into two categories: (1) Byte-counting ACK that sends an ACK for every L (L>=2) incoming full sized packets. (2) Periodic ACK that sends an ACK for each time interval (or send window). However, simply reducing ACK intensity not only disturbs the packet clocking algorithms (e.g., send pattern, send window update and loss detection) and round-trip timing [Jbson], but also impairs the feedback robustness (e.g., more sensitive to ACK loss). The hurdle here is that legacy TCP couples the high ACK intensity with transport controls such as rapid loss detection, accurate round trip timing, and effective send rate control. 3. Possibility of ACK Optimization on the Transport Layer ACK intensity can be expressed as ACK frequency (denoted by f) with unit of Hz, i.e., number of ACKs per second. As above, ACK frequency can be reduced in two fundamental ways on the transport layer: 1. Byte-counting ACK: ACK frequency is in control by sending an ACK for every L (L>=2) incoming full-sized packets (packet size equals to the maximum segment size (MSS)) [Eitan][RFC4341][Sara][Rao]. The frequency of byte-counting ACK is proportional to data throughput bw: Li, et al. Expires May 1, 2020 [Page 3] Internet-Draft ACK for wireless October 2019 f(b) = bw/L*MSS (1) In general, f(b) can be reduced by setting a large L. However, for a given L, f(b) increases with bw. This means when data throughput is extremely high, the ACK frequency still might be comparatively large. In other words, the intensity of byte-counting ACK is not bounded under bandwidth change. 2. Periodic ACK: ACK frequency can be reduced by sending an ACK for each time interval alpha. The frequency of periodic ACK is: f(pack) = 1/alpha (2) The frequency of periodic ACK is decoupled from bw, this means when data throughput is extremely low, the ACK frequency is always as high as that in the case of a high throughput. In other words, the intensity of periodic ACK is not adaptable to bandwidth change, which wastes resources. To summarize, both of the above ways fail to match the number of ACKs to transport's required intensity under different network conditions (e.g, time-varying bit rate). A possible optimization can be combining these two ways, i.e., ACK frequency can be set as f = min{f(b),f(pack)}. Through Equations (1) and (2), we have f = min{bw/L*MSS, 1/alpha} (3) In 2006, Sally Floyd [RFC4341] proposed a tunable transport control variant in which the minimum ACK frequency allowed is twice per send window (i.e., per RTT). In 2007, Sara Landstrom [Sara] has also demonstrated that, in theory, acknowledging data twice per send window should be sufficient to ensure utilization with some modifications to the traditional TCP. Doubling the acknowledgment frequency to four times per send window can produce good performance and it is more robust in practice. Based on this rationale, we set alpha = RTTmin/beta, which means sending beta ACKs per RTTmin. RTTmin is the smallest RTT observed over a long period of time. As a consequence, the frequency can be given as follow: f = min{bw/L*MSS, beta/RTTmin} (4) where beta >= 2 according to Floyd and Landstrom's insights, and sets bw according to the maximum bandwidth estimate. Qualitatively, dynamic ACK interval is possible and feasible that means periodic ACK is applied when bandwidth delay product (bdp) is large (i.e., bdp >= beta*L*MSS), and falls back to byte-counting ACK when bdp is small (i.e., bdp < beta*L*MSS). Li, et al. Expires May 1, 2020 [Page 4] Internet-Draft ACK for wireless October 2019 4. Issues to handle 4.1. Issues in loss recovery It is learnt from experiments, compared to per-packet ACK, decreasing ACK frequency can cause feedback delay upon loss event. If ACK is lost or the retransmission is lost again, then the delay doubles. 4.2. Issues in round-trip timing Multiple data packets might be received during the ACK interval, generating only one RTT sample among multiple packets is likely to result in biases. For example, a larger minimum RTT estimate and a smaller maximum RTT estimate. In general, the higher the throughput, the larger the biases. 4.3. Issues in send rate control A burst of packets can be sent in response to a single delayed ACK. Traditional TCP usually sends micro bursts of one to three packets, which is bounded by L <= 2 according to definition of TCP's delayed ACK. However, the fewer ACKs sent, the larger the bursts of packets released. Send window update requires ACKs to update the largest acknowledged packet and the announcement window (AWND). With a small frequency, ACKs probably delay acknowledging packet receipts and reporting the AWND, resulting in feedback lags and bandwidth under- utilization. 5. Security Considerations This document neither strengthens nor weakens TCP's current security properties. 6. IANA Considerations This document is the problem statement. This section will be completed when further solution is proposed. 7. References 7.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . Li, et al. Expires May 1, 2020 [Page 5] Internet-Draft ACK for wireless October 2019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2006, . 7.2. Informative References [Ammar] Al-Jubari, A. M., "An adaptive delayed acknowledgment strategy to improve tcp performance in multi-hop wireless networks", Springer WPC 69(1):307-333, 2013. [Eitan] Altman, E. and T. Jimenez, "Novel delayed ack techniques for improving tcp performance in multihop wireless networks", In Proceedings of IFIP PWC pages 237-250, 2003. [Eugenio] Magistretti, E., Chintalapudi, K. K., Radunovic, B., and R. Ramjee, "Wifi-nano: Reclaiming wifi efficiency through 800 ns slots", In Proceedings of ACM MobiCom pages 37-48, 2011. [Farzaneh] Armaghani, F. R., Jamuar, S. S., Khatun, S., and M. F. A, "Performance analysis of tcp with delayed acknowledgments in multi-hop ad-hoc networks", Springer WPC 56(4):791-811, 2011. [Hong] Chen, H., Guo, Z., Yao, R. Y., Shen, X., and Y. Li, "Performance analysis of delayed acknowledgment scheme in uwb-based high-rate wpan", IEEE TVT 55(2):606-621, 2006. [Jbson] Jacobson, V., "Congestion avoidance and control", ACM SIGCOMM CCR 18(4):314-329, 1988. [Jiwei] Chen, J., Gerla, M., Lee, Y. Z., and M. Y.Sanadidi, "Tcp with delayed ack for wireless networks", Networks 6(7):1098-1116, 2008. [Lynne] Salameh, L., Zhushi, A., Handley, M., Jamieson, K., and B. Karp, "Hack: Hierarchical acks for efficient wireless medium utilization.", In Proceedings of USENIX ATC pages 359-370, 2014. Li, et al. Expires May 1, 2020 [Page 6] Internet-Draft ACK for wireless October 2019 [Mario] Gerla, M., Tang, K., and R. Bagrodia, "Tcp performance in wireless multi-hop networks", In Proceedings of IEEE WMCSA pages 1-10, 1999. [Rao] Rao, K. N., Krishna, Y. K. S., and K.Lakshminadh, "Improving tcp performance with delayed acknowledgments over wireless networks: A receiver side solution", In IET Communication and Computing , 2013. [RDe] Oliveira, R. D. and T. Braun, "A dynamic adaptive acknowledgment strategy for tcp over multihop wireless networks". [Ruy] Oliveira, R. D. and T. Braun, "A smart tcp acknowledgment approach for multihop wireless networks", IEEE TMC 6(2):192-205, 2006. [Sara] Landstrom, S. and L. Larzon, "Reducing the tcp acknowledgment frequency", ACM SIGCOMM CCR 37(3):5-16, 2007. [WL] IEEE Standards Association, "Wireless lan medium access control (mac) and physical layer (phy) specifications", 2016, . Authors' Addresses Tong Li (editor) Huawei Technologies D2-03,Huawei Industrial Base Longgang District Shenzhen China Email: li.tong@huawei.com Kai Zheng (editor) Huawei Technologies Information Road, Haidian District Beijing China Email: kai.zheng@huawei.com Li, et al. Expires May 1, 2020 [Page 7] Internet-Draft ACK for wireless October 2019 Rahul Arvind Jadhav (editor) Huawei Technologies Kundalahalli Village, Whitefield, Bangalore, Karnataka 560037 India Phone: +91-080-49160700 Email: rahul.ietf@gmail.com Jiao Kang Huawei Technologies D2-03,Huawei Industrial Base Longgang District Shenzhen China Email: kangjiao@huawei.com Li, et al. Expires May 1, 2020 [Page 8]