华为的TACK和谷歌的RACK有什么区别？

RACK和TACK目前都在IETF工作组中进行讨论，那两者有什么区别和联系呢？

先说说概念上的区别。TACK是由华为提出的，为了减少ACK数目，但是又不影响协议性能的一种传输协议确认机制。确认机制需要支撑的协议功能不仅仅是丢包检测，还要其他功能比如拥塞控制和传输状态监控等。RACK是一个由谷歌提出的丢包检测算法，它依赖的确认机制还是原生的delayed ACK (SACK enabled)。虽然两者命名类似，但是我更倾向于把两者看作不同范畴的概念。

TACK的进一步通俗解读，请参考另一篇文章：协议确认机制TACK的通俗解析

下面探讨一下两者的联系。如果一个协议使用TACK机制，ACK数量就会急剧下降，那么这个协议不太容易实现仅发送端修改的RACK。原因是ACK太慢，最新收到的包时间戳更新缓慢，无法及时检测丢包。我在论文里提到的，在接收端检测丢包，其实本质上就是接收端版本的RACK算法。区别是RACK使用时间戳，而我使用的是一个严格递增的packet number （可参考QUIC的设计）。而时间也是严格递增的，所以说本质上时间戳和packet number的作用是一样的。

作为一个协议确认机制，TACK的对比对象可以是TCP或者QUIC正在默认使用的延迟确认机制（Delayed ACK）。延迟确认机制最早由RFC 1122提出，后面在RFC 5681中进行了更新。延迟确认机制规定满足以下任意一个条件时（划重点），接收端需要发送一个ACK报文。

1. 每收到2个的数据报文（full-sized：大小等于最大段长）；
2. 每经过一个时钟周期，如果没有后续报文到达（这个时钟周期叫确认延迟，哈哈，这里真是容易混淆，英文叫ACK delay，就是收到一个报文后，还要等下一个报文才能满足第一个条件，但是如果一直没有等到下一个报文呢，那就最多等一段时间，也得发ACK。这段时间就是ACK delay）；
3. 出现乱序（就是接收缓存里不连续了，出现了所谓的“泡泡”）。

延迟确认机制与TACK机制的区别，主要有两点：

1. ACK发送频率控制逻辑正好相反（min vs max）。传统的延迟确认机制多个触发发送ACK的条件是“或”的关系，而TACK机制使用的是“与”的逻辑（详细分析参考Acknowledgment On Demand for Transport Control）。因此，当带宽很大的时候，两者的ACK数目不在一个量级。
2. 延迟确认机制只规定了什么时候发（When to send ACKs）。而TACK机制除了规定什么时候发，不仅规定了每种ACK类型需要携带什么信息（What to carry in ACKs），而且还给出了其它协议模块（如拥塞控制、丢包恢复、往返时延测量等）应该怎么修改（How to interact with other protocol components）。

至于TACK机制与Delayed ACK的区别，可以参考这篇论文：Acknowledgment On Demand for Transport Control。如果读者有疑惑或者对其中的问题感兴趣，欢迎给我留言~

更多的细节可以阅读论文： Tong Li, Kai Zheng, Ke Xu, Rahul Arvind Jadhav, Tao Xiong, Keith Winstein, Kun Tan. “TACK: Improving Wireless Transport Performance by Taming Acknowledgments.” Proceedings of the 2020 Conference of the ACM Special Interest Group on Data Communication (ACM SIGCOMM), pp. 15-30, 2020.
Youtube视频讲解：https://www.youtube.com/watch?v=NQG3Pmxn9xE
也可以访问我的主页，下载PPT和视频资料：https://leetong.weebly.com/