7.2 Background Transport (LEDBAT)
Last updated
Last updated
与数据中心环境中低延时形成鲜明对比的是，有许多应用程序需要在较长时间内传输大量数据。文件共享协议如BitTorrent和软件更新就是其中的两个例子。LEDBAT（Low Extra Delay Background Transport）针对的就是这些应用场景。
在各种旨在提升TCP拥塞控制算法的努力中，有一个共同的主题就是要与标准TCP的共存。众所周知，某个算法可以仅仅通过在对拥塞的反应上更为激进而“胜过”TCP。因此，新的拥塞控制算法存在一个“潜规则”：它应该与标准TCP一起进行评估，以确保它们不是仅仅从不那么激进的TCP实现中抢夺带宽。
LEDBAT 选择了一个相反的方向，它通过创建一个故意比 TCP 不那么 激进的拥塞控制算法。其思想是在链路未拥堵时利用可用的带宽，但当其他标准流量到来时，迅速退让并为它们留出带宽。此外，正如名称所暗示的，LEDBAT 试图不产生显著的队列延迟，这与典型的 TCP 填满瓶颈链路队列的行为不同。
与TCP Vegas一样，LEDBAT也会检测到拥塞变得严重到足够引起丢包之前的状态。然而，LEDBAT采用了不同的检测方法，它使用测量到的单向延迟作为该过程的主要输入。这是一种相对新颖的方法，在时钟同步相对准确但又不是完美同步成为一个常态的现在，这种方法是有意义的。
为了计算单向延迟，发送端在每个传输包中放置一个时间戳，接收端将其与本地系统时间进行对比，以测量包经历的延迟。然后，它将这个计算出来的值发送回发送端。即使时钟并未精确同步，延迟的变化可以被用来表示队列的堆积。这里假设时钟频率之间没有大的相对偏差，即它们的相对偏移不会变化的太快，这在实践中是一个合理的假设。
发送端监控收到的计算出来的延迟，并认为一段时间间隔内观察到的最低值为固定延时（可能由于是光速限制和其他原因导致）。为了适应新的路由路径可能改变固定延迟的情况，固定延时会时不时的更新。任何高于此固定延时都将被认为是由于队列延时所致。
现在有了一个基础延时，发送端会用测量延时减去这个基础延时，得到队列延时，并且可以选择使用一个过滤算法来减少短期噪声的影响。然后，算法将这个估算的队列延时与一个目标值进行对比。当延时低于目标值时，允许拥塞窗口增长；当延时高于目标时，减小拥塞窗口，增长和减少的速率与目标的差距成比例。增长速率被限制为最快不超过标准TCP在其加法递增阶段的窗口增长速度。
LEDBAT 算法在收到ACK之后，会按照下面的公式设置 CongestionWindow：
其中，GAIN是一个介于0和1之间的配置参数，offTarget是测量的队列延迟与目标之间的差距，以目标的比例来表达，而bytesNewlyAcked是当前ACK中确认的字节数。因此，当测量的延迟越低于目标时，拥塞窗口的增长速度越快，但每个RTT的增速永远不会超过一个MSS。当队列延时超过目标值时，拥塞窗口下降速度会与超出的长度成正比。当遇到丢包、超时和长时间空闲状态时，拥塞窗口的行为与TCP一致。
因此，LEDBAT能够很好地利用可用的空闲带宽，同时避免长时间的队列积压，因为它的目标就是将延时控制在目标值左右（建议的目标延迟值大约为100毫秒）。如果其他流量开始与LEDBAT流量竞争，LEDBAT会减少其带宽使用以防止队列变长。
LEDBAT 被 IETF 定义为一种实验性协议，它的实现具有较大的灵活性，例如可以选择过滤预估延时的滤波器，以及一系列配置参数。更多细节可以在 RFC6817 中找到。