draft-ietf-mptcp-architecture-04.txt   draft-ietf-mptcp-architecture-05.txt 
Internet Engineering Task Force A. Ford, Ed. Internet Engineering Task Force A. Ford
Internet-Draft Roke Manor Research Internet-Draft Roke Manor Research
Intended status: Informational C. Raiciu Intended status: Informational C. Raiciu
Expires: July 15, 2011 M. Handley Expires: July 25, 2011 M. Handley
University College London 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
January 11, 2011 January 21, 2011
Architectural Guidelines for Multipath TCP Development Architectural Guidelines for Multipath TCP Development
draft-ietf-mptcp-architecture-04 draft-ietf-mptcp-architecture-05
Abstract Abstract
Hosts are often connected by multiple paths, but TCP restricts Hosts 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.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on July 15, 2011. This Internet-Draft will expire on July 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
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 Simplified 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 . . . . . . . . . . . . . . . . . . . . 6
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 6 2.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 6
2.2. Compatibility Goals . . . . . . . . . . . . . . . . . . . 7 2.2. Compatibility Goals . . . . . . . . . . . . . . . . . . . 7
2.2.1. Application Compatibility . . . . . . . . . . . . . . 7 2.2.1. Application Compatibility . . . . . . . . . . . . . . 7
2.2.2. Network Compatibility . . . . . . . . . . . . . . . . 7 2.2.2. Network Compatibility . . . . . . . . . . . . . . . . 8
2.2.3. Compatibility with other network users . . . . . . . . 9 2.2.3. Compatibility with other network users . . . . . . . . 9
2.3. Security Goals . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Security Goals . . . . . . . . . . . . . . . . . . . . . . 10
2.4. Related Protocols . . . . . . . . . . . . . . . . . . . . 9 2.4. Related Protocols . . . . . . . . . . . . . . . . . . . . 10
3. An Architectural Basis For Multipath TCP . . . . . . . . . . . 10 3. An Architectural Basis For Multipath TCP . . . . . . . . . . . 10
4. A Functional Decomposition of MPTCP . . . . . . . . . . . . . 12 4. A Functional Decomposition of MPTCP . . . . . . . . . . . . . 12
5. High-Level Design Decisions . . . . . . . . . . . . . . . . . 13 5. High-Level Design Decisions . . . . . . . . . . . . . . . . . 14
5.1. Sequence Numbering . . . . . . . . . . . . . . . . . . . . 14 5.1. Sequence Numbering . . . . . . . . . . . . . . . . . . . . 14
5.2. Reliability and Retransmissions . . . . . . . . . . . . . 15 5.2. Reliability and Retransmissions . . . . . . . . . . . . . 15
5.3. Buffers . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Buffers . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 17 5.4. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 18
5.5. Path Management . . . . . . . . . . . . . . . . . . . . . 18 5.5. Path Management . . . . . . . . . . . . . . . . . . . . . 19
5.6. Connection Identification . . . . . . . . . . . . . . . . 19 5.6. Connection Identification . . . . . . . . . . . . . . . . 20
5.7. Congestion Control . . . . . . . . . . . . . . . . . . . . 20 5.7. Congestion Control . . . . . . . . . . . . . . . . . . . . 21
5.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Interactions with Applications . . . . . . . . . . . . . . . . 21 6. Software Interactions . . . . . . . . . . . . . . . . . . . . 22
7. Interactions with Middleboxes . . . . . . . . . . . . . . . . 22 6.1. Interactions with Applications . . . . . . . . . . . . . . 22
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2. Interactions with Management Systems . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 7. Interactions with Middleboxes . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
A.1. Changes since draft-ietf-mptcp-architecture-03 . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . . 26
A.2. Changes since draft-ietf-mptcp-architecture-02 . . . . . . 26 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 28
A.3. Changes since draft-ietf-mptcp-architecture-01 . . . . . . 26 A.1. Changes since draft-ietf-mptcp-architecture-04 . . . . . . 28
A.4. Changes since draft-ietf-mptcp-architecture-00 . . . . . . 27 A.2. Changes since draft-ietf-mptcp-architecture-03 . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 A.3. Changes since draft-ietf-mptcp-architecture-02 . . . . . . 28
A.4. Changes since draft-ietf-mptcp-architecture-01 . . . . . . 28
A.5. Changes since draft-ietf-mptcp-architecture-00 . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
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 be used
used concurrently, end user experience could be greatly improved. concurrently, end user experience could be greatly improved. Such
Such enhancements would also reduce the necessary expenditure on enhancements would also reduce the necessary expenditure on network
network infrastructure that would otherwise be needed to create an infrastructure that would otherwise be needed to create an equivalent
equivalent improvement in user experience. 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.
By the application of resource pooling [3], these available resources Multipath transport aims to realize some of the goals of resource
can be 'pooled' such that they appear as a single logical resource to pooling by simultaneously making use of multiple disjoint (or
the user. The purpose of a multipath transport, therefore, is to partially disjoint) paths across a network. The two key benefits of
make use of multiple available paths, through resource pooling, to multipath transport are:
bring two key benefits:
o To increase the resilience of the connectivity by providing o To increase the resilience of the connectivity by providing
multiple paths, protecting end hosts from the failure of one. multiple paths, protecting end hosts from the failure of one.
o To increase the efficiency of the resource usage, and thus o To increase the efficiency of the resource usage, and thus
increase the network capacity available to end hosts. increase the network capacity available to end hosts.
Multipath TCP is a modified version of TCP [1] that implements a Multipath TCP is a modified version of TCP [1] that implements a
multipath transport and achieves these goals by pooling multiple multipath transport and achieves these goals by pooling multiple
paths within a transport connection, transparently to the paths within a transport connection, transparently to the
application. MPTCP, defined in [4], is a specific protocol that application. Multipath TCP is primarily concerned with utilising
instantiates the Multipath TCP concept. This document looks both at multiple paths end-to-end, where one or both end host is multi-homed.
general architectural principles for a Multipath TCP fulfilling the It may also have applications where multiple paths exist within the
goals described in Section 2, as well as the key design decisions network and can be manipulated by an end host, such as using
behind MPTCP, which are detailed in Section 5. different port numbers with ECMP [4].
MPTCP, defined in [5], is a specific protocol that instantiates the
Multipath TCP concept. This document looks both at general
architectural principles for a Multipath TCP fulfilling the goals
described in Section 2, as well as the key design decisions behind
MPTCP, which are detailed in Section 5.
Although multihoming and multipath functions are not new to transport Although multihoming and multipath functions are not new to transport
protocols (SCTP [5] being a notable example), MPTCP aims to gain protocols (SCTP [6] being a notable example), MPTCP aims to gain
wide-scale deployment by recognising the importance of application wide-scale deployment by recognising the importance of application
and network compatibility goals. These goals, discussed in detail in and network compatibility goals. These goals, discussed in detail in
Section 2, relate to the appearance of MPTCP to the network (so non- 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 MPTCP-aware entities see it as TCP) and to the application (through
providing an equivalent service to TCP to non-MPTCP-aware providing an service equivalent to TCP for non-MPTCP-aware
applications). applications).
This document has three key purposes: (i) it describes goals for a This document has three key purposes: (i) it describes goals for a
multipath transport - goals that MPTCP is designed to meet; (ii) it multipath transport - goals that MPTCP is designed to meet; (ii) it
lays out an architectural basis for MPTCP's design - a discussion lays out an architectural basis for MPTCP's design - a discussion
that applies to other multipath transports as well; and (iii) it that applies to other multipath transports as well; and (iii) it
discusses and documents high-level design decisions made in MPTCP's discusses and documents high-level design decisions made in MPTCP's
development, and considers their implications. development, and considers their implications.
Companion documents to this architectural overview are those which Companion documents to this architectural overview are those which
provide details of the protocol extensions [4], congestion control provide details of the protocol extensions [5], congestion control
algorithms [6], and application-level considerations [7]. Put algorithms [7], and application-level considerations [8]. Put
together, these components specify a complete Multipath TCP design. together, these components specify a complete Multipath TCP design.
We note that specific components are replaceable in accordance with We note that specific components are replaceable in accordance with
the layer and functional decompositions discussed in this document. the layer and functional decompositions discussed in this document.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. document are to be interpreted as described in RFC 2119 [2].
1.2. Terminology 1.2. Terminology
Multipath TCP: A modified version of the TCP [1] protocol that Regular/Single-Path TCP: The standard version of the TCP [1]
supports the simultaneous use of multiple paths between hosts. protocol in use today, operating between a single pair of IP
addresses.
Multipath TCP: A modified version of the TCP protocol that supports
the simultaneous use of multiple paths between hosts.
Path: A sequence of links between a sender and a receiver, defined Path: A sequence of links between a sender and a receiver, defined
in this context by a source and destination address pair. in this context by a source and destination address pair.
Host: An end host either initiating or terminating a Multipath TCP Host: An end host either initiating or terminating a Multipath TCP
connection. connection.
MPTCP: The proposed protocol extensions specified in [4] to provide MPTCP: The proposed protocol extensions specified in [5] to provide
a Multipath TCP implementation. a Multipath TCP implementation.
Subflow: A flow of TCP segments operating over an individual path, Subflow: A flow of TCP segments operating over an individual path,
which forms part of a larger Multipath TCP connection. which forms part of a larger Multipath TCP connection.
(Multipath TCP) Connection: A set of one or more subflows combined (Multipath TCP) Connection: A set of one or more subflows combined
to provide a single Multipath TCP service to an application at a to provide a single Multipath TCP service to an application at a
host. host.
1.3. Reference Scenario 1.3. Reference Scenario
skipping to change at page 6, line 16 skipping to change at page 6, line 25
| |A1 ______ ( ) ______ B1| | | |A1 ______ ( ) ______ B1| |
| Host |--/ ( ) \--| Host | | Host |--/ ( ) \--| Host |
| | ( Internet ) | | | | ( Internet ) | |
| A |--\______( )______/--| B | | A |--\______( )______/--| B |
| |A2 (__________) B2| | | |A2 (__________) B2| |
+------+ +------+ +------+ +------+
Figure 1: Simple Multipath TCP Usage Scenario Figure 1: Simple Multipath TCP Usage Scenario
The scenario could have any number of addresses (1 or more) on each The scenario could have any number of addresses (1 or more) on each
host, so long as the number of paths available between the two hosts 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 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 by these address combinations through the Internet need not be
entirely disjoint - potential fairness issues introduced by shared entirely disjoint - potential fairness issues introduced by shared
bottlenecks need to be handled by the Multipath TCP congestion bottlenecks need to be handled by the Multipath TCP congestion
controller. Furthermore, the paths through the Internet often do not controller. Furthermore, the paths through the Internet often do not
provide a pure end-to-end service, and instead may be affected by provide a pure end-to-end service, and instead may be affected by
middleboxes such as NATs and Firewalls. middleboxes such as NATs and Firewalls.
2. Goals 2. Goals
skipping to change at page 7, line 32 skipping to change at page 7, line 40
2.2.1. Application Compatibility 2.2.1. Application Compatibility
Application compatibility refers to the appearance of Multipath 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 to the application both in terms of the API that can be used and the
expected service model that is provided. expected service model that is provided.
Multipath TCP MUST follow the same service model as TCP [1]: in- Multipath TCP MUST follow the same service model as TCP [1]: in-
order, reliable, and byte-oriented delivery. Furthermore, a order, reliable, and byte-oriented delivery. Furthermore, a
Multipath TCP connection SHOULD provide the application with no worse Multipath TCP connection SHOULD provide the application with no worse
throughput than it would expect from running a single TCP connection throughput or resilience than it would expect from running a single
over any one of its available paths. 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].
A multipath-capable equivalent of TCP MUST retain some level of A multipath-capable equivalent of TCP MUST retain some level of
backward compatibility with existing TCP APIs, so that existing backward compatibility with existing TCP APIs, so that existing
applications can use the newer transport merely by upgrading the applications can use the newer transport merely by upgrading the
operating systems of the end-hosts. This does not preclude the use operating systems of the end-hosts. This does not preclude the use
of an advanced API to permit multipath-aware applications to specify of an advanced API to permit multipath-aware applications to specify
preferences, nor for users to configure their systems in a different preferences, nor for users to configure their systems in a different
way from the default, for example switching on or off the automatic way from the default, for example switching on or off the automatic
use of multipath extensions. use of multipath extensions.
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.
2.2.2. Network Compatibility 2.2.2. Network Compatibility
In the traditional Internet architecture, network devices operate at In the traditional Internet architecture, network devices operate at
the network layer and lower layers, with the layers above the network the network layer and lower layers, with the layers above the network
layer instantiated only at the end-hosts. While this architecture, layer instantiated only at the end-hosts. While this architecture,
shown in Figure 2, was initially largely adhered to, this layering no shown in Figure 2, was initially largely adhered to, 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 [9]. 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 3. 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 |
skipping to change at page 8, line 31 skipping to change at page 9, line 6
| 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 3: 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" [10], 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.
The network compatibility goal requires that the multipath extension The network compatibility goal requires that the multipath extension
to TCP retains compatibility with the Internet as it exists today, to TCP retains compatibility with the Internet as it exists today,
including making reasonable efforts to be able to traverse including making reasonable efforts to be able to traverse
predominant middleboxes such as firewalls, NATs, and performance predominant middleboxes such as firewalls, NATs, and performance
enhancing proxies [8]. This requirement comes from recognizing enhancing proxies [9]. This requirement comes from recognizing
middleboxes as a significant deployment bottleneck for any transport middleboxes as a significant deployment bottleneck for any transport
that is not TCP or UDP, and constrains Multipath TCP to appear as TCP 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 does on the wire and to use established TCP extensions where
necessary. To ensure end-to-endness of the transport, we further necessary. To ensure end-to-endness of the transport, we further
require Multipath TCP to preserve fate-sharing without making any require Multipath TCP to preserve fate-sharing without making any
assumptions about middlebox behavior. assumptions about middlebox behavior.
A detailed analysis of middlebox behaviour and the impact on the A detailed analysis of middlebox behaviour and the impact on the
Multipath TCP architecture is presented in Section 7. In addition, Multipath TCP architecture is presented in Section 7. In addition,
network compatibility must be retained to the extent that Multipath network compatibility must be retained to the extent that Multipath
TCP MUST fall back to regular TCP if there are insurmountable TCP MUST fall back to regular TCP if there are insurmountable
incompatibilities for the multipath extension on a path. incompatibilities for the multipath extension on a path.
Middleboxes may also cause some TCP features to be able to exist on 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 one subflow but not another. Typically these will be at the subflow
level (such as SACK [10]) and thus do not affect the connection-level level (such as SACK [11]) and thus do not affect the connection-level
behaviour. In the future, any proposed TCP connection-level behaviour. In the future, any proposed TCP connection-level
extensions should consider how they can co-exist with MPTCP. extensions should consider how they can co-exist with MPTCP.
The modifications to support Multipath TCP remain at the transport The modifications to support Multipath TCP remain at the transport
layer, although some knowledge of the underlying network layer is layer, although some knowledge of the underlying network layer is
required. Multipath TCP SHOULD work with IPv4 and IPv6 required. Multipath TCP SHOULD work with IPv4 and IPv6
interchangeably, i.e. one connection may operate over both IPv4 and interchangeably, i.e. one connection may operate over both IPv4 and
IPv6 networks. IPv6 networks.
2.2.3. Compatibility with other network users 2.2.3. Compatibility with other network users
skipping to change at page 9, line 35 skipping to change at page 10, line 8
such as with LEDBAT). The use of multiple paths MUST NOT unduly harm such as with LEDBAT). The use of multiple paths MUST NOT unduly harm
users using single-path TCP at shared bottlenecks, beyond the impact users using single-path TCP at shared bottlenecks, beyond the impact
that would occur from another single-path TCP flow. Multiple that would occur from another single-path TCP flow. Multiple
Multipath TCP flows on a shared bottleneck MUST share bandwidth Multipath TCP flows on a shared bottleneck MUST share bandwidth
between each other with similar fairness to that which occurs at a between each other with similar fairness to that which occurs at a
shared bottleneck with single-path TCP. shared bottleneck with single-path TCP.
2.3. Security Goals 2.3. Security Goals
The extension of TCP with multipath capabilities will bring with it a The extension of TCP with multipath capabilities will bring with it a
number of new threats, analysed in detail in [11]. The security goal number of new threats, analysed in detail in [12]. The security goal
for Multipath TCP is to provide a service no less secure than for Multipath TCP is to provide a service no less secure than
regular, single-path TCP. This will be achieved through a regular, single-path TCP. This will be achieved through a
combination of existing TCP security mechanisms (potentially modified combination of existing TCP security mechanisms (potentially modified
to align with the Multipath TCP extensions) and of protection against to align with the Multipath TCP extensions) and of protection against
the new multipath threats identified. The design decisions derived the new multipath threats identified. The design decisions derived
from this goal are presented in Section 5.8. from this goal are presented in Section 5.8.
2.4. Related Protocols 2.4. Related Protocols
There are several similarities between SCTP [5] and MPTCP, in that There are several similarities between SCTP [6] and MPTCP, in that
both can make use of multiple addresses at end hosts to give some both can make use of multiple addresses at end hosts to give some
multi-path capability. In SCTP, the primary use case is to support multi-path capability. In SCTP, the primary use case is to support
redundancy and mobility for multihomed hosts (i.e. a single path will redundancy and mobility for multihomed hosts (i.e. a single path will
change one of its end host addresses); the simultaneous use of change one of its end host addresses); the simultaneous use of
multiple paths is not supported . Extensions are proposed to support multiple paths is not supported . Extensions are proposed to support
simultaneous multipath transport [12], but these are yet to be simultaneous multipath transport [13], but these are yet to be
standardised. By far the most widely used stream-based transport standardised. By far the most widely used stream-based transport
protocol is, however, TCP [1], and SCTP does not meet the network and protocol is, however, TCP [1], and SCTP does not meet the network and
application compatibility goals specified in Section 2.2. For application compatibility goals specified in Section 2.2. For
network compatibility, there are issues with various middleboxes network compatibility, there are issues with various middleboxes
(especially NATs) that are unaware of SCTP and consequently end up (especially NATs) that are unaware of SCTP and consequently end up
blocking it. For application compatibility, applications need to blocking it. For application compatibility, applications need to
actively choose to use SCTP, and with the deployment issues very few 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 choose to do so. MPTCP's compatibility goals are in part based on
these observations of SCTP's deployment issues. these observations of SCTP's deployment issues.
3. An Architectural Basis For Multipath TCP 3. An Architectural Basis For Multipath TCP
We now present one possible transport architecture that we believe We now present one possible transport architecture that we believe
can effectively support the goals for Multipath TCP. The new can effectively support the goals for Multipath TCP. The new
Internet model described here is based on ideas proposed earlier in Internet model described here is based on ideas proposed earlier in
Tng ("Transport next-generation") [13]. While by no means the only Tng ("Transport next-generation") [14]. While by no means the only
possible architecture supporting multipath transport, Tng possible architecture supporting multipath transport, Tng
incorporates many lessons learned from previous transport research incorporates many lessons learned from previous transport research
and development practice, and offers a strong starting point from and development practice, and offers a strong starting point from
which to consider the extant Internet architecture and its bearing on which to consider the extant Internet architecture and its bearing on
the design of any new Internet transports or transport extensions. the design of any new Internet transports or transport extensions.
+------------------+ +------------------+
| Application | | Application |
+------------------+ ^ Application-oriented transport +------------------+ ^ Application-oriented transport
| | | functions (Semantic Layer) | | | functions (Semantic Layer)
skipping to change at page 10, line 49 skipping to change at page 11, line 28
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 4. 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 [14] [15] or optimize communication enforce network usage policies [15] [16] or optimize communication
performance [16]. Figure 5 shows how middleboxes interact with performance [17]. 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 |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
skipping to change at page 13, line 26 skipping to change at page 14, line 10
reassembled data to the packet scheduling component for reassembled data to the packet scheduling component for
connection-level reassembly; the data sequence mapping from the connection-level reassembly; the data sequence mapping from the
sender's packet scheduling component allows re-ordering of the sender's packet scheduling component allows re-ordering of the
entire bytestream. entire bytestream.
o Congestion Control: This function coordinates congestion control o Congestion Control: This function coordinates congestion control
across the subflows. As specified, this congestion control across the subflows. As specified, this congestion control
algorithm MUST ensure that a MPTCP connection does not unfairly algorithm MUST ensure that a MPTCP connection does not unfairly
take more bandwidth than a single path TCP flow would take at a take more bandwidth than a single path TCP flow would take at a
shared bottleneck. An algorithm to support this is specified in shared bottleneck. An algorithm to support this is specified in
[6]. [7].
These functions fit together as follows. The Path Management looks These functions fit together as follows. The Path Management looks
after the discovery (and if necessary, initialisation) of multiple after the discovery (and if necessary, initialisation) of multiple
paths between two hosts. The Packet Scheduler then receives a stream paths between two hosts. The Packet Scheduler then receives a stream
of data from the application destined for the network, and undertakes of data from the application destined for the network, and undertakes
the necessary operations on it (such as segmenting the data into the necessary operations on it (such as segmenting the data into
connection-level segments, and adding a connection-level sequence connection-level segments, and adding a connection-level sequence
number) before sending it on to a subflow. The subflow then adds its number) before sending it on to a subflow. The subflow then adds its
own sequence number, ACKs, and passes them to network. The receiving own sequence number, ACKs, and passes them to network. The receiving
subflow re-orders data (if necessary) and passes it to the packet subflow re-orders data (if necessary) and passes it to the packet
skipping to change at page 13, line 50 skipping to change at page 14, line 34
in order to schedule which segments should be sent at what rate on in order to schedule which segments should be sent at what rate on
which subflow. which subflow.
5. High-Level Design Decisions 5. High-Level Design Decisions
There is seemingly a wide range of choices when designing a multipath There is seemingly a wide range of choices when designing a multipath
extension to TCP. However, the goals as discussed earlier in this extension to TCP. However, the goals as discussed earlier in this
document constrain the possible solutions, leaving relative little document constrain the possible solutions, leaving relative little
choice in many areas. Here, we outline high-level design choices choice in many areas. Here, we outline high-level design choices
that draw from the architectural basis discussed earlier in that draw from the architectural basis discussed earlier in
Section 3, which the design of MPTCP [4] takes into account. Section 3, which the design of MPTCP [5] takes into account.
5.1. Sequence Numbering 5.1. Sequence Numbering
MPTCP uses two levels of sequence spaces: a connection level sequence MPTCP uses two levels of sequence spaces: a connection level sequence
number, and another sequence number for each subflow. This permits number, and another sequence number for each subflow. This permits
connection-level segmentation and reassembly, and retransmission of connection-level segmentation and reassembly, and retransmission of
the same part of connection-level sequence space on different the same part of connection-level sequence space on different
subflow-level sequence space. subflow-level sequence space.
The alternative approach would be to use a single connection level The alternative approach would be to use a single connection level
skipping to change at page 15, line 47 skipping to change at page 16, line 31
connection-level acknowledgement to be transmitted over the shortest connection-level acknowledgement to be transmitted over the shortest
Round-Trip Time (RTT) path, potentially reducing send buffer Round-Trip Time (RTT) path, potentially reducing send buffer
requirements (see Section 5.3). requirements (see Section 5.3).
Therefore, to provide a fully robust multipath TCP solution given the Therefore, to provide a fully robust multipath TCP solution given the
above constraints, MPTCP for use on the public Internet MUST feature above constraints, MPTCP for use on the public Internet MUST feature
explicit connection-level acknowledgements, in addition to subflow- explicit connection-level acknowledgements, in addition to subflow-
level acknowledgements. A connection-level acknowledgement would level acknowledgements. A connection-level acknowledgement would
only be required in order to signal when the receive window moves only be required in order to signal when the receive window moves
forward; the heuristics for using such a signal are discussed in more forward; the heuristics for using such a signal are discussed in more
detail in the protocol specification [4]. detail in the protocol specification [5].
Regarding retransmissions, it MUST be possible for a segments to be Regarding retransmissions, it MUST be possible for a segments to be
retransmitted on a different subflow to that on which it was retransmitted on a different subflow to that on which it was
originally sent. This is one of MPTCP's core goals, in order to originally sent. This is one of MPTCP's core goals, in order to
maintain integrity during temporary or permanent subflow failure, and maintain integrity during temporary or permanent subflow failure, and
this is enabled by the dual sequence number space. this is enabled by the dual sequence number space.
The scheduling of retransmissions will have significant impact on The scheduling of retransmissions will have significant impact on
MPTCP user experience. The current MPTCP specification suggests that MPTCP user experience. The current MPTCP specification suggests that
data outstanding on subflows that have timed out should be data outstanding on subflows that have timed out should be
skipping to change at page 19, line 19 skipping to change at page 19, line 51
in the network. in the network.
Multiple different (source, destination) address pairs will thus be Multiple different (source, destination) address pairs will thus be
used as path selectors in most cases. Each path will be identified used as path selectors in most cases. Each path will be identified
by a standard five-tuple (i.e. source address, destination address, by a standard five-tuple (i.e. source address, destination address,
source port, destination port, protocol), however, which can allow source port, destination port, protocol), however, which can allow
the extension of MPTCP to use ports as well as addresses as path the extension of MPTCP to use ports as well as addresses as path
selectors. This will allow hosts to use port-based load balancing selectors. This will allow hosts to use port-based load balancing
with MPTCP, for example if the network routes different ports over with MPTCP, for example if the network routes different ports over
different paths (which may be the case with technologies such as different paths (which may be the case with technologies such as
Equal Cost MultiPath (ECMP) routing [17]). Equal Cost MultiPath (ECMP) routing [4]). It should be noted,
however, that ISPs often undertake traffic engineering in order to
optimise resource utilisation 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.
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 host SHOULD be able to add new subflows to a MPTCP middlebox), either host SHOULD be able to add new subflows to a MPTCP
connection. MPTCP MUST be able to handle paths that appear and connection. MPTCP MUST be able to handle paths that appear and
disappear during the lifetime of a connection (for example, through disappear during the lifetime of a connection (for example, through
the activation of an additional network interface). the activation of an additional network interface).
The path management is a separate function from the packet The path management is a separate function from the packet
scheduling, subflow interface, and congestion control functions of scheduling, subflow interface, and congestion control functions of
skipping to change at page 19, line 47 skipping to change at page 20, line 35
Since a MPTCP connection may not be bound to a traditional 5-tuple Since a MPTCP connection may not be bound to a traditional 5-tuple
(source address and port, destination address and port, protocol (source address and port, destination address and port, protocol
number) for the entirety of its existence, it is desirable to provide number) for the entirety of its existence, it is desirable to provide
a new mechanism for connection identification. This will be useful a new mechanism for connection identification. This will be useful
for MPTCP-aware applications, and for the MPTCP implementation (and for MPTCP-aware applications, and for the MPTCP implementation (and
MPTCP-aware middleboxes) to have a unique identifier with which to MPTCP-aware middleboxes) to have a unique identifier with which to
associate the multiple subflows. associate the multiple subflows.
Therefore, each MPTCP connection requires a connection identifier at Therefore, each MPTCP connection requires a connection identifier at
each host, which is locally unique within that host. In many ways, each host, which is locally unique within that host. In many ways,
this is analogous to a port number in regular TCP. The manifestation this is analogous to an ephemeral port number in regular TCP. The
and purpose of such an identifier is out of the scope of this manifestation and purpose of such an identifier is out of the scope
architecture document. of this architecture document.
Legacy applications will not, however, have access to this identifier Legacy applications will not, however, have access to this identifier
and in such cases a MPTCP connection will be identified by the and in such cases a MPTCP connection will be identified by the
5-tuple of the first TCP subflow. It is out of the scope of this 5-tuple of the first TCP subflow. It is out of the scope of this
document, however, to define the behaviour of the MPTCP document, however, to define the behaviour of the MPTCP
implementation if the first TCP subflow later fails. If there are implementation if the first TCP subflow later fails. If there are
MPTCP-unaware applications that make assumptions about continued MPTCP-unaware applications that make assumptions about continued
existence of the initial address pair, their behaviour could be existence of the initial address pair, their behaviour could be
disrupted by carrying on regardless. It is expected that this is a disrupted by carrying on regardless. It is expected that this is a
very small, possibly negligible, set of applications, however. In very small, possibly negligible, set of applications, however. MPTCP
the case of applications that have used an existing API call to bind MUST NOT be used for applications that request to bind to a specific
to a specific address or interface, the MPTCP extension MUST NOT be address or interface, since such applications are making a deliberate
used, since the applications are indicating a clear choice of path to choice of path in use.
use and thus will have expectations of behaviour that must be
maintained, in order to adhere to the application compatibility
goals.
Since the requirements of applications are not clear at this stage, Since the requirements of applications are not clear at this stage,
however, it is as yet unconfirmed what the best behaviour is. It however, it is as yet unconfirmed whether carrying on in the event of
will be an implementation-specific solution, however, and as such the the loss of the initial address pair would be a damaging assumption
behaviour is expected to be chosen by implementors once more research to make. This behaviour will be an implementation-specific solution,
has been undertaken to determine its impact. and as such it is expected to be chosen by implementors once more
research has been undertaken to determine its impact.
5.7. Congestion Control 5.7. Congestion Control
As discussed in network-layer compatibility requirements As discussed in network-layer compatibility requirements
Section 2.2.3, there are three goals for the congestion control Section 2.2.3, there are three goals for the congestion control
algorithms used by a MPTCP implementation: improve throughput (at algorithms used by a MPTCP implementation: improve throughput (at
least as well as a single-path TCP connection would perform); do no 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 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 path than if it was a single path flow using only that route - this
is particularly relevant for shared bottlenecks); and balance is particularly relevant for shared bottlenecks); and balance
congestion by moving traffic away from the most congested paths. To congestion by moving traffic away from the most congested paths. To
achieve these goals, the congestion control algorithms on each achieve these goals, the congestion control algorithms on each
subflow must be coupled in some way. A proposal for a suitable subflow must be coupled in some way. A proposal for a suitable
congestion control algorithm is given in [6]. congestion control algorithm is given in [7].
5.8. Security 5.8. Security
A detailed threat analysis for Multipath TCP is presented in a A detailed threat analysis for Multipath TCP is presented in a
separate document [11]. This focuses on flooding attacks and separate document [12]. This focuses on flooding attacks and
hijacking attacks that can be launched against a Multipath TCP hijacking attacks that can be launched against a Multipath TCP
connection. connection.
The basic security goal of Multipath TCP, as introduced in The basic security goal of Multipath TCP, as introduced in
Section 2.3, can be stated as: "provide a solution that is no worse Section 2.3, can be stated as: "provide a solution that is no worse
than standard TCP". than standard TCP".
From the threat analysis, and with this goal in mind, three key From the threat analysis, and with this goal in mind, three key
security requirements can be identified. A multi-addressed Multipath security requirements can be identified. A multi-addressed Multipath
TCP SHOULD be able to: TCP SHOULD be able to:
skipping to change at page 21, line 45 skipping to change at page 22, line 32
o The need to work through middleboxes results in the need to handle o The need to work through middleboxes results in the need to handle
mutability of packets. mutability of packets.
o The desire to support a 'break-before-make' (as well as a 'make- o The desire to support a 'break-before-make' (as well as a 'make-
before-break') approach to adding subflows (within a limited time before-break') approach to adding subflows (within a limited time
period) implies that a host cannot rely on using a pre-existing period) implies that a host cannot rely on using a pre-existing
subflow to support the addition of a new one. subflow to support the addition of a new one.
The MPTCP protocol will be designed with these security requirements The MPTCP protocol will be designed with these security requirements
in mind, and the protocol specification [4] will document how these in mind, and the protocol specification [5] will document how these
are met. are met.
6. Interactions with Applications 6. Software Interactions
Interactions with applications are presented in [7] - including, but 6.1. Interactions with Applications
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 behaviour
that must be maintained, in order to adhere to the application
compatibility goals.
Interactions with applications are presented in [8] - including, but
not limited to, performances changes that may be expected, semantic not limited to, performances changes that may be expected, semantic
changes, and new features that may be requested through an enhanced changes, and new features that may be requested through an enhanced
API. API.
TCP features the ability to send out-of-band ("Urgent") data. TCP features the ability to send "Urgent" data, the delivery of which
Although the use of Urgent data is not recommended (see [20]), MPTCP to the application may or may not be out-of-band. The use of this
SHOULD still support this feature if requested by an application. An feature is not recommended due to security implications and
MPTCP implementation SHOULD send the Urgent data on one subflow of implementation differences [20]. MPTCP requires contiguous data to
the MPTCP connection; it MAY choose this to be the best performing support its Data Sequence Mapping over multiple segments, and
subflow. 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.
6.2. Interactions with Management Systems
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 the these MIBs for aspects that are
designed to be transparent to the application.
It is anticipated that a 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.
7. Interactions with Middleboxes 7. Interactions with Middleboxes
As discussed in Section 2.2, it is a goal of MPTCP to be deployable 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 today and thus compatible with the majority of middleboxes. This
section summarises the issues that may arise with NATs, firewalls, section summarises the issues that may arise with NATs, firewalls,
proxies, intrusion detection systems, and other middleboxes that, if proxies, intrusion detection systems, and other middleboxes that, if
not considered in the protocol design, may hinder its deployment. not considered in the protocol design, may hinder its deployment.
This section is intended primarily as a description of options and This section is intended primarily as a description of options and
considerations only. Protocol-specific solutions to these issues considerations only. Protocol-specific solutions to these issues
will be given in the companion documents. will be given in the companion documents.
Multipath TCP will be deployed in a network that no longer provides Multipath TCP will be deployed in a network that no longer provides
just basic datagram delivery. A myriad of middleboxes are deployed just basic datagram delivery. A myriad of middleboxes are deployed
to optimize various perceived problems with the Internet protocols: to optimize various perceived problems with the Internet protocols:
NATs primarily address space shortage [14], Performance Enhancing NATs primarily address IP address space shortage [15], Performance
Proxies (PEPs) optimize TCP for different link characteristics [16], Enhancing Proxies (PEPs) optimize TCP for different link
firewalls [15] and intrusion detection systems try to block malicious characteristics [17], firewalls [16] and intrusion detection systems
content from reaching a host, and traffic normalizers [21] ensure a try to block malicious content from reaching a host, and traffic
consistent view of the traffic stream to Intrusion Detection Systems normalizers [23] ensure a consistent view of the traffic stream to
(IDS) and hosts. Intrusion Detection Systems (IDS) and hosts.
All these middleboxes optimize current applications at the expense of All these middleboxes optimize current applications at the expense of
future applications. In effect, future applications will often need future applications. In effect, future applications will often need
to behave in a similar fashion to existing ones, in order to increase to behave in a similar fashion to existing ones, in order to increase
the chances of successful deployment. Further, the precise behaviour the chances of successful deployment. Further, the precise behaviour
of all these middleboxes is not clearly specified, and implementation of all these middleboxes is not clearly specified, and implementation
errors make matters worse, raising the bar for the deployment of new errors make matters worse, raising the bar for the deployment of new
technologies. technologies.
The following list of middlebox classes documents behaviour that The following list of middlebox classes documents behaviour that
could impact the use of MPTCP. This list is used in [4] to describe 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 the features of the MPTCP protocol that are used to mitigate the
impact of these middlebox behaviours. impact of these middlebox behaviours.
o NATs: Network Address Translators decouple the host's local IP o NATs: Network Address Translators decouple the host's local IP
address (and, in the case of NAPTs, port) with that which is seen address (and, in the case of NAPTs, port) with that which is seen
in the wider Internet when the packets are transmitted through a in the wider Internet when the packets are transmitted through a
NAT. This adds complexity, and reduces the chances of success, NAT. This adds complexity, and reduces the chances of success,
when signalling IP addresses. when signalling IP addresses.
o PEPs: Performance Enhancing Proxies, which aim to improve the o PEPs: Performance Enhancing Proxies, which aim to improve the
skipping to change at page 24, line 12 skipping to change at page 25, line 24
we cannot say for sure what a middlebox will do with TCP options 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). in these cases (they may be repeated, dropped, or sent only once).
8. Contributors 8. Contributors
The authors would like to acknowledge the contributions of Andrew The authors would like to acknowledge the contributions of Andrew
McDonald and Bryan Ford to this document. McDonald and Bryan Ford to this document.
The authors would also like to thank the following people for The authors would also like to thank the following people for
detailed reviews: Olivier Bonaventure, Gorry Fairhurst, Iljitsch van detailed reviews: Olivier Bonaventure, Gorry Fairhurst, Iljitsch van
Beijnum, Philip Eardley, Michael Scharf, Lars Eggert, and Cullen Beijnum, Philip Eardley, Michael Scharf, Lars Eggert, Cullen
Jennings. Jennings, Joel Halpern, Juergen Quittek, Alexey Melnikov, David
Harrington, Jari Arkko and Stewart Bryant.
9. Acknowledgements 9. Acknowledgements
Alan Ford, Costin Raiciu, Mark Handley, and Sebastien Barre are Alan Ford, Costin Raiciu, Mark Handley, and Sebastien Barre are
supported by Trilogy (http://www.trilogy-project.org), a research supported by Trilogy (http://www.trilogy-project.org), a research
project (ICT-216372) partially funded by the European Community under project (ICT-216372) partially funded by the European Community under
its Seventh Framework Program. The views expressed here are those of its Seventh Framework Program. The views expressed here are those of
the author(s) only. The European Commission is not liable for any the author(s) only. The European Commission is not liable for any
use that may be made of the information in this document. use that may be made of the information in this document.
10. IANA Considerations 10. IANA Considerations
None. None.
11. Security Considerations 11. Security Considerations
This informational document provides an architectural overview for This informational document provides an architectural overview for
Multipath TCP and so does not, in itself, raise any security issues. Multipath TCP and so does not, in itself, raise any security issues.
A separate threat analysis [11] lists threats that can exist with a A separate threat analysis [12] lists threats that can exist with a
Multipath TCP. However, a protocol based on the architecture in this Multipath TCP. However, a protocol based on the architecture in this
document will have a number of security requirements. The high level document will have a number of security requirements. The high level
goals for such a protocol are identified in Section 2.3, whilst goals for such a protocol are identified in Section 2.3, whilst
Section 5.8 provides more detailed discussion of security Section 5.8 provides more detailed discussion of security
requirements and design decisions which are applied in the MPTCP requirements and design decisions which are applied in the MPTCP
protocol design [4]. protocol design [5].
12. References 12. References
12.1. Normative References 12.1. Normative References
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References 12.2. Informative References
[3] Wischik, D., Handley, M., and M. Bagnulo Braun, "The Resource [3] 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>.
[4] Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for [4] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm",
RFC 2992, November 2000.
[5] Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for
Multipath Operation with Multiple Addresses", Multipath Operation with Multiple Addresses",
draft-ietf-mptcp-multiaddressed-02 (work in progress), draft-ietf-mptcp-multiaddressed-02 (work in progress),
October 2010. October 2010.
[5] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, [6] Stewart, R., "Stream Control Transmission Protocol", RFC 4960,
September 2007. September 2007.
[6] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion [7] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion
Control for Multipath Transport Protocols", Control for Multipath Transport Protocols",
draft-ietf-mptcp-congestion-01 (work in progress), draft-ietf-mptcp-congestion-01 (work in progress),
January 2011. January 2011.
[7] Scharf, M. and A. Ford, "MPTCP Application Interface [8] Scharf, M. and A. Ford, "MPTCP Application Interface
Considerations", draft-ietf-mptcp-api-00 (work in progress), Considerations", draft-ietf-mptcp-api-00 (work in progress),
November 2010. November 2010.
[8] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", [9] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues",
RFC 3234, February 2002. RFC 3234, February 2002.
[9] Carpenter, B., "Internet Transparency", RFC 2775, [10] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000. February 2000.
[10] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [11] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996. Selective Acknowledgment Options", RFC 2018, October 1996.
[11] Bagnulo, M., "Threat Analysis for Multi-addressed/Multi-path [12] Bagnulo, M., "Threat Analysis for TCP Extensions for Multi-path
TCP", draft-ietf-mptcp-threat-06 (work in progress), Operation with Multiple Addresses", draft-ietf-mptcp-threat-07
December 2010. (work in progress), January 2011.
[12] Becke, M., Dreibholz, T., Iyengar, J., Natarajan, P., and M. [13] Becke, M., Dreibholz, T., Iyengar, J., Natarajan, P., and M.
Tuexen, "Load Sharing for the Stream Control Transmission Tuexen, "Load Sharing for the Stream Control Transmission
Protocol (SCTP)", draft-tuexen-tsvwg-sctp-multipath-01 (work in Protocol (SCTP)", draft-tuexen-tsvwg-sctp-multipath-01 (work in
progress), December 2010. progress), December 2010.
[13] Ford, B. and J. Iyengar, "Breaking Up the Transport Logjam", [14] Ford, B. and J. Iyengar, "Breaking Up the Transport Logjam",
ACM HotNets, October 2008. ACM HotNets, October 2008.
[14] Srisuresh, P. and K. Egevang, "Traditional IP Network Address [15] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001. Translator (Traditional NAT)", RFC 3022, January 2001.
[15] Freed, N., "Behavior of and Requirements for Internet [16] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC 2979, October 2000. Firewalls", RFC 2979, October 2000.
[16] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. [17] 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.
[17] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm",
RFC 2992, November 2000.
[18] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's [18] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961, August 2010. Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
[19] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", [19] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations",
RFC 4987, August 2007. RFC 4987, August 2007.
[20] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP [20] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP
Urgent Mechanism", RFC 6093, January 2011. Urgent Mechanism", RFC 6093, January 2011.
[21] Handley, M., Paxson, V., and C. Kreibich, "Network Intrusion [21] Raghunarayan, R., "Management Information Base for the
Transmission Control Protocol (TCP)", RFC 4022, March 2005.
[22] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP Extended
Statistics MIB", RFC 4898, May 2007.
[23] Handley, M., Paxson, V., and C. Kreibich, "Network Intrusion
Detection: Evasion, Traffic Normalization, and End-to-End Detection: Evasion, Traffic Normalization, and End-to-End
Protocol Semantics", Usenix Security 2001, 2001, <http:// Protocol Semantics", Usenix Security 2001, 2001, <http://
www.usenix.org/events/sec01/full_papers/handley/handley.pdf>. www.usenix.org/events/sec01/full_papers/handley/handley.pdf>.
Appendix A. Changelog Appendix A. Changelog
(For removal by the RFC Editor) (For removal by the RFC Editor)
A.1. Changes since draft-ietf-mptcp-architecture-03 A.1. Changes since draft-ietf-mptcp-architecture-04
o Responded to IETF Last Call and IESG review comments.
A.2. Changes since draft-ietf-mptcp-architecture-03
o Responded to AD review comments. o Responded to AD review comments.
A.2. Changes since draft-ietf-mptcp-architecture-02 A.3. Changes since draft-ietf-mptcp-architecture-02
o Responded to WG last call review comments. Included editorial o Responded to WG last call review comments. Included editorial
fixes, adding Section 2.4, and improving Section 5.4 and fixes, adding Section 2.4, and improving Section 5.4 and
Section 7. Section 7.
A.3. Changes since draft-ietf-mptcp-architecture-01 A.4. Changes since draft-ietf-mptcp-architecture-01
o Responded to review comments. o Responded to review comments.
o Added security sections. o Added security sections.
A.4. Changes since draft-ietf-mptcp-architecture-00 A.5. Changes since draft-ietf-mptcp-architecture-00
o Added middlebox compatibility discussion (Section 7). o Added middlebox compatibility discussion (Section 7).
o Clarified path identification (TCP 4-tuple) in Section 5.5. o Clarified path identification (TCP 4-tuple) in Section 5.5.
o Added brief scenario and diagram to Section 1.3. o Added brief scenario and diagram to Section 1.3.
Authors' Addresses Authors' Addresses
Alan Ford (editor) Alan Ford
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
Costin Raiciu Costin Raiciu
University College London University College London
Gower Street Gower Street
London WC1E 6BT London WC1E 6BT
UK UK
Email: c.raiciu@cs.ucl.ac.uk Email: c.raiciu@cs.ucl.ac.uk
Mark Handley Mark Handley
University College London University College London
 End of changes. 69 change blocks. 
131 lines changed or deleted 198 lines changed or added

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