Internet Engineering Task Force (IETF) C. Raiciu
Request for Comments: 6356 Univ. Politehnica of Bucharest
Category: Experimental M. Handly
ISSN: 2070-1721 D. Wischik
Univ. College London
October 2011
Internet Engineering Task Force (IETF) C. Raiciu
Request for Comments: 6356 Univ. Politehnica of Bucharest
Category: Experimental M. Handly
ISSN: 2070-1721 D. Wischik
Univ. College London
October 2011
Coupled Congestion Control for Multipath Transport Protocols
多径传输协议的耦合拥塞控制
Abstract
摘要
Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP.
端点通常由多条路径连接，但每个连接的通信通常仅限于一条路径。如果可以同时使用这些多条路径，则网络内的资源使用效率将更高。多路径TCP是一种在TCP中实现多路径传输的方案。
New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called "resource pooling" where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall efficiency of the network and also its robustness to failure.
多路径传输协议（如多路径TCP）需要新的拥塞控制算法，因为单路径算法在多路径环境中存在一系列问题。其中一个突出的问题是，在每条路径上独立运行现有算法（如标准TCP）会使多路径流在多个子流通过的瓶颈链路上超过其公平份额。此外，期望具有多条可用路径的源将使用路径中拥塞最少的路径来传输更多通信量，从而实现称为“资源池”的属性，其中链路束有效地表现为具有更大容量的共享链路。这将提高网络的整体效率及其对故障的鲁棒性。
This document presents a congestion control algorithm that couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links.
本文档介绍了一种拥塞控制算法，该算法通过链接不同子流上运行的拥塞控制算法的增加函数来耦合这些算法，并动态控制多径流的总体攻击性。结果是一个实用的算法，在瓶颈处对TCP公平，同时将流量从拥塞的链路移开。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6356.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6356.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Language ...........................................5
3. Coupled Congestion Control Algorithm ............................5
4. Implementation Considerations ...................................7
4.1. Computing "alpha" in Practice ..............................7
4.2. Implementation Considerations when CWND is
Expressed in Packets .......................................8
5. Discussion ......................................................9
6. Security Considerations ........................................10
7. Acknowledgements ...............................................11
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................11
1. Introduction ....................................................3
2. Requirements Language ...........................................5
3. Coupled Congestion Control Algorithm ............................5
4. Implementation Considerations ...................................7
4.1. Computing "alpha" in Practice ..............................7
4.2. Implementation Considerations when CWND is
Expressed in Packets .......................................8
5. Discussion ......................................................9
6. Security Considerations ........................................10
7. Acknowledgements ...............................................11
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................11
Multipath TCP (MPTCP, [MPTCP-MULTIADDRESSED]) is a set of extensions to regular TCP [RFC0793] that allows one TCP connection to be spread across multiple paths. MPTCP distributes load through the creation of separate "subflows" across potentially disjoint paths.
多路径TCP（MPTCP，[MPTCP-MULTIADDRESSED]）是常规TCP[RFC0793]的一组扩展，允许一个TCP连接跨多条路径分布。MPTCP通过在可能不相交的路径上创建单独的“子流”来分配负载。
How should congestion control be performed for multipath TCP? First, each subflow must have its own congestion control state (i.e., cwnd) so that capacity on that path is matched by offered load. The simplest way to achieve this goal is to simply run standard TCP congestion control on each subflow. However, this solution is unsatisfactory as it gives the multipath flow an unfair share when the paths taken by its different subflows share a common bottleneck.
如何对多路径TCP执行拥塞控制？首先，每个子流必须有自己的拥塞控制状态（即cwnd），以便该路径上的容量与提供的负载相匹配。实现这一目标的最简单方法是在每个子流上运行标准TCP拥塞控制。然而，这种解决方案并不令人满意，因为当多路径流的不同子流所采用的路径共享一个共同的瓶颈时，它会给多路径流带来不公平的共享。
Bottleneck fairness is just one requirement multipath congestion control should meet. The following three goals capture the desirable properties of a practical multipath congestion control algorithm:
瓶颈公平性只是多径拥塞控制应该满足的一个要求。以下三个目标体现了实用多路径拥塞控制算法的理想特性：
o Goal 1 (Improve Throughput) A multipath flow should perform at least as well as a single path flow would on the best of the paths available to it.
o 目标1（提高吞吐量）多路径流的性能应至少与单路径流在其可用的最佳路径上的性能相同。
o Goal 2 (Do no harm) A multipath flow should not take up more capacity from any of the resources shared by its different paths than if it were a single flow using only one of these paths. This guarantees it will not unduly harm other flows.
o 目标2（无害）与仅使用其中一条路径的单个流相比，多路径流不应从其不同路径共享的任何资源中占用更多容量。这保证了它不会不适当地损害其他流量。
o Goal 3 (Balance congestion) A multipath flow should move as much traffic as possible off its most congested paths, subject to meeting the first two goals.
o 目标3（平衡拥塞）多径流应在满足前两个目标的前提下，将尽可能多的流量移出其最拥挤的路径。
Goals 1 and 2 together ensure fairness at the bottleneck. Goal 3 captures the concept of resource pooling [WISCHIK]: if each multipath flow sends more data through its least congested path, the traffic in the network will move away from congested areas. This improves robustness and overall throughput, among other things. The way to achieve resource pooling is to effectively "couple" the congestion control loops for the different subflows.
目标1和目标2共同确保瓶颈处的公平性。目标3捕获了资源池的概念[WISCHIK]：如果每个多路径流通过其最不拥挤的路径发送更多数据，则网络中的流量将远离拥挤区域。除其他外，这提高了健壮性和总体吞吐量。实现资源池的方法是有效地“耦合”不同子流的拥塞控制循环。
We propose an algorithm that couples the additive increase function of the subflows, and uses unmodified TCP behavior in case of a drop. The algorithm relies on the traditional TCP mechanisms to detect drops, to retransmit data, etc.
我们提出了一种算法，该算法耦合子流的加法增加函数，并在丢弃的情况下使用未修改的TCP行为。该算法依靠传统的TCP机制来检测丢包、重传数据等。
Detecting shared bottlenecks reliably is quite difficult, but is just one part of a bigger question. This bigger question is how much bandwidth a multipath user should use in total, even if there is no shared bottleneck.
可靠地检测共享瓶颈相当困难，但这只是一个更大问题的一部分。这个更大的问题是，即使没有共享瓶颈，多路径用户总共应该使用多少带宽。
The congestion controller aims to set the multipath flow's aggregate bandwidth to be the same as that of a regular TCP flow would get on the best path available to the multipath flow. To estimate the bandwidth of a regular TCP flow, the multipath flow estimates loss rates and round-trip times (RTTs) and computes the target rate. Then, it adjusts the overall aggressiveness (parameter alpha) to achieve the desired rate.
拥塞控制器旨在将多路径流的聚合带宽设置为与常规TCP流在多路径流可用的最佳路径上的聚合带宽相同。为了估计常规TCP流的带宽，多径流估计丢失率和往返时间（RTT），并计算目标速率。然后，它调整总体攻击性（参数alpha）以达到所需的速率。
While the mechanism above applies always, its effect depends on whether the multipath TCP flow influences or does not influence the link loss rates (low versus high statistical multiplexing). If MPTCP does not influence link loss rates, MPTCP will get the same throughput as TCP on the best path. In cases with low statistical multiplexing, where the multipath flow influences the loss rates on the path, the multipath throughput will be strictly higher than that a single TCP would get on any of the paths. In particular, if using two idle paths, multipath throughput will be sum of the two paths' throughput.
尽管上述机制始终适用，但其效果取决于多路径TCP流是否影响链路丢失率（低统计复用率与高统计复用率）。如果MPTCP不影响链路丢失率，MPTCP将在最佳路径上获得与TCP相同的吞吐量。在统计复用率较低的情况下，如果多径流影响路径上的丢失率，则多径吞吐量将严格高于单个TCP在任何路径上的吞吐量。特别是，若使用两条空闲路径，则多路径吞吐量将是两条路径吞吐量的总和。
This algorithm ensures bottleneck fairness and fairness in the broader, network sense. We acknowledge that current TCP fairness criteria are far from ideal, but a multipath TCP needs to be deployable in the current Internet. If needed, new fairness criteria can be implemented by the same algorithm we propose by appropriately scaling the overall aggressiveness.
该算法保证了瓶颈公平性和更广泛的网络公平性。我们承认，目前的TCP公平性标准还远远不够理想，但是多径TCP需要能够在当前的互联网上部署。如果需要，新的公平性标准可以通过我们提出的相同算法来实现，即适当地调整总体攻击性。
It is intended that the algorithm presented here can be applied to other multipath transport protocols, such as alternative multipath extensions to TCP, or indeed any other congestion-aware transport protocols. However, for the purposes of example, this document will, where appropriate, refer to the MPTCP.
本文提出的算法可以应用于其他多路径传输协议，例如TCP的替代多路径扩展，或者任何其他拥塞感知传输协议。然而，出于示例目的，本文件将在适当情况下参考MPTCP。
The design decisions and evaluation of the congestion control algorithm are published in [NSDI].
拥塞控制算法的设计决策和评估发表在[NSDI]中。
The algorithm presented here only extends standard TCP congestion control for multipath operation. It is foreseeable that other congestion controllers will be implemented for multipath transport to achieve the bandwidth-scaling properties of the newer congestion control algorithms for regular TCP (such as Compound TCP and Cubic).
本文提出的算法仅扩展了多径操作的标准TCP拥塞控制。可以预见，其他拥塞控制器将用于多路径传输，以实现常规TCP（如复合TCP和Cubic）的较新拥塞控制算法的带宽扩展特性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] .
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The algorithm we present only applies to the increase phase of the congestion avoidance state specifying how the window inflates upon receiving an ACK. The slow start, fast retransmit, and fast recovery algorithms, as well as the multiplicative decrease of the congestion avoidance state are the same as in standard TCP [RFC5681].
我们提出的算法只适用于拥塞避免状态的增加阶段，指定窗口在接收到ACK时如何膨胀。慢启动、快速重传和快速恢复算法以及拥塞避免状态的乘法减少与标准TCP中的相同[RFC5681]。
Let cwnd_i be the congestion window on the subflow i. Let cwnd_total be the sum of the congestion windows of all subflows in the connection. Let p_i, rtt_i, and MSS_i be the loss rate, round-trip time (i.e., smoothed round-trip time estimate used by TCP), and maximum segment size on subflow i.
设cwnd_i为子流i上的拥塞窗口。设cwnd_total为连接中所有子流的拥塞窗口之和。设p_i、rtt_i和MSS_i为丢失率、往返时间（即TCP使用的平滑往返时间估计）和子流i上的最大段大小。
We assume throughout this document that the congestion window is maintained in bytes, unless otherwise specified. We briefly describe the algorithm for packet-based implementations of cwnd in section Section 4.2.
在本文档中，我们假设拥塞窗口以字节为单位进行维护，除非另有规定。在第4.2节中，我们简要描述了基于数据包的cwnd实现算法。
Our proposed "Linked Increases" algorithm MUST:
我们提出的“关联增长”算法必须：
o For each ACK received on subflow i, increase cwnd_i by
o 对于在子流i上接收到的每个ACK，将cwnd_i增加
alpha * bytes_acked * MSS_i bytes_acked * MSS_i
min ( --------------------------- , ------------------- ) (1)
cwnd_total cwnd_i
alpha * bytes_acked * MSS_i bytes_acked * MSS_i
min ( --------------------------- , ------------------- ) (1)
cwnd_total cwnd_i
The increase formula (1) takes the minimum between the computed increase for the multipath subflow (first argument to min), and the increase TCP would get in the same scenario (the second argument). In this way, we ensure that any multipath subflow cannot be more aggressive than a TCP flow in the same circumstances, hence achieving Goal 2 (do no harm).
增加公式（1）取多路径子流的计算增加值（第一个参数为min）和TCP在相同情况下的增加值（第二个参数）之间的最小值。通过这种方式，我们确保在相同的情况下，任何多路径子流都不会比TCP流更具攻击性，从而实现目标2（无害）。
"alpha" is a parameter of the algorithm that describes the aggressiveness of the multipath flow. To meet Goal 1 (improve throughput), the value of alpha is chosen such that the aggregate throughput of the multipath flow is equal to the throughput a TCP flow would get if it ran on the best path.
“alpha”是描述多径流攻击性的算法参数。为了满足目标1（提高吞吐量），选择alpha的值，以便多径流的聚合吞吐量等于TCP流在最佳路径上运行时将获得的吞吐量。
To get an idea of what the algorithm is trying to do, let's take the case where all the subflows have the same round-trip time and Maximum Segment Size (MSS). In this case, the algorithm will grow the total window by approximately alpha*MSS per RTT. This increase is distributed to the individual flows according to their instantaneous window size. Subflow i will increase by alpha*cwnd_i/cwnd_total segments per RTT.
为了了解算法试图做什么，让我们以所有子流具有相同往返时间和最大段大小（MSS）的情况为例。在这种情况下，算法将使总窗口每RTT增加大约alpha*Ms。根据瞬时窗口大小，将增加的流量分配给各个流量。每个RTT的子流i将增加alpha*cwnd_i/cwnd_总段数。
Note that, as in standard TCP, when cwnd_total is large the increase may be 0. In this case, the increase MUST be set to 1. We discuss how to implement this formula in practice in the next section.
请注意，与标准TCP一样，当cwnd_总数较大时，增加值可能为0。在这种情况下，增加值必须设置为1。我们将在下一节讨论如何在实践中实现此公式。
We assume implementations use an approach similar to appropriate byte counting (ABC, [RFC3465]), where the bytes_acked variable records the number of bytes newly acknowledged. If this is not the case, bytes_acked SHOULD be set to MSS_i.
我们假设实现使用类似于适当字节计数（ABC，[RFC3465]）的方法，其中bytes_acked变量记录新确认的字节数。如果不是这种情况，则应将已确认的字节设置为MSS_i。
To compute cwnd_total, it is an easy mistake to sum up cwnd_i across all subflows: when a flow is in fast retransmit, its cwnd is typically inflated and no longer represents the real congestion window. The correct behavior is to use the ssthresh (slow start threshold) value for flows in fast retransmit when computing cwnd_total. To cater to connections that are app limited, the computation should consider the minimum between flight_size_i and cwnd_i, and flight_size_i and ssthresh_i, where appropriate.
要计算cwnd_total，将所有子流中的cwnd_i相加很容易出错：当流处于快速重传时，其cwnd通常会膨胀，不再代表真正的拥塞窗口。正确的行为是在计算cwnd_total时，对快速重传中的流使用ssthresh（慢启动阈值）值。为了迎合APP有限的连接，计算应考虑FelthySsiZi I和CWNDWI I之间的最小值，以及FLASTYSIZEZI I和SSVeldHythi，在适当的情况下。
The total throughput of a multipath flow depends on the value of alpha and the loss rates, maximum segment sizes, and round-trip times of its paths. Since we require that the total throughput is no worse than the throughput a single TCP would get on the best path, it is impossible to choose, a priori, a single value of alpha that achieves the desired throughput in every occasion. Hence, alpha must be computed based on the observed properties of the paths.
多径流的总吞吐量取决于alpha值及其路径的丢失率、最大段大小和往返时间。由于我们要求总吞吐量不低于单个TCP在最佳路径上获得的吞吐量，因此不可能事先选择一个alpha值来在每种情况下实现所需的吞吐量。因此，必须根据观察到的路径特性计算alpha。
The formula to compute alpha is:
计算alpha的公式为：
MAX (cwnd_i/rtt_i^2)
alpha = cwnd_total * ------------------------- (2)
(SUM (cwnd_i/rtt_i))^2
MAX (cwnd_i/rtt_i^2)
alpha = cwnd_total * ------------------------- (2)
(SUM (cwnd_i/rtt_i))^2
Note:
注:
MAX (x_i) means the maximum value for any possible value of i.
MAX（x_i）指i的任何可能值的最大值。
SUM (x_i) means the summation for all possible values of i.
SUM（x_i）是指i的所有可能值的总和。
The formula (2) is derived by equalizing the rate of the multipath flow with the rate of a TCP running on the best path, and solving for alpha.
公式（2）是通过将多径流的速率与TCP在最佳路径上运行的速率相等，并求解alpha得到的。
Equation (2) implies that alpha is a floating point value. This would require performing costly floating point operations whenever an ACK is received. Further, in many kernels, floating point operations are disabled. There is an easy way to approximate the above calculations using integer arithmetic.
等式（2）表示alpha是一个浮点值。这将需要在收到ACK时执行代价高昂的浮点操作。此外，在许多内核中，浮点操作被禁用。有一种简单的方法可以使用整数算术近似上述计算。
Let alpha_scale be an integer. When computing alpha, use alpha_scale * cwnd_total instead of cwnd_total and do all the operations in integer arithmetic.
让alpha_scale为整数。计算alpha时，请使用alpha_scale*cwnd_total而不是cwnd_total，并使用整数算术进行所有运算。
Then, scale down the increase per ACK by alpha_scale. The resulting algorithm is a simple change from Equation (1):
然后，按alpha_比例缩小每个ACK的增量。由此产生的算法是方程式（1）的简单变化：
o For each ACK received on subflow i, increase cwnd_i by:
o 对于在子流i上接收到的每个ACK，将cwnd_i增加：
alpha * bytes_acked * MSS_i bytes_acked * MSS_i
min ( --------------------------- , ------------------- ) (3)
alpha_scale * cwnd_total cwnd_i
alpha * bytes_acked * MSS_i bytes_acked * MSS_i
min ( --------------------------- , ------------------- ) (3)
alpha_scale * cwnd_total cwnd_i
The alpha_scale parameter denotes the precision we want for computing alpha. Observe that the errors in computing the numerator or the denominator in the formula for alpha are quite small, as the cwnd in bytes is typically much larger than the RTT (measured in ms).
alpha_scale参数表示计算alpha所需的精度。注意，计算alpha公式中的分子或分母时的误差非常小，因为以字节为单位的cwnd通常比RTT（以毫秒为单位）大得多。
With these changes, all the operations can be done using integer arithmetic. We propose alpha_scale be a small power of two, to allow using faster shift operations instead of multiplication and division. Our experiments show that using alpha_scale=512 works well in a wide range of scenarios. Increasing alpha_scale increases precision, but also increases the risk of overflow when computing alpha. Using 64- bit operations would solve this issue. Another option is to dynamically adjust alpha_scale when computing alpha; in this way, we avoid overflow and obtain maximum precision.
通过这些更改，所有操作都可以使用整数算术完成。我们建议alpha_标度为2的小幂，以允许使用更快的移位运算，而不是乘法和除法。我们的实验表明，使用alpha_scale=512在广泛的场景中效果良好。增加alpha_刻度会提高精度，但也会增加计算alpha时溢出的风险。使用64位操作可以解决这个问题。另一个选择是在计算alpha时动态调整alpha_比例；这样，我们可以避免溢出并获得最大精度。
It is possible to implement the algorithm by calculating cwnd_total on each ack; however, this would be costly especially when the number of subflows is large. To avoid this overhead, the implementation MAY choose to maintain a new per-connection state variable called "cwnd_total". If it does so, the implementation will update the cwnd_total value whenever the individual subflow's windows are
可以通过计算每个ack上的cwnd_总数来实现该算法；然而，这将是昂贵的，尤其是当子流的数量很大时。为了避免这种开销，实现可以选择维护一个新的每个连接状态变量“cwnd_total”。如果这样做，则无论何时打开单个子流的窗口，实现都将更新cwnd_总值
updated. Updating only requires one more addition or subtraction operation compared to the regular, per-subflow congestion control code, so its performance impact should be minimal.
更新。与常规的逐子流拥塞控制代码相比，更新只需要多做一次加法或减法操作，因此其性能影响应该最小。
Computing alpha per ACK is also costly. We propose alpha be a per-connection variable, computed whenever there is a drop and once per RTT otherwise. More specifically, let cwnd_new be the new value of the congestion window after it is inflated or after a drop. Update alpha only if the quotient of cwnd_i/MSS_i differs from the quotient of cwnd_new_i/MSS_i.
计算每个ACK的alpha值也很昂贵。我们建议alpha是每个连接的变量，在出现下降时计算，否则每个RTT计算一次。更具体地说，让cwnd_new成为拥塞窗口充气或下降后的新值。仅当cwnd_i/MSS_i的商与cwnd_new_i/MSS_i的商不同时，才更新alpha。
In certain cases with small RTTs, computing alpha can still be expensive. We observe that if RTTs were constant, it is sufficient to compute alpha once per drop, as alpha does not change between drops (the insight here is that cwnd_i/cwnd_j = constant as long as both windows increase). Experimental results show that even if round-trip times are not constant, using average round-trip time per sawtooth instead of instantaneous round-trip time (i.e., TCP's smoothed RTT estimator) gives good precision for computing alpha. Hence, it is possible to compute alpha only once per drop using a modified version of equation (2) where rtt_i is replaced with rtt_avg_i.
在某些使用小型RTT的情况下，计算alpha的成本仍然很高。我们观察到，如果RTT为常数，则每滴计算一次alpha就足够了，因为alpha在两次滴之间没有变化（这里的观点是，只要两个窗口都增加，cwnd_i/cwnd_j=常数）。实验结果表明，即使往返时间不是常数，使用每个锯齿的平均往返时间而不是瞬时往返时间（即TCP的平滑RTT估计器）计算α的精度很高。因此，可以使用公式（2）的修改版本（其中rtt_i替换为rtt_avg_i）来计算每滴α仅一次。
If using average round-trip time, rtt_avg_i will be computed by sampling the rtt_i whenever the window can accommodate one more packet, i.e., when cwnd / MSS < (cwnd+increase)/MSS. The samples are averaged once per sawtooth into rtt_avg_i. This sampling ensures that there is no sampling bias for larger windows.
如果使用平均往返时间，则只要窗口可以容纳一个以上的数据包，即当cwnd/MSS<（cwnd+增加）/MSS时，将通过采样rtt_i来计算rtt_avg_i。将每个锯齿的样本平均一次，转换为rtt_avg_i。此采样确保对于较大的窗口没有采样偏差。
Given cwnd_total and alpha, the congestion control algorithm is run for each subflow independently, with similar complexity to the standard TCP increase code [RFC5681].
给定cwnd_total和alpha，拥塞控制算法针对每个子流独立运行，其复杂性与标准TCP增量码[RFC5681]相似。
When the congestion control algorithm maintains cwnd in packets rather than bytes, the algorithms above must change to take into account path MSS.
当拥塞控制算法以数据包而不是字节维护cwnd时，上述算法必须更改以考虑路径MSS。
To compute the increase when an ACK is received, the implementation for multipath congestion control is a simple extension of the standard TCP code. In standard, TCP cwnd_cnt is an additional state variable that tracks the number of segments acked since the last cwnd increment; cwnd is incremented only when cwnd_cnt > cwnd; then, cwnd_cnt is set to 0.
为了计算接收到ACK时的增量，多径拥塞控制的实现是标准TCP代码的简单扩展。在标准中，TCP cwnd_cnt是一个额外的状态变量，用于跟踪自上次cwnd增量以来确认的段数；仅当cwnd_cnt>cwnd时，cwnd才递增；然后，将cwnd_cnt设置为0。
In the multipath case, cwnd_cnt_i is maintained for each subflow as above, and cwnd_i is increased by 1 when cwnd_cnt_i > max(alpha_scale * cwnd_total / alpha, cwnd_i).
在多路径情况下，如上所述，为每个子流保持cwnd_cnt_i，并且当cwnd_cnt_i>max（alpha_标度*cwnd_总/alpha，cwnd_i）时，cwnd_i增加1。
When computing alpha for packet-based stacks, the errors in computing the terms in the denominator are larger (this is because cwnd is much smaller and rtt may be comparatively large). Let max be the index of the subflow used in the numerator. To reduce errors, it is easiest to move rtt_max (once calculated) from the numerator to the denominator, changing equation (2) to obtain the equivalent formula below.
当计算基于分组的堆栈的alpha时，计算分母中的项的错误较大（这是因为cwnd小得多，而rtt可能相对较大）。设max为分子中使用的子流的索引。为了减少误差，最简单的方法是将rtt_max（一旦计算）从分子移动到分母，改变方程式（2）以获得下面的等效公式。
(4)
(4)
cwnd_max
alpha = alpha_scale * cwnd_total * ------------------------------------
(SUM ((rtt_max * cwnd_i) / rtt_i))^2
cwnd_max
alpha = alpha_scale * cwnd_total * ------------------------------------
(SUM ((rtt_max * cwnd_i) / rtt_i))^2
Note that the calculation of alpha does not take into account path MSS and is the same for stacks that keep cwnd in bytes or packets. With this formula, the algorithm for computing alpha will match the rate of TCP on the best path in B/s for byte-oriented stacks, and in packets/s in packet-based stacks. In practice, MSS rarely changes between paths so this shouldn't be a problem.
注意，alpha的计算不考虑路径MSS，对于以字节或数据包为单位保留cwnd的堆栈也是如此。根据这个公式，计算alpha的算法将匹配面向字节堆栈的B/s最佳路径上的TCP速率，以及基于包堆栈的B/s最佳路径上的TCP速率。实际上，MSS很少在路径之间更改，所以这不应该是一个问题。
However, it is simple to derive formulae allowing packet-based stacks to achieve byte rate fairness (and vice versa) if needed. In particular, for packet-based stacks wanting byte-rate fairness, equation (4) above changes as follows: cwnd_max is replaced by cwnd_max * MSS_max * MSS_max, while cwnd_i is replaced with cwnd_i * MSS_i.
然而，如果需要的话，推导允许基于分组的堆栈实现字节速率公平性（反之亦然）的公式很简单。特别地，对于需要字节速率公平性的基于分组的栈，上面的等式（4）改变如下：cwnd_max被cwnd_max*MSS_max*MSS_max替换，而cwnd_i被cwnd_i*MSS_i替换。
The algorithm we've presented fully achieves Goals 1 and 2, but does not achieve full resource pooling (Goal 3). Resource pooling requires that no traffic should be transferred on links with higher loss rates. To achieve perfect resource pooling, one must couple both increase and decrease of congestion windows across subflows, as in [KELLY].
我们介绍的算法完全实现了目标1和2，但没有实现完全的资源池（目标3）。资源池要求在丢失率较高的链路上不传输流量。为了实现完美的资源池，必须在子流之间耦合拥塞窗口的增加和减少，如[KELLY]中所述。
There are a few problems with such a fully coupled controller. First, it will insufficiently probe paths with high loss rates and will fail to detect free capacity when it becomes available. Second, such controllers tend to exhibit "flappiness": when the paths have similar levels of congestion, the congestion controller will tend to allocate all the window to one random subflow and allocate zero
这种完全耦合的控制器存在一些问题。首先，它将无法充分探测高丢失率的路径，并且在可用时无法检测空闲容量。其次，这种控制器往往表现出“flappiness”：当路径具有相似的拥塞级别时，拥塞控制器将倾向于将所有窗口分配给一个随机子流，并分配零
window to the other subflows. The controller will perform random flips between these stable points. This doesn't seem desirable in general, and is particularly bad when the achieved rates depend on the RTT (as in the current Internet): in such a case, the resulting rate with fluctuate unpredictably depending on which state the controller is in, hence violating Goal 1.
窗口到其他子流。控制器将在这些稳定点之间执行随机翻转。一般来说，这似乎不可取，尤其是当实现的速率依赖于RTT时（如当前互联网中）：在这种情况下，产生的速率会根据控制器所处的状态不可预测地波动，因此违反了目标1。
By only coupling increases our proposal probes high loss paths, detecting free capacity quicker. Our proposal does not suffer from flappiness but also achieves less resource pooling. The algorithm will allocate window to the subflows such that p_i * cwnd_i = constant, for all i. Thus, when the loss rates of the subflows are equal, each subflow will get an equal window, removing flappiness. When the loss rates differ, progressively more windows will be allocated to the flow with the lower loss rate. In contrast, perfect resource pooling requires that all the window should be allocated on the path with the lowest loss rate. Further details can be found in [NSDI].
仅通过耦合增加我们的建议探测高损耗路径，更快地检测自由容量。我们的提案没有受到吹捧，但也实现了较少的资源共享。该算法将窗口分配给子流，使得对于所有i，p_i*cwnd_i=常量。因此，当子流的损失率相等时，每个子流将获得一个相等的窗口，从而消除剥落。当损失率不同时，将逐渐为损失率较低的流分配更多的窗口。相反，完美的资源池要求所有窗口都分配在丢失率最低的路径上。有关更多详细信息，请参见[NSDI]。
One security concern relates to what we call the traffic-shifting attack: on-path attackers can drop packets belonging to a multipath subflow, which, in turn, makes the path seem congested and will force the sender's congestion controller to avoid that path and push more data over alternate subflows.
一个安全问题与我们所称的流量转移攻击有关：路径上的攻击者可以丢弃属于多路径子流的数据包，这反过来会使路径看起来拥挤，并迫使发送方的拥塞控制器避开该路径，并在备用子流上推送更多数据。
The attacker's goal is to create congestion on the corresponding alternative paths. This behavior is entirely feasible but will only have minor effects: by design, the coupled congestion controller is less (or similarly) aggressive on any of its paths than a single TCP flow. Thus, the biggest effect this attack can have is to make a multipath subflow be as aggressive as a single TCP flow.
攻击者的目标是在相应的备选路径上造成拥塞。这种行为是完全可行的，但只会产生很小的影响：根据设计，耦合拥塞控制器在其任何路径上的攻击性（或类似地）小于单个TCP流。因此，此攻击可能产生的最大影响是使多路径子流与单个TCP流一样具有攻击性。
Another effect of the traffic-shifting attack is that the new path can monitor all the traffic, whereas before it could only see a subset of traffic. We believe that if privacy is needed, splitting traffic across multiple paths with MPTCP is not the right solution in the first place; end-to-end encryption should be used instead.
流量转移攻击的另一个影响是，新路径可以监视所有流量，而以前它只能看到流量的子集。我们认为，如果需要隐私，首先使用MPTCP在多条路径上分割流量不是正确的解决方案；应改用端到端加密。
Besides the traffic-shifting attack mentioned above, the coupled congestion control algorithm defined in this document adds no other security considerations to those found in [MPTCP-MULTIADDRESSED] and [RFC6181]. Detailed security analysis for the Multipath TCP protocol itself is included in [MPTCP-MULTIADDRESSED] and [RFC6181].
除了上面提到的流量转移攻击外，本文中定义的耦合拥塞控制算法在[MPTCP-MULTIADDRESSED]和[RFC6181]中没有添加其他安全注意事项。[MPTCP-MULTIADDRESSED]和[RFC6181]中包含了多路径TCP协议本身的详细安全性分析。
We thank Christoph Paasch for his suggestions for computing alpha in packet-based stacks. The authors are supported by Trilogy (http://www.trilogy-project.org), a research project (ICT-216372) partially funded by the European Community under its Seventh Framework Program. The views expressed here are those of the author(s) only. The European Commission is not liable for any use that may be made of the information in this document.
我们感谢Christoph Paasch提出的在基于包的堆栈中计算alpha的建议。作者得到了三部曲的支持(http://www.trilogy-project.org)，一个研究项目（ICT-216372），部分由欧洲共同体根据其第七个框架计划资助。此处表达的观点仅为作者的观点。欧盟委员会对可能使用本文件中的信息不承担任何责任。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 56812009年9月。
[KELLY] Kelly, F. and T. Voice, "Stability of end-to-end algorithms for joint routing and rate control", ACM SIGCOMM CCR vol. 35 num. 2, pp. 5-12, 2005, <http://portal.acm.org/citation.cfm?id=1064415>.
[KELLY]KELLY，F.和T.Voice，“用于联合路由和速率控制的端到端算法的稳定性”，ACM SIGCOMM CCR第35卷第2期，第5-12页，2005年<http://portal.acm.org/citation.cfm?id=1064415>.
[MPTCP-MULTIADDRESSED] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", Work in Progress, July 2011.
[MPTCP-MULTIADDRESSED]Ford，A.，Raiciu，C.，Handley，M.，和O.Bonaventure，“多地址多路径操作的TCP扩展”，正在进行的工作，2011年7月。
[NSDI] Wischik, D., Raiciu, C., Greenhalgh, A., and M. Handley, "Design, Implementation and Evaluation of Congestion Control for Multipath TCP", Usenix NSDI , March 2011, <htt p://www.cs.ucl.ac.uk/staff/c.raiciu/files/mptcp-nsdi.pdf>.
[NSDI]Wischik，D.，Raiciu，C.，Greenhalgh，A.，和M.Handley，“多路径TCP拥塞控制的设计、实施和评估”，Usenix NSDI，2011年3月，<htt p://www.cs.ucl.ac.uk/staff/C.Raiciu/files/mptcp NSDI.pdf>。
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, February 2003.
[RFC3465]Allman，M.，“具有适当字节计数的TCP拥塞控制（ABC）”，RFC 3465，2003年2月。
[RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, March 2011.
[RFC6181]Bagnulo，M.，“具有多个地址的多路径操作的TCP扩展的威胁分析”，RFC 61812011年3月。
[WISCHIK] Wischik, D., Handley, M., and M. Bagnulo Braun, "The Resource Pooling Principle", ACM SIGCOMM CCR vol. 38 num. 5, pp. 47-52, October 2008, <http://ccr.sigcomm.org/online/files/p47-handleyA4.pdf>.
[WISCHIK]WISCHIK，D.，Handley，M.和M.Bagnulo Braun，“资源池原则”，ACM SIGCOMM CCR第38卷第5期，第47-52页，2008年10月<http://ccr.sigcomm.org/online/files/p47-handleyA4.pdf>.
Authors' Addresses
作者地址
Costin Raiciu University Politehnica of Bucharest Splaiul Independentei 313 Bucharest Romania
罗马尼亚布加勒斯特独立学院布加勒斯特理工大学
EMail: costin.raiciu@cs.pub.ro
EMail: costin.raiciu@cs.pub.ro
Mark Handley University College London Gower Street London WC1E 6BT UK
马克·汉德利大学学院伦敦高尔街伦敦WC1E 6BT英国
EMail: m.handley@cs.ucl.ac.uk
EMail: m.handley@cs.ucl.ac.uk
Damon Wischik University College London Gower Street London WC1E 6BT UK
Damon Wischik大学学院伦敦高尔街伦敦WC1E 6BT英国
EMail: d.wischik@cs.ucl.ac.uk
EMail: d.wischik@cs.ucl.ac.uk