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



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.


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.


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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
1. Introduction
1. はじめに

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.


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:


o To increase the resilience of the connectivity by providing multiple paths, protecting end hosts from the failure of one.


o To increase the efficiency of the resource usage, and thus increase the network capacity available to end hosts.


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].


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.


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).


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を満たすように設計された目標を、 (ⅱ)それは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.


1.1. Requirements Language
1.1. 要件言語

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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。

1.2. Terminology
1.2. 用語

Regular/Single-Path TCP: The standard version of TCP [1] in use today, operating between a single pair of IP addresses and ports.


Multipath TCP: A modified version of the TCP protocol that supports the simultaneous use of multiple paths between hosts.


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.


MPTCP: The proposed protocol extensions specified in [5] to provide a Multipath TCP implementation.


Subflow: A flow of TCP segments operating over an individual path, which forms part of a larger Multipath TCP connection.


(Multipath TCP) Connection: A set of one or more subflows combined to provide a single Multipath TCP service to an application at a host.


1.3. Reference Scenario
1.3. レファレンス・シナリオ

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に示されている図は、マルチパスTCPのための典型的な使用シナリオを示す図です。 2つのホストA及びBは、互いに通信しています。これらのホストは、インターネットへの2つの互いに素な接続を提供する、マルチホームおよびマルチ対処されています。各ホストのアドレスがA1、A2、B1、及びB2と称します。 A1-B1、A1-B2、A2-B1、A2-B2:2つのホスト間従ってに最大4つの異なる経路が存在します。

               +------+           __________           +------+
               |      |A1 ______ (          ) ______ B1|      |
               | Host |--/      (            )      \--| Host |
               |      |        (   Internet   )        |      |
               |  A   |--\______(            )______/--|   B  |
               |      |A2        (__________)        B2|      |
               +------+                                +------+

Figure 1: Simple Multipath TCP Usage Scenario


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.

シナリオ(1>即ち、num_addr(A)* num_addr(B))であれば、2つのホスト間の利用可能なパスの数が2以上であるように、各ホスト上のアドレス(1以上)の任意の数を有することができます。インターネットを介してこれらのアドレスの組み合わせによって作成されたパスは、完全に互いに素である必要はない - 共有ボトルネックによって導入可能性、公平性の問題は、マルチパスTCPの輻輳制御装置によって処理される必要があります。また、インターネットを介した経路は、多くの場合、純粋なエンドツーエンドのサービスを提供せず、その代わりに、そのようなNATのファイアウォールのような中間装置によって影響され得ます。

2. Goals

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.


2.1. Functional Goals
2.1. 機能目標

In supporting the use of multiple paths, Multipath TCP has the following two functional goals.


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 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.


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.


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.


2.2. Compatibility Goals
2.2. 互換性の目標

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.


2.2.1. Application Compatibility
2.2.1. アプリケーションの互換性

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.


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].

インオーダー、信頼性、およびバイト指向の配信:マルチパスTCPは、[1] TCPと同じサービスモデルに従わなければなりません。また、マルチパス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節で述べたように、これは、しかし、セキュリティメカニズムの制約を課します。この関数のタイムアウトは、ローカルに設定されます。

2.2.2. Network Compatibility
2.2.2. ネットワークの互換性

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]中間装置の増殖を伴うインターネットで「グランドトゥルース」を反映していません。 Middleboxesは定期輸送層の上に挟み込みます。図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


   +-------------+                                       +-------------+
   | Application |<------------ end-to-end ------------->| Application |
   +-------------+                     +-------------+   +-------------+
   |  Transport  |<------------------->|  Transport  |<->|  Transport  |
   +-------------+   +-------------+   +-------------+   +-------------+
   |   Network   |<->|   Network   |<->|   Network   |<->|   Network   |
   +-------------+   +-------------+   +-------------+   +-------------+
      End Host           Router         NAT, or Proxy      End Host

Figure 3: Internet Reality


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.

「運命の共有」の損失にトランスポート層の結果に挟んでのMiddleboxes [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を制約します。 「エンドツーendness」輸送のを確実にするために、マルチパス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.


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.


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.


2.2.3. Compatibility with Other Network Users
2.2.3. ネットワークのほかのユーザーとの互換性

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.


2.3. Security Goals
2.3. セキュリティ目標

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.


2.4. Related Protocols
2.4. 関連するプロトコル

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においては、主な使用ケースは、マルチホームホスト(すなわち、単一のパスがそのエンドホストアドレスのいずれかを変化させる)ための冗長性と移動性をサポートすることです。複数のパスの同時使用はサポートされていません。拡張機能は、同時マルチ輸送[13]をサポートするために提案されているが、これらは標準化することがまだあります。これまでで最も広く使用されているストリームベースのトランスポートプロトコルは、しかし、TCP [1]、およびSCTPは、2.2節で指定されたネットワークとアプリケーションの互換性の目標を満たしていないされています。ネットワークの互換性のために、SCTPを知らない、その結果、それをブロックしてしまう様々なミドルボックス(特にNATを)との問題があります。アプリケーションの互換性のために、アプリケーションは、積極的にSCTPを使用することを選択する必要があり、展開の問題で、非常に少数のは、そうすることを選択します。 MPTCPの互換性の目標は、一部にSCTPの展開の問題のこれらの観察に基づいています。

3. An Architectural Basis for Multipath TCP

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.


          |    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


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.

アプリケーション指向の「意味」層は、アプリケーションのエンドツーを支持及び保護の懸念によって主に駆動される機能を実現する、図4に示すようにTNGは緩く、「アプリケーション指向」および「ネットワーク志向」層にトランスポート層を分割しますネットワーク指向の「フロー+エンドポイント」層は、エンドポイント識別子(使用ポート番号)と輻輳制御などの機能を実現しながら、通信を終了します。これらのネットワーク指向の機能に、伝統的に表向きは「エンドツーエンドの」トランスポート層に位置しながら、ネットワークオペレータと、彼らはネットワーク利用ポリシーを強制するために、ネットワーク内に展開する中間ボックスに大きな懸念であることが実際に証明されている[15] [16]または通信性能を最適化する[17]。図5は、中間装置は、トランスポート層のこの分解モデルに異なる層と相互作用する方法を示していますネットワーク志向層「セグメントごとの」動作によって際に介在させることができるしながらアプリケーション指向層は、エンド・ツー・エンドを操作しますミドルボックス。

   +-------------+                                       +-------------+
   | Application |<------------ end-to-end ------------->| Application |
   +-------------+                                       +-------------+
   |  Semantic   |<------------ end-to-end ------------->|  Semantic   |
   +-------------+   +-------------+   +-------------+   +-------------+
   +-------------+   +-------------+   +-------------+   +-------------+
   |   Network   |<->|   Network   |<->|   Network   |<->|   Network   |
   +-------------+   +-------------+   +-------------+   +-------------+
                        Firewall         Performance
      End Host           or NAT        Enhancing Proxy      End Host

Figure 5: Middleboxes in the New Internet Model


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.

アプリケーションデータ及び信頼性のグローバルな順序付けのTCPのような意味の保存を介してアプリケーションの互換性を提供する図6 MPTCPに示すようにMPTCPの建築設計は、TNGの分解を以下、「アプリケーション指向」セマンティックレイヤのインスタンスです。ネットワークにおける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)


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.


4. A Functional Decomposition of MPTCP
4. MPTCPの機能分解

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.


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.


                                   |           Application         |
      +---------------+            +-------------------------------+
      |  Application  |            |             MPTCP             |
      +---------------+            + - - - - - - - + - - - - - - - +
      |      TCP      |            | Subflow (TCP) | Subflow (TCP) |
      +---------------+            +-------------------------------+
      |      IP       |            |       IP      |      IP       |
      +---------------+            +-------------------------------+

Figure 7: Comparison of Standard TCP and MPTCP Protocol Stacks


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:


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パケットスケジューリング:この関数は、利用可能なサブフローのいずれかに送信されるセグメントにアプリケーションから受信したバイトストリームを壊します。 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.


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].


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つのホスト間の複数のパスの発見(及び必要に応じて、初期化)した後に見えます。パケットスケジューラは、ネットワーク宛のアプリケーションからデータのストリームを受信し、そして上にそれを送信する前に(例えば、接続レベルのセグメントにデータをセグメント化し、接続レベルのシーケンス番号を追加するなど)、その上に必要な操作を行っていサブフロー。サブフローはその後、自身のシーケンス番号、ACKを追加し、ネットワークに渡します。 (必要な場合)サブフロー再注文データを受信し、接続レベルの再順序付けを実行し、アプリケーションにデータストリームを送信するパケットスケジューリングコンポーネントに渡します。最後に、輻輳制御コンポーネントは、サブフローにどの速度で送信すべきセグメントをスケジュールするために、パケットスケジューリングの一部として存在します。

5. High-Level Design Decisions

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.


5.1. Sequence Numbering
5.1. シーケンス番号

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.


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).


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.


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.


5.2. Reliability and Retransmissions
5.2. 信頼性および再送信

MPTCP features acknowledgements at connection-level as well as subflow-level acknowledgements, in order to provide a robust service to the application.


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は接続レベルのセグメントが受信されたときを決定するデータ列マッピングとサブフローACKを使用することができます。サブフローのためのTCP ACKの送信は、TCPのセマンティクスを維持し、サブフローレベルの再送信をトリガするために、サブフローレベルで完全に処理されます。これは、エンド・ツー・エンドのセマンティクス上の特定の意味を持ちます。これは、セグメントがサブフローレベルでACKされると、それが接続レベルでのリオーダバッファで廃棄することができないことを意味します。必要であれば第二に、標準の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).


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].


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.


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.


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.


5.3. Buffers
5.3. バッファ

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.


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 =ラウンドトリップ時間)。一BDPは、ネットワークによってセグメントの並べ替えをサポートすることができます。他のBDPは、接続が高速再送信の間継続することを可能にする:セグメントが高速再送信された場合、受信機は、一以上の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.


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の期間中、すべてのサブフローからのデータをバッファリングしなければなりません。したがって、最小の接続レベルは、サブフロー障害に失速を回避するために必要とされる受信バッファ各サブフローのためBW_i =帯域幅(BW_i)* RTO_max、合計であり、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 *和RTT_maxすべてサブフローを横切る最大RTTである(BW_i)* RTT_max、ある受け取ります。このバッファのサイズは、高速再送信がどのサブフローにトリガされたときのサブフローが失速していない保証します。

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.


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 *の和(BW_i)* RTT_max。送信者がローカルに接続レベルのACKによって送られたが、未確認のセグメントを保存する必要があるためです。送信バッファサイズは、進行中の多数の接続を維持するホストに対して特に重要。必要な送信バッファが大きすぎると、ホストはのみだけで障害が発生した場合にスローサブフローを使用して、高速なサブフローにデータを送信するように選択することができます。

5.4. Signaling
5.4. シグナリング

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.


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.


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.


This decision is the consensus of the Working Group (following detailed discussions at IETF78), and the main reasons for this are as follows:


o TCP options are the traditional signaling method for 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 Middleboxes, such as NAT traversal helpers, can easily parse TCP options, e.g., to rewrite addresses.


On the other hand, the main drawbacks of TCP options compared to TLV encoding in the payload are the following:


o There is limited space for signaling messages;


o A middlebox may, potentially, drop a packet with an unknown option;


o The transport of control information in options is not necessarily reliable.


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.


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とデータの別々の取り扱いに起因するオフロード簡素化すべきです。

5.5. Path Management
5.5. パス管理

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.


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の拡張は、パスセレクタとしてポートならびにアドレスを使用できるようにすることができ、。異なる経路を介してネットワーク経路の異なるポート(例えば等価コストマルチパス(ECMPなどの技術を有する場合であってもよい)[4]経路)場合、これは、ホストは、例えば、MPTCPとバランスポート・ベースのロードを使用できるようになります。 ISPが、多くの場合、そのネットワーク内でのリソース使用率を最適化するために、トラフィック・エンジニアリングを行う、とケアがMPTCPに悪影響をこれに干渉しない広く類似のパスを使用していること(ISPや開発者の両方で)取られるべきであることに留意すべきです。

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.


5.6. Connection Identification
5.6. 接続識別

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.


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.


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.


5.7. Congestion Control
5.7. 輻輳制御

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つの目標がある:スループットを向上させる(少なくともならびに単一パスTCP接続が行うであろう)。他のネットワークユーザーに害しない(それだけでそのルートを使用して、単一パスの流れだった場合よりもいずれかのパスでより多くの容量を占有していない - これは、共有ボトルネックのために特に関連があります)。そして離れて最も混雑のパスからのトラフィックを移動することで輻輳のバランスをとります。これらの目標を達成するために、各サブフローの輻輳制御アルゴリズムは、何らかの方法で結合されなければなりません。適切な輻輳制御アルゴリズムの提案は[7]で与えられます。

5.8. Security
5.8. セキュリティ

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.


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".


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:


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 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 Provide replay protection, i.e., ensure that a request to add/ remove a subflow is 'fresh'.


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).

追加のメカニズムは、サービス拒否(DoS)攻撃に対する耐性を提供するために、標準のTCPスタックの一部として展開されています。たとえば、TCPから保護するためのさまざまなメカニズムが存在し、攻撃[18]をリセットして、マルチパスTCPは、同様の保護をサポートするために継続すべきです。また、TCP SYNクッキー[19]はTCPサーバがSYN_RCVD状態でセッション状態の作成を延期できるようにするために開発され、ESTABLISHED状態に達するまでステートレス残りました。マルチパスTCPは、理想的には、このような機能を提供し続けると、最低でも、前に(全体としてマルチTCPコネクションの)ESTABLISHED状態に到達する大きな計算負荷を避ける必要があります。

It should be noted that aspects of the Multipath TCP design space place constraints on the security solution:


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 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.


The MPTCP protocol will be designed with these security requirements in mind, and the protocol specification [5] will document how these are met.


6. Software Interactions
6.1. Interactions with Applications
6.1. アプリケーションとの相互作用

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.


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で緊急データに類似したアプリケーションに送達されるべきです。

6.2. Interactions with Management Systems
6.2. 管理システムとの相互作用

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拡張統計(ESTATS)は、[22] MIBは定義されています。 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が有効であるかどうかなどの特性と、使用中の個々のパスの数およびプロパティへのアクセスを提供するであろう。

7. Interactions with Middleboxes
Middleboxes 7.相互作用

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.


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.


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.


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の:ネットワークアドレス変換器は、パケットがNATを介して送信されたときに、より広いインターネットで見られるもので、ホストのローカルIPアドレス(および、NAPTsの場合には、ポート)を切り離します。これは、複雑さを追加し、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のPEP:パフォーマンス強化プロキシ、低性能(例えば、高いレイテンシまたは高エラーレート)上プロトコルの性能を改善することを目的とリンク。そのため、彼らは、このような積極的な肯定応答(ACK)などの「スプリット」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 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 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 Content-Aware Firewalls: Some middleboxes may actively change data in packets, such as rewriting URIs in HTTP traffic.


In addition, all classes of middleboxes may affect TCP traffic in the following ways:


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.


8. Contributors

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.

オリヴィエ・ボナベンチャー、Gorry Fairhurst、IljitschバンBeijnum、フィリップEardley、マイケル・シャーフ、ラースEggertの、カレン・ジェニングス、ジョエル・ハルパーン、ユルゲンQuittek、アレクセイ・メルニコフ、デヴィッド・ハリントン、ヤリArkko:著者らはまた、詳細なレビューのために、次の人に感謝したいと思います、そしてスチュワートブライアント。

9. Acknowledgements

Alan Ford, Costin Raiciu, Mark Handley, and Sebastien Barre are supported by Trilogy (, 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.


10. Security Considerations

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].

この情報のドキュメントは、マルチパスTCPのためのアーキテクチャの概要を説明しますので、それ自体は、どのようなセキュリティ上の問題を提起しません。別の脅威分析[12]はマルチパスTCPで存在することができ脅威を示しています。しかし、この文書に記載されているアーキテクチャに基づいたプロトコルは、セキュリティ要件の数を持っています。セクション5.8 MPTCPプロトコル設計[5]に適用されるセキュリティ要件及び設計上の決定のより詳細な議論を提供しながら、そのようなプロトコルのための高レベルの目標は、セクション2.3で特定されます。

11. References
11.1. Normative References
11.1. 引用規格

[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[1]ポステル、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

11.2. Informative References
11.2. 参考文献

[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, <>.

[3] Wischik、D.、ハンドレー、M.、およびM. Bagnuloブラウン、 "リソースプーリング原理"、ACM SIGCOMM CCR体積。 38 NUM。 5、頁47-52、2008年10月、<>。

[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]フォード、A.、Raiciu、C.、ハンドリー、M.、およびO.ボナベンチャー、 "複数のアドレスを持つマルチパス操作のためのTCP拡張機能"、進歩、2011年3月に作業。

[6] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.

[6]スチュワート、R.、 "ストリーム制御伝送プロトコル"、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.、ハンドリー、M.、およびD. Wischik、 "マルチパストランスポートプロトコルのための結合輻輳制御"、進歩、2011年3月に作業。

[8] Scharf, M. and A. Ford, "MPTCP Application Interface Considerations", Work in Progress, March 2011.

[8]シャーフ、M.とA.フォード、 "MPTCPアプリケーションインターフェイスに関する注意事項"、進歩、2011年3月に作業。

[9] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.

[9]大工、B.とS.つば、 "のMiddleboxes:分類と課題"、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]マティス、M.、Mahdavi、J.、フロイド、S.、とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。

[12] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, March 2011.

"複数のアドレスを持つマルチパス操作のためのTCP拡張のための脅威分析" [12] Bagnulo、M.、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]ベッケ、M.、Dreibholz、T.、アイアンガー、J.、Natarajan、P.、およびM. Tuexen、 "ストリーム制御伝送プロトコル(SCTP)のための負荷分散" は進歩、2010年12月ワーク。

[14] Ford, B. and J. Iyengar, "Breaking Up the Transport Logjam", ACM HotNets, October 2008.

[14]フォード、B.とJ.アイアンガー、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]フリード、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]ボーダー、J.、古城、M.、Griner、J.、モンテネグロ、G.、およびZ.シェルビー、 "パフォーマンスプロキシは、リンク関連の劣化を軽減することを目的と強化"、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.、スチュワート、R.、およびM. Dalalは、RFC 5961、2010年8月 "ブラインドウィンドウ攻撃に対してTCPのロバスト性を向上させます"。

[19] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.

[19]エディ、W.、 "TCPのSYNフラッド攻撃と共通の軽減策"、RFC 4987、2007年8月。

[20] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, January 2011.

[20] "TCP緊急機構の実現について" Gont、F.およびA. Yourtchenko、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]マシス、M.、Heffner、J.、およびR. Raghunarayan、2007年5月、RFC 4898 "TCPは、統計情報MIBを拡張しました"。

[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://>.

[23]ハンドリー、M.、パクソン、V.、およびC. Kreibich、 "ネットワーク侵入検知:回避、トラフィック正規化、およびエンドツーエンドのプロトコルセマンティクス"、のUsenixセキュリティ2001、2001、<のhttp:// WWW /イベント/ SEC01 / full_papers /ハンドリー/ handley.pdf>。

Authors' Addresses


Alan Ford Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK Phone: +44 1794 833 465 EMail:

アラン・フォードRokeマナー研究オールド・ソールズベリーレーンロムジー、ハンプシャーSO51 0ZN英国電話:+44 1794 833 465 Eメール

Costin Raiciu University College London Gower Street London WC1E 6BT UK EMail:

コスティンRaiciuロンドン大学ガウアーストリートロンドンWC1E 6BTイギリスのEメール

Mark Handley University College London Gower Street London WC1E 6BT UK EMail:

マーク・ハンドリーロンドン大学ガウアーストリートロンドンWC1E 6BTイギリスのEメール

Sebastien Barre Universite catholique de Louvain Pl. Ste Barbe, 2 Louvain-la-Neuve 1348 Belgium Phone: +32 10 47 91 03 EMail:

。セバスチャン・ルーベン・カトリック大学バレP1のスイートバーベ、2ルーヴァン=ラ=ヌーヴ1348ベルギー電話:+32 10 47 91 03 Eメール

Janardhan Iyengar Franklin and Marshall College Mathematics and Computer Science PO Box 3003 Lancaster, PA 17604-3003 USA Phone: 717-358-4774 EMail:

Janardhanアイアンガーフランクリンやマーシャル・カレッジ数学とコンピュータサイエンス私書箱3003ランカスター、PA 17604から3003 USA電話:717-358-4774 Eメール