draft-ietf-mptcp-architecture-00.txt   draft-ietf-mptcp-architecture-01.txt 
Internet Engineering Task Force A. Ford, Ed. Internet Engineering Task Force A. Ford, Ed.
Internet-Draft Roke Manor Research Internet-Draft Roke Manor Research
Intended status: Informational C. Raiciu Intended status: Informational C. Raiciu
Expires: September 1, 2010 University College London Expires: December 24, 2010 University College London
S. Barre S. Barre
Universite catholique de Universite catholique de
Louvain Louvain
J. Iyengar J. Iyengar
Franklin and Marshall College Franklin and Marshall College
February 28, 2010 June 22, 2010
Architectural Guidelines for Multipath TCP Development Architectural Guidelines for Multipath TCP Development
draft-ietf-mptcp-architecture-00 draft-ietf-mptcp-architecture-01
Abstract Abstract
Endpoints are often connected by multiple paths, but TCP restricts Endpoints are often connected by multiple paths, but TCP restricts
communications to a single path per transport connection. Resource communications to a single path per transport connection. Resource
usage within the network would be more efficient were these multiple usage within the network would be more efficient were these multiple
paths able to be used concurrently. This should enhance user paths able to be used concurrently. This should enhance user
experience through improved resilience to network failure and higher experience through improved resilience to network failure and higher
throughput. throughput.
This document outlines architectural guidelines for the development This document outlines architectural guidelines for the development
of a Multipath Transport Protocol, with references to how these of a Multipath Transport Protocol, with references to how these
architectural components come together in the Multipath TCP (MPTCP) architectural components come together in the Multipath TCP (MPTCP)
protocol. This document also lists certain high level design protocol. This document also lists certain high level design
decisions that provide foundations for the MPTCP design, based upon decisions that provide foundations for the MPTCP design, based upon
these architectural requirements. these architectural requirements.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 24, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Reference Scenario . . . . . . . . . . . . . . . . . . . . 5 1.3. Reference Scenario . . . . . . . . . . . . . . . . . . . . 5
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 5 2.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 6
2.2. Compatibility Goals . . . . . . . . . . . . . . . . . . . 6 2.2. Compatibility Goals . . . . . . . . . . . . . . . . . . . 7
2.2.1. Application Compatibility . . . . . . . . . . . . . . 6 2.2.1. Application Compatibility . . . . . . . . . . . . . . 7
2.2.2. Network Compatibility . . . . . . . . . . . . . . . . 7 2.2.2. Network Compatibility . . . . . . . . . . . . . . . . 7
2.2.3. Compatibility with other network users . . . . . . . . 8 2.2.3. Compatibility with other network users . . . . . . . . 8
3. An Architectural Basis For MPTCP . . . . . . . . . . . . . . . 8 3. An Architectural Basis For MPTCP . . . . . . . . . . . . . . . 9
4. A Functional Decomposition of MPTCP . . . . . . . . . . . . . 10 4. A Functional Decomposition of MPTCP . . . . . . . . . . . . . 10
5. High-Level Design Decisions . . . . . . . . . . . . . . . . . 11 5. High-Level Design Decisions . . . . . . . . . . . . . . . . . 12
5.1. Sequence Numbering . . . . . . . . . . . . . . . . . . . . 12 5.1. Sequence Numbering . . . . . . . . . . . . . . . . . . . . 12
5.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Buffers . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3. Buffers . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 15
5.5. Path Management . . . . . . . . . . . . . . . . . . . . . 15 5.5. Path Management . . . . . . . . . . . . . . . . . . . . . 15
5.6. Connection Identification . . . . . . . . . . . . . . . . 15 5.6. Connection Identification . . . . . . . . . . . . . . . . 16
5.7. Network Layer Compatibility . . . . . . . . . . . . . . . 16 5.7. Network Layer Compatibility . . . . . . . . . . . . . . . 16
5.8. Congestion Control . . . . . . . . . . . . . . . . . . . . 16 5.8. Congestion Control . . . . . . . . . . . . . . . . . . . . 17
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Interactions with Applications . . . . . . . . . . . . . . . . 17 8. Interactions with Applications . . . . . . . . . . . . . . . . 17
9. Interactions with Middleboxes . . . . . . . . . . . . . . . . 17 9. Interactions with Middleboxes . . . . . . . . . . . . . . . . 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Implementation Architecture . . . . . . . . . . . . . 19 Appendix A. Implementation Architecture . . . . . . . . . . . . . 21
A.1. Functional Separation . . . . . . . . . . . . . . . . . . 19 A.1. Functional Separation . . . . . . . . . . . . . . . . . . 21
A.1.1. Application to default MPTCP protocol . . . . . . . . 19 A.1.1. Application to default MPTCP protocol . . . . . . . . 21
A.1.2. Generic architecture for MPTCP . . . . . . . . . . . . 22 A.1.2. Generic architecture for MPTCP . . . . . . . . . . . . 24
A.2. PM/MPS interface . . . . . . . . . . . . . . . . . . . . . 23 A.2. PM/MPS interface . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 26
B.1. Changes since draft-ietf-mptcp-architecture-00 . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
As the Internet evolves, demands on Internet resources are ever- As the Internet evolves, demands on Internet resources are ever-
increasing, but often these resources (in particular, bandwidth) increasing, but often these resources (in particular, bandwidth)
cannot be fully utilised due to protocol constraints both on the end- cannot be fully utilised due to protocol constraints both on the end-
systems and within the network. If these resources could instead be systems and within the network. If these resources could instead be
used concurrently, end user experience could be greatly improved. used concurrently, end user experience could be greatly improved.
Such enhancements would also reduce the necessary expenditure on Such enhancements would also reduce the necessary expenditure on
network infrastructure which would otherwise be needed to create an network infrastructure which would otherwise be needed to create an
skipping to change at page 5, line 33 skipping to change at page 5, line 33
endpoints. endpoints.
Subflow: A flow of TCP packets operating over an individual path, Subflow: A flow of TCP packets operating over an individual path,
which forms part of a larger MPTCP connection. which forms part of a larger MPTCP connection.
MPTCP Connection: A set of one or more subflows combined to provide MPTCP Connection: A set of one or more subflows combined to provide
a single Multipath TCP service to an application at an endpoint. a single Multipath TCP service to an application at an endpoint.
1.3. Reference Scenario 1.3. Reference Scenario
TBD - would this be useful? The diagram shown in Figure 1 illustrates a typical usage scenario
for MPTCP. Two hosts, A and B, are communicating with each other.
These endpoints are multi-homed and multi-addressed, providing two
disjoint connections to the Internet. The addresses on each endpoint
are referred to as A1, A2, B1 and B2. There are therefore up to four
different paths between the two endpoints: A1-B1, A1-B2, A2-B1,
A2-B2.
Endpoints, routes. Addresses/path selection mechanisms? +------+ __________ +------+
| |A1 ______ ( ) ______ B1| |
| Host |--/ ( ) \--| Host |
| | ( Internet ) | |
| A |--\______( )______/--| B |
| |A2 (__________) B2| |
+------+ +------+
Figure 1: Simple MPTCP Usage Scenario
The scenario could have any number of addresses (1 or more) on each
endpoint, so long as the number of paths available between the two
endpoints 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 - shared bottlenecks will be addressed by
the MPTCP congestion controller. Furthermore, the paths through the
Internet may be interrupted by any number of middleboxes including
NATs and Firewalls. Finally, although the diagram refers to the
Internet, MPTCP may be used over any network where there are multiple
paths that could be used concurrently.
TBD - what further detail here would be useful?
2. Goals 2. Goals
This section outlines primary goals that Multipath TCP aims to meet. This section outlines primary goals that Multipath TCP aims to meet.
These are broadly broken down into functional goals, which steer These are broadly broken down into functional goals, which steer
services and features that MPTCP must provide, and compatibility services and features that MPTCP must provide, and compatibility
goals, which determine how MPTCP should appear to entities that goals, which determine how MPTCP should appear to entities that
interact with it. interact with it.
2.1. Functional Goals 2.1. Functional Goals
skipping to change at page 7, line 14 skipping to change at page 7, line 40
to permit multipath-aware applications to specify preferences, nor to permit multipath-aware applications to specify preferences, nor
for users to configure their systems in a different way from the for users to configure their systems in a different way from the
default, for example switching on or off the automatic use of MPTCP. default, for example switching on or off the automatic use of MPTCP.
2.2.2. Network Compatibility 2.2.2. Network Compatibility
Traditional Internet architecture slots network devices in the Traditional Internet architecture slots network devices in the
network layer and lower layers of the OSI 7-layer stack, where the network layer and lower layers of the OSI 7-layer stack, where the
layers above the network layer - the transport layer and upper layers layers above the network layer - the transport layer and upper layers
- are instantiated only at the end-hosts. While this architecture, - are instantiated only at the end-hosts. While this architecture,
shown in Figure 1, was largely adhered to earlier, this layering no shown in Figure 2, was largely adhered to earlier, this layering no
longer reflects the "ground truth" in the Internet with the longer reflects the "ground truth" in the Internet with the
proliferation of middleboxes[8]. Middleboxes routinely interpose on proliferation of middleboxes[8]. Middleboxes routinely interpose on
the transport layer; sometimes even completely terminating transport the transport layer; sometimes even completely terminating transport
connections, thus leaving the application layer as the first real connections, thus leaving the application layer as the first real
end-to-end layer, as shown in Figure 2. end-to-end layer, as shown in Figure 3.
+-------------+ +-------------+ +-------------+ +-------------+
| Application |<------------ end-to-end ------------->| Application | | Application |<------------ end-to-end ------------->| Application |
+-------------+ +-------------+ +-------------+ +-------------+
| Transport |<------------ end-to-end ------------->| Transport | | Transport |<------------ end-to-end ------------->| Transport |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
| Network |<->| Network |<->| Network |<->| Network | | Network |<->| Network |<->| Network |<->| Network |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
End Host Router Router End Host End Host Router Router End Host
Figure 1: Traditional Internet Architecture Figure 2: Traditional Internet Architecture
+-------------+ +-------------+ +-------------+ +-------------+
| Application |<------------ end-to-end ------------->| Application | | Application |<------------ end-to-end ------------->| Application |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
| Transport |<------------------->| Transport |<->| Transport | | Transport |<------------------->| Transport |<->| Transport |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
| Network |<->| Network |<->| Network |<->| Network | | Network |<->| Network |<->| Network |<->| Network |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
Firewall, Firewall,
End Host Router NAT, or Proxy End Host End Host Router NAT, or Proxy End Host
Figure 2: Internet Reality Figure 3: Internet Reality
Middleboxes that interpose on the transport layer result in loss of Middleboxes that interpose on the transport layer result in loss of
"fate-sharing"[9], that is, they often hold "hard" state that, when "fate-sharing"[9], that is, they often hold "hard" state that, when
lost or corrupted, results in loss or corruption of the end-to-end lost or corrupted, results in loss or corruption of the end-to-end
transport connection. transport connection.
MPTCP MUST remain backward compatible with the Internet as it exists MPTCP MUST remain backward compatible with the Internet as it exists
today, including being able to traverse predominant middleboxes such today, including being able to traverse predominant middleboxes such
as firewalls, NATs, and performance enhancing proxies[8]. This as firewalls, NATs, and performance enhancing proxies[8]. This
requirement comes from recognizing middleboxes as a significant requirement comes from recognizing middleboxes as a significant
skipping to change at page 8, line 46 skipping to change at page 9, line 29
| Application | | Application |
+------------------+ ^ Application-oriented transport +------------------+ ^ Application-oriented transport
| | | functions (Semantic Layer) | | | functions (Semantic Layer)
+ - - Transport - -+ ---------------------------------- + - - Transport - -+ ----------------------------------
| | | Network-oriented transport | | | Network-oriented transport
+------------------+ v functions (Flow+Endpoint Layer) +------------------+ v functions (Flow+Endpoint Layer)
| Network | | Network |
+------------------+ +------------------+
Existing Layers Tng Decomposition Existing Layers Tng Decomposition
Figure 3: Decomposition of Transport Functions Figure 4: Decomposition of Transport Functions
Tng loosely splits the transport layer into "application-oriented" Tng loosely splits the transport layer into "application-oriented"
and "network-oriented" layers, as shown in Figure 3. The and "network-oriented" layers, as shown in Figure 4. The
application-oriented "Semantic" layer implements functions driven application-oriented "Semantic" layer implements functions driven
primarily by concerns of supporting and protecting the application's primarily by concerns of supporting and protecting the application's
end-to-end communication, while the network-oriented "Flow+Endpoint" end-to-end communication, while the network-oriented "Flow+Endpoint"
layer implements functions such as endpoint identification (using layer implements functions such as endpoint identification (using
port numbers) and congestion control. These network-oriented port numbers) and congestion control. These network-oriented
functions, while traditionally located in the ostensibly "end-to-end" functions, while traditionally located in the ostensibly "end-to-end"
Transport layer, have proven in practice to be of great concern to Transport layer, have proven in practice to be of great concern to
network operators and the middleboxes they deploy in the network to network operators and the middleboxes they deploy in the network to
enforce network usage policies[11] [12] or optimize communication enforce network usage policies[11] [12] or optimize communication
performance[13]. Figure 4 shows how middleboxes interact with performance[13]. Figure 5 shows how middleboxes interact with
different layers in this decomposed model of the transport layer: the different layers in this decomposed model of the transport layer: the
application-oriented layer operates end-to-end, while the network- application-oriented layer operates end-to-end, while the network-
oriented layer operates "segment-by-segment" and can be interposed oriented layer operates "segment-by-segment" and can be interposed
upon by middleboxes. upon by middleboxes.
+-------------+ +-------------+ +-------------+ +-------------+
| Application |<------------ end-to-end ------------->| Application | | Application |<------------ end-to-end ------------->| Application |
+-------------+ +-------------+ +-------------+ +-------------+
| Semantic |<------------ end-to-end ------------->| Semantic | | Semantic |<------------ end-to-end ------------->| Semantic |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
|Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint| |Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint|
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
| Network |<->| Network |<->| Network |<->| Network | | Network |<->| Network |<->| Network |<->| Network |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
Firewall Performance Firewall Performance
End Host or NAT Enhancing Proxy End Host End Host or NAT Enhancing Proxy End Host
Figure 4: Middleboxes in the new Internet model Figure 5: Middleboxes in the new Internet model
MPTCP's architectural design follows Tng's decomposition as shown in MPTCP's architectural design follows Tng's decomposition as shown in
Figure 5. The MPTCP component, which provides application Figure 6. The MPTCP component, which provides application
compatibility through the preservation of TCP-like semantics of compatibility through the preservation of TCP-like semantics of
global ordering of application data and reliability, is an global ordering of application data and reliability, is an
instantiation of the "application-oriented" Semantic layer; whereas instantiation of the "application-oriented" Semantic layer; whereas
the legacy-TCP component, which provides network compatibility by the legacy-TCP component, which provides network compatibility by
appearing and behaving as a TCP flow in network, is an instantiation appearing and behaving as a TCP flow in network, is an instantiation
of the "network-oriented" Flow+Endpoint layer. of the "network-oriented" Flow+Endpoint layer.
+--------------------------+ +-------------------------+ +--------------------------+ +-------------------------+
| Application | | Application | | Application | | Application |
+--------------------------+ +-------------------------+ +--------------------------+ +-------------------------+
| Semantic | | MPTCP | | Semantic | | MPTCP |
|--------------------------| + - - - - - + - - - - - + |--------------------------| + - - - - - + - - - - - +
| Flow+Endpt | Flow+Endpt | | TCP | TCP | | Flow+Endpt | Flow+Endpt | | TCP | TCP |
+--------------------------+ +-------------------------+ +--------------------------+ +-------------------------+
| Network | Network | | IP | IP | | Network | Network | | IP | IP |
+--------------------------+ +-------------------------+ +--------------------------+ +-------------------------+
Figure 5: MPTCP mapping to Tng Figure 6: MPTCP mapping to Tng
As a protocol extension to TCP, MPTCP thus explicitly acknowledges As a protocol extension to TCP, MPTCP thus explicitly acknowledges
middleboxes in its design, and specifies a protocol that operates at middleboxes in its design, and specifies a protocol that operates at
two scales: the MPTCP component operates end-to-end, while it allows two scales: the MPTCP component operates end-to-end, while it allows
the TCP component to operate segment-by-segment. the TCP component to operate segment-by-segment.
4. A Functional Decomposition of MPTCP 4. A Functional Decomposition of MPTCP
Having laid out the goals to be met and the architectural basis for Having laid out the goals to be met and the architectural basis for
MPTCP, we now provide a functional decomposition MPTCP's design. MPTCP, we now provide a functional decomposition MPTCP's design.
The MPTCP component relies upon (what appear to the network to be) The MPTCP component relies upon (what appear to the network to be)
standard TCP sessions, termed "subflows", to provide the underlying standard TCP sessions, termed "subflows", to provide the underlying
transport per path, and as such these retain the network transport per path, and as such these retain the network
compatibility desired. MPTCP as described in [3] carries MPTCP- compatibility desired. MPTCP as described in [3] carries MPTCP-
specific information in a TCP-compatible manner, although this specific information in a TCP-compatible manner, although this
mechanism is separate from the actual information being transferred mechanism is separate from the actual information being transferred
so could evolve in future revisions. Figure 6 illustrates the so could evolve in future revisions. Figure 7 illustrates the
layered architecture. layered architecture.
+-------------------------------+ +-------------------------------+
| Application | | Application |
+---------------+ +-------------------------------+ +---------------+ +-------------------------------+
| Application | | MPTCP | | Application | | MPTCP |
+---------------+ + - - - - - - - + - - - - - - - + +---------------+ + - - - - - - - + - - - - - - - +
| TCP | | Subflow (TCP) | Subflow (TCP) | | TCP | | Subflow (TCP) | Subflow (TCP) |
+---------------+ +-------------------------------+ +---------------+ +-------------------------------+
| IP | | IP | IP | | IP | | IP | IP |
+---------------+ +-------------------------------+ +---------------+ +-------------------------------+
Figure 6: Comparison of Standard TCP and MPTCP Protocol Stacks Figure 7: Comparison of Standard TCP and MPTCP Protocol Stacks
Situated below the application, the MPTCP extension manages multiple Situated below the application, the MPTCP extension manages multiple
TCP subflows below it and must implement the following functions: TCP subflows below it and must implement the following functions:
o Path Management: This is the function to detect and use multiple o Path Management: This is the function to detect and use multiple
paths between two endpoints. In the case of the MPTCP design [3], paths between two endpoints. In the case of the MPTCP design [3],
this feature is implemented using multiple IP addresses at least this feature is implemented using multiple IP addresses at least
one of the endpoints. Although this does not guarantee path one of the endpoints. Although this does not guarantee path
diversity, and there may be shared bottlenecks, this is a simple diversity, and there may be shared bottlenecks, this is a simple
mechanism that can be used with no additional features in the mechanism that can be used with no additional features in the
skipping to change at page 15, line 16 skipping to change at page 15, line 50
5.5. Path Management 5.5. Path Management
Currently, the network does not expose multiple paths between Currently, the network does not expose multiple paths between
endpoints. Multipath TCP will use multiple addresses at one or both endpoints. Multipath TCP will use multiple addresses at one or both
endpoints to get different paths to the destination. The hope is endpoints to get different paths to the destination. The hope is
that these paths, whilst not necesarily entirely non-overlapping, that these paths, whilst not necesarily entirely non-overlapping,
will be sufficiently disjoint to allow multipath achieve improved will be sufficiently disjoint to allow multipath achieve improved
throughput and robustness. throughput and robustness.
Multiple different (source, destination) address pairs will thus be Multiple different (source, destination) address pairs will thus be
used as path selectors. used as path selectors. Each path will be identified by a TCP
4-tuple (i.e. source address, destination address, source port,
destination port), thus allowing the extension of MPTCP to use such
4-tuples as path selectors if the network will route different ports
over different paths (which may be the case with technologies such as
ECMP).
For increased chance of successfully setting up additional subflows For increased chance of successfully setting up additional subflows
(such as when one end is behind a firewall, NAT, or other restrictive (such as when one end is behind a firewall, NAT, or other restrictive
middlebox), either endpoint should be able to add new subflows to a middlebox), either endpoint should be able to add new subflows to a
MPTCP connection. MPTCP connection.
The modularity of path management will permit alternative mechanisms The modularity of path management will permit alternative mechanisms
to be employed if appropriate in the future. to be employed if appropriate in the future.
5.6. Connection Identification 5.6. Connection Identification
skipping to change at page 17, line 13 skipping to change at page 18, line 7
the protocol design [3]. the protocol design [3].
8. Interactions with Applications 8. Interactions with Applications
Interactions with applications - incuding, but not limited to, Interactions with applications - incuding, but not limited to,
performances changes that may be expected, semantic changes, and new performances changes that may be expected, semantic changes, and new
features that may be requested of an API, are presented in [7]. features that may be requested of an API, are presented in [7].
9. Interactions with Middleboxes 9. Interactions with Middleboxes
TBD 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 summarises the issues that may arise with NATs, firewalls,
proxies, intrusion detection systems, and other middleboxes that, if
not considered in the protocol design, may hinder its deployment.
This section will contain a list of issues that may arise with NATs, This section is intended primarily as a description of options and
firewalls, proxies, intrusion detection systems, etc. considerations only. Protocol-specific solutions to these issues
will be given in the companion documents.
This will be an overview only, to the level of suggested high-level Multipath TCP will be deployed in a network that no longer provides
solutions as presented in this document (e.g. dual-level sequence just basic datagram delivery. A miriad of middleboxes are deployed
space), but protocol-specific solutions to these issues will be given to optimize various perceived problems with the Internet protocols:
in the companion documents. NATs primarily address space shortage [11], Performance Enhancing
Proxies (PEPs) optimize TCP for different link characteristics [13],
firewalls [12] and intrusion detection systems try to block malicious
content from reaching a host, and traffic normalizers [15] ensure a
consistent view of the traffic stream to IDSes and hosts.
Example points include: All these middleboxes optimize current applications at the expense of
future applications. In effect, future applications must mimic
existing ones if they want to be deployed. Further, the precise
behaviour of all these middleboxes is not clearly specified, and
implementation errors make matters worse, raising the bar for the
deployment of new technologies.
o NATs: change addresses The following list of middlebox classes documents behaviour that
could impact the use of MPTCP. This list is used in [3] to describe
the features of the MPTCP protocol that are used to mitigate the
impact of these middlebox behaviours.
o NATs/Firewalls: drop options; split, coalesce packets; change o NATs: Network Address Translators decouple the endpoint's local IP
sequence numbering? address 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 signalling IP addresses.
o Firewalls: block incoming connection attempts; block unknown TCP o PEPs: Performance Enhancing Proxies, which aim to improve the
options performance of protocols over low-performance (e.g. high latency
or high error rate) links. As such, they may "split" a TCP
connection and behaviour such as proactive ACKing may occur. As
with NATs, it is no longer guaranteed that one endpoint is
communicating directly with another.
o Proxies: PEPs can terminate TCP sessions before an endpoint 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 sequence space.
o Intrusion Detection: require ways to correlate subflows o TCP Options: many middleboxes are in a position to drop packets
with unknown TCP options, or strip those options from the packets.
o ... o Segmentation/Colescing: middleboxes (or even something as close to
the end host as TCP Segmentation Offloading) may change the packet
boundaries from those which the sender intended. It may do this
by splitting packets, or coalescing them together. This leads to
two major impacts: we cannot guarantee where a packet boundary
will be, and we cannot say for sure what a middlebox will do with
TCP options in these cases (they may be repeated, dropped, or sent
only once).
o Firewalls: on top of preventing incoming connections, firewalls
may also attempt additional protection such as sequence number
randomization.
o Intrusion Detection Systems: IDSs may look for traffic patterns to
protect a network, and may have false positives with MPTCP and
drop the connections during normal operation. For future MPTCP-
aware middleboxes, they will require the ability to correlate the
various paths in use.
10. Acknowledgements 10. Acknowledgements
Alan Ford, Costin Raiciu and Sebastien Barre are supported by Trilogy Alan Ford, Costin Raiciu and Sebastien Barre are supported by Trilogy
(http://www.trilogy-project.org), a research project (ICT-216372) (http://www.trilogy-project.org), a research project (ICT-216372)
partially funded by the European Community under its Seventh partially funded by the European Community under its Seventh
Framework Program. The views expressed here are those of the Framework Program. The views expressed here are those of the
author(s) only. The European Commission is not liable for any use author(s) only. The European Commission is not liable for any use
that may be made of the information in this document. that may be made of the information in this document.
skipping to change at page 18, line 30 skipping to change at page 20, line 18
13.2. Informative References 13.2. Informative References
[2] Wischik, D., Handley, M., and M. Bagnulo Braun, "The Resource [2] Wischik, D., Handley, M., and M. Bagnulo Braun, "The Resource
Pooling Principle", ACM SIGCOMM CCR vol. 38 num. 5, pp. 47-52, Pooling Principle", ACM SIGCOMM CCR vol. 38 num. 5, pp. 47-52,
October 2008, October 2008,
<http://ccr.sigcomm.org/online/files/p47-handleyA4.pdf>. <http://ccr.sigcomm.org/online/files/p47-handleyA4.pdf>.
[3] Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for [3] Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for
Multipath Operation with Multiple Addresses", Multipath Operation with Multiple Addresses",
draft-ford-mptcp-multiaddressed-02 (work in progress), draft-ietf-mptcp-multiaddressed-00 (work in progress),
October 2009. June 2010.
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[5] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, [5] Stewart, R., "Stream Control Transmission Protocol", RFC 4960,
September 2007. September 2007.
[6] Raiciu, C., Handley, M., and D. Wischik, "Coupled Multipath- [6] Raiciu, C., Handley, M., and D. Wischik, "Coupled Multipath-
Aware Congestion Control", draft-raiciu-mptcp-congestion-00 Aware Congestion Control", draft-raiciu-mptcp-congestion-01
(work in progress), October 2009. (work in progress), March 2010.
[7] Scharf, M. and A. Ford, "MPTCP Application Interface [7] Scharf, M. and A. Ford, "MPTCP Application Interface
Considerations", draft-scharf-mptcp-api-00 (work in progress), Considerations", draft-scharf-mptcp-api-01 (work in progress),
October 2009. March 2010.
[8] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", [8] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues",
RFC 3234, February 2002. RFC 3234, February 2002.
[9] Carpenter, B., "Internet Transparency", RFC 2775, [9] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000. February 2000.
[10] Ford, B. and J. Iyengar, "Breaking Up the Transport Logjam", [10] Ford, B. and J. Iyengar, "Breaking Up the Transport Logjam",
ACM HotNets, October 2008. ACM HotNets, October 2008.
skipping to change at page 19, line 20 skipping to change at page 21, line 7
Translator (Traditional NAT)", RFC 3022, January 2001. Translator (Traditional NAT)", RFC 3022, January 2001.
[12] Freed, N., "Behavior of and Requirements for Internet [12] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC 2979, October 2000. Firewalls", RFC 2979, October 2000.
[13] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. [13] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to Mitigate Shelby, "Performance Enhancing Proxies Intended to Mitigate
Link-Related Degradations", RFC 3135, June 2001. Link-Related Degradations", RFC 3135, June 2001.
[14] Bagnulo, M., "Threat Analysis for Multi-addressed/Multi-path [14] Bagnulo, M., "Threat Analysis for Multi-addressed/Multi-path
TCP", draft-ietf-mptcp-threat-00 (work in progress), TCP", draft-ietf-mptcp-threat-02 (work in progress),
February 2010. March 2010.
[15] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [15] Handley, M., Paxson, V., and C. Kreibich, "Network Intrusion
Control", RFC 5681, September 2009. 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>.
Appendix A. Implementation Architecture Appendix A. Implementation Architecture
This section provides suggestions for an architecture to implement an This section provides suggestions for an architecture to implement an
extensible, modular multipath transport protocol. extensible, modular multipath transport protocol.
A.1. Functional Separation A.1. Functional Separation
This section describes a generic view of the internal implementation This section describes a generic view of the internal implementation
of a Multipath TCP, through which the technical components specified of a Multipath TCP, through which the technical components specified
skipping to change at page 19, line 50 skipping to change at page 21, line 39
is completely contained in the transport layer. That solution is is completely contained in the transport layer. That solution is
described in more details in [3]. Then we generalize the approach to described in more details in [3]. Then we generalize the approach to
allow good extensibility of that solution. allow good extensibility of that solution.
A.1.1. Application to default MPTCP protocol A.1.1. Application to default MPTCP protocol
Although, in the default approach, MPTCP is fully contained in the Although, in the default approach, MPTCP is fully contained in the
transport layer, it can still be divided into two main modules. One transport layer, it can still be divided into two main modules. One
manages the scheduling of packets as well as congestion control. The manages the scheduling of packets as well as congestion control. The
other one manages the control of paths. The interface between the other one manages the control of paths. The interface between the
two is dealt with thanks to a Path Index. As shown in Figure 7, the two is dealt with thanks to a Path Index. As shown in Figure 8, the
Path Manager announces to the MultiPath Scheduler what paths can be Path Manager announces to the MultiPath Scheduler what paths can be
used trough path indices, and maintains the mapping between that used trough path indices, and maintains the mapping between that
value and the particular action that it must apply to use the path value and the particular action that it must apply to use the path
(an example of such a mapping is in Table 1). In the case of the (an example of such a mapping is in Table 1). In the case of the
built-in Path Manager, the action is to replace an address/port pair built-in Path Manager, the action is to replace an address/port pair
with another one, in such a way that another path is used across the with another one, in such a way that another path is used across the
Internet to forward that packet. Internet to forward that packet.
Control plane <-- | --> Data plane Control plane <-- | --> Data plane
+---------------------------------------------------------------+ +---------------------------------------------------------------+
skipping to change at page 20, line 36 skipping to change at page 22, line 29
+--------------------------------------------------\------------+ +--------------------------------------------------\------------+
/ \ | \ / \ | \
/-----------------------------\ | /"\ /"\ /"\ /"\ /-----------------------------\ | /"\ /"\ /"\ /"\
| rewriting table: || | | | | | | | | | rewriting table: || | | | | | | | |
| Subflow id <--> network_id || | | | | | | | | | Subflow id <--> network_id || | | | | | | | |
| || | | | | | | | | | || | | | | | | | |
| [see table below] || | | | | | | | | | [see table below] || | | | | | | | |
| || \./ \./ \./ \./ | || \./ \./ \./ \./
+------------------------------+| path1 path2 path3 path4 +------------------------------+| path1 path2 path3 path4
Figure 7: Functional separation of MPTCP in the transport layer Figure 8: Functional separation of MPTCP in the transport layer
The MultiPath Scheduler only deals with abstract paths, represented The MultiPath Scheduler only deals with abstract paths, represented
by numbers. It only sees one address pair throughout the by numbers. It only sees one address pair throughout the
communication, that we call the connection identifier. However, the communication, that we call the connection identifier. However, the
MultiPath Scheduler must be able to perform per-subflow congestion MultiPath Scheduler must be able to perform per-subflow congestion
control, and thus to distinguish between the subflows. This leads to control, and thus to distinguish between the subflows. This leads to
define a subflow identifier, that consists of the usual transport define a subflow identifier, that consists of the usual transport
identifier extended with the path index: identifier extended with the path index:
<addr_src,psrc,addr_dst,pdst,path_index>. The following options, <addr_src,psrc,addr_dst,pdst,path_index>. The following options,
described in [3], are managed by the MultiPath Scheduler. described in [3], are managed by the MultiPath Scheduler.
skipping to change at page 22, line 27 skipping to change at page 24, line 18
be able to fallback to the default PM in case the other end does not be able to fallback to the default PM in case the other end does not
support the custom PM. Alternative Path Managers may be specified in support the custom PM. Alternative Path Managers may be specified in
separate documents in the future. separate documents in the future.
A.1.2. Generic architecture for MPTCP A.1.2. Generic architecture for MPTCP
Now that the functional decomposition has been shown for MPTCP with Now that the functional decomposition has been shown for MPTCP with
the built-in Path Manager, we show how that architecture can be the built-in Path Manager, we show how that architecture can be
generalized to allow the implementation of other Path Managers for generalized to allow the implementation of other Path Managers for
MPTCP. A general overview of the architecture is provided in MPTCP. A general overview of the architecture is provided in
Figure 8. The Multipath Scheduler (MPS) learns about the number of Figure 9. The Multipath Scheduler (MPS) learns about the number of
available paths through notifications received from the Path Manager available paths through notifications received from the Path Manager
(PM). From the point of view of the Multipath Scheduler, a path is (PM). From the point of view of the Multipath Scheduler, a path is
just a number, called a Path Index. Notifications from the PM to the just a number, called a Path Index. Notifications from the PM to the
MPS MAY contain supporting information about the paths, if relevant, MPS MAY contain supporting information about the paths, if relevant,
so that the MPS can make more intelligent decisions about where to so that the MPS can make more intelligent decisions about where to
route traffic. When the Multipath Scheduler initiates a route traffic. When the Multipath Scheduler initiates a
communication to a new host, it can only send the packets to the communication to a new host, it can only send the packets to the
default path. But since the Path manager is layered below the MPS, default path. But since the Path manager is layered below the MPS,
it can detect that a new communication is happening, and tell the MPS it can detect that a new communication is happening, and tell the MPS
about the other paths it knows about. about the other paths it knows about.
skipping to change at page 23, line 28 skipping to change at page 25, line 28
| Path Manager (PM) \__________zzzzz | | Path Manager (PM) \__________zzzzz |
+--------------------------------------------------------\------+ +--------------------------------------------------------\------+
/ \ | \ / \ | \
/---------------------------\ | /"\ /"\ /"\ /---------------------------\ | /"\ /"\ /"\
| subflow_id Action | | | | | | | | | subflow_id Action | | | | | | | |
|<A1,B1,pA1,pB1,1> xxxxx | | | | | | | | |<A1,B1,pA1,pB1,1> xxxxx | | | | | | | |
|<A1,B1,pA1,pB1,2> yyyyy | | \./ \./ \./ |<A1,B1,pA1,pB1,2> yyyyy | | \./ \./ \./
|<A1,B1,pA1,pB1,3> zzzzz | | path1 path2 path3 |<A1,B1,pA1,pB1,3> zzzzz | | path1 path2 path3
+---------------------------+ +---------------------------+
Figure 8: Overview of MPTCP architecture Figure 9: Overview of MPTCP architecture
From then on, it is possible for the MPS to associate a Path Index From then on, it is possible for the MPS to associate a Path Index
with its packets, so that the Path Manager can map this Path Index to with its packets, so that the Path Manager can map this Path Index to
a particular action (see table in the lower left part of Figure 8). a particular action (see table in the lower left part of Figure 9).
The particular action depends on the network mechanism used to select The particular action depends on the network mechanism used to select
a path. Examples are address rewriting, tunnelling or setting a path a path. Examples are address rewriting, tunnelling or setting a path
selector value inside the packet. Note that the Path Index is not selector value inside the packet. Note that the Path Index is not
supposed to be written inside the packet, but instead associated with supposed to be written inside the packet, but instead associated with
it, internally to the implementation. it, internally to the implementation.
The applicability of the architecture is not limited to the MPTCP The applicability of the architecture is not limited to the MPTCP
protocol. While we define in this document an MPTCP MPS (MPTCP protocol. While we define in this document an MPTCP MPS (MPTCP
Multipath Scheduler), other Multipath Schedulers can be defined. For Multipath Scheduler), other Multipath Schedulers can be defined. For
example, if an appropriate socket interface is designed, applications example, if an appropriate socket interface is designed, applications
skipping to change at page 24, line 39 skipping to change at page 26, line 39
what outgoing path is acknowledged by an incoming packet. what outgoing path is acknowledged by an incoming packet.
o Module interface: A PM MUST be able to notify the MPS about the o Module interface: A PM MUST be able to notify the MPS about the
number of available paths. Such notifications MUST contain the number of available paths. Such notifications MUST contain the
path indices that are legal for use by the MPS. In case the PM path indices that are legal for use by the MPS. In case the PM
decides to stop providing service for one path, it MUST notify the decides to stop providing service for one path, it MUST notify the
MPS about path removal. Additionnaly, a PM MAY provide MPS about path removal. Additionnaly, a PM MAY provide
complementary path information when available, such as link complementary path information when available, such as link
quality or preference level. quality or preference level.
Appendix B. Changelog
B.1. Changes since draft-ietf-mptcp-architecture-00
o Added middlebox compatibility discussion (Section 9).
o Clarified path identification (TCP 4-tuple) in Section 5.5.
o Added brief scenario and diagram to Section 1.3.
Authors' Addresses Authors' Addresses
Alan Ford (editor) Alan Ford (editor)
Roke Manor Research Roke Manor Research
Old Salisbury Lane Old Salisbury Lane
Romsey, Hampshire SO51 0ZN Romsey, Hampshire SO51 0ZN
UK UK
Phone: +44 1794 833 465 Phone: +44 1794 833 465
Email: alan.ford@roke.co.uk Email: alan.ford@roke.co.uk
 End of changes. 50 change blocks. 
85 lines changed or deleted 168 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/