BBR与CoDel

    本篇文章，力图说明两个问题：(1)为什么BBR中的拥塞控制中有一个pacing rate（在一个rtt内，相对均匀地向网络中发包）？(2)为什么BBR在带宽探测阶段(PROBE_BW)中的八个周期(1.25,0.75,1,1,1,1,1,1)中，第二个阶段要降低发送速率？

    这两个机制考虑的是网络路由器的处理能力。CoDel的出现[1]为了解决网络中越来越长的排队长度和不断增加的端到端的时延。BBR的出现，纠正了TCP拥塞控制的发展方向，而CoDel则是纠正网络队列管理机制的发展方向。CoDel应该与BBR配合使用。而这两篇文章均有TCP拥塞控制研究的开山祖师Van Jocobson的署名，体现了其对自己以往提出的TCP拥塞控制机制的修正，或者说TCP的拥塞控制机制的演进体现了Van Jocobson不断思考的结果。

    剩下的文字，基本来自于对于CoDel[1][队列管理机制的翻译。

    谷歌的quic协议中的仿真器抽象了几个网络模型。

Sender(Queue)<-----(Link 10Mbps)----->Switch(Port Queue)<--------(Link 10Mbps)------->Receiver(Queue)

    发送端向交换机发送数据包带宽能力为100M，交换机向接收端发送数据包的带宽能力为10M。发送端的TCP初始拥塞窗口假设为25个。一个数据包的长度为1500字节(12000bit)。发送端突发发送25个数据包，包与包在网络中的时间间隔T=(12000bit/100M)~0.12ms。这里假设0.12ms一个单位时间，用τ表示。

    接下来看看[1]中的图1。这个图在讲解BBR中文章中很多都用到了。队列中是发送端向网络中发送的25个数据包，小方块的长为包的时长τ，高度为网络带宽(100M)。

  

    在100M向10M链路上发包时，包的时延会被拉长（The bottleneck spaces out the packets, and they retain that spacing after leaving.）。100M对应的包的时长为1τ，则10M链路上包的时长可以计算出为10t。第一个包在交换机中的处理时长为10τ，则第二个包就要在交换机中等待9τ，第三个包要等待18τ。。。注意包本身的时间长度为1τ(图一中一个小方块的长度)。经过一个单向时延，接收端收到数据包，开始向发送端回馈ACK，ACK之间的时间间隔，反映的就是瓶颈链路的处理能力（The receiver just turns a data packet into an ack (acknowledgment packet), so the ack stream retains the spacing on the return path.）。经过一个RTT（这里假设一个RTT为200τ）。发送端开始收到接收端返回的ACK，接收端就可以按照接收ACK的速率向网络中发包(The sender turns each ack into a data packet, so, after just one RTT, the packet-arrival rate at the bottleneck exactly equals the departure rate, and the queue won’t grow )。具体情况可以论文[1]中的图2与图3。这个例子就说明了为什么发送端向网络中发包时要pacing，就是适配瓶颈链路的处理能力，按照接收ACK的时间间隔向网络中发包。

    但是问题出现。初始的拥塞窗口为25个包。RTT为200τ，包之间的理想发送时间间隔为10τ，就是说发送端在一个RTT内可以向管道中注入20个包，初始拥塞窗口多了5个。这五个包在网络中动态滞留，网络队列中始终存在5个包。网络队列长度，不增，不减，它就在那里。理想情况下，网络中要是只有一个连接，这个不会造成任何问题。但是，每个连接都在网络中动态滞留5个包，大量的连接，就会造成队列长度的积累，就是bufferbloat。这个可以说明BBR在加速一个周期后，要减速一个周期，就是让路由器清空连接在加速阶段增长的队列长度。

   关于CoDel中的队列管理机制就不介绍了，有博文介绍[2][3]。我没有仔细看。其中的思想也是创举，它弥补了RED这种主动队列管理的不足。它逼迫网络中的连接按照瓶颈链路的处理能力进行发包。CoDel的队列管理机制，会以较大概率丢弃不守规矩流的数据包。

   要是这种队列管理机制在网络中得到大规模部署，搞网络加速的这些聪明人，可以休矣。聪明人在网络中制造了麻烦。

   大早上，为什么花了一个半小时写这么个东西。昨天读CoDel的文章，为其中作者做研究的态度打动。CoDel的想法验证，有一部分是基于ns2仿真的，代码地址[4]。

 

[1]Controlling Queue Delay-A modern AQM is just one piece of the solution to bufferbloat

[2]TSQ/CoDel队列管理以及TCP BBR如何解决Bufferbloat问题

[3]Linux网络堆栈的排队机制

[4]CoDel Wiki