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]
