# TACK: Improving Wireless Transport Performance by Taming Acknowledgements

* Wireless local area network (WLAN) demands high throughput 
  * Far from satisfactory 
* TCP ACKs cause internal interference 
  * External interference: between wireless devices on the same channel
  * **Internal interference**: between data packets and ACKs in the same connection 
  * ![](/files/tUitBxj7ypEWJXDRRHfw)
* ACKs cause similar medium access overhead 
  * Extra overhead for sending each packet independent with packet size 
* Reducing ACK frequency improves throughput 
  * Emulations over wireless links
*  But, simply reducing ACK frequency hurts TCP performance 
  * Negative impact: TCP's transport control depends on frequency ACKs 
* Goal: seek the optimal ACK frequency with corresponding improvements in transport mechanism to avoid the "negative effect"  
* Takeaways
  * **TCP's delayed ACK is far from optimal** 
    * Because: TCP adopts a max function other than a min function 
      * "MIN" is also able to achieve good transport performance
      * Key: avoid TACK's negative effect 
      * TACK adopts a "min" instead of a "mx" to assure the minimized ACK frequency in the context of network dynamics 
    * data throughput high / low 
    * The frequency of TCP's delayed ACK is not bounded 
    * Tame ACK (TACK)
      * A new ack whose frequency is decided by the bandwidth and the delayed product (bdp) 
      * TACK applies periodic ACK when bdp is large, and falls back to byte-counting ACK is small 
        * Throughput is high --> ACK frequency is bounded
        * Low --> ACK frequency reduced proportionally 
  * **Our way of avoiding "negative effective" is a TACK-based acknowledgement mechanism**
    * ![](/files/laqvxGLY9H52SORzWKbW)
    * ![](/files/bgvODiwxaJ83JBihaTta)
    * ![](/files/dgqKpturYzyebzgY02OT)
      * Advancements in loss recovery 
      * Advancements in round-trip timing 
      * Advancements in send rate control 
    * With more types of ACKs and more necessary information carried in ACKs, less number of ACKs are required 
  * **An approximately minimized ACK frequency works better than expected**  
    * Wired / wireless links 
    * TACK-based protocol provides a good replacement of legacy TCP in WLAN, and also works well in WAN scenarios 
    * TACK and its corresponding improvements in transport mechanism can also be adopted into other stacks (e.g., QUIC) to compensate for scenarios where the ack overhead is non-negligible 
* Evaluation
  * TCP-TACK implementation 
  * Experimental setup 
* Questions 
  * WiFi (cellular) networks: scheduling to enter WiFi, more stable, TACK is needed? 
    * Contention is less than WLAN 
    * Cellular: uplinks (bandwidth) is usually limited, asymmetric bandwidth, maybe reducing the ACK frequency when the ACK path is congestion 
    * WiFi 6: contention is less, but always exist
  * Multi-hop wireless network 
    * Contention bigger 
    * TACK works? 
      * In theory, the benefits may increase 
  * Harder to figure out performance issue? 
    * Reduce 90% of the number of ACKs 
    * According to the connection states, more difficult 
    * TACK carries more necessary information, the size of the ACK is larger than the traditional one. The end-point can also get most of the information needed for the connections 
  * Protocol based on the rate? 
    * Rate-based CC 
      * TACK: less number of acks, the sender will have less information to do CC, also will result in burst in window-based CC 
    * TACK is more suitable for rate-based CC
      * BBR: pacing as the basic mechanism for the sender, can avoid the large burst for sending less number of ACKs  


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://sliu583.gitbook.io/blog/specific-work/wisr-group/cache/index/tack-improving-wireless-transport-performance-by-taming-acknowledgements.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.