[要約] RFC 6356は、複数のパスを使用するトランスポートプロトコルにおける結合された輻輳制御に関するものであり、その目的は、複数のパスを効果的に利用してネットワークの輻輳を制御することです。
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.
多くの場合、エンドポイントは複数のパスで接続されますが、通常、通信は接続ごとに単一のパスに制限されます。ネットワーク内のリソースの使用は、これらの複数のパスを同時に使用することができれば、より効率的になります。MultiPath 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などのマルチパストランスポートプロトコルには、新しい混雑制御アルゴリズムが必要です。顕著な問題の1つは、各パスで標準のTCPなどの既存のアルゴリズムを実行すると、マルチパスフローが、そのサブフローの1つ以上が通過するボトルネックリンクでの公正なシェアよりも多くを与えることです。さらに、利用可能な複数のパスを持つソースは、パスの最小の混雑を使用してより多くのトラフィックを転送し、リンクの束がより大きな容量と共有リンクのように効果的に動作する「リソースプーリング」と呼ばれるプロパティを達成することが望ましいです。これにより、ネットワークの全体的な効率が向上し、失敗に対する堅牢性も向上します。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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.
MultiPath TCP（MPTCP、[MPTCP-MultiAddressed]）は、通常のTCP [RFC0793]の拡張セットであり、1つの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.
MultiPath 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:
Bottleneckの公平性は、マルチパス混雑制御を満たす必要がある要件の1つにすぎません。次の3つの目標は、実用的なマルチパス輻輳制御アルゴリズムの望ましい特性を捉えています。
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（害を及ぼさない）マルチパスフローは、これらのパスの1つだけを使用して単一のフローであった場合よりも、異なるパスで共有されるリソースのいずれかからより多くの容量を占めるべきではありません。これにより、他のフローを不当に害しないことが保証されます。
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（バランス渋滞）マルチパスフローは、最初の2つの目標を達成することを条件として、最も混雑したパスからできるだけ多くのトラフィックを移動する必要があります。
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）を推定し、目標率を計算します。次に、全体的な攻撃性（パラメーターアルファ）を調整して、目的のレートを達成します。
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がパスのいずれかに到達することよりも厳密に高くなります。特に、2つのアイドルパスを使用する場合、マルチパススループットは2つのパスのスループットの合計になります。
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やキュービックなど）の新しい混雑コントロールアルゴリズムの帯域幅スケーリング特性を実現するために、マルチパス輸送のために他の輻輳コントローラーが実装されることが予見可能です。
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] .
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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
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の増加は同じシナリオ（2番目の引数）で得られます。このようにして、マルチパスサブフローは、同じ状況で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.
「アルファ」は、マルチパスフローの攻撃性を説明するアルゴリズムのパラメーターです。目標1（スループットの改善）を満たすために、アルファの値が選択され、マルチパスフローの集約スループットが最良のパスで実行された場合に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*MSSだけ増加させます。この増加は、瞬時のウィンドウサイズに応じて個々のフローに分散されます。サブフロー私は、RTTごとにAlpha*CWND_I/CWND_TOTALセグメントによって増加します。
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_TOTALが大きい場合、増加は0になる可能性があることに注意してください。この場合、増加は次のセクションで実際にこの式を実装する方法について説明する必要があります。
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変数は、新たに認められたバイト数を記録します。そうでない場合は、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 Limitedの接続に対応するには、計算では、flight_size_iとcwnd_i、およびflight_size_iとssthresh_iの間の最小値を必要に応じて考慮する必要があります。
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.
マルチパスフローの合計スループットは、アルファの値と損失率、最大セグメントサイズ、およびパスの往復時間に依存します。合計スループットは、単一のTCPが最良のパスに到達するスループットよりも悪くないため、選択することは不可能であるため、あらゆる機会に望ましいスループットを達成するアルファの単一の値を選択することは不可能です。したがって、アルファは、パスの観測された特性に基づいて計算する必要があります。
The formula to compute alpha is:
アルファを計算する式は次のとおりです。
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の速度とアルファを解くことにより導出されます。
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）は、アルファが浮動小数点値であることを意味します。これには、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を整数とします。アルファを計算するときは、cwnd_totalの代わりにalpha_scale * cwnd_totalを使用し、整数算術ですべての操作を実行します。
Then, scale down the increase per ACK by alpha_scale. The resulting algorithm is a simple change from Equation (1):
次に、Alpha_scaleによる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
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を計算するために必要な精度を示します。アルファの式の分子または分母を計算する際のエラーは非常に小さいことを観察します。バイト中のCWNDは通常、RTT（MSで測定）よりもはるかに大きいためです。
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_scaleは、乗算と分割の代わりに高速なシフト操作を使用できるようにするために、2つの小さなパワーであることを提案します。私たちの実験は、Alpha_scale = 512を使用することで、幅広いシナリオでうまく機能することが示されています。Alpha_scaleの増加は精度を増加させますが、Alphaを計算するとオーバーフローのリスクも増加します。64ビット操作を使用すると、この問題が解決します。別のオプションは、アルファを計算するときにAlpha_scaleを動的に調整することです。このようにして、オーバーフローを避け、最大精度を取得します。
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_TOTALを計算することにより、アルゴリズムを実装することができます。ただし、これは特にサブフローの数が多い場合は費用がかかります。このオーバーヘッドを回避するために、実装は「cwnd_total」と呼ばれる新しい接続ごとの変数を維持することを選択できます。そうする場合、実装は個々のサブフローのウィンドウがいつでもCWND_TOTAL値を更新します
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.
更新しました。更新するには、通常のサブフローごとの混雑制御コードと比較して、もう1つの追加または減算操作のみが必要であるため、パフォーマンスへの影響は最小限に抑えられます。
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は接続ごとの変数であることを提案し、ドロップがあるときはいつでも、RTTごとに1回を計算します。より具体的には、cwnd_newを膨張した後、またはドロップ後にcwnd_newを渋滞ウィンドウの新しい値にします。CWND_I/MSS_Iの商がCWND_NEW_I/MSS_Iの商と異なる場合にのみ、アルファを更新します。
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が一定である場合、アルファがドロップ間で変化しないため、アルファをドロップごとに1回計算するだけで十分であることがわかります（ここでの洞察は、両方のウィンドウが増加する限りCWND_I/CWND_J =一定であることです）。実験結果は、往復時間が一定でない場合でも、瞬時の往復時間（つまり、TCPの平滑化されたRTT推定器）の代わりに、鋸歯あたりの平均ラウンドトリップ時間を使用して、アルファを計算するのに適切な精度を与えることを示しています。したがって、rtt_iがRTT_AVG_Iに置き換える式（2）の変更バージョンを使用して、ドロップごとに1回だけアルファを計算することができます。
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.
平均ラウンドトリップ時間を使用している場合、RTT_AVG_Iは、ウィンドウがもう1つのパケットに対応できる場合、つまりCWND / MSS <（CWNDの増加） / MSSに対応できるときにRTT_Iをサンプリングすることにより計算されます。サンプルは、Sawtoothごとに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およびアルファを考慮すると、標準の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を受信したときに増加を計算するために、MultiPath混雑制御の実装は標準のTCPコードの単純な拡張です。標準では、TCP CWND_CNTは、最後のCWND増分以降にACKENTの数を追跡する追加の状態変数です。CWNDは、CWND_CNT> 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_IはCWND_CNT_I> MAX（Alpha_Scale * CWND_TOTAL / ALPHA、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.
パケットベースのスタックのアルファを計算する場合、分母の用語を計算する際のエラーが大きくなります（これは、CWNDがはるかに小さく、RTTが比較的大きい可能性があるためです）。Maxを分子で使用されるサブフローのインデックスとします。エラーを減らすために、RTT_MAX（一度計算されたら）を分子から分母に移動するのが最も簡単です。式（2）を変更して、以下の等価式を取得します。
(4)
（4）
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をバイトまたはパケットに保持するスタックで同じであることに注意してください。この式を使用すると、アルファを計算するためのアルゴリズムは、バイト指向のスタックのB/s、およびパケットベースのスタックのパケット/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
このような完全に結合したコントローラーにはいくつかの問題があります。まず、損失率が高いパスを不十分にプローブし、利用可能になったときに自由容量を検出できません。第二に、そのようなコントローラーは「フラップ」を示す傾向があります。パスの輻輳のレベルが同様のレベルの場合、混雑コントローラーはすべてのウィンドウを1つのランダムサブフローに割り当て、ゼロを割り当てる傾向があります
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.
1つのセキュリティ上の懸念は、私たちがトラフィックシフト攻撃と呼ぶものに関連しています：オンパス攻撃者はマルチパスサブフローに属するパケットをドロップできます。代替サブフローに関するより多くのデータ。
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.
トラフィックシフト攻撃のもう1つの効果は、新しいパスがすべてのトラフィックを監視できるのに対し、トラフィックのサブセットのみが表示される前には、すべてのトラフィックを監視できることです。プライバシーが必要な場合、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]で見つかったものに他のセキュリティ上の考慮事項を追加しません。MultiPath TCPプロトコル自体の詳細なセキュリティ分析は、[MPTCP-MultiAddressed]および[RFC6181]に含まれています。
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に感謝します。著者は、第7回フレームワークプログラムの下で欧州共同体によって部分的に資金提供されている研究プロジェクト（ICT-216372）であるTrilogy（http://www.trilogy-project.org）によってサポートされています。ここで表現されている見解は、著者のみです。欧州委員会は、この文書の情報から作られている可能性のある使用について責任を負いません。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 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 5681、2009年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。and T. Voice、「ジョイントルーティングとレート制御のためのエンドツーエンドアルゴリズムの安定性」、ACM Sigcomm CCR Vol。35 num。2、pp。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。、「適切なバイトカウント（ABC）によるTCP混雑制御」、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 6181、2011年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 Vol。38 num。5、pp。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
Costin Raiciu University Bucharest Splaiul Indedenderei 313 Bucharest RomaniaのPolitehnica
EMail: costin.raiciu@cs.pub.ro
Mark Handley University College London Gower Street London WC1E 6BT UK
マークハンドリー大学カレッジロンドンガワーストリートロンドンWC1E 6BT UK
EMail: m.handley@cs.ucl.ac.uk
Damon Wischik University College London Gower Street London WC1E 6BT UK
デイモン・ウィスチク大学カレッジロンドンガワーストリートロンドンWC1E 6BT UK
EMail: d.wischik@cs.ucl.ac.uk