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.

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. Problem Statement
• 3. Possibility of ACK Optimization on the Transport Layer
• 4. Issues to handle
• 4.1. Issues in loss recovery
• 4.2. Issues in round-trip timing
• 4.3. Issues in send rate control
• 5. Security Considerations
• 6. IANA Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

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.

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 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:

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).

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

7.2. Informative References

Authors' Addresses