Internet DRAFT - draft-li-ack-handling-for-wireless-transports

draft-li-ack-handling-for-wireless-transports







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,
              <https://www.rfc-editor.org/info/rfc793>.






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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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, <https://www.rfc-editor.org/info/rfc4341>.

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, <https://ieeexplore.ieee.org/document/7786995>.

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]