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