Multipath TCP(MPTCP) Congestion Control抛砖引玉

MPTCP是一个全新的古老协议，从效果上看，它对标准TCP的扩展主要体现在两方面：

• 多路径切换：应用程序无感知的前提下在多条链路之间进行切换。
• 负载均衡：使用多条路径同时传输，提高链路带宽利用率。

似乎人们对多路径切换更感兴趣，几乎所有MPTCP的资料上都会介绍MPTCP在Wi-Fi和3G之间的透明切换能力，但有趣的是，定义MPTCP的RFC6182中(详见Section 2. Goals¹)并没有提到这一点，路径备份似乎是一个附加的功能。

从本质(而不是从表面)上看，MPTCP是一个支持流量调度的资源分配协议。MPTCP将同一连接的每条路径上的数据流抽象成subflow，将所有的subflow路径上的带宽看作一个资源池，在该资源池中进行动态流量调度。

池化带宽资源，是分组交换网统计复用的极致体现。引用一段MPTCP网站blog的原话：

Since the early days of computer networks, statistical multiplexing, failure resilience and load balancing have played a key role in enabling networks to carry a growing amount of traffic. However, many of the techniques that are used today were designed under the assumption that they needed to have a local impact. Many of these designs missed the opportunity of considering the problem of pooling all the available resources as an end-to-end problem. ²

对此，先来个感官上的认识。

两条连接A和B，两条100Mbps的路径供它们使用，先看标准TCP的带宽分配情况：


但如果部署了MPTCP，在带宽资源分配上将更具弹性：


面对池化的带宽资源，MPTCP的核心任务就是资源分配和流量调度，目标就是最大化资源利用率。

互联网协议必须遵守公平原则，作为需要长期与标准TCP混部的MPTCP，TCP友好性必须是其一个内在特征，MPTCP必须在保证不损害标准TCP的前提下，最大化带宽资源利用率。这个任务最终由MPTCP Congestion Control负责。

为了理解这一切背后的动力学，先看MPTCP Congestion Control的三大目标：

• 目标1：保证所有subflow总带宽不小于最佳subflow标准TCP带宽。
• 目标2：保证所有subflow任意子集总体带宽不大于该子集最佳subflow标准TCP带宽。
• 目标3：在所有subflow之间进行动态流量调度，保证目标1和目标2的前提下最大化带宽利用率。

下文将基于MPTCP Coupled Congestion Control算法介绍。

将所有可用subflow path视为一整体，统一实施AIMD。设一条MPTCP连接的subflow set为$R$，$w_r$为subflow $r$的cwnd，则：

$w_{total}={\Sigma }_{r\in R}{w}_r$

因此，最朴素的MPTCP AIMD算法显而易见，对于所有subflow：

• 未发生丢包时实施AI：$w_r=w_r+\frac{1}{w_{total}}$
• 发生丢包时实施MD：$w_r=\max \{1,w_r-\frac{w_{total}}{2}\}$

丢包包括拥塞丢包和随机丢包，一条subflow subpath丢包率高表现为buffer过小或线路噪声大，无论如何均会导致该subpath的cwnd过小，天然满足了MPTCP的目标3。

总体来讲，目标3只需要利用为拥塞subflow计算一个较小的cwnd即可满足，这是对反馈环的利用。The way to achieve resource pooling is to effectively “couple” the congestion control loops for the different subflows.

但以上算法存在以下问题：

• 每条subflow丢包率差异很大，固定数量的MD行为会将高丢包率subflow饿死。
• 每条subflow的AI行为会抢占标准TCP流量的带宽，违背了公平性原则。

为避免高丢包率subflow被饿死，MD行为需要修正，不再MD等量cwnd，改为MD与该subflow cwnd等比例的cwnd：

• 发生丢包时实施MD：$w_r=\max \{1,w_r-\frac{w_r}{2}\}$
  这样可以确保任意subflow cwnd保持一定的比例。

公平性的保证稍微复杂些，需要额外的约束。

将MPTCP的目标1和目标2的约束写成数学形式：

• 目标1约束：${\Sigma }_{r\in R}\frac{w_r}{RT{T}_r}\ge {\max }_{r\in R}\frac{w_r^{TCP}}{RT{T}_r}$
• 目标2约束：${\Sigma }_{r\in (S|S\subseteq R)}\frac{w_r}{RT{T}_r}\ge {\max }_{r\in (S|S\subseteq R)}\frac{w_r^{TCP}}{RT{T}_r}$

解法如下：

• 对于目标1，需要控制AI系数来保证所有$w_r$增量至少达到最佳subpath标准TCP的效果。
• 对于目标2，需要为每次AI行为设置一个上界，保证其不超过标准TCP的对应AI增量。

用数学表述即：

• 未发生丢包时实施AI：$w_r=w_r+\min \{\frac{\alpha }{w_{total}},\frac{1}{w_r}\}$

求解$\alpha$即可。

下面将用两种方法推导出$\alpha$的值，首先采用MPTCP论文里的方法³，然后介绍我自己的方法。

按照Design, implementation and evaluation of congestion control for multipath TCP这篇论文中的简化模型推导，如下：
设$p_r$为subflow path $r$的丢包率，按照数据包守恒，AI和MD速率需要相互抵消：

$(\frac{w_r}{RT{T}_r}(1-p_r))\frac{\alpha }{w_{total}}=(\frac{w_r}{RT{T}_r}{p}_r)\frac{w_r}{2}$

对于$p_r$非常小情况，可以近似为：

$\frac{\alpha }{w_{total}}\approx p_r\frac{w_r}{2}$

对于标准TCP，设丢包率为$p$，通过类似的守恒律：

$(1-p)\frac{1}{w_r^{TCP}}=p\frac{w_r^{TCP}}{2}\approx \frac{1}{w_r^{TCP}}$

因此：

$p=\frac{2}{w_r^{{TCP}^2}}$

对于特定subflow path的标准TCP，上式就是丢包率$p$和$w_r^{TCP}$的关系，将$p$代入$p_r$得到：

$w_r^{{TCP}^2}=\frac{w_{total}{w}_r}{\alpha }$

将$w_r^{TCP}$的表达式代入目标约束1：

$({\Sigma }_{r\in R}\frac{w_r}{RT{T}_r}{)}^2\ge \frac{w_{total}}{\alpha }{\max }_{r\in R}\frac{w_r}{RT{T}_r^2}$

解出$\alpha$：

$\alpha =\frac{\max \{\frac{w_r}{RT{T}_r^2}\}}{({\Sigma }_{r\in R}\frac{w_r}{RT{T}_r}{)}^2}$

以上就是MPTCP Coupled Congestion Control算法的介绍以及AIMD系数的推导过程。

下面是我理解的另一个视角来推导AI系数$\alpha$。

根据目标1约束，设吞吐率为$T$，最佳subflow path的吞吐为，：

$T_{best}={\max }_{r\in R}\{\frac{w_r}{RT{T}_r}\}$

如果让该MPTCP flow所有subflow均从该path通过，则其吞吐为：

$T_{total}=\frac{w_{total}}{RT{T}_{best}}$

同时，最佳subflow path在MPTCP中的吞吐率实际占比为：

$P_{best}=\frac{T_{best}}{{\Sigma }_{r\in R}\frac{w_r}{RT{T}_r}}$

若以最佳subflow作为标准吞吐，平均分给所有的subflow，那么每一个subflow将分得：

$T_{avg}=T_{total}\times P_{best}=w_{total}{\max }_{r\in R}\frac{w_r}{RT{T}_r^2}$

现在问，总吞吐${\Sigma }_{r\in R}\frac{w_r}{RT{T}_r}$如何分割才能获得$T_{avg}$：

${\alpha }^{\prime }\times {\Sigma }_{r\in R}\frac{w_r}{RT{T}_r}=T_{avg}=w_{total}{\max }_{r\in R}\frac{w_r}{RT{T}_r^2}$

解出${\alpha }^{\prime }$：

${\alpha }^{\prime }=\frac{\max \{\frac{w_r}{RT{T}_r^2}\}}{({\Sigma }_{r\in R}\frac{w_r}{RT{T}_r}{)}^2}$

由于吞吐率和cwnd是同步变化的，AI系数$\alpha$可取${\alpha }^{\prime }$：

$\alpha ={\alpha }^{\prime }$

和论文里的推导方法殊途同归，并且不再假设稳定平衡态AI，MD速率守恒。

以上只是MPTCP基本的Coupled Congestion Control算法，这只是多种CCA中的一种，还有很多诸如OLIA，BALIA，wVegas算法可供参考和研究，但目标不会改变。理解了MPTCP的3个目标，所有这些算法也就都成了细节，同时下面的问题也将不再是问题：

• 为什么不为每个subflow维护一个独立的cwnd呢？这样岂不是可以获得很好的加速效果吗？
  如何回答这个问题，你觉得呢？

最后，无论多么优秀的算法，最终都是要落实到CPU cycles，这个时候算法的效能就成了首先要考虑的了，然而通过上述论证中看到的诸多$\max \{...\}$，$\min \{...\}$，$\Sigma$算符就可以看到隐含的$O(n)$时间复杂度，特别是在subflow数量特别多的时候，问题将会更加严重。如何优化它们将会是一件非常有意思的事情，只是它们不是本文的重点，后面有时间会接着谈。对于本文而言，也到了要结束的时候了。

有几个关于MPTCP有点儿意思的话题，在文末点一下，不深究：

• 多个subflow的数据段在接收端的保序，实际上是一个插入排序的过程，但有没有更高效的方案呢？
• MPTCP对于胖树拓扑的数据中心DCI而言，其带宽调度能力能否解除掉其大部分拥塞控制工作呢？
• Wi-Fi，3G互相透明切换，应用程序无感知，这件事到底应该由传输层做还是应用程序本身做呢？或者增加一个会话层？

参考：

• The Multipath TCP foundations：
  http://blog.multipath-tcp.org/blog/html/2018/12/03/the_multipath_tcp_foundations.html
• Design, implementation and evaluation of congestion control for multipath TCP：
  https://www.usenix.org/legacy/events/nsdi11/tech/full_papers/Wischik.pdf
• An Overview of Multipath TCP：
  https://www.usenix.org/system/files/login/articles/login1210_bonaventure.pdf
• Architectural Guidelines for Multipath TCP Development：
  https://datatracker.ietf.org/doc/html/rfc6182
• Coupled Congestion Control for Multipath Transport Protocols：
  https://datatracker.ietf.org/doc/html/rfc6356

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

---

1. https://datatracker.ietf.org/doc/html/rfc6182 ↩︎

2. http://blog.multipath-tcp.org/blog/html/2018/12/03/the_multipath_tcp_foundations.html ↩︎

3. https://www.usenix.org/legacy/events/nsdi11/tech/full_papers/Wischik.pdf ↩︎