摘要

  • RACK 用发送时间、ACK/SACK、RTT 与有限乱序窗口标记丢失；它没有直接观察物理丢弃。
  • 后续 DSACK 可以表明重传可能多余，却不能指出网络中的具体原因。
  • 运维记录应保存推断输入和每个发送副本，不能把恢复动作直接改写成事故事实。

在完整历史出现前先恢复

RACK 回答的是一个实际问题：后续交付证据和等待时间是否已经足够，可以重传更早但未确认的序列范围？发送方不能无限等待确定答案，必须为歧义设置边界。

RFC 8985 要求两个条件同时成立：某个更晚发送的分段已经交付；较早分段在估算 RTT 加乱序窗口之后仍未交付。这比单纯定时器更有依据，但仍是发送方在特定时刻依据可见证据作出的推断。

ECMP、无线链路修复和其他机制都可能改变到达次序。原始副本可能仍在途中，其序列范围已经被标记丢失。该标记的含义是“按算法修复这个范围”，不是“设备目击这个数据包消失”。

RACK 的时钟属于证据本身

RACK 保存每个分段最近一次发送时间，包括重传。它从已交付分段中选取发送时间最晚者作为参考，并取得最近 RTT 样本，再用乱序窗口比较尚未交付的范围。

乱序窗口会自适应，但有上限。较小初值能更快恢复短流，同时承担虚假重传风险；出现乱序证据后可扩大等待预算，又不会把每个歧义都变成无限等待。

TLP 处理确认稀少的尾部。在 RTO 前，它发送新数据或重传最高序列分段来触发 ACK。这个反馈可让 RACK 推断更早范围需要修复；探测增加了信息，却不是对物理丢弃的直接观察。

DSACK 改写事后判断

RFC 2883 允许接收方报告重复分段或重复序列范围。重传之后出现 DSACK，只能证明接收方收到了重复数据；结合发送方历史，它可以提示某次重传可能多余，却不能确定哪一个副本在何时、因何原因到达。

因此 RFC 8985 建议在 DSACK 暗示虚假重传时扩大乱序窗口。DSACK 并不指出具体队列、无线链路、隧道或 ECMP 成员；它证明收到重复数据，不提供完整因果链。

来源