1、第 1 页设计，实施和评价的拥塞控制多径 TCP达蒙 Wischik，海东青 Raiciu，亚当格林哈尔希，马克汉德利伦敦大学学院（University College London）摘要多路径 TCP IETF 工作组的建议，MPTCP，允许一个单一的数据流被 t通过多条路径来分割开。 这在可靠性方面有明显的好处，而且还可以更有效地利用网络资源。 我们描述了一个多路径拥塞控制算法的设计，我们在 Linux 落实，我们为多宿主服务器，数据中心和移动客户端评估。 我们发现，一些明显的多路径拥塞控制解决方案可以是有害的，但是相比单路径的 TCP，我们的算法提高了吞吐量和公平性。 我们的算法是一个
2、TCP 下拉替换，并且我们相信它是安全的部署。1。 简介多路径 TCP IETF 工作组的建议，MPTCP 7，允许一个单一的数据流被分割在多条路径。 这可靠性上的明显的好处：连接路径发生故障时链接依然能坚持不断开。 它也可以对下面我们展示的多宿主服务器和数据中心以及移动设备在负载均衡方面有好处。多路径 TCP 还提出了问题，一些明显的一些微妙的，关于应如何在竞争的流之间有效率的和公平的共享网络容量。本文详细介绍了设计和实现多路径拥塞控制算法，它 robustly 跨广泛的情况下，可以是作为一个 TCP 混入替换。2 中，我们提出了一个多径 TCP 拥塞控制窗口机制，然后阐明它带给我们的问题。
3、 本节通过相关的例子和通过计算分析实践思考所呈列作为设计空间路标。 这不是一个详尽的设计空间调查，我们并不认为我们的算法是最佳，甚至定义最优需要更先进的理论基础比我们还没有发展延伸出来。 一些问题（2.1-2.3）提出在多路径拥塞控制的一些相关文献上，但并非所有已解决。 其他（2.4-2.5）的小说。zai3 - 5，我们在三个应用场景评估我们的算法：多宿主服务器，数据中心和移动设备。 我们这样做是通过仿真一个高速的自定义数据包级的模拟器，在 Linux 实施的试验台实验。 我们表明，只要拥塞控制运行正确，多径 TCP 就有好处。 单纯的解决方案不如单路径 TCP。6 中，我们将讨论我们从实施
4、 Linux 的协议学到了什么。 问题是难以解决的：在接收缓冲区如何避免死锁当包可以不按顺序到达，而有关数据流本身序列空间 vs 子流序列空间。 但仔细考虑角落案件迫使我们向具体实施。 7 中，我们将讨论协议的设计的相关工作。在本文中我们将最终限制我们的注意力到端到端的容量共享的机制，特别模拟 TCP 的拥塞控制算法。 我们将假定每个 TCP 流的访问一个或多个路径，它可以控制发送多少流量在每个路径上，但它不能指定自己的路径。例如，我们的 Linux 实现使用多宿主的在一端或两端提供路径的选择，但它依赖于标准Internet 路由机制确定那些路径是什么。 我们这些原因（i）本 IETF 工作组
5、在相同的限制下工作，（）它们会导致一种容易部署的协议，不修改互联网的核心，及（iii）的理论结果表明，无效的结果可能会出现时，无论是终端系统和核心参与在均衡流量1。2。多路径资源分配 的设计问题基本的基于窗口的拥塞控制算法在 TCP 组成附加的增加行为当没有被检测到损失和被观察到亏损事件乘法减小时。 总之：一算法：常规 TCP每个 ACK，增加拥塞窗口 W 1 /w，导致每个 RTT 增加一个数据包。每损失，降低 W 的 W / 2。此外，在连接的开始，一个使用指数增加，重传超时后立即使用。 较新版本的 TCP 241为简单起见，我们表达的是 Windows 在本文中的数据包，但真正的实现通常
6、保持他们（以字节为单位）。1第 2 页图 1：一个场景显示的重要性的加权子流的侵略性。更快的网络行为时，下载网页，我们可以相信，我们的多径增强直截了当应用到这些版本，但它对于未来工作是一个话题。我们提出的拥塞控制算法是这样的：算法：MPTCP一个连接包括一系列子流 R 的，其中每个通过互联网可能会采取不同的路线。 每子流 R，维护其自身的拥塞窗口 W。 在 MPTCP 发送包流通过子流在子流窗口的空间中变得有用。 窗户适于如下：子流 R 的每个 ACK 子集 SR，包括路径 R，计算然后在所有的 S 中找到最小值，并增加 Wr 那么多。 （找到这些部分的最小值的复杂性是线性的，就像我们在附录中
7、显示。）子流 每损失一次，减少窗口 w 减半。这里 RTT 是测量子流 r 的往返时间。 我们用一个平滑的 RTT 估计，计算同样为 TCP。在我们的实现中， 只有当拥塞窗口的增长到能容纳更多的数据包，我们计算增加参数，而不是每一个 ACK 每个子流程。以下小节解释我们是如何得出这种设计。 我们着手回答的基本问题是如何精准的适应多路径 TCP 的子流窗口，从而获得最大的可能的性能，受约束并存优雅与现有的 TCP 流量。2.1 公平共享的瓶颈显而易见的问题要问的是，为什么只是运行常规 TCP 拥塞控制每个子流？ 考虑图 1 中的场景。如果多路径 TCP 两个路径上 都运行 TCP 拥塞控制，那么
8、多路径流，得到两倍多的吞吐量相对于单一路径流量（假设所有的往返时间是相等的）。 这是不公平的。 一个明显的解决方案是运行一个加权的 TCP 版本图 2：一个场景来说明的重要性选择不太拥挤的路径在每个子流上，加权，采取常规 TCP 会用的一些固定的一小部分的带宽。 5中提出的加权 TCP 不适合重量小于 0.5，所以不是11考虑下面的算法 EWTCP。一算法：EWTCP对于每个通道 R 的 ACK，以 a/Wr 增加窗口 W每个路径 上一旦有丢失了，窗口 Wr 减半。这里 W 是路径 R 窗口大小，a= 1 /N，其中 n 是路径的数目。每个子流得到的窗口的大小成比例的 a 的平方 11。通过选
9、择 a= 1 /n，且假设平等的 RTT，多径流量得到相同的吞吐量作为一常规 TCP在瓶颈链路上。 这是一个吸引人的简单的机制，它不需要任何形式的明确共享瓶颈检测。2.2 选择有效的路径Athough EWTCP 公平对待常规 TCP 流量，不会使非常有效地利用网络。考虑到的有点刻意的场景图 2，和支持构成这三个环节各有容量 12MB /秒。 如果每个流均匀地分布在它的访问流量分割通过两条路径，然后，每个子流程将得到 4MB / S，因此每个流 8Mb / s 的。 但是，如果每个流只使用单跳最短路径，它可以得到 12MB /秒。 （但一般情况下，它是没有效率始终只使用最短路径，模拟4 数据中
10、心拓扑显示。）一个解决方案已经在有关拥塞控制理论文献中给出，独立15和10。 其核心思想是，一个多流应该转移所有的流量到最拥堵最轻的路径。 在像图 2 情况。 两跳路径将具有更高的液滴比单跳路径的概率，因此应用的核心想法将产生的有效配置。 令人惊讶的是它2在这种拓扑结构 EWTCP 实际上不会分裂 TRAFFIC 均匀，由于两跳路径遍历两个瓶颈等环节遇到更高的拥堵。 事实上，如 TCP吞吐量的损失的平方根成反比率，EWTCP 将结束发送约 3.5MB / s 的两跳路径和为 5Mb / s 的单跳路径，共超过甚至分裂 8.5Mb/s-slightly，但大部分小于具有最佳分配。2第 3 页事实
11、证明，这样就可以实现（在理论上）无任何需要明确测量拥堵3 考虑下面的算法，称为 COUPLED4：一算法：COUPLED对于路径 R 每个 ACK，增加窗口 W 由 1 / Wtotal。每个路径 损失，减少窗口 W 由 Wtotal / 2。这里 Wtotal 是所有子流的总的窗口大小。我们保持 W 非负，在我们的实验中我们势必要1pkt 目，而是为了分析很容易认为它是0。为了得到一个在此算法中的行为的感觉，我们派生近似的吞吐量公式。首先考虑所有的路径具有相同的损失率 P 的情况， 每个窗口 w按 ACK 数增加，丢掉时减少，处于平衡状态，增加和减少必须平衡的应答率，即每 ACK平均增幅必须
12、等于滴率每一滴水，即平均下降（2）解为 Wtotal 给 Wtotal =2（1 - P）/p2 /p（近似越接近如果 p比较小的）。 注意当有只是一个路径，那么 COUPLED 降低为常规TCP，Wtotal 公式不依赖于路径的数目，因此 OUPLED 自动解决了第 2.1节中的公平性问题。损失率并不都是想相等的，让 p 作为路径 R 的损失率，并令 pmin 是所有路径的最小丢失率。 对于所有路径增加和减少的数量是相同的，但较高的 h 的路径与会看到更多的减少，因此 p Pmin 的路径上平衡的窗口大小为 w= 0。在图 2 中，两跳路径通过两个挤塞连结，因此，他们将有较高的损耗率比一个跳
13、路径，因此 OUPLED 仅使用单跳路径上作出了有效的选择。数据流从更拥塞的路径中移开的一个有趣的结果通过整个网络的丢失率将趋于平衡。 3 实验这证明一点。 或考虑如图 3 所示网络，假设所有往返时间是相等的。3当然，它也可以实现通过显式测量拥堵11，但是这引起了棘手的测量疑问句蒸发散。4OUPLED是改编自15，方程（21）和10，方程重刑（14），提出了一个差分方程模型基于速率的多版本 ScalableTCP 16。 我们应用背后的概念，经典的基于窗口的方程TCP，而不是基于速率的版本 ScalableTCP 的，翻译成拥塞控制微分方程算法。图：情景 EWTCP（左）不均衡拥塞或总吞吐量而
14、 OUPLED（右）。图 4：在该情境下的 RTT 和拥塞不匹配可能会导致低吞吐量。每个环节都会根据 EWTCP 均分使用它的子流，从而流入 A 得到的吞吐量 5 和 6 Mb /秒，B 得到 6 和 5 Mb / s 的，和 C 得到 5 和 3 Mb / s 的。 由于 TCP 的吞吐量是与丢弃的概率负相关，我们推断，3MB / s 的链路最高丢失概率和 12Mb / s 的链路最低，对于 COUPLED，我们可以计算的吞吐量，通过使用两个事实：每个子流流使用路径仅当该路径在其可用路径具有最低的损耗率 pmin 和流量的总吞吐量是2 /pmin唯一的结局与这些事实一致是所有四个链接到具有相
15、同的损失率，所有流量以获得相同的通过，即 10Mb / s 的。在这种情况下，规则“只用一个路径，如果路径在可用路径间丢弃概率最低 “用于平衡拥堵和平衡的总吞吐量。在某些情况下，这些目标 本身 可能是可取的 。即使不是他们的主要目标，他们作为一个测试仍然有用的：多路径拥塞控制算法不平衡拥堵的图 3 不可能进行有效的路径选择图 2。2.3 RTT 错配的问题往返时间（RTT）是不平等时，EWTCP 和 COUPLED 双方都会有问题。 这在5 中通过实验表现出来。 要了解这个问题，可以考虑这个场景，无线客户端有两个接口中所示图 4：3G 的路径通常使用大的缓冲区，导致漫长的等待和低丢失率，而 W
16、IFI 路径可能有较小的延迟和更高的丢失率。 第 4 页图 5：场景，多径 TCP 可能困，使用一个不太理想的路径。如一个简单的近似，丢失率固定（尽管在实践中，例如，在5 中的实验，掉落率也将取决于发件人的数据速率）。此外，一个单路 TCP 吞吐量2 / P / RTTpkt/s。 然后单路无线网络的流量将得到 707pkt/s，并单路径 3G 流量将得到141pkt/s。每条路径上 EWTCP 只有单路径 TCP 一半的侵略性，因此它会得到总吞吐量（707 +141）/ 2 = 424pkt/s。OUPLED 会将所有它的流量发送到少拥塞的路径，并能在其得到了相同的窗口大小作为单路径 TCP
17、，所以它会得到吞吐量 141pkt/s。5EWTCP 和 COUPLED 都是不希望的用户考虑是否采用多路径 TCP。一种解决方案是基于窗口的控制切换为基于速率控制;基于速率方程15，10，启发 OUPLED 不用遭受 RTT 不匹配问题。 但是，在网络拥塞控制架构方面这将是一个重大的变化，改变的时间还没有来。 相反，我们有一个基于窗口的拥塞控制的实际建议，这是我们2.5 会介绍。 不过首先，我们描述的另一个关于 OUPLED 的问题以及我们的补救措施。2.4 适应负载的变化原来有另一个关于 COUPLED 的陷阱，显示自己，即使当所有的子流具有相同 RTT。 考虑中的场景图 5。 最初有两个
18、单路径 TCP 在每一个连路上，和一个多径 TCP 能够同时使用两链接。在通过这两链路时 ，它应该结束平衡本身，因为如果它是不均匀然后一个链路比其他会较为挤塞和 COUPLED 会把一些它的访问流量转移到不太拥挤的链路上。 现在假设一个流量顶部链接终止，所以顶部链接是不太拥挤，因此多 TCP流将其所有流量到顶部链接。 但是，那么它就是困：无论有多少额外的拥塞在顶部链接上，多径 TCP 流不使用底部链路，因此它5比例经理在多路径算法11所有的交通也将移动到不太拥挤的道路上，同样的结果。没有得到的 ACK 在底部链接，所以 COUPLED 底部子流上是不能够增加窗口大小的。 在3 中的实验，证明了
19、同样的问题。我们可以总结这一简单的规则，“仅使用最不拥挤的路径“需要通过相对的的考虑达到平衡，“始终保持足够的流量在其他路径，一个探头，当他们提高让你可以快速发现。“事实上，我们实施 OUPLED保持窗口大小1pkt，所以它总是有一些探测流。理论上工作15，方程（11）和10，方程（14），启发 OUPLED 也有一个参数控制大量的探测，理论认为，与无穷探测渐近（足够长的时间后，有足够的流量）实现公平和有效率的分配。但是，我们在实验中发现，如果探测流太少，拥塞反馈信息太不够频繁，以至于不能在有效时间内发现其变化。 使得噪声反馈（随机数据包丢失）更难得到一个快速可靠的信号。 作为折中，我们提出以
20、下建议。一算法：SEMICOUPLED对于每个 ACK 通道 R，增加窗口 W 由 a/Wtotal。每个路径 损失，减半窗口 W。在这里，a 是常数，控制侵略性，在下面讨论。EMICOUPLED 试图每条路径上的流量保持适量的，同时还具有偏向不太拥挤的路径。 例如，假设一个 EMICOUPLED 流量使用三个路径，两个丢失的概率 1，和第三丢弃概率 5。 我们可以计算平衡的窗口大小平衡相似讨论相似，当为 1 - p1，口的大小是在三个路径的例子，则流程将投入 45的重量。在每个较不拥挤的路径和 10较拥挤的路径。 这中间 EWTCP 的（每条路径上 33）和COUPLED（更多拥路径 0）。
21、为了能够获得公正如像图 1，相当简单的调整的参数 A。 对于更复杂这样的场景图 4 中，我们需要一个更严格的清晰的公平，我们现在建议。2.5 补偿 RTT 不匹配在以偏见和公正的原因在有原则的方式，我们提出了以下两个要求多路径拥塞控制：第 5 页图 6：两个路径流的公平约束。约束（3）在左边，约束条件（4）上的正确的。多径流量应给予一个连接，至少它会与单路径 TCP 的最佳路径上的吞吐量一样多。 这是用来确保部署多路径的激励。多路径流在任何路径上或者所有路径上，不应该比如果它是一个用最好的那些路径的单一路径的 tcp 流占有更多能量。 这保证它在瓶颈链路上不会过分伤害其他流量，无论什么样的路径
22、组合通过链接。在数学符号，假设一组可用路径是 R，让 w 获得平衡窗口通过通道 R多路径 TCP，让 作为相等窗口中，将通过一个单一的路径 TCP以下被获得，在路径 r 的损失率下。 我们应需要：这些限制被示出，一个两路径的流量，在图 6。 在左手图中示（3），即（W1，W2）应该位于对角线以上。 该确切的对角线上的斜率的比率是由往返时间（RTT）支配，在这里我们选择了他们让。 右手图中示出了三个约束条件（4）。 S = path1约束说挑上的一个点或左侧的垂直线。 该约束 S = 路径2说挑上的一个点或低于水平线。 联合瓶颈制约 S = path1，path2说，挑点在对角线上或以下。 显然
23、，同时满足（3）及（4）的唯一方法是是在对角线上挑选一些点，箱里面;任何这样的点是公平的。（另外，考虑第 2.2 节中的操作说，我们应该更喜欢不太拥挤路径，并在此 因此，损失率满足 p1P2，因此，我们应该更喜欢右手侧的对角线）。下面的算法，修改的 SEMICOUPLED，满足了我们两个的公平性要求，当流有两条路可供选择。 EWTCP 也可以固定类似的修改。 5 显示的实验改造工程。算法每个 ACK 子流 上，增加窗口 w每损失子流 上，减半窗口 w由W 是当前窗口的大小通道 R 和 是平衡窗口大小通道 R，同样增加和减少的规则是相似于 SEMICOUPLED，所以该算法更喜欢较不拥塞的路径。
24、不同的是，上限为窗口增加 1 / W，以任一条路径上确保多径流量可以采取没有更多的能力比单路径 TCP 两种路径流量，也就是说，它可以确保我们的水平内和图 6 中的垂直约束。该参数 a 控制的侵略性。 明确地如果 a 是非常大的，那么两个流像两个独立流量，因此平衡窗口将在右上方的方块中图 6。 另一方面，如果 a 是非常小的，那么流量将被粘在的盒子的左下方。 正如我们所说的，这两个公平目标需要我们确切的打斜线。 问题是如何找到 a 实现这一目标。我们可以计算出 a 从平衡方程。 在平衡时，窗口增加和减少的平衡在每个路径上，因此制作近似的 P 是足够小，1 - P1，并将其写在（6）通过同时解决
25、（3）（不平等代替平等）和（6），到达（5）。我们的最终 MPTCP 算法，在2 开始，是一个概括的上述算法任意数目的路径。 证明它满足（3） - （4）在附录中。 式（5），技术上需要 w，平衡窗口的大小，而在我们最终的算法，我们已经使用瞬时窗口大小。 下面所描述的实验暗示这不会造成问题。打到公平太难了？“以不超过一个单一的路径 TCP”是我们的公平性的目标。 乍一看这似乎过于严格。 例如，考虑一个单路径有 14.4MB / s 的无线接入链路的用户第 6 页图 7：环面拓扑。 我们调节的链接 C 的容量，和测试拥堵平衡保持均衡。图 8：改变的影响链接 C 的容量的比率损失率 p/ P一。
26、所有其他链接有能力 1000pkt /秒。图 9：突发 CBR 流量顶部链接需要快速重新响应多径流。然后添加一个 2MB / s 的 3G 接入链路。 如果不是这个用户现在16.4MB / s 的，不公平的目标决定 14.4MB /秒？我们描述了这种情况下的测试，有些像5 中的。 事实上，MPTCP把相同的吞吐量给予接入链路的带宽的总和，当不存在的相互竞争的流。 当有连路上竞争的流量的答案是不同的。要明白这是怎么回事，请注意，我们的精确公平目标说“不超过将获得由一个单一的路径 TCP 遇到了同样的丢失率 “。假设有任一链接，没有竞争流量。用户只需要 14.4MB / s 的。 然后一个或另两个
27、中的一个接入链路是未充分利用的，所以它没有亏损，假设没有亏损的单路径的 TCP 获得非常高的吞吐量，因此公平的目标允许 MPTCP 以增加吞吐量。一旦两个接入链路完全动用 该系统将达到平衡。 见5 进一步的实验结果，包括接入链路上的流量竞争的情况。3。 在多宿主服务器中平衡拥塞53 -我们调查多径 TCP 在三种不同的情况的行为：一个多宿主网络服务器，数据中心，移动客户端。 本文我们的宗旨是产生一个多路径算法跨越广泛的情况能强劲工作。 这些三个场景将展示2 中的所有的设计决策-但并非所有的设计决策在每一个场景都是重要的。第一种情形是一个多宿主互联网服务器。多宿主重要服务器在过去十年中已经变得无
28、处不在，没有一家公司的依赖于网络为他们的业务接入能力要依赖于一个单一的上游网络。 然而，通过这些链路平衡流是很难的，就证明了运营商通过使用 BGP 技术，如跳前缀分裂和 AS 前面加。 这样的技术是粗粒度的，速度很慢，且链接系统达到目标很有压力。 在本节中，我们将展示多径运输可以平衡拥堵，即使只有一少数流是具有多径能力。我们将首先简单的模拟在展示拥塞均衡，来说明2 设计讨论比较MPTCP 到 EWTCP 和 COUPLED。在静态的情况 COUPLED 优于 MPTCP 的会优于 EWTCP，在动态的情况下，顺序颠倒，但在每种况下 MPTCP 接近最好的，所以它似乎是一个合理的折中。 我们然后
29、将验证结果与我们的研究实验测试结果平台运行 Linux 实现。静态负载平衡仿真，首先，我们将调查长期稳定的环境中的负载平衡短命的流量，测试预测2.2。 图 7 所示一个场景安排在一个圆环的五个瓶颈链路，使用两个多径流量。 所有路径有平等的 RTT 为100ms，和缓冲器是一个带宽延迟产品。 我们将调整链接 C 的运力.当的链接 C 的容量减少，那么它会更加拥挤，所以这两个流使用它时应分流到B 和 D，使这些链接成为更加拥挤，所以是一个连锁效应和他们的流量转移其他流量到链路 A 和 E。与完美的平衡，最终的结果应该是平等拥塞到各个链路上。图 8 划分拥塞的不平衡成为相等容量的链路 C.当所有链路
30、有相同的容量（C = 1000pkt /秒），然后拥堵当然所有的算法是完美的平衡。当链接 C 是较小的，不平衡的较大值。 OUPLED 是非常善于平衡拥堵，EWTCP 是坏的，MPTCP 是在两者之间。 我们还发现，平衡拥塞导致总数据流速率之间更公平了：当链路 C 具有容量 100pkt/ s，然后，JAINS 的公平指数为 0.99，流速与 COUPLED0.986 为 MPTCP 和 0.92 为 EWTCP 的。6第 7 页图 10：服务器负载均衡与 MPTCP动态负载平衡仿真，接下来我们阐述一个关于动态负载如2.4 中所述的问题。我们运行一个两个链路的模拟如图 9，两个 100Mb /
31、 s 的容量和缓冲区 50 包，和一个多路径流，其中每个路径具有 10ms 的 RTT。在顶部链接有一个额外的突发 CBR 流 100Mb / s 的速度的随机的平均10ms 时间发送一个，然后一个随机 100ms 的时间是安静的。 该多径流量应该只使用底部的链接时 CBR 流的存在，并且它应该迅速启用这两个链接当 CBR 流缺席。 我们的理由了 COUPLED 做得不好，和我们获得的吞吐量证实这一点。 在 Mb / s 的，它们在很宽的范围的不同的情况内，我们已经发现了类似的问题。 确切的数字取决于拥塞水平的变化有多快，在这个阐述中，我们选择了特别的突然变化。 一移动设备可能期望类似的突然变
32、化当一个无线接口上的覆盖范围是突然丢失，然后恢复正常。服务器负载平衡实验，接下来我们给实验测试得出的结果，从 Linux平台。 实施的 MPTCP 平衡拥塞，验证我们刚才提出的模拟是有用的。首先，我们运行有两个 100Mb / s 链路的双宿主服务器以及一些客户机。 我们使用了模拟网络添加 10ms 的延迟来模拟广域的情况。 我们运作 5 个客户端机器连接到链接 1，和 15 链接 2，均使用长寿命的Linux 2.6 的 NewReno TCP 流量。图 10 示出 第一分钟通过实现清楚的链接 2 有更多的拥堵。 然后，我们开始 10 多径流量能够同时使用链接。 完美的负载平衡将需要这些新的
33、流量完全转向链接 1。 这还没有完全实现，但尽管如此，多路径对平衡负载有显着帮助，尽管只有 1/3构成流量的总数。该图仅显示 MPTCP; COUPLED 是相似和 EWTCP 的略差，当它迫使更多的流量到链路 2。我们的第二个实验中，使用相同的拓扑结构。链接 1 上我们产生泊松到达的 TCP 流率 10 张/秒（轻载）和 60 幅/秒（重加载）之间交替，来自一个帕累托分布与文件大小平均 200KB。 链接 2，我们跑了一个单一的长寿命 TCP 流。 我们也跑了三个多径流量，一个用于每个多路径算法。 他们的平均吞吐量分别为 61MB / s 的为 MPTCP，应用于 54Mb / s 的为 C
34、OUPLED 和 47MB /秒 EWTCP。 在重负载 EWTCP做了最坏的，因为它没有移动尽可能多的流量到少拥塞路径。 在轻负载 COUPLED 做了最糟糕的，因为阵阵的交通链接 1 推到链路 2，在那里仍然被困甚至链接 1 清理后。4。 数据中心高效的路由公司在云应用增长如谷歌，微软和亚马逊已经形成了巨大数据中心显着的数据流机器之间的转换，而不是仅仅移动到因特网中。 为了支持这一点，研究人员已经提出了新的比传统已经被实施的有更密集的互连架构。 两个这样的建议，FatTree 2和 BCube 8，在图 11 中示出。 该互连装置密度，有许多可能的路径在任何一对路径之间。所面临的挑战是：我
35、们如何能够保证负载有效地分布，无论交通格局？数据中心任何形式的多径 TCP 的一个明显的好处是，它可以在主机NICs 缓解瓶颈。 例如在 BCube，图 11（b）条，如果核心是轻载并且主机拥有单一大流量，然后它是有道理的，同时使用这两个可用的接口。多路径 TCP 是当网络核心是瓶颈也有利的。 为了说明这一点，我们比较多路径 TCP 和平等成本多路径（ECMP）的单路径 TCP，这是我们通过随机使每个模拟 TCP 源接的最短跳路径之一。 我们跑了包级仿真 FatTree with128 单接口主机和 80 个 8 端口交换机，和每对主机，我们随机选择了 8 个路径使用多路径。 （我们之所以选择
36、 8 路径在下面的讨论）。而且，我们模拟 BCube 的 125 三接口主机和 25 个五口交换机，每对主机，根据的 BCube 路由算法我们选择了 3 边相交路径，随机选择中间节点当算法需要选择。所有的链接 100Mb / s。我们模拟了三种交通模式，由7第 8 页图 11：两个建议数据中心的拓扑结构。 大胆的线条显示出多条路径之间的来源和目的地。图 12：多路径需要 8 个路径得到很好的利用 FatTree图 13：吞吐量和损失率的分布，在 128 节点FatTree长寿命的流量组成。 TP1 是随机排列：每个主机打开一个数据流到到一致随机选择的单一目的地，例如，每个主机有一个单一的传入流
37、量。对于 FatTree，这是最少量的流，可以充分利用网络，是一个很好的整体利用率的测试。 在 TP2 打开每个主机 12 流向 12 个目的地; FatTree 目的地是随意选择的，而他们在 BCube 是主机的邻居三个层次中。 这模仿写在一个分布式的文件系统的通信的地方，一个块的副本在物理拓扑中可能互相靠近被放置，以允许更高的吞吐量。 我们采用了高数量的副本作为一个压力测试的地方。 最后，TP3 是一个稀疏流量模型：30的主机打开一个流量到一个随机选择的单一的目的。FatTree 模拟。在 FatTree 中每个主机的吞吐量的获得以 Mb / s 为单位，是：这些数字表明，所有三个流量模式
38、，EWTCP 和 MPTCP 有足够的路径多样性“发现”在网络中几乎所有的能力，我们可以看到的事实，他们得到接近充分利用机器的 100Mb / s 的接口卡。 图 12 示出通过作为路径的使用的功能取得的吞吐量，MPTCP 在 TP1 下，在通过一系列流量矩阵和数千台主机的模拟，我们已经发现，8 就足够了得到 90的利用率。平均吞吐量数字没有完全在图片中给出。 图 13 示出的分布，通过对每个流程的吞吐量分布，每个链路上的损失率，通过三种算法获得，TP1 的流量模式。 我们看到，MPTCP 在公平分配吞吐量上比 EWTC P 做一个更好的工作，2.2 和3 讨论的原因。公平事宜，许多分布式计算
39、的数据中心处理许多节点和被最慢的节点的响应时间所限制。我们也看到 MPTCP 在平衡拥堵方面做一个更好的工作的。BCube 模拟。每个主机吞吐量在 BCube 中以 Mb / s 表示，分别是：这些的吞吐量数字反映三种不同的现象。 首先，双方的多路径算法允许主机使用它的接口，而所有这三个单路径 TCP 只能使用一个，所以他们允许更高的吞吐量。 网络核心载入，这在稀疏的交通格局TP3 最清晰。 二，BCube 路径有不同的跳数，因此他们很可能会遍历不同数量的瓶颈，所以一些路径比其他人更拥挤。 如2.2 所讨论的，一个高效的多路径算法应该转移8第 9 页图 14：多径流同台竞技两个单路流图 15：
40、多 TCP 吞吐量单路径，链路 1 的比较 3G WiFi 和链接 2。图 16：流量比为 M 的吞吐量的更好的流动 S1 和 S2，因为我们不同的链接图 14 2。流量使其远离拥堵，EWTCP 没有做到这个，因此比 MPTCP 其吞吐量趋于变得更糟。这在 TP2 特别清楚，并没有显着 TP3，其中的核心有一点拥塞。 第三，第 2.4 节中即使 MPTCP 不把所有的流量远离最拥挤的路径，所以当发生最不拥挤的路径都变成最短跳路径。而最短跳单路径TCP 会做更好， 这是在 TP2 所发生过的。 （当然，这不总是对的，最不拥挤的路径是所有最短跳路径，最短跳单路径 TCP 在其他情况下确实很差。）综上所述，在很宽的范围的数据流模式下 MPTCP 的执行的很好。在某些情况下 EWTCP 实现如 MPTCP 一样好，并在其他情况下，它通过功亏一篑。 即使它的平均吞吐量跟 MPTCP 的一样好，它是不公平的。我们已经比较多径 TCP 和单路径的 TCP，假设从最短跳可用路径随机抽取的单一路径中。 随机化在某种程度上有助于平衡流量，但它很可能造成一些拥塞热点。 另一种平衡流量解决方案是使用一个集中调度，监控大流量和解决优化问题，计算好的路线问题3。 我们有研究发现，为了 MPTCP 获得具有可比性的性能，可能需要重新运行调度
