TCP Maintenance and Minor Extensions T. Li
Internet-Draft K. Zheng
Intended status: Experimental R. Jadhav
Expires: September 7, 2020 J. Kang
Huawei Technologies
March 6, 2020
Advancing ACK Handling for Wireless Transports
draft-li-tcpm-advancing-ack-for-wireless-00
Abstract
Acknowledgement (ACK) is a basic function and implemented in most of
the ordered and reliable transport protocols [RFC0793]. Legacy TCP
ACK is designed with high frequency to guarantee correct interaction
between sender and receiver. However, the shared nature of the
wireless medium over wireless local area network (WLAN) induces
contention between data transport and backward signaling, such as
acknowledgement. The current way of TCP acknowledgment induces
control overhead which is counter-productive for TCP performance
especially for WLAN scenarios.
This document conducts the ACK frequency breakdown, analyzes several
ways of reducing ACK frequency, and discusses the compatibility
issues with existing systems in detail.
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 September 7, 2020.
Li, et al. Expires September 7, 2020 [Page 1]
Internet-Draft Advancing ACK for Wireless March 2020
Copyright Notice
Copyright (c) 2020 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. ACK Frequency Minimization on the Transport Layer . . . . . . 4
3.1. Ways to reduce ACK frequency . . . . . . . . . . . . . . 4
3.2. Provisioning for TACK . . . . . . . . . . . . . . . . . . 5
3.3. Benefits for applying TACK . . . . . . . . . . . . . . . 6
4. Difference between delayed ACK and TACK . . . . . . . . . . . 6
5. Compatibility issues . . . . . . . . . . . . . . . . . . . . 7
5.1. Issues in loss recovery . . . . . . . . . . . . . . . . . 7
5.2. Issues in round-trip timing . . . . . . . . . . . . . . . 8
5.3. Issues in send pattern . . . . . . . . . . . . . . . . . 8
5.4. Issues in startup cwnd update . . . . . . . . . . . . . . 8
5.5. Issues in awnd update . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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
Li, et al. Expires September 7, 2020 [Page 2]
Internet-Draft Advancing ACK for Wireless March 2020
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
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 frequency for
legacy TCP. Consequently, rethinking the way of TCP acknowledgement
that reduce medium acquisition overheads in WLAN, so as to improve
transport 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, which 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
frequency 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). Both
fail to match the number of ACKs to transport's required frequency
under different network conditions (e.g, time-varying data
throughput). Tame ACK (TACK) is suggested to combines these two
approaches, achieving a minimized ACK frequency under different
network scenarios.
However, simply reducing ACK frequency not only disturbs the packet
clocking algorithms (e.g., loss recovery, send pattern, window
update) 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 frequency with transport
controls such as rapid loss detection, accurate round trip timing,
and effective send rate control.
Li, et al. Expires September 7, 2020 [Page 3]
Internet-Draft Advancing ACK for Wireless March 2020
3. ACK Frequency Minimization on the Transport Layer
3.1. Ways to reduce ACK frequency
ACK frequency can be denoted by f with unit of Hz, i.e., number of
ACKs per second. Byte-counting ACK and periodic ACK are two
fundamental ways to reduce ACK frequency 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):
f(b) = bw/L*MSS (1)
In general, f(b) can be reduced by setting a large value of 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 frequency of byte-counting
ACK is unbounded under bandwidth change.
2. Periodic ACK: Byte-counting ACK's unbounded frequency can be
attributed to the coupling between ACK sending and packet arrivals.
Periodic ACK can decouple ACK frequency from packet arrivals,
achieving a bounded ACK frequency when bw is high. The frequency of
periodic ACK is:
f(pack) = 1/alpha (2)
Where alpha is the time interval between two ACKs. However, when bw
is extremely low, the ACK frequency is always as high as that in the
case of a high throughput. In other words, the frequency of periodic
ACK is unadaptable to bandwidth change, which wastes resources.
3. Tame ACK (TACK): To summarize, both of the above ways fail to
bound or minimize the number of ACKs that required by transport under
different network conditions (e.g, time-varying data throughput).
TACK is suggested to combine these two ways so that minimize ACK
frequency required, i.e., ACK frequency can be set as f(tack) =
min{f(b),f(pack)}. Through Equations (1) and (2), we have
f(tack) = min{bw/L*MSS, 1/alpha} (3)
Li, et al. Expires September 7, 2020 [Page 4]
Internet-Draft Advancing ACK for Wireless March 2020
3.2. Provisioning for TACK
In 2006, Floyd and Kohler [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 et al.
[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 of TACK can be given as
follow:
f(tack) = min{bw/L*MSS, beta/RTTmin} (4)
where beta indicates the number of ACKs per RTT, and L indicates the
number of full-sized data packets counted before sending an ACK. To
minimize the ACK frequency, a smaller beta or a larger L is expected.
Sara Landstrom et al. has given a lower bound of beta in [Sara],
i.e., beta >= 2. An upper bound of L can also be derived according
to the loss rate on the data path (plr_data) and the ack path
(plr_ack), i.e., L <= feedback_info/(plr_data*plr_ack), where
feedback_info denotes the amount of information carried by an ACK.
Qualitatively, TACK turns to periodic ACK 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).
In terms of a transport with a large bdp, beta = 2 should be
sufficient to ensure utilization, but the large bottleneck buffer
(i.e., one bdp) makes it necessary to acknowledge data more often.
In general, the minimum send window (SWNDmin) can be roughly
estimated as follow:
SWNDmin = beta*bdp/(beta-1) (5)
Ideally, the bottleneck buffer requirement is decided by the minimum
send window, i.e., SWNDmin - bdp. Since doubling the ACK frequency
reduces the bottleneck buffer requirement substantially from 1 bdp to
0.33 bdp, beta = 4 is RECOMMENDED to provide redundancy, being more
robust in practice.
The parameter L comes into effect in terms of TACK frequency when the
bdp is small. Latency-sensitive transport usually has a small bdp,
in the case of application limitation, the latency of thin flows
might be enlarged due to a large L. Since the high ACK frequency is
Li, et al. Expires September 7, 2020 [Page 5]
Internet-Draft Advancing ACK for Wireless March 2020
not the main bottleneck in the case of a mall bdp, the delayed TCP-
like provisioning of L = 2 is RECOMMENDED to be more robust in
practice. It is also feasible to enable the TCP QUICKACK option,
allowing real-time applications to set L = 1.
3.3. Benefits for applying TACK
First, given an L, the frequency of TACK is always no more than that
of the legacy TCP ACK. Assume all data packets are full-sized (MSS =
1500 B), L = 1 and beta = 4, the frequency is reduced to 10% when bw
= 48 Mbps and RTTmin = 10 ms. Second, the higher bit rate over
wireless links, the more number of ACKs are reduced. For example,
the frequency has dropped two orders of magnitude when bw increases
from 48 Mbps to 200 Mbps. Meanwhile, the larger latency between
endpoints, the more number of ACKs are reduced. For example, the
frequency has dropped three orders of magnitude when RTTmin increases
from 10 ms to 20 ms (bw = 200 Mbps). In summary, TACK significantly
reduces ACK frequency in most cases. This can be not only a win for
throughput improvement but also win for energy and CPU efficiency.
4. Difference between delayed ACK and TACK
To facilitate the analysis, we assume that every data packet is full-
sized (i.e., MSS). When the TCP socket option TCP QUICKACK is
enabled, the legacy TCP sends an ACK for every packet (i.e., per-
packet ACK). The frequency of per-packet ACK is computed as:
f(tcp) = bw/MSS (6)
Transport protocols, such as TCP and QUIC, also alternatively adopt
delayed ACK, in which a data receiver may delay sending an ACK
response by a given time interval (gamma) or for every L full-sized
incoming packets. As described in [RFC1122] and updated in
[RFC5681], L is strictly limited up to 2, and gamma is tens to
hundreds of milliseconds and varies in different Linux distributions.
When 0 <= bw < 2*MSS/gamma, less than 2 full-sized data packets are
transported during the time period of gamma. The frequency of
delayed ACK is computed as:
f(tcp_delayed) = bw/MSS, 0 <= bw < 2*MSS/gamma (7)
When bw >= 2*MSS/gamma, at least 2 full-sized data packets are
transported during the time period of gamma. The frequency of
delayed ACK is computed as:
f(tcp_delayed) = bw/(2*MSS), bw >= 2*MSS/gamma (8)
Li, et al. Expires September 7, 2020 [Page 6]
Internet-Draft Advancing ACK for Wireless March 2020
Delayed ACK falls into the category of byte-counting ACK except that
an extra timer prevents ACK from being excessively delayed. For
full-sized data packets, it turns to byte-counting ACK when bw is
large and falls back to per-packet ACK when bw is small (see
Equations (7) and (8)). TACK differs from delayed ACK by mandatorily
sending ACKs periodically when bw is large (see Equation (4)). In
particular, TACK applies periodic ACK when bdp is large and falls
back to byte-counting ACK when bdp is small.
5. Compatibility issues
It is depicted in [RFC2525] that a TCP receiver which does not
generate an ACK for every second full-sized segment exhibits a
"Stretch ACK Violation". Several implications of generating fewer
ACKs are also discussed in [RFC2525]. TACK aims to achieve a
minimized or controlled ACK frequency under different network
scenarios, but unfortunately exhibits the "Stretch ACK Violation".
Since TACK excessively decreases the rate at which ACKs are
transmitted, in order to apply TACK without decreasing transport
performance, we list all detailed challenges that need to be overcome
as below.
5.1. Issues in loss recovery
For ordered and byte-stream transport, when loss occurs and a packet
has to be retransmitted, packets that have already arrived but that
appear later in the bytestream must await delivery of the missing
packet so the bytestream can be reassembled in order. Known as head-
of-line blocking (HoLB), this incurs high delay of packet
reassembling and thus can be detrimental to the transport
performance. Applying TACK will further enlarge this delay incurred
by HoLB.
We define the TACK delay as the delay incurred between when the
packet is received and when the TACK is sent. According to Equation
(4), with a large RTTmin, TACK might be excessively delayed. When
loss occurs during the TACK interval, the excessive TACK delay might
disturb loss detection, resulting in costly retransmission timeouts.
TACK loss further aggravates this problem. For example, RTTmin = 200
ms, bw = 10 Mbps, and L = 1, then f(tack) = 20 Hz. Compared to per-
packet ACK, TACK can cause the feedback delay of up to 50 ms upon
loss event. If ACK is lost or the retransmission is lost again, then
the delay doubles.
Li, et al. Expires September 7, 2020 [Page 7]
Internet-Draft Advancing ACK for Wireless March 2020
5.2. Issues in round-trip timing
An RTT can be sampled at the sender upon receiving a TACK. For
example, a packet is sent at time t_0 and arrives at time t_2.
Assume that the TACK is constructed at time t_3, the receiver
computes the TACK delay delta_t = t_3 - t_2. The sender therefore
computes the RTT according to delta_t, t_0 and the TACK arrival time
(t_1), i.e., RTT_sample = t_1 - t_0 - delta_t. Measuring delta_t at
the receiver assures an explicit correction for a more accurate RTT
estimate.
The issue here is that multiple data packets might be received during
the TACK 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. One alternative way to
reduce biases can be that, each TACK carries the per-packet delta_t
(specific TACK delays for each data packet) for the sender to
generate more RTT samples. However, (1) the overhead is high, which
is unacceptable especially under high-bandwidth transport. Also, (2)
the number of data packets might be far more than the maximum number
of delta_t that a TACK is capable to carry.
5.3. Issues in send pattern
A burst of packets can be sent in response to a single delayed ACK.
Legacy TCP usually sends micro bursts of one to three packets, which
is bounded by L <= 2 according to the definition of TCP delayed ACK.
However, the fewer ACKs sent, the larger the bursts of packets
released. Since TACK might be excessively delayed, the burst send
pattern is non-negligible as it may have larger buffer requirement,
higher loss rate and longer queueing delay if not carefully handled.
5.4. Issues in startup cwnd update
The TCP slow start algorithm increases the congestion window (cwnd)
upon ACK arrials. Therefore, applying TACK increases the amount of
time needed by the slow start algorithm to reach the maximum
bandwidth, which diminishes performance in networks with large bdps.
5.5. Issues in awnd update
Send window update requires ACKs to update the largest acknowledged
packet and the announcement window (awnd). With a small frequency,
TACK probably delays acknowledging packet receipts and reporting the
awnd, resulting in feedback lags and bandwidth under-utilization.
For example, f(tack) = 20 Hz, then TACK is sent every 50 ms. Assume
a TACK notifies awnd = 0 due to receive buffer runs out at t = 0 ms,
Li, et al. Expires September 7, 2020 [Page 8]
Internet-Draft Advancing ACK for Wireless March 2020
upon receiving this TACK, the sender stops sending data. In the case
that the receive buffer is released at t = 5 ms due to loss recovery,
the sender continues to be blocked for another 45 ms until a
subsequent TACK is sent at t = 50 ms, and thus wastes opportunity of
sending data. TACK loss further aggravates this issue.
6. Security Considerations
This document neither strengthens nor weakens TCP's current security
properties.
7. IANA Considerations
This document is the problem statement. This section will be
completed when further solution is proposed.
8. References
8.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>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[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>.
[RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner,
J., Heavens, I., Lahey, K., Semke, J., and B. Volz, "Known
TCP Implementation Problems", RFC 2525,
DOI 10.17487/RFC2525, March 1999,
<https://www.rfc-editor.org/info/rfc2525>.
[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>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>.
Li, et al. Expires September 7, 2020 [Page 9]
Internet-Draft Advancing ACK for Wireless March 2020
8.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.
[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.
Li, et al. Expires September 7, 2020 [Page 10]
Internet-Draft Advancing ACK for Wireless March 2020
[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
Huawei Technologies
D2-03,Huawei Industrial Base
Longgang District
Shenzhen
China
Email: li.tong@huawei.com
Kai Zheng
Huawei Technologies
Information Road, Haidian District
Beijing
China
Email: kai.zheng@huawei.com
Rahul Arvind Jadhav
Huawei Technologies
D2-03,Huawei Industrial Base
Longgang District
Shenzhen
China
Email: rahul.jadhav@huawei.com
Li, et al. Expires September 7, 2020 [Page 11]
Internet-Draft Advancing ACK for Wireless March 2020
Jiao Kang
Huawei Technologies
D2-03,Huawei Industrial Base
Longgang District
Shenzhen
China
Email: kangjiao@huawei.com
Li, et al. Expires September 7, 2020 [Page 12]