tcp westwood 比 reno，cubic 好在哪
今天说说 tcp 韦斯特伍德，和昨天 dctcp 的路子一样，主要还是一个观点，信息带来性能收益。
reno，cubic 仅做孤立 aimd，没有将 rtt 用到极致，信息相当于浪费掉了，而 westwood 却充分利用 ack 和 rtt 叠加计算了一个 bandwidth，简称 bw，并在过程中冒泡 minrtt，来看看 bw * minrtt 是什么，就是这条流的实际有效的 inflight，既然它有效，为何不随行它呢，所以在丢包恢复后还需要从 (1 - β) 个 cwnd 重新开始吗：
简单建模，然后照例用 matplotlib 对比：
w：cwnd
x：goodput
y：drop-model
z：动态 buffer 占量
R：propagation delay
C：bandwidth
α：静态 buffer 占量
d w d t = { 1 , y ≤ 0 x ⋅ R − w , y > 0 \dfrac{dw}{dt} = \begin{cases} 1, & y \leq 0 \\ x\cdot R-w, & y \gt 0 \end{cases} dtdw={1,x⋅R−w,y≤0y>0
d x d t = C ⋅ w w + ( α + ⋅ z ) − x \dfrac{dx}{dt}=C\cdot \dfrac{w}{w+(\alpha+\cdot z)}-x dtdx=C⋅w+(α+⋅z)w−x
z = u p d a t e z ( z , y 1 , y 0 ) z = update_z(z, y_1,y_0) z=updatez(z,y1,y0)
def update_z(z, y_curr, y_prev):if int(y_curr) == int(y_prev):z = y_currreturn z
简单解释一下 update_z 函数，y 标识是否丢包，z 是动态 buffer 占有量，这里的模拟方式很简单，如果 y 是随机丢包，那么 z 不受影响，如果 y 是拥塞丢包，就让 y 正相关于 z，采用的方法是简单 z = y。
OK，简单设 reno，cubic 的 β = 0.5，模拟如下：
可看出锯齿的变化，westwood 并不太受随机丢包的影响，因为它保有实际测量 bw。但在实践中，这种效果依赖测量精度和信息本身的准确度，而我们知道，tcp 的信息精度并不高。
说说 westwood 的实现，由于早期 Linux 内核并不支持高精度时间戳，与 vegas 一样，Linux 内核的 tcp_westwood.c 也是个阉割版：
- bw 计算非常粗糙，应该用 bbr 使用的那套新基础设施来重构；
- 不支持 pacing，这是拜早期 Linux 内核不支持高精度时钟所赐。
浙江温州皮鞋湿，下雨进水不会胖。