简单理解,如果经过同一转发节点的流数量大于
B
D
P
m
s
s
\dfrac{BDP}{mss}
mssBDP ,理论 cwnd 会小于 1,但对于不支持浮点运算的 Linux kernel 而言,处理小数非常麻烦,即使通过缩放技术完成了运算,如何处理小于 1 的 cwnd 依然存在问题。
比如 cwnd = 0.1,即 10 个 RTT 发送 1 个报文。问题在于要在第几个 RTT 发送这个报文呢? 如果所有流的发送端都在某个固定的 RTT 发送 1 个报文,cwnd = 0.1 的效果只不过是将拥塞延后了几个 RTT。
高尚的做法应该采用随机退避,这简直回到了 CSMA/CD 的策略,原始且精妙。
比如 cwnd = 0.1, sender 应该在接下来第 random(0, 10) 个 RTT 发送 1 个报文;cwnd = 0.02, sender 即在第 random(0, 50) 个 RTT 发送 1 个报文。
相比之下,Linux kernel TCP 将 cwnd 约束在 max(1, cwnd) 略激进,对 3MB 的 buffer,只需 3000 条流就能产生拥塞控制算法无法处理的丢包,而 30000 条流共存空见惯的现代高并发网络,仅能适配 30MB 的 buffer。
虽然 buffer 大小与流数量 n 满足平方反比律
B
=
B
D
P
n
B=\dfrac{BDP}{\sqrt n}
B=nBDP ,但对于 DC 网络的 incast 流量,多条同步流显然无法从中受益,,使多条流异步化,意义是:
- 从平方反比律对 buffer 的需求随 n 的增加递减中受益。
- 随机发送,统计复用时隙,减少冲突。
事实上,DC buffer 平方反比律,CSMA/CD 统计复用,cwnd < 1 时随机化发送 RTT 时隙,都是一回事,流要异步,不要同步!
Linux Kernel TCP 不支持浮点数,TCP cwnd,pacing rate 的计算必须取整,这损失了精度,但 RFC 也是这么规范 cwnd 的,这明显已经不适合 DC 网络这种微秒级网络了,相对粗旷的 cwnd 规范是面向 Internet 的,但现在 DC 显然是另一种性质的网络。
浙江温州皮鞋湿,下雨进水不会胖。
原文链接: https://blog.csdn.net/dog250/article/details/127457021
欢迎关注
微信关注下方公众号,第一时间获取干货硬货;公众号内回复【pdf】免费获取数百本计算机经典书籍;
也有高质量的技术群,里面有嵌入式、搜广推等BAT大佬
原创文章受到原创版权保护。转载请注明出处:https://www.ccppcoding.com/archives/405375
非原创文章文中已经注明原地址,如有侵权,联系删除
关注公众号【高性能架构探索】,第一时间获取最新文章
转载文章受原作者版权保护。转载请注明原作者出处!