5.1 TCP Vegas

TCP Vegas背后的核心思想是根据测量的吞吐量和预期的吞吐量之间的差异，来调整数据的发送速率。

为什么要这么做呢？可以从TCP Reno 的行为找到答案。图29展示了TCP Reno的曲线。最上面的图是拥塞窗口随时间的变化，它与上一章中展示的信息一样；中间的图展示了发送端的发送速率随时间的变化；下面的图展示了瓶颈路由器的平均队列长度随时间的变化。3 个图的时间轴是同步的。在 4.5 和 6 秒之间（蓝色阴影区域），拥塞窗口在增加（上图），我们预期发送端吞吐量也应该相应的增加，但是实际吞吐量却保持不变（中图），这是因为吞吐量不能超过实际可用带宽。在这个区间内，增加窗口大小只会使得瓶颈路由器的 buffer 被填的更满（下图）。

图29：拥塞窗口和观察到的吞吐量（三个图是同步的）。上：拥塞窗口；中：观察到的吞吐量；下：路由器中的buffer空间。蓝线：拥塞窗口大小；实心圆点：超时发生；短竖线：每次发送packet时间；长竖线：最终要重传的packet第一次发送的时间。

给图 29 中4.5-6 秒之间的现象打个比方，这就像是在冰上开车。速度表（对应拥塞窗口）或许显示当前速率是 30miles/h，但是你从车窗外望去可以看见步行的人走的都比你快（对应测量的吞吐量），所以你知道你的实际速率小于 5miles/h。这个比喻里车轮的空转就像是上图中发送的额外的 packet，除了占用了路由器的 buffer，并没有什么实际的效果。

TCP Vegas的出发点就是上面这个场景。TCP Vegas 会测量并控制当前 TCP 连接向网络中发送的额外数据，所谓的额外数据是指，如果当前发送速率与网络可用带宽一样时，本不会发送的那些数据（注，即 TCP Vegas 会多发一些数据，并根据这些数据的表现来实现拥塞控制）。所以，TCP Vegas 的目标是维持“正确的”在网络中传输的额外数据量。很明显，如果 TCP 发送端发送了太多额外数据到网络中，会导致更长的延时，甚至导致拥塞丢包。但是另一方面容易忽略的是，如果一个连接向网络中发送的额外数据量太少，它将无法对网络中临时增加的可用带宽做出足够快速的响应。TCP Vegas 的拥塞规避行为是基于对网络中预估的额外数据量的变化实现，而不是仅仅基于丢包。我们接下来详细描述这个算法。

首先，定义一个 TCP 连接的 BaseRTT 为当网络不拥塞时一个包的 RTT。TCP Vegas取 BaseRTT 为所有测量到的 RTT 的最小值，通常是一个 TCP 连接的第一个包的 RTT，因为此时路由器的队列还没有因为当前这个 TCP 连接而增加。假设当前网络没有被填满，那么预期的吞吐量 ExpectedRate 为：

此时，传输中的数据量（bytes）等于 CongestionWindow。

接下来，TCP Vegas 会计算当前的发送速率 ActualRate。这是通过记录每一个包的发送时间和对应的 ACK 收到时间，用这段时间发送的字节数除以时间差得到。每个 RTT 时间都会计算一次ActualRate。

接下来，TCP Vegas 会比较ExpectedRate和ActualRate，并根据结果调整拥塞窗口大小。假设 Diff = ExpectedRate - ActualRate，那么 Diff 必然大于等于 0。因为当 ActualRate 大于 ExpectedRate 时，当前的 RTT 小于 BaseRTT。当这发生时，说明 BaseRTT 已经失效，我们需要更新 BaseRTT 为当前的 RTT，并重新计算ExpectedRate。这里再定义两个阈值α和β，分别表示网络中传输的数据太少和太多。当 Diff 小于α时，TCP Vegas 在下次 RTT 中线性增加拥塞窗口大小，当 Diff 大于β时，TCP Vegas 在下次 RTT 中线性减少拥塞窗口大小。当 Diff 位于α和β之间时，TCP Vegas 保持拥塞窗口不变。

很明显，当 ActualRate 越小于 ExpectedRate 时（即 Diff 大于β），网络会更加拥塞，暗示着发送速率该降低了，所以减少拥塞窗口大小。β阈值控制了这里的降低。另一方面，当 ActualRate 接近 ExpectedRate 时（即 Diff 小于α），TCP 连接可能未能充分利用可用的带宽，所以增加拥塞窗口大小。α阈值会触发增加发送速率。算法总体目标是保持网络中传输的数据量在α和β之间。

图30展示了TCP Vegas的拥塞规避算法。上图展示了拥塞窗口的大小随时间的变化；下图展示了预期的和实际的吞吐量随时间的变化，这里的吞吐量会控制拥塞窗口的大小。下图更好的展示了算法是如何工作的。蓝色线代表了ExpectedRate，黑线代表了ActualRate。蓝色粗阴影线展示了α和β之间的区域：阴影的上边界表明了与ExpectedRate差距 α KBps，阴影的下边界表明了与ExpectedRate差距 β KBps。算法的目标就是让ActualRate位于这两个阈值之间，也就是在阴影区域内。当ActualRate在阴影区域下方时（也就是离ExpectedRate太远），TCP Vegas会减少拥塞窗口大小，因为它担心会有太多的包被缓存到网络中。类似的，当ActualRate在阴影区域上方时（也就是离ExpectedRate太近），TCP Vegas会增加拥塞窗口大小，因为它担心没有充分利用网络。

图30：TCP Vegas拥塞规避算法机制展示。

因为α和β是吞吐量差值的阈值，所以它们的单位是KBps。然而，跟Control-based拥塞算法一样，如果按照网络中传输的packet数来理解该算法，会更加容易。例如，对于一个TCP连接，其BaseRTT是100ms，一个packet大小是1KB，如果α = 30KBps且β = 60KBps，那么我们可以认为α表明该TCP连接在一个 RTT 时间内需要占据网络中至少3个packet大小的buffer，而β表明该TCP连接在一个 RTT 时间内应该占据网络中不超过6个packet大小的buffer。这样设置α和β在Vegas的最初部署中工作的很好，但是我们下一节可以看到，这些参数在不同的环境需要不通的调整。

最后，你会发现TCP Vegas线性的减少拥塞窗口，这与前面提到的乘法递减以确保稳定性是矛盾的。TCP Vegas在超时发生时的确会使用乘法递减；这里的线性递减只是在拥塞发生和实际丢包之前，等于说此时什么都还没有发生，不必这么激进。