TACK: Improving Wireless Transport Performance by Taming Acknowledgements

https://www.youtube.com/watch?v=NQG3Pmxn9xE

• 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

  • 

• 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

    • 

    • 

    • 

      • 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