# 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 
  * ![](https://2097630930-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MVORxAomcgtzVVUqmws%2Fuploads%2FgZLWqFHPKSkH5HxOh45x%2Fimage.png?alt=media\&token=9e07cd7c-3f1a-482c-b3b7-3d09ee098c06)
* 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**
    * ![](https://2097630930-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MVORxAomcgtzVVUqmws%2Fuploads%2F5zMLWN2yBvw5fvNQEPDy%2Fimage.png?alt=media\&token=05d121e4-8c84-4c6e-bf17-0e3afbc25c46)
    * ![](https://2097630930-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MVORxAomcgtzVVUqmws%2Fuploads%2FquGfJzdWqzxtDuXAW3mK%2Fimage.png?alt=media\&token=07bebf58-8e23-4351-aef6-170a4e88193c)
    * ![](https://2097630930-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MVORxAomcgtzVVUqmws%2Fuploads%2FyN6dxN004MVpMDgEAWGZ%2Fimage.png?alt=media\&token=8c628f7d-d63c-4806-92fa-a760538416c4)
      * 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