今天说说 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 占量

$\frac{dw}{dt}=\{\begin{array}{ll}1,& y\le 0\\ x\cdot R-w,& y>0\end{array}$

$\frac{dx}{dt}=C\cdot \frac{w}{w+(\alpha +\cdot z)}-x$

$z=updat{e}_z(z,y_1,y_0)$

def update_z(z, y_curr, y_prev):
    if int(y_curr) == int(y_prev):
        z = y_curr
    return 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 内核不支持高精度时钟所赐。

浙江温州皮鞋湿，下雨进水不会胖。