翻译design, implementation and evaluation of congestion control

第1页设计，实施和评价的拥塞控制多径TCP达蒙WISCHIK，海东青RAICIU，亚当格林哈尔希，马克汉德利伦敦大学学院（UNIVERSITYCOLLEGELONDON）摘要多路径TCPIETF工作组的建议，MPTCP，允许一个单一的数据流被T通过多条路径来分割开。这在可靠性方面有明显的好处，而且还可以更有效地利用网络资源。我们描述了一个多路径拥塞控制算法的设计，我们在LINUX落实，我们为多宿主服务器，数据中心和移动客户端评估。我们发现，一些明显的多路径拥塞控制解决方案可以是有害的，但是相比单路径的TCP，我们的算法提高了吞吐量和公平性。我们的算法是一个TCP下拉替换，并且我们相信它是安全的部署。1。简介多路径TCPIETF工作组的建议，MPTCP7，允许一个单一的数据流被分割在多条路径。这可靠性上的明显的好处连接路径发生故障时链接依然能坚持不断开。它也可以对下面我们展示的多宿主服务器和数据中心以及移动设备在负载均衡方面有好处。多路径TCP还提出了问题，一些明显的一些微妙的，关于应如何在竞争的流之间有效率的和公平的共享网络容量。本文详细介绍了设计和实现多路径拥塞控制算法，它ROBUSTLY跨广泛的情况下，可以是作为一个TCP混入替换。2中，我们提出了一个多径TCP拥塞控制窗口机制，然后阐明它带给我们的问题。本节通过相关的例子和通过计算分析实践思考所呈列作为设计空间路标。这不是一个详尽的设计空间调查，我们并不认为我们的算法是最佳，甚至定义最优需要更先进的理论基础比我们还没有发展延伸出来。一些问题（2123）提出在多路径拥塞控制的一些相关文献上，但并非所有已解决。其他（2425）的小说。ZAI35，我们在三个应用场景评估我们的算法多宿主服务器，数据中心和移动设备。我们这样做是通过仿真一个高速的自定义数据包级的模拟器，在LINUX实施的试验台实验。我们表明，只要拥塞控制运行正确，多径TCP就有好处。单纯的解决方案不如单路径TCP。6中，我们将讨论我们从实施LINUX的协议学到了什么。问题是难以解决的在接收缓冲区如何避免死锁当包可以不按顺序到达，而有关数据流本身序列空间VS子流序列空间。但仔细考虑角落案件迫使我们向具体实施。7中，我们将讨论协议的设计的相关工作。在本文中我们将最终限制我们的注意力到端到端的容量共享的机制，特别模拟TCP的拥塞控制算法。我们将假定每个TCP流的访问一个或多个路径，它可以控制发送多少流量在每个路径上，但它不能指定自己的路径。例如，我们的LINUX实现使用多宿主的在一端或两端提供路径的选择，但它依赖于标准INTERNET路由机制确定那些路径是什么。我们这些原因（I）本IETF工作组在相同的限制下工作，（）它们会导致一种容易部署的协议，不修改互联网的核心，及（III）的理论结果表明，无效的结果可能会出现时，无论是终端系统和核心参与在均衡流量1。2。多路径资源分配的设计问题基本的基于窗口的拥塞控制算法在TCP组成附加的增加行为当没有被检测到损失和被观察到亏损事件乘法减小时。总之一算法常规TCP每个ACK，增加拥塞窗口W1/W，导致每个RTT增加一个数据包。每损失，降低W的W/2。此外，在连接的开始，一个使用指数增加，重传超时后立即使用。较新版本的TCP241为简单起见，我们表达的是WINDOWS在本文中的数据包，但真正的实现通常保持他们（以字节为单位）。1第2页图1一个场景显示的重要性的加权子流的侵略性。更快的网络行为时，下载网页，我们可以相信，我们的多径增强直截了当应用到这些版本，但它对于未来工作是一个话题。我们提出的拥塞控制算法是这样的算法MPTCP一个连接包括一系列子流R的，其中每个通过互联网可能会采取不同的路线。每子流R，维护其自身的拥塞窗口W。在MPTCP发送包流通过子流在子流窗口的空间中变得有用。窗户适于如下子流R的每个ACK子集SR，包括路径R，计算然后在所有的S中找到最小值，并增加WR那么多。（找到这些部分的最小值的复杂性是线性的，就像我们在附录中显示。）子流每损失一次，减少窗口W减半。这里RTT是测量子流R的往返时间。我们用一个平滑的RTT估计，计算同样为TCP。在我们的实现中，只有当拥塞窗口的增长到能容纳更多的数据包，我们计算增加参数，而不是每一个ACK每个子流程。以下小节解释我们是如何得出这种设计。我们着手回答的基本问题是如何精准的适应多路径TCP的子流窗口，从而获得最大的可能的性能，受约束并存优雅与现有的TCP流量。21公平共享的瓶颈显而易见的问题要问的是，为什么只是运行常规TCP拥塞控制每个子流考虑图1中的场景。如果多路径TCP两个路径上都运行TCP拥塞控制，那么多路径流，得到两倍多的吞吐量相对于单一路径流量（假设所有的往返时间是相等的）。这是不公平的。一个明显的解决方案是运行一个加权的TCP版本图2一个场景来说明的重要性选择不太拥挤的路径在每个子流上，加权，采取常规TCP会用的一些固定的一小部分的带宽。5中提出的加权TCP不适合重量小于05，所以不是11考虑下面的算法EWTCP。一算法EWTCP对于每个通道R的ACK，以A/WR增加窗口W每个路径上一旦有丢失了，窗口WR减半。这里W是路径R窗口大小，A1/N，其中N是路径的数目。每个子流得到的窗口的大小成比例的A的平方11。通过选择A1/N，且假设平等的RTT，多径流量得到相同的吞吐量作为一常规TCP在瓶颈链路上。这是一个吸引人的简单的机制，它不需要任何形式的明确共享瓶颈检测。22选择有效的路径ATHOUGHEWTCP公平对待常规TCP流量，不会使非常有效地利用网络。考虑到的有点刻意的场景图2，和支持构成这三个环节各有容量12MB/秒。如果每个流均匀地分布在它的访问流量分割通过两条路径，然后，每个子流程将得到4MB/S，因此每个流8MB/S的。但是，如果每个流只使用单跳最短路径，它可以得到12MB/秒。（但一般情况下，它是没有效率始终只使用最短路径，模拟4数据中心拓扑显示。）一个解决方案已经在有关拥塞控制理论文献中给出，独立15和10。其核心思想是，一个多流应该转移所有的流量到最拥堵最轻的路径。在像图2情况。两跳路径将具有更高的液滴比单跳路径的概率，因此应用的核心想法将产生的有效配置。令人惊讶的是它2在这种拓扑结构EWTCP实际上不会分裂TRAFFIC均匀，由于两跳路径遍历两个瓶颈等环节遇到更高的拥堵。事实上，如TCP吞吐量的损失的平方根成反比率，EWTCP将结束发送约35MB/S的两跳路径和为5MB/S的单跳路径，共超过甚至分裂85MB/SSLIGHTLY，但大部分小于具有最佳分配。2第3页事实证明，这样就可以实现（在理论上）无任何需要明确测量拥堵3考虑下面的算法，称为COUPLED4一算法COUPLED对于路径R每个ACK，增加窗口W由1/WTOTAL。每个路径损失，减少窗口W由WTOTAL/2。这里WTOTAL是所有子流的总的窗口大小。我们保持W非负，在我们的实验中我们势必要1PKT目，而是为了分析很容易认为它是0。为了得到一个在此算法中的行为的感觉，我们派生近似的吞吐量公式。首先考虑所有的路径具有相同的损失率P的情况，每个窗口W按ACK数增加，丢掉时减少，处于平衡状态，增加和减少必须平衡的应答率，即每ACK平均增幅必须等于滴率每一滴水，即平均下降（2）解为WTOTAL给WTOTAL2（1P）/P2/P（近似越接近如果P比较小的）。注意当有只是一个路径，那么COUPLED降低为常规TCP，WTOTAL公式不依赖于路径的数目，因此OUPLED自动解决了第21节中的公平性问题。损失率并不都是想相等的，让P作为路径R的损失率，并令PMIN是所有路径的最小丢失率。对于所有路径增加和减少的数量是相同的，但较高的H的路径与会看到更多的减少，因此PPMIN的路径上平衡的窗口大小为W0。在图2中，两跳路径通过两个挤塞连结，因此，他们将有较高的损耗率比一个跳路径，因此OUPLED仅使用单跳路径上作出了有效的选择。数据流从更拥塞的路径中移开的一个有趣的结果通过整个网络的丢失率将趋于平衡。3实验这证明一点。或考虑如图3所示网络，假设所有往返时间是相等的。3当然，它也可以实现通过显式测量拥堵11，但是这引起了棘手的测量疑问句蒸发散。4OUPLED是改编自15，方程（21）和10，方程重刑（14），提出了一个差分方程模型基于速率的多版本SCALABLETCP16。我们应用背后的概念，经典的基于窗口的方程TCP，而不是基于速率的版本SCALABLETCP的，翻译成拥塞控制微分方程算法。图情景EWTCP（左）不均衡拥塞或总吞吐量而OUPLED（右）。图4在该情境下的RTT和拥塞不匹配可能会导致低吞吐量。每个环节都会根据EWTCP均分使用它的子流，从而流入A得到的吞吐量5和6MB/秒，B得到6和5MB/S的，和C得到5和3MB/S的。由于TCP的吞吐量是与丢弃的概率负相关，我们推断，3MB/S的链路最高丢失概率和12MB/S的链路最低，对于COUPLED，我们可以计算的吞吐量，通过使用两个事实每个子流流使用路径仅当该路径在其可用路径具有最低的损耗率PMIN和流量的总吞吐量是2/PMIN唯一的结局与这些事实一致是所有四个链接到具有相同的损失率，所有流量以获得相同的通过，即10MB/S的。在这种情况下，规则“只用一个路径，如果路径在可用路径间丢弃概率最低“用于平衡拥堵和平衡的总吞吐量。在某些情况下，这些目标本身可能是可取的。即使不是他们的主要目标，他们作为一个测试仍然有用的多路径拥塞控制算法不平衡拥堵的图3不可能进行有效的路径选择图2。23RTT错配的问题往返时间（RTT）是不平等时，EWTCP和COUPLED双方都会有问题。这在5中通过实验表现出来。要了解这个问题，可以考虑这个场景，无线客户端有两个接口中所示图43G的路径通常使用大的缓冲区，导致漫长的等待和低丢失率，而WIFI路径可能有较小的延迟和更高的丢失率。第4页图5场景，多径TCP可能困，使用一个不太理想的路径。如一个简单的近似，丢失率固定（尽管在实践中，例如，在5中的实验，掉落率也将取决于发件人的数据速率）。此外，一个单路TCP吞吐量2/P/RTTPKT/S。然后单路无线网络的流量将得到707PKT/S，并单路径3G流量将得到141PKT/S。每条路径上EWTCP只有单路径TCP一半的侵略性，因此它会得到总吞吐量（707141）/2424PKT/S。OUPLED会将所有它的流量发送到少拥塞的路径，并能在其得到了相同的窗口大小作为单路径TCP，所以它会得到吞吐量141PKT/S。5EWTCP和COUPLED都是不希望的用户考虑是否采用多路径TCP。一种解决方案是基于窗口的控制切换为基于速率控制基于速率方程15，10，启发OUPLED不用遭受RTT不匹配问题。但是，在网络拥塞控制架构方面这将是一个重大的变化，改变的时间还没有来。相反，我们有一个基于窗口的拥塞控制的实际建议，这是我们25会介绍。不过首先，我们描述的另一个关于OUPLED的问题以及我们的补救措施。24适应负载的变化原来有另一个关于COUPLED的陷阱，显示自己，即使当所有的子流具有相同RTT。考虑中的场景图5。最初有两个单路径TCP在每一个连路上，和一个多径TCP能够同时使用两链接。在通过这两链路时，它应该结束平衡本身，因为如果它是不均匀然后一个链路比其他会较为挤塞和COUPLED会把一些它的访问流量转移到不太拥挤的链路上。现在假设一个流量顶部链接终止，所以顶部链接是不太拥挤，因此多TCP流将其所有流量到顶部链接。但是，那么它就是困无论有多少额外的拥塞在顶部链接上，多径TCP流不使用底部链路，因此它5比例经理在多路径算法11所有的交通也将移动到不太拥挤的道路上，同样的结果。没有得到的ACK在底部链接，所以COUPLED底部子流上是不能够增加窗口大小的。在3中的实验，证明了同样的问题。我们可以总结这一简单的规则，“仅使用最不拥挤的路径“需要通过相对的的考虑达到平衡，“始终保持足够的流量在其他路径，一个探头，当他们提高让你可以快速发现。“事实上，我们实施OUPLED保持窗口大小1PKT，所以它总是有一些探测流。理论上工作15，方程（11）和10，方程（14），启发OUPLED也有一个参数控制大量的探测，理论认为，与无穷探测渐近（足够长的时间后，有足够的流量）实现公平和有效率的分配。但是，我们在实验中发现，如果探测流太少，拥塞反馈信息太不够频繁，以至于不能在有效时间内发现其变化。使得噪声反馈（随机数据包丢失）更难得到一个快速可靠的信号。作为折中，我们提出以下建议。一算法SEMICOUPLED对于每个ACK通道R，增加窗口W由A/WTOTAL。每个路径损失，减半窗口W。在这里，A是常数，控制侵略性，在下面讨论。EMICOUPLED试图每条路径上的流量保持适量的，同时还具有偏向不太拥挤的路径。例如，假设一个EMICOUPLED流量使用三个路径，两个丢失的概率1，和第三丢弃概率5。我们可以计算平衡的窗口大小平衡相似讨论相似，当为1P1，口的大小是在三个路径的例子，则流程将投入45的重量。在每个较不拥挤的路径和10较拥挤的路径。这中间EWTCP的（每条路径上33）和COUPLED（更多拥路径0）。为了能够获得公正如像图1，相当简单的调整的参数A。对于更复杂这样的场景图4中，我们需要一个更严格的清晰的公平，我们现在建议。25补偿RTT不匹配在以偏见和公正的原因在有原则的方式，我们提出了以下两个要求多路径拥塞控制第5页图6两个路径流的公平约束。约束（3）在左边，约束条件（4）上的正确的。多径流量应给予一个连接，至少它会与单路径TCP的最佳路径上的吞吐量一样多。这是用来确保部署多路径的激励。多路径流在任何路径上或者所有路径上，不应该比如果它是一个用最好的那些路径的单一路径的TCP流占有更多能量。这保证它在瓶颈链路上不会过分伤害其他流量，无论什么样的路径组合通过链接。在数学符号，假设一组可用路径是R，让W获得平衡窗口通过通道R多路径TCP，让作为相等窗口中，将通过一个单一的路径TCP以下被获得，在路径R的损失率下。我们应需要这些限制被示出，一个两路径的流量，在图6。在左手图中示（3），即（W1，W2）应该位于对角线以上。该确切的对角线上的斜率的比率是由往返时间（RTT）支配，在这里我们选择了他们让。右手图中示出了三个约束条件（4）。SPATH1约束说挑上的一个点或左侧的垂直线。该约束S路径2说挑上的一个点或低于水平线。联合瓶颈制约SPATH1，PATH2说，挑点在对角线上或以下。显然，同时满足（3）及（4）的唯一方法是是在对角线上挑选一些点，箱里面任何这样的点是公平的。（另外，考虑第22节中的操作说，我们应该更喜欢不太拥挤路径，并在此因此，损失率满足P1P2，因此，我们应该更喜欢右手侧的对角线）。下面的算法，修改的SEMICOUPLED，满足了我们两个的公平性要求，当流有两条路可供选择。EWTCP也可以固定类似的修改。5显示的实验改造工程。算法每个ACK子流上，增加窗口W每损失子流上，减半窗口W由W是当前窗口的大小通道R和是平衡窗口大小通道R，同样增加和减少的规则是相似于SEMICOUPLED，所以该算法更喜欢较不拥塞的路径。不同的是，上限为窗口增加1/W，以任一条路径上确保多径流量可以采取没有更多的能力比单路径TCP两种路径流量，也就是说，它可以确保我们的水平内和图6中的垂直约束。该参数A控制的侵略性。明确地如果A是非常大的，那么两个流像两个独立流量，因此平衡窗口将在右上方的方块中图6。另一方面，如果A是非常小的，那么流量将被粘在的盒子的左下方。正如我们所说的，这两个公平目标需要我们确切的打斜线。问题是如何找到A实现这一目标。我们可以计算出A从平衡方程。在平衡时，窗口增加和减少的平衡在每个路径上，因此制作近似的P是足够小，1P1，并将其写在（6）通过同时解决（3）（不平等代替平等）和（6），到达（5）。我们的最终MPTCP算法，在2开始，是一个概括的上述算法任意数目的路径。证明它满足（3）（4）在附录中。式（5），技术上需要W，平衡窗口的大小，而在我们最终的算法，我们已经使用瞬时窗口大小。下面所描述的实验暗示这不会造成问题。打到公平太难了“以不超过一个单一的路径TCP”是我们的公平性的目标。乍一看这似乎过于严格。例如，考虑一个单路径有144MB/S的无线接入链路的用户第6页图7环面拓扑。我们调节的链接C的容量，和测试拥堵平衡保持均衡。图8改变的影响链接C的容量的比率损失率P/P一。所有其他链接有能力1000PKT/秒。图9突发CBR流量顶部链接需要快速重新响应多径流。然后添加一个2MB/S的3G接入链路。如果不是这个用户现在164MB/S的，不公平的目标决定144MB/秒我们描述了这种情况下的测试，有些像5中的。事实上，MPTCP把相同的吞吐量给予接入链路的带宽的总和，当不存在的相互竞争的流。当有连路上竞争的流量的答案是不同的。要明白这是怎么回事，请注意，我们的精确公平目标说“不超过将获得由一个单一的路径TCP遇到了同样的丢失率“。假设有任一链接，没有竞争流量。用户只需要144MB/S的。然后一个或另两个中的一个接入链路是未充分利用的，所以它没有亏损，假设没有亏损的单路径的TCP获得非常高的吞吐量，因此公平的目标允许MPTCP以增加吞吐量。一旦两个接入链路完全动用该系统将达到平衡。见5进一步的实验结果，包括接入链路上的流量竞争的情况。3。在多宿主服务器中平衡拥塞53我们调查多径TCP在三种不同的情况的行为一个多宿主网络服务器，数据中心，移动客户端。本文我们的宗旨是产生一个多路径算法跨越广泛的情况能强劲工作。这些三个场景将展示2中的所有的设计决策但并非所有的设计决策在每一个场景都是重要的。第一种情形是一个多宿主互联网服务器。多宿主重要服务器在过去十年中已经变得无处不在，没有一家公司的依赖于网络为他们的业务接入能力要依赖于一个单一的上游网络。然而，通过这些链路平衡流是很难的，就证明了运营商通过使用BGP技术，如跳前缀分裂和AS前面加。这样的技术是粗粒度的，速度很慢，且链接系统达到目标很有压力。在本节中，我们将展示多径运输可以平衡拥堵，即使只有一少数流是具有多径能力。我们将首先简单的模拟在展示拥塞均衡，来说明2设计讨论比较MPTCP到EWTCP和COUPLED。在静态的情况COUPLED优于MPTCP的会优于EWTCP，在动态的情况下，顺序颠倒，但在每种况下MPTCP接近最好的，所以它似乎是一个合理的折中。我们然后将验证结果与我们的研究实验测试结果平台运行LINUX实现。静态负载平衡仿真，首先，我们将调查长期稳定的环境中的负载平衡短命的流量，测试预测22。图7所示一个场景安排在一个圆环的五个瓶颈链路，使用两个多径流量。所有路径有平等的RTT为100MS，和缓冲器是一个带宽延迟产品。我们将调整链接C的运力当的链接C的容量减少，那么它会更加拥挤，所以这两个流使用它时应分流到B和D，使这些链接成为更加拥挤，所以是一个连锁效应和他们的流量转移其他流量到链路A和E。与完美的平衡，最终的结果应该是平等拥塞到各个链路上。图8划分拥塞的不平衡成为相等容量的链路C当所有链路有相同的容量（C1000PKT/秒），然后拥堵当然所有的算法是完美的平衡。当链接C是较小的，不平衡的较大值。OUPLED是非常善于平衡拥堵，EWTCP是坏的，MPTCP是在两者之间。我们还发现，平衡拥塞导致总数据流速率之间更公平了当链路C具有容量100PKT/S，然后，JAINS的公平指数为099，流速与COUPLED0986为MPTCP和092为EWTCP的。6第7页图10服务器负载均衡与MPTCP动态负载平衡仿真，接下来我们阐述一个关于动态负载如24中所述的问题。我们运行一个两个链路的模拟如图9，两个100MB/S的容量和缓冲区50包，和一个多路径流，其中每个路径具有10MS的RTT。在顶部链接有一个额外的突发CBR流100MB/S的速度的随机的平均10MS时间发送一个，然后一个随机100MS的时间是安静的。该多径流量应该只使用底部的链接时CBR流的存在，并且它应该迅速启用这两个链接当CBR流缺席。我们的理由了COUPLED做得不好，和我们获得的吞吐量证实这一点。在MB/S的，它们在很宽的范围的不同的情况内，我们已经发现了类似的问题。确切的数字取决于拥塞水平的变化有多快，在这个阐述中，我们选择了特别的突然变化。一移动设备可能期望类似的突然变化当一个无线接口上的覆盖范围是突然丢失，然后恢复正常。服务器负载平衡实验，接下来我们给实验测试得出的结果，从LINUX平台。实施的MPTCP平衡拥塞，验证我们刚才提出的模拟是有用的。首先，我们运行有两个100MB/S链路的双宿主服务器以及一些客户机。我们使用了模拟网络添加10MS的延迟来模拟广域的情况。我们运作5个客户端机器连接到链接1，和15链接2，均使用长寿命的LINUX26的NEWRENOTCP流量。图10示出第一分钟通过实现清楚的链接2有更多的拥堵。然后，我们开始10多径流量能够同时使用链接。完美的负载平衡将需要这些新的流量完全转向链接1。这还没有完全实现，但尽管如此，多路径对平衡负载有显着帮助，尽管只有1/3构成流量的总数。该图仅显示MPTCPCOUPLED是相似和EWTCP的略差，当它迫使更多的流量到链路2。我们的第二个实验中，使用相同的拓扑结构。链接1上我们产生泊松到达的TCP流率10张/秒（轻载）和60幅/秒（重加载）之间交替，来自一个帕累托分布与文件大小平均200KB。链接2，我们跑了一个单一的长寿命TCP流。我们也跑了三个多径流量，一个用于每个多路径算法。他们的平均吞吐量分别为61MB/S的为MPTCP，应用于54MB/S的为COUPLED和47MB/秒EWTCP。在重负载EWTCP做了最坏的，因为它没有移动尽可能多的流量到少拥塞路径。在轻负载COUPLED做了最糟糕的，因为阵阵的交通链接1推到链路2，在那里仍然被困甚至链接1清理后。4。数据中心高效的路由公司在云应用增长如谷歌，微软和亚马逊已经形成了巨大数据中心显着的数据流机器之间的转换，而不是仅仅移动到因特网中。为了支持这一点，研究人员已经提出了新的比传统已经被实施的有更密集的互连架构。两个这样的建议，FATTREE2和BCUBE8，在图11中示出。该互连装置密度，有许多可能的路径在任何一对路径之间。所面临的挑战是我们如何能够保证负载有效地分布，无论交通格局数据中心任何形式的多径TCP的一个明显的好处是，它可以在主机NICS缓解瓶颈。例如在BCUBE，图11（B）条，如果核心是轻载并且主机拥有单一大流量，然后它是有道理的，同时使用这两个可用的接口。多路径TCP是当网络核心是瓶颈也有利的。为了说明这一点，我们比较多路径TCP和平等成本多路径（ECMP）的单路径TCP，这是我们通过随机使每个模拟TCP源接的最短跳路径之一。我们跑了包级仿真FATTREEWITH128单接口主机和80个8端口交换机，和每对主机，我们随机选择了8个路径使用多路径。（我们之所以选择8路径在下面的讨论）。而且，我们模拟BCUBE的125三接口主机和25个五口交换机，每对主机，根据的BCUBE路由算法我们选择了3边相交路径，随机选择中间节点当算法需要选择。所有的链接100MB/S。我们模拟了三种交通模式，由7第8页图11两个建议数据中心的拓扑结构。大胆的线条显示出多条路径之间的来源和目的地。图12多路径需要8个路径得到很好的利用FATTREE图13吞吐量和损失率的分布，在128节点FATTREE长寿命的流量组成。TP1是随机排列每个主机打开一个数据流到到一致随机选择的单一目的地，例如，每个主机有一个单一的传入流量。对于FATTREE，这是最少量的流，可以充分利用网络，是一个很好的整体利用率的测试。在TP2打开每个主机12流向12个目的地FATTREE目的地是随意选择的，而他们在BCUBE是主机的邻居三个层次中。这模仿写在一个分布式的文件系统的通信的地方，一个块的副本在物理拓扑中可能互相靠近被放置，以允许更高的吞吐量。我们采用了高数量的副本作为一个压力测试的地方。最后，TP3是一个稀疏流量模型30的主机打开一个流量到一个随机选择的单一的目的。FATTREE模拟。在FATTREE中每个主机的吞吐量的获得以MB/S为单位，是这些数字表明，所有三个流量模式，EWTCP和MPTCP有足够的路径多样性“发现”在网络中几乎所有的能力，我们可以看到的事实，他们得到接近充分利用机器的100MB/S的接口卡。图12示出通过作为路径的使用的功能取得的吞吐量，MPTCP在TP1下，在通过一系列流量矩阵和数千台主机的模拟，我们已经发现，8就足够了得到90的利用率。平均吞吐量数字没有完全在图片中给出。图13示出的分布，通过对每个流程的吞吐量分布，每个链路上的损失率，通过三种算法获得，TP1的流量模式。我们看到，MPTCP在公平分配吞吐量上比EWTCP做一个更好的工作，22和3讨论的原因。公平事宜，许多分布式计算的数据中心处理许多节点和被最慢的节点的响应时间所限制。我们也看到MPTCP在平衡拥堵方面做一个更好的工作的。BCUBE模拟。每个主机吞吐量在BCUBE中以MB/S表示，分别是这些的吞吐量数字反映三种不同的现象。首先，双方的多路径算法允许主机使用它的接口，而所有这三个单路径TCP只能使用一个，所以他们允许更高的吞吐量。网络核心载入，这在稀疏的交通格局TP3最清晰。二，BCUBE路径有不同的跳数，因此他们很可能会遍历不同数量的瓶颈，所以一些路径比其他人更拥挤。如22所讨论的，一个高效的多路径算法应该转移8第9页图14多径流同台竞技两个单路流图15多TCP吞吐量单路径，链路1的比较3GWIFI和链接2。图16流量比为M的吞吐量的更好的流动S1和S2，因为我们不同的链接图142。流量使其远离拥堵，EWTCP没有做到这个，因此比MPTCP其吞吐量趋于变得更糟。这在TP2特别清楚，并没有显着TP3，其中的核心有一点拥塞。第三，第24节中即使MPTCP不把所有的流量远离最拥挤的路径，所以当发生最不拥挤的路径都变成最短跳路径。而最短跳单路径TCP会做更好，这是在TP2所发生过的。（当然，这不总是对的，最不拥挤的路径是所有最短跳路径，最短跳单路径TCP在其他情况下确实很差。）综上所述，在很宽的范围的数据流模式下MPTCP的执行的很好。在某些情况下EWTCP实现如MPTCP一样好，并在其他情况下，它通过功亏一篑。即使它的平均吞吐量跟MPTCP的一样好，它是不公平的。我们已经比较多径TCP和单路径的TCP，假设从最短跳可用路径随机抽取的单一路径中。随机化在某种程度上有助于平衡流量，但它很可能造成一些拥塞热点。另一种平衡流量解决方案是使用一个集中调度，监控大流量和解决优化问题，计算好的路线问题3。我们有研究发现，为了MPTCP获得具有可比性的性能，可能需要重新运行调度每100MS一次22这引起了严重的可伸缩性顾虑。不过，确切的数字取决于动态流量矩阵。5。多无线客户端现代的移动电话和设备，如诺基亚的N900有多个无线接口，如WIFI和3G，但只是其中之一可以在任何给定时间使用数据。随着越来越多的应用需要网络接入，从电子邮件到导航，通过同时使用这两个接口，多径可以改善移动用户的体验。这从固有的可变连接的无线网络对用户进行保护。3G和WIFI有相当不同的链路特性。无线网络提供更高的吞吐量和短的往返时间（RTT），但在我们的测试中，由于损失率相当高，其性能是非常可变，因为有显著24GHZ频段接口。3G的倾向更长的时间尺度上变化，我们发现它被缓冲从而导致的RTT超过一秒钟。这些不同分配办法的公平性目标提供了一个很好的测试和RTT25补偿算法的发展。我们在这里描述的实验表明MPTCP为用户提供了至少相当于其通过作为单路径的用户，并其他我们所描述的多路径算法做的更糟。单流实验，我们的第一个实验使用笔记本电脑配备了一个3G的USB接口和80211网络适配器，运行LINUX实现MPTCP。作为笔记本电脑放置在同一个房间，无线基站和3G接收正常。不移动电脑，所以特征为静态状态。我们每20秒运行15个测试无线网络条件下，5个单路径TCP，5个单路径TCP再3G条件下和5个MPTCP。的平均吞吐量（具有标准差）分别为144（02）21（02）和173（07）MB/S。我们希望，MPTCP用户获得带宽大致等于的接入链路的带宽总和。竞争流实验。我们重复实验，但现在随着在每条路径上竞争的单一路径TCP流，如在图14中。为了展示我们的RTT补偿算法，我们反复实验，但首先用EWTCP更换MPTCP然后用COUPLED。前者没有任何RTT补偿内置的，虽然该技术中，我们使用可以适应MPTCP的。对于后者，我们不知道如何建立在RTT补偿上。图15示出在5分钟的过程三个流各自获得的总吞吐量，三个多径算法的每个如图。图的上半显示的WIFI无线网络路径上的带宽实现，下半部分显示（倒）3G路径上的吞吐量，和灰色区域的范围延的两半，显示的是在两个路径上多径算法实现的吞吐量。该图显示，只有MPTCP给多径流一个公平的总吞吐量，即约更好的单路径竞争的流一样好，在这种情况下是无线网络的流量。图片有些断断续续似乎无线基站在缓冲，因此在接收端测量的TCP吞吐量在高峰和波谷之间锯齿形波动也似乎3G链接，也许缓冲堆积触发的。尽管有这些实验变化无常，长期平均水平表明，MPTCP获得公平的总吞吐量方面做得更好。从长期来看以MB/S的平均吞吐量，每个设置超过5分钟，主要有这些数字相匹配23的预测。OUPLED发送所有的流在不太拥挤的道路，所以它往往对3G的路径选择发送，并几乎不使用WIFI路径。EWTCP分割其流量，所以它得到平均WIFI和3G的吞吐量。只有MPTCP得到接近正确的总吞吐量。差额（221MB/秒为MPTCP相比256MB/S的最佳单路径TCP）可能是由于难以在适应变化频繁的3G链路速度，我们将继续研究多径TCP应该如何快速适应拥塞变化。模拟，为了补偿整个测试RTT更广泛的情景中，我们模拟的拓扑用两个有线链路，图14容量1250PKT/S和C2500PKT/S时，延迟和传播延迟RTT1500MS和RTT250MS的。乍一看我们可能期望的每个流获得250PKT/S。仿真结果有很大的不同流动S1得到130PKT/秒，流量2获取315PKT/S的,流量M得到305PKT/秒丢失概率为P1022和P2028。后有些人认为我们实现这样的目标是非常接近我们设计了算法来实现。25中讨论的，流量M说“路径2一个单一的路径TCP应该得到什么，基于对当前损失率我至少应该获得尽可能多的“并决定其吞吐量应该大约315PKT/秒。这并不是说，“你会路径2中单路径TCP会的到什么，如果我只使用路径2这将给出答案250PKT/秒。问题是，多径流量不考虑如何交流才能影响丢弃概率当其就公允率作出决定时。这是很难看到任何实际的替代。图17多径和定期吞吐量TCP运行，同时在3G和WIFI。3G图形显示反转，所以总多路径吞吐量（灰色区域），可以清楚地看到。然而，在这种情况下，其结果对于S1和M来说，比只用链路一的流M要更好。对于S2和M比仅用链接2的流量M要更好。我们反复的实验，但与C1400PKT/S的RTT1100MS时，和C2价值范围（显示为在图16中的标签）和RTT2（水平轴）。流M的目标为做的跟流动S1和S2一样好。图16示出所以情况下它是在这个百分之几的目标，除了链接2带宽延迟产品非常小，在这种情况下，由于超时而存在一些问题。在所有这些情况下，流量M利用多径比总是用两条链路中更好的一条时得到更好的吞吐量，如果它使用只是平均提高15。移动实验表明，我们的RTT补偿算法的工作原理，在一个相当测试无线环境，我们现在希望看到如何MPTCP执行当客户端是移动和3G和间歇性的WIFI连通性。我们使用相同的笔记本电脑和服务器作为静态试验，但现在的笔记本电脑用户移动楼层之间移动。该建筑有效的WIFI覆盖大部分楼层，但是楼梯区域没有。3G网络覆盖是可以接受的，但因为其他用户使用有时候严重阻塞。实验开始，在3G接口运行一个TCP和一个通过WIFI，都是从其它空闲大学服务器下载数据。多径流，然后开始使用这两个接口，从同一台服务器上下载数据。图17示出每一个链路（每点一个5S平均）的吞吐量。再次，无线上方的虚线所示，3G所示下方的虚线，多径流总吞吐量可以从垂直灰色区域范围清楚地看到。10第11页在实验过程中，对象在建筑周围移动。开始的第9分钟3G路径有少量拥塞，所以MPTCP宁愿发送它的访问流量这条路线。但同时也希望得到尽可能多的吞吐量把作为高吞吐量部分，在这种情况下的无线网络。该公平算法可以防止它从发送这么多流量到3G路径上，所以没超出竞争其他可能会使用3G单一路径，所以剩下的无线网络上发送。在9分钟的对象走楼下去拿一个咖啡机。在楼梯间有没有WIFI覆盖，但3G覆盖更好，所以MPTCP适应和占据优势。当主体离开楼梯间，一个新的无线基站提供，和多迅速采取它的优势。这种单跟踪显示多TCP的鲁棒性优势，这也表明，它做了很好的工作，利用不同链接，同时不损害竞争这些路段的流量。6。协议的实施虽然本文主要侧重于拥塞控制动态的MPTCP，TCP协议发生变化需要实现多路径可以是相当微妙。特别是，我们必须要小心，在一些情况下以避免死锁定，特别是有关的缓冲管理和流量控制。事实上，我们发现在设计的许多方面几乎没有选择。那里也有许多棘手的问题关于MIDDLEBOXESWHICH进一步限制设计，这里不作说明。这些约束的一个更完整的论述可以在21中发现，我们的协议在当前MPTCP草案7被精确地描述。子流程的建立。我们MPTCP实施要求客户端和服务器都具有多路径延伸。第一子流SYN数据包中的一个TCP选项，如果两端支持它那么用于协商使用的多径，否则就退回到常规TCP行为状态。在此之后，可以启动额外的子流一个新的子流的SYN数据包的TCP选项允许接收方配合子流与现有的子流连接。我们依赖于多个接口或多个IP地址，以获得不同的路径，我们还没有研究其他路径应该开始的问题。丢失检测和流重组。RGEULARTCP使用一个单一的序列空间来丢失检测和应用数据流的重组。随着MPTCP，损失是一个子流问题，但应用程序的数据流跨越了所有的子流程。要使用单序列空间达到这两个目标，序列空间需要横跨子流程。要检测的损失，接收方，然后需要使用选择性确认和发件人需要保持一个记分板记录每个子流被送了哪个数据包。在不同的子流重传数据包变得很不明确，但真正的问题是中间设备察觉不到MPTCP的流。例如，PF19防火墙可以重新编写TCP序列号，以改善随机性的初始序列号。如果只有一个子流通过这样的防火墙，接收方不能可靠地重构数据流。为了避免这样的问题，我们分开这两种序列号。序列号和每个子流TCP报头中的累积的ACK，从而使丢失检测更有效和快速重传。然后允许可靠的流重组，一个额外的数据序列号应加一个说明放在应用程序数据流中的有效载荷。流量控制，TCP的流量控制是通过接收窗口字段和TCP包头确认域结合来完成的的。接收窗口显示的字节数超出确认的序列号，接收器可以缓冲。发件人是不允许发送超过这笔额外的数据。多路径TCP还需要实现流量控制，现在虽然数据包到达的多个子流程。二选择似乎是可行的每个子流在接收端保持独立的缓冲池，和他们的入住信号相对于在子流序列空间使用接收窗口字段。接收器保持在一个缓冲池，其占用的数据信号相对数据序列空间使用接收窗口领域。不幸的是，前者遭受潜在死锁。假设子流由于中断而延迟，但子流2的接收缓冲区填满。从子流2收到的报文不能传递给应用程序因为从子流1数据包人仍丢失，但是子流2的接收窗口没有空间的重新发送子流程1丢失的数据包。为了避免这种情况，我们使用一个单一的共享缓存，所有的子流接收报告接收窗口在数据序列空间持续接收到的数据相对于窗口。则需要明确累计数据是否应答，或者可以从子流ACKS的推断，通过跟踪数据对应的子流序列数字是什么请考虑以下情形一个接收器对两个数据包有足够缓冲空间。根据接收窗口，发送方发送两个数据包数据段1在子流1上发送，子流序列数是10第12页数据段在子流2上发送子流序列号20。接收方只用子流序列号确认包接收方将会推断哪一个数据被确认。最初，推断累积的ACK是0。（一）接收机的10个ACK，数据1入队，但接收应用程序尚未读取到数据，因此，相对于1，对1数据包接收窗口关闭了。二。接收方应答ACK20，数据2入队（等待）。由于应用程序仍然无法读取，相对于2，接收窗口现在是零。III。不幸的是，ACK被重新排列，仅仅是因为路径2上的往返时间短于路径1的，常见的事件。发件人收到ACK20，推断，2已收到但1还没有。因此，累积ACK数据仍然为0。四。当ACK10到达时，接收器推断出已收到1和2，所以数据的累积现在是2。接收窗口是指1数据包，相对于推断累积数据2的ACK。因此，发送者可以发送数据包3。不幸的是，接收机不能缓冲3，必须删除它。在一般情况下，问题是，尽管有可能从子流的ACKS来推断数据的累积ACK，这是不可能可靠地推断出接收窗口的边缘值。其结果是要么错过发送机会或丢弃数据包。这不是一个偶然情况，它会发生无论往返时间（RTT）的不同使在他们被发送过程以不同的顺序到达的ACK。为了避免这个问题（和其他一些相关的中间件），我们在TCP报头添加一个明确的数据确认域在子流的确认字段的域中。编码数据的序列号和数据确认应该如何在TCP报文中进行编码呢二机制似乎是可行的把它们放进在TCP进行运算或将它们嵌在有效载荷使用SSLLIKE分块机制。对于数据的序列号选择一方或另一方，但没有令人信服的理由。但是，数据确认的情况是更复杂。为了明确起见，让我们假设，有效负载编码采用分块TLV结构，数据ACK是包含在它自己的组块，交错数据块在同一目的地流动。由于数据的ACK是现在的数据流的一部分，他们服从拥塞控制和流量控制。这可能会导致潜在的死锁情况。考虑这样一个场景，其中A的接收缓冲区已满因为应用程序无法读取数据，但A的应用程序希望将数据发送到B的空的接收缓冲区。这可能发生，例如当B要求为A传输，而A需要发送响应到一个较早的请求给B，在阅读下一个请求之前。A发送的数据，B存储在本地，要发送数据ACK，但不能这样做A的接收窗口停止流量管制。由于从B没有数据的ACK收到，A不能释放它的发送缓冲区，所以这充满，且拦截A的发送应用程序答连接现在陷入死锁。A的应用程序将只读，当它完成向B发送数据，但它不能这样做，因为他的发送缓冲区已满。发送缓冲区只有空当A从B接收到一个数据ACK，但B不能发送数据ACK，直到A的应用程序读取。这是一个经典僵局周期。在一般情况下，流量控制的应答似乎是危险的。我们使用TCP选项以避免这个问题和类似问题来实现传送数据的ACK。鉴于这样的选择，在TCP选项，我们也编码数据的序列号。7。相关工作已经很好个想法，构建多路径传输协议，13,27，18，12,14,6，23，7。这项工作大部分集中在协议机制需要实现多径传输，与关键目标是对长期路径故障和路径上的短