网站建设实训步骤,wordpress 炫酷主题,10个国内建筑网站,南京做网站优化哪家好就着 TCP 本身说事#xff0c;而不是高谈阔论关于它是如何不合时宜#xff0c;然后摆出一个更务虚的更新。 从一个 case 开始。
按照现在 Linux TCP(遵守 RFC) 实现#xff0c;以下是一个将会导致 reordering 更新的 sack 序列#xff1a; 考虑一种情况#xff0c;这两个…就着 TCP 本身说事而不是高谈阔论关于它是如何不合时宜然后摆出一个更务虚的更新。 从一个 case 开始。
按照现在 Linux TCP(遵守 RFC) 实现以下是一个将会导致 reordering 更新的 sack 序列 考虑一种情况这两个携带 sack block 的 ack 本身乱序而不是被 sack 确认的 data 乱序 以上的 reordering 更新就是误判而 reordering 是单调更新的递增的 reordering 将影响 mark lost 的数量进而影响 retransmit 效率。
reordering 误判对 rate-based cc 影响非常大因为 rate-based cc 要求即使在 loss recovey 状态也要源源不断地发送数据以支撑测量而 reordering 可能会造成 sender 等待减少 retransmit。
上述误判情况由下图所示(sack block 上的数字标识 sack block 生成的顺序) reordering 误判的依据在于考虑 sender 发送 110其中 13579 丢失receiver 依次收到 246810. 假设 receiver 由于被其它 option 挤占空间只能支持 max 3 个 sack block 段它 “一般”(下面解释为何不是一定) 会按照以下序列生成 sack block
收到 2发送 ack 1携带 sack 2 收到 4发送 ack 1携带 sack 4-2 收到 6发送 ack 1携带 sack 6-4-2 收到 8发送 ack 1携带 sack 8-6-4 收到 10发送 ack 1携带 sack 10-8-6 …
如果收到 8 或者 10 后发送的 ack 比收到 2 后发送的 ack 先到达 sender就会出现第一幅图所示的场景。
为什么这么明显问题Linux TCP 没处理呢
因为 RFC 并未规定 sack block 的顺序一定是 LRR(Least Recently Received类似 LRULeast Recently Used) 链表的形式。在 RFC2018 第 4 小节 Generating Sack Options: Data Receiver Behavior 中有以下描述 The SACK option SHOULD be filled out by repeating the most recently reported SACK blocks (based on first SACK blocks in previous SACK options) that are not subsets of a SACK block already included in the SACK option being constructed. This assures that in normal operation, any segment remaining part of a non-contiguous block of data held by the data receiver is reported in at least three successive SACK options, even for large-window TCP implementations [RFC1323]). After the first SACK block, the following SACK blocks in the SACK option may be listed in arbitrary order. 既然不是 MUSTsender 就不能对 sack block 假设任何时间序。对 receiver 而言由于无法区分原始 seg 和重传 seg如果是重传 seg这个 LRR 时间序就不准了。
如果(仅如果) RFC 要求 sack block 保持 LRR 强序那么 sender 收到的 sack block 就一定是这个强序便不再受 ack 反向路径乱序影响。
我想的是虽然 RFC 并未要求 MUST但事实上应该非常大比例的 receiver 实现了 LRR 强序这样做最简单。不然因为 RFC 的 maybe 摆布一个 arbitrary order 动机呢图什么呢
因此管它 MUST or SHOULD/MAYBEsender 假设 sack block 是 LRR 强序如果真的大部分 receiver 命中了我的猜测reordering 误判将会减少很多。当然这个假设需要现网数据支撑。
如果真将 sack block 的 LRR 序从 SHOULD/MAYBE 改为 MUST根据收到 sack option 中 sack block 的顺序可更加精确处理 reordering 更新。后文基于该假设继续。
同样上面的 case加入强序后就更加精确且清晰 显然sender 可根据不同的 sack block 序列判断出不同的 reordering metric进而将 reordering 更新成不同值。
LRR 强序前不能确保 sack block 顺序一定有确切含义对 sender 就更不能确定其意义sender 只简单将收到的 sack block 进行升序排序用这个序列去 mask 所有 rtxq(retransmit queue)求两个区间链表的交集区间列表的交集
LRR 强序后sender 实现更简单了。按照 sack block 在 sack option 的天然顺序匹配发送顺序即可精确判断 reordering。dsack 亦可统一处理。
引入 rack 之后事情变得更简单sender 可用 sack block 的 LRR 时间序与 rack 时间序做比对来精确判断 reordering
照 sack block 顺序比对 rack 环倒排即乱序reordering 单调递增rto 复位(rto 意味着路由可能发生了重收敛)。
由于重传歧义硬伤sender 仍需稍微的启发判断dsack 一个 seg 后相信自然序(原始 seg 带来第 1 个 sack重传 seg 带来第 2 个 sack)重传后的 sack 相信重传而非乱序当然也可以配置信任度量。
无论如何sack block LRR 强序对 sender 带来更加确定的信息该信息对 sender 的 cc 决策有益。并且实现更简单了为什么不呢
回到 RFC2018看看初衷。 The SACK option SHOULD be filled out by repeating the most recently reported SACK blocks that are not subsets of a SACK block already included in the SACK option being constructed. sack block 被安排成 LRR 弱序(may be listed in arbitrary order)原因二首先 sack option 长度有限要为最新的接收事件的数据生成 sack block其次 sack option 长度又不是那么有限安排冗余信息可以抵御 ack/sack 丢失提高鲁棒性
Sending a selective acknowledgment for the most recently received data reduces the need for long SACK options.The redundant blocks in the SACK option packet increase the robustness of SACK delivery in the presence of lost ACKs.
按照现代的观点考虑到 sack block 以及反向 ack 本身的乱序对 reordering 的影响sack block 数量越多越容忍反向路径 ack 乱序确实如此4 个 block 够了(如果被其它 option 挤占可能不足 4 个)况且就算最多只有 4 个 block只要能零散接收sack block 就能像滑动窗口(最大 4 段)一样一直滑下去覆盖所有 ofo(out of order) seg由于每个 seg 最多可出现4次即可提供冗余。sack 的该机制是好的非常好的。
演化过程是见招拆招的过程远不是全局视角下的设计过程。遇到问题痛点是解决这个问题看看初衷问题和 RFC2018 的来源 sack 解决了问题sack 就是好的。RFC2018 引入时的 loss recovey 算法依然如旧 彼时 sack 仅仅可区分对待了 sacked seg避免不必要的重传。新式的 loss recovey 算法要等后续发布。
标识 sack 相关 loss recovey 算法的 RFC6675 以及前身 RFC3517 均未引入 reordring 的影响直到 RFC4737 才引入 reordering 度量Packet Reordering Metrics这是 2006 年的事sack 被引入 TCP 时尚无 reordering issue更谈不上为它提供精准信息。但无论如何现在 sack 和 reordering 以及 rack 可以结合并且高尚。 说下本文的缘起。
我用 packetdrill 做 sack 测试构造了本文图 1 的 ack 乱序 case触发了 reordering 更新后 mark lost 便不及时了(按照 scoreboard update 算法保留 reordering 个 sacked seg)影响了 retransmit 效率。
So若做 TCP 双边我觉得一定要确保 receiver 生成 LRR 强序 sack block多些确切信息总不会错TCP 就是不确定信息太多才复杂。若做 TCP 单边我觉得要假设 receiver 生成 LRR 强序 sack block就算它不是损失也不多况且大概率它是不然对它有什么好处呢
对了reordering 的更新不仅和 sack 有关和 cumulative ack 也有关系。此外关于反向路径对正向 rate-based 发送的影响我还有另外一个建议TCP 时间戳的妙用 以及 TCP 拥塞识别。
浙江温州皮鞋湿下雨进水不会胖。
