[要約] RFC 6182は、Multipath TCP（MPTCP）の開発におけるアーキテクチャガイドラインを提供するものであり、MPTCPの設計と実装に関する指針を提供します。その目的は、MPTCPの効果的な開発と展開を支援し、ネットワークのパフォーマンスと信頼性を向上させることです。
Internet Engineering Task Force (IETF) A. Ford
Request for Comments: 6182 Roke Manor Research
Category: Informational C. Raiciu
ISSN: 2070-1721 M. Handley
University College London
S. Barre
Universite catholique de Louvain
J. Iyengar
Franklin and Marshall College
March 2011
Architectural Guidelines for Multipath TCP Development
マルチパスTCP開発のための建築ガイドライン
Abstract
概要
Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput.
ホストは多くの場合、複数のパスで接続されますが、TCPは通信を輸送接続ごとに単一のパスに制限します。ネットワーク内のリソースの使用は、これらの複数のパスを同時に使用できる場合、より効率的になります。これにより、ネットワークの障害に対する回復力の向上とスループットの向上により、ユーザーエクスペリエンスが向上するはずです。
This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of a Multipath TCP (MPTCP). This document lists certain high-level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements.
このドキュメントでは、マルチパスTCP（MPTCP）の開発でこれらのアーキテクチャコンポーネントがどのように一緒になっているかについての言及とともに、マルチパス輸送プロトコルの開発に関するアーキテクチャガイドラインの概要を説明しています。このドキュメントには、これらのアーキテクチャの要件に基づいて、MPTCPプロトコルの設計の基礎を提供する特定の高レベルの設計決定がリストされています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6182.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6182で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Requirements Language ......................................5
1.2. Terminology ................................................5
1.3. Reference Scenario .........................................6
2. Goals ...........................................................6
2.1. Functional Goals ...........................................6
2.2. Compatibility Goals ........................................7
2.2.1. Application Compatibility ...........................7
2.2.2. Network Compatibility ...............................8
2.2.3. Compatibility with Other Network Users .............10
2.3. Security Goals ............................................10
2.4. Related Protocols .........................................10
3. An Architectural Basis for Multipath TCP .......................11
4. A Functional Decomposition of MPTCP ............................12
5. High-Level Design Decisions ....................................14
5.1. Sequence Numbering ........................................14
5.2. Reliability and Retransmissions ...........................15
5.3. Buffers ...................................................17
5.4. Signaling .................................................18
5.5. Path Management ...........................................19
5.6. Connection Identification .................................20
5.7. Congestion Control ........................................21
5.8. Security ..................................................21
6. Software Interactions ..........................................23
6.1. Interactions with Applications ............................23
6.2. Interactions with Management Systems ......................23
7. Interactions with Middleboxes ..................................23
8. Contributors ...................................................25
9. Acknowledgements ...............................................25
10. Security Considerations .......................................26
11. References ....................................................26
11.1. Normative References .....................................26
11.2. Informative References ...................................26
As the Internet evolves, demands on Internet resources are ever-increasing, but often these resources (in particular, bandwidth) cannot be fully utilized due to protocol constraints both on the end-systems and within the network. If these resources could be used concurrently, end user experience could be greatly improved. Such enhancements would also reduce the necessary expenditure on network infrastructure that would otherwise be needed to create an equivalent improvement in user experience. By the application of resource pooling [3], these available resources can be 'pooled' such that they appear as a single logical resource to the user.
インターネットが進化するにつれて、インターネットリソースに対する需要は増え続けていますが、多くの場合、これらのリソース（特に帯域幅）は、エンドシステムとネットワーク内のプロトコルの制約のために完全に利用できません。これらのリソースを同時に使用できれば、エンドユーザーエクスペリエンスが大幅に改善される可能性があります。このような強化は、ユーザーエクスペリエンスに同等の改善をもたらすために必要なネットワークインフラストラクチャへの必要な支出を減らすこともできます。リソースプーリング[3]を適用することにより、これらの利用可能なリソースは、ユーザーに単一の論理リソースとして表示されるように「プール」できます。
Multipath transport aims to realize some of the goals of resource pooling by simultaneously making use of multiple disjoint (or partially disjoint) paths across a network. The two key benefits of multipath transport are the following:
MultiPath Transportは、ネットワークを横切る複数のバラバラ（または部分的に否定）パスを同時に使用することにより、リソースプーリングの目標の一部を実現することを目的としています。マルチパス輸送の2つの重要な利点は次のとおりです。
o To increase the resilience of the connectivity by providing multiple paths, protecting end hosts from the failure of one.
o 複数のパスを提供することにより、接続性の回復力を高め、エンドホストを1つの障害から保護します。
o To increase the efficiency of the resource usage, and thus increase the network capacity available to end hosts.
o リソース使用量の効率を高め、ホストを終了するために利用可能なネットワーク容量を増やすため。
Multipath TCP is a modified version of TCP [1] that implements a multipath transport and achieves these goals by pooling multiple paths within a transport connection, transparently to the application. Multipath TCP is primarily concerned with utilizing multiple paths end-to-end, where one or both of the end hosts are multihomed. It may also have applications where multiple paths exist within the network and can be manipulated by an end host, such as using different port numbers with Equal Cost MultiPath (ECMP) [4].
MultiPath TCPは、TCP [1]の修正バージョンであり、マルチパストランスポートを実装し、輸送接続内の複数のパスをアプリケーションに透過的にプールすることにより、これらの目標を達成します。MultiPath TCPは、主にエンドツーエンドの複数のパスを利用することに関係しています。ここでは、1つまたは両方のエンドホストがマルチホームです。また、ネットワーク内に複数のパスが存在するアプリケーションがあり、等しいコストマルチパス（ECMP）で異なるポート番号を使用するなど、エンドホストによって操作できるアプリケーションもあります[4]。
MPTCP, defined in [5], is a specific protocol that instantiates the Multipath TCP concept. This document looks both at general architectural principles for a Multipath TCP fulfilling the goals described in Section 2, as well as the key design decisions behind MPTCP, which are detailed in Section 5.
[5]で定義されているMPTCPは、マルチパスTCPコンセプトをインスタンス化する特定のプロトコルです。このドキュメントは、セクション2で説明されている目標を満たすマルチパスTCPの一般的な建築原則と、セクション5で詳述されているMPTCPの背後にある主要な設計決定の両方を検討しています。
Although multihoming and multipath functions are not new to transport protocols (Stream Control Transmission Protocol (SCTP) [6] being a notable example), MPTCP aims to gain wide-scale deployment by recognizing the importance of application and network compatibility goals. These goals, discussed in detail in Section 2, relate to the appearance of MPTCP to the network (so non-MPTCP-aware entities see it as TCP) and to the application (through providing a service equivalent to TCP for non-MPTCP-aware applications).
マルチホミングおよびマルチパス機能は、輸送プロトコルには新しいものではありませんが（ストリーム制御伝送プロトコル（SCTP）[6]、注目すべき例）、MPTCPは、アプリケーションとネットワーク互換性の目標の重要性を認識することにより、幅広い展開を獲得することを目指しています。セクション2で詳細に議論されているこれらの目標は、ネットワーク（したがって、非MPTCPを認識しているエンティティがTCPと見なしている）およびアプリケーション（非MPTCPアウェアのTCPに相当するサービスを提供することにより）へのMPTCPの外観に関連しています。アプリケーション）。
This document has three key purposes: (i) it describes goals for a multipath transport -- goals that MPTCP is designed to meet; (ii) it lays out an architectural basis for MPTCP's design -- a discussion that applies to other multipath transports as well; and (iii) it discusses and documents high-level design decisions made in MPTCP's development, and considers their implications.
このドキュメントには3つの重要な目的があります。（i）マルチパス輸送の目標を説明しています。MPTCPが満たすように設計されている目標。（ii）MPTCPの設計の建築基盤をレイアウトします。これは、他のマルチパストランスポートにも適用される議論です。（iii）MPTCPの開発で行われた高レベルの設計上の決定について議論し、文書化し、その意味を考慮します。
Companion documents to this architectural overview are those that provide details of the protocol extensions [5], congestion control algorithms [7], and application-level considerations [8]. Put together, these components specify a complete Multipath TCP design. Note that specific components are replaceable in accordance with the layer and functional decompositions discussed in this document.
このアーキテクチャの概要のコンパニオンドキュメントは、プロトコル拡張[5]、混雑制御アルゴリズム[7]、およびアプリケーションレベルの考慮事項[8]の詳細を提供するものです。まとめて、これらのコンポーネントは完全なマルチパスTCP設計を指定します。特定のコンポーネントは、このドキュメントで説明されているレイヤーおよび機能的分解に従って置き換えられることに注意してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [2]に記載されているように解釈される。
Regular/Single-Path TCP: The standard version of TCP [1] in use today, operating between a single pair of IP addresses and ports.
レギュラー/シングルパスTCP：今日使用されているTCP [1]の標準バージョンで、単一のIPアドレスとポートの間で動作します。
Multipath TCP: A modified version of the TCP protocol that supports the simultaneous use of multiple paths between hosts.
MultiPath TCP：ホスト間の複数のパスの同時使用をサポートするTCPプロトコルの変更されたバージョン。
Path: A sequence of links between a sender and a receiver, defined in this context by a source and destination address pair.
パス：送信者と受信機の間のリンクのシーケンス。このコンテキストでは、ソースと宛先のアドレスペアで定義されています。
Host: An end host either initiating or terminating a Multipath TCP connection.
ホスト：マルチパスTCP接続を開始または終了するエンドホスト。
MPTCP: The proposed protocol extensions specified in [5] to provide a Multipath TCP implementation.
MPTCP：マルチパスTCP実装を提供するために[5]で指定された提案されたプロトコル拡張機能。
Subflow: A flow of TCP segments operating over an individual path, which forms part of a larger Multipath TCP connection.
サブフロー：個々のパスで動作するTCPセグメントのフローは、より大きなマルチパスTCP接続の一部を形成します。
(Multipath TCP) Connection: A set of one or more subflows combined to provide a single Multipath TCP service to an application at a host.
（MultiPath TCP）接続：1つ以上のサブフローのセットを組み合わせて、ホストのアプリケーションに単一のマルチパスTCPサービスを提供します。
The diagram shown in Figure 1 illustrates a typical usage scenario for Multipath TCP. Two hosts, A and B, are communicating with each other. These hosts are multihomed and multi-addressed, providing two disjoint connections to the Internet. The addresses on each host are referred to as A1, A2, B1, and B2. There are therefore up to four different paths between the two hosts: A1-B1, A1-B2, A2-B1, A2-B2.
図1に示す図は、MultiPath TCPの典型的な使用シナリオを示しています。AとBの2人のホストが互いに通信しています。これらのホストはマルチホームでマルチホームされており、インターネットとの2つのばらばらのつながりを提供します。各ホストのアドレスは、A1、A2、B1、およびB2と呼ばれます。したがって、2つのホストの間に最大4つの異なるパスがあります：A1-B1、A1-B2、A2-B1、A2-B2。
+------+ __________ +------+
| |A1 ______ ( ) ______ B1| |
| Host |--/ ( ) \--| Host |
| | ( Internet ) | |
| A |--\______( )______/--| B |
| |A2 (__________) B2| |
+------+ +------+
Figure 1: Simple Multipath TCP Usage Scenario
図1：単純なマルチパスTCP使用シナリオ
The scenario could have any number of addresses (1 or more) on each host, as long as the number of paths available between the two hosts is 2 or more (i.e., num_addr(A) * num_addr(B) > 1). The paths created by these address combinations through the Internet need not be entirely disjoint -- potential fairness issues introduced by shared bottlenecks need to be handled by the Multipath TCP congestion controller. Furthermore, the paths through the Internet often do not provide a pure end-to-end service, and instead may be affected by middleboxes such as NATs and firewalls.
2つのホスト間のパスの数が2つ以上（つまり、num_addr（a） * num_addr（b）> 1）である限り、シナリオは各ホストに任意の数のアドレス（1以上）を持つことができます。インターネットを介したこれらのアドレスの組み合わせによって作成されたパスは、完全にばらばらである必要はありません - 共有ボトルネックによって導入された潜在的な公平性の問題は、Multipath TCP輻輳コントローラーによって処理される必要があります。さらに、インターネットを通るパスは純粋なエンドツーエンドサービスを提供せず、代わりにNATやファイアウォールなどのミドルボックスの影響を受ける可能性があります。
This section outlines primary goals that Multipath TCP aims to meet. These are broadly broken down into the following: functional goals, which steer services and features that Multipath TCP must provide, and compatibility goals, which determine how Multipath TCP should appear to entities that interact with it.
このセクションでは、MultiPath TCPが満たすことを目的としている主な目標の概要を説明します。これらは、マルチパスTCPが提供する必要があるサービスと機能を操縦する機能と機能を操縦する機能目標と、マルチパスTCPが対話するエンティティにマルチパスTCPがどのように見えるかを決定する機能目標に大まかに分類されます。
In supporting the use of multiple paths, Multipath TCP has the following two functional goals.
複数のパスの使用をサポートする際に、MultiPath TCPには次の2つの機能目標があります。
o Improve Throughput: Multipath TCP MUST support the concurrent use of multiple paths. To meet the minimum performance incentives for deployment, a Multipath TCP connection over multiple paths SHOULD achieve no worse throughput than a single TCP connection over the best constituent path.
o スループットの改善：MultiPath TCPは、複数のパスの同時使用をサポートする必要があります。展開の最小パフォーマンスインセンティブを満たすために、複数のパス上のマルチパスTCP接続は、最適な構成パス上の単一のTCP接続よりも悪いスループットを達成する必要がありません。
o Improve Resilience: Multipath TCP MUST support the use of multiple paths interchangeably for resilience purposes, by permitting segments to be sent and re-sent on any available path. It follows that, in the worst case, the protocol MUST be no less resilient than regular single-path TCP.
o 回復力の向上：MultiPath TCPは、セグメントを送信し、利用可能なパスで再配置することを許可することにより、レジリエンスの目的で複数のパスの使用を互換的にサポートする必要があります。そのため、最悪の場合、プロトコルは通常のシングルパスTCPと同じくらい回復力がなければなりません。
As distribution of traffic among available paths and responses to congestion are done in accordance with resource pooling principles [3], a secondary effect of meeting these goals is that widespread use of Multipath TCP over the Internet should improve overall network utility by shifting load away from congested bottlenecks and by taking advantage of spare capacity wherever possible.
利用可能なパス間のトラフィックの分布と混雑に対する応答は、リソースプーリングの原則[3]に従って行われるため、これらの目標を達成することの二次的な効果は、インターネット経由でマルチパスTCPを広く使用することで、からの負荷をシフトすることによりネットワークユーティリティ全体を改善するはずです。混雑したボトルネックと、可能な限り予備の容量を利用することにより。
Furthermore, Multipath TCP SHOULD feature automatic negotiation of its use. A host supporting Multipath TCP that requires the other host to do so too must be able to detect reliably whether this host does in fact support the required extensions, using them if so, and otherwise automatically falling back to single-path TCP.
さらに、MultiPath TCPは、その使用の自動交渉を特徴とする必要があります。他のホストがそうすることを要求するマルチパスTCPをサポートするホストは、このホストが実際に必要な拡張機能をサポートし、その場合は使用し、そうでなければシングルパスTCPに自動的に戻るかどうかを確実に検出できる必要があります。
In addition to the functional goals listed above, a Multipath TCP must meet a number of compatibility goals in order to support deployment in today's Internet. These goals fall into the following categories.
上記の機能目標に加えて、マルチパスTCPは、今日のインターネットでの展開をサポートするために、多くの互換性の目標を満たす必要があります。これらの目標は、次のカテゴリに分類されます。
Application compatibility refers to the appearance of Multipath TCP to the application both in terms of the API that can be used and the expected service model that is provided.
アプリケーションの互換性とは、使用できるAPIと提供される予想されるサービスモデルの両方の観点から、アプリケーションへのマルチパスTCPの外観を指します。
Multipath TCP MUST follow the same service model as TCP [1]: in-order, reliable, and byte-oriented delivery. Furthermore, a Multipath TCP connection SHOULD provide the application with no worse throughput or resilience than it would expect from running a single TCP connection over any one of its available paths. A Multipath TCP may not, however, be able to provide the same level of consistency of throughput and latency as a single TCP connection. These, and other, application considerations are discussed in detail in [8].
MultiPath TCPは、TCP [1]と同じサービスモデルに従う必要があります。さらに、MultiPath TCP接続は、利用可能なパスのいずれかで単一のTCP接続を実行することで予想されるよりも悪いスループットまたは回復力をアプリケーションに提供する必要があります。ただし、マルチパスTCPは、単一のTCP接続と同じレベルのスループットとレイテンシの一貫性を提供することはできません。これらおよびその他のアプリケーションの考慮事項については、[8]で詳細に説明します。
A multipath-capable equivalent of TCP MUST retain some level of backward compatibility with existing TCP APIs, so that existing applications can use the newer transport merely by upgrading the operating systems of the end hosts. This does not preclude the use of an advanced API to permit multipath-aware applications to specify preferences, nor for users to configure their systems in a different way from the default, for example switching on or off the automatic use of multipath extensions.
TCPに相当するマルチパス対応の同等物は、既存のアプリケーションが最終ホストのオペレーティングシステムをアップグレードするだけで新しいトランスポートを使用できるように、既存のTCP APIとのある程度の後方互換性を保持する必要があります。これにより、高度なAPIが使用されてマルチパスを意識したアプリケーションが設定を指定することを許可したり、ユーザーがデフォルトとは異なる方法でシステムを構成したり、マルチパスエクステンションの自動使用をオンまたはオフにしたりすることはできません。
It is possible for regular TCP sessions today to survive brief breaks in connectivity by retaining state at end hosts before a timeout occurs. It would be desirable to support similar session continuity in MPTCP; however, the circumstances could be different. Whilst in regular TCP the IP addresses will remain constant across the break in connectivity, in MPTCP a different interface may appear. It is desirable (but not mandated) to support this kind of "break-before-make" session continuity. This places constraints on security mechanisms, however, as discussed in Section 5.8. Timeouts for this function would be locally configured.
今日の定期的なTCPセッションは、タイムアウトが発生する前にエンドホストで状態を保持することにより、接続の短い休憩を生き延びることができます。MPTCPでの同様のセッションの継続性をサポートすることが望ましいでしょう。ただし、状況は異なる場合があります。通常のTCPでは、IPアドレスは接続の破損全体で一定のままになりますが、MPTCPでは異なるインターフェイスが表示される場合があります。この種の「侵入前」のセッションの継続性をサポートすることは望ましい（義務付けられていない）。ただし、セクション5.8で説明したように、これはセキュリティメカニズムに制約を課します。この関数のタイムアウトはローカルで構成されます。
In the traditional Internet architecture, network devices operate at the network layer and lower layers, with the layers above the network layer instantiated only at the end hosts. While this architecture, shown in Figure 2, was initially largely adhered to, this layering no longer reflects the "ground truth" in the Internet with the proliferation of middleboxes [9]. Middleboxes routinely interpose on the transport layer; sometimes even completely terminating transport connections, thus leaving the application layer as the first real end-to-end layer, as shown in Figure 3.
従来のインターネットアーキテクチャでは、ネットワークデバイスはネットワークレイヤーと下層層で動作し、ネットワークレイヤーの上のレイヤーはエンドホストにのみインスタンス化されます。図2に示されているこのアーキテクチャは、当初は主に順守されていましたが、このレイヤーは、ミドルボックスの増殖を伴うインターネットの「グラウンドトゥルース」を反映していません[9]。ミドルボックスは、輸送層に日常的に干渉します。図3に示すように、輸送接続を完全に終了することがあります。
+-------------+ +-------------+
| Application |<------------ end-to-end ------------->| Application |
+-------------+ +-------------+
| Transport |<------------ end-to-end ------------->| Transport |
+-------------+ +-------------+ +-------------+ +-------------+
| Network |<->| Network |<->| Network |<->| Network |
+-------------+ +-------------+ +-------------+ +-------------+
End Host Router Router End Host
Figure 2: Traditional Internet Architecture
図2：従来のインターネットアーキテクチャ
+-------------+ +-------------+
| Application |<------------ end-to-end ------------->| Application |
+-------------+ +-------------+ +-------------+
| Transport |<------------------->| Transport |<->| Transport |
+-------------+ +-------------+ +-------------+ +-------------+
| Network |<->| Network |<->| Network |<->| Network |
+-------------+ +-------------+ +-------------+ +-------------+
Firewall,
End Host Router NAT, or Proxy End Host
Figure 3: Internet Reality
図3：インターネットの現実
Middleboxes that interpose on the transport layer result in loss of "fate-sharing" [10], that is, they often hold "hard" state that, when lost or corrupted, results in loss or corruption of the end-to-end transport connection.
輸送層に干渉するミドルボックスは、「運命共有」[10]の損失をもたらします。つまり、しばしば「硬い」状態を保持します。繋がり。
The network compatibility goal requires that the multipath extension to TCP retain compatibility with the Internet as it exists today, including making reasonable efforts to be able to traverse predominant middleboxes such as firewalls, NATs, and performance-enhancing proxies [9]. This requirement comes from recognizing middleboxes as a significant deployment bottleneck for any transport that is not TCP or UDP, and constrains Multipath TCP to appear as TCP does on the wire and to use established TCP extensions where necessary. To ensure "end-to-endness" of the transport, Multipath TCP MUST preserve fate-sharing without making any assumptions about middlebox behavior.
ネットワーク互換性の目標は、TCPのマルチパス拡張が、インターネットとの互換性を今日存在するように維持することを必要とします。これには、ファイアウォール、NAT、パフォーマンス向上プロキシなどの主要な中間ボックスを通過できる合理的な努力をすることが含まれます[9]。この要件は、TCPまたはUDPではない輸送の重要な展開ボトルネックとしてミドルボックスを認識し、マルチパスTCPをワイヤー上で行うように表示され、必要に応じて確立されたTCP拡張機能を使用するように制約します。輸送の「エンドツーエンド」を確保するために、マルチパスTCPは、ミドルボックスの動作について仮定することなく運命共有を保持する必要があります。
A detailed analysis of middlebox behavior and the impact on the Multipath TCP architecture is presented in Section 7. In addition, network compatibility must be retained to the extent that Multipath TCP MUST fall back to regular TCP if there are insurmountable incompatibilities for the multipath extension on a path.
ミドルボックスの動作とマルチパスTCPアーキテクチャへの影響の詳細な分析をセクション7に示します。さらに、マルチパスTCPが克服できない互換性がある場合は、マルチパスTCPが通常のTCPに戻る必要がある限り、ネットワークの互換性を保持する必要があります。通り。
Middleboxes may also cause some TCP features to be able to exist on one subflow but not another. Typically, these will be at the subflow level (such as selective acknowledgment (SACK) [11]) and thus do not affect the connection-level behavior. In the future, any proposed TCP connection-level extensions should consider how they can coexist with MPTCP.
また、ミドルボックスにより、あるTCP機能が1つのサブフローに存在することもありますが、別のサブフローでは存在する場合もあります。通常、これらはサブフローレベル（選択的承認（SACK）[11]など）になり、接続レベルの動作には影響しません。将来、提案されているTCP接続レベルの拡張機能は、MPTCPと共存する方法を検討する必要があります。
The modifications to support Multipath TCP remain at the transport layer, although some knowledge of the underlying network layer is required. Multipath TCP SHOULD work with IPv4 and IPv6 interchangeably, i.e., one connection may operate over both IPv4 and IPv6 networks.
MultiPath TCPをサポートするための変更は輸送層に残りますが、基礎となるネットワークレイヤーの知識が必要です。MultiPath TCPは、IPv4とIPv6と同じ意味で動作する必要があります。つまり、1つの接続がIPv4ネットワークとIPv6ネットワークの両方で動作する場合があります。
As a corollary to both network and application compatibility, the architecture must enable new Multipath TCP flows to coexist gracefully with existing single-path TCP flows, competing for bandwidth neither unduly aggressively nor unduly timidly (unless low-precedence operation is specifically requested by the application, such as with LEDBAT). The use of multiple paths MUST NOT unduly harm users using single-path TCP at shared bottlenecks, beyond the impact that would occur from another single-path TCP flow. Multiple Multipath TCP flows on a shared bottleneck MUST share bandwidth between each other with similar fairness to that which occurs at a shared bottleneck with single-path TCP.
ネットワークとアプリケーションの互換性の両方の結果として、アーキテクチャは、新しいマルチパスTCPフローが既存のシングルパスTCPフローと優雅に共存することを可能にする必要があり、帯域幅を過度に攻撃的にも邪魔にも競合しません（低認定操作がアプリケーションによって特異的に要求されない限り、Ledbatなど）。複数のパスの使用は、別のシングルパスTCPフローから発生する影響を超えて、共有ボトルネックでシングルパスTCPを使用してユーザーを不当に害してはなりません。共有されたボトルネック上の複数のマルチパスTCPフローは、シングルパスTCPを使用して共有ボトルネックで発生するものと同様の公平性で帯域幅を共有する必要があります。
The extension of TCP with multipath capabilities will bring with it a number of new threats, analyzed in detail in [12]. The security goal for Multipath TCP is to provide a service no less secure than regular, single-path TCP. This will be achieved through a combination of existing TCP security mechanisms (potentially modified to align with the Multipath TCP extensions) and of protection against the new multipath threats identified. The design decisions derived from this goal are presented in Section 5.8.
MultiPath機能を備えたTCPの拡張は、[12]で詳細に分析された多くの新しい脅威をもたらします。MultiPath TCPのセキュリティ目標は、通常のシングルパスTCPよりも安全なサービスを提供することです。これは、既存のTCPセキュリティメカニズム（マルチパスTCPエクステンションと整合するように変更される可能性がある）と特定された新しいマルチパスの脅威に対する保護によって達成されます。この目標から導き出された設計上の決定は、セクション5.8に示されています。
There are several similarities between SCTP [6] and MPTCP, in that both can make use of multiple addresses at end hosts to give some multipath capability. In SCTP, the primary use case is to support redundancy and mobility for multihomed hosts (i.e., a single path will change one of its end host addresses); the simultaneous use of multiple paths is not supported. Extensions are proposed to support simultaneous multipath transport [13], but these are yet to be standardized. By far the most widely used stream-based transport protocol is, however, TCP [1], and SCTP does not meet the network and application compatibility goals specified in Section 2.2. For network compatibility, there are issues with various middleboxes (especially NATs) that are unaware of SCTP and consequently end up blocking it. For application compatibility, applications need to actively choose to use SCTP, and with the deployment issues, very few choose to do so. MPTCP's compatibility goals are in part based on these observations of SCTP's deployment issues.
SCTP [6]とMPTCPの間にはいくつかの類似点がありますが、両方ともエンドホストで複数のアドレスを使用してマルチパス機能を提供できるという点でいくつかの類似点があります。SCTPでは、主要なユースケースは、マルチホームのホストの冗長性とモビリティをサポートすることです（つまり、単一のパスはその最終ホストアドレスの1つを変更します）。複数のパスの同時使用はサポートされていません。拡張機能は、同時マルチパス輸送をサポートするために提案されています[13]が、これらはまだ標準化されていません。ただし、最も広く使用されているストリームベースの輸送プロトコルは、TCP [1]であり、SCTPはセクション2.2で指定されたネットワークおよびアプリケーションの互換性の目標を満たしていません。ネットワークの互換性については、SCTPを知らないため、さまざまなミドルボックス（特にNAT）に問題があり、その結果、それをブロックすることになります。アプリケーションの互換性のために、アプリケーションはSCTPを使用することを積極的に選択する必要があり、展開の問題により、そうすることを選択することはほとんどありません。MPTCPの互換性の目標は、SCTPの展開問題のこれらの観察に一部基づいています。
This section presents one possible transport architecture that the authors believe can effectively support the goals for Multipath TCP. The new Internet model described here is based on ideas proposed earlier in Tng ("Transport next-generation") [14]. While by no means the only possible architecture supporting multipath transport, Tng incorporates many lessons learned from previous transport research and development practice, and offers a strong starting point from which to consider the extant Internet architecture and its bearing on the design of any new Internet transports or transport extensions.
このセクションでは、著者がMultiPath TCPの目標を効果的にサポートできると考えている輸送アーキテクチャの1つを紹介します。ここで説明する新しいインターネットモデルは、TNG（「輸送次世代」）で前述したアイデアに基づいています[14]。マルチパストランスポートをサポートする唯一の可能なアーキテクチャは決してありませんが、TNGは以前の輸送研究開発の実践から学んだ多くの教訓を組み込み、現存するインターネットアーキテクチャを検討する強力な出発点と、新しいインターネットトランスポートの設計に関係する強力な出発点を提供します。または輸送拡張機能。
+------------------+
| Application |
+------------------+ ^ Application-oriented transport
| | | functions (Semantic Layer)
+ - - Transport - -+ ----------------------------------
| | | Network-oriented transport
+------------------+ v functions (Flow+Endpoint Layer)
| Network |
+------------------+
Existing Layers Tng Decomposition
Figure 4: Decomposition of Transport Functions
図4：輸送機能の分解
Tng loosely splits the transport layer into "application-oriented" and "network-oriented" layers, as shown in Figure 4. The application-oriented "Semantic" layer implements functions driven primarily by concerns of supporting and protecting the application's end-to-end communication, while the network-oriented "Flow+Endpoint" layer implements functions such as endpoint identification (using port numbers) and congestion control. These network-oriented functions, while traditionally located in the ostensibly "end-to-end" Transport layer, have proven in practice to be of great concern to network operators and the middleboxes they deploy in the network to enforce network usage policies [15] [16] or optimize communication performance [17]. Figure 5 shows how middleboxes interact with different layers in this decomposed model of the transport layer: the application-oriented layer operates end-to-end, while the network-oriented layer operates "segment-by-segment" and can be interposed upon by middleboxes.
TNGは、図4に示すように、輸送層を「アプリケーション指向」および「ネットワーク指向の」レイヤーに緩やかに分割します。エンド通信。一方、ネットワーク指向の「フローエンドポイント」レイヤーは、エンドポイント識別（ポート番号を使用）や混雑制御などの関数を実装します。これらのネットワーク指向の機能は、伝統的に表面的に表面的に「エンドツーエンド」トランスポートレイヤーに位置していますが、ネットワークオペレーターとネットワークで展開するためにネットワークに展開するミドルボックスに大きな関心があることが実際に証明されています[15][16]または通信パフォーマンスを最適化します[17]。図5は、この分解された輸送層のモデルでミドルボックスが異なるレイヤーと相互作用する方法を示しています。アプリケーション指向のレイヤーはエンドツーエンドで動作し、ネットワーク指向のレイヤーは「セグメントごと」を動作させ、介在することができます。ミドルボックス。
+-------------+ +-------------+
| Application |<------------ end-to-end ------------->| Application |
+-------------+ +-------------+
| Semantic |<------------ end-to-end ------------->| Semantic |
+-------------+ +-------------+ +-------------+ +-------------+
|Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint|
+-------------+ +-------------+ +-------------+ +-------------+
| Network |<->| Network |<->| Network |<->| Network |
+-------------+ +-------------+ +-------------+ +-------------+
Firewall Performance
End Host or NAT Enhancing Proxy End Host
Figure 5: Middleboxes in the New Internet Model
図5：新しいインターネットモデルのミドルボックス
MPTCP's architectural design follows Tng's decomposition as shown in Figure 6. MPTCP, which provides application compatibility through the preservation of TCP-like semantics of global ordering of application data and reliability, is an instantiation of the "application-oriented" Semantic layer; whereas the subflow TCP component, which provides network compatibility by appearing and behaving as a TCP flow in the network, is an instantiation of the "network-oriented" Flow+Endpoint layer.
MPTCPの建築設計は、図6に示すようにTNGの分解に従います。MPTCPは、アプリケーションデータと信頼性のTCP様のセマンティクスを保存することでアプリケーションの互換性を提供し、「アプリケーション指向の」セマンティックレイヤーのインスタンス化です。一方、ネットワーク内のTCPフローとして表示および動作することでネットワーク互換性を提供するサブフローTCPコンポーネントは、「ネットワーク指向の」フローエンドポイントレイヤーのインスタンス化です。
+--------------------------+ +-------------------------------+
| Application | | Application |
+--------------------------+ +-------------------------------+
| Semantic | | MPTCP |
|------------+-------------| + - - - - - - - + - - - - - - - +
| Flow+Endpt | Flow+Endpt | | Subflow (TCP) | Subflow (TCP) |
+------------+-------------+ +---------------+---------------+
| Network | Network | | IP | IP |
+------------+-------------+ +---------------+---------------+
Figure 6: Relationship between Tng (Left) and MPTCP (Right)
図6：TNG（左）とMPTCP（右）の関係
As a protocol extension to TCP, MPTCP thus explicitly acknowledges middleboxes in its design, and specifies a protocol that operates at two scales: the MPTCP component operates end-to-end, while it allows the TCP component to operate segment-by-segment.
したがって、MPTCPはTCPへのプロトコル拡張として、その設計の中間ボックスを明示的に認識し、2つのスケールで動作するプロトコルを指定します。MPTCPコンポーネントはエンドツーエンドで動作し、TCPコンポーネントはセグメントごとに動作できます。
The previous two sections have discussed the goals for a Multipath TCP design, and provided a basis for decomposing the functions of a transport protocol in order to better understand the form a solution should take. This section builds upon this analysis by presenting the functional components that are used within the MPTCP design.
前の2つのセクションでは、マルチパスTCP設計の目標について説明し、ソリューションが取るべき形式をよりよく理解するために、輸送プロトコルの機能を分解するための基礎を提供しました。このセクションは、MPTCP設計内で使用される機能コンポーネントを提示することにより、この分析に基づいて構築されます。
MPTCP makes use of (what appear to the network to be) standard TCP sessions, termed "subflows", to provide the underlying transport per path, and as such these retain the network compatibility desired. MPTCP-specific information is carried in a TCP-compatible manner, although this mechanism is separate from the actual information being transferred so could evolve in future revisions. Figure 7 illustrates the layered architecture.
MPTCPは、「サブフロー」と呼ばれる標準のTCPセッション（ネットワークのように見えるもの）を使用して、パスごとの基礎となる輸送を提供するため、これらは必要なネットワークの互換性を保持します。MPTCP固有の情報は、TCP互換的な方法で実施されますが、このメカニズムは転送される実際の情報とは別に、将来の改訂で進化する可能性があります。図7は、層状アーキテクチャを示しています。
+-------------------------------+
| Application |
+---------------+ +-------------------------------+
| Application | | MPTCP |
+---------------+ + - - - - - - - + - - - - - - - +
| TCP | | Subflow (TCP) | Subflow (TCP) |
+---------------+ +-------------------------------+
| IP | | IP | IP |
+---------------+ +-------------------------------+
Figure 7: Comparison of Standard TCP and MPTCP Protocol Stacks
図7：標準のTCPとMPTCPプロトコルスタックの比較
Situated below the application, the MPTCP extension in turn manages multiple TCP subflows below it. In order to do this, it must implement the following functions:
アプリケーションの下にあるMPTCP拡張は、その下の複数のTCPサブフローを管理します。これを行うには、次の機能を実装する必要があります。
o Path Management: This is the function to detect and use multiple paths between two hosts. MPTCP uses the presence of multiple IP addresses at one or both of the hosts as an indicator of this. The path management features of the MPTCP protocol are the mechanisms to signal alternative addresses to hosts, and mechanisms to set up new subflows joined to an existing MPTCP connection.
o パス管理：これは、2つのホスト間で複数のパスを検出および使用する機能です。MPTCPは、これの指標として、ホストの一方または両方に複数のIPアドレスの存在を使用します。MPTCPプロトコルのパス管理機能は、既存のMPTCP接続に結合された新しいサブフローを設定するためのメカニズムと、ホストに代替アドレスを信号するメカニズムです。
o Packet Scheduling: This function breaks the byte stream received from the application into segments to be transmitted on one of the available subflows. The MPTCP design makes use of a data sequence mapping, associating segments sent on different subflows to a connection-level sequence numbering, thus allowing segments sent on different subflows to be correctly re-ordered at the receiver. The packet scheduler is dependent upon information about the availability of paths exposed by the path management component, and then makes use of the subflows to transmit queued segments. This function is also responsible for connection-level re-ordering on receipt of packets from the TCP subflows, according to the attached data sequence mappings.
o パケットスケジューリング：この関数は、アプリケーションから受信したバイトストリームをセグメントに分割し、利用可能なサブフローの1つに送信されます。MPTCP設計では、データシーケンスマッピング、接続レベルのシーケンス番号に異なるサブフローで送信されるセグメントを関連付けるため、さまざまなサブフローに送信されるセグメントを受信機に正しく再注文できるようにします。パケットスケジューラは、パス管理コンポーネントによって公開されるパスの可用性に関する情報に依存し、サブフローを利用してキューに囲まれたセグメントを送信します。この関数は、添付のデータシーケンスマッピングに従って、TCPサブフローからパケットの受信時に接続レベルの再注文を担当します。
o Subflow (single-path TCP) Interface: A subflow component takes segments from the packet-scheduling component and transmits them over the specified path, ensuring detectable delivery to the host.
o サブフロー（シングルパスTCP）インターフェイス：サブフローコンポーネントは、パケットスケジューリングコンポーネントからセグメントを取得し、指定されたパス上に送信し、ホストへの検出可能な配信を確保します。
MPTCP uses TCP underneath for network compatibility; TCP ensures in-order, reliable delivery. TCP adds its own sequence numbers to the segments; these are used to detect and retransmit lost packets at the subflow layer. On receipt, the subflow passes its reassembled data to the packet scheduling component for connection-level reassembly; the data sequence mapping from the sender's packet scheduling component allows re-ordering of the entire byte stream.
MPTCPは、ネットワーク互換性にTCPを下に使用します。TCPは、順序で信頼性の高い配信を保証します。TCPは、独自のシーケンス番号をセグメントに追加します。これらは、サブフロー層で紛失したパケットを検出および再送信するために使用されます。受領時に、サブフローは、接続レベルの再組み立てのために、その再組み立てデータをパケットスケジューリングコンポーネントに渡します。送信者のパケットスケジューリングコンポーネントからのデータシーケンスマッピングにより、バイトストリーム全体を再注文できます。
o Congestion Control: This function coordinates congestion control across the subflows. As specified, this congestion control algorithm MUST ensure that an MPTCP connection does not unfairly take more bandwidth than a single path TCP flow would take at a shared bottleneck. An algorithm to support this is specified in [7].
o 輻輳制御：この関数は、サブフロー全体の輻輳制御を調整します。指定されているように、この輻輳制御アルゴリズムは、MPTCP接続が共有ボトルネックで1つのパスTCPフローが取るよりも不当に帯域幅を取ることを保証する必要があります。これをサポートするアルゴリズムは[7]で指定されています。
These functions fit together as follows. The path management looks after the discovery (and if necessary, initialization) of multiple paths between two hosts. The packet scheduler then receives a stream of data from the application destined for the network, and undertakes the necessary operations on it (such as segmenting the data into connection-level segments, and adding a connection-level sequence number) before sending it on to a subflow. The subflow then adds its own sequence number, ACKs, and passes them to network. The receiving subflow re-orders data (if necessary) and passes it to the packet scheduling component, which performs connection level re-ordering, and sends the data stream to the application. Finally, the congestion control component exists as part of the packet scheduling, in order to schedule which segments should be sent at what rate on which subflow.
これらの関数は次のように適合します。パス管理は、2つのホスト間の複数のパスの発見（および必要に応じて初期化）の面倒を見ます。パケットスケジューラは、ネットワークに向けられたアプリケーションからデータのストリームを受信し、必要な操作（データを接続レベルセグメントにセグメント化し、接続レベルのシーケンス番号を追加するなど）を引き受けてから送信します。サブフロー。次に、サブフローは独自のシーケンス番号、Acksを追加し、それらをネットワークに渡します。受信サブフローはデータ（必要に応じて）に再度順序付けされ、接続レベルの再注文を実行するパケットスケジューリングコンポーネントに渡し、データストリームをアプリケーションに送信します。最後に、渋滞制御コンポーネントは、パケットスケジューリングの一部として存在し、どのセグメントをどのサブフローのレートで送信するかをスケジュールします。
There is seemingly a wide range of choices when designing a multipath extension to TCP. However, the goals as discussed earlier in this document constrain the possible solutions, leaving relative little choice in many areas. This section outlines high-level design choices that draw from the architectural basis discussed earlier in Section 3, which the design of MPTCP [5] takes into account.
TCPにマルチパス拡張機能を設計する際には、幅広い選択肢があるように見えます。ただし、このドキュメントで前述した目標は、可能な解決策を制約し、多くの領域で比較的選択肢がほとんどありません。このセクションでは、MPTCP [5]の設計が考慮に入れるセクション3で前述した建築基盤から引き出される高レベルの設計の選択肢の概要を説明します。
MPTCP uses two levels of sequence spaces: a connection-level sequence number and another sequence number for each subflow. This permits connection-level segmentation and reassembly and retransmission of the same part of connection-level sequence space on different subflow-level sequence space.
MPTCPは、2つのレベルのシーケンススペースを使用します。各サブフローの接続レベルのシーケンス番号と別のシーケンス番号です。これにより、接続レベルのセグメンテーションと再組み立てと、異なるサブフローレベルのシーケンス空間での接続レベルのシーケンス空間の同じ部分の再送信が可能になります。
The alternative approach would be to use a single connection-level sequence number, which gets sent on multiple subflows. This has two problems: first, the individual subflows will appear to the network as TCP sessions with gaps in the sequence space; this in turn may upset certain middleboxes such as intrusion detection systems, or certain transparent proxies, and would thus go against the network compatibility goal. Second, the sender would not be able to attribute packet losses or receptions to the correct path when the same segment is sent on multiple paths (i.e., in the case of retransmissions).
別のアプローチは、複数のサブフローで送信される単一の接続レベルのシーケンス番号を使用することです。これには2つの問題があります。最初に、個々のサブフローは、シーケンススペースにギャップがあるTCPセッションとしてネットワークに表示されます。これにより、侵入検知システムや特定の透明なプロキシなどの特定のミドルボックスが混乱する可能性があり、したがって、ネットワーク互換性の目標に反します。第二に、送信者は、同じセグメントが複数のパスで送信される場合（つまり、再送信の場合）、パケットの損失またはレセプションを正しいパスに属性することができません。
The sender must be able to tell the receiver how to reassemble the data, for delivery to the application. In order to achieve this, the receiver must determine how subflow-level data (carrying subflow sequence numbers) maps at the connection level. This is referred to as the "data sequence mapping". This mapping can be represented as a tuple of (data sequence number, subflow sequence number, length), i.e., for a given number of bytes (the length), the subflow sequence space beginning at the given sequence number maps to the connection-level sequence space (beginning at the given data sequence number). This information could conceivably have various sources.
送信者は、アプリケーションへの配信のために、データを再組み立てする方法を受信者に伝えることができる必要があります。これを達成するために、受信者は、接続レベルでサブフローレベルのデータ（サブフローシーケンス番号の運搬）がどのようにマップするかを決定する必要があります。これは「データシーケンスマッピング」と呼ばれます。このマッピングは、（データシーケンス番号、サブフローシーケンス番号、長さ）のタプルとして表すことができます。つまり、特定のバイト数（長さ）で、特定のシーケンス番号マップから始まるサブフローシーケンススペースを接続レベルのマップで始めることができます。シーケンス空間（指定されたデータシーケンス番号から始まります）。この情報には、さまざまな情報源がある可能性があります。
One option to signal the data sequence mapping would be to use existing fields in the TCP segment (such as subflow sequence number, length) and add only the data sequence number to each segment, for instance, as a TCP option. This would be vulnerable, however, to middleboxes that re-segment or assemble data, since there is no specified behavior for coalescing TCP options. If one signaled (data sequence number, length), this would still be vulnerable to middleboxes that coalesce segments and do not understand MPTCP signaling so do not correctly rewrite the options.
データシーケンスマッピングに信号を送信する1つのオプションは、TCPセグメントの既存のフィールド（サブフローシーケンス番号、長さなど）を使用し、たとえばTCPオプションとして各セグメントにデータシーケンス番号のみを追加することです。ただし、TCPオプションを合体するための指定された動作がないため、これはデータを再セグメントまたは組み立てる中間ボックスに対して脆弱になります。シグナル（データシーケンス番号、長さ）がある場合、これはセグメントを合体し、MPTCPシグナル伝達を理解していないミドルボックスに対して依然として脆弱であるため、オプションを正しく書き換えません。
Because of these potential issues, the design decision taken in the MPTCP protocol is that whenever a mapping for subflow data needs to be conveyed to the other host, all three pieces of data (data seq, subflow seq, length) must be sent. To reduce the overhead, it would be permissible for the mapping to be sent periodically and cover more than a single segment. Further experimentation is required to determine what tradeoffs exist regarding the frequency at which mappings should be sent. It could also be excluded entirely in the case of a connection before more than one subflow is used, where the data-level and subflow-level sequence space is the same.
これらの潜在的な問題のため、MPTCPプロトコルで行われた設計上の決定は、サブフローデータのマッピングを他のホストに伝える必要がある場合、3つのデータ（データSEQ、サブフローSEQ、長さ）をすべて送信する必要があることです。オーバーヘッドを減らすために、マッピングを定期的に送信し、単一のセグメント以上をカバーすることが許可されます。マッピングを送信する頻度に関するトレードオフが存在するかどうかを判断するには、さらなる実験が必要です。また、データレベルとサブフローレベルのシーケンススペースが同じである場合、複数のサブフローが使用される前に、接続の場合に完全に除外することもできます。
MPTCP features acknowledgements at connection-level as well as subflow-level acknowledgements, in order to provide a robust service to the application.
MPTCPは、アプリケーションに堅牢なサービスを提供するために、接続レベルとサブフローレベルの謝辞での謝辞を特徴としています。
Under normal behavior, MPTCP could use the data sequence mapping and subflow ACKs to decide when a connection-level segment was received. The transmission of TCP ACKs for a subflow are handled entirely at the subflow level, in order to maintain TCP semantics and trigger subflow-level retransmissions. This has certain implications on end-to-end semantics. It would mean that once a segment is ACKed at the subflow level, it cannot be discarded in the re-order buffer at the connection level. Secondly, unlike in standard TCP, a receiver cannot simply drop out-of-order segments if needed (for instance, due to memory pressure). Under certain circumstances, it may be desirable to drop segments after acknowledgement on the subflow but before delivery to the application, and this can be facilitated by a connection-level acknowledgement.
通常の動作の下で、MPTCPはデータシーケンスマッピングとサブフローアクックを使用して、接続レベルのセグメントをいつ受信したかを決定できます。TCPセマンティクスを維持し、サブフローレベルの再送信をトリガーするために、サブフロー用のTCP Acksの送信は、完全にサブフローレベルで処理されます。これは、エンドツーエンドのセマンティクスに特定の意味を持ちます。それは、セグメントがサブフローレベルでアクセスされると、接続レベルの再注文バッファーで破棄できないことを意味します。第二に、標準のTCPとは異なり、受信者は必要に応じて（たとえば、メモリ圧力のため）、秩序外セグメントを単純にドロップすることはできません。特定の状況では、サブフローの承認後、アプリケーションへの配信前にセグメントをドロップすることが望ましい場合があり、これは接続レベルの確認によって促進される可能性があります。
Furthermore, it is possible to conceive of some cases where connection-level acknowledgements could improve robustness. Consider a subflow traversing a transparent proxy: if the proxy ACKs a segment and then crashes, the sender will not retransmit the lost segment on another subflow, as it thinks the segment has been received. The connection grinds to a halt despite having other working subflows, and the sender would be unable to determine the cause of the problem. An example situation where this may occur would be mobility between wireless access points, each of which operates a transport-level proxy. Finally, as an optimization, it may be feasible for a connection-level acknowledgement to be transmitted over the shortest Round-Trip Time (RTT) path, potentially reducing send buffer requirements (see Section 5.3).
さらに、接続レベルの承認が堅牢性を改善できる場合がある場合がある場合がある場合があります。透明なプロキシを通過するサブフローを考慮してください。プロキシAcksがセグメントになってからクラッシュする場合、セグメントが受け取ったと思われるため、送信者は別のサブフローで失われたセグメントを再送信しません。他の作業サブフローがあるにもかかわらず、接続は停止し、送信者は問題の原因を決定することができません。これが発生する可能性のある状況の例は、ワイヤレスアクセスポイント間のモビリティであり、それぞれがトランスポートレベルのプロキシを動作させます。最後に、最適化として、接続レベルの承認が最短の往復時間（RTT）パスで送信される可能性があり、送信バッファー要件を削減する可能性があります（セクション5.3を参照）。
Therefore, to provide a fully robust multipath TCP solution given the above constraints, MPTCP for use on the public Internet MUST feature explicit connection-level acknowledgements, in addition to subflow-level acknowledgements. A connection-level acknowledgement would only be required in order to signal when the receive window moves forward; the heuristics for using such a signal are discussed in more detail in the protocol specification [5].
したがって、上記の制約を考慮して完全に堅牢なマルチパスTCPソリューションを提供するには、パブリックインターネットで使用するMPTCPは、サブフローレベルの承認に加えて、明示的な接続レベルの確認を特徴とする必要があります。受信ウィンドウが前方に移動したときに信号を送るためにのみ、接続レベルの確認が必要です。このような信号を使用するためのヒューリスティックについては、プロトコル仕様[5]で詳細に説明します。
Regarding retransmissions, it MUST be possible for a segment to be retransmitted on a different subflow from that on which it was originally sent. This is one of MPTCP's core goals, in order to maintain integrity during temporary or permanent subflow failure, and this is enabled by the dual sequence number space.
再送信に関しては、セグメントが最初に送信されたサブフローとは異なるサブフローで再送信されることが可能である必要があります。これは、一時的または永続的なサブフロー障害中に完全性を維持するためのMPTCPの中核目標の1つであり、これはデュアルシーケンス番号スペースによって有効になっています。
The scheduling of retransmissions will have significant impact on MPTCP user experience. The current MPTCP specification suggests that data outstanding on subflows that have timed out should be rescheduled for transmission on different subflows. This behavior aims to minimize disruption when a path breaks, and uses the first timeout as indicators. More conservative versions would be to use second or third timeouts for the same segment.
再送信のスケジューリングは、MPTCPユーザーエクスペリエンスに大きな影響を与えます。現在のMPTCP仕様は、タイムアウトしたサブフローの未解決のデータを、異なるサブフローでの送信のために再スケジュールする必要があることを示唆しています。この動作の目的は、パスが壊れたときの混乱を最小限に抑えることを目的としており、最初のタイムアウトをインジケーターとして使用します。より保守的なバージョンは、同じセグメントに対して2番目または3番目のタイムアウトを使用することです。
Typically, fast retransmit on an individual subflow will not trigger retransmission on another subflow, although this may still be desirable in certain cases, for instance, to reduce the receive buffer requirements. However, in all cases with retransmissions on different subflows, the lost segments SHOULD still be sent on the path that lost them. This is currently believed to be necessary to maintain subflow integrity, as per the network compatibility goal. By doing this, some efficiency is lost, and it is unclear at this point what the optimal retransmit strategy is.
通常、個々のサブフローでの高速再送信は、別のサブフローの再送信をトリガーしませんが、これは、特定の場合、受信バッファー要件を削減するためにまだ望ましい場合があります。ただし、さまざまなサブフローで再送信がある場合はすべての場合、失われたセグメントを失ったパスに送信する必要があります。これは現在、ネットワーク互換性の目標に従って、サブフローの完全性を維持するために必要であると考えられています。これを行うことにより、ある程度の効率が失われ、この時点で最適な再送信戦略が何であるかは不明です。
Large-scale experiments are therefore required in order to determine the most appropriate retransmission strategy, and recommendations will be refined once more information is available.
したがって、最も適切な再送信戦略を決定するためには、大規模な実験が必要であり、推奨事項を洗練され、もう一度情報が利用可能になります。
To ensure in-order delivery, MPTCP must use a connection level receive buffer, where segments are placed until they are in order and can be read by the application.
注文の配信を確保するために、MPTCPは接続レベルの受信バッファーを使用する必要があります。このバッファーでは、セグメントが順番に配置され、アプリケーションで読み取ることができます。
In regular, single-path TCP, it is usually recommended to set the receive buffer to 2*BDP (Bandwidth-Delay Product, i.e., BDP = BW*RTT, where BW = Bandwidth and RTT = Round-Trip Time). One BDP allows supporting reordering of segments by the network. The other BDP allows the connection to continue during fast retransmit: when a segment is fast retransmitted, the receiver must be able to store incoming data during one more RTT.
通常のシングルパスTCPでは、通常、受信バッファーを2*BDP（帯域幅遅延製品、つまりBDP = BW*RTT）に設定することをお勧めします。ここで、BW =帯域幅とRTT =往復時間）。1つのBDPを使用すると、ネットワークによるセグメントの並べ替えをサポートできます。もう1つのBDPを使用すると、速い再送信中に接続を継続できます。セグメントが高速な再送信を行うと、受信者はもう1つのRTT中に着信データを保存できる必要があります。
For MPTCP, the story is a bit more complicated. The ultimate goal is that a subflow packet loss or subflow failure should not affect the throughput of other working subflows; the receiver should have enough buffering to store all data until the missing segment is re-transmitted and reaches the destination.
MPTCPの場合、ストーリーはもう少し複雑です。究極の目標は、サブフローパケットの損失またはサブフロー障害が他の作業サブフローのスループットに影響を与えないことです。欠落しているセグメントが再送信され、宛先に到達するまで、すべてのデータを保存するのに十分なバッファリングが必要です。
The worst-case scenario would be when the subflow with the highest RTT/RTO (Round-Trip Time or Retransmission TimeOut) experiences a timeout; in that case, the receiver has to buffer data from all subflows for the duration of the RTO. Thus, the smallest connection-level receive buffer that would be needed to avoid stalling with subflow failures is sum(BW_i)*RTO_max, where BW_i = Bandwidth for each subflow and RTO_max is the largest RTO across all subflows.
最悪のシナリオは、最高のRTT/RTO（ラウンドトリップ時間または再送信タイムアウト）のサブフローがタイムアウトを経験する場合です。その場合、レシーバーはRTOの期間中、すべてのサブフローからデータをバッファリングする必要があります。したがって、サブフロー障害で失速するのを避けるために必要な最小の接続レベルの受信バッファーは、sum（bw_i）*rto_maxです。ここで、各サブフローのbw_i =帯域幅とrto_maxはすべてのサブフローにわたって最大のRTOです。
This is an order of magnitude more than the receive buffer required for a single connection, and is probably too expensive for practical purposes. A more sensible requirement is to avoid stalls in the absence of timeouts. Therefore, the RECOMMENDED receive buffer is 2*sum(BW_i)*RTT_max, where RTT_max is the largest RTT across all subflows. This buffer sizing ensures subflows do not stall when fast retransmit is triggered on any subflow.
これは、単一の接続に必要な受信バッファーよりも数桁高いものであり、おそらく実用的な目的では高すぎます。より賢明な要件は、タイムアウトがない場合に屋台を避けることです。したがって、推奨される受信バッファーは2*sum（bw_i）*rtt_maxです。ここで、rtt_maxはすべてのサブフローにわたって最大のRTTです。このバッファのサイジングにより、サブフローで高速再送信がトリガーされた場合、サブフローが失速しないようにします。
The resulting buffer size should be small enough for practical use. However, there may be extreme cases where fast, high throughput paths (e.g., 100 Mb/s, 10 ms RTT) are used in conjunction with slow paths (e.g., 1 Mb/s, 1000 ms RTT). In that case, the required receive buffer would be 12.5 MB, which is likely too big. In extreme cases such as this example, it may be prudent to only use some of the fastest available paths for the MPTCP connection, potentially using the slow path(s) for backup only.
結果のバッファサイズは、実際に使用するのに十分小さい必要があります。ただし、遅いパス（1 Mb/s、1000 ms RTTなど）と組み合わせて、高速で高スループットパス（100 mb/s、10 ms RTTなど）が使用される極端なケースがある場合があります。その場合、必要な受信バッファーは12.5 MBで、大きすぎる可能性があります。この例のような極端な場合、MPTCP接続で最も速いパスの一部のみを使用することは賢明かもしれません。
Send Buffer: The RECOMMENDED send buffer is the same size as the recommended receive buffer, i.e., 2*sum(BW_i)*RTT_max. This is because the sender must locally store the segments sent but unacknowledged by the connection level ACK. The send buffer size matters particularly for hosts that maintain a large number of ongoing connections. If the required send buffer is too large, a host can choose to only send data on the fast subflows, using the slow subflows only in cases of failure.
送信バッファー：推奨される送信バッファーは、推奨される受信バッファー、つまり2*sum（bw_i）*rtt_maxと同じサイズです。これは、送信者が送信されたセグメントをローカルに保存する必要があるが、接続レベルのACKによって承認されていないためです。送信バッファサイズは、特に多数の継続的な接続を維持するホストにとって重要です。必要な送信バッファーが大きすぎる場合、ホストは、故障の場合にのみ遅いサブフローを使用して、高速サブフローに関するデータのみを送信することを選択できます。
Since MPTCP uses TCP as its subflow transport mechanism, an MPTCP connection will also begin as a single TCP connection. Nevertheless, it must signal to the peer that it supports MPTCP and wishes to use it on this connection. As such, a TCP option will be used to transmit this information, since this is the established mechanism for indicating additional functionality on a TCP session.
MPTCPはTCPをサブフロー輸送メカニズムとして使用するため、MPTCP接続も単一のTCP接続として開始されます。それにもかかわらず、MPTCPをサポートし、この接続で使用したいことをピアに合図する必要があります。そのため、TCPセッションで追加の機能を示すための確立されたメカニズムであるため、TCPオプションを使用してこの情報を送信します。
In addition, further signaling is required during the operation of an MPTCP session, such as that for reassembly across multiple subflows, and for informing the other host about other available IP addresses.
さらに、MPTCPセッションの操作中に、複数のサブフローを横切る再組み立てや他のホストに他の利用可能なIPアドレスについて通知するために、さらなるシグナル伝達が必要です。
The MPTCP protocol design will use TCP options for this additional signaling. This has been chosen as the mechanism most fitting in with the goals as specified in Section 2. With this mechanism, the signaling required to operate MPTCP is transported separately from the data, allowing it to be created and processed separately from the data stream, and retaining architectural compatibility with network entities.
MPTCPプロトコル設計では、この追加のシグナル伝達にTCPオプションを使用します。これは、セクション2で指定されている目標に最も適合するメカニズムとして選択されています。このメカニズムにより、MPTCPを動作させるために必要なシグナル伝達はデータとは別に輸送され、データストリームとは別に作成および処理できるようになり、ネットワークエンティティとのアーキテクチャの互換性を維持します。
This decision is the consensus of the Working Group (following detailed discussions at IETF78), and the main reasons for this are as follows:
この決定は、ワーキンググループのコンセンサスです（IETF78での詳細な議論に続いて）、これの主な理由は次のとおりです。
o TCP options are the traditional signaling method for TCP;
o TCPオプションは、TCPの従来のシグナル伝達方法です。
o A TCP option on a SYN is the most compatible way for an end host to signal it is MPTCP capable;
o synのTCPオプションは、エンドホストがMPTCP対応であることを示す最も互換性のある方法です。
o If connection-level ACKs are signaled in the payload, then they may suffer from packet loss and may be congestion-controlled, which may affect the data throughput in the forward direction and could lead to head-of-line blocking;
o 接続レベルのACKがペイロードで信号を送られている場合、それらはパケット損失に苦しみ、輻輳制御される可能性があり、これは前方向のデータスループットに影響を与え、頭のブロックにつながる可能性があります。
o Middleboxes, such as NAT traversal helpers, can easily parse TCP options, e.g., to rewrite addresses.
o NAT Traversal Helpersなどのミドルボックスは、アドレスを書き換えるために、TCPオプションを簡単に解析できます。
On the other hand, the main drawbacks of TCP options compared to TLV encoding in the payload are the following:
一方、ペイロードでのTLVエンコードと比較したTCPオプションの主な欠点は次のとおりです。
o There is limited space for signaling messages;
o シグナリングメッセージのスペースは限られています。
o A middlebox may, potentially, drop a packet with an unknown option;
o ミドルボックスは、潜在的に、未知のオプションを備えたパケットをドロップする場合があります。
o The transport of control information in options is not necessarily reliable.
o オプションでの制御情報の輸送は、必ずしも信頼できるわけではありません。
The detailed design of MPTCP alleviates these issues as far as possible by carefully considering the size of MPTCP options and seamlessly falling back to regular TCP on the loss of control data.
MPTCPの詳細な設計は、MPTCPオプションのサイズを慎重に検討し、制御データの損失について通常のTCPにシームレスに戻ることにより、これらの問題を可能な限り軽減します。
Both option and payload encoding may interfere with offloading of TCP processing to high-speed network interface cards, such as segmentation, checksumming, and reassembly. For network cards supporting MPTCP, signaling in TCP options should simplify offloading due to the separate handling of MPTCP signaling and data.
オプションとペイロードエンコードの両方が、セグメンテーション、チェックサム、再組み立てなどの高速ネットワークインターフェイスカードへのTCP処理のオフロードを妨げる場合があります。MPTCPをサポートするネットワークカードの場合、TCPオプションのシグナリングは、MPTCPシグナルとデータの個別の処理により、オフロードを簡素化する必要があります。
Currently, the network does not expose path diversity between pairs of IP addresses. In order to achieve path diversity from today's IP networks, in the typical case, MPTCP uses multiple addresses at one or both hosts to infer different paths across the network. It is expected that these paths, whilst not necessarily entirely non-overlapping, will be sufficiently disjoint to allow multipath to achieve improved throughput and robustness. The use of multiple IP addresses is a simple mechanism that requires no additional features in the network.
現在、ネットワークはIPアドレスのペア間のパスの多様性を公開していません。今日のIPネットワークからパスの多様性を達成するために、典型的なケースでは、MPTCPは一方または両方のホストで複数のアドレスを使用して、ネットワーク全体の異なるパスを推測します。これらのパスは、必ずしも完全に完全に重複していないものではありませんが、マルチパスがスループットと堅牢性の改善を実現できるように十分にばらばらになると予想されます。複数のIPアドレスの使用は、ネットワーク内の追加機能を必要としない単純なメカニズムです。
Multiple different (source, destination) address pairs will thus be used as path selectors in most cases. However, each path will be identified by a standard five-tuple (i.e., source address, destination address, source port, destination port, protocol), which can allow the extension of MPTCP to use ports as well as addresses as path selectors. This will allow hosts to use port-based load balancing with MPTCP, for example, if the network routes different ports over different paths (which may be the case with technologies such as Equal Cost MultiPath (ECMP) routing [4]). It should be noted, however, that ISPs often undertake traffic engineering in order to optimize resource utilization within their networks, and care should be taken (by both ISPs and developers) that MPTCP using broadly similar paths does not adversely interfere with this.
したがって、複数の異なる（ソース、宛先）アドレスペアは、ほとんどの場合、パスセレクターとして使用されます。ただし、各パスは、標準の5タプル（つまり、ソースアドレス、宛先アドレス、ソースポート、宛先ポート、プロトコル）によって識別されます。これにより、MPTCPの拡張がポートを使用し、アドレスをパスセレクターとして使用できます。これにより、ホストはMPTCPを使用したポートベースのロードバランスを使用できます。たとえば、ネットワークが異なるパスにわたって異なるポートをルーティングする場合（これは、等しいコストマルチパス（ECMP）ルーティング[4]などのテクノロジーの場合には当てはまります）。ただし、ネットワーク内でのリソース利用を最適化するためにISPが交通工学を引き受けることが多く、MPTCPが広く類似したパスを使用してMPTCPがこれを妨害しないことに注意する必要があることに注意する必要があります。
For an increased chance of successfully setting up additional subflows (such as when one end is behind a firewall, NAT, or other restrictive middlebox), either host SHOULD be able to add new subflows to an MPTCP connection. MPTCP MUST be able to handle paths that appear and disappear during the lifetime of a connection (for example, through the activation of an additional network interface).
追加のサブフローを正常にセットアップする可能性が高くなると（一方の端がファイアウォール、NAT、またはその他の制限的なミドルボックスの後ろにある場合など）、ホストはMPTCP接続に新しいサブフローを追加できるはずです。MPTCPは、接続の存続期間中に表示および消滅するパスを処理できる必要があります（たとえば、追加のネットワークインターフェイスのアクティブ化を介して）。
The path management is a separate function from the packet scheduling, subflow interface, and congestion control functions of MPTCP, as documented in Section 4. As such, it would be feasible to replace this IP-address-based design with an alternative path selection mechanism in the future, with no significant changes to the other functional components.
パス管理は、セクション4で文書化されているように、MPTCPのパケットスケジューリング、サブフローインターフェイス、および輻輳制御機能とは別の関数です。そのため、このIPアドレスベースのデザインを代替パス選択メカニズムに置き換えることができます。将来、他の機能コンポーネントに大きな変化はありません。
Since an MPTCP connection may not be bound to a traditional 5-tuple (source address and port, destination address and port, protocol number) for the entirety of its existence, it is desirable to provide a new mechanism for connection identification. This will be useful for MPTCP-aware applications and for the MPTCP implementation (and MPTCP-aware middleboxes) to have a unique identifier with which to associate the multiple subflows.
MPTCP接続は、その存在全体について、従来の5タプル（ソースアドレスとポート、宛先アドレスとポート、プロトコル番号）にバインドされていない可能性があるため、接続識別のための新しいメカニズムを提供することが望ましいです。これは、MPTCP認識アプリケーションとMPTCP実装（およびMPTCPを認識したミドルボックス）が複数のサブフローを関連付けるための一意の識別子を持つために役立ちます。
Therefore, each MPTCP connection requires a connection identifier at each host, which is locally unique within that host. In many ways, this is analogous to an ephemeral port number in regular TCP. The manifestation and purpose of such an identifier is out of the scope of this architecture document.
したがって、各MPTCP接続には、各ホストの接続識別子が必要です。これは、そのホスト内で局所的にユニークです。多くの点で、これは通常のTCPの一時的なポート番号に類似しています。このような識別子の症状と目的は、このアーキテクチャ文書の範囲外です。
Non-MPTCP-aware applications will not, however, have access to this identifier and in such cases an MPTCP connection will be identified by the 5-tuple of the first TCP subflow. It is out of the scope of this document, however, to define the behavior of the MPTCP implementation if the first TCP subflow later fails. If there are MPTCP-unaware applications that make assumptions about continued existence of the initial address pair, their behavior could be disrupted by carrying on regardless. It is expected that this is a very small, possibly negligible, set of applications, however. MPTCP MUST NOT be used for applications that request to bind to a specific address or interface, since such applications are making a deliberate choice of path in use.
ただし、非MPTCP対応アプリケーションはこの識別子にアクセスできず、そのような場合はMPTCP接続が最初のTCPサブフローの5タプルによって識別されます。ただし、最初のTCPサブフローが後で失敗した場合、MPTCP実装の動作を定義することは、このドキュメントの範囲外です。初期アドレスペアの継続的な存在について仮定を立てるMPTCPとアウェアのアプリケーションがある場合、その動作は、関係なく続行することで破壊される可能性があります。ただし、これは非常に小さく、おそらくごくわずかなアプリケーションセットであると予想されます。MPTCPは、そのようなアプリケーションが使用中のパスの意図的な選択を行っているため、特定のアドレスまたはインターフェイスにバインドすることを要求するアプリケーションに使用してはなりません。
Since the requirements of applications are not clear at this stage, however, it is as yet unconfirmed whether carrying on in the event of the loss of the initial address pair would be a damaging assumption to make. This behavior will be an implementation-specific solution, and as such it is expected to be chosen by implementors once more research has been undertaken to determine its impact.
ただし、この段階ではアプリケーションの要件が明確ではないため、初期アドレスペアが失われた場合に続行することが有害な仮定であるかどうかはまだ未確認です。この動作は実装固有のソリューションであり、そのため、実装者によって選択されることが予想されます。
As discussed in network-layer compatibility requirements Section 2.2.3, there are three goals for the congestion control algorithms used by an MPTCP implementation: improve throughput (at least as well as a single-path TCP connection would perform); do no harm to other network users (do not take up more capacity on any one path than if it was a single path flow using only that route -- this is particularly relevant for shared bottlenecks); and balance congestion by moving traffic away from the most congested paths. To achieve these goals, the congestion control algorithms on each subflow must be coupled in some way. A proposal for a suitable congestion control algorithm is given in [7].
ネットワーク層の互換性要件セクション2.2.3で説明したように、MPTCP実装で使用される渋滞制御アルゴリズムには3つの目標があります。他のネットワークユーザーに害を及ぼさないでください（そのルートのみを使用して単一のパスフローであった場合よりも、1つのパスでより多くの容量を占有しないでください。これは、共有ボトルネックに特に関連しています）。トラフィックを最も混雑した経路から遠ざけることにより、混雑のバランスを取ります。これらの目標を達成するには、各サブフローの輻輳制御アルゴリズムを何らかの方法で結合する必要があります。適切な輻輳制御アルゴリズムの提案は[7]に記載されています。
A detailed threat analysis for Multipath TCP is presented in a separate document [12]. That document focuses on flooding attacks and hijacking attacks that can be launched against a Multipath TCP connection.
MultiPath TCPの詳細な脅威分析は、別の文書[12]に示されています。そのドキュメントは、マルチパスTCP接続に対して開始できる洪水攻撃とハイジャック攻撃に焦点を当てています。
The basic security goal of Multipath TCP, as introduced in Section 2.3, can be stated as: "provide a solution that is no worse than standard TCP".
セクション2.3で導入されたMultiPath TCPの基本的なセキュリティ目標は、「標準のTCPよりも悪くないソリューションを提供する」と述べることができます。
From the threat analysis, and with this goal in mind, three key security requirements can be identified. A multi-addressed Multipath TCP SHOULD be able to do the following:
脅威分析から、そしてこの目標を念頭に置いて、3つの主要なセキュリティ要件を特定できます。多重化されたマルチパスTCPは、次のことを行うことができるはずです。
o Provide a mechanism to confirm that the parties in a subflow handshake are the same as in the original connection setup (e.g., require use of a key exchanged in the initial handshake in the subflow handshake, to limit the scope for hijacking attacks).
o サブフローハンドシェイクの当事者が元の接続セットアップと同じであることを確認するメカニズムを提供します（たとえば、サブフローハンドシェイクの最初の握手でのキーを使用する必要があり、ハイジャック攻撃の範囲を制限します）。
o Provide verification that the peer can receive traffic at a new address before adding it (i.e., verify that the address belongs to the other host, to prevent flooding attacks).
o ピアが新しいアドレスを追加する前に新しいアドレスでトラフィックを受信できることを確認します（つまり、洪水攻撃を防ぐために、住所が他のホストに属していることを確認してください）。
o Provide replay protection, i.e., ensure that a request to add/ remove a subflow is 'fresh'.
o リプレイ保護を提供します。つまり、サブフローを追加/削除するリクエストが「新鮮」であることを確認してください。
Additional mechanisms have been deployed as part of standard TCP stacks to provide resistance to Denial-of-Service (DoS) attacks. For example, there are various mechanisms to protect against TCP reset attacks [18], and Multipath TCP should continue to support similar protection. In addition, TCP SYN Cookies [19] were developed to allow a TCP server to defer the creation of session state in the SYN_RCVD state, and remain stateless until the ESTABLISHED state had been reached. Multipath TCP should, ideally, continue to provide such functionality and, at a minimum, avoid significant computational burden prior to reaching the ESTABLISHED state (of the Multipath TCP connection as a whole).
追加のメカニズムが標準のTCPスタックの一部として展開されており、サービス拒否（DOS）攻撃に対する抵抗を提供します。たとえば、TCPリセット攻撃[18]から保護するさまざまなメカニズムがあり、MultiPath TCPは同様の保護をサポートし続ける必要があります。さらに、TCP Syn Cookie [19]は、TCPサーバーがSyn_RCVD状態でセッション状態の作成を延期することを可能にし、確立された状態に到達するまでステートレスのままにするために開発されました。MultiPath TCPは、理想的には、そのような機能を提供し続け、少なくとも、確立された状態に到達する前に大きな計算負担を回避する必要があります（マルチパスTCP接続全体）。
It should be noted that aspects of the Multipath TCP design space place constraints on the security solution:
マルチパスTCPデザインスペースの側面は、セキュリティソリューションの制約を配置することに注意する必要があります。
o The use of TCP options significantly limits the amount of information that can be carried in the handshake.
o TCPオプションを使用すると、握手で実行できる情報の量が大幅に制限されます。
o The need to work through middleboxes results in the need to handle mutability of packets.
o ミドルボックスを介して作業する必要があるため、パケットの可変性を処理する必要があります。
o The desire to support a 'break-before-make' (as well as a 'make-before-break') approach to adding subflows (within a limited time period) implies that a host cannot rely on using a pre-existing subflow to support the addition of a new one.
o サブフローを追加する（限られた期間内）を追加するための「破損する前に」（および「ブレイク前」）アプローチをサポートしたいという願望は、ホストが既存のサブフローを使用することに依存できないことを意味します。新しいものの追加をサポートします。
The MPTCP protocol will be designed with these security requirements in mind, and the protocol specification [5] will document how these are met.
MPTCPプロトコルは、これらのセキュリティ要件を念頭に置いて設計され、プロトコル仕様[5]は、これらがどのように満たされるかを文書化します。
In the case of applications that have used an existing API call to bind to a specific address or interface, the MPTCP extension MUST NOT be used. This is because the applications are indicating a clear choice of path to use and thus will have expectations of behavior that must be maintained, in order to adhere to the application compatibility goals.
既存のAPI呼び出しを使用して特定のアドレスまたはインターフェイスにバインドしたアプリケーションの場合、MPTCP拡張機能を使用してはなりません。これは、アプリケーションが使用するパスの明確な選択を示しているため、アプリケーションの互換性の目標を遵守するために、維持する必要がある行動に期待されることを示すためです。
Interactions with applications are presented in [8] -- including, but not limited to, performances changes that may be expected, semantic changes, and new features that may be requested through an enhanced API.
アプリケーションとの相互作用は、[8]に示されています。これには、予想されるパフォーマンスの変更、セマンティックな変更、および拡張されたAPIを通じて要求される可能性のある新機能が含まれますが、これらに限定されません。
TCP features the ability to send "Urgent" data, the delivery of which to the application may or may not be out-of-band. The use of this feature is not recommended due to security implications and implementation differences [20]. MPTCP requires contiguous data to support its data sequence mapping over multiple segments, and therefore the Urgent pointer cannot interrupt an existing mapping. An MPTCP implementation MAY choose to support sending Urgent data, and if it does, it SHOULD send the Urgent data on the soonest available unassigned subflow sequence space. Incoming Urgent data SHOULD be mapped to connection-level sequence space and delivered to the application analogous to Urgent data in regular TCP.
TCPは、「緊急」データを送信する機能を備えており、アプリケーションへの配信が帯域外である場合とそうでない場合があります。この機能の使用は、セキュリティへの影響と実装の違いのために推奨されません[20]。MPTCPでは、複数のセグメントでデータシーケンスマッピングをサポートするために連続データが必要であるため、緊急のポインターは既存のマッピングを中断することはできません。MPTCPの実装は、緊急データの送信をサポートすることを選択する場合があります。もしそうなら、最新の未割り当てサブフローシーケンススペースに関する緊急データを送信する必要があります。着信緊急データは、接続レベルのシーケンス空間にマッピングし、通常のTCPの緊急データに類似したアプリケーションに配信する必要があります。
To enable interactions between TCP and network management systems, the TCP [21] and TCP Extended Statistics (ESTATS) [22] MIBs have been defined. MPTCP should share these MIBs for aspects that are designed to be transparent to the application.
TCPとネットワーク管理システム間の相互作用を可能にするために、TCP [21]とTCP拡張統計（ESTAT）[22] MIBSが定義されています。MPTCPは、アプリケーションに対して透過的であるように設計された側面について、これらのMIBを共有する必要があります。
It is anticipated that an MPTCP MIB will be defined in the future, once experience of experimental MPTCP deployments is gathered. This MIB would provide access to MPTCP-specific properties such as whether MPTCP is enabled and the number and properties of the individual paths in use.
実験的なMPTCP展開の経験が収集されると、MPTCP MIBが将来定義されると予想されます。このMIBは、MPTCPが有効になっているかどうか、使用中の個々のパスの数とプロパティなど、MPTCP固有のプロパティへのアクセスを提供します。
As discussed in Section 2.2, it is a goal of MPTCP to be deployable today and thus compatible with the majority of middleboxes. This section summarizes the issues that may arise with NATs, firewalls, proxies, intrusion detection systems, and other middleboxes that, if not considered in the protocol design, may hinder its deployment.
セクション2.2で説明したように、MPTCPが今日展開できるという目標であり、したがって、ミドルボックスの大部分と互換性があります。このセクションでは、NAT、ファイアウォール、プロキシ、侵入検知システム、およびプロトコル設計で考慮されていない場合、その展開を妨げる可能性のあるその他のミドルボックスで発生する可能性のある問題をまとめたものです。
This section is intended primarily as a description of options and considerations only. Protocol-specific solutions to these issues will be given in the companion documents.
このセクションは、主にオプションと考慮事項の説明としてのみ意図されています。これらの問題に対するプロトコル固有のソリューションは、コンパニオンドキュメントに記載されています。
Multipath TCP will be deployed in a network that no longer provides just basic datagram delivery. A myriad of middleboxes are deployed to optimize various perceived problems with the Internet protocols: NATs primarily address IP address space shortage [15], Performance Enhancing Proxies (PEPs) optimize TCP for different link characteristics [17], firewalls [16] and intrusion detection systems try to block malicious content from reaching a host, and traffic normalizers [23] ensure a consistent view of the traffic stream to Intrusion Detection Systems (IDS) and hosts.
MultiPath TCPは、基本的なデータグラム配信だけを提供しなくなるネットワークに展開されます。インターネットプロトコルのさまざまな問題を最適化するために無数のミドルボックスが展開されます。NATは主にIPアドレス空間不足に対処します[15]、パフォーマンスのプロキシ（PEPS）は、さまざまなリンク特性[17]、ファイアウォール[16]、および侵入検出のTCPを最適化しますシステムは悪意のあるコンテンツがホストに到達するのをブロックしようとし、トラフィックノーマイザー[23]は、侵入検知システム（ID）とホストへのトラフィックストリームの一貫したビューを確保します。
All these middleboxes optimize current applications at the expense of future applications. In effect, future applications will often need to behave in a similar fashion to existing ones, in order to increase the chances of successful deployment. Further, the precise behavior of all these middleboxes is not clearly specified, and implementation errors make matters worse, raising the bar for the deployment of new technologies.
これらのミドルボックスはすべて、将来のアプリケーションを犠牲にして現在のアプリケーションを最適化します。実際、将来のアプリケーションは、展開の成功の可能性を高めるために、既存のアプリケーションと同様の方法で動作する必要があることがよくあります。さらに、これらすべてのミドルボックスの正確な動作は明確に指定されておらず、実装エラーがさらに悪化し、新しいテクノロジーの展開のための水準を上げます。
The following list of middlebox classes documents behavior that could impact the use of MPTCP. This list is used in [5] to describe the features of the MPTCP protocol that are used to mitigate the impact of these middlebox behaviors.
MPTCPの使用に影響を与える可能性のあるMiddleboxクラスの次のリストは動作を文書化します。このリストは[5]で使用され、これらのミドルボックスの動作の影響を軽減するために使用されるMPTCPプロトコルの機能を説明します。
o NATs: Network Address Translators decouple the host's local IP address (and, in the case of NAPTs, port) with that which is seen in the wider Internet when the packets are transmitted through a NAT. This adds complexity, and reduces the chances of success, when signaling IP addresses.
o NAT：ネットワークアドレス翻訳者は、ホストのローカルIPアドレス（およびNAPTSの場合、ポート）を、パケットがNATを介して送信されるときにより広いインターネットで見られるものと切り離します。これにより、複雑さが加わり、IPアドレスを信号するときに成功の可能性が減ります。
o PEPs: Performance Enhancing Proxies, which aim to improve the performance of protocols over low-performance (e.g., high-latency or high-error-rate) links. As such, they may "split" a TCP connection and behavior such as proactive ACKing may occur, and therefore it is no longer guaranteed that one host is communicating directly with another. PEPs, firewalls, or other middleboxes may also change the declared receive window size.
o PEPS：パフォーマンスの向上プロキシ。これは、低パフォーマンス（例えば、高層または高誤差）リンクよりもプロトコルのパフォーマンスを改善することを目的としています。そのため、TCP接続を「分割」する可能性があり、プロアクティブアキングなどの動作が発生する可能性があるため、あるホストが別のホストと直接通信していることは保証されなくなります。PEP、ファイアウォール、またはその他のミドルボックスも、宣言された受信ウィンドウサイズを変更する場合があります。
o Traffic Normalizers: These aim to eliminate ambiguities and potential attacks at the network level, and amongst other things, are unlikely to permit holes in TCP-level sequence space (which has an impact on MPTCP's retransmission and subflow sequence numbering design choices).
o トラフィックノーマイザー：これらは、ネットワークレベルでのあいまいさと潜在的な攻撃を排除することを目的としており、とりわけ、TCPレベルのシーケンススペースの穴を許可する可能性は低い（MPTCPの再送信とサブフローシーケンス番号の設計の選択に影響を与える）。
o Firewalls: on top of preventing incoming connections, firewalls may also attempt additional protection such as sequence number randomization (so a sender cannot reliably know what TCP sequence number the receiver will see).
o ファイアウォール：着信接続の防止に加えて、ファイアウォールはシーケンス数のランダム化などの追加の保護を試みることもできます（そのため、送信者は受信機が表示するTCPシーケンス番号を確実に把握できません）。
o IDSs: Intrusion Detection Systems may look for traffic patterns to protect a network and may have false positives with MPTCP and drop the connections during normal operation. Future MPTCP-aware middleboxes will require the ability to correlate the various paths in use.
o IDSS：侵入検知システムは、ネットワークを保護するためのトラフィックパターンを探し、MPTCPで誤検知し、通常の動作中に接続をドロップする場合があります。将来のMPTCP認識中間ボックスには、使用中のさまざまなパスを相関させる機能が必要です。
o Content-Aware Firewalls: Some middleboxes may actively change data in packets, such as rewriting URIs in HTTP traffic.
o コンテンツアウェアファイアウォール：一部のミドルボックスは、HTTPトラフィックでURIを書き換えるなど、パケットのデータを積極的に変更する場合があります。
In addition, all classes of middleboxes may affect TCP traffic in the following ways:
さらに、すべてのクラスのミドルボックスは、次の方法でTCPトラフィックに影響を与える可能性があります。
o TCP Options: some middleboxes may drop packets with unknown TCP options or strip those options from the packets.
o TCPオプション：一部のミドルボックスでは、未知のTCPオプションを使用してパケットをドロップするか、パケットからそれらのオプションを削除する場合があります。
o Segmentation and Coalescing: middleboxes (or even something as close to the end host as TCP Segmentation Offloading (TSO) on a Network Interface Card (NIC)) may change the packet boundaries from those that the sender intended. It may do this by splitting packets or coalescing them together. This leads to two major impacts: where a packet boundary will be cannot be guaranteed and what a middlebox will do with TCP options in these cases (they may be repeated, dropped, or sent only once) cannot be said for sure.
o セグメンテーションと合体：ミドルボックス（または、ネットワークインターフェイスカード（NIC）のTCPセグメンテーションオフロード（TSO）などのエンドホストに近いもの）は、送信者が意図したものからパケットの境界を変更する場合があります。これは、パケットを分割するか、それらを合体化することでこれを行う場合があります。これは2つの大きな影響につながります。パケットの境界を保証することはできません。これらのケースでは、MiddleBoxがTCPオプションで行うこと（繰り返されたり、ドロップしたり、1回だけ送信されたりすることができます）は、確実には言えません。
The authors would like to acknowledge the contributions of Andrew McDonald and Bryan Ford to this document.
著者は、この文書へのアンドリュー・マクドナルドとブライアン・フォードの貢献を認めたいと考えています。
The authors would also like to thank the following people for detailed reviews: Olivier Bonaventure, Gorry Fairhurst, Iljitsch van Beijnum, Philip Eardley, Michael Scharf, Lars Eggert, Cullen Jennings, Joel Halpern, Juergen Quittek, Alexey Melnikov, David Harrington, Jari Arkko, and Stewart Bryant.
著者はまた、詳細なレビューについて以下の人々に感謝したいと思います：Olivier Bonaventure、Gorry Fairhurst、Iljitsch van Beijnum、Philip Eardley、Michael Scharf、Lars Eggert、Cullen Jennings、Joel Halpern、Juergen Quittek、Alexey Melnikov、David Harrington、Jari arkko、そしてスチュワート・ブライアント。
Alan Ford, Costin Raiciu, Mark Handley, and Sebastien Barre are supported by Trilogy (http://www.trilogy-project.org), a research project (ICT-216372) partially funded by the European Community under its Seventh Framework Program. The views expressed here are those of the author(s) only. The European Commission is not liable for any use that may be made of the information in this document.
アラン・フォード、コスティン・ライチウ、マーク・ハンドリー、およびセバスチャン・バレは、第7回のフレームワークプログラムの下でヨーロッパコミュニティから部分的に資金提供されている研究プロジェクト（ICT-216372）である3部作（http://www.trilogy-project.org）によってサポートされています。ここで表現されている見解は、著者のみです。欧州委員会は、この文書の情報から作られている可能性のある使用について責任を負いません。
This informational document provides an architectural overview for Multipath TCP and so does not, in itself, raise any security issues. A separate threat analysis [12] lists threats that can exist with a Multipath TCP. However, a protocol based on the architecture in this document will have a number of security requirements. The high-level goals for such a protocol are identified in Section 2.3, whilst Section 5.8 provides more detailed discussion of security requirements and design decisions which are applied in the MPTCP protocol design [5].
この情報ドキュメントは、MultiPath TCPのアーキテクチャの概要を提供するため、セキュリティの問題を引き起こすことはありません。個別の脅威分析[12]には、マルチパスTCPで存在する可能性のある脅威がリストされています。ただし、このドキュメントのアーキテクチャに基づくプロトコルには、多くのセキュリティ要件があります。このようなプロトコルの高レベルの目標をセクション2.3で特定し、セクション5.8では、MPTCPプロトコル設計に適用されるセキュリティ要件と設計上の決定のより詳細な議論を提供します[5]。
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[1] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Wischik, D., Handley, M., and M. Bagnulo Braun, "The Resource Pooling Principle", ACM SIGCOMM CCR vol. 38 num. 5, pp. 47-52, October 2008, <http://ccr.sigcomm.org/online/files/p47-handleyA4.pdf>.
[3] Wischik、D.、Handley、M。、およびM. Bagnulo Braun、「リソースプーリング原則」、ACM Sigcomm Ccr Vol。38 num。5、pp。47-52、2008年10月、<http://ccr.sigcomm.org/online/files/p47 handleya4.pdf>。
[4] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000.
[4] Hopps、C。、「等しいコストのマルチパスアルゴリズムの分析」、RFC 2992、2000年11月。
[5] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", Work in Progress, March 2011.
[5] Ford、A.、Raiciu、C.、Handley、M。、およびO. Bonaventure、「複数のアドレスを備えたマルチパス操作のためのTCP拡張」、2011年3月、作業中。
[6] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[6] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[7] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", Work in Progress, March 2011.
[7] Raiciu、C.、Handley、M。、およびD. Wischik、「マルチパス輸送プロトコルの渋滞制御と結合した」、2011年3月に進行中。
[8] Scharf, M. and A. Ford, "MPTCP Application Interface Considerations", Work in Progress, March 2011.
[8] Scharf、M。and A. Ford、「MPTCPアプリケーションインターフェイスの考慮事項」、2011年3月、進行中の作業。
[9] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[9] カーペンター、B。およびS.ブリム、「ミドルボックス：分類法と問題」、RFC 3234、2002年2月。
[10] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[10] カーペンター、B。、「インターネット透明性」、RFC 2775、2000年2月。
[11] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[11] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Aumponed Coundment Options」、RFC 2018、1996年10月。
[12] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, March 2011.
[12] Bagnulo、M。、「複数のアドレスを備えたマルチパス操作のためのTCP拡張の脅威分析」、RFC 6181、2011年3月。
[13] Becke, M., Dreibholz, T., Iyengar, J., Natarajan, P., and M. Tuexen, "Load Sharing for the Stream Control Transmission Protocol (SCTP)", Work in Progress, December 2010.
[13] Becke、M.、Dreibholz、T.、Iyengar、J.、Natarajan、P。、およびM. Tuexen、「Stream Control Transmission Protocol（SCTP）の負荷共有」、2010年12月の進行中。
[14] Ford, B. and J. Iyengar, "Breaking Up the Transport Logjam", ACM HotNets, October 2008.
[14] Ford、B。、およびJ. Iyengar、「Transport Logjamの分割」、ACM HotNets、2008年10月。
[15] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[15] Srisuresh、P。およびK. Egevang、「従来のIPネットワークアドレス翻訳者（従来のNAT）」、RFC 3022、2001年1月。
[16] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[16] Freed、N。、「インターネットファイアウォールの行動と要件」、RFC 2979、2000年10月。
[17] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
[17] Border、J.、Kojo、M.、Griner、J.、Montenegro、G。、およびZ. Shelby、「リンク関連の劣化を緩和することを目的としたプロキシを向上させるパフォーマンス」、RFC 3135、2001年6月。
[18] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
[18] Ramaiah、A.、Stewart、R。、およびM. Dalal、「Window In-Window攻撃に対するTCPの堅牢性の向上」、RFC 5961、2010年8月。
[19] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[19] Eddy、W。、「TCP Syn Flooding Attacks and Common Mitigations」、RFC 4987、2007年8月。
[20] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, January 2011.
[20] Gont、F。and A. Yourtchenko、「TCP緊急メカニズムの実装について」、RFC 6093、2011年1月。
[21] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005.
[21] Raghunarayan、R。、「送信制御プロトコルの管理情報ベース（TCP）」、RFC 4022、2005年3月。
[22] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP Extended Statistics MIB", RFC 4898, May 2007.
[22] Mathis、M.、Heffner、J。、およびR. Raghunarayan、「TCP Extended Statistics MIB」、RFC 4898、2007年5月。
[23] Handley, M., Paxson, V., and C. Kreibich, "Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics", Usenix Security 2001, 2001, <http:// www.usenix.org/events/sec01/full_papers/handley/handley.pdf>.
[23] Handley、M.、Paxson、V。、およびC. Kreibich、「ネットワーク侵入検出：回避、トラフィックの正規化、およびエンドツーエンドプロトコルセマンティクス」、Usenix Security 2001、2001、<http：// www.usenix。org/events/sec01/full_papers/handley/handley.pdf>。
Authors' Addresses
著者のアドレス
Alan Ford Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK Phone: +44 1794 833 465 EMail: alan.ford@roke.co.uk
Alan Ford Roke Manor Research Old Salisbury Lane Romsey、Hampshire SO51 0ZN UK電話：44 1794 833 465メール：alan.ford@roke.co.uk
Costin Raiciu University College London Gower Street London WC1E 6BT UK EMail: c.raiciu@cs.ucl.ac.uk
Costin Raiciu University College London Gower Street London WC1E 6BT UKメール：c.raiciu@cs.ucl.ac.uk
Mark Handley University College London Gower Street London WC1E 6BT UK EMail: m.handley@cs.ucl.ac.uk
マークハンドリー大学カレッジロンドンガワーストリートロンドンWC1E 6BT UKメール：m.handley@cs.ucl.ac.uk
Sebastien Barre Universite catholique de Louvain Pl. Ste Barbe, 2 Louvain-la-Neuve 1348 Belgium Phone: +32 10 47 91 03 EMail: sebastien.barre@uclouvain.be
Sebastien Barre Universite Catholique de Louvain Pl。Ste Barbe、2 Louvain-La-Neuve 1348 Belgium電話：32 10 47 91 03メール：sebastien.barre@uclouvain.be
Janardhan Iyengar Franklin and Marshall College Mathematics and Computer Science PO Box 3003 Lancaster, PA 17604-3003 USA Phone: 717-358-4774 EMail: jiyengar@fandm.edu
Janardhan Iyengar Franklin and Marshall College Mathematics and Computer Science PO Box 3003 Lancaster、PA 17604-3003 USA電話：717-358-4774メール：jiyengar@fandm.edu