[要約] RFC 8041は、Multipath TCP（MPTCP）の使用事例と運用経験に関する情報を提供するものであり、MPTCPの目的は、複数のパスを同時に使用して通信の信頼性とパフォーマンスを向上させることです。
Internet Engineering Task Force (IETF) O. Bonaventure
Request for Comments: 8041 UCLouvain
Category: Informational C. Paasch
ISSN: 2070-1721 Apple, Inc.
G. Detal
Tessares
January 2017
Use Cases and Operational Experience with Multipath TCP
マルチパスTCPの使用例と運用経験
Abstract
概要
This document discusses both use cases and operational experience with Multipath TCP (MPTCP) in real networks. It lists several prominent use cases where Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases and suggests possible improvements.
このドキュメントでは、実際のネットワークでのマルチパスTCP（MPTCP）の使用例と運用経験の両方について説明します。マルチパスTCPが検討され、使用されているいくつかの顕著な使用例をリストします。また、これらのユースケースを実現するのに役立ついくつかのヒューリスティックと決定に対する洞察を提供し、可能な改善を提案します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション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/rfc8041.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8041で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Use Cases .......................................................4
2.1. Datacenters ................................................4
2.2. Cellular/WiFi Offload ......................................5
2.3. Multipath TCP Proxies ......................................8
3. Operational Experience ..........................................9
3.1. Middlebox Interference .....................................9
3.2. Congestion Control ........................................11
3.3. Subflow Management ........................................12
3.4. Implemented Subflow Managers ..............................13
3.5. Subflow Destination Port ..................................15
3.6. Closing Subflows ..........................................16
3.7. Packet Schedulers .........................................17
3.8. Segment Size Selection ....................................18
3.9. Interactions with the Domain Name System ..................19
3.10. Captive Portals ..........................................20
3.11. Stateless Webservers .....................................20
3.12. Load-Balanced Server Farms ...............................21
4. Security Considerations ........................................21
5. References .....................................................23
5.1. Normative References ......................................23
5.2. Informative References ....................................23
Acknowledgements ..................................................30
Authors' Addresses ................................................30
Multipath TCP was specified in [RFC6824] and five independent implementations have been developed. As of November 2016, Multipath TCP has been or is being implemented on the following platforms:
マルチパスTCPは[RFC6824]で指定されており、5つの独立した実装が開発されています。 2016年11月の時点で、マルチパスTCPは次のプラットフォームに実装されています。
o Linux kernel [MultipathTCP-Linux]
o Linuxカーネル[MultipathTCP-Linux]
o Apple iOS and macOS
o Apple iOSおよびmacOS
o Citrix load balancers
o Citrixロードバランサー
o FreeBSD [FreeBSD-MPTCP]
o FreeBSD [FreeBSD-MPTCP]
o Oracle Solaris
o Oracle Solaris
The first three implementations are known to interoperate. Three of these implementations are open source (Linux kernel, FreeBSD and Apple's iOS and macOS). Apple's implementation is widely deployed.
最初の3つの実装は相互運用することが知られています。これらの実装のうち3つはオープンソースです（Linuxカーネル、FreeBSD、AppleのiOSおよびmacOS）。 Appleの実装は広く展開されています。
Since the publication of [RFC6824] as an Experimental RFC, experience has been gathered by various network researchers and users about the operational issues that arise when Multipath TCP is used in today's Internet.
[RFC6824]が試験的RFCとして公開されて以来、今日のインターネットでマルチパスTCPが使用された場合に発生する運用上の問題について、さまざまなネットワーク研究者やユーザーによって経験が集まっています。
When the MPTCP working group was created, several use cases for Multipath TCP were identified [RFC6182]. Since then, other use cases have been proposed and some have been tested and even deployed. We describe these use cases in Section 2.
MPTCPワーキンググループが作成されたとき、マルチパスTCPのいくつかの使用例が特定されました[RFC6182]。それ以来、他のユースケースが提案され、いくつかはテストされ、さらには配備されました。これらの使用例については、セクション2で説明します。
Section 3 focuses on the operational experience with Multipath TCP. Most of this experience comes from the utilization of the Multipath TCP implementation in the Linux kernel [MultipathTCP-Linux]. This open-source implementation has been downloaded and implemented by thousands of users all over the world. Many of these users have provided direct or indirect feedback by writing documents (scientific articles or blog messages) or posting to the mptcp-dev mailing list (see https://listes-2.sipr.ucl.ac.be/sympa/arc/mptcp-dev). This Multipath TCP implementation is actively maintained and continuously improved. It is used on various types of hosts, ranging from smartphones or embedded routers to high-end servers.
セクション3では、マルチパスTCPの運用経験に焦点を当てます。この経験のほとんどは、Linuxカーネル[MultipathTCP-Linux]でのマルチパスTCP実装の利用から得られます。このオープンソースの実装は、世界中の何千人ものユーザーによってダウンロードおよび実装されています。これらのユーザーの多くは、ドキュメント（科学記事またはブログメッセージ）を作成するか、mptcp-devメーリングリスト（https://listes-2.sipr.ucl.ac.be/sympa/arcを参照）に投稿することにより、直接的または間接的なフィードバックを提供しています。 / mptcp-dev）。このマルチパスTCP実装は積極的に維持され、継続的に改善されています。スマートフォンや組み込みルーターからハイエンドサーバーまで、さまざまなタイプのホストで使用されます。
The Multipath TCP implementation in the Linux kernel is not, by far, the most widespread deployment of Multipath TCP. Since September 2013, Multipath TCP is also supported on smartphones and tablets beginning with iOS7 [IETFJ]. There are likely hundreds of millions of MPTCP-enabled devices. This Multipath TCP implementation is currently only used to support the Siri voice recognition/control application. Some lessons learned from this deployment are described in [IETFJ].
LinuxカーネルでのマルチパスTCPの実装は、マルチパスTCPの最も普及した配備ではありません。 2013年9月以降、マルチパスTCPはiOS7 [IETFJ]以降のスマートフォンおよびタブレットでもサポートされます。数億ものMPTCP対応デバイスが存在する可能性があります。このマルチパスTCP実装は、現在、Siri音声認識/制御アプリケーションをサポートするためにのみ使用されています。この導入から学んだいくつかの教訓は、[IETFJ]で説明されています。
Section 3 is organized as follows. Supporting the middleboxes was one of the difficult issues in designing the Multipath TCP protocol. We explain in Section 3.1 which types of middleboxes the Linux Kernel implementation of Multipath TCP supports and how it reacts upon encountering these. Section 3.2 summarizes the MPTCP-specific congestion controls that have been implemented. Sections 3.3 to 3.7 discuss heuristics and issues with respect to subflow management as well as the scheduling across the subflows. Section 3.8 explains some problems that occurred with subflows having different Maximum Segment Size (MSS) values. Section 3.9 presents issues with respect to content delivery networks and suggests a solution to this issue. Finally, Section 3.10 documents an issue with captive portals where MPTCP will behave suboptimally.
セクション3は次のように構成されています。ミドルボックスのサポートは、マルチパスTCPプロトコルの設計における困難な問題の1つでした。セクション3.1で、マルチパスTCPのLinuxカーネル実装がサポートするミドルボックスのタイプと、これらのミドルボックスが発生したときの対応について説明します。セクション3.2は、実装されたMPTCP固有の輻輳制御を要約しています。セクション3.3から3.7では、サブフロー管理およびサブフロー全体のスケジューリングに関するヒューリスティックと問題について説明します。セクション3.8では、最大セグメントサイズ（MSS）の値が異なるサブフローで発生したいくつかの問題について説明します。セクション3.9では、コンテンツ配信ネットワークに関する問題を提示し、この問題の解決策を提案します。最後に、セクション3.10は、MPTCPが最適に動作しないキャプティブポータルの問題を説明しています。
Multipath TCP has been tested in several use cases. There is already an abundant amount of scientific literature on Multipath TCP [MPTCPBIB]. Several of the papers published in the scientific literature have identified possible improvements that are worth being discussed here.
マルチパスTCPは、いくつかの使用例でテストされています。マルチパスTCP [MPTCPBIB]に関する科学文献はすでに豊富にあります。科学文献で発表されたいくつかの論文は、ここで議論する価値のある可能性のある改善を特定しています。
A first, although initially unexpected, documented use case for Multipath TCP has been in datacenters [HotNets][SIGCOMM11]. Today's datacenters are designed to provide several paths between single-homed servers. The multiplicity of these paths comes from the utilization of Equal-Cost Multipath (ECMP) and other load-balancing techniques inside the datacenter. Most of the deployed load-balancing techniques in datacenters rely on hashes computed over the five tuple. Thus, all packets from the same TCP connection follow the same path: so they are not reordered. The results in [HotNets] demonstrate by simulations that Multipath TCP can achieve a better utilization of the available network by using multiple subflows for each Multipath TCP session. Although [RFC6182] assumes that at least one of the communicating hosts has several IP addresses, [HotNets] demonstrates that Multipath TCP is beneficial when both hosts are single-homed. This idea is analyzed in more details in [SIGCOMM11], where the Multipath TCP implementation in the Linux kernel is modified to be able to use several subflows from the same IP address. Measurements in a public datacenter show the quantitative benefits of Multipath TCP [SIGCOMM11] in this environment.
最初に、最初は予想外でしたが、マルチパスTCPの文書化された使用例がデータセンター[HotNets] [SIGCOMM11]にありました。今日のデータセンターは、シングルホームサーバー間にいくつかのパスを提供するように設計されています。これらのパスの多様性は、等コストマルチパス（ECMP）とデータセンター内の他のロードバランシング技術の利用に由来します。データセンターに導入されている負荷分散手法のほとんどは、5つのタプルに対して計算されたハッシュに依存しています。したがって、同じTCP接続からのすべてのパケットは同じパスをたどります。したがって、パケットは並べ替えられません。 [HotNets]の結果は、マルチパスTCPが各マルチパスTCPセッションに複数のサブフローを使用することで、利用可能なネットワークの利用率を向上できることをシミュレーションで示しています。 [RFC6182]は、通信するホストの少なくとも1つに複数のIPアドレスがあると想定していますが、[HotNets]は、両方のホストがシングルホームである場合にマルチパスTCPが有益であることを示しています。このアイデアは、[SIGCOMM11]で詳細に分析されています。LinuxカーネルのマルチパスTCP実装は、同じIPアドレスから複数のサブフローを使用できるように変更されています。公共のデータセンターでの測定結果は、この環境におけるマルチパスTCP [SIGCOMM11]の定量的な利点を示しています。
Although ECMP is widely used inside datacenters, this is not the only environment where there are different paths between a pair of hosts. ECMP and other load-balancing techniques such as Link Aggregation Groups (LAGs) are widely used in today's networks; having multiple paths between a pair of single-homed hosts is becoming the norm instead of the exception. Although these multiple paths often have the same cost (from an IGP metrics viewpoint), they do not necessarily have the same performance. For example, [IMC13c] reports the results of a long measurement study showing that load-balanced Internet paths between that same pair of hosts can have huge delay differences.
ECMPはデータセンター内で広く使用されていますが、これは、ホストのペア間に異なるパスが存在する唯一の環境ではありません。 ECMPやリンク集約グループ（LAG）などの他の負荷分散技術は、今日のネットワークで広く使用されています。シングルホームホストのペア間に複数のパスを持つことは、例外ではなく標準になりつつあります。これらの複数のパスのコストは（IGPメトリックの観点から）同じであることがよくありますが、必ずしも同じパフォーマンスであるとは限りません。たとえば、[IMC13c]は、同じ測定結果のホストのペア間で負荷分散されたインターネットパスに大きな遅延差がある可能性があることを示す、長期にわたる測定調査の結果を報告しています。
A second use case that has been explored by several network researchers is the cellular/WiFi offload use case. Smartphones or other mobile devices equipped with two wireless interfaces are a very common use case for Multipath TCP. In September 2015, this is also the largest deployment of MPTCP-enabled devices [IETFJ]. It has been briefly discussed during IETF 88 [IETF88], but there is no published paper or report that analyses this deployment. For this reason, we only discuss published papers that have mainly used the Multipath TCP implementation in the Linux kernel for their experiments.
いくつかのネットワーク研究者によって調査された2番目の使用例は、セルラー/ WiFiオフロードの使用例です。 2つのワイヤレスインターフェイスを備えたスマートフォンやその他のモバイルデバイスは、マルチパスTCPの非常に一般的な使用例です。 2015年9月、これはMPTCP対応デバイスの最大の展開でもあります[IETFJ]。これはIETF 88 [IETF88]で簡単に議論されましたが、この展開を分析する公開された論文やレポートはありません。このため、Linuxカーネルで主にマルチパスTCP実装を使用して実験を行った公開論文のみを説明します。
The performance of Multipath TCP in wireless networks was briefly evaluated in [NSDI12]. One experiment analyzes the performance of Multipath TCP on a client with two wireless interfaces. This evaluation shows that when the receive window is large, Multipath TCP can efficiently use the two available links. However, if the window becomes smaller, then packets sent on a slow path can block the transmission of packets on a faster path. In some cases, the performance of Multipath TCP over two paths can become lower than the performance of regular TCP over the best performing path. Two heuristics, reinjection and penalization, are proposed in [NSDI12] to solve this identified performance problem. These two heuristics have since been used in the Multipath TCP implementation in the Linux kernel. [CONEXT13] explored the problem in more detail and revealed some other scenarios where Multipath TCP can have difficulties in efficiently pooling the available paths. Improvements to the Multipath TCP implementation in the Linux kernel are proposed in [CONEXT13] to cope with some of these problems.
ワイヤレスネットワークでのマルチパスTCPのパフォーマンスは、[NSDI12]で簡単に評価されました。 1つの実験では、2つのワイヤレスインターフェイスを備えたクライアントでのマルチパスTCPのパフォーマンスを分析しています。この評価は、受信ウィンドウが大きい場合、マルチパスTCPが2つの使用可能なリンクを効率的に使用できることを示しています。ただし、ウィンドウが小さくなると、低速パスで送信されたパケットが、高速パスでのパケットの送信をブロックする可能性があります。場合によっては、2つのパスを介したマルチパスTCPのパフォーマンスが、最もパフォーマンスの高いパスを介した通常のTCPのパフォーマンスよりも低くなることがあります。 [NSDI12]では、この識別されたパフォーマンスの問題を解決するために、2つのヒューリスティック、再注入とペナルティが提案されています。これら2つのヒューリスティックは、LinuxカーネルのマルチパスTCP実装で使用されています。 [CONEXT13]は問題をより詳細に調査し、マルチパスTCPが利用可能なパスを効率的にプールすることが困難である他のいくつかのシナリオを明らかにしました。 LinuxカーネルのマルチパスTCP実装の改善は、これらの問題のいくつかに対処するために[CONEXT13]で提案されています。
The first experimental analysis of Multipath TCP in a public wireless environment was presented in [Cellnet12]. These measurements explore the ability of Multipath TCP to use two wireless networks (real WiFi and 3G networks). Three modes of operation are compared. The first mode of operation is the simultaneous use of the two wireless networks. In this mode, Multipath TCP pools the available resources and uses both wireless interfaces. This mode provides fast handover from WiFi to cellular or the opposite when the user moves. Measurements presented in [CACM14] show that the handover from one wireless network to another is not an abrupt process. When a host moves, there are regions where the quality of one of the wireless networks is weaker than the other, but the host considers this wireless network to still be up. When a mobile host enters such regions, its ability to send packets over another wireless network is important to ensure a smooth handover. This is clearly illustrated from the packet trace discussed in [CACM14].
パブリックワイヤレス環境でのマルチパスTCPの最初の実験的分析は、[Cellnet12]で発表されました。これらの測定では、2つのワイヤレスネットワーク（実際のWiFiと3Gネットワーク）を使用するマルチパスTCPの機能を探ります。 3つの動作モードが比較されます。最初の動作モードは、2つのワイヤレスネットワークの同時使用です。このモードでは、マルチパスTCPは利用可能なリソースをプールし、両方のワイヤレスインターフェイスを使用します。このモードは、ユーザーが移動したときにWiFiからセルラーまたはその逆への高速ハンドオーバーを提供します。 [CACM14]で提示された測定は、ある無線ネットワークから別の無線ネットワークへのハンドオーバーが突然のプロセスではないことを示しています。ホストが移動すると、一方のワイヤレスネットワークの品質が他方よりも劣る地域がありますが、ホストはこのワイヤレスネットワークがまだ稼働していると見なします。モバイルホストがそのような領域に入るとき、別のワイヤレスネットワークを介してパケットを送信するその機能は、スムーズなハンドオーバーを保証するために重要です。これは、[CACM14]で説明されているパケットトレースから明確に示されています。
Many cellular networks use volume-based pricing; users often prefer to use unmetered WiFi networks when available instead of metered cellular networks. [Cellnet12] implements support for the MP_PRIO option to explore two other modes of operation.
多くの携帯電話ネットワークは、ボリュームベースの価格を使用しています。ユーザーは、利用可能な場合、従量制のセルラーネットワークではなく、従量制のWiFiネットワークを使用することを好みます。 [Cellnet12]は、MP_PRIOオプションのサポートを実装して、他の2つの動作モードを探索します。
In the backup mode, Multipath TCP opens a TCP subflow over each interface, but the cellular interface is configured in backup mode. This implies that data flows only over the WiFi interface when both interfaces are considered to be active. If the WiFi interface fails, then the traffic switches quickly to the cellular interface, ensuring a smooth handover from the user's viewpoint [Cellnet12]. The cost of this approach is that the WiFi and cellular interfaces are likely to remain active all the time since all subflows are established over the two interfaces.
バックアップモードでは、マルチパスTCPは各インターフェイス上でTCPサブフローを開きますが、セルラーインターフェイスはバックアップモードで構成されます。これは、両方のインターフェースがアクティブであると見なされている場合に、データがWiFiインターフェースを介してのみ流れることを意味します。 WiFiインターフェースに障害が発生した場合、トラフィックはセルラーインターフェースにすばやく切り替わり、ユーザーの観点からスムーズなハンドオーバーが保証されます[Cellnet12]。このアプローチのコストは、2つのインターフェース上ですべてのサブフローが確立されるため、WiFiとセルラーインターフェースが常にアクティブなままになる可能性が高いことです。
The single-path mode is slightly different. This mode benefits from the break-before-make capability of Multipath TCP. When an MPTCP session is established, a subflow is created over the WiFi interface. No packet is sent over the cellular interface as long as the WiFi interface remains up [Cellnet12]. This implies that the cellular interface can remain idle and battery capacity is preserved. When the WiFi interface fails, a new subflow is established over the cellular interface in order to preserve the established Multipath TCP sessions. Compared to the backup mode described earlier, measurements reported in [Cellnet12] indicate that this mode of operation is characterized by a throughput drop while the cellular interface is brought up and the subflows are reestablished.
シングルパスモードは少し異なります。このモードは、マルチパスTCPのbreak-before-make機能の恩恵を受けます。 MPTCPセッションが確立されると、WiFiインターフェース上にサブフローが作成されます。 WiFiインターフェースがアップしている限り、セルラーインターフェースを介してパケットは送信されません[Cellnet12]。これは、セルラーインターフェイスがアイドル状態を維持でき、バッテリー容量が保持されることを意味します。 WiFiインターフェースが失敗すると、確立されたマルチパスTCPセッションを維持するために、セルラーインターフェース上に新しいサブフローが確立されます。前述のバックアップモードと比較して、[Cellnet12]で報告された測定値は、この動作モードは、セルラーインターフェイスが起動してサブフローが再確立されている間のスループットの低下を特徴とすることを示しています。
From a protocol viewpoint, [Cellnet12] discusses the problem posed by the unreliability of the REMOVE_ADDR option and proposes a small protocol extension to allow hosts to reliably exchange this option. It would be useful to analyze packet traces to understand whether the unreliability of the REMOVE_ADDR option poses an operational problem in real deployments.
プロトコルの観点から、[Cellnet12]はREMOVE_ADDRオプションの信頼性の低さによって引き起こされる問題について説明し、ホストがこのオプションを確実に交換できるようにする小さなプロトコル拡張を提案します。パケットトレースを分析して、REMOVE_ADDRオプションの信頼性の低さが実際の展開で運用上の問題を引き起こすかどうかを理解することは有用です。
Another study of the performance of Multipath TCP in wireless networks was reported in [IMC13b]. This study uses laptops connected to various cellular ISPs and WiFi hotspots. It compares various file transfer scenarios. [IMC13b] observes that 4-path MPTCP outperforms 2-path MPTCP, especially for larger files. However, for three congestion-control algorithms (LIA, OLIA, and Reno -- see Section 3.2), there is no significant performance difference for file sizes smaller than 4 MB.
ワイヤレスネットワークにおけるマルチパスTCPのパフォーマンスに関する別の研究が[IMC13b]で報告されました。この調査では、さまざまなセルラーISPおよびWiFiホットスポットに接続されたラップトップを使用しています。さまざまなファイル転送シナリオを比較します。 [IMC13b]は、特に大きなファイルの場合、4パスMPTCPが2パスMPTCPよりも優れていることを観察しています。ただし、3つの輻輳制御アルゴリズム（LIA、OLIA、Reno-セクション3.2を参照）の場合、4 MB未満のファイルサイズではパフォーマンスに大きな違いはありません。
A different study of the performance of Multipath TCP with two wireless networks is presented in [INFOCOM14]. In this study the two networks had different qualities: a good network and a lossy network. When using two paths with different packet-loss ratios, the Multipath TCP congestion-control scheme moves traffic away from the lossy link that is considered to be congested. However, [INFOCOM14] documents an interesting scenario that is summarized hereafter.
2つのワイヤレスネットワークを備えたマルチパスTCPのパフォーマンスに関する別の研究が[INFOCOM14]に示されています。この調査では、2つのネットワークの質が異なっていました。優れたネットワークと損失の多いネットワークです。パケット損失率が異なる2つのパスを使用する場合、マルチパスTCP輻輳制御スキームは、輻輳していると見なされる非可逆リンクからトラフィックを移動させます。ただし、[INFOCOM14]には、以下に要約する興味深いシナリオが記載されています。
client ----------- path1 -------- server
| |
+--------------- path2 ------------+
Figure 1: Simple network topology
図1：単純なネットワークトポロジ
Initially, the two paths in Figure 1 have the same quality and Multipath TCP distributes the load over both of them. During the transfer, the path2 becomes lossy, e.g., because the client moves. Multipath TCP detects the packet losses and they are retransmitted over path1. This enables the data transfer to continue over this path. However, the subflow over path2 is still up and transmits one packet from time to time. Although the N packets have been acknowledged over the first subflow (at the MPTCP level), they have not been acknowledged at the TCP level over the second subflow. To preserve the continuity of the sequence numbers over the second subflow, TCP will continue to retransmit these segments until either they are acknowledged or the maximum number of retransmissions is reached. This behavior is clearly inefficient and may lead to blocking since the second subflow will consume window space to be able to retransmit these packets. [INFOCOM14] proposes a new Multipath TCP option to solve this problem. In practice, a new TCP option is probably not required. When the client detects that the data transmitted over the second subflow has been acknowledged over the first subflow, it could decide to terminate the second subflow by sending a RST segment. If the interface associated to this subflow is still up, a new subflow could be immediately reestablished. It would then be immediately usable to send new data and would not be forced to first retransmit the previously transmitted data. As of this writing, this dynamic management of the subflows is not yet implemented in the Multipath TCP implementation in the Linux kernel.
最初は、図1の2つのパスは同じ品質であり、マルチパスTCPは両方に負荷を分散します。転送中、たとえばクライアントが移動するため、path2は不可逆になります。マルチパスTCPはパケット損失を検出し、path1経由で再送信されます。これにより、データ転送をこのパスで続行できます。ただし、path2上のサブフローはまだアップしており、時々1つのパケットを送信します。 Nパケットは最初のサブフロー（MPTCPレベル）で確認されていますが、TCPレベルでは2番目のサブフローでは確認されていません。 2番目のサブフローでシーケンス番号の連続性を維持するために、TCPは、これらのセグメントが確認されるか、再送信の最大数に達するまで、これらのセグメントを再送信し続けます。この動作は明らかに非効率的であり、2番目のサブフローがウィンドウスペースを消費してこれらのパケットを再送信できるため、ブロッキングにつながる可能性があります。 [INFOCOM14]は、この問題を解決するための新しいマルチパスTCPオプションを提案しています。実際には、新しいTCPオプションはおそらく必要ありません。クライアントは、2番目のサブフローで送信されたデータが最初のサブフローで確認されたことを検出すると、RSTセグメントを送信して2番目のサブフローを終了することを決定できます。このサブフローに関連付けられているインターフェースがまだ稼働している場合は、新しいサブフローをすぐに再確立できます。その後、新しいデータを送信するためにすぐに使用でき、以前に送信されたデータを最初に再送信する必要はありません。これを書いている時点では、サブフローのこの動的管理は、LinuxカーネルのマルチパスTCP実装にはまだ実装されていません。
Some studies have started to analyze the performance of Multipath TCP on smartphones with real applications. In contrast with the bulk transfers that are used by many publications, many deployed applications do not exchange huge amounts of data and mainly use small connections. [COMMAG2016] proposes a software testing framework that allows to automate Android applications to study their interactions with Multipath TCP. [PAM2016] analyses a one-month packet trace of all the packets exchanged by a dozen of smartphones utilized by regular users. This analysis reveals that short connections are important on smartphones and that the main benefit of using Multipath TCP on smartphones is the ability to perform seamless handovers between different wireless networks. Long connections benefit from these handovers.
実際のアプリケーションを備えたスマートフォンでマルチパスTCPのパフォーマンスを分析する研究がいくつか始まっています。多くのパブリケーションで使用されるバルク転送とは対照的に、デプロイされたアプリケーションの多くは、大量のデータを交換せず、主に小さな接続を使用します。 [COMMAG2016]は、Androidアプリケーションを自動化してマルチパスTCPとの相互作用を研究できるソフトウェアテストフレームワークを提案しています。 [PAM2016]は、一般ユーザーが使用する数十のスマートフォンによって交換されたすべてのパケットの1か月間のパケットトレースを分析します。この分析により、スマートフォンでは短い接続が重要であり、スマートフォンでマルチパスTCPを使用する主な利点は、異なるワイヤレスネットワーク間でシームレスなハンドオーバーを実行できることです。長い接続は、これらのハンドオーバーの恩恵を受けます。
As Multipath TCP is not yet widely deployed on both clients and servers, several deployments have used various forms of proxies. Two families of solutions are currently being used or tested.
マルチパスTCPはクライアントとサーバーの両方にまだ広く展開されていないため、いくつかの展開ではさまざまな形式のプロキシを使用しています。現在、2つのソリューションファミリが使用またはテストされています。
A first use case is when an MPTCP-enabled client wants to use several interfaces to reach a regular TCP server. A typical use case is a smartphone that needs to use both its WiFi and its cellular interface to transfer data. Several types of proxies are possible for this use case. An HTTP proxy deployed on a MPTCP-capable server would enable the smartphone to use Multipath TCP to access regular web servers. Obviously, this solution only works for applications that rely on HTTP. Another possibility is to use a proxy that can convert any Multipath TCP connection into a regular TCP connection. MPTCP-specific proxies have been proposed [HotMiddlebox13b] [HAMPEL].
最初の使用例は、MPTCP対応のクライアントが複数のインターフェースを使用して通常のTCPサーバーに到達したい場合です。典型的な使用例は、WiFiとセルラーインターフェイスの両方を使用してデータを転送する必要があるスマートフォンです。この使用例では、いくつかのタイプのプロキシが可能です。 MPTCP対応サーバーにデプロイされたHTTPプロキシにより、スマートフォンはマルチパスTCPを使用して通常のWebサーバーにアクセスできるようになります。明らかに、このソリューションはHTTPに依存するアプリケーションに対してのみ機能します。別の可能性は、マルチパスTCP接続を通常のTCP接続に変換できるプロキシを使用することです。 MPTCP固有のプロキシが提案されています[HotMiddlebox13b] [HAMPEL]。
Another possibility leverages the SOCKS protocol [RFC1928]. SOCKS is often used in enterprise networks to allow clients to reach external servers. For this, the client opens a TCP connection to the SOCKS server that relays it to the final destination. If both the client and the SOCKS server use Multipath TCP, but not the final destination, then Multipath TCP can still be used on the path between the clients and the SOCKS server. At IETF 93, Korea Telecom announced that they have deployed (in June 2015) a commercial service that uses Multipath TCP on smartphones. These smartphones access regular TCP servers through a SOCKS proxy. This enables them to achieve throughputs of up to 850 Mbps [KT].
別の可能性は、SOCKSプロトコル[RFC1928]を活用します。 SOCKSは、クライアントが外部サーバーにアクセスできるようにするために、企業ネットワークでよく使用されます。このために、クライアントはSOCKSサーバーへのTCP接続を開き、それを最終的な宛先に中継します。クライアントとSOCKSサーバーの両方がマルチパスTCPを使用していて、最終的な宛先を使用していない場合でも、クライアントとSOCKSサーバー間のパスでマルチパスTCPを使用できます。韓国テレコムはIETF 93で、スマートフォンにマルチパスTCPを使用する商用サービスを（2015年6月に）展開したことを発表しました。これらのスマートフォンは、SOCKSプロキシを介して通常のTCPサーバーにアクセスします。これにより、最大850 Mbps [KT]のスループットを実現できます。
Measurements performed with Android smartphones [Mobicom15] show that popular applications work correctly through a SOCKS proxy and MPTCP-enabled smartphones. Thanks to Multipath TCP, long-lived connections can be spread over the two available interfaces. However, for short-lived connections, most of the data is sent over the initial subflow that is created over the interface corresponding to the default route and the second subflow is almost not used [PAM2016].
Androidスマートフォン[Mobicom15]で実行された測定は、人気のあるアプリケーションがSOCKSプロキシとMPTCP対応のスマートフォンを介して正しく機能することを示しています。マルチパスTCPのおかげで、長寿命の接続を2つの使用可能なインターフェースに分散できます。ただし、有効期間が短い接続の場合、ほとんどのデータは、デフォルトルートに対応するインターフェースを介して作成される最初のサブフローを介して送信され、2番目のサブフローはほとんど使用されません[PAM2016]。
A second use case is when Multipath TCP is used by middleboxes, typically inside access networks. Various network operators are discussing and evaluating solutions for hybrid access networks [TR-348]. Such networks arise when a network operator controls two different access network technologies, e.g., wired and cellular, and wants to combine them to improve the bandwidth offered to the end users [HYA-ARCH]. Several solutions are currently investigated for such networks [TR-348]. Figure 2 shows the organization of such a network. When a client creates a normal TCP connection, it is intercepted by the Hybrid CPE (HPCE) that converts it in a Multipath TCP connection so that it can use the available access networks (DSL and LTE in the example). The Hybrid Access Gateway (HAG) does the opposite to ensure that the regular server sees a normal TCP connection. Some of the solutions currently discussed for hybrid networks use Multipath TCP on the HCPE and the HAG. Other solutions rely on tunnels between the HCPE and the HAG [GRE-NOTIFY].
2番目の使用例は、通常はアクセスネットワーク内のミドルボックスでマルチパスTCPが使用される場合です。さまざまなネットワークオペレータがハイブリッドアクセスネットワークのソリューションを検討および評価しています[TR-348]。このようなネットワークは、ネットワークオペレーターが2つの異なるアクセスネットワークテクノロジー（有線とセルラーなど）を制御し、それらを組み合わせてエンドユーザーに提供される帯域幅を改善する場合に発生します[HYA-ARCH]。現在、このようなネットワークについていくつかのソリューションが調査されています[TR-348]。図2は、このようなネットワークの構成を示しています。クライアントが通常のTCP接続を作成すると、利用可能なアクセスネットワーク（この例ではDSLおよびLTE）を使用できるように、マルチパスTCP接続に変換するハイブリッドCPE（HPCE）によってインターセプトされます。ハイブリッドアクセスゲートウェイ（HAG）は、通常のサーバーが通常のTCP接続を認識できるようにするために、その逆を行います。ハイブリッドネットワークについて現在議論されているソリューションのいくつかは、HCPEとHAGでマルチパスTCPを使用しています。他のソリューションは、HCPEとHAGの間のトンネルに依存しています[GRE-NOTIFY]。
client --- HCPE ------ DSL ------- HAG --- internet --- server
| |
+------- LTE -----------+
Figure 2: Hybrid Access Network
図2：ハイブリッドアクセスネットワーク
The interference caused by various types of middleboxes has been an important concern during the design of the Multipath TCP protocol. Three studies on the interactions between Multipath TCP and middleboxes are worth discussing.
さまざまなタイプのミドルボックスによって引き起こされる干渉は、マルチパスTCPプロトコルの設計中に重要な問題でした。マルチパスTCPとミドルボックスの間の相互作用に関する3つの研究は、議論する価値があります。
The first analysis appears in [IMC11]. This paper was the main motivation for Multipath TCP incorporating various techniques to cope with middlebox interference. More specifically, Multipath TCP has been designed to cope with middleboxes that:
最初の分析は[IMC11]に表示されます。このホワイトペーパーは、ミドルボックス干渉に対処するためのさまざまな技術を組み込んだマルチパスTCPの主な動機でした。より具体的には、マルチパスTCPは、次のミドルボックスに対応するように設計されています。
o change source or destination addresses
o 送信元または宛先アドレスを変更する
o change source or destination port numbers
o 送信元または宛先のポート番号を変更する
o change TCP sequence numbers
o TCPシーケンス番号を変更する
o split or coalesce segments
o セグメントの分割または合体
o remove TCP options
o TCPオプションを削除する
o modify the payload of TCP segments
o TCPセグメントのペイロードを変更する
These middlebox interferences have all been included in the MBtest suite [MBTest]. This test suite is used in [HotMiddlebox13] to verify the reaction of the Multipath TCP implementation in the Linux kernel [MultipathTCP-Linux] when faced with middlebox interference. The test environment used for this evaluation is a dual-homed client connected to a single-homed server. The middlebox behavior can be activated on any of the paths. The main results of this analysis are:
これらのミドルボックス干渉はすべて、MBtestスイート[MBTest]に含まれています。このテストスイートは[HotMiddlebox13]で使用され、ミドルボックス干渉に直面したときのLinuxカーネル[MultipathTCP-Linux]でのマルチパスTCP実装の反応を検証します。この評価に使用されたテスト環境は、シングルホームサーバーに接続されたデュアルホームクライアントです。ミドルボックスの動作は、どのパスでもアクティブ化できます。この分析の主な結果は次のとおりです。
o the Multipath TCP implementation in the Linux kernel is not affected by a middlebox that performs NAT or modifies TCP sequence numbers
o LinuxカーネルのマルチパスTCP実装は、NATを実行するか、TCPシーケンス番号を変更するミドルボックスの影響を受けません。
o when a middlebox removes the MP_CAPABLE option from the initial SYN segment, the Multipath TCP implementation in the Linux kernel falls back correctly to regular TCP
o ミドルボックスが初期SYNセグメントからMP_CAPABLEオプションを削除すると、LinuxカーネルのマルチパスTCP実装は通常のTCPに正しくフォールバックします
o when a middlebox removes the DSS option from all data segments, the Multipath TCP implementation in the Linux kernel falls back correctly to regular TCP
o ミドルボックスがすべてのデータセグメントからDSSオプションを削除すると、LinuxカーネルのマルチパスTCP実装は通常のTCPに正しくフォールバックします
o when a middlebox performs segment coalescing, the Multipath TCP implementation in the Linux kernel is still able to accurately extract the data corresponding to the indicated mapping
o ミドルボックスがセグメント合体を実行するとき、LinuxカーネルのマルチパスTCP実装は、指定されたマッピングに対応するデータを正確に抽出できます
o when a middlebox performs segment splitting, the Multipath TCP implementation in the Linux kernel correctly reassembles the data corresponding to the indicated mapping. [HotMiddlebox13] shows, in Figure 4 in Section 3.3, a corner case with segment splitting that may lead to a desynchronization between the two hosts.
o ミドルボックスがセグメント分割を実行すると、LinuxカーネルのマルチパスTCP実装が、示されたマッピングに対応するデータを正しく再構成します。 [HotMiddlebox13]は、セクション3.3の図4に、2つのホスト間の非同期化につながる可能性のあるセグメント分割のあるまれなケースを示しています。
The interactions between Multipath TCP and real deployed middleboxes are also analyzed in [HotMiddlebox13]; a particular scenario with the FTP Application Level Gateway running on a NAT is described.
マルチパスTCPと実際にデプロイされたミドルボックス間の相互作用も[HotMiddlebox13]で分析されます。 NATで実行されているFTPアプリケーションレベルゲートウェイを使用した特定のシナリオについて説明します。
Middlebox interference can also be detected by analyzing packet traces on MPTCP-enabled servers. A closer look at the packets received on the multipath-tcp.org server [TMA2015] shows that among the 184,000 Multipath TCP connections, only 125 of them were falling back to regular TCP. These connections originated from 28 different client IP addresses. These include 91 HTTP connections and 34 FTP connections. The FTP interference is expected since Application Level Gateways used for FTP modify the TCP payload and the DSS Checksum detects these modifications. The HTTP interference appeared only on the direction from server to client and could have been caused by transparent proxies deployed in cellular or enterprise networks. A longer trace is discussed in [COMCOM2016] and similar conclusions about the middlebox interference are provided.
ミドルボックス干渉は、MPTCP対応サーバーでパケットトレースを分析することによっても検出できます。 multipath-tcp.orgサーバー[TMA2015]で受信したパケットを詳しく見ると、184,000のマルチパスTCP接続のうち、125のみが通常のTCPにフォールバックしていたことがわかります。これらの接続は、28の異なるクライアントIPアドレスから発信されました。これには、91個のHTTP接続と34個のFTP接続が含まれます。 FTPに使用されるアプリケーションレベルゲートウェイがTCPペイロードを変更し、DSSチェックサムがこれらの変更を検出するため、FTP干渉が予想されます。 HTTP干渉は、サーバーからクライアントへの方向にのみ現れ、セルラーネットワークまたはエンタープライズネットワークに展開された透過プロキシによって引き起こされた可能性があります。より長いトレースは[COMCOM2016]で説明されており、ミドルボックス干渉に関する同様の結論が提供されています。
From an operational viewpoint, knowing that Multipath TCP can cope with various types of middlebox interference is important. However, there are situations where the network operators need to gather information about where a particular middlebox interference occurs. The tracebox software [tracebox] described in [IMC13a] is an extension of the popular traceroute software that enables network operators to check at which hop a particular field of the TCP header (including options) is modified. It has been used by several network operators to debug various middlebox interference problems. Experience with tracebox indicates that supporting the ICMP extension defined in [RFC1812] makes it easier to debug middlebox problems in IPv4 networks.
運用上の観点から、マルチパスTCPがさまざまなタイプのミドルボックス干渉に対処できることを知ることは重要です。ただし、ネットワークオペレーターが特定のミドルボックス干渉が発生する場所に関する情報を収集する必要がある状況があります。 [IMC13a]で説明されているtraceboxソフトウェア[tracebox]は、ネットワークオペレーターがTCPヘッダーの特定のフィールド（オプションを含む）がどのホップで変更されているかを確認できる、人気のtracerouteソフトウェアの拡張です。さまざまなミドルボックス干渉問題をデバッグするために、いくつかのネットワークオペレーターによって使用されています。トレースボックスの経験から、[RFC1812]で定義されているICMP拡張機能をサポートすると、IPv4ネットワークでのミドルボックスの問題のデバッグが容易になります。
Users of the Multipath TCP implementation have reported some experience with middlebox interference. The strangest scenario has been a middlebox that accepts the Multipath TCP options in the SYN segment but later replaces Multipath TCP options with a TCP EOL option [StrangeMbox]. This causes Multipath TCP to perform a fallback to regular TCP without any impact on the application.
マルチパスTCP実装のユーザーは、ミドルボックス干渉の経験を報告しています。最も奇妙なシナリオは、SYNセグメントのマルチパスTCPオプションを受け入れるミドルボックスですが、後でマルチパスTCPオプションをTCP EOLオプション[StrangeMbox]に置き換えます。これにより、アプリケーションに影響を与えることなく、マルチパスTCPが通常のTCPへのフォールバックを実行します。
Congestion control has been an important challenge for Multipath TCP. The coupled congestion-control scheme defined in [RFC6356] in an adaptation of the NewReno algorithm. A detailed description of this coupled algorithm is provided in [NSDI11]. It is the default scheme in the Linux implementation of Multipath TCP, but Linux supports other schemes.
輻輳制御は、マルチパスTCPにとって重要な課題です。 NewRenoアルゴリズムの適応で[RFC6356]で定義された結合された輻輳制御方式。この結合アルゴリズムの詳細な説明は、[NSDI11]で提供されています。これは、マルチパスTCPのLinux実装におけるデフォルトのスキームですが、Linuxは他のスキームをサポートしています。
The second congestion-control scheme is OLIA [CONEXT12]. It is also an adaptation of the NewReno single path congestion-control scheme to support multiple paths. Simulations [CONEXT12] and measurements [CONEXT13] have shown that it provides some performance benefits compared to the default coupled congestion-control scheme.
2番目の輻輳制御方式はOLIA [CONEXT12]です。これは、複数のパスをサポートするためのNewReno単一パス輻輳制御方式の適応でもあります。シミュレーション[CONEXT12]および測定[CONEXT13]は、デフォルトの結合された輻輳制御方式と比較して、いくつかのパフォーマンス上の利点を提供することを示しています。
The delay-based scheme proposed in [ICNP12] has also been ported to the Multipath TCP implementation in the Linux kernel. It has been evaluated by using simulations [ICNP12] and measurements [PaaschPhD].
[ICNP12]で提案された遅延ベースのスキームも、LinuxカーネルのマルチパスTCP実装に移植されました。シミュレーション[ICNP12]と測定[PaaschPhD]を使用して評価されています。
BALIA, defined in [BALIA], provides a better balance between TCP friendliness, responsiveness, and window oscillation.
[BALIA]で定義されているBALIAは、TCPの親しみやすさ、応答性、およびウィンドウの振動のバランスを改善します。
These different congestion-control schemes have been compared in several articles. [CONEXT13] and [PaaschPhD] compare these algorithms in an emulated environment. The evaluation showed that the delay-based congestion-control scheme is less able to efficiently use the available links than the three other schemes.
これらのさまざまな輻輳制御方式は、いくつかの記事で比較されています。 [CONEXT13]と[PaaschPhD]は、エミュレートされた環境でこれらのアルゴリズムを比較します。評価は、遅延ベースの輻輳制御方式が他の3つの方式よりも利用可能なリンクを効率的に使用できないことを示しました。
The multipath capability of Multipath TCP comes from the utilization of one subflow per path. The Multipath TCP architecture [RFC6182] and the protocol specification [RFC6824] define the basic usage of the subflows and the protocol mechanisms that are required to create and terminate them. However, there are no guidelines on how subflows are used during the lifetime of a Multipath TCP session. Most of the published experiments with Multipath TCP have been performed in controlled environments. Still, based on the experience running them and discussions on the mptcp-dev mailing list, interesting lessons have been learned about the management of these subflows.
マルチパスTCPのマルチパス機能は、パスごとに1つのサブフローを使用することで実現されます。マルチパスTCPアーキテクチャ[RFC6182]とプロトコル仕様[RFC6824]は、サブフローの基本的な使用法と、サブフローの作成と終了に必要なプロトコルメカニズムを定義しています。ただし、マルチパスTCPセッションの存続期間中のサブフローの使用方法に関するガイドラインはありません。マルチパスTCPを使用して公開された実験のほとんどは、制御された環境で実行されています。それでも、それらを実行した経験とmptcp-devメーリングリストでの議論に基づいて、これらのサブフローの管理について興味深い教訓が得られました。
From a subflow viewpoint, the Multipath TCP protocol is completely symmetrical. Both the clients and the server have the capability to create subflows. However, in practice, the existing Multipath TCP implementations have opted for a strategy where only the client creates new subflows. The main motivation for this strategy is that often the client resides behind a NAT or a firewall, preventing passive subflow openings on the client. Although there are environments such as datacenters where this problem does not occur, as of this writing, no precise requirement has emerged for allowing the server to create new subflows.
サブフローの観点から見ると、マルチパスTCPプロトコルは完全に対称です。クライアントとサーバーの両方にサブフローを作成する機能があります。ただし、実際には、既存のマルチパスTCP実装は、クライアントのみが新しいサブフローを作成する戦略を選択しています。この戦略の主な動機は、多くの場合、クライアントがNATまたはファイアウォールの背後に常駐し、クライアントでパッシブサブフローが開かれないようにすることです。この問題が発生しないデータセンターなどの環境がありますが、これを書いている時点では、サーバーが新しいサブフローを作成できるようにするための正確な要件は明らかにされていません。
The Multipath TCP implementation in the Linux kernel includes several strategies to manage the subflows that compose a Multipath TCP session. The basic subflow manager is the full-mesh. As the name implies, it creates a full-mesh of subflows between the communicating hosts.
LinuxカーネルのマルチパスTCP実装には、マルチパスTCPセッションを構成するサブフローを管理するためのいくつかの戦略が含まれています。基本的なサブフローマネージャーはフルメッシュです。名前が示すように、通信するホスト間にサブフローのフルメッシュを作成します。
The most frequent use case for this subflow manager is a multihomed client connected to a single-homed server. In this case, one subflow is created for each interface on the client. The current implementation of the full-mesh subflow manager is static. The subflows are created immediately after the creation of the initial subflow. If one subflow fails during the lifetime of the Multipath TCP session (e.g., due to excessive retransmissions or the loss of the corresponding interface), it is not always reestablished. There is ongoing work to enhance the full-mesh path manager to deal with such events.
このサブフローマネージャーの最も頻繁な使用例は、シングルホームサーバーに接続されたマルチホームクライアントです。この場合、クライアント上のインターフェースごとに1つのサブフローが作成されます。フルメッシュサブフローマネージャーの現在の実装は静的です。サブフローは、最初のサブフローの作成直後に作成されます。マルチパスTCPセッションの存続期間中に1つのサブフローが失敗した場合（過度の再送信や対応するインターフェースの損失など）、常に再確立されるとは限りません。このようなイベントに対処するためにフルメッシュパスマネージャーを拡張する作業が進行中です。
When the server is multihomed, using the full-mesh subflow manager may lead to a large number of subflows being established. For example, consider a dual-homed client connected to a server with three interfaces. In this case, even if the subflows are only created by the client, six subflows will be established. This may be excessive in some environments, in particular when the client and/or the server have a large number of interfaces. Implementations should limit the number of subflows that are used.
サーバーがマルチホームの場合、フルメッシュサブフローマネージャーを使用すると、多数のサブフローが確立される可能性があります。たとえば、3つのインターフェイスを持つサーバーに接続されたデュアルホームクライアントを考えてみます。この場合、サブフローがクライアントによってのみ作成される場合でも、6つのサブフローが確立されます。一部の環境では、特にクライアントやサーバーに多数のインターフェースがある場合、これは過剰になる可能性があります。実装では、使用されるサブフローの数を制限する必要があります。
Creating subflows between multihomed clients and servers may sometimes lead to operational issues as observed by discussions on the mptcp-dev mailing list. In some cases, the network operators would like to have a better control on how the subflows are created by Multipath TCP [MPTCP-MAX-SUB]. This might require the definition of policy rules to control the operation of the subflow manager. The two scenarios below illustrate some of these requirements.
マルチホームのクライアントとサーバー間にサブフローを作成すると、mptcp-devメーリングリストでの議論で観察されているように、運用上の問題が発生する場合があります。場合によっては、ネットワークオペレーターは、マルチパスTCP [MPTCP-MAX-SUB]によってサブフローが作成される方法をより適切に制御する必要があります。これには、サブフローマネージャーの操作を制御するためのポリシールールの定義が必要になる場合があります。以下の2つのシナリオは、これらの要件の一部を示しています。
host1 ---------- switch1 ----- host2
| | |
+-------------- switch2 --------+
Figure 3: Simple Switched Network Topology
図3：単純なスイッチドネットワークトポロジ
Consider the simple network topology shown in Figure 3. From an operational viewpoint, a network operator could want to create two subflows between the communicating hosts. From a bandwidth utilization viewpoint, the most natural paths are host1-switch1-host2 and host1-switch2-host2. However, a Multipath TCP implementation running on these two hosts may sometimes have difficulties to obtain this result.
図3に示す単純なネットワークトポロジを考えてみます。運用上の観点から、ネットワークオペレーターは通信ホスト間に2つのサブフローを作成することができます。帯域幅使用率の観点から、最も自然なパスはhost1-switch1-host2とhost1-switch2-host2です。ただし、これらの2つのホストで実行されているマルチパスTCP実装では、この結果を取得することが困難な場合があります。
To understand the difficulty, let us consider different allocation strategies for the IP addresses. A first strategy is to assign two subnets: subnetA (resp. subnetB) contains the IP addresses of host1's interface to switch1 (resp. switch2) and host2's interface to switch1 (resp. switch2). In this case, a Multipath TCP subflow manager should only create one subflow per subnet. To enforce the utilization of these paths, the network operator would have to specify a policy that prefers the subflows in the same subnet over subflows between addresses in different subnets. It should be noted that the policy should probably also specify how the subflow manager should react when an interface or subflow fails.
難しさを理解するために、IPアドレスのさまざまな割り当て戦略について考えてみましょう。最初の戦略は、2つのサブネットを割り当てることです。subnetA（またはsubnetB）には、switch1（またはswitch2）へのhost1のインターフェースおよびswitch1（またはswitch2）へのhost2のインターフェースのIPアドレスが含まれます。この場合、マルチパスTCPサブフローマネージャーは、サブネットごとに1つのサブフローのみを作成する必要があります。これらのパスの使用を強制するには、ネットワークオペレーターは、異なるサブネット内のアドレス間のサブフローよりも同じサブネット内のサブフローを優先するポリシーを指定する必要があります。ポリシーはおそらく、インターフェースまたはサブフローが失敗したときにサブフローマネージャーがどのように反応するかを指定する必要があることに注意してください。
A second strategy is to use a single subnet for all IP addresses. In this case, it becomes more difficult to specify a policy that indicates which subflows should be established.
2番目の戦略は、すべてのIPアドレスに単一のサブネットを使用することです。この場合、どのサブフローを確立する必要があるかを示すポリシーを指定することがより困難になります。
The second subflow manager that is currently supported by the Multipath TCP implementation in the Linux kernel is the ndiffport subflow manager. This manager was initially created to exploit the path diversity that exists between single-homed hosts due to the utilization of flow-based load-balancing techniques [SIGCOMM11]. This subflow manager creates N subflows between the same pair of IP addresses. The N subflows are created by the client and differ only in the source port selected by the client. It was not designed to be used on multihomed hosts.
LinuxカーネルのマルチパスTCP実装で現在サポートされている2番目のサブフローマネージャーは、ndiffportサブフローマネージャーです。このマネージャは、フローベースのロードバランシング技術[SIGCOMM11]の利用により、シングルホームのホスト間に存在するパスの多様性を利用するために最初に作成されました。このサブフローマネージャーは、同じIPアドレスのペア間にN個のサブフローを作成します。 Nサブフローはクライアントによって作成され、クライアントによって選択された送信元ポートのみが異なります。マルチホームホストで使用するように設計されていません。
A more flexible subflow manager has been proposed, implemented and evaluated in [CONEXT15]. This subflow manager exposes various kernel events to a user space daemon that decides when subflows need to be created and terminated based on various policies.
[CONEXT15]では、より柔軟なサブフローマネージャーが提案、実装、評価されています。このサブフローマネージャーは、さまざまなポリシーに基づいてサブフローを作成および終了する必要がある時期を決定するユーザースペースデーモンにさまざまなカーネルイベントを公開します。
The Multipath TCP protocol relies on the token contained in the MP_JOIN option to associate a subflow to an existing Multipath TCP session. This implies that there is no restriction on the source address, destination address and source or destination ports used for the new subflow. The ability to use different source and destination addresses is key to support multihomed servers and clients. The ability to use different destination port numbers is worth discussing because it has operational implications.
マルチパスTCPプロトコルは、MP_JOINオプションに含まれているトークンに依存して、サブフローを既存のマルチパスTCPセッションに関連付けます。これは、新しいサブフローに使用される送信元アドレス、宛先アドレス、および送信元または宛先ポートに制限がないことを意味します。異なる送信元アドレスと宛先アドレスを使用する機能は、マルチホームサーバーとクライアントをサポートするための鍵です。異なる宛先ポート番号を使用する機能は、運用に影響を与えるため、検討する価値があります。
For illustration, consider a dual-homed client that creates a second subflow to reach a single-homed server as illustrated in Figure 4.
説明のために、図4に示すように、シングルホームサーバーに到達するための2番目のサブフローを作成するデュアルホームクライアントを考えます。
client ------- r1 --- internet --- server
| |
+----------r2-------+
Figure 4: Multihomed-Client Connected to Single-Homed Server
図4：シングルホームサーバーに接続されたマルチホームクライアント
When the Multipath TCP implementation in the Linux kernel creates the second subflow, it uses the same destination port as the initial subflow. This choice is motivated by the fact that the server might be protected by a firewall and only accept TCP connections (including subflows) on the official port number. Using the same destination port for all subflows is also useful for operators that rely on the port numbers to track application usage in their network.
LinuxカーネルのマルチパスTCP実装が2番目のサブフローを作成するとき、最初のサブフローと同じ宛先ポートを使用します。この選択は、サーバーがファイアウォールで保護され、公式のポート番号でのみTCP接続（サブフローを含む）を受け入れる可能性があるという事実に基づいています。すべてのサブフローに同じ宛先ポートを使用することは、ネットワークでのアプリケーションの使用状況を追跡するためにポート番号に依存するオペレーターにとっても役立ちます。
There have been suggestions from Multipath TCP users to modify the implementation to allow the client to use different destination ports to reach the server. This suggestion seems mainly motivated by traffic-shaping middleboxes that are used in some wireless networks. In networks where different shaping rates are associated with different destination port numbers, this could allow Multipath TCP to reach a higher performance. This behavior is valid according to the Multipath TCP specification [RFC6824]. An application could use an enhanced socket API [SOCKET] to behave in this way.
マルチパスTCPユーザーから、クライアントが異なる宛先ポートを使用してサーバーに到達できるように実装を変更する提案がありました。この提案は、一部のワイヤレスネットワークで使用されているトラフィックシェーピングミドルボックスが主な動機となっているようです。異なるシェーピングレートが異なる宛先ポート番号に関連付けられているネットワークでは、これによりマルチパスTCPがより高いパフォーマンスに到達できる可能性があります。この動作は、マルチパスTCP仕様[RFC6824]に従って有効です。アプリケーションは、拡張ソケットAPI [SOCKET]を使用してこのように動作できます。
However, from an implementation point-of-view supporting different destination ports for the same Multipath TCP connection can cause some issues. A legacy implementation of a TCP stack creates a listening socket to react upon incoming SYN segments. The listening socket is handling the SYN segments that are sent on a specific port number. Demultiplexing incoming segments can thus be done solely by looking at the IP addresses and the port numbers. With Multipath TCP however, incoming SYN segments may have an MP_JOIN option with a different destination port. This means that all incoming segments that did not match on an existing listening-socket or an already established socket must be parsed for an eventual MP_JOIN option. This imposes an additional cost on servers, previously not existent on legacy TCP implementations.
ただし、同じマルチパスTCP接続に対して異なる宛先ポートをサポートする実装の観点からは、いくつかの問題が発生する可能性があります。 TCPスタックのレガシー実装では、着信SYNセグメントに反応するリスニングソケットが作成されます。待機ソケットは、特定のポート番号で送信されるSYNセグメントを処理しています。したがって、着信セグメントの逆多重化は、IPアドレスとポート番号を調べるだけで実行できます。ただし、マルチパスTCPでは、着信SYNセグメントに別の宛先ポートを持つMP_JOINオプションがある場合があります。つまり、既存のリスニングソケットまたは既に確立されているソケットで一致しなかったすべての着信セグメントは、最終的なMP_JOINオプションを解析する必要があります。これにより、以前はレガシーTCP実装に存在しなかったサーバーに追加のコストがかかります。
client server
| |
MPTCP: ESTABLISHED | | MPTCP: ESTABLISHED
Sub: ESTABLISHED | | Sub: ESTABLISHED
| |
| DATA_FIN |
MPTCP: CLOSE-WAIT | <------------------------ | close() (step 1)
Sub: ESTABLISHED | DATA_ACK |
| ------------------------> | MPTCP: FIN-WAIT-2
| | Sub: ESTABLISHED
| |
| DATA_FIN + subflow-FIN |
close()/shutdown() | ------------------------> | MPTCP: TIME-WAIT
(step 2) | DATA_ACK | Sub: CLOSE-WAIT
MPTCP: CLOSED | <------------------------ |
Sub: FIN-WAIT-2 | |
| |
| subflow-FIN |
MPTCP: CLOSED | <------------------------ | subflow-close()
Sub: TIME-WAIT | subflow-ACK |
(step 3) | ------------------------> | MPTCP: TIME-WAIT
| | Sub: CLOSED
| |
Figure 5: Multipath TCP may not be able to avoid time-wait state on the subflow (indicated as Sub in the drawing), even if enforced by the application on the client-side.
図5：クライアント側のアプリケーションによって強制されている場合でも、マルチパスTCPはサブフロー（図ではSubとして示されています）での時間待機状態を回避できない場合があります。
Figure 5 shows a very particular issue within Multipath TCP. Many high-performance applications try to avoid TIME-WAIT state by deferring the closure of the connection until the peer has sent a FIN. That way, the client on the left of Figure 5 does a passive closure of the connection, transitioning from CLOSE-WAIT to Last-ACK and finally freeing the resources after reception of the ACK of the FIN. An application running on top of an MPTCP-enabled Linux kernel might also use this approach. The difference here is that the close() of the connection (step 1 in Figure 5) only triggers the sending of a DATA_FIN. Nothing guarantees that the kernel is ready to combine the DATA_FIN with a subflow-FIN. The reception of the DATA_FIN will make the application trigger the closure of the connection (step 2), trying to avoid TIME-WAIT state with this late closure. This time, the kernel might decide to combine the DATA_FIN with a subflow-FIN. This decision will be fatal, as the subflow's state machine will not transition from CLOSE_WAIT to Last-ACK, but rather go through FIN_WAIT-2 into TIME-WAIT state. The TIME-WAIT state will consume resources on the host for at least 2 MSL (Maximum Segment Lifetime). Thus, a smart application that tries to avoid TIME-WAIT state by doing late closure of the connection actually ends up with one of its subflows in TIME-WAIT state. A high-performance Multipath TCP kernel implementation should honor the desire of the application to do passive closure of the connection and successfully avoid TIME-WAIT state -- even on the subflows.
図5は、マルチパスTCP内の非常に特定の問題を示しています。多くの高性能アプリケーションは、ピアがFINを送信するまで接続のクローズを延期することにより、TIME-WAIT状態を回避しようとします。このようにして、図5の左側のクライアントは接続のパッシブクローズを行い、CLOSE-WAITからLast-ACKに移行し、FINのACKの受信後にリソースを最終的に解放します。 MPTCP対応のLinuxカーネル上で実行されるアプリケーションも、このアプローチを使用する場合があります。ここでの違いは、接続のclose()（図5のステップ1）がDATA_FINの送信のみをトリガーすることです。カーネルがDATA_FINとサブフローFINを組み合わせる準備ができていることを保証するものは何もありません。 DATA_FINを受信すると、アプリケーションは接続のクローズをトリガーし（ステップ2）、この遅いクローズでTIME-WAIT状態を回避しようとします。今回、カーネルはDATA_FINをサブフローFINと組み合わせることに決めるかもしれません。サブフローの状態マシンはCLOSE_WAITからLast-ACKに遷移せず、FIN_WAIT-2を通過してTIME-WAIT状態になるため、この決定は致命的です。 TIME-WAIT状態は、少なくとも2 MSL（最大セグメントライフタイム）の間、ホスト上のリソースを消費します。したがって、接続の遅延クローズを実行してTIME-WAIT状態を回避しようとするスマートアプリケーションは、実際には、TIME-WAIT状態のサブフローの1つで終了します。高性能マルチパスTCPカーネル実装は、接続のパッシブクローズを実行し、サブフロー上でもTIME-WAIT状態を回避するというアプリケーションの要望を尊重する必要があります。
The solution to this problem lies in an optimistic assumption that a host doing active-closure of a Multipath TCP connection by sending a DATA_FIN will soon also send a FIN on all its subflows. Thus, the passive closer of the connection can simply wait for the peer to send exactly this FIN -- enforcing passive closure even on the subflows. Of course, to avoid consuming resources indefinitely, a timer must limit the time our implementation waits for the FIN.
この問題の解決策は、DATA_FINを送信してマルチパスTCP接続のアクティブなクローズを行うホストが、すぐにすべてのサブフローでFINも送信するという楽観的な仮定にあります。したがって、接続のパッシブクローザーは、ピアがこのFINを正確に送信するのを単に待つことができます-サブフローでさえパッシブクロージャを強制します。もちろん、無期限にリソースを消費しないようにするために、タイマーは、実装がFINを待機する時間を制限する必要があります。
In a Multipath TCP implementation, the packet scheduler is the algorithm that is executed when transmitting each packet to decide on which subflow it needs to be transmitted. The packet scheduler itself does not have any impact on the interoperability of Multipath TCP implementations. However, it may clearly impact the performance of Multipath TCP sessions. The Multipath TCP implementation in the Linux kernel supports a pluggable architecture for the packet scheduler [PaaschPhD]. As of this writing, two schedulers have been implemented: round-robin and lowest-rtt-first. The second scheduler relies on the round-trip time (rtt) measured on each TCP subflow and sends first segments over the subflow having the lowest round-trip time. They are compared in [CSWS14]. The experiments and measurements described in [CSWS14] show that the lowest-rtt-first scheduler appears to be the best compromise from a performance viewpoint. Another study of the packet schedulers is presented in [PAMS2014]. This study relies on simulations with the Multipath TCP implementation in the Linux kernel. They compare the lowest-rtt-first with the round-robin and a random scheduler. They show some situations where the lowest-rtt-first scheduler does not perform as well as the other schedulers, but there are many scenarios where the opposite is true. [PAMS2014] notes that "it is highly likely that the optimal scheduling strategy depends on the characteristics of the paths being used."
マルチパスTCPの実装では、パケットスケジューラは、各パケットを送信するときに実行するアルゴリズムで、送信する必要のあるサブフローを決定します。パケットスケジューラ自体は、マルチパスTCP実装の相互運用性に影響を与えません。ただし、マルチパスTCPセッションのパフォーマンスに明らかに影響する場合があります。 LinuxカーネルのマルチパスTCP実装は、パケットスケジューラ[PaaschPhD]のプラグ可能なアーキテクチャをサポートしています。これを書いている時点では、2つのスケジューラーが実装されています：ラウンドロビンと最下位rt-firstです。 2番目のスケジューラーは、各TCPサブフローで測定された往復時間（rtt）に依存し、往復時間が最も短いサブフローを介して最初のセグメントを送信します。これらは[CSWS14]で比較されます。 [CSWS14]で説明されている実験と測定は、パフォーマンスの観点から、lowest-rtt-firstスケジューラーが最良の妥協案であると思われることを示しています。パケットスケジューラの別の研究が[PAMS2014]に示されています。この調査は、LinuxカーネルのマルチパスTCP実装を使用したシミュレーションに依存しています。彼らは最も低いrt-firstをラウンドロビンとランダムスケジューラと比較します。それらは、最下位の最初のスケジューラーが他のスケジューラーと同じように実行しないいくつかの状況を示していますが、その逆が当てはまる多くのシナリオがあります。 [PAMS2014]は、「最適なスケジューリング戦略は、使用されるパスの特性に依存する可能性が非常に高い」と述べています。
When an application performs a write/send system call, the kernel allocates a packet buffer (sk_buff in Linux) to store the data the application wants to send. The kernel will store at most one MSS (Maximum Segment Size) of data per buffer. As the MSS can differ amongst subflows, an MPTCP implementation must select carefully the MSS used to generate application data. The Linux kernel implementation had various ways of selecting the MSS: minimum or maximum amongst the different subflows. However, these heuristics of MSS selection can cause significant performance issues in some environments. Consider the following example. An MPTCP connection has two established subflows that respectively use an MSS of 1420 and 1428 bytes. If MPTCP selects the maximum, then the application will generate segments of 1428 bytes of data. An MPTCP implementation will have to split the segment in two (1420-byte and 8-byte) segments when pushing on the subflow with the smallest MSS. The latter segment will introduce a large overhead as this single data segment will use 2 slots in the congestion window (in packets) therefore reducing by roughly twice the potential throughput (in bytes/s) of this subflow. Taking the smallest MSS does not solve the issue as there might be a case where the subflow with the smallest MSS only sends a few packets, therefore reducing the potential throughput of the other subflows.
アプリケーションが書き込み/送信システムコールを実行すると、カーネルはパケットバッファー（Linuxではsk_buff）を割り当てて、アプリケーションが送信するデータを格納します。カーネルは、バッファごとに最大で1つのMSS（最大セグメントサイズ）のデータを格納します。 MSSはサブフロー間で異なる可能性があるため、MPTCP実装では、アプリケーションデータの生成に使用されるMSSを慎重に選択する必要があります。 Linuxカーネルの実装には、MSSを選択するさまざまな方法がありました。異なるサブフローの中で最小または最大です。ただし、これらのMSS選択のヒューリスティックは、一部の環境で重大なパフォーマンスの問題を引き起こす可能性があります。次の例を考えてみましょう。 MPTCP接続には、それぞれ1420バイトと1428バイトのMSSを使用する2つの確立されたサブフローがあります。 MPTCPが最大値を選択した場合、アプリケーションは1428バイトのデータのセグメントを生成します。 MPTCP実装では、最小のMSSでサブフローをプッシュするときに、セグメントを2つ（1420バイトと8バイト）のセグメントに分割する必要があります。後者のセグメントは、この単一のデータセグメントが輻輳ウィンドウの2つのスロット（パケット単位）を使用するため、大きなオーバーヘッドが発生し、このサブフローの潜在的なスループット（バイト/秒単位）の約2倍に削減されます。最小のMSSを使用しても、最小のMSSのサブフローが少数のパケットしか送信しないため、他のサブフローの潜在的なスループットが低下する場合があるため、問題は解決しません。
The Linux implementation recently took another approach [DetalMSS]. Instead of selecting the minimum and maximum values, it now dynamically adapts the MSS based on the contribution of all the subflows to the connection's throughput. For each subflow, it computes the potential throughput achieved by selecting each MSS value and by taking into account the lost space in the congestion window. It then selects the MSS that allows to achieve the highest potential throughput.
Linuxの実装では、最近別のアプローチ[DetalMSS]が採用されました。最小値と最大値を選択する代わりに、接続のスループットへのすべてのサブフローの寄与に基づいて、MSSを動的に適合させます。各サブフローについて、各MSS値を選択し、輻輳ウィンドウで失われたスペースを考慮に入れることにより、潜在的なスループットを計算します。次に、最高のスループットを達成できるMSSを選択します。
Given the prevalence of middleboxes that clamp the MSS, Multipath TCP implementations must be able to efficiently support subflows with different MSS values. The strategy described above is a possible solution to this problem.
MSSをクランプするミドルボックスの普及により、マルチパスTCP実装は、異なるMSS値を持つサブフローを効率的にサポートできる必要があります。上記の戦略は、この問題に対する可能な解決策です。
Multihomed clients such as smartphones can send DNS queries over any of their interfaces. When a single-homed client performs a DNS query, it receives from its local resolver the best answer for its request. If the client is multihomed, the answer in response to the DNS query may vary with the interface over which it has been sent.
スマートフォンなどのマルチホームクライアントは、任意のインターフェースを介してDNSクエリを送信できます。シングルホームのクライアントがDNSクエリを実行すると、ローカルリゾルバーから要求に対する最良の回答を受け取ります。クライアントがマルチホームの場合、DNSクエリへの応答は、送信されたインターフェイスによって異なる場合があります。
cdn1
|
client -- cellular -- internet -- cdn3
| |
+----- wifi --------+
|
cdn2
Figure 6: Simple Network Topology
図6：単純なネットワークトポロジ
If the client sends a DNS query over the WiFi interface, the answer will point to the cdn2 server while the same request sent over the cellular interface will point to the cdn1 server. This might cause problems for CDN providers that locate their servers inside ISP networks and have contracts that specify that the CDN server will only be accessed from within this particular ISP. Assume now that both the client and the CDN servers support Multipath TCP. In this case, a Multipath TCP session from cdn1 or cdn2 would potentially use both the cellular network and the WiFi network. Serving the client from cdn2 over the cellular interface could violate the contract between the CDN provider and the network operators. A similar problem occurs with regular TCP if the client caches DNS replies. For example, the client obtains a DNS answer over the cellular interface and then stops this interface and starts to use its WiFi interface. If the client retrieves data from cdn1 over its WiFi interface, this may also violate the contract between the CDN and the network operators.
クライアントがWiFiインターフェースを介してDNSクエリを送信する場合、セルラーインターフェースを介して送信される同じ要求がcdn1サーバーを指す一方で、答えはcdn2サーバーを指します。これは、サーバーをISPネットワーク内に配置し、CDNサーバーがこの特定のISP内からのみアクセスされることを指定する契約を持っているCDNプロバイダーに問題を引き起こす可能性があります。ここで、クライアントとCDNサーバーの両方がマルチパスTCPをサポートするとします。この場合、cdn1またはcdn2からのマルチパスTCPセッションは、セルラーネットワークとWiFiネットワークの両方を使用する可能性があります。セルラーインターフェイスを介してcdn2からクライアントにサービスを提供すると、CDNプロバイダーとネットワークオペレーター間の契約に違反する可能性があります。クライアントがDNS応答をキャッシュする場合、通常のTCPでも同様の問題が発生します。たとえば、クライアントはセルラーインターフェイスを介してDNS応答を取得し、このインターフェイスを停止して、WiFiインターフェイスの使用を開始します。クライアントがWiFiインターフェースを介してcdn1からデータを取得する場合、これはCDNとネットワークオペレーター間の契約にも違反する可能性があります。
A possible solution to prevent this problem would be to modify the DNS resolution on the client. The client subnet Extension Mechanisms for DNS (EDNS) defined in [RFC7871] could be used for this purpose. When the client sends a DNS query from its WiFi interface, it should also send the client subnet corresponding to the cellular interface in this request. This would indicate to the resolver that the answer should be valid for both the WiFi and the cellular interfaces (e.g., the cdn3 server).
この問題を防ぐための可能な解決策は、クライアントのDNS解決を変更することです。 [RFC7871]で定義されているDNSのクライアントサブネット拡張メカニズム（EDNS）は、この目的に使用できます。クライアントがWiFiインターフェースからDNSクエリを送信するとき、このリクエストでは、セルラーインターフェースに対応するクライアントサブネットも送信する必要があります。これは、解決策がWiFiとセルラーインターフェース（cdn3サーバーなど）の両方で有効であることをリゾルバーに示します。
Multipath TCP enables a host to use different interfaces to reach a server. In theory, this should ensure connectivity when at least one of the interfaces is active. However, in practice, there are some particular scenarios with captive portals that may cause operational problems. The reference environment is shown in Figure 7.
マルチパスTCPにより、ホストはさまざまなインターフェースを使用してサーバーに到達できます。理論的には、これにより、少なくとも1つのインターフェイスがアクティブなときに接続が保証されます。ただし、実際には、運用上の問題を引き起こす可能性のあるキャプティブポータルの特定のシナリオがいくつかあります。参照環境を図7に示します。
client ----- network1
|
+------- internet ------------- server
Figure 7: Issue with Captive Portal
図7：キャプティブポータルの問題
The client is attached to two networks: network1 that provides limited connectivity and the entire Internet through the second network interface. In practice, this scenario corresponds to an open WiFi network with a captive portal for network1 and a cellular service for the second interface. On many smartphones, the WiFi interface is preferred over the cellular interface. If the smartphone learns a default route via both interfaces, it will typically prefer to use the WiFi interface to send its DNS request and create the first subflow. This is not optimal with Multipath TCP. A better approach would probably be to try a few attempts on the WiFi interface and then, upon failure of these attempts, try to use the second interface for the initial subflow as well.
クライアントは2つのネットワークに接続されています。制限付きの接続を提供するnetwork1と、2番目のネットワークインターフェイスを介したインターネット全体です。実際には、このシナリオは、ネットワーク1のキャプティブポータルと2番目のインターフェイスのセルラーサービスを備えたオープンWiFiネットワークに対応しています。多くのスマートフォンでは、セルラーインターフェイスよりもWiFiインターフェイスが優先されます。スマートフォンが両方のインターフェースを介してデフォルトルートを学習する場合、通常、WiFiインターフェースを使用してDNSリクエストを送信し、最初のサブフローを作成します。これは、マルチパスTCPでは最適ではありません。より良いアプローチは、おそらくWiFiインターフェースで数回試行してから、これらの試行が失敗したときに、最初のサブフローにも2番目のインターフェースを使用することです。
MPTCP has been designed to interoperate with webservers that benefit from SYN-cookies to protect against SYN-flooding attacks [RFC4987]. MPTCP achieves this by echoing the keys negotiated during the MP_CAPABLE handshake in the third ACK of the three-way handshake. Reception of this third ACK then allows the server to reconstruct the state specific to MPTCP.
MPTCPは、SYNフラッディング攻撃[RFC4987]から保護するためにSYN-cookieの恩恵を受けるWebサーバーと相互運用するように設計されています。 MPTCPは、3方向ハンドシェイクの3番目のACKでMP_CAPABLEハンドシェイク中にネゴシエートされたキーをエコーすることでこれを実現します。この3番目のACKを受信すると、サーバーはMPTCPに固有の状態を再構築できます。
However, one caveat to this mechanism is the unreliable nature of the third ACK. Indeed, when the third ACK gets lost, the server will not be able to reconstruct the MPTCP state. MPTCP will fall back to regular TCP in this case. This is in contrast to regular TCP. When the client starts sending data, the first data segment also includes the SYN-cookie, which allows the server to reconstruct the TCP-state. Further, this data segment will be retransmitted by the client in case it gets lost and thus is resilient against loss. MPTCP does not include the keys in this data segment and thus the server cannot reconstruct the MPTCP state.
ただし、このメカニズムの注意点の1つは、3番目のACKの信頼できない性質です。実際、3番目のACKが失われると、サーバーはMPTCP状態を再構築できなくなります。この場合、MPTCPは通常のTCPにフォールバックします。これは通常のTCPとは対照的です。クライアントがデータの送信を開始すると、最初のデータセグメントにはSYN-cookieも含まれるため、サーバーはTCP状態を再構築できます。さらに、このデータセグメントは、紛失した場合に備えてクライアントによって再送信されるため、紛失からの回復力があります。 MPTCPはこのデータセグメントにキーを含まないため、サーバーはMPTCP状態を再構築できません。
This issue might be considered as a minor one for MPTCP. Losing the third ACK should only happen when packet loss is high; in this case, MPTCP provides a lot of benefits as it can move traffic away from the lossy link. It is undesirable that MPTCP has a higher chance to fall back to regular TCP in those lossy environments.
この問題は、MPTCPのマイナーな問題と見なされる場合があります。 3番目のACKの損失は、パケット損失が大きい場合にのみ発生します。この場合、MPTCPは損失の多いリンクからトラフィックを移動できるため、多くの利点があります。これらの損失の多い環境では、MPTCPが通常のTCPにフォールバックする可能性が高いことは望ましくありません。
[MPTCP-DEPLOY] discusses this issue and suggests a modified handshake mechanism that ensures reliable delivery of the MP_CAPABLE, following the three-way handshake. This modification will make MPTCP reliable, even in lossy environments when servers need to use SYN-cookies to protect against SYN-flooding attacks.
[MPTCP-DEPLOY]はこの問題について説明し、3ウェイハンドシェイクに続いて、MP_CAPABLEの信頼性の高い配信を保証する変更されたハンドシェイクメカニズムを提案します。この変更により、サーバーがSYN-cookieを使用してSYNフラッディング攻撃から保護する必要がある損失の多い環境でも、MPTCPの信頼性が向上します。
Large-scale server farms typically deploy thousands of servers behind a single virtual IP (VIP). Steering traffic to these servers is done through Layer 4 load-balancers that ensure that a TCP-flow will always be routed to the same server [Presto08].
大規模なサーバーファームでは、通常、単一の仮想IP（VIP）の背後に何千ものサーバーを展開します。これらのサーバーへのトラフィックのステアリングは、TCPフローが常に同じサーバーにルーティングされるようにするレイヤー4ロードバランサーを介して行われます[Presto08]。
As Multipath TCP uses multiple different TCP subflows to steer the traffic across the different paths, load-balancers need to ensure that all these subflows are routed to the same server. This implies that the load-balancers need to track the MPTCP-related state, allowing them to parse the token in the MP_JOIN and assign those subflows to the appropriate server. However, server farms typically deploy several load-balancers for reliability and capacity reasons. As a TCP subflow might get routed to any of these load-balancers, they would need to synchronize the MPTCP-related state -- a solution that is not feasible on a large scale.
マルチパスTCPは複数の異なるTCPサブフローを使用して異なるパスを介してトラフィックを誘導するため、ロードバランサーはこれらすべてのサブフローが同じサーバーにルーティングされるようにする必要があります。これは、ロードバランサーがMPTCP関連の状態を追跡し、MP_JOINのトークンを解析して適切なサーバーにサブフローを割り当てる必要があることを意味します。ただし、サーバーファームは通常、信頼性と容量の理由からいくつかのロードバランサーを展開します。 TCPサブフローはこれらのロードバランサーのいずれかにルーティングされる可能性があるため、MPTCP関連の状態を同期する必要があります。これは、大規模では実行できないソリューションです。
The token (carried in the MP_JOIN) contains the information indicating to which MPTCP-session the subflow belongs. As the token is a hash of the key, servers are not able to generate the token in such a way that the token can provide the necessary information to the load-balancers, which would allow them to route TCP subflows to the appropriate server. [MPTCP-LOAD] discusses this issue in detail and suggests two alternative MP_CAPABLE handshakes to overcome these.
トークン（MP_JOINに含まれる）には、サブフローが属するMPTCPセッションを示す情報が含まれています。トークンはキーのハッシュであるため、サーバーは、トークンがロードバランサーに必要な情報を提供できるような方法でトークンを生成できません。これにより、TCPサブフローを適切なサーバーにルーティングできます。 [MPTCP-LOAD]はこの問題を詳細に説明し、これらを克服するために2つの代替MP_CAPABLEハンドシェイクを提案しています。
This informational document discusses use cases and operational experience with Multipath TCP. An extensive analysis of the remaining security issues in the Multipath TCP specification has been published in [RFC7430], together with suggestions for possible solutions.
この情報ドキュメントでは、マルチパスTCPの使用例と運用経験について説明します。マルチパスTCP仕様の残りのセキュリティ問題の広範な分析が、可能な解決策の提案とともに[RFC7430]で公開されています。
From a security viewpoint, it is important to note that Multipath TCP, like other multipath solutions such as SCTP, has the ability to send packets belonging to a single connection over different paths. This design feature of Multipath TCP implies that middleboxes that have been deployed on-path assuming that they would observe all the packets exchanged for a given connection in both directions may not function correctly anymore. A typical example are firewalls, Intrusion Detection System (IDS) or deep packet inspections (DPIs) deployed in enterprise networks. Those devices expect to observe all the packets from all TCP connections. With Multipath TCP, those middleboxes may not observe anymore all packets since some of them may follow a different path. The two examples below illustrate typical deployments of such middleboxes. The first example, Figure 8, shows an MPTCP-enabled smartphone attached to both an enterprise and a cellular network. If a Multipath TCP connection is established by the smartphone towards a server, some of the packets sent by the smartphone or the server may be transmitted over the cellular network and thus be invisible for the enterprise middlebox.
セキュリティの観点から、マルチパスTCPは、SCTPなどの他のマルチパスソリューションと同様に、単一の接続に属するパケットを異なるパスで送信する機能を備えていることに注意することが重要です。マルチパスTCPのこの設計機能は、特定の接続で双方向に交換されるすべてのパケットを監視すると想定してパス上にデプロイされたミドルボックスが正しく機能しなくなる可能性があることを意味します。典型的な例は、ファイアウォール、侵入検知システム（IDS）、エンタープライズネットワークに展開されたディープパケットインスペクション（DPI）です。これらのデバイスは、すべてのTCP接続からのすべてのパケットを監視することを期待しています。マルチパスTCPでは、一部のパケットが別のパスをたどる可能性があるため、これらのミドルボックスはすべてのパケットを監視しない場合があります。以下の2つの例は、このようなミドルボックスの典型的なデプロイメントを示しています。最初の例である図8は、企業ネットワークとセルラーネットワークの両方に接続されたMPTCP対応のスマートフォンを示しています。スマートフォンによってサーバーに向けてマルチパスTCP接続が確立されると、スマートフォンまたはサーバーによって送信されたパケットの一部がセルラーネットワーク経由で送信され、エンタープライズミドルボックスから見えなくなる場合があります。
smartphone +----- enterprise net --- MBox----+------ server
| |
+----- cellular net -------------+
Figure 8: Enterprise Middlebox May Not Observe All Packets from Multihomed Host
図8：Enterprise Middleboxがマルチホームホストからのすべてのパケットを監視しない場合がある
The second example, Figure 9, shows a possible issue when multiple middleboxes are deployed inside a network. For simplicity, we assume that network1 is the default IPv4 path while network2 is the default IPv6 path. A similar issue could occur with per-flow load-balancing such as ECMP [RFC2992]. With regular TCP, all packets from each connection would either pass through Mbox1 or Mbox2. With Multipath TCP, the client can easily establish a subflow over network1 and another over network2 and each middlebox would only observe a part of the traffic of the end-to-end Multipath TCP connection.
2番目の例である図9は、ネットワーク内に複数のミドルボックスがデプロイされている場合に発生する可能性のある問題を示しています。簡単にするために、network1がデフォルトのIPv4パスであり、network2がデフォルトのIPv6パスであると想定します。 ECMP [RFC2992]などのフローごとのロードバランシングでも同様の問題が発生する可能性があります。通常のTCPでは、各接続からのすべてのパケットがMbox1またはMbox2を通過します。マルチパスTCPを使用すると、クライアントはnetwork1とnetwork2を介してサブフローを簡単に確立でき、各ミドルボックスはエンドツーエンドマルチパスTCP接続のトラフィックの一部のみを監視します。
client ----R-- network1 --- MBox1 -----R------------- server
| |
+-- network2 --- MBox2 -----+
Figure 9: Interactions between Load-Balancing and Security Middleboxes
図9：ロードバランシングとセキュリティミドルボックス間の相互作用
In these two cases, it is possible for an attacker to evade some security measures operating on the TCP byte stream and implemented on the middleboxes by controlling the bytes that are actually sent over each subflow and there are tools that ease those kinds of evasion [PZ15] [PT14]. This is not a security issue for Multipath TCP itself
これら2つのケースでは、攻撃者がTCPバイトストリームで動作し、ミドルボックスに実装されたセキュリティ対策を回避して、各サブフローで実際に送信されるバイトを制御することが可能であり、そのような種類の回避を容易にするツールがあります[PZ15 ] [PT14]。これはマルチパスTCP自体のセキュリティ問題ではありません
since Multipath TCP behaves correctly. However, this demonstrates the difficulty of enforcing security policies by relying only on on-path middleboxes instead of enforcing them directly on the endpoints.
マルチパスTCPが正しく動作するためです。ただし、これは、エンドポイントに直接適用するのではなく、パス上のミドルボックスのみに依存することによってセキュリティポリシーを適用することの難しさを示しています。
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, <http://www.rfc-editor.org/info/rfc6182>.
[RFC6182] Ford、A.、Raiciu、C.、Handley、M.、Barre、S.、J。Iyengar、「マルチパスTCP開発のアーキテクチャガイドライン」、RFC 6182、DOI 10.17487 / RFC6182、2011年3月、<http ：//www.rfc-editor.org/info/rfc6182>。
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <http://www.rfc-editor.org/info/rfc6824>.
[RFC6824] Ford、A.、Raiciu、C.、Handley、M。、およびO. Bonaventure、「複数のアドレスを持つマルチパス操作のためのTCP拡張機能」、RFC 6824、DOI 10.17487 / RFC6824、2013年1月、<http：// www.rfc-editor.org/info/rfc6824>。
[BALIA] Peng, Q., Walid, A., Hwang, J., and S. Low, "Multipath TCP: analysis, design, and implementation", IEEE/ACM Trans. on Networking (TON), Volume 24, Issue 1, February 2016.
[BALIA] Peng、Q.、Walid、A.、Hwang、J。、およびS. Low、「マルチパスTCP：分析、設計、および実装」、IEEE / ACM Trans。 on Networking（TON）、Volume 24、Issue 1、2016年2月。
[CACM14] Paasch, C. and O. Bonaventure, "Multipath TCP", Communications of the ACM, 57(4):51-57, April 2014, <http://inl.info.ucl.ac.be/publications/multipath-tcp>.
[CACM14] Paasch、C。およびO. Bonaventure、「Multipath TCP」、Communications of the ACM、57（4）：51-57、2014年4月、<http://inl.info.ucl.ac.be/publications / multipath-tcp>。
[Cellnet12] Paasch, C., Detal, G., Duchene, F., Raiciu, C., and O. Bonaventure, "Exploring Mobile/WiFi Handover with Multipath TCP", ACM SIGCOMM workshop on Cellular Networks (Cellnet12), August 2012, <http://inl.info.ucl.ac.be/publications/ exploring-mobilewifi-handover-multipath-tcp>.
[Cellnet12] Paasch、C.、Detal、G.、Duchene、F.、Raiciu、C。、およびO. Bonaventure、「Exploring Mobile / WiFi Handover with Multipath TCP」、ACM SIGCOMM Workshop on Cellular Networks（Cellnet12）、8月2012、<http://inl.info.ucl.ac.be/publications/exploring-mobilewifi-handover-multipath-tcp>。
[COMCOM2016] Tran, V., De Coninck, Q., Hesmans, B., Sadre, R., and O. Bonaventure, "Observing real Multipath TCP traffic", Computer Communications, DOI 10.1016/j.comcom.2016.01.014, April 2016, <http://inl.info.ucl.ac.be/publications/ observing-real-multipath-tcp-traffic>.
[COMCOM2016] Tran、V.、De Coninck、Q.、Hesmans、B.、Sadre、R.、and O. Bonaventure、 "Observing real multipath TCP traffic"、Computer Communications、DOI 10.1016 / j.comcom.2016.01.014 、2016年4月、<http://inl.info.ucl.ac.be/publications/ observing-real-multipath-tcp-traffic>。
[COMMAG2016] De Coninck, Q., Baerts, M., Hesmans, B., and O. Bonaventure, "Observing Real Smartphone Applications over Multipath TCP", IEEE Communications Magazine Network Testing Series, 54(3), March 2016, <http://inl.info.ucl.ac.be/publications/observing-real-smartphone-applications-over-multipath-tcp>.
[COMMAG2016] De Coninck、Q.、Baerts、M.、Hesmans、B.、and O. Bonaventure、 "Observing Real Smartphone Applications over Multipath TCP"、IEEE Communications Magazine Network Testing Series、54（3）、March 2016、< http://inl.info.ucl.ac.be/publications/observing-real-smartphone-applications-over-multipath-tcp>。
[CONEXT12] Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J. Leboudec, "MPTCP is not Pareto-Optimal: Performance Issues and a Possible Solution", CoNEXT '12: Proceedings of the 8th international conference on Emerging networking experiments and technologies, DOI 10.1145/2413176.2413178, December 2012.
[CONEXT12] Khalili、R.、Gast、N.、Popovic、M.、Upadhyay、U、およびJ. Leboudec、「MPTCPはパレート最適ではありません：パフォーマンスの問題と可能な解決策」、CoNEXT '12：Proceedings of新たなネットワーク実験と技術に関する第8回国際会議、DOI 10.1145 / 2413176.2413178、2012年12月。
[CONEXT13] Paasch, C., Khalili, R., and O. Bonaventure, "On the Benefits of Applying Experimental Design to Improve Multipath TCP", Conference on emerging Networking EXperiments and Technologies (CoNEXT), DOI 10.1145/2535372.2535403, December 2013, <http://inl.info.ucl.ac.be/publications/benefits-applying-experimental-design-improve-multipath-tcp>.
[CONEXT13] Paasch、C.、Khalili、R。、およびO. Bonaventure、「実験的設計を適用してマルチパスTCPを改善する利点について」、新興のネットワーク実験およびテクノロジーに関する会議（CoNEXT）、DOI 10.1145 / 2535372.2535403、2013年12月、<http://inl.info.ucl.ac.be/publications/benefits-applying-experimental-design-improve-multipath-tcp>。
[CONEXT15] Hesmans, B., Detal, G., Barre, S., Bauduin, R., and O. Bonaventure, "SMAPP: Towards Smart Multipath TCP-enabled APPlications", Proc. Conext 2015, Heidelberg, Germany, December 2015, <http://inl.info.ucl.ac.be/publications/ smapp-towards-smart-multipath-tcp-enabled-applications>.
[CONEXT15] Hesmans、B.、Detal、G.、Barre、S.、Bauduin、R。、およびO. Bonaventure、「SMAPP：Towards Multi Multipath TCP-enabled APPlications」、Proc。 Conext 2015、ドイツ、ハイデルベルク、2015年12月、<http://inl.info.ucl.ac.be/publications/ smapp-towards-smart-multipath-tcp-enabled-applications>。
[CSWS14] Paasch, C., Ferlin, S., Alay, O., and O. Bonaventure, "Experimental evaluation of multipath TCP schedulers", CSWS '14: Proceedings of the 2014 ACM SIGCOMM workshop on Capacity sharing workshop, DOI 10.1145/2630088.2631977, August 2014.
[CSWS14] Paasch、C.、Ferlin、S.、Alay、O。、およびO. Bonaventure、「マルチパスTCPスケジューラーの実験的評価」、CSWS '14：容量共有ワークショップに関する2014 ACM SIGCOMMワークショップの議事録、DOI 10.1145 /2630088.2631977、2014年8月。
[DetalMSS] Detal, G., "dynamically adapt mss value", Post on the mptcp-dev mailing list, September 2014, <https://listes-2.sipr.ucl.ac.be/sympa/arc/mptcp-dev/ 2014-09/msg00130.html>.
[DetalMSS] Detal、G。、「動的にmss値を適合させる」、mptcp-devメーリングリストに投稿、2014年9月、<https://listes-2.sipr.ucl.ac.be/sympa/arc/mptcp- dev / 2014-09 / msg00130.html>。
[FreeBSD-MPTCP] Williams, N., "Multipath TCP For FreeBSD Kernel Patch v0.5", <http://caia.swin.edu.au/urp/newtcp/mptcp>.
[FreeBSD-MPTCP]ウィリアムズ、N。、「FreeBSDカーネルパッチv0.5のマルチパスTCP」、<http://caia.swin.edu.au/urp/newtcp/mptcp>。
[GRE-NOTIFY] Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M. Zhang, "GRE Notifications for Hybrid Access", Work in Progress, draft-lhwxz-gre-notifications-hybrid-access-01, January 2015.
[GRE-NOTIFY] Leymann、N.、Heidemann、C.、Wasserman、M.、Xue、L。、およびM. Zhang、「ハイブリッドアクセスのGRE通知」、作業中、draft-lhwxz-gre-notifications- hybrid-access-01、2015年1月。
[HAMPEL] Hampel, G., Rana, A., and T. Klein, "Seamless TCP mobility using lightweight MPTCP proxy", MobiWac '13: Proceedings of the 11th ACM international symposium on Mobility management and wireless access, DOI 10.1145/2508222.2508226, November 2013.
[HAMPEL] Hampel、G.、Rana、A。、およびT. Klein、「軽量MPTCPプロキシを使用したシームレスなTCPモビリティ」、MobiWac '13：モビリティ管理およびワイヤレスアクセスに関する第11回ACM国際シンポジウムの議事録、DOI 10.1145 / 2508222.2508226 、 2013年11月。
[HotMiddlebox13] Hesmans, B., Duchene, F., Paasch, C., Detal, G., and O. Bonaventure, "Are TCP Extensions Middlebox-proof?", CoNEXT workshop Hot Middlebox, December 2013, <http://inl.info.ucl.ac.be/publications/ are-tcp-extensions-middlebox-proof>.
[HotMiddlebox13] Hesmans、B.、Duchene、F.、Paasch、C.、Detal、G。、およびO. Bonaventure、「Are TCP Extensions Middlebox-proof？」、CoNEXTワークショップHot Middlebox、2013年12月、<http：/ /inl.info.ucl.ac.be/publications/ are-tcp-extensions-middlebox-proof>。
[HotMiddlebox13b] Detal, G., Paasch, C., and O. Bonaventure, "Multipath in the Middle(Box)", HotMiddlebox '13, December 2013, <http://inl.info.ucl.ac.be/publications/ multipath-middlebox>.
[HotMiddlebox13b] Detal、G.、Paasch、C.、O。Bonaventure、「Multipath in the Middle（Box）」、HotMiddlebox '13、2013年12月、<http://inl.info.ucl.ac.be/ publications / multipath-middlebox>。
[HotNets] Raiciu, C., Pluntke, C., Barre, S., Greenhalgh, A., Wischik, D., and M. Handley, "Data center networking with multipath TCP", Hotnetx-IX: Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks Article No. 10, DOI 10.1145/1868447.1868457, October 2010, <http://doi.acm.org/10.1145/1868447.1868457>.
[HotNets] Raiciu、C.、Pluntke、C.、Barre、S.、Greenhalgh、A.、Wischik、D。、およびM. Handley、「マルチパスTCPによるデータセンターネットワーキング」、Hotnetx-IX：第9回議事録ACM SIGCOMM Workshop on Hot Topics on Networks Article No.10、DOI 10.1145 / 1868447.1868457、2010年10月、<http://doi.acm.org/10.1145/1868447.1868457>。
[HYA-ARCH] Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M. Zhang, "Hybrid Access Network Architecture", Work in Progress, draft-lhwxz-hybrid-access-network-architecture-02, January 2015.
[HYA-ARCH] Leymann、N.、Heidemann、C.、Wasserman、M.、Xue、L。、およびM. Zhang、「ハイブリッドアクセスネットワークアーキテクチャ」、Work in Progress、draft-lhwxz-hybrid-access-network -architecture-02、2015年1月。
[ICNP12] Cao, Y., Xu, M., and X. Fu, "Delay-based congestion control for multipath TCP", 20th IEEE International Conference on Network Protocols (INCP), DOI 10.1109/ICNP.2012.6459978, October 2012.
[ICNP12] Cao、Y.、Xu、M。、およびX. Fu、「マルチパスTCPの遅延ベースの輻輳制御」、第20回ネットワークプロトコルに関するIEEE国際会議（INCP）、DOI 10.1109 / ICNP.2012.6459978、2012年10月。
[IETF88] Stewart, L., "IETF 88 Meeting minutes of the MPTCP working group", November 2013, <https://www.ietf.org/proceedings/ 88/minutes/minutes-88-mptcp>.
[IETF88]スチュワートL。、「MPTCPワーキンググループのIETF 88会議議事録」、2013年11月、<https://www.ietf.org/proceedings/ 88 / minutes / minutes-88-mptcp>。
[IETFJ] Bonaventure, O. and S. Seo, "Multipath TCP Deployments", IETF Journal, Vol. 12, Issue 2, November 2016.
[IETFJ] Bonaventure、O。およびS. Seo、「Multipath TCP Deployments」、IETF Journal、Vol。 12、問題2、2016年11月。
[IMC11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M., and H. Tokuda, "Is it still possible to extend TCP?", IMC '11: Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference, DOI 10.1145/2068816.2068834, November 2011, <http://doi.acm.org/10.1145/2068816.2068834>.
[IMC11]ホンダM.、西田Y.、ライシウC.、Greenhalgh、A.、Handley、M。、およびH.徳田、「TCPを拡張することはまだ可能ですか？」、IMC '11：Proceedings ofインターネット測定会議に関する2011 ACM SIGCOMM会議、DOI 10.1145 / 2068816.2068834、2011年11月、<http://doi.acm.org/10.1145/2068816.2068834>。
[IMC13a] Detal, G., Hesmans, B., Bonaventure, O., Vanaubel, Y., and B. Donnet, "Revealing Middlebox Interference with Tracebox", Proceedings of the 2013 ACM SIGCOMM conference on Internet measurement conference, DOI 10.1145/2504730.2504757, October 2013, <http://inl.info.ucl.ac.be/publications/ revealing-middlebox-interference-tracebox>.
[IMC13a] Detal、G.、Hesmans、B.、Bonaventure、O.、Vanaubel、Y。、およびB. Donnet、「Revealing Middlebox Interference with Tracebox」、Proceedings of the 2013 ACM SIGCOMM Conference on Internet Measurement Conference、DOI 10.1145 /2504730.2504757、2013年10月、<http://inl.info.ucl.ac.be/publications/ appearing-middlebox-interference-tracebox>。
[IMC13b] Chen, Y., Lim, Y., Gibbens, R., Nahum, E., Khalili, R., and D. Towsley, "A measurement-based study of MultiPath TCP performance over wireless network", ICM '13: Proceedings of the 2013 conference on Internet measurement conference, DOI 10.1145/2504730.2504751, October 2013, <http://doi.acm.org/10.1145/2504730.2504751>.
[IMC13b] Chen、Y.、Lim、Y.、Gibbens、R.、Nahum、E.、Khalili、R。、およびD. Towsley、「ワイヤレスネットワーク上のマルチパスTCPパフォーマンスの測定ベースの研究」、ICM 13：2013年のインターネット測定会議に関する会議の議事録、DOI 10.1145 / 2504730.2504751、2013年10月、<http://doi.acm.org/10.1145/2504730.2504751>。
[IMC13c] Pelsser, C., Cittadini, L., Vissicchio, S., and R. Bush, "From Paris to Tokyo: on the suitability of ping to measure latency", IMC '13: Proceedings of the 2013 conference on Internet measurement Conference, DOI 10.1145/2504730.2504765, October 2013, <http://doi.acm.org/10.1145/2504730.2504765>.
[IMC13c] Pelsser、C.、Cittadini、L.、Vissicchio、S。、およびR. Bush、「パリから東京へ：遅延を測定するためのpingの適切性について」、IMC '13：インターネットでの2013年会議の議事録測定会議、DOI 10.1145 / 2504730.2504765、2013年10月、<http://doi.acm.org/10.1145/2504730.2504765>。
[INFOCOM14] Lim, Y., Chen, Y., Nahum, E., Towsley, D., and K. Lee, "Cross-layer path management in multi-path transport protocol for mobile devices", IEEE INFOCOM'14, DOI 10.1109/INFOCOM.2014.6848120, April 2014.
[INFOCOM14] Lim、Y.、Chen、Y.、Nahum、E.、Towsley、D.、and K. Lee、 "Cross-layer path management in multi-path transport protocol for mobile devices"、IEEE INFOCOM'14、 DOI 10.1109 / INFOCOM.2014.6848120、2014年4月。
[KT] Seo, S., "KT's GiGA LTE", July 2015, <https://www.ietf.org/proceedings/93/slides/ slides-93-mptcp-3.pdf>.
「ＫＴ」 せお、 Ｓ。、 ”ＫＴ’ｓ ぎが Ｌて”、 じゅｌｙ ２０１５、 ＜ｈっｔｐｓ：／／ｗっｗ。いえｔｆ。おｒｇ／ｐろせえぢんｇｓ／９３／ｓぃでｓ／ ｓぃでｓー９３ーｍｐｔｃｐー３。ｐｄｆ＞。
[MBTest] Hesmans, B., "MBTest", October 2013, <https://bitbucket.org/bhesmans/mbtest>.
[MBTest] Hesmans、B。、「MBTest」、2013年10月、<https://bitbucket.org/bhesmans/mbtest>。
[Mobicom15] De Coninck, Q., Baerts, M., Hesmans, B., and O. Bonaventure, "Poster - Evaluating Android Applications with Multipath TCP", Mobicom 2015 (Poster), DOI 10.1145/2789168.2795165, September 2015.
[Mobicom15] De Coninck、Q.、Baerts、M.、Hesmans、B。、およびO. Bonaventure、「Poster-Evaluating Android Applications with Multipath TCP」、Mobicom 2015（Poster）、DOI 10.1145 / 2789168.2795165、2015年9月。
[MPTCP-DEPLOY] Paasch, C., Biswas, A., and D. Haas, "Making Multipath TCP robust for stateless webservers", Work in Progress, draft-paasch-mptcp-syncookies-02, October 2015.
[MPTCP-DEPLOY] Paasch、C.、Biswas、A。、およびD. Haas、「ステートレスWebサーバーに対してマルチパスTCPを堅牢にする」、作業中、draft-paasch-mptcp-syncookies-02、2015年10月。
[MPTCP-LOAD] Paasch, C., Greenway, G., and A. Ford, "Multipath TCP behind Layer-4 loadbalancers", Work in Progress, draft-paasch-mptcp-loadbalancer-00, September 2015.
[MPTCP-LOAD] Paasch、C.、Greenway、G。、およびA. Ford、「レイヤー4ロードバランサーの背後にあるマルチパスTCP」、作業中、draft-paasch-mptcp-loadbalancer-00、2015年9月。
[MPTCP-MAX-SUB] Boucadair, M. and C. Jacquenet, "Negotiating the Maximum Number of Multipath TCP (MPTCP) Subflows", Work in Progress draft-boucadair-mptcp-max-subflow-02, May 2016.
[MPTCP-MAX-SUB] Boucadair、M。、およびC. Jacquenet、「マルチパスTCP（MPTCP）サブフローの最大数のネゴシエーション」、Work in Progress draft-boucadair-mptcp-max-subflow-02、2016年5月。
[MPTCPBIB] Bonaventure, O., "Multipath TCP - Annotated bibliography", Technical report, April 2015, <https://github.com/obonaventure/mptcp-bib>.
[MPTCPBIB] Bonaventure、O。、「Multipath TCP-Annotated bibliography」、テクニカルレポート、2015年4月、<https://github.com/obonaventure/mptcp-bib>。
[MultipathTCP-Linux] Paasch, C., Barre, S., and . et al, "Multipath TCP - Linux Kernel implementation", <http://www.multipath-tcp.org>.
[MultipathTCP-Linux] Paasch、C.、Barre、S。、および。他、「マルチパスTCP-Linuxカーネル実装」、<http://www.multipath-tcp.org>。
[NSDI11] Wischik, D., Raiciu, C., Greenhalgh, A., and M. Handley, "Design, implementation and evaluation of congestion control for multipath TCP", NSDI11: In Proceedings of the 8th USENIX conference on Networked systems design and implementation, 2011.
[NSDI11] Wischik、D.、Raiciu、C.、Greenhalgh、A。、およびM. Handley、「マルチパスTCPの輻輳制御の設計、実装、および評価」、NSDI11：ネットワークシステム設計に関する第8回USENIX会議の議事録と実装、2011。
[NSDI12] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M., Duchene, F., Bonaventure, O., and M. Handley, "How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP", NSDI '12: USENIX Symposium of Networked Systems Design and implementation, April 2012, <http://inl.info.ucl.ac.be/publications/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp>.
[NSDI12] Raiciu、C.、Paasch、C.、Barre、S.、Ford、A.、Honda、M.、Duchene、F.、Bonaventure、O。、およびM. Handley、「どれほど難しいのでしょうか。展開可能なマルチパスTCPの設計と実装」、NSDI '12：ネットワークシステムの設計と実装のUSENIXシンポジウム、2012年4月、<http://inl.info.ucl.ac.be/publications/how-hard-can-it- be-designing-and-implementing-deployable-multipath-tcp>。
[PaaschPhD] Paasch, C., "Improving Multipath TCP", Ph.D. Thesis , November 2014, <http://inl.info.ucl.ac.be/publications/ improving-multipath-tcp>.
[PaaschPhD] Paasch、C。、「Improving Multipath TCP」、Ph.D。論文、2014年11月、<http://inl.info.ucl.ac.be/publications/ Improvement-multipath-tcp>。
[PAM2016] De Coninck, Q., Baerts, M., Hesmans, B., and O. Bonaventure, "A First Analysis of Multipath TCP on Smartphones", 17th International Passive and Active Measurements Conference (PAM2016) volume 17, March 2016, <http://inl.info.ucl.ac.be/publications/ first-analysis-multipath-tcp-smartphones>.
[PAM2016] De Coninck、Q.、Baerts、M.、Hesmans、B.、and O. Bonaventure、 "A First Analysis of Multipath TCP on Smartphones"、17th International Passive and Active Measurements Conference（PAM2016）volume 17、March 2016 、<http://inl.info.ucl.ac.be/publications/ first-analysis-multipath-tcp-smartphones>。
[PAMS2014] Arzani, B., Gurney, A., Cheng, S., Guerin, R., and B. Loo, "Impact of Path Selection and Scheduling Policies on MPTCP Performance", PAMS2014, DOI 10.1109/WAINA.2014.121, May 2014.
[PAMS2014] Arzani、B.、Gurney、A.、Cheng、S.、Guerin、R。、およびB. Loo、「MPTCPパフォーマンスへのパス選択とスケジューリングポリシーの影響」、PAMS2014、DOI 10.1109 / WAINA.2014.121、 2014年5月。
[Presto08] Greenberg, A., Lahiri, P., Maltz, D., Patel, P., and S. Sengupta, "Towards a next generation data center architecture: scalability and commoditization", ACM PRESTO 2008, DOI 10.1145/1397718.1397732, August 2008, <http://dl.acm.org/citation.cfm?id=1397732>.
[Presto08] Greenberg、A.、Lahiri、P.、Maltz、D.、Patel、P。、およびS. Sengupta、「次世代のデータセンターアーキテクチャに向けて：スケーラビリティとコモディティ化」、ACM PRESTO 2008、DOI 10.1145 / 1397718.1397732 、2008年8月、<http://dl.acm.org/citation.cfm?id=1397732>。
[PT14] Pearce, C. and P. Thomas, "Multipath TCP Breaking Today's Networks with Tomorrow's Protocols", Proc. Blackhat Briefings, 2014, <http://www.blackhat.com/docs/ us-14/materials/us-14-Pearce-Multipath-TCP-Breaking-Todays-Networks-With-Tomorrows-Protocols-WP.pdf>.
[PT14]ピアース、C。およびP.トーマス、「マルチパスTCPが明日のプロトコルで今日のネットワークを壊す」、Proc。 Blackhat Briefings、2014、<http://www.blackhat.com/docs/ us-14 / materials / us-14-Pearce-Multipath-TCP-Breaking-Todays-Networks-With-Tomorrows-Protocols-WP.pdf> 。
[PZ15] Pearce, C. and S. Zeadally, "Ancillary Impacts of Multipath TCP on Current and Future Network Security", IEEE Internet Computing, vol. 19, no. 5, pp. 58-65, DOI 10.1109/MIC.2015.70, September 2015.
[PZ15] Pearce、C。およびS. Zeadally、「現在および将来のネットワークセキュリティに対するマルチパスTCPの補助的な影響」、IEEE Internet Computing、vol。 19、いいえ。 5、58-65ページ、DOI 10.1109 / MIC.2015.70、2015年9月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <http://www.rfc-editor.org/info/rfc1812>.
[RFC1812]ベイカー、F。、編、「IPバージョン4ルーターの要件」、RFC 1812、DOI 10.17487 / RFC1812、1995年6月、<http://www.rfc-editor.org/info/rfc1812>。
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, DOI 10.17487/RFC1928, March 1996, <http://www.rfc-editor.org/info/rfc1928>.
[RFC1928] Leech、M.、Ganis、M.、Lee、Y.、Kuris、R.、Koblas、D。、およびL. Jones、「SOCKS Protocol Version 5」、RFC 1928、DOI 10.17487 / RFC1928、1996年3月、<http://www.rfc-editor.org/info/rfc1928>。
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, <http://www.rfc-editor.org/info/rfc2992>.
[RFC2992] Hopps、C。、「Analysis of an Equal-Cost Multi-Path Algorithm」、RFC 2992、DOI 10.17487 / RFC2992、2000年11月、<http://www.rfc-editor.org/info/rfc2992>。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, <http://www.rfc-editor.org/info/rfc4987>.
[RFC4987] Eddy、W。、「TCP SYN Flooding Attacks and Common Mitigations」、RFC 4987、DOI 10.17487 / RFC4987、2007年8月、<http://www.rfc-editor.org/info/rfc4987>。
[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, DOI 10.17487/RFC6356, October 2011, <http://www.rfc-editor.org/info/rfc6356>.
[RFC6356] Raiciu、C.、Handley、M。、およびD. Wischik、「マルチパストランスポートプロトコルの結合された輻輳制御」、RFC 6356、DOI 10.17487 / RFC6356、2011年10月、<http：//www.rfc-editor。 org / info / rfc6356>。
[RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. Raiciu, "Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)", RFC 7430, DOI 10.17487/RFC7430, July 2015, <http://www.rfc-editor.org/info/rfc7430>.
[RFC7430] Bagnulo、M.、Paasch、C.、Gont、F.、Bonaventure、O。、およびC. Raiciu、「Analysis of Residual Threats and Potible Fix for Multipath TCP（MPTCP）」、RFC 7430、DOI 10.17487 / RFC7430、2015年7月、<http://www.rfc-editor.org/info/rfc7430>。
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, <http://www.rfc-editor.org/info/rfc7871>.
[RFC7871] Contavalli、C.、van der Gaast、W.、Lawrence、D。、およびW. Kumari、「DNSクエリのクライアントサブネット」、RFC 7871、DOI 10.17487 / RFC7871、2016年5月、<http：// www .rfc-editor.org / info / rfc7871>。
[SIGCOMM11] Raiciu, C., Barre, S., Pluntke, C., Greenhalgh, A., Wischik, D., and M. Handley, "Improving datacenter performance and robustness with multipath TCP", SIGCOMM '11: Proceedings of the ACM SIGCOMM 2011 conference, DOI 10.1145/2018436.2018467, August 2011, <http://doi.acm.org/10.1145/2018436.2018467>.
[SIGCOMM11] Raiciu、C.、Barre、S.、Pruntke、C.、Greenhalgh、A.、Wischik、D。、およびM. Handley、「マルチパスTCPによるデータセンターのパフォーマンスと堅牢性の向上」、SIGCOMM '11：Proceedings of ACM SIGCOMM 2011カンファレンス、DOI 10.1145 / 2018436.2018467、2011年8月、<http://doi.acm.org/10.1145/2018436.2018467>。
[SOCKET] Hesmans, B. and O. Bonaventure, "An enhanced socket API for Multipath TCP", Proceedings of the 2016 Applied Networking Research Workshop, DOI 10.1145/2959424.2959433, July 2016, <http://doi.acm.org/10.1145/2959424.2959433>.
[ソケット] Hesmans、B。およびO. Bonaventure、「マルチパスTCP用の拡張ソケットAPI」、2016 Applied Networking Research Workshopの議事録、DOI 10.1145 / 2959424.2959433、2016年7月、<http://doi.acm.org/ 10.1145 / 2959424.2959433>。
[StrangeMbox] Bonaventure, O., "Multipath TCP through a strange middlebox", Blog post, January 2015, <http://blog.multipath-tcp.org/blog/html/2015/01/30/ multipath_tcp_through_a_strange_middlebox.html>.
[StrangeMbox] Bonaventure、O。、「奇妙なミドルボックスを介したマルチパスTCP」、ブログ投稿、2015年1月、<http://blog.multipath-tcp.org/blog/html/2015/01/30/ multipath_tcp_through_a_strange_middlebox.html> 。
[TMA2015] Hesmans, B., Tran Viet, H., Sadre, R., and O. Bonaventure, "A First Look at Real Multipath TCP Traffic", Traffic Monitoring and Analysis, 2015, <http://inl.info.ucl.ac.be/publications/ first-look-real-multipath-tcp-traffic>.
[TMA2015] Hesmans、B.、Tran Viet、H.、Sadre、R。、およびO. Bonaventure、「A Real Look at Real Multipath TCP Traffic」、Traffic Monitoring and Analysis、2015、<http://inl.info .ucl.ac.be / publications / first-look-real-multipath-tcp-traffic>。
[TR-348] Broadband Forum, ., "TR 348 - Hybrid Access Broadband Network Architecture", Issue: 1, July 2016, <https://www.broadband-forum.org/technical/download/ TR-348.pdf>.
[TR-348]ブロードバンドフォーラム、。、「TR 348-ハイブリッドアクセスブロードバンドネットワークアーキテクチャ」、問題：2016年7月1日、<https://www.broadband-forum.org/technical/download/ TR-348.pdf >。
[tracebox] Detal, G. and O. Tilmans, "Tracebox: A Middlebox Detection Tool", 2013, <http://www.tracebox.org>.
[tracebox] Detal、G。およびO. Tilmans、「Tracebox：A Middlebox Detection Tool」、2013、<http://www.tracebox.org>。
Acknowledgements
謝辞
This work was partially supported by the FP7-Trilogy2 project. We would like to thank all the implementers and users of the Multipath TCP implementation in the Linux kernel. This document has benefited from the comments of John Ronan, Yoshifumi Nishida, Phil Eardley, Jaehyun Hwang, Mirja Kuehlewind, Benoit Claise, Jari Arkko, Qin Wu, Spencer Dawkins, and Ben Campbell.
この作品は、FP7-Trilogy2プロジェクトによって部分的にサポートされていました。 LinuxカーネルでのマルチパスTCP実装のすべての実装者とユーザーに感謝します。このドキュメントは、John Ronan、Nishida Yoshifumi、Phil Eardley、Jaehyun Hwang、Mirja Kuehlewind、Benoit Claise、Jari Arkko、Qin Wu、Spencer Dawkins、およびBen Campbellのコメントの恩恵を受けています。
Authors' Addresses
著者のアドレス
Olivier Bonaventure UCLouvain
オリビエボナベンチャーUCLouvain
Email: Olivier.Bonaventure@uclouvain.be
Christoph Paasch Apple, Inc.
Christoph Paasch Apple、Inc.
Email: cpaasch@apple.com
Gregory Detal Tessares
クイックディタルフォー
Email: Gregory.Detal@tessares.net