重构节点拥塞控制

闲鱼瞎读系列

---

Restructuring Endpoint Congestion Control

---

文章理解：现在的拥塞控制算法是直接编译到内核中的，每次使用都需要对内核模块进行修改（也就是打开内核中相应模块，更换拥塞控制协议）并重新进行启动，这样就很麻烦。这篇文章就是做出一个拥塞控制平台（CCP），用户只需要将拥塞控制协议放在平台进行加载就能运行，不用再打开内核进行修改，这样就很方便，而且性能和在内核中运行差不多。

datapath：只存在于路由器和交换机。可这样理解：每个应用建立TCP连接后，都要发送一系列数据包，路由器会寻找这个包的路径该怎么走（可理解为走哪条网线），数据包所走的这个路径就是datapath.

数据流：可理解为发往同一个地址的很多个数据包，就像水流一样。

RTT（Round-Trip-TIme）：往返时延，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。

一、介绍：

拥塞控制的核心是决定何时发送每个数据段，由于进行此决策的位置是在传输层中，因此拥塞控制现在紧密的编织到内核的TCP软件中，并且为每个TCP连接独立运行。

这样的设计有三个缺点：

1、许多模型建议在缺少用于所需计算的有用库的内核中实现使用一些困难的技术，这是不可能的。此外，为了满足严格的性能约束，内核内拥塞控制算法在很大程度上仅限于简单的窗口或速率算法。
2、内核TCP堆栈只是数据路径的一个例子，我们使用这个术语（数据路径）来描述任何模块，这些模块在上层应用程序和底层网络硬件之间提供数据传输和接收接口，最近出来了一些新的数据路径。这一趋势表明未来应用程序将使用不同于传统内核支持的TCP连接的数据路径。新的的数据路径为拥塞控制提供了有限的选择，但这极大的阻碍了数据路径和运行在数据路径上的拥塞控制算法的实验和创新。而且随着硬件加速器和可编程网络接口卡的出现，这种情况将进一步恶化。
3、将拥塞控制紧密地绑定到数据路径使其难以提供新功能，例如在拥塞管理器项目中提出的跨共享瓶颈的流聚合拥塞信息。

相反，如果数据路径封装了可用的关于拥塞信号的信息，如包往返时间(RTT)、接收、丢失、ECN等，并定期将这些信息提供给一个off-datapath模块，然后拥塞控制算法可以在该模块的上下文中运行。通过公开一个类似的接口来控制传输参数，如窗口大小、速率和传输模式，数据路径可以根据off-datapath拥塞控制算法指定的策略传输数据。当然，必须修改数据路径。

在CCP上运行拥塞控制有如下好处：

1、编写一