[要約] RFC 6897は、Multipath TCP（MPTCP）アプリケーションインターフェースの考慮事項に関するドキュメントです。このRFCの目的は、MPTCPを使用するアプリケーションの開発者に対して、MPTCPの実装と統合に関するガイダンスを提供することです。
Internet Engineering Task Force (IETF) M. Scharf
Request for Comments: 6897 Alcatel-Lucent Bell Labs
Category: Informational A. Ford
ISSN: 2070-1721 Cisco
March 2013
Multipath TCP (MPTCP) Application Interface Considerations
マルチパスTCP（MPTCP）アプリケーションインターフェイスの考慮事項
Abstract
概要
Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface that is a simple extension of TCP's interface for MPTCP-aware applications.
マルチパスTCP（MPTCP）は、通常のTCPセッションに複数のパスを使用する機能を追加します。アプリケーションと完全に下位互換性を持つように設計されていますが、データ転送は通常のTCPとは異なり、アプリケーションが活用したい自由度がいくつかあります。このドキュメントでは、MPTCPがパフォーマンスの変化など、アプリケーションに与える影響をまとめています。さらに、MPTCP非対応アプリケーションと組み合わせたMPTCPの互換性の問題についても説明します。最後に、このドキュメントでは、MPTCP対応アプリケーション用のTCPインターフェースの単純な拡張である基本的なアプリケーションインターフェースについて説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc6897.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6897で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Comparison of MPTCP and Regular TCP .............................5
3.1. Effect on Performance ......................................5
3.1.1. Throughput ..........................................5
3.1.2. Delay ...............................................6
3.1.3. Resilience ..........................................7
3.2. Potential Problems .........................................8
3.2.1. Impact of Middleboxes ...............................8
3.2.2. Dealing with Multiple Addresses inside
Applications ........................................9
3.2.3. Security Implications ..............................10
4. Operation of MPTCP with Legacy Applications ....................10
4.1. Overview of the MPTCP Network Stack .......................10
4.2. Address Issues ............................................11
4.2.1. Specification of Addresses by Applications .........11
4.2.2. Querying of Addresses by Applications ..............12
4.3. MPTCP Connection Management ...............................13
4.3.1. Reaction to Close Call by Application ..............13
4.3.2. Other Connection Management Functions ..............13
4.4. Socket Option Issues ......................................13
4.4.1. General Guideline ..................................13
4.4.2. Disabling of the Nagle Algorithm ...................13
4.4.3. Buffer Sizing ......................................14
4.4.4. Other Socket Options ...............................14
4.5. Default Enabling of MPTCP .................................14
4.6. Summary of Advice to Application Developers ...............15
5. Basic API for MPTCP-Aware Applications .........................15
5.1. Design Considerations .....................................15
5.2. Requirements on the Basic MPTCP API .......................16
5.3. Sockets Interface Extensions by the Basic MPTCP API .......17
5.3.1. Overview ...........................................17
5.3.2. Enabling and Disabling of MPTCP ....................19
5.3.3. Binding MPTCP to Specified Addresses ...............19
5.3.4. Querying the MPTCP Subflow Addresses ...............20
5.3.5. Getting a Unique Connection Identifier .............20
6. Other Compatibility Issues .....................................21
6.1. Usage of TLS over MPTCP ...................................21
6.2. Usage of the SCTP Sockets API .............................21
6.3. Incompatibilities with Other Multihoming Solutions ........21
6.4. Interactions with DNS .....................................22
7. Security Considerations ........................................22
8. Conclusion .....................................................23
9. Acknowledgments ................................................23
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................24
Appendix A. Requirements on a Future Advanced MPTCP API ...........26
A.1. Design Considerations ......................................26
A.2. MPTCP Usage Scenarios and Application Requirements .........27
A.3. Potential Requirements on an Advanced MPTCP API ............29
A.4. Integration with the SCTP Sockets API ......................30
Multipath TCP adds the capability of using multiple paths to a regular TCP session [1]. The motivations for this extension include increasing throughput, overall resource utilization, and resilience to network failure, and these motivations are discussed, along with high-level design decisions, as part of the multipath TCP architecture [4]. MPTCP [5] offers the same reliable, in-order, byte-stream transport as TCP and is designed to be backward compatible with both applications and the network layer. It requires support inside the network stack of both endpoints.
マルチパスTCPは、通常のTCPセッションに複数のパスを使用する機能を追加します[1]。この拡張の動機には、スループットの向上、全体的なリソース使用率、ネットワーク障害への回復力が含まれます。これらの動機は、マルチパスTCPアーキテクチャの一部として、高レベルの設計決定とともに説明されます[4]。 MPTCP [5]は、TCPと同じ信頼性の高い、順序正しいバイトストリームトランスポートを提供し、アプリケーションとネットワークレイヤーの両方との下位互換性を持つように設計されています。両方のエンドポイントのネットワークスタック内でのサポートが必要です。
This document first presents the effects that MPTCP may have on applications, such as performance changes compared to regular TCP. Second, it defines the interoperation of MPTCP and applications that are unaware of the multipath transport. MPTCP is designed to be usable without any application changes, but some compatibility issues have to be taken into account. Third, this memo specifies a basic Application Programming Interface (API) for MPTCP-aware applications. The API presented here is an extension to the regular TCP API to allow an MPTCP-aware application the equivalent level of control and access to information of an MPTCP connection that would be possible with the standard TCP API on a regular TCP connection.
このドキュメントでは、最初に、通常のTCPと比較したパフォーマンスの変化など、MPTCPがアプリケーションに与える影響について説明します。次に、MPTCPとマルチパストランスポートを認識しないアプリケーションの相互運用を定義します。 MPTCPはアプリケーションを変更せずに使用できるように設計されていますが、いくつかの互換性の問題を考慮する必要があります。 3番目に、このメモはMPTCP対応アプリケーションの基本的なアプリケーションプログラミングインターフェイス（API）を指定します。ここで紹介するAPIは、通常のTCP APIの拡張機能であり、MPTCP対応のアプリケーションが、通常のTCP接続の標準TCP APIで可能なMPTCP接続の情報と同等の制御とアクセスを可能にします。
The de facto standard API for TCP/IP applications is the "sockets" interface [8]. This document provides an abstract definition of MPTCP-specific extensions to this interface. These are operations that can be used by an application to get or set additional MPTCP-specific information on a socket, in order to provide an equivalent level of information and control over MPTCP as exists for an application using regular TCP. It is up to the applications, high-level programming languages, or libraries to decide whether to use these optional extensions. For instance, an application may want to turn on or off the MPTCP mechanism for certain data transfers or limit its use to certain interfaces. The abstract specification is in line with the Portable Operating System Interface (POSIX) standard [8] as much as possible.
TCP / IPアプリケーションの事実上の標準APIは、「ソケット」インターフェースです[8]。このドキュメントは、このインターフェイスに対するMPTCP固有の拡張の抽象的な定義を提供します。これらは、通常のTCPを使用するアプリケーションに存在するのと同等レベルの情報とMPTCPの制御を提供するために、アプリケーションがソケットで追加のMPTCP固有の情報を取得または設定するために使用できる操作です。これらのオプションの拡張機能を使用するかどうかを決定するのは、アプリケーション、高水準プログラミング言語、またはライブラリです。たとえば、アプリケーションは、特定のデータ転送のMPTCPメカニズムをオンまたはオフにしたり、その使用を特定のインターフェイスに制限したりする場合があります。抽象仕様は、可能な限りポータブルオペレーティングシステムインターフェイス（POSIX）標準[8]に準拠しています。
An advanced API for MPTCP is outside the scope of this document. Such an advanced API could offer a more fine-grained control over multipath transport functions and policies. The appendix includes a brief, non-compulsory list of potential features of such an advanced API.
MPTCPの高度なAPIは、このドキュメントの範囲外です。このような高度なAPIを使用すると、マルチパス転送機能とポリシーをより細かく制御できます。付録には、そのような高度なAPIの潜在的な機能の簡単な必須リストが含まれています。
There can be interactions or incompatibilities of MPTCP with other APIs or sockets interface extensions, which are discussed later in this document. Some network stack implementations, especially on mobile devices, have centralized connection managers or other higher-level APIs to solve multi-interface issues, as surveyed in [15]. Their interaction with MPTCP is outside the scope of this document.
MPTCPと他のAPIまたはソケットインターフェイス拡張との相互作用または非互換性がある可能性があります。これらについては、このドキュメントで後述します。 [15]で調査したように、一部のネットワークスタック実装は、特にモバイルデバイスで、マルチインターフェイスの問題を解決するために、集中接続マネージャーまたは他の高レベルAPIを備えています。 MPTCPとの対話は、このドキュメントの範囲外です。
The target readers of this document are application developers whose software may benefit significantly from MPTCP. This document also provides the necessary information for developers of MPTCP to implement the API in a TCP/IP network stack.
このドキュメントの対象読者は、ソフトウェアがMPTCPから大幅に恩恵を受ける可能性のあるアプリケーション開発者です。このドキュメントでは、MPTCPの開発者がAPIをTCP / IPネットワークスタックに実装するために必要な情報も提供します。
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 [3].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [3]で説明されているように解釈されます。
This document uses the MPTCP terminology introduced in [5].
このドキュメントでは、[5]で導入されたMPTCP用語を使用しています。
Concerning the API towards applications, the following terms are distinguished:
アプリケーション向けのAPIについては、次の用語が区別されます。
o Legacy API: The interface towards TCP that is currently used by applications. This document explains the effect of MPTCP for such applications, as well as resulting issues.
o レガシーAPI：アプリケーションが現在使用しているTCPへのインターフェース。このドキュメントでは、このようなアプリケーションに対するMPTCPの影響と、その結果生じる問題について説明します。
o Basic API: A simple extension of TCP's interface for applications that are aware of MPTCP. This document abstractly describes this interface, which provides access to multipath address information and a level of control equivalent to regular TCP.
o 基本API：MPTCPを認識するアプリケーション用のTCPインターフェースの単純な拡張。このドキュメントでは、このインターフェイスについて抽象的に説明します。このインターフェイスは、マルチパスアドレス情報へのアクセスと、通常のTCPと同等の制御レベルを提供します。
o Advanced API: An API that offers more fine-grained control over the behavior of MPTCP. Its specification is outside the scope of this document.
o Advanced API：MPTCPの動作をより細かく制御できるAPI。その仕様はこのドキュメントの範囲外です。
This section discusses the effect of MPTCP on performance as seen by an application, in comparison to what may be expected from the use of regular TCP.
このセクションでは、通常のTCPの使用から予想されるものと比較して、アプリケーションから見たMPTCPのパフォーマンスへの影響について説明します。
One of the key goals of adding multipath capability to TCP is to improve the performance of a transport connection by load distribution over separate subflows across potentially disjoint paths. Furthermore, it is an explicit goal of MPTCP that it provides a connection that performs at least as well as one using single-path TCP. A corresponding congestion control algorithm is described in [7]. The following sections summarize the performance effect of MPTCP as seen by an application.
TCPにマルチパス機能を追加する主要な目標の1つは、互いに素である可能性のあるパスにまたがる個別のサブフローに負荷を分散することにより、トランスポート接続のパフォーマンスを向上させることです。さらに、MPTCPの明示的な目標は、少なくともシングルパスTCPを使用する接続と同様に機能する接続を提供することです。対応する輻輳制御アルゴリズムは、[7]で説明されています。次のセクションでは、アプリケーションから見たMPTCPのパフォーマンス効果を要約します。
The most obvious performance improvement that can be expected from the use of MPTCP is an increase in throughput, since MPTCP will pool more than one path (where available) between two endpoints. This will usually provide as great or greater bandwidth for an application, even though exceptions may exist, e.g., due to differences in the congestion control dynamics. For instance, if a new subflow is started, the short-term throughput can be smaller than the theoretical optimum. If there are shared bottlenecks between the flows, then the congestion control algorithms will in most cases ensure that load is evenly spread amongst regular and multipath TCP sessions, so that no end user receives worse performance than if all were using single-path TCP. There are some known corner cases in which an upgrade to MPTCP can affect other users [21].
MPTCPは2つのエンドポイント間に複数のパス（利用可能な場合）をプールするため、MPTCPの使用により期待できる最も明らかなパフォーマンスの向上はスループットの向上です。これにより、たとえば輻輳制御ダイナミクスの違いなどの例外が存在する場合でも、通常、アプリケーションに同じかそれ以上の帯域幅が提供されます。たとえば、新しいサブフローが開始された場合、短期的なスループットは理論上の最適値よりも小さくなる可能性があります。フロー間にボトルネックが共有されている場合、輻輳制御アルゴリズムはほとんどの場合、負荷が通常のマルチパスTCPセッションに均等に分散されるようにします。これにより、すべてのシングルパスTCPを使用している場合よりもパフォーマンスが低下するエンドユーザーがなくなります。 MPTCPへのアップグレードが他のユーザーに影響を与える可能性がある既知のコーナーケースがいくつかあります[21]。
This performance increase additionally means that an MPTCP session could achieve throughput that is greater than the capacity of a single interface on the device. If any applications make assumptions about interfaces due to throughput, they must take this into account (although an MPTCP implementation must always respect an application's request for a particular interface).
さらに、このパフォーマンスの向上は、MPTCPセッションがデバイス上の単一のインターフェイスの容量を超えるスループットを達成できることを意味します。スループットのためにアプリケーションがインターフェースについての仮定を行う場合、アプリケーションはこれを考慮に入れる必要があります（ただし、MPTCP実装は、特定のインターフェースに対するアプリケーションの要求を常に尊重する必要があります）。
Furthermore, the flexibility of MPTCP to add and remove subflows as paths change availability could lead to a greater variation, and more frequent change, in connection bandwidth. Applications that adapt to available bandwidth (such as video and audio streaming) may need to adjust some of their assumptions to most effectively take this into account.
さらに、パスがアベイラビリティを変更するときにサブフローを追加および削除するMPTCPの柔軟性により、接続帯域幅の変動が大きくなり、頻繁に変更される可能性があります。利用可能な帯域幅に適応するアプリケーション（ビデオやオーディオのストリーミングなど）では、これを最も効果的に考慮するために、想定の一部を調整する必要がある場合があります。
The transport of MPTCP signaling information results in a small overhead. The use of MPTCP instead of a single TCP connection therefore results in a smaller goodput. Also, if multiple subflows share a same bottleneck, this overhead slightly reduces the capacity that is available for data transport. Yet, this potential reduction of throughput will be negligible in many usage scenarios, and the protocol contains optimizations in its design so that this overhead is minimal.
MPTCPシグナリング情報の転送により、オーバーヘッドが小さくなります。したがって、単一のTCP接続の代わりにMPTCPを使用すると、グッドプットが小さくなります。また、複数のサブフローが同じボトルネックを共有している場合、このオーバーヘッドにより、データ転送に使用できる容量がわずかに減少します。ただし、このスループットの潜在的な低下は多くの使用シナリオでは無視でき、プロトコルの設計には最適化が含まれているため、このオーバーヘッドは最小限に抑えられます。
The benefits of MPTCP regarding throughput and resilience may come at some cost regarding data delivery delay and delay jitter.
スループットと回復力に関するMPTCPの利点は、データ配信の遅延と遅延ジッターに関していくらか犠牲になるかもしれません。
If the delays on the constituent subflows of an MPTCP connection differ, the jitter perceivable to an application may appear higher as the data are spread across the subflows. Although MPTCP will ensure in-order delivery to the application, the data delivery could be more bursty than may be usual with single-path TCP, in particular on highly asymmetric paths.
MPTCP接続の構成サブフローの遅延が異なる場合、データがサブフロー全体に分散されるため、アプリケーションで認識できるジッターが高くなることがあります。 MPTCPはアプリケーションへの順序どおりの配信を保証しますが、データ配信は、特に高度に非対称的なパスで、シングルパスTCPの通常の場合よりもバースト性になる可能性があります。
Applications with high real-time requirements might be affected by such a scenario. One possible remedy is to disable MPTCP for such jitter-sensitive applications, either by using the basic API defined in this document, or by other means, such as system policies.
リアルタイム要件が高いアプリケーションは、このようなシナリオの影響を受ける可能性があります。このドキュメントで定義されている基本的なAPIを使用するか、システムポリシーなどの他の方法を使用して、ジッターの影響を受けやすいアプリケーションのMPTCPを無効にすることが考えられる解決策の1つです。
However, the actual delay and jitter of data transport over MPTCP depend on the scheduling and congestion control algorithms used for sending data, as well as the heuristics to establish and shut down subflows. A sender can implement strategies to minimize the delay jitter seen by applications, but this requires an accurate estimation of the path characteristics. If the scheduling decisions are suboptimal or if assumptions about the path characteristics turn out to be wrong, delay jitter may be increased and affect delay-sensitive applications. In general, for a delay-sensitive application, it would be desirable to select an appropriate congestion control algorithm for its traffic needs.
ただし、MPTCPを介したデータ転送の実際の遅延とジッターは、データの送信に使用されるスケジューリングと輻輳制御アルゴリズム、およびサブフローを確立してシャットダウンするヒューリスティックに依存します。送信側は、アプリケーションで見られる遅延ジッタを最小限に抑えるための戦略を実装できますが、これにはパス特性の正確な推定が必要です。スケジューリングの決定が最適ではない場合、またはパス特性に関する仮定が間違っていることが判明した場合、遅延ジッターが増加し、遅延の影響を受けやすいアプリケーションに影響を与える可能性があります。一般に、遅延の影響を受けやすいアプリケーションでは、トラフィックのニーズに応じて適切な輻輳制御アルゴリズムを選択することが望ましいでしょう。
Alternatively, MPTCP could be used in high-reliability, rather than high-throughput, modes of operation, such as by mirroring traffic on subflows, or by only using additional subflows for hot standby. These methods of traffic scheduling would not cause delay variation in the same way. These additional modes, and the selection of alternative scheduling algorithms, would need to be indicated by an advanced API, the specification of which requires further analysis and is outside the scope of this document.
あるいは、MPTCPは、サブフローでトラフィックをミラーリングすることや、ホットスタンバイに追加のサブフローのみを使用することなど、高スループットの操作モードではなく、高信頼性モードで使用できます。これらのトラフィックスケジューリング方法では、同じ方法で遅延変動が発生することはありません。これらの追加モードと代替スケジューリングアルゴリズムの選択は、高度なAPIで示す必要があります。その仕様は、さらに分析が必要であり、このドキュメントの範囲外です。
If data transport on one subflow fails, the retransmissions inside MPTCP could affect the delivery delay to the application. Yet, without MPTCP that data or the whole connection might have been lost, and other reliability mechanisms (e.g., application-level recovery) would likely have an even larger delay impact.
1つのサブフローでのデータ転送が失敗した場合、MPTCP内の再送信がアプリケーションへの配信遅延に影響を与える可能性があります。しかし、MPTCPがなければ、そのデータまたは接続全体が失われた可能性があり、他の信頼性メカニズム（アプリケーションレベルの回復など）は、さらに大きな遅延の影響を与える可能性があります。
In addition, applications that make round-trip time (RTT) estimates at the application level may have some issues. Whilst the average delay calculated will be accurate, whether this is useful for an application will depend on what it requires this information for. If a new application wishes to derive such information, it should consider how multiple subflows may affect its measurements and thus how it may wish to respond. In such a case, an application may wish to express its scheduling preferences, as described later in this document.
さらに、アプリケーションレベルで往復時間（RTT）の見積もりを行うアプリケーションには、いくつかの問題がある可能性があります。計算された平均遅延は正確ですが、これがアプリケーションに役立つかどうかは、この情報が何のために必要かによって異なります。新しいアプリケーションがそのような情報を導出したい場合は、複数のサブフローがその測定にどのように影響するか、したがってどのように応答するかを検討する必要があります。このような場合、このドキュメントで後述するように、アプリケーションはそのスケジューリング設定を表現したい場合があります。
Another performance improvement through the use of MPTCP is better resilience. The use of multiple subflows simultaneously means that if one should fail, all traffic will move to the remaining subflow(s), and additionally any lost packets can be retransmitted on these subflows.
MPTCPの使用によるもう1つのパフォーマンスの向上は、回復力の向上です。複数のサブフローを同時に使用すると、障害が発生した場合、すべてのトラフィックが残りのサブフローに移動し、さらにこれらのサブフローで失われたパケットを再送信できます。
As one special case, MPTCP can be used with only one active subflow at a given point in time. In that case, resilience compared to single-path TCP is improved. MPTCP also supports make-before-break and break-before-make handovers between subflows. In both cases, the MPTCP connection can survive an unavailability or change of an IP address (e.g., due to shutdown of an interface or handover). MPTCP closes or resets the MPTCP connection separately from the individual subflows, as described in [5].
特別なケースの1つとして、MPTCPは特定の時点でアクティブなサブフローを1つだけ使用できます。その場合、シングルパスTCPと比較して回復力が向上します。 MPTCPは、サブフロー間のmake-before-breakおよびbreak-before-makeハンドオーバーもサポートします。どちらの場合でも、MPTCP接続は、IPアドレスの使用不可または変更（たとえば、インターフェースのシャットダウンまたはハンドオーバーによる）に耐えることができます。 [5]で説明されているように、MPTCPは個々のサブフローとは別にMPTCP接続を閉じるかリセットします。
Subflow failure may be caused by issues within the network, which an application would be unaware of, or interface failure on the node.
サブフロー障害は、アプリケーションが認識していないネットワーク内の問題、またはノードのインターフェース障害によって引き起こされる可能性があります。
An application may, under certain circumstances, be in a position to be aware of such failure (e.g., by radio signal strength, or simply an interface enabled flag), and so must not make assumptions of an MPTCP flow's stability based on this. An MPTCP implementation must never override an application's request for a given interface, however, so the cases where this issue may be applicable are limited.
アプリケーションは、特定の状況下で、そのような障害（たとえば、無線信号の強さ、または単にインターフェイスが有効になっているフラグなど）を認識できる状況にある可能性があるため、これに基づいてMPTCPフローの安定性を想定してはなりません。ただし、MPTCP実装は、特定のインターフェイスに対するアプリケーションの要求を上書きしてはなりません。そのため、この問題が発生する可能性があるケースは限られています。
MPTCP has been designed to pass through the majority of middleboxes. Empirical evidence suggests that new TCP options can successfully be used on most paths in the Internet [22]. Nevertheless, some middleboxes may still refuse to pass MPTCP messages due to the presence of TCP options, or they may strip TCP options. If this is the case, MPTCP falls back to regular TCP. Although this will not create a problem for the application (its communication will be set up either way), there may be additional (and indeed, user-perceivable) delay while the first handshake fails. Therefore, an alternative approach could be to try both MPTCP and regular TCP connection attempts at the same time and respond to whichever replies first, in a fashion similar to the "Happy Eyeballs" mechanism for IPv6 [16]. One could also apply a shorter timeout on the MPTCP attempt and thus reduce the setup delay if fallback to regular TCP is needed.
MPTCPは、ミドルボックスの大部分を通過するように設計されています。経験的な証拠は、新しいTCPオプションがインターネットのほとんどのパスで正常に使用できることを示唆しています[22]。それにもかかわらず、一部のミドルボックスは、TCPオプションの存在が原因でMPTCPメッセージの通過を拒否するか、TCPオプションを取り除く場合があります。この場合、MPTCPは通常のTCPにフォールバックします。これでアプリケーションに問題が発生することはありませんが（その通信はどちらの方法でも設定されます）、最初のハンドシェイクが失敗する間に、追加の（そして実際にユーザーが認識できる）遅延が発生する可能性があります。したがって、代替のアプローチは、IPv6の「Happy Eyeballs」メカニズムと同様の方法で、MPTCPと通常のTCP接続の試行を同時に試行し、最初に応答した方に応答することです[16]。通常のTCPへのフォールバックが必要な場合は、MPTCPの試行に短いタイムアウトを適用して、セットアップの遅延を減らすこともできます。
An MPTCP implementation can learn the rate of MPTCP connection attempt successes or failures to particular hosts or networks, and on particular interfaces, and could therefore learn heuristics of when and when not to use MPTCP. A detailed discussion of the various fallback mechanisms, for failures occurring at different points in the connection, is presented in [5]. It must be emphasized that all such heuristics could also fail, and learning can be difficult in certain environments, e.g., if the host is mobile.
MPTCP実装は、特定のホストまたはネットワークへのMPTCP接続試行の成功または失敗の割合を特定のインターフェイスで学習できるため、MPTCPを使用しない場合と使用しない場合のヒューリスティックを学習できます。接続のさまざまなポイントで発生する障害のさまざまなフォールバックメカニズムの詳細については、[5]で説明されています。そのようなすべてのヒューリスティックも失敗する可能性があり、特定の環境（ホストがモバイルである場合など）では学習が困難になる可能性があることを強調する必要があります。
There may also be middleboxes that transparently change the length of content. If such middleboxes are present, MPTCP's reassembly of the byte stream in the receiver is difficult. Still, MPTCP can detect such middleboxes and then fall back to regular TCP. An overview of the impact of middleboxes is presented in [4], and MPTCP's mechanisms to work around these issues are presented and discussed in [5].
コンテンツの長さを透過的に変更するミドルボックスもあります。そのようなミドルボックスが存在する場合、レシーバーでのMPTCPによるバイトストリームの再構成は困難です。それでも、MPTCPはそのようなミドルボックスを検出して、通常のTCPにフォールバックできます。ミドルボックスの影響の概要は[4]に示され、これらの問題を回避するMPTCPのメカニズムは[5]に示され、議論されます。
MPTCP can also have other unexpected implications. For instance, intrusion detection systems could be triggered. A full analysis of MPTCP's impact on such middleboxes is for further study after deployment experiments.
MPTCPは、他の予期しない影響を与える可能性もあります。たとえば、侵入検知システムがトリガーされる可能性があります。このようなミドルボックスに対するMPTCPの影響の完全な分析は、導入実験後にさらに調査する必要があります。
In regular TCP, there is a one-to-one mapping of the sockets interface to a flow through a network. Since MPTCP can make use of multiple subflows, applications cannot implicitly rely on this one-to-one mapping any more.
通常のTCPでは、ソケットインターフェイスとネットワークを通過するフローとの1対1のマッピングがあります。 MPTCPは複数のサブフローを利用できるため、アプリケーションはこの1対1のマッピングに暗黙的に依存することはできません。
Whilst this doesn't matter for most applications, some applications may need to adapt to the presence of multiple addresses, because implicit assumptions are outdated. In this section, selected examples for resulting issues are discussed. The question of whether such implicit assumptions matter is an application-level decision, and this document only provides general guidance and a basic API to retrieve relevant information.
これはほとんどのアプリケーションにとって重要ではありませんが、暗黙的な仮定は時代遅れであるため、複数のアドレスの存在に適応する必要があるアプリケーションもあります。このセクションでは、結果として生じる問題の選択例について説明します。そのような暗黙の仮定が重要であるかどうかの問題は、アプリケーションレベルの決定であり、このドキュメントは、関連情報を取得するための一般的なガイダンスと基本的なAPIのみを提供します。
A few applications require the transport to be along a single path; they can disable the use of MPTCP as described later in this document. Examples include monitoring tools that want to measure the available bandwidth on a path, or routing protocols such as BGP that require the use of a specific link.
一部のアプリケーションでは、トランスポートが単一のパスに沿っている必要があります。このドキュメントで後述するように、MPTCPの使用を無効にすることができます。例には、パスで利用可能な帯域幅を測定する監視ツールや、特定のリンクの使用を必要とするBGPなどのルーティングプロトコルが含まれます。
Certain applications store the IP addresses of TCP connections, e.g., by logging mechanisms. Such logging mechanisms will continue to work with MPTCP, but two important aspects have to be mentioned: First, if the application is not aware of MPTCP, it will use the existing interface to the network stack. This implies that an MPTCP-unaware application will track the IP addresses of the first subflow only. IP addresses used by follow-up subflows will be ignored. Second, an MPTCP-aware application can use the basic API described in this document to monitor the IP addresses of all subflows, e.g., for logging mechanisms. If an MPTCP connection uses several subflows, this will possibly imply that data structures have to be adapted and that the amount of data that has to be logged and stored per connection will increase.
特定のアプリケーションは、ロギングメカニズムなどによって、TCP接続のIPアドレスを保存します。このようなロギングメカニズムは引き続きMPTCPで機能しますが、2つの重要な側面に言及する必要があります。まず、アプリケーションがMPTCPを認識していない場合、ネットワークスタックへの既存のインターフェイスを使用します。これは、MPTCP非対応アプリケーションが最初のサブフローのIPアドレスのみを追跡することを意味します。フォローアップサブフローで使用されるIPアドレスは無視されます。次に、MPTCP対応アプリケーションは、このドキュメントで説明されている基本的なAPIを使用して、たとえばロギングメカニズムなど、すべてのサブフローのIPアドレスを監視できます。 MPTCP接続が複数のサブフローを使用する場合、これはおそらく、データ構造を調整する必要があり、接続ごとにログに記録して保存する必要があるデータの量が増えることを意味します。
An MPTCP implementation may choose to maintain an MPTCP connection even if the IP address of the original subflow is no longer allocated to a host, depending on the policy concerning the first subflow (fate-sharing; see Section 4.2.2). In this case, the IP address exposed to an MPTCP-unaware application can differ from the addresses actually being used by MPTCP. It is even possible that the IP address gets assigned to another host during the lifetime of an MPTCP connection. As further discussed below, this could be an issue if the IP addresses are exchanged by applications, e.g., inside the application protocol. This issue can be addressed by enabling fate-sharing, at the cost of resilience, because the MPTCP connection then cannot close the initial subflow.
最初のサブフローに関するポリシーに応じて、元のサブフローのIPアドレスがホストに割り当てられなくなった場合でも、MPTCP実装はMPTCP接続を維持することを選択できます（運命共有。セクション4.2.2を参照）。この場合、MPTCP非対応アプリケーションに公開されるIPアドレスは、MPTCPによって実際に使用されているアドレスと異なる場合があります。 MPTCP接続の存続期間中にIPアドレスが別のホストに割り当てられる可能性さえあります。以下でさらに説明するように、たとえばアプリケーションプロトコル内などのアプリケーションによってIPアドレスが交換される場合、これは問題になる可能性があります。 MPTCP接続は最初のサブフローを閉じることができないため、この問題は、回復力を犠牲にして運命共有を有効にすることで解決できます。
The support for multiple IP addresses within one MPTCP connection can result in additional security vulnerabilities, such as possibilities for attackers to hijack connections. The protocol design of MPTCP minimizes this risk. An attacker on one of the paths can cause harm, but this is hardly an additional security risk compared to single-path TCP, which is vulnerable to man-in-the-middle attacks as well. A detailed threat analysis of MPTCP is published in [6].
1つのMPTCP接続で複数のIPアドレスをサポートすると、攻撃者が接続を乗っ取る可能性など、セキュリティの脆弱性がさらに高まる可能性があります。 MPTCPのプロトコル設計は、このリスクを最小限に抑えます。いずれかのパスで攻撃者が危害を加える可能性がありますが、これは、中間者攻撃に対して脆弱である単一パスTCPと比較して、追加のセキュリティリスクになることはほとんどありません。 MPTCPの詳細な脅威分析は[6]で公開されています。
Impact on Transport Layer Security (TLS) is discussed in Section 6.1.
Transport Layer Security（TLS）への影響については、セクション6.1で説明します。
MPTCP is an extension of TCP, but it is designed to be backward compatible for legacy (MPTCP-unaware) applications. TCP interacts with other parts of the network stack via different interfaces. The de facto standard API between TCP and applications is the sockets interface. The position of MPTCP in the protocol stack is illustrated in Figure 1.
MPTCPはTCPの拡張ですが、レガシー（MPTCP非対応）アプリケーションに対して下位互換性を持つように設計されています。 TCPは、異なるインターフェイスを介してネットワークスタックの他の部分と対話します。 TCPとアプリケーションの間の事実上の標準APIは、ソケットインターフェイスです。プロトコルスタックにおけるMPTCPの位置を図1に示します。
+-------------------------------+
| Application |
+-------------------------------+
^ |
~~~~~~~~~~|~Sockets Interface|~~~~~~~~~
| v
+-------------------------------+
| MPTCP |
+ - - - - - - - + - - - - - - - +
| Subflow (TCP) | Subflow (TCP) |
+-------------------------------+
| IP | IP |
+-------------------------------+
Figure 1: MPTCP Protocol Stack
図1：MPTCPプロトコルスタック
In general, MPTCP can affect all interfaces that make assumptions about the coupling of a TCP connection to a single IP address and TCP port pair, to one socket endpoint, to one network interface, or to a given path through the network.
一般に、MPTCPは、単一のIPアドレスとTCPポートのペア、1つのソケットエンドポイント、1つのネットワークインターフェイス、またはネットワーク上の特定のパスへのTCP接続のカップリングについて想定しているすべてのインターフェイスに影響を与える可能性があります。
This means that there are two classes of applications:
これは、2つのクラスのアプリケーションがあることを意味します。
o Legacy applications: These applications are unaware of MPTCP and use the existing API towards TCP without any changes. This is the default case.
o レガシーアプリケーション：これらのアプリケーションはMPTCPを認識せず、TCPに対して既存のAPIを変更せずに使用します。これがデフォルトのケースです。
o MPTCP-aware applications: These applications indicate support for an enhanced MPTCP interface. This document specifies a minimum set of API extensions for such applications.
o MPTCP対応アプリケーション：これらのアプリケーションは、拡張MPTCPインターフェースのサポートを示します。このドキュメントでは、そのようなアプリケーション用のAPI拡張の最小セットを指定します。
In the following sections, it is discussed to what extent MPTCP affects legacy applications using the existing sockets API. The existing sockets API implies that applications deal with data structures that store, amongst others, the IP addresses and TCP port numbers of a TCP connection. A design objective of MPTCP is that legacy applications can continue to use the established sockets API without any changes. However, in MPTCP there is a one-to-many mapping between the socket endpoint and the subflows. This has several subtle implications for legacy applications using sockets API functions.
次のセクションでは、MPTCPが既存のソケットAPIを使用するレガシーアプリケーションにどの程度影響を与えるかについて説明します。既存のソケットAPIは、アプリケーションが、とりわけ、TCP接続のIPアドレスとTCPポート番号を格納するデータ構造を処理することを意味します。 MPTCPの設計目標は、レガシーアプリケーションが確立されたソケットAPIを変更せずに引き続き使用できることです。ただし、MPTCPでは、ソケットエンドポイントとサブフローの間に1対多のマッピングがあります。これは、ソケットAPI関数を使用するレガシーアプリケーションにいくつかの微妙な影響を及ぼします。
During binding, an application can either select a specific address or bind to INADDR_ANY. Furthermore, on some systems other socket options (e.g., SO_BINDTODEVICE) can be used to bind to a specific interface. If an application uses a specific address or binds to a specific interface, then MPTCP MUST respect this and not interfere in the application's choices. The binding to a specific address or interface implies that the application is not aware of MPTCP and will disable the use of MPTCP on this connection. An application that wishes to bind to a specific set of addresses with MPTCP must use multipath-aware calls to achieve this (as described in Section 5.3.3).
バインド中、アプリケーションは特定のアドレスを選択するか、INADDR_ANYにバインドできます。さらに、一部のシステムでは、他のソケットオプション（SO_BINDTODEVICEなど）を使用して特定のインターフェースにバインドできます。アプリケーションが特定のアドレスを使用するか、特定のインターフェイスにバインドする場合、MPTCPはこれを尊重し、アプリケーションの選択に干渉しないようにする必要があります。特定のアドレスまたはインターフェースへのバインディングは、アプリケーションがMPTCPを認識せず、この接続でのMPTCPの使用を無効にすることを意味します。 MPTCPを使用して特定のアドレスセットにバインドするアプリケーションは、マルチパス対応の呼び出しを使用してこれを実現する必要があります（セクション5.3.3を参照）。
If an application binds to INADDR_ANY, it is assumed that the application does not care which addresses are used locally. In this case, a local policy MAY allow MPTCP to automatically set up multiple subflows on such a connection.
アプリケーションがINADDR_ANYにバインドする場合、アプリケーションはローカルで使用されるアドレスを気にしないと想定されます。この場合、ローカルポリシーは、MPTCPがそのような接続で複数のサブフローを自動的にセットアップすることを許可する場合があります。
The basic sockets API of MPTCP-aware applications allows the expression of further preferences in an MPTCP-compatible way (e.g., binding to a subset of interfaces only).
MPTCP対応アプリケーションの基本的なソケットAPIを使用すると、MPTCPと互換性のある方法（たとえば、インターフェースのサブセットのみにバインドすること）で、さらに詳細な設定を表現できます。
Applications can use the getpeername() or getsockname() functions in order to retrieve the IP address of the peer or of the local socket. These functions can be used for various purposes, including security mechanisms, geo-location, or interface checks. The sockets API was designed with an assumption that a socket is using just one address, and since this address is visible to the application, the application may assume that the information provided by the functions is the same during the lifetime of a connection. However, in MPTCP, unlike in TCP, there is a one-to-many mapping of a connection to subflows, and subflows can be added and removed while the connection continues to exist. Since the subflow addresses can change, MPTCP cannot expose addresses by getpeername() or getsockname() that are both valid and constant during the connection's lifetime.
アプリケーションはgetpeername()またはgetsockname()関数を使用して、ピアまたはローカルソケットのIPアドレスを取得できます。これらの機能は、セキュリティメカニズム、地理位置情報、インターフェイスチェックなど、さまざまな目的に使用できます。ソケットAPIは、ソケットがアドレスを1つだけ使用していることを前提に設計されています。このアドレスはアプリケーションから見えるため、アプリケーションは、接続の存続期間中、関数によって提供される情報は同じであると想定する場合があります。ただし、MPTCPでは、TCPとは異なり、サブフローへの接続の1対多のマッピングがあり、接続が存在している間にサブフローを追加および削除できます。サブフローアドレスは変更される可能性があるため、MPTCPはgetpeername()またはgetsockname()によって、接続の存続期間中は有効かつ一定のアドレスを公開できません。
This problem is addressed as follows: If used by a legacy application, the MPTCP stack MUST always return the addresses and port numbers of the first subflow of an MPTCP connection, in all circumstances, even if that particular subflow is no longer in use.
この問題は次のように対処されます。レガシーアプリケーションで使用される場合、MPTCPスタックは、特定のサブフローが使用されなくなった場合でも、すべての状況で、常にMPTCP接続の最初のサブフローのアドレスとポート番号を返す必要があります。
As the addresses may not be valid any more if the first subflow is closed, the MPTCP stack MAY close the whole MPTCP connection if the first subflow is closed (i.e., fate-sharing between the initial subflow and the MPTCP connection as a whole). This fate-sharing avoids the reuse of the pair of IP addresses and ports while an MPTCP connection is still in progress, but at the cost of reducing the utility of MPTCP if IP addresses of the first subflow are not available any more (e.g., mobility events). Whether to close the whole MPTCP connection by default SHOULD be controlled by a local policy. Further experiments are needed to investigate its implications.
最初のサブフローが閉じている場合、アドレスは有効ではなくなる可能性があるため、最初のサブフローが閉じている場合（つまり、最初のサブフローとMPTCP接続全体の運命共有）、MPTCPスタックはMPTCP接続全体を閉じる場合があります（MAY）。この運命共有により、MPTCP接続の進行中はIPアドレスとポートのペアの再利用が回避されますが、最初のサブフローのIPアドレスが利用できなくなった場合（例：モビリティ）、MPTCPのユーティリティが減少します。イベント）。デフォルトでMPTCP接続全体を閉じるかどうかは、ローカルポリシーで制御する必要があります（SHOULD）。その影響を調査するには、さらなる実験が必要です。
The functions getpeername() and getsockname() SHOULD also always return the addresses of the first subflow if the socket is used by an MPTCP-aware application, in order to be consistent with MPTCP-unaware applications, and, e.g., also with the Stream Control Transmission Protocol (SCTP). Instead of getpeername() or getsockname(), MPTCP-aware applications can use new API calls, described in Section 5.3, in order to retrieve the full list of address pairs for the subflows in use.
関数getpeername()およびgetsockname()は、ソケットがMPTCP非対応アプリケーションと、たとえばStreamとの整合性を保つためにMPTCP対応アプリケーションによって使用される場合、常に最初のサブフローのアドレスも返す必要があります（SHOULD） Control Transmission Protocol（SCTP）。 getpeername()またはgetsockname()の代わりに、MPTCP対応アプリケーションは、使用中のサブフローのアドレスペアの完全なリストを取得するために、セクション5.3で説明されている新しいAPI呼び出しを使用できます。
As described in [5], MPTCP distinguishes between the closing of subflows (by TCP FIN) and closing the whole MPTCP connection (by Data FIN).
[5]で説明されているように、MPTCPはサブフローのクローズ（TCP FINによる）とMPTCP接続全体のクローズ（データFINによる）を区別します。
When an application closes a socket, e.g., by calling the close() function, this indicates that the application has no more data to send, like for single-path TCP. MPTCP will then close the MPTCP connection via Data FIN messages. This is completely transparent for an application.
たとえば、close()関数を呼び出してアプリケーションがソケットを閉じると、シングルパスTCPのように、アプリケーションに送信するデータがないことを示します。次に、MPTCPはデータFINメッセージを介してMPTCP接続を閉じます。これは、アプリケーションに対して完全に透過的です。
In summary, the semantics of the close() interface for applications are not changed compared to TCP.
要約すると、アプリケーションのclose()インターフェースのセマンティクスは、TCPと比較して変更されていません。
In general, an MPTCP connection is maintained separately from individual subflows. MPTCP therefore has internal mechanisms to establish, close, or reset the MPTCP connection [5]. These mechanisms provide equivalent functions like single-path TCP and can be mapped accordingly. Therefore, these MPTCP internals do not affect the application interface.
一般に、MPTCP接続は個々のサブフローとは別に維持されます。したがって、MPTCPには、MPTCP接続を確立、クローズ、またはリセットする内部メカニズムがあります[5]。これらのメカニズムは、シングルパスTCPのような同等の機能を提供し、それに応じてマッピングできます。したがって、これらのMPTCP内部はアプリケーションインターフェイスに影響を与えません。
The existing sockets API includes options that modify the behavior of sockets and their underlying communications protocols. Various socket options exist on the socket, TCP, and IP level. The value of an option can usually be set by the setsockopt() system function. The getsockopt() function gets information. In general, the existing sockets interface functions cannot configure each MPTCP subflow individually. In order to be backward compatible, existing APIs therefore SHOULD apply to all subflows within one connection, as far as possible.
既存のソケットAPIには、ソケットとその基礎となる通信プロトコルの動作を変更するオプションが含まれています。ソケット、TCP、およびIPレベルには、さまざまなソケットオプションがあります。オプションの値は通常、setsockopt()システム関数によって設定できます。 getsockopt()関数は情報を取得します。一般に、既存のソケットインターフェイス関数は、各MPTCPサブフローを個別に構成できません。したがって、下位互換性を保つために、既存のAPIは1つの接続内のすべてのサブフローに可能な限り適用する必要があります（SHOULD）。
One commonly used TCP socket option (TCP_NODELAY) disables the Nagle algorithm as described in [2]. This option is also specified in the POSIX standard [8]. Applications can use this option in combination with MPTCP in exactly the same way. It then SHOULD disable the Nagle algorithm for the MPTCP connection, i.e., all subflows.
[2]で説明されているように、一般的に使用されるTCPソケットオプション（TCP_NODELAY）はNagleアルゴリズムを無効にします。このオプションはPOSIX標準[8]でも指定されています。アプリケーションは、このオプションをMPTCPと組み合わせてまったく同じ方法で使用できます。次に、MPTCP接続、つまりすべてのサブフローのNagleアルゴリズムを無効にする必要があります（SHOULD）。
In addition, the MPTCP protocol instance MAY use a different path scheduler algorithm if TCP_NODELAY is present. For instance, it could use an algorithm that is optimized for latency-sensitive traffic (for instance, only transmitting on one path). Specific algorithms are outside the scope of this document.
さらに、TCP_NODELAYが存在する場合、MPTCPプロトコルインスタンスは別のパススケジューラアルゴリズムを使用する場合があります。たとえば、レイテンシの影響を受けやすいトラフィックに最適化されたアルゴリズムを使用できます（たとえば、1つのパスでのみ送信する）。特定のアルゴリズムはこのドキュメントの範囲外です。
Applications can explicitly configure send and receive buffer sizes via the sockets API (SO_SNDBUF, SO_RCVBUF). These socket options can also be used in combination with MPTCP and then affect the buffer size of the MPTCP connection. However, when defining buffer sizes, application programmers should take into account that the transport over several subflows requires a certain amount of buffer for resequencing in the receiver. MPTCP may also require more storage space in the sender, in particular, if retransmissions are sent over more than one path. In addition, very small send buffers may prevent MPTCP from efficiently scheduling data over different subflows. Therefore, it does not make sense to use MPTCP in combination with small send or receive buffers.
アプリケーションは、ソケットAPI（SO_SNDBUF、SO_RCVBUF）を介して、送信および受信バッファーサイズを明示的に構成できます。これらのソケットオプションは、MPTCPと組み合わせて使用することもでき、MPTCP接続のバッファサイズに影響します。ただし、バッファー・サイズを定義するとき、アプリケーション・プログラマーは、いくつかのサブフローを介したトランスポートがレシーバーでの再シーケンスのために一定量のバッファーを必要とすることを考慮に入れる必要があります。特に再送信が複数のパスを介して送信される場合、MPTCPは送信側にさらに多くのストレージスペースを必要とする場合もあります。さらに、送信バッファーが非常に小さいと、MPTCPが異なるサブフローを介してデータを効率的にスケジュールできない場合があります。したがって、MPTCPを小さな送信バッファーまたは受信バッファーと組み合わせて使用することは意味がありません。
An MPTCP implementation MAY set a lower bound for send and receive buffers and treat a small buffer size request as an implicit request not to use MPTCP.
MPTCP実装は、送信および受信バッファーの下限を設定して、小さいバッファーサイズの要求をMPTCPを使用しない暗黙の要求として扱うことができます（MAY）。
TCP features the ability to send "Urgent" data, but its use is not recommended in general, and specifically not with MPTCP [4].
TCPは「緊急」データを送信する機能を備えていますが、一般的には使用しないことをお勧めします。具体的にはMPTCPでは使用しません[4]。
Some network stacks may provide additional implementation-specific socket options or interfaces that affect TCP's behavior. In such cases, implementers must ensure that these options do not interfere with the MPTCP interface.
一部のネットワークスタックは、TCPの動作に影響を与える追加の実装固有のソケットオプションまたはインターフェイスを提供する場合があります。このような場合、実装者はこれらのオプションがMPTCPインターフェイスに干渉しないことを確認する必要があります。
It is up to a local policy at the end system whether a network stack should automatically enable MPTCP for sockets even if there is no explicit sign of MPTCP awareness of the corresponding application. Such a choice may be under the control of the user through system preferences.
対応するアプリケーションのMPTCP認識の明示的な兆候がない場合でも、ネットワークスタックがソケットのMPTCPを自動的に有効にするかどうかは、エンドシステムのローカルポリシー次第です。このような選択は、システム設定を通じてユーザーの制御下にある場合があります。
The enabling of MPTCP, either by application or by system defaults, does not necessarily mean that MPTCP will always be used. Both endpoints must support MPTCP, and there must be multiple addresses at at least one endpoint, for MPTCP to be used. Even if those requirements are met, however, MPTCP may not be immediately used on a connection. It may make sense for multiple paths to be brought into operation only after a given period of time, or if the connection is saturated.
アプリケーションまたはシステムのデフォルトでMPTCPを有効にしても、必ずしもMPTCPが常に使用されるわけではありません。 MPTCPを使用するには、両方のエンドポイントがMPTCPをサポートし、少なくとも1つのエンドポイントに複数のアドレスが必要です。ただし、これらの要件が満たされていても、MPTCPが接続ですぐに使用されない場合があります。複数のパスが特定の期間の後に、または接続が飽和している場合にのみ動作するようにすることは意味があります。
o Using the default MPTCP configuration: Like TCP, MPTCP is designed to be efficient and robust in the default configuration. Application developers should not explicitly configure TCP (or MPTCP) features unless this is really needed.
o デフォルトのMPTCP構成の使用：TCPと同様に、MPTCPはデフォルトの構成で効率的で堅牢になるように設計されています。アプリケーション開発者は、本当に必要でない限り、TCP（またはMPTCP）機能を明示的に構成しないでください。
o Socket buffer dimensioning: Multipath transport requires larger buffers in the receiver for resequencing, as already explained. Applications should use reasonable buffer sizes (such as the operating system default values) in order to fully benefit from MPTCP. A full discussion of buffer sizing issues is given in [5].
o ソケットバッファーのサイズ決定：既に説明したように、マルチパストランスポートでは、再シーケンス化のためにレシーバーでより大きなバッファーが必要です。 MPTCPを十分に活用するには、アプリケーションで適切なバッファサイズ（オペレーティングシステムのデフォルト値など）を使用する必要があります。バッファのサイズに関する問題の詳細については、[5]を参照してください。
o Facilitating stack-internal heuristics: The path management and data scheduling by MPTCP is realized by stack-internal algorithms that may implicitly try to self-optimize their behavior according to assumed application needs. For instance, an MPTCP implementation may use heuristics to determine whether an application requires delay-sensitive or bulk data transport, using, for instance, port numbers, the TCP_NODELAY socket options, or the application's read/write patterns as input parameters. An application developer can facilitate the operation of such heuristics by avoiding atypical interface use cases. For instance, for long bulk data transfers, it does not make sense to enable the TCP_NODELAY socket option, nor is it reasonable to use many small socket send() calls each with small amounts of data only.
o スタック内部のヒューリスティックの促進：MPTCPによるパス管理とデータスケジューリングは、想定されるアプリケーションのニーズに応じて動作を暗黙的に自己最適化しようとするスタック内部アルゴリズムによって実現されます。たとえば、MPTCP実装はヒューリスティックを使用して、アプリケーションが遅延に敏感なデータ転送またはバルクデータ転送を必要とするかどうかを判断します。たとえば、ポート番号、TCP_NODELAYソケットオプション、またはアプリケーションの読み取り/書き込みパターンを入力パラメーターとして使用します。アプリケーション開発者は、異例のインターフェースの使用例を回避することにより、このようなヒューリスティックの操作を容易にすることができます。たとえば、長いバルクデータ転送の場合、TCP_NODELAYソケットオプションを有効にすることは意味がありません。また、少量のデータのみで多数の小さなソケットsend()呼び出しを使用することも妥当ではありません。
While applications can use MPTCP with the unmodified sockets API, multipath transport results in many degrees of freedom. MPTCP manages the data transport over different subflows automatically. By default, this is transparent to the application, but an application could use an additional API to interface with the MPTCP layer and to control important aspects of the MPTCP implementation's behavior.
アプリケーションは変更されていないソケットAPIでMPTCPを使用できますが、マルチパストランスポートは多くの自由度をもたらします。 MPTCPは、さまざまなサブフロー上のデータ転送を自動的に管理します。デフォルトでは、これはアプリケーションに対して透過的ですが、アプリケーションは追加のAPIを使用してMPTCP層とインターフェースし、MPTCP実装の動作の重要な側面を制御できます。
This document describes a basic MPTCP API. The API contains a minimum set of functions that provide an equivalent level of control and information as exists for regular TCP. It maintains backward compatibility with legacy applications.
このドキュメントでは、基本的なMPTCP APIについて説明します。 APIには、通常のTCPと同じレベルの制御と情報を提供する最小限の関数セットが含まれています。レガシーアプリケーションとの下位互換性を維持します。
An advanced MPTCP API is outside the scope of this document. The basic API does not allow a sender or a receiver to express preferences about the management of paths or the scheduling of data, even if this can have a significant performance impact and if an MPTCP implementation could benefit from additional guidance by applications. A list of potential further API extensions is provided in the appendix. The specification of such an advanced API is for further study and may partly be implementation-specific.
高度なMPTCP APIは、このドキュメントの範囲外です。基本的なAPIでは、パフォーマンスの大幅な影響があり、MPTCP実装がアプリケーションによる追加のガイダンスの恩恵を受ける可能性がある場合でも、送信者または受信者はパスの管理またはデータのスケジューリングに関する設定を表現できません。付録には、潜在的なその他のAPI拡張のリストが示されています。このような高度なAPIの仕様は今後の検討課題であり、一部実装固有の場合があります。
MPTCP mainly affects the sending of data. But a receiver may also have preferences about data transfer choices, and it may have performance requirements as well. Yet, the configuration of such preferences is outside of the scope of the basic API.
MPTCPは主にデータの送信に影響します。ただし、レシーバーにはデータ転送の選択に関する設定があり、パフォーマンス要件もある場合があります。ただし、そのような設定の構成は基本APIの範囲外です。
Because of the importance of the sockets interface there are several fundamental design objectives for the basic interface between MPTCP and applications:
ソケットインターフェイスの重要性のため、MPTCPとアプリケーション間の基本的なインターフェイスには、いくつかの基本的な設計目標があります。
o Consistency with existing sockets APIs must be maintained as far as possible. In order to support the large base of applications using the original API, a legacy application must be able to continue to use standard sockets interface functions when run on a system supporting MPTCP. Also, MPTCP-aware applications should be able to access the socket without any major changes.
o 既存のソケットAPIとの整合性は、可能な限り維持する必要があります。元のAPIを使用してアプリケーションの大規模なベースをサポートするために、レガシーアプリケーションは、MPTCPをサポートするシステムで実行するときに、標準ソケットインターフェイス関数を引き続き使用できる必要があります。また、MPTCP対応のアプリケーションは、大きな変更なしにソケットにアクセスできる必要があります。
o Sockets API extensions must be minimized and independent of an implementation.
o ソケットAPI拡張は最小化し、実装に依存しないようにする必要があります。
o The interface should handle both IPv4 and IPv6.
o インターフェイスはIPv4とIPv6の両方を処理する必要があります。
The following is a list of the core requirements for the basic API:
以下は、基本APIのコア要件のリストです。
REQ1: Turn on/off MPTCP: An application should be able to request to turn on or turn off the usage of MPTCP. This means that an application should be able to explicitly request the use of MPTCP if this is possible. Applications should also be able to request not to enable MPTCP and to use regular TCP transport instead. This can be implicit in many cases, since MPTCP must be disabled by the use of binding to a specific address. MPTCP may also be enabled if an application uses a dedicated multipath address family (such as AF_MULTIPATH [20]).
REQ1：MPTCPをオン/オフにする：アプリケーションは、MPTCPの使用をオンまたはオフにするよう要求できる必要があります。これは、可能であれば、アプリケーションがMPTCPの使用を明示的に要求できる必要があることを意味します。アプリケーションは、MPTCPを有効にせず、代わりに通常のTCPトランスポートを使用するように要求できる必要もあります。特定のアドレスへのバインディングを使用してMPTCPを無効にする必要があるため、これは多くの場合暗黙的です。アプリケーションが専用のマルチパスアドレスファミリ（AF_MULTIPATH [20]など）を使用している場合も、MPTCPを有効にできます。
REQ2: An application should be able to restrict MPTCP to binding to a given set of addresses.
REQ2：アプリケーションは、MPTCPを特定のアドレスセットへのバインディングに制限できる必要があります。
REQ3: An application should be able to obtain information on the pairs of addresses used by the MPTCP subflows.
REQ3：アプリケーションは、MPTCPサブフローで使用されるアドレスのペアに関する情報を取得できる必要があります。
REQ4: An application should be able to extract a unique identifier for the connection (per endpoint).
REQ4：アプリケーションは、接続の一意の識別子を（エンドポイントごとに）抽出できる必要があります。
The first requirement is the most important one, since some applications could benefit a lot from MPTCP, but there are also cases in which it hardly makes sense. The existing sockets API provides similar mechanisms to enable or disable advanced TCP features. The second requirement corresponds to the binding of addresses with the bind() socket call, or, e.g., explicit device bindings with a SO_BINDTODEVICE option. The third requirement ensures that there is an equivalent to getpeername() or getsockname() that is able to deal with more than one subflow. Finally, it should be possible for the application to retrieve a unique connection identifier (local to the endpoint on which it is running) for the MPTCP connection. This replaces the (address, port) pair for a connection identifier in single-path TCP, which is no longer static in MPTCP.
最初の要件は最も重要な要件です。これは、一部のアプリケーションはMPTCPから多くのメリットを得られる可能性があるためですが、ほとんど意味がない場合もあります。既存のソケットAPIは、高度なTCP機能を有効または無効にする同様のメカニズムを提供します。 2番目の要件は、bind()ソケット呼び出しによるアドレスのバインディング、またはSO_BINDTODEVICEオプションによる明示的なデバイスバインディングなどに対応します。 3番目の要件は、複数のサブフローを処理できるgetpeername()またはgetsockname()と同等のものがあることを保証します。最後に、アプリケーションがMPTCP接続の一意の接続識別子（アプリケーションが実行されているエンドポイントに対してローカル）を取得できるようにする必要があります。これは、MPTCPでは静的ではなくなったシングルパスTCPの接続識別子の（アドレス、ポート）ペアを置き換えます。
An application can continue to use getpeername() or getsockname() in addition to the basic MPTCP API. Both functions return the corresponding addresses of the first subflow, as already explained.
アプリケーションは、基本的なMPTCP APIに加えて、getpeername()またはgetsockname()を引き続き使用できます。すでに説明したように、どちらの関数も最初のサブフローの対応するアドレスを返します。
The abstract, basic MPTCP API consists of a set of new values that are associated with an MPTCP socket. Such values may be used for changing properties of an MPTCP connection or retrieving information. These values could be accessed by new symbols on existing calls such as setsockopt() and getsockopt() or could be implemented as entirely new function calls. This implementation decision is out of scope for this document. The following list presents symbolic names for these MPTCP socket settings.
抽象的で基本的なMPTCP APIは、MPTCPソケットに関連付けられた新しい値のセットで構成されています。このような値は、MPTCP接続のプロパティの変更や情報の取得に使用できます。これらの値は、setsockopt()やgetsockopt()などの既存の呼び出しの新しいシンボルでアクセスするか、まったく新しい関数呼び出しとして実装できます。この実装の決定は、このドキュメントの範囲外です。次のリストは、これらのMPTCPソケット設定の記号名を示しています。
o TCP_MULTIPATH_ENABLE: Enable/disable MPTCP
o TCP_MULTIPATH_ENABLE：MPTCPを有効/無効にします
o TCP_MULTIPATH_ADD: Bind MPTCP to a set of given local addresses, or add a set of new local addresses to an existing MPTCP connection
o TCP_MULTIPATH_ADD：MPTCPを特定のローカルアドレスのセットにバインドするか、新しいローカルアドレスのセットを既存のMPTCP接続に追加します
o TCP_MULTIPATH_REMOVE: Remove a local address from an MPTCP connection
o TCP_MULTIPATH_REMOVE：MPTCP接続からローカルアドレスを削除する
o TCP_MULTIPATH_SUBFLOWS: Get the pairs of addresses currently used by the MPTCP subflows
o TCP_MULTIPATH_SUBFLOWS：MPTCPサブフローで現在使用されているアドレスのペアを取得します
o TCP_MULTIPATH_CONNID: Get the local connection identifier for this MPTCP connection
o TCP_MULTIPATH_CONNID：このMPTCP接続のローカル接続識別子を取得します
Table 1 shows a list of the abstract socket operations for the basic configuration of MPTCP. The first column gives the symbolic name of the operation. The second and third columns indicate whether the operation provides values to be read ("Get") or takes values to configure ("Set"). The fourth column lists the type of data associated with this operation. The data types are listed for information only. In addition to IP addresses, an application MAY also indicate TCP port numbers, as further detailed below.
表1は、MPTCPの基本構成の抽象ソケット操作のリストを示しています。最初の列は、操作の記号名を示しています。 2番目と3番目の列は、オペレーションが読み取る値を提供するか（ "Get"）、構成する値を取得するか（ "Set"）を示します。 4番目の列は、この操作に関連付けられたデータのタイプを示しています。データ型は、情報提供のみを目的としてリストされています。以下でさらに詳しく説明するように、IPアドレスに加えて、アプリケーションはTCPポート番号も示す場合があります。
+------------------------+-----+-----+------------------------------+
| Name | Get | Set | Data type |
+------------------------+-----+-----+------------------------------+
| TCP_MULTIPATH_ENABLE | o | o | boolean |
| TCP_MULTIPATH_ADD | | o | list of addresses |
| | | | (and ports) |
| TCP_MULTIPATH_REMOVE | | o | list of addresses |
| | | | (and ports) |
| TCP_MULTIPATH_SUBFLOWS | o | | list of pairs of addresses |
| | | | (and ports) |
| TCP_MULTIPATH_CONNID | o | | integer |
+------------------------+-----+-----+------------------------------+
Table 1: MPTCP Socket Operations
表1：MPTCPソケット操作
There are restrictions on when these new socket operations can be used:
これらの新しいソケット操作をいつ使用できるかに制限があります。
o TCP_MULTIPATH_ENABLE: This value should only be set before the establishment of a TCP connection. Its value should only be read after the establishment of a connection.
o TCP_MULTIPATH_ENABLE：この値は、TCP接続の確立前にのみ設定する必要があります。その値は、接続の確立後にのみ読み取られる必要があります。
o TCP_MULTIPATH_ADD: This operation can be applied both before connection setup and during a connection. If used before, it controls the local addresses that an MPTCP connection can use. In the latter case, it allows MPTCP to use an additional local address, if there has been a restriction before connection setup.
o TCP_MULTIPATH_ADD：この操作は、接続のセットアップ前と接続中の両方に適用できます。以前に使用した場合、MPTCP接続が使用できるローカルアドレスを制御します。後者の場合、接続設定の前に制限があった場合、MPTCPは追加のローカルアドレスを使用できます。
o TCP_MULTIPATH_REMOVE: This operation can be applied both before connection setup and during a connection. In both cases, it removes an address from the list of local addresses that may be used by subflows.
o TCP_MULTIPATH_REMOVE：この操作は、接続のセットアップ前と接続中の両方に適用できます。どちらの場合も、サブフローで使用できるローカルアドレスのリストからアドレスを削除します。
o TCP_MULTIPATH_SUBFLOWS: This value is read-only and can only be used after connection setup.
o TCP_MULTIPATH_SUBFLOWS：この値は読み取り専用であり、接続のセットアップ後にのみ使用できます。
o TCP_MULTIPATH_CONNID: This value is read-only and should only be used after connection setup.
o TCP_MULTIPATH_CONNID：この値は読み取り専用であり、接続のセットアップ後にのみ使用する必要があります。
An application can explicitly indicate multipath capability by setting TCP_MULTIPATH_ENABLE to the value "true". In this case, the MPTCP implementation SHOULD try to negotiate MPTCP for that connection. Note that multipath transport will not necessarily be enabled, as it requires support at both end systems, no middleboxes on the path that would prevent any additional signaling, and at least one endpoint with multiple addresses.
アプリケーションは、TCP_MULTIPATH_ENABLEを値「true」に設定することにより、マルチパス機能を明示的に示すことができます。この場合、MPTCP実装は、その接続についてMPTCPのネゴシエーションを試みる必要があります（SHOULD）。両方のエンドシステムでのサポート、追加のシグナリングを妨げるパス上のミドルボックス、および複数のアドレスを持つ少なくとも1つのエンドポイントが必要であるため、マルチパストランスポートは必ずしも有効ではないことに注意してください。
Building on the backward compatibility specified in Section 4.2.1, if an application enables MPTCP but binds to a specific address or interface, MPTCP MUST be enabled, but MPTCP MUST respect the application's choice and only use addresses that are explicitly provided by the application. Note that it would be possible for an application to use the legacy bindings and then expand on them by using TCP_MULTIPATH_ADD. Note also that it is possible for more than one local address to be initially available to MPTCP in this case, if an application has bound to a specific interface with multiple addresses.
セクション4.2.1で指定された下位互換性に基づいて、アプリケーションがMPTCPを有効にするが特定のアドレスまたはインターフェースにバインドする場合、MPTCPを有効にする必要がありますが、MPTCPはアプリケーションの選択を尊重し、アプリケーションによって明示的に提供されるアドレスのみを使用する必要があります。アプリケーションがレガシーバインディングを使用し、TCP_MULTIPATH_ADDを使用してそれらを拡張できることに注意してください。この場合、アプリケーションが複数のアドレスを持つ特定のインターフェイスにバインドされている場合、最初に複数のローカルアドレスをMPTCPで使用できる可能性があることにも注意してください。
An application can disable MPTCP by setting TCP_MULTIPATH_ENABLE to a value of "false". In that case, MPTCP MUST NOT be used on that connection.
アプリケーションは、TCP_MULTIPATH_ENABLEの値を「false」に設定することにより、MPTCPを無効にできます。その場合、その接続でMPTCPを使用してはなりません（MUST NOT）。
After connection establishment, an application can get the value of TCP_MULTIPATH_ENABLE. A value of "false" then means lack of MPTCP support. A value of "true" means that MPTCP is supported.
接続の確立後、アプリケーションはTCP_MULTIPATH_ENABLEの値を取得できます。 「false」の値は、MPTCPサポートの欠如を意味します。 「true」の値は、MPTCPがサポートされていることを意味します。
Before connection establishment, an application can use the TCP_MULTIPATH_ADD function to indicate a set of local IP addresses that MPTCP may bind to. The parameter of the function is a list of addresses in a corresponding data structure. By extension, this operation will also control the list of addresses that can be advertised to the peer via MPTCP signaling.
接続を確立する前に、アプリケーションはTCP_MULTIPATH_ADD関数を使用して、MPTCPがバインドできるローカルIPアドレスのセットを示すことができます。関数のパラメーターは、対応するデータ構造内のアドレスのリストです。拡張により、この操作は、MPTCPシグナリングを介してピアにアドバタイズできるアドレスのリストも制御します。
If an application binds to a specific address or interface, it is not required to use the TCP_MULTIPATH_ADD operation for that address. As explained in Section 5.3.2, MPTCP MUST only use the explicitly specified addresses in that case.
アプリケーションが特定のアドレスまたはインターフェースにバインドする場合、そのアドレスに対してTCP_MULTIPATH_ADD操作を使用する必要はありません。セクション5.3.2で説明されているように、MPTCPは明示的に指定されたアドレスのみを使用する必要があります（MUST）。
An application MAY also indicate a TCP port number that, if specified, MPTCP MUST attempt to bind to. The port number MAY be different than the one used by existing subflows. If no port number is provided by the application, the port number is automatically selected by the MPTCP implementation, and it is RECOMMENDED that it is the same across all subflows.
アプリケーションは、指定されている場合、MPTCPがバインドを試行する必要があるTCPポート番号を示すこともできます（MAY）。ポート番号は、既存のサブフローで使用されるものとは異なる場合があります。アプリケーションによってポート番号が提供されない場合、ポート番号はMPTCP実装によって自動的に選択され、すべてのサブフローで同じであることが推奨されます。
This operation can also be used to modify the address list in use during the lifetime of an MPTCP connection. In this case, it is used to indicate a set of additional local addresses that the MPTCP connection can make use of and that can be signaled to the peer. It should be noted that this signal is only a hint, and an MPTCP implementation MAY select only a subset of the addresses.
この操作を使用して、MPTCP接続の存続期間中に使用中のアドレスリストを変更することもできます。この場合、これは、MPTCP接続が利用でき、ピアにシグナリングできる追加のローカルアドレスのセットを示すために使用されます。この信号は単なるヒントであり、MPTCP実装はアドレスのサブセットのみを選択してもよいことに注意してください。
The TCP_MULTIPATH_REMOVE operation can be used to remove a local address, or a set of local addresses, from an MPTCP connection. MPTCP MUST close any corresponding subflows (i.e., those using the local address that is no longer present) and signal the removal of the address to the peer. If alternative paths are available using the supplied address list but MPTCP is not currently using them, an MPTCP implementation SHOULD establish alternative subflows before undertaking the address removal.
TCP_MULTIPATH_REMOVE操作を使用して、MPTCP接続からローカルアドレスまたはローカルアドレスのセットを削除できます。 MPTCPは、対応するサブフロー（つまり、存在しないローカルアドレスを使用しているサブフロー）を閉じ、ピアにアドレスの削除を通知する必要があります。提供されたアドレスリストを使用して代替パスが利用可能であるが、MPTCPがそれらを現在使用していない場合、MPTCP実装はアドレスの削除を行う前に代替サブフローを確立する必要があります（SHOULD）。
It should be remembered that these operations SHOULD support both IPv4 and IPv6 addresses, potentially in the same call.
これらの操作はIPv4とIPv6の両方のアドレスをサポートする必要があることに注意してください。
An application can get a list of the addresses used by the currently established subflows in an MPTCP connection by means of the read-only TCP_MULTIPATH_SUBFLOWS operation.
アプリケーションは、読み取り専用のTCP_MULTIPATH_SUBFLOWS操作を使用して、MPTCP接続で現在確立されているサブフローが使用するアドレスのリストを取得できます。
The return value is a list of pairs of tuples of IP address and TCP port number. In one pair, the first tuple refers to the local IP address and the local TCP port, and the second one to the remote IP address and remote TCP port used by the subflow. The list MUST only include established subflows. Both addresses in each pair MUST be either IPv4 or IPv6.
戻り値は、IPアドレスとTCPポート番号のタプルのペアのリストです。 1つのペアでは、最初のタプルはローカルIPアドレスとローカルTCPポートを参照し、2番目のタプルはサブフローで使用されるリモートIPアドレスとリモートTCPポートを参照します。リストには、確立されたサブフローのみを含める必要があります。各ペアの両方のアドレスは、IPv4またはIPv6でなければなりません。
An application that wants a unique identifier for the connection, analogous to an (address, port) pair in regular TCP, can query the TCP_MULTIPATH_CONNID value to get a local connection identifier for the MPTCP connection.
通常のTCPの（アドレス、ポート）ペアに類似した、接続の一意の識別子を必要とするアプリケーションは、TCP_MULTIPATH_CONNID値をクエリして、MPTCP接続のローカル接続識別子を取得できます。
This SHOULD be an integer number and SHOULD be locally unique (e.g., the MPTCP token).
これは整数である必要があり（SHOULD）、ローカルで一意である必要があります（例：MPTCPトークン）。
Transport Layer Security (TLS) [17] may be used over MPTCP's basic API. When TLS compares any addresses used by MPTCP against names or addresses present in X.509 certificates [18] [19], it MUST only compare them with the address that MPTCP used to start the initial subflow as presented to TLS. The addresses used for subsequent subflows need not to be compared against any TLS certificate information. Finer-grained control would require an advanced API or proactive subflow management via the basic API.
Transport Layer Security（TLS）[17]は、MPTCPの基本APIを介して使用できます。 TLSがMPTCPによって使用されるアドレスをX.509証明書[18] [19]に存在する名前またはアドレスと比較するとき、TLSに提示された初期サブフローを開始するためにMPTCPが使用したアドレスとのみ比較する必要があります。後続のサブフローに使用されるアドレスは、TLS証明書情報と比較する必要はありません。よりきめ細かい制御には、高度なAPIまたは基本的なAPIを介した予防的なサブフロー管理が必要です。
For dealing with multihoming, several sockets API extensions have been defined for SCTP [13]. As MPTCP realizes multipath transport from and to multihomed end systems, some of these interface function calls are actually applicable to MPTCP in a similar way.
マルチホーミングを処理するために、SCTPに対していくつかのソケットAPI拡張が定義されています[13]。 MPTCPはマルチホームエンドシステムとの間のマルチパストランスポートを実現するため、これらのインターフェイス関数呼び出しの一部は、実際には同様の方法でMPTCPに適用できます。
API developers may wish to integrate SCTP and MPTCP calls to provide a consistent interface to the application. Yet, it must be emphasized that the transport service provided by MPTCP is different than that of SCTP, and this is why not all SCTP API functions can be mapped directly to MPTCP. Furthermore, a network stack implementing MPTCP does not necessarily support SCTP and its specific sockets interface extensions. This is why the basic API of MPTCP defines additional socket options only, which are a backward-compatible extension of TCP's application interface. Integration with the SCTP API is outside the scope of the basic API.
API開発者は、SCTP呼び出しとMPTCP呼び出しを統合して、アプリケーションへの一貫したインターフェースを提供することを望む場合があります。ただし、MPTCPによって提供されるトランスポートサービスはSCTPのトランスポートサービスとは異なることを強調する必要があります。そのため、すべてのSCTP API関数をMPTCPに直接マップできるわけではありません。さらに、MPTCPを実装するネットワークスタックは必ずしもSCTPとその特定のソケットインターフェイス拡張をサポートしていません。 MPTCPの基本APIが追加のソケットオプションのみを定義するのはこのためです。これは、TCPのアプリケーションインターフェイスの下位互換性のある拡張機能です。 SCTP APIとの統合は、基本APIの範囲外です。
The use of MPTCP can interact with various related sockets API extensions. The use of a multihoming shim layer conflicts with multipath transport such as MPTCP or SCTP [11]. Care should be taken that the use of MPTCP not conflict with the overlapping features of other APIs:
MPTCPを使用すると、関連するさまざまなソケットAPI拡張と対話できます。マルチホーミングシムレイヤーの使用は、MPTCPやSCTPなどのマルチパストランスポートと競合します[11]。 MPTCPの使用が他のAPIの重複する機能と競合しないように注意する必要があります。
o SHIM API [11]: This API specifies sockets API extensions for the multihoming shim layer.
o SHIM API [11]：このAPIは、マルチホーミングシムレイヤーのソケットAPI拡張を指定します。
o HIP API [12]: The Host Identity Protocol (HIP) also results in a new API.
o HIP API [12]：Host Identity Protocol（HIP）も新しいAPIをもたらします。
o API for Mobile IPv6 [10]: For Mobile IPv6, a significantly extended sockets API exists as well (in addition to API extensions for IPv6 [9]).
o モバイルIPv6のAPI [10]：モバイルIPv6の場合、大幅に拡張されたソケットAPIも（IPv6のAPI拡張[9]に加えて）存在します。
In order to avoid any conflict, multiaddressed MPTCP SHOULD NOT be enabled if a network stack uses SHIM6, HIP, or Mobile IPv6. Furthermore, applications should not try to use both the MPTCP API and another multihoming or mobility layer API.
競合を回避するために、ネットワークスタックがSHIM6、HIP、またはモバイルIPv6を使用している場合は、マルチアドレスMPTCPを有効にしないでください。さらに、アプリケーションはMPTCP APIと別のマルチホーミングまたはモビリティレイヤーAPIの両方を使用しないでください。
It is possible, however, that some of the MPTCP functionality, such as congestion control, could be used in a SHIM6 or HIP environment. Such operation is for further study.
ただし、輻輳制御などの一部のMPTCP機能は、SHIM6またはHIP環境で使用できます。このような操作は、今後の検討課題です。
In multihomed or multiaddressed environments, there are various issues that are not specific to MPTCP but have to be considered as well. These problems are summarized in [14].
マルチホーム環境またはマルチアドレス環境では、MPTCPに固有ではないが考慮すべきさまざまな問題があります。これらの問題は[14]に要約されています。
Specifically, there can be interactions with DNS. Whilst it is expected that an application will iterate over the list of addresses returned from a call such as getaddrinfo(), MPTCP itself MUST NOT make any assumptions about multiple A or AAAA records from the same DNS query referring to the same host, as it is possible that multiple addresses refer to multiple servers for load-balancing purposes.
具体的には、DNSとの相互作用があります。アプリケーションはgetaddrinfo()などの呼び出しから返されたアドレスのリストを反復処理することが予想されますが、MPTCP自体は、同じホストを参照する同じDNSクエリからの複数のAまたはAAAAレコードについていかなる仮定も行わないでください。複数のアドレスが負荷分散の目的で複数のサーバーを参照する可能性があります。
This document first defines the behavior of the standard TCP/IP API for MPTCP-unaware applications. In general, enabling MPTCP has some security implications for applications, which are introduced in Section 5.3.3, and these threats are further detailed in [6]. The protocol specification of MPTCP [5] defines several mechanisms to protect MPTCP against those attacks.
このドキュメントでは、最初にMPTCP非対応アプリケーションの標準TCP / IP APIの動作を定義します。一般に、MPTCPを有効にすると、アプリケーションにセキュリティの影響が生じます。これは、セクション5.3.3で紹介されています。これらの脅威については、[6]で詳しく説明しています。 MPTCP [5]のプロトコル仕様は、これらの攻撃からMPTCPを保護するためのいくつかのメカニズムを定義しています。
The syntax and semantics of the API for MPTCP-unaware applications does not change. However, assumptions that non-MPTCP-aware applications may make on the data retrieved by the backward-compatible API are discussed in Section 4.2.2. System administrators may wish to disable MPTCP for certain applications that signal addresses, or make security decisions (e.g., opening firewall holes), based on responses to such queries.
MPTCP非対応アプリケーションのAPIの構文とセマンティクスは変更されません。ただし、非MPTCP対応アプリケーションが下位互換性のあるAPIによって取得されたデータに対して行う可能性のある想定については、セクション4.2.2で説明します。システム管理者は、そのようなクエリへの応答に基づいて、アドレスを通知したり、セキュリティの決定（ファイアウォールホールを開くなど）を行ったりする特定のアプリケーションに対してMPTCPを無効にすることができます。
In addition, the basic MPTCP API for MPTCP-aware applications defines functions that provide an equivalent level of control and information as exists for regular TCP. This document does not mandate a specific implementation of the basic MPTCP API. The implementation should be designed not to affect memory management assumptions in existing code. Implementors should take into account that data structures will be more complex than for standard TCP, e.g., when multiple subflow addresses have to be stored. When dealing with such data structures, care is needed not to add security vulnerabilities to applications.
さらに、MPTCP対応アプリケーション用の基本的なMPTCP APIは、通常のTCPに存在するのと同じレベルの制御と情報を提供する関数を定義します。このドキュメントでは、基本的なMPTCP APIの特定の実装を義務付けていません。実装は、既存のコードのメモリ管理の前提に影響を与えないように設計する必要があります。実装者は、たとえば複数のサブフローアドレスを格納する必要がある場合など、データ構造が標準のTCPよりも複雑になることを考慮する必要があります。このようなデータ構造を扱う場合、アプリケーションにセキュリティの脆弱性を追加しないように注意する必要があります。
New functions enable adding and removing local addresses from an MPTCP connection (TCP_MULTIPATH_ADD and TCP_MULTIPATH_REMOVE). These functions don't add security threats if the MPTCP stack verifies that the addresses provided by the application are indeed available as source addresses for subflows.
新しい機能により、MPTCP接続（TCP_MULTIPATH_ADDおよびTCP_MULTIPATH_REMOVE）からローカルアドレスを追加および削除できます。アプリケーションによって提供されたアドレスが実際にサブフローの送信元アドレスとして使用可能であることをMPTCPスタックが確認した場合、これらの関数はセキュリティの脅威を追加しません。
However, applications should use the TCP_MULTIPATH_ADD function with care, as new subflows might get established to those addresses. Furthermore, it could result in some form of information leakage since MPTCP might advertise those addresses to the other connection endpoint, which could learn IP addresses of interfaces that are not visible otherwise.
ただし、新しいサブフローがこれらのアドレスに確立される可能性があるため、アプリケーションはTCP_MULTIPATH_ADD関数を注意して使用する必要があります。さらに、MPTCPがこれらのアドレスを他の接続エンドポイントにアドバタイズする可能性があるため、何らかの形で情報漏洩が発生する可能性があります。
Use of different addresses should not be assumed to lead to use of different paths, especially for security purposes.
特にセキュリティ上の理由から、異なるアドレスの使用が異なるパスの使用につながると想定すべきではありません。
MPTCP-aware applications should also take care when querying and using information about the addresses used by subflows (TCP_MULTIPATH_SUBFLOWS). As MPTCP can dynamically open and close subflows, a list of addresses queried once can get outdated during the lifetime of an MPTCP connection. Then, the list may contain invalid entries, i.e., addresses that are not used any more or that might not even be assigned to that host any more. Applications that want to ensure that MPTCP only uses a certain set of addresses should explicitly bind to those addresses.
MPTCP対応のアプリケーションは、サブフロー（TCP_MULTIPATH_SUBFLOWS）によって使用されるアドレスに関する情報を照会および使用する場合にも注意が必要です。 MPTCPはサブフローを動的に開いたり閉じたりできるため、一度クエリされたアドレスのリストは、MPTCP接続の存続期間中に古くなる可能性があります。次に、リストに無効なエントリ、つまり、使用されなくなったアドレス、またはそのホストに割り当てられなくなったアドレスが含まれる可能性があります。 MPTCPが特定のアドレスセットのみを使用することを保証する必要があるアプリケーションは、それらのアドレスに明示的にバインドする必要があります。
One specific example is the use TLS on top of MPTCP. Corresponding guidance can be found in Section 6.1.
具体的な例の1つは、MPTCPでのTLSの使用です。対応するガイダンスはセクション6.1にあります。
This document discusses MPTCP's implications and its performance impact on applications. In addition, it specifies a basic MPTCP API. For legacy applications, it is ensured that the existing sockets API continues to work. MPTCP-aware applications can use the basic MPTCP API that provides some control over the transport layer equivalent to regular TCP.
このドキュメントでは、MPTCPの影響とアプリケーションに対するパフォーマンスの影響について説明します。さらに、基本的なMPTCP APIを指定します。レガシーアプリケーションの場合、既存のソケットAPIが引き続き機能することが保証されます。 MPTCP対応のアプリケーションは、通常のTCPと同等のトランスポート層の制御を提供する基本的なMPTCP APIを使用できます。
The authors sincerely thank the following people for their helpful comments and reviews of the document: Philip Eardley, Lavkesh Lahngir, John Leslie, Costin Raiciu, Michael Tuexen, and Javier Ubillos.
著者は、ドキュメントの有益なコメントとレビューを提供してくれたPhilip Eardley、Lavkesh Lahngir、John Leslie、Costin Raiciu、Michael Tuexen、およびJavier Ubillosに心から感謝します。
Michael Scharf is supported by the German-Lab project (http://www.german-lab.de/) funded by the German Federal Ministry of Education and Research (BMBF). Alan Ford was previously supported by Roke Manor Research and by Trilogy (http://www.trilogy-project.org/), a research project (ICT-216372) partially funded by the European Community under its Seventh Framework Program.
Michael Scharfは、ドイツ連邦教育研究省（BMBF）が資金提供するGerman-Labプロジェクト（http://www.german-lab.de/）によってサポートされています。アランフォードは以前、Roke Manor ResearchとTrilogy（http://www.trilogy-project.org/）によってサポートされていました。その研究プロジェクト（ICT-216372）は、第7フレームワークプログラムに基づいて欧州共同体から資金提供を受けています。
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[1] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[2] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[2] ブレーデン、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011.
[4] Ford、A.、Raiciu、C.、Handley、M.、Barre、S.、J。Iyengar、「Multipath TCP Development Architectural Guidelines」、RFC 6182、2011年3月。
[5] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013.
[5] Ford、A.、Raiciu、C.、Handley、M。、およびO. Bonaventure、「複数のアドレスを持つマルチパス操作のためのTCP拡張機能」、RFC 6824、2013年1月。
[6] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, March 2011.
[6] Bagnulo、M。、「複数のアドレスを使用したマルチパス操作のためのTCP拡張の脅威分析」、RFC 6181、2011年3月。
[7] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, October 2011.
[7] Raiciu、C.、Handley、M。、およびD. Wischik、「マルチパストランスポートプロトコルの結合された輻輳制御」、RFC 6356、2011年10月。
[8] "IEEE Standard for Information Technology -- Portable Operating System Interface (POSIX) Base Specifications, Issue 7", IEEE Std. 1003.1-2008, 2008.
[8] 「情報技術のためのIEEE標準-ポータブルオペレーティングシステムインターフェース（POSIX）基本仕様、第7号」、IEEE標準。 1003.1-2008、2008。
[9] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
[9] Stevens、W.、Thomas、M.、Nordmark、E.、and T. Jinmei、 "Advanced Sockets Application Program Interface（API）for IPv6"、RFC 3542、May 2003。
[10] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for Mobile IPv6", RFC 4584, July 2006.
[10] Chakrabarti、S.およびE. Nordmark、「Extension to Sockets API for Mobile IPv6」、RFC 4584、2006年7月。
[11] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Sockets Application Program Interface (API) for Multihoming Shim", RFC 6316, July 2011.
[11] Komu、M.、Bagnulo、M.、Slavov、K.、and S. Sugimoto、 "Sockets Application Program Interface（API）for Multihoming Shim"、RFC 6316、July 2011。
[12] Komu, M. and T. Henderson, "Basic Socket Interface Extensions for the Host Identity Protocol (HIP)", RFC 6317, July 2011.
[12] Komu、M。、およびT. Henderson、「Basic Identity Socket Interface Extensions for the Host Identity Protocol（HIP）」、RFC 6317、2011年7月。
[13] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, December 2011.
[13] Stewart、R.、Tuexen、M.、Poon、K.、Lei、P。、およびV. Yasevich、「Socket Control Extensions for the Stream Control Transmission Protocol（SCTP）」、RFC 6458、2011年12月。
[14] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011.
[14] Blanchet、M.およびP. Seite、「Multiple Interfaces and Provisioning Domains Problem Statement」、RFC 6418、2011年11月。
[15] Wasserman, M. and P. Seite, "Current Practices for Multiple-Interface Hosts", RFC 6419, November 2011.
[15] Wasserman、M。およびP. Seite、「Current- Practices for Multiple-Interface Hosts」、RFC 6419、2011年11月。
[16] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.
[16] Wing、D。およびA. Yourtchenko、「Happy Eyeballs：Success with Dual-Stack Hosts」、RFC 6555、2012年4月。
[17] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[17] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[18] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[18] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile」、RFC 5280、2008年5月。
[19] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[19] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、RFC 6125、 2011年3月。
[20] Sarolahti, P., "Multi-address Interface in the Socket API", Work in Progress, March 2010.
[20] Sarolahti、P。、「ソケットAPIのマルチアドレスインターフェイス」、Work in Progress、2010年3月。
[21] Khalili, R., Gast, N., Popovic, M., and J. Le Boudec, "Performance Issues with MPTCP", Work in Progress, February 2013.
[21] Khalili、R.、Gast、N.、Popovic、M.、and J. Le Boudec、 "Performance Issues with MPTCP"、Work in Progress、2013年2月。
[22] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M., and H. Tokuda, "Is it Still Possible to Extend TCP?", Proc. ACM Internet Measurement Conference (IMC), November 2011.
[22] 本田雅夫、西田康夫、ライチウC.、グリーンハルグA.、ハンドラリーM.、徳田H.「TCPを拡張することはまだ可能ですか？」、Proc。 ACMインターネット測定会議（IMC）、2011年11月。
Multipath transport results in many degrees of freedom. The basic MPTCP API only defines a minimum set of the API extensions for the interface between the MPTCP layer and applications, which does not offer much control of the MPTCP implementation's behavior. A future, advanced API could address further features of MPTCP and provide more control.
マルチパス転送により、多くの自由度が生まれます。基本的なMPTCP APIは、MPTCPレイヤーとアプリケーションの間のインターフェースのAPI拡張の最小セットのみを定義します。これは、MPTCP実装の動作をあまり制御しません。将来の高度なAPIは、MPTCPのさらなる機能に対応し、より多くの制御を提供する可能性があります。
Applications that use TCP may have different requirements on the transport layer. While developers have become used to the characteristics of regular TCP, new opportunities created by MPTCP could allow the service provided to be optimized further. An advanced API could enable MPTCP-aware applications to specify preferences and control certain aspects of the behavior, in addition to the simple control provided by the basic interface. An advanced API could also address aspects that are completely out of scope of the basic API, for example, the question of whether a receiving application could influence the sending policy. A better integration with TLS could be another relevant objective (cf. Section 6.1) that requires further work.
TCPを使用するアプリケーションは、トランスポート層で異なる要件を持つ場合があります。開発者は通常のTCPの特性に慣れてきましたが、MPTCPによって作成された新しい機会により、提供されるサービスをさらに最適化できます。高度なAPIを使用すると、MPTCP対応のアプリケーションで、基本的なインターフェースによって提供される単純な制御に加えて、設定を指定し、動作の特定の側面を制御できます。高度なAPIは、基本的なAPIの範囲から完全に外れた側面、たとえば、受信アプリケーションが送信ポリシーに影響を与える可能性があるかどうかの問題にも対処できます。 TLSとのより良い統合は、さらなる作業を必要とする別の関連する目的（セクション6.1を参照）である可能性があります。
Furthermore, an advanced MPTCP API could be part of a new overall interface between the network stack and applications that addresses other issues as well, such as the split between identifiers and locators. An API that does not use IP addresses (but instead uses, e.g., the connectbyname() function) would be useful for numerous purposes, independent of MPTCP.
さらに、高度なMPTCP APIは、識別子とロケーターの分割など、他の問題にも対処する、ネットワークスタックとアプリケーション間の新しい全体的なインターフェイスの一部になる可能性があります。 IPアドレスを使用しない（ただし、代わりに、例えば、connectbyname()関数を使用する）APIは、MPTCPとは関係なく、多くの目的に役立ちます。
It has also been suggested that a separate address family called AF_MULTIPATH [20] be used. This separate address family could be used to exchange multiple addresses between an application and the standard sockets API, but it would be a more fundamental change compared to the basic API described in this document.
AF_MULTIPATH [20]と呼ばれる別のアドレスファミリを使用することも提案されています。この個別のアドレスファミリは、アプリケーションと標準ソケットAPIの間で複数のアドレスを交換するために使用できますが、このドキュメントで説明する基本的なAPIと比較すると、より根本的な変更になります。
This appendix documents a list of potential usage scenarios and requirements for the advanced API. The specification and implementation of a corresponding API are outside the scope of this document.
この付録には、高度なAPIの潜在的な使用シナリオと要件のリストが記載されています。対応するAPIの仕様と実装は、このドキュメントの範囲外です。
There are different MPTCP usage scenarios. An application that wishes to transmit bulk data will want MPTCP to provide a high-throughput service immediately, through creating and maximizing utilization of all available subflows. This is the default MPTCP use case.
さまざまなMPTCP使用シナリオがあります。バルクデータを送信したいアプリケーションは、MPTCPがすべての利用可能なサブフローの利用を作成して最大化することにより、高スループットサービスを即座に提供することを望みます。これは、デフォルトのMPTCPの使用例です。
But at the other extreme, there are applications that are highly interactive but require only a small amount of throughput, and these are optimally served by low latency and jitter stability. In such a situation, it would be preferable for the traffic to use only the lowest-latency subflow (assuming it has sufficient capacity), maybe with one or two additional subflows for resilience and recovery purposes. The key challenge for such a strategy is that the delay on a path may fluctuate significantly and that just always selecting the path with the smallest delay might result in instability.
しかし、逆に、非常にインタラクティブでありながら、必要なスループットが少ないアプリケーションもあり、これらは低遅延とジッター安定性によって最適に提供されます。そのような状況では、回復力と回復の目的で、おそらく1つまたは2つのサブフローを追加して、トラフィックが最小のレイテンシサブフロー（十分な容量があると仮定）のみを使用することが望ましいでしょう。このような戦略の主な課題は、パスの遅延が大きく変動する可能性があり、常に最小の遅延を持つパスを選択するだけで不安定になる可能性があることです。
The choice between bulk data transport and latency-sensitive transport affects the scheduler in terms of whether traffic should be, by default, sent on one subflow or across several subflows. Even if the total bandwidth required is less than that available on an individual path, it is desirable to spread this load to reduce stress on potential bottlenecks, and this is why this method should be the default for bulk data transport. However, that may not be optimal for applications that require latency/jitter stability.
バルクデータトランスポートと遅延の影響を受けやすいトランスポートのどちらを選択するかは、デフォルトでトラフィックを1つのサブフローで送信するか、複数のサブフローに送信するかという点でスケジューラに影響します。必要な総帯域幅が個々のパスで利用可能な帯域幅より少ない場合でも、この負荷を分散して潜在的なボトルネックへのストレスを減らすことが望ましいため、この方法をバルクデータ転送のデフォルトにする必要があります。ただし、レイテンシ/ジッタの安定性を必要とするアプリケーションには最適ではない場合があります。
In the case of the latter option, a further question arises: Should additional subflows be used whenever the primary subflow is overloaded, or only when the primary path fails (hot standby)? In other words, is latency stability or bandwidth more important to the application? This results in two different options: Firstly, there is the single path that can overflow into an additional subflow; and secondly, there is the single path with hot standby, whereby an application may want an alternative backup subflow in order to improve resilience. In case data delivery on the first subflow fails, the data transport could immediately be continued on the second subflow, which is idle otherwise.
後者のオプションの場合、追加の質問が発生します。プライマリサブフローが過負荷になるときはいつでも、またはプライマリパスに障害が発生したとき（ホットスタンバイ）にのみ、追加のサブフローを使用する必要がありますか？言い換えれば、レイテンシの安定性または帯域幅はアプリケーションにとってより重要ですか？これにより、2つの異なるオプションが生じます。最初に、追加のサブフローにオーバーフローする可能性がある単一のパスがあります。 2つ目は、ホットスタンバイの単一パスです。これにより、アプリケーションは、回復力を向上させるために代替のバックアップサブフローを必要とする場合があります。最初のサブフローでのデータ配信が失敗した場合、データ転送はすぐに2番目のサブフローで続行され、それ以外の場合はアイドル状態になります。
Yet another complication is introduced with the potential that MPTCP introduces for changes in available bandwidth as the number of available subflows changes. Such jitter in bandwidth may prove confusing for some applications, such as video or audio streaming, that dynamically adapt codecs based on available bandwidth. Such applications may prefer MPTCP to attempt to provide a consistent bandwidth as far as is possible and avoid maximizing the use of all subflows.
利用可能なサブフローの数が変化すると、MPTCPが利用可能な帯域幅の変化をもたらす可能性があるため、さらに複雑な問題が発生します。帯域幅のこのようなジッターは、使用可能な帯域幅に基づいてコーデックを動的に適応させるビデオやオーディオストリーミングなどの一部のアプリケーションを混乱させる可能性があります。このようなアプリケーションは、可能な限り一貫した帯域幅を提供し、すべてのサブフローの使用を最大化しないようにするために、MPTCPを優先する場合があります。
A further, mostly orthogonal question is whether data should be duplicated over the different subflows, in particular if there is spare capacity. This could improve both the timeliness and reliability of data delivery.
さらに、ほぼ直交する質問は、特に予備の容量がある場合に、データをさまざまなサブフローで複製するかどうかです。これにより、データ配信の適時性と信頼性の両方を向上させることができます。
In summary, there are at least three possible performance objectives for multipath transport:
要約すると、マルチパストランスポートには、少なくとも3つの可能なパフォーマンス目標があります。
1. High bandwidth
1. 高帯域幅
2. Low latency and jitter stability
2. 低遅延とジッター安定性
3. High reliability
3. 高信頼性
These are not necessarily disjoint, since there are also broadband interactive applications that require both high-speed bulk data traffic and a low latency and jitter.
高速バルクデータトラフィックと低遅延およびジッターの両方を必要とするブロードバンドインタラクティブアプリケーションも存在するため、これらは必ずしもばらばらではありません。
In an advanced API, applications could provide high-level guidance to the MPTCP implementation concerning these performance requirements, for instance, which requirement is considered to be the most important. The MPTCP stack would then use internal mechanisms to fulfill this abstract indication of a desired service, as far as possible. This would affect the assignment of data (including retransmissions) to existing subflows (e.g., 'use all in parallel', 'use as overflow', 'hot standby', 'duplicate traffic') as well as the decisions regarding when to set up additional subflows to which addresses. In both cases, different policies can exist, which can be expected to be implementation-specific.
高度なAPIでは、アプリケーションはこれらのパフォーマンス要件、たとえばどの要件が最も重要であると考えられるかに関して、MPTCP実装に高レベルのガイダンスを提供できます。次に、MPTCPスタックは内部メカニズムを使用して、可能な限り、目的のサービスのこの抽象的な表示を実行します。これは、既存のサブフローへのデータ（再送信を含む）の割り当て（たとえば、「すべてを並行して使用する」、「オーバーフローとして使用する」、「ホットスタンバイ」、「トラフィックを複製する」）と、いつセットアップするかに関する決定に影響しますどのアドレスへの追加のサブフロー。どちらの場合も、異なるポリシーが存在する可能性があり、実装固有であることが期待できます。
Therefore, an advanced API could provide a mechanism for how applications can specify their high-level requirements in an implementation-independent way. One possibility would be to select one "application profile" out of a number of choices that characterize typical applications. Yet, as applications today do not have to inform TCP about their communication requirements, it requires further studies as to whether such an approach would be realistic.
したがって、高度なAPIは、アプリケーションが実装に依存しない方法で高レベルの要件を指定する方法のメカニズムを提供できます。 1つの可能性は、一般的なアプリケーションを特徴付ける多数の選択肢から1つの「アプリケーションプロファイル」を選択することです。しかし、今日のアプリケーションはTCPに通信要件を通知する必要がないため、このようなアプローチが現実的かどうかについては、さらに調査が必要です。
Of course, independent of an advanced API, such functionality could also partly be achieved by MPTCP-internal heuristics that infer some application preferences, e.g., from existing socket options, such as TCP_NODELAY. Whether this would be reliable, and indeed appropriate, is for further study.
もちろん、高度なAPIとは無関係に、そのような機能は、一部のアプリケーション設定を、たとえばTCP_NODELAYなどの既存のソケットオプションから推測するMPTCP内部ヒューリスティックによって部分的に実現することもできます。これが信頼できるかどうか、実際に適切かどうかは、今後の検討課題です。
The following is a list of potential requirements for an advanced MPTCP API beyond the features of the basic API. It is included here for information only:
以下は、基本APIの機能を超えた高度なMPTCP APIの潜在的な要件のリストです。これは、情報のみを目的としてここに含まれています。
REQ5: An application should be able to establish MPTCP connections without using IP addresses as locators.
REQ5：アプリケーションは、ロケーターとしてIPアドレスを使用せずにMPTCP接続を確立できる必要があります。
REQ6: An application should be able to obtain usage information and statistics about all subflows (e.g., ratio of traffic sent via this subflow).
REQ6：アプリケーションは、すべてのサブフローに関する使用情報と統計情報（このサブフローを介して送信されるトラフィックの比率など）を取得できる必要があります。
REQ7: An application should be able to request a change in the number of subflows in use, thus triggering removal or addition of subflows. An even finer control granularity would be a request for the establishment of a specific subflow to a provided destination or a request for the termination of a specified, existing subflow.
REQ7：アプリケーションは、使用中のサブフローの数の変更を要求できるため、サブフローの削除または追加をトリガーできます。さらに細かい制御の粒度は、指定された宛先への特定のサブフローの確立の要求、または指定された既存のサブフローの終了の要求です。
REQ8: An application should be able to inform the MPTCP implementation about its high-level performance requirements, e.g., in the form of a profile.
REQ8：アプリケーションは、MPTCP実装にその高レベルのパフォーマンス要件について、たとえばプロファイルの形で通知できる必要があります。
REQ9: An application should be able to indicate communication characteristics, e.g., the expected amount of data to be sent, the expected duration of the connection, or the expected rate at which data is provided. Applications may in some cases be able to forecast such properties. If so, such information could be an additional input parameter for heuristics inside the MPTCP implementation, which could be useful, for example, to decide when to set up additional subflows.
REQ9：アプリケーションは、送信されるデータの予想量、接続の予想期間、またはデータが提供される予想レートなどの通信特性を示すことができる必要があります。アプリケーションは、このようなプロパティを予測できる場合があります。その場合、そのような情報はMPTCP実装内のヒューリスティックの追加の入力パラメーターになる可能性があり、たとえば、追加のサブフローをいつセットアップするかを決定するのに役立ちます。
REQ10: An application should be able to control the automatic establishment/termination of subflows. This would imply a selection among different heuristics of the path manager, e.g., 'try as soon as possible', 'wait until there is a bunch of data', etc.
REQ10：アプリケーションは、サブフローの自動確立/終了を制御できる必要があります。これは、パスマネージャのさまざまなヒューリスティックから選択することを意味します。たとえば、「できるだけ早く試してみる」、「データの束ができるまで待つ」などです。
REQ11: An application should be able to set preferred subflows or subflow usage policies. This would result in a selection among different configurations of the multipath scheduler. For instance, an application might want to use certain subflows as backup only.
REQ11：アプリケーションは、優先サブフローまたはサブフロー使用ポリシーを設定できる必要があります。これにより、マルチパススケジューラのさまざまな構成から選択されます。たとえば、アプリケーションが特定のサブフローをバックアップとしてのみ使用したい場合があります。
REQ12: An application should be able to control the level of redundancy by telling whether segments should be sent on more than one path in parallel.
REQ12：セグメントを複数のパスで並行して送信する必要があるかどうかを通知することにより、アプリケーションは冗長性のレベルを制御できる必要があります。
REQ13: An application should be able to control the use of fate-sharing of the MPTCP connection and the initial subflow, e.g., to overwrite system policies.
REQ13：システムポリシーを上書きするなど、アプリケーションはMPTCP接続の運命共有と初期サブフローの使用を制御できる必要があります。
REQ14: An application should be able to register for callbacks to be informed of changes to subflows on an MPTCP connection. This "push" interface would allow the application to make timely logging and configuration changes, if required, and would avoid frequent polling of information.
REQ14：アプリケーションは、MPTCP接続でのサブフローの変更を通知されるコールバックに登録できる必要があります。この「プッシュ」インターフェースにより、アプリケーションは必要に応じてタイムリーなロギングと構成の変更を行うことができ、情報の頻繁なポーリングを回避できます。
An advanced API fulfilling these requirements would allow application developers to more specifically configure MPTCP. It could avoid suboptimal decisions of internal, implicit heuristics. However, it is unclear whether all of these requirements would have a significant benefit to applications, since they are going above and beyond what the existing API to regular TCP provides.
これらの要件を満たす高度なAPIにより、アプリケーション開発者はより具体的にMPTCPを構成できます。内部の暗黙のヒューリスティックの最適ではない決定を回避できます。ただし、これらの要件のすべてが、通常のTCPに対する既存のAPIが提供するものを超えているため、アプリケーションに大きなメリットがあるかどうかは不明です。
A subset of these functions might also be implemented system-wide or by other configuration mechanisms. These implementation details are left for further study.
これらの機能のサブセットは、システム全体または他の構成メカニズムによって実装される場合もあります。これらの実装の詳細は、さらに調査するために残されています。
The advanced API may also integrate or use the SCTP sockets API. The following functions that are defined for SCTP have functionality similar to the basic MPTCP API:
高度なAPIは、SCTPソケットAPIを統合または使用する場合もあります。 SCTPに対して定義されている以下の関数には、基本的なMPTCP APIと同様の機能があります。
o sctp_bindx()
o sctp_bindx()
o sctp_connectx()
o sctp_connectx()
o sctp_getladdrs()
o sctp_getladdrs()
o sctp_getpaddrs()
o sctp_getpaddrs()
o sctp_freeladdrs()
o sctp_freeladdrs()
o sctp_freepaddrs()
o sctp_freepaddrs()
The syntax and semantics of these functions are described in [13].
これらの関数の構文とセマンティクスは、[13]で説明されています。
A potential objective for the advanced API is to provide a consistent MPTCP and SCTP interface to the application. This is left for further study.
高度なAPIの潜在的な目的は、アプリケーションに一貫したMPTCPおよびSCTPインターフェイスを提供することです。これはさらなる研究に残されています。
Authors' Addresses
著者のアドレス
Michael Scharf Alcatel-Lucent Bell Labs Lorenzstrasse 10 70435 Stuttgart Germany
Michael Scharf Alcatel-Lucent Bell Labs Lorenzstrasse 10 70435シュトゥットガルトドイツ
EMail: michael.scharf@alcatel-lucent.com
Alan Ford Cisco Ruscombe Business Park Ruscombe, Berkshire RG10 9NN UK
アランフォードCisco Ruscombe Business Park Ruscombe、Berkshire RG10 9NN UK
EMail: alanford@cisco.com