draft-ietf-mptcp-architecture-02.txt   draft-ietf-mptcp-architecture-03.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: April 19, 2011 M. Handley Expires: June 11, 2011 M. Handley
University College London University College London
S. Barre
Universite catholique de
Louvain
J. Iyengar J. Iyengar
Franklin and Marshall College Franklin and Marshall College
October 16, 2010 December 8, 2010
Architectural Guidelines for Multipath TCP Development Architectural Guidelines for Multipath TCP Development
draft-ietf-mptcp-architecture-02 draft-ietf-mptcp-architecture-03
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 46 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 April 19, 2011. This Internet-Draft will expire on June 11, 2011.
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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 7
2.2.3. Compatibility with other network users . . . . . . . . 9 2.2.3. Compatibility with other network users . . . . . . . . 9
2.2.4. Security Goals . . . . . . . . . . . . . . . . . . . . 9 2.3. Security Goals . . . . . . . . . . . . . . . . . . . . . . 9
3. An Architectural Basis For MPTCP . . . . . . . . . . . . . . . 9 2.4. Related Protocols . . . . . . . . . . . . . . . . . . . . 9
3. An Architectural Basis For Multipath TCP . . . . . . . . . . . 10
4. A Functional Decomposition of MPTCP . . . . . . . . . . . . . 11 4. A Functional Decomposition of MPTCP . . . . . . . . . . . . . 11
5. High-Level Design Decisions . . . . . . . . . . . . . . . . . 13 5. High-Level Design Decisions . . . . . . . . . . . . . . . . . 13
5.1. Sequence Numbering . . . . . . . . . . . . . . . . . . . . 13 5.1. Sequence Numbering . . . . . . . . . . . . . . . . . . . . 13
5.2. Reliability and Retransmissions . . . . . . . . . . . . . 14 5.2. Reliability and Retransmissions . . . . . . . . . . . . . 14
5.3. Buffers . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Buffers . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 16 5.4. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 17
5.5. Path Management . . . . . . . . . . . . . . . . . . . . . 17 5.5. Path Management . . . . . . . . . . . . . . . . . . . . . 18
5.6. Connection Identification . . . . . . . . . . . . . . . . 18 5.6. Connection Identification . . . . . . . . . . . . . . . . 19
5.7. Congestion Control . . . . . . . . . . . . . . . . . . . . 18 5.7. Congestion Control . . . . . . . . . . . . . . . . . . . . 20
5.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Interactions with Applications . . . . . . . . . . . . . . . . 20 6. Interactions with Applications . . . . . . . . . . . . . . . . 21
7. Interactions with Middleboxes . . . . . . . . . . . . . . . . 20 7. Interactions with Middleboxes . . . . . . . . . . . . . . . . 21
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 25
A.1. Changes since draft-ietf-mptcp-architecture-01 . . . . . . 24 A.1. Changes since draft-ietf-mptcp-architecture-02 . . . . . . 25
A.2. Changes since draft-ietf-mptcp-architecture-00 . . . . . . 24 A.2. Changes since draft-ietf-mptcp-architecture-01 . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 A.3. Changes since draft-ietf-mptcp-architecture-00 . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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 that would otherwise be needed to create an network infrastructure that would otherwise be needed to create an
skipping to change at page 4, line 28 skipping to change at page 4, line 28
the user. The purpose of a multipath transport, therefore, is to the user. The purpose of a multipath transport, therefore, is to
make use of multiple available paths, through resource pooling, to make use of multiple available paths, through resource pooling, to
bring two key benefits: 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.
MPTCP [4] is a set of extensions for 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, transparent to the application. paths within a transport connection, transparently to the
application. MPTCP, defined in [4], 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, MPTCP aims to gain wide-scale deployment by recognising protocols (SCTP [5] being a notable example), MPTCP aims to gain
the importance of application and network compatibility goals. These wide-scale deployment by recognising the importance of application
goals, discussed in detail in Section 2, relate to the appearance of and network compatibility goals. These goals, discussed in detail in
MPTCP to the network (so non-MPTCP-aware entities see it as TCP) and Section 2, relate to the appearance of MPTCP to the network (so non-
to the application (through providing an equivalent service to TCP to MPTCP-aware entities see it as TCP) and to the application (through
non-MPTCP-aware applications). providing an equivalent service to TCP to non-MPTCP-aware
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[4], congestion control
algorithms[5], and application-level considerations[6]. Put algorithms[6], and application-level considerations[7]. 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 with other protocols We note that specific components are replaceable in accordance with
in accordance with the layer and functional decompositions discussed the layer and functional decompositions discussed in this document.
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
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.
Path Identifier: Within the context of a multi-addressed multipath Path Identifier: Within the context of a multi-addressed multipath
TCP, a path is defined by the source and destination (address, TCP, a path is defined by the source and destination (address,
port) pairs (i.e. a 4-tuple). port) pairs (i.e. a 4-tuple).
Host: An end host either initiating or terminating a MPTCP Host: An end host either initiating or terminating a Multipath TCP
connection. connection.
Multipath TCP: A modified version of the TCP [1] protocol that Multipath TCP: A modified version of the TCP [1] protocol that
supports the simultaneous use of multiple paths between hosts. supports the simultaneous use of multiple paths between hosts.
MPTCP: The proposed protocol extensions specified in [4] to provide MPTCP: The proposed protocol extensions specified in [4] to provide
a Multipath TCP implementation. a Multipath TCP implementation.
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 Multipath TCP connection.
MPTCP Connection: A set of one or more subflows combined to provide (Multipath TCP) Connection: A set of one or more subflows combined
a single Multipath TCP service to an application at a host. to provide a single Multipath TCP service to an application at a
host.
1.3. Reference Scenario 1.3. Reference Scenario
The diagram shown in Figure 1 illustrates a typical usage scenario The diagram shown in Figure 1 illustrates a typical usage scenario
for MPTCP. Two hosts, A and B, are communicating with each other. for Multipath TCP. Two hosts, A and B, are communicating with each
These hosts are multi-homed and multi-addressed, providing two other. These hosts are multi-homed and multi-addressed, providing
disjoint connections to the Internet. The addresses on each host are two disjoint connections to the Internet. The addresses on each host
referred to as A1, A2, B1 and B2. There are therefore up to four are referred to as A1, A2, B1 and B2. There are therefore up to four
different paths between the two hosts: A1-B1, A1-B2, A2-B1, A2-B2. different paths between the two hosts: A1-B1, A1-B2, A2-B1, A2-B2.
+------+ __________ +------+ +------+ __________ +------+
| |A1 ______ ( ) ______ B1| | | |A1 ______ ( ) ______ B1| |
| Host |--/ ( ) \--| Host | | Host |--/ ( ) \--| Host |
| | ( Internet ) | | | | ( Internet ) | |
| A |--\______( )______/--| B | | A |--\______( )______/--| B |
| |A2 (__________) B2| | | |A2 (__________) B2| |
+------+ +------+ +------+ +------+
Figure 1: Simple MPTCP 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, so 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 - shared bottlenecks will be addressed by the MPTCP entirely disjoint - shared bottlenecks will be addressed by the
congestion controller. Furthermore, the paths through the Internet Multipath TCP congestion controller. Furthermore, the paths through
may be interrupted by any number of middleboxes including NATs and the Internet may be interrupted by any number of middleboxes
Firewalls. Finally, although the diagram refers to the Internet, including NATs and Firewalls. Finally, although the diagram refers
MPTCP may be used over any network where there are multiple paths to the Internet, Multipath TCP may be used over any network where
that could be used concurrently. there are multiple paths that could be used concurrently.
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 Multipath TCP must provide; and services and features that Multipath TCP must provide; and
compatibility goals, which determine how Multipath TCP should appear compatibility goals, which determine how Multipath TCP should appear
to entities that interact with it. to entities that interact with it.
2.1. Functional Goals 2.1. Functional Goals
skipping to change at page 7, line 21 skipping to change at page 7, line 31
deployment in today's Internet. These goals fall into the following deployment in today's Internet. These goals fall into the following
categories: categories:
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, an 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 than it would expect from running a single TCP connection
over any one of its available paths. over any one of its available paths.
A multipath-capable equivalent of TCP SHOULD retain backward A multipath-capable equivalent of TCP SHOULD retain backward
compatibility with existing TCP APIs, so that existing applications compatibility with existing TCP APIs, so that existing applications
can use the newer transport merely by upgrading the operating systems can use the newer transport merely by upgrading the operating systems
of the end-hosts. This does not preclude the use of an advanced API of the end-hosts. This does not preclude the use of an advanced API
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 default, for example switching on or off the automatic use of
multipath extensions. multipath extensions.
2.2.2. Network Compatibility 2.2.2. Network Compatibility
Traditional Internet architecture slots network devices in the In the traditional Internet architecture, network devices operate at
network layer and lower layers, where the layers above the network the network layer and lower layers, with the layers above the network
layer are instantiated only at the end-hosts. While this layer instantiated only at the end-hosts. While this architecture,
architecture, shown in Figure 2, was initially largely adhered to, shown in Figure 2, was initially largely adhered to, this layering no
this layering no longer reflects the "ground truth" in the Internet longer reflects the "ground truth" in the Internet with the
with the proliferation of middleboxes[7]. Middleboxes routinely proliferation of middleboxes[8]. Middleboxes routinely interpose on
interpose on the transport layer; sometimes even completely the transport layer; sometimes even completely terminating transport
terminating transport connections, thus leaving the application layer connections, thus leaving the application layer as the first real
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 |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
End Host Router Router End Host End Host Router Router End Host
skipping to change at page 8, line 29 skipping to change at page 8, line 33
| 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"[8], 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.
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[7]. This requirement comes from recognizing enhancing proxies[8]. 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, and constrains Multipath TCP to appear as TCP does that is not TCP, and constrains Multipath TCP to appear as TCP does
on the wire and to use established TCP extensions where necessary. on the wire and to use established TCP extensions where necessary.
To ensure end-to-endness of the transport, we further require To ensure end-to-endness of the transport, we further require
Multipath TCP to preserve fate-sharing without making any assumptions Multipath TCP to preserve fate-sharing without making any assumptions
about middlebox behavior. 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.
MPTCP's modifications remain at the transport layer, although some The modifications to support Multipath TCP remain at the transport
knowledge of the underlying network layer is required. MPTCP SHOULD layer, although some knowledge of the underlying network layer is
work with IPv4 and IPv6 interchangeably, i.e. one MPTCP connection required. Multipath TCP SHOULD work with IPv4 and IPv6
may operate over both IPv4 and IPv6 networks. interchangeably, i.e. one connection may operate over both IPv4 and
IPv6 networks.
2.2.3. Compatibility with other network users 2.2.3. Compatibility with other network users
As a corollary to both network and application compatibility, the As a corollary to both network and application compatibility, the
architecture must enable new Multipath TCP flows to coexist architecture must enable new Multipath TCP flows to coexist
gracefully with existing single-path TCP flows, competing for gracefully with existing single-path TCP flows, competing for
bandwidth neither unduly aggressively or unduly timidly (unless low- bandwidth neither unduly aggressively nor unduly timidly (unless low-
precedence operation is specifically requested by the application, precedence operation is specifically requested by the application,
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 the similar fairness to that which occurs between each other with similar fairness to that which occurs at a
with a shared bottleneck with single-path TCP. shared bottleneck with single-path TCP.
2.2.4. 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 [9]. The security goal number of new threats, analysed in detail in [10]. 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.
3. An Architectural Basis For MPTCP 2.4. Related Protocols
There are several similarities between SCTP [5] and MPTCP, in that
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
redundancy and mobility for multihomed hosts (i.e. a single path will
change one of its end host addresses); the simultaneous use of
multiple paths is not supported . Extensions are proposed to support
simultaneous multipath transport [11], but these are yet to be
standardised. The de facto standard stream-based transport protocol
is, however, TCP [1], and SCTP does not meet the network and
application compatibility goals specified in Section 2.2. For
network compatibility, there are issues with various middleboxes
(especially NATs) that are unaware of SCTP and consequently end up
blocking it. For application compatibility, applications need to
actively choose to use SCTP, and with the deployment issues very few
choose to do so. MPTCP's compatibility goals are in part based on
these observations of SCTP's deployment issues.
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 MPTCP's goals. The new Internet model can effectively support the goals for Multipath TCP. The new
described here is based on ideas proposed earlier in Tng ("Transport Internet model described here is based on ideas proposed earlier in
next-generation") [10]. While by no means the only possible Tng ("Transport next-generation") [12]. While by no means the only
architecture supporting multipath transport, Tng incorporates many possible architecture supporting multipath transport, Tng
lessons learned from previous transport research and development incorporates many lessons learned from previous transport research
practice, and offers a strong starting point from which to consider and development practice, and offers a strong starting point from
the extant Internet architecture and its bearing on the design of any which to consider the extant Internet architecture and its bearing on
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)
+ - - Transport - -+ ---------------------------------- + - - Transport - -+ ----------------------------------
| | | Network-oriented transport | | | Network-oriented transport
+------------------+ v functions (Flow+Endpoint Layer) +------------------+ v functions (Flow+Endpoint Layer)
| Network | | Network |
+------------------+ +------------------+
skipping to change at page 10, line 28 skipping to change at page 10, line 45
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[11] [12] or optimize communication enforce network usage policies[13] [14] or optimize communication
performance[13]. Figure 5 shows how middleboxes interact with performance[15]. 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 11, line 19 skipping to change at page 11, line 38
+--------------------------+ +-------------------------------+ +--------------------------+ +-------------------------------+
| Application | | Application | | Application | | Application |
+--------------------------+ +-------------------------------+ +--------------------------+ +-------------------------------+
| Semantic | | MPTCP | | Semantic | | MPTCP |
|------------+-------------| + - - - - - - - + - - - - - - - + |------------+-------------| + - - - - - - - + - - - - - - - +
| Flow+Endpt | Flow+Endpt | | Subflow (TCP) | Subflow (TCP) | | Flow+Endpt | Flow+Endpt | | Subflow (TCP) | Subflow (TCP) |
+------------+-------------+ +---------------+---------------+ +------------+-------------+ +---------------+---------------+
| Network | Network | | IP | IP | | Network | Network | | IP | IP |
+------------+-------------+ +---------------+---------------+ +------------+-------------+ +---------------+---------------+
Figure 6: MPTCP mapping to Tng Figure 6: Relationship between Tng (left) and MPTCP (right)
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
MPTCP, as described in [4], makes use of (what appear to the network The previous two sections have discussed the goals for a Multipath
to be) standard TCP sessions, termed "subflows", to provide the TCP design, and provided a basis for decomposing the functions of a
underlying transport per path, and as such these retain the network transport protocol in order to better understand the form a solution
compatibility desired. MPTCP-specific information is carried in a should take. This section builds upon this analysis by presenting
TCP-compatible manner, although this mechanism is separate from the the functional components that are used within the MPTCP design.
actual information being transferred so could evolve in future
revisions. Figure 7 illustrates the layered architecture. MPTCP makes use of (what appear to the network to be) standard TCP
sessions, termed "subflows", to provide the underlying transport per
path, and as such these retain the network compatibility desired.
MPTCP-specific information is carried in a TCP-compatible manner,
although this mechanism is separate from the actual information being
transferred so could evolve in future revisions. Figure 7
illustrates the layered architecture.
+-------------------------------+ +-------------------------------+
| Application | | Application |
+---------------+ +-------------------------------+ +---------------+ +-------------------------------+
| Application | | MPTCP | | Application | | MPTCP |
+---------------+ + - - - - - - - + - - - - - - - + +---------------+ + - - - - - - - + - - - - - - - +
| TCP | | Subflow (TCP) | Subflow (TCP) | | TCP | | Subflow (TCP) | Subflow (TCP) |
+---------------+ +-------------------------------+ +---------------+ +-------------------------------+
| IP | | IP | IP | | IP | | IP | IP |
+---------------+ +-------------------------------+ +---------------+ +-------------------------------+
Figure 7: 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 in turn manages Situated below the application, the MPTCP extension in turn manages
multiple TCP subflows below it. In order to do this, it must multiple TCP subflows below it. In order to do this, it must
implement the following functions: 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 hosts. In the case of the MPTCP design [4], paths between two hosts. MPTCP uses the presence of multiple IP
this feature is implemented using multiple IP addresses at one or addresses at one or both of the hosts as an indicator of this.
both of the hosts. The path management features of the MPTCP The path management features of the MPTCP protocol are the
protocol are the mechanisms to signal alternative addresses to mechanisms to signal alternative addresses to hosts, and
hosts, and mechanisms to set up new subflows joined to an existing mechanisms to set up new subflows joined to an existing MPTCP
MPTCP connection. connection.
o Packet Scheduling: This function breaks the bytestream received o Packet Scheduling: This function breaks the bytestream received
from the application into segments to be transmitted on one of the from the application into segments to be transmitted on one of the
available lower subflows. The MPTCP design makes use of a data available subflows. The MPTCP design makes use of a data sequence
sequence mapping, associating segments sent on different subflows mapping, associating segments sent on different subflows to a
to a connection-level sequence numbering, thus allowing segments connection-level sequence numbering, thus allowing segments sent
sent on different subflows to be correctly re-ordered at the on different subflows to be correctly re-ordered at the receiver.
receiver. The packet scheduler is dependent upon information The packet scheduler is dependent upon information about the
about the availability of paths exposed by the path management availability of paths exposed by the path management component,
component, and then makes use of the subflows to transmit queued and then makes use of the subflows to transmit queued segments.
segments. This function is also responsible for connection-level re-ordering
on receipt of packets from the TCP subflows, according to the
attached data sequence mappings.
o Subflow (single-path TCP) Interface: A subflow component takes o Subflow (single-path TCP) Interface: A subflow component takes
segments from the packet-scheduling component and transmits them segments from the packet-scheduling component and transmits them
over the specified path, ensuring detectable delivery to the host. over the specified path, ensuring detectable delivery to the host.
MPTCP uses TCP underneath for network compatibility; TCP ensures MPTCP uses TCP underneath for network compatibility; TCP ensures
in-order, reliable delivery. TCP adds its own sequence numbers to in-order, reliable delivery. TCP adds its own sequence numbers to
the segments; these are used to detect and retransmit lost packets the segments; these are used to detect and retransmit lost packets
at the subflow layer. The connection-level sequence numbering at the subflow layer. On receipt, the subflow passes its
from the packet scheduling component allows re-ordering of the reassembled data to the packet scheduling component for
connection-level reassembly; the data sequence mapping from the
sender's packet scheduling component allows re-ordering of the
entire 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 bottlneck. An algorithm to support this is specified in shared bottlneck. An algorithm to support this is specified in
[5]. [6].
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 14 skipping to change at page 13, line 43
in order to schedule which packets should be sent at what rate on in order to schedule which packets 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, and their implications for the MPTCP design [4]. Section 3, which the design of MPTCP [4] 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 13, line 43 skipping to change at page 14, line 24
retransmissions). retransmissions).
The sender must be able to tell the receiver how to reassemble the The sender must be able to tell the receiver how to reassemble the
data, for delivery to the application. In order to achieve this, the data, for delivery to the application. In order to achieve this, the
receiver must determine how subflow-level data (carying subflow receiver must determine how subflow-level data (carying subflow
sequence numbers) maps at the connection level. We refer to this as sequence numbers) maps at the connection level. We refer to this as
the Data Sequence Mapping. This mapping takes the form (data seq, the Data Sequence Mapping. This mapping takes the form (data seq,
subflow seq, length), i.e. for a given number of bytes (the length), subflow seq, length), i.e. for a given number of bytes (the length),
the subflow sequence space beginning at the given sequence number the subflow sequence space beginning at the given sequence number
maps to the connection-level sequence space (beginning at the given maps to the connection-level sequence space (beginning at the given
data seq number). data seq number). This information could conceivably have various
sources.
This architecture does not mandate a mechanism for signalling the
Data Sequence Mapping, and it could conceivably have various sources.
One option would be to use existing fields in the TCP segment (such One option to signal the Data Sequence Mapping would be to use
as subflow seqno, length) and only add the data sequence number to existing fields in the TCP segment (such as subflow seqno, length)
each segment, for instance as a TCP option. This is, however, and only add the data sequence number to each segment, for instance
vulnerable to middleboxes that resegment or assemble data, since as a TCP option. This would be vulnerable, however, to middleboxes
there is no specified behaviour for coalescing TCP options. If one that resegment or assemble data, since there is no specified
signalled (data seqno, length), this would still be vulnerable to behaviour for coalescing TCP options. If one signalled (data seqno,
middleboxes that coalesce segments and do not understand MPTCP length), this would still be vulnerable to middleboxes that coalesce
signalling so do not correctly rewrite the options. segments and do not understand MPTCP signalling so do not correctly
rewrite the options.
Because of these potential issues, the design decision taken in the Because of these potential issues, the design decision taken in the
MPTCP protocol [4] is that whenever a mapping for subflow data needs MPTCP protocol is that whenever a mapping for subflow data needs to
to be conveyed to the other host, all three pieces of data (data seq, be conveyed to the other host, all three pieces of data (data seq,
subflow seq, length) must be sent. To reduce the overhead, it would subflow seq, length) must be sent. To reduce the overhead, it would
be permissable for the mapping to be sent periodically and cover more be permissable for the mapping to be sent periodically and cover more
than a single segment. Further experimentation is required to than a single segment. Further experimentation is required to
determine what tradeoffs exist regarding the frequency at which determine what tradeoffs exist regarding the frequency at which
mappings should be sent. It could also be excluded entirely in the mappings should be sent. It could also be excluded entirely in the
case of a connection before more than one subflow is used, where the case of a connection before more than one subflow is used, where the
data-level and subflow-level sequence space is the same. data-level and subflow-level sequence space is the same.
5.2. Reliability and Retransmissions 5.2. Reliability and Retransmissions
skipping to change at page 14, line 37 skipping to change at page 15, line 15
Under normal behaviour, MPTCP can use the data sequence mapping and Under normal behaviour, MPTCP can use the data sequence mapping and
subflow ACKs to decide when a connection-level segment was received. subflow ACKs to decide when a connection-level segment was received.
The transmission of TCP ACKs for a subflow are handled entirely at The transmission of TCP ACKs for a subflow are handled entirely at
the subflow level, in order to maintain TCP semantics and trigger the subflow level, in order to maintain TCP semantics and trigger
subflow-level retransmissions. This has certain implications on end- subflow-level retransmissions. This has certain implications on end-
to-end semantics. It means that once a packet is acked at the to-end semantics. It means that once a packet is acked at the
subflow level it cannot be discarded in the re-order buffer at the subflow level it cannot be discarded in the re-order buffer at the
connection level. Secondly, unlike in standard TCP, a receiver connection level. Secondly, unlike in standard TCP, a receiver
cannot simply drop out-of-order segments if needed (for instance, due cannot simply drop out-of-order segments if needed (for instance, due
to memory pressure). Under certain circumstances, therefore, it may to memory pressure). Under certain circumstances, therefore, it may
be desirable to be able to drop packets after acknowledgement on the be desirable to drop packets after acknowledgement on the subflow but
subflow but before delivery to the application, and this can be before delivery to the application, and this can be facilitated by a
facilitated by a connection-level acknowledgement. connection-level acknowledgement.
Furthermore, it is possible to conceive of some cases where Furthermore, it is possible to conceive of some cases where
connection-level acknowledgements could improve robustness. Consider connection-level acknowledgements could improve robustness. Consider
a subflow traversing a transparent proxy: if the proxy acks a segment a subflow traversing a transparent proxy: if the proxy acks a segment
and then crashes, the sender will not retransmit the lost segment on and then crashes, the sender will not retransmit the lost segment on
another subflow, as it thinks the segment has been received. The another subflow, as it thinks the segment has been received. The
connection grinds to a halt despite having other working subflows, connection grinds to a halt despite having other working subflows,
and the sender would be unable to determine the cause of the problem. and the sender would be unable to determine the cause of the problem.
An example situation where this may occur would be mobility between An example situation where this may occur would be mobility between
wireless access points, each of which operates a transport-level wireless access points, each of which operates a transport-level
proxy. Finally, as an optimisation, it may be feasible for a proxy. Finally, as an optimisation, it may be feasible for a
connection-level acknowledgement to be transmitted over the shortest connection-level acknowledgement to be transmitted over the shortest
RTT path, potentially reducing send buffer requirements (see Round-Trip Time (RTT) path, potentially reducing send buffer
Section 5.3). requirements (see Section 5.3).
Therefore, to provide a fully robust multipath TCP solution, MPTCP Therefore, to provide a fully robust multipath TCP solution, MPTCP
SHOULD feature explicit connection-level acknowledgements, in SHOULD feature explicit connection-level acknowledgements, in
addition to subflow-level acknowledgements. A connection-level addition to subflow-level acknowledgements. A connection-level
acknowledgement would only be required in order to signal when the acknowledgement would only be required in order to signal when the
receive window moves forward; the heuristics for using such a signal receive window moves forward; the heuristics for using such a signal
are discussed in more detail in the protocol specificiation [4]. are discussed in more detail in the protocol specification [4].
Regarding retransmissions, it MUST be possible for a packet to be Regarding retransmissions, it MUST be possible for a packet 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 15, line 44 skipping to change at page 16, line 21
maintain subflow integrity, as per the network compatiblity goal. By maintain subflow integrity, as per the network compatiblity goal. By
doing this, throughput will be wasted, and it is unclear at this doing this, throughput will be wasted, and it is unclear at this
point what the optimal retransmit strategy is. point what the optimal retransmit strategy is.
Large-scale experiments are therefore required in order to determine Large-scale experiments are therefore required in order to determine
the most appropriate retransmission strategy, and recommendations the most appropriate retransmission strategy, and recommendations
will be refined once more information is available. will be refined once more information is available.
5.3. Buffers 5.3. Buffers
To ensure in-order delivery, Multipath TCP must use a connection To ensure in-order delivery, MPTCP must use a connection level
level receive buffer, where segments are placed until they are in receive buffer, where segments are placed until they are in order and
order and can be read by the application. can be read by the application.
In regular, single-path TCP, it is usually recommended to set the In regular, single-path TCP, it is usually recommended to set the
receive buffer to 2*BDP (Bandwidth-Delay Product, i.e. BDP = BW*RTT, receive buffer to 2*BDP (Bandwidth-Delay Product, i.e. BDP = BW*RTT,
where BW = Bandwidth and RTT = Round-Trip Time). One BDP allows where BW = Bandwidth and RTT = Round-Trip Time). One BDP allows
supporting reordering of segments by the network. The other BDP supporting reordering of segments by the network. The other BDP
allows the connection to continue during fast retransmit: when a allows the connection to continue during fast retransmit: when a
segment is fast retransmitted, the receiver must be able to store segment is fast retransmitted, the receiver must be able to store
incoming data during one more RTT. incoming data during one more RTT.
For Multipath TCP, the story is a bit more complicated. The ultimate For MPTCP, the story is a bit more complicated. The ultimate goal is
goal is that a subflow packet loss or subflow failure should not that a subflow packet loss or subflow failure should not affect the
affect the throughput of other working subflows; the receiver should throughput of other working subflows; the receiver should have enough
have enough buffering to store all data until the missing packet is buffering to store all data until the missing packet is re-
re-transmitted and reaches the destination. transmitted and reaches the destination.
The worst case scenario would be when the subflow with the highest The worst case scenario would be when the subflow with the highest
RTT/RTO (Round-Trip Time or Retransmission TimeOut) experiences a RTT/RTO (Round-Trip Time or Retransmission TimeOut) experiences a
timeout; in that case the receiver has to buffer data from all timeout; in that case the receiver has to buffer data from all
subflows for the duration of the RTO. Thus, the smallest connection- subflows for the duration of the RTO. Thus, the smallest connection-
level receive buffer that would be needed to avoid stalling with level receive buffer that would be needed to avoid stalling with
subflow failures is sum(BW_i)*RTO_max, where BW_i = Bandwidth for subflow failures is sum(BW_i)*RTO_max, where BW_i = Bandwidth for
each subflow and RTO_max is the largest RTO across all subflows. each subflow and RTO_max is the largest RTO across all subflows.
This is an order of magnitude more than the receive buffer required This is an order of magnitude more than the receive buffer required
skipping to change at page 17, line 8 skipping to change at page 17, line 32
5.4. Signalling 5.4. Signalling
Since MPTCP uses TCP as its subflow transport mechanism, a MPTCP Since MPTCP uses TCP as its subflow transport mechanism, a MPTCP
connection will also begin as a single TCP connection. Nevertheless, connection will also begin as a single TCP connection. Nevertheless,
it must signal to the peer that it supports MPTCP and wishes to use it must signal to the peer that it supports MPTCP and wishes to use
it on this connection. As such, a TCP Option will be used to it on this connection. As such, a TCP Option will be used to
transmit this information, since this is the established mechanism transmit this information, since this is the established mechanism
for indicating additional functionality on a TCP session. for indicating additional functionality on a TCP session.
In addition, further signalling is required during the operation of In addition, further signalling is required during the operation of a
an MPTCP session, such as that for reassembly for multiple subflows, MPTCP session, such as that for reassembly for multiple subflows, and
and for informing the other host about potential other available for informing the other host about potential other available
addresses. It is not mandated by the architecture in what format addresses.
this signalling should be transmitted.
The MPTCP protocol design [4] continues to use TCP Options for this The MPTCP protocol design will, however, use TCP Options for this
signalling. This has been chosen as the mechanism most fitting in additional signalling. This has been chosen as the mechanism most
with the goals as specified in Section 2. With this mechanism, the fitting in with the goals as specified in Section 2. With this
signalling requires to operate MPTCP is transported separately from mechanism, the signalling requires to operate MPTCP is transported
the data, allowing it to be created and processed separately from the separately from the data, allowing it to be created and processed
data stream, and retaining architectural compatibility with network separately from the data stream, and retaining architectural
entities. compatibility with network entities.
This decision is the consensus of the Working Group (following
detailed discussions at IETF78), and the main reasons for this are as
follows:
o TCP options are the traditional signalling method for TCP;
o A TCP option on a SYN is the most compatible way for an end host
to signal it is MPTCP-capable;
o If connection-level ACKs are signalled in the payload then they
may suffer from packet loss and may be congestion-controlled,
which may affect the data throughput in the forward direction and
could lead to head-of-line blocking;
o Middleboxes, such as NAT traversal helpers, can easily parse TCP
options, e. g., to rewrite addresses.
On the other hand, the main drawbacks of TCP options compared to TLV
encoding in the payload are:
o There is limited space for signalling messages;
o A middlebox may, potentially, drop a packet with an unknown
option;
o The transport of control information in options is not necessarily
reliable.
The detailed design of MPTCP alleviates these issues as far as
possible by carefully considering the size of MPTCP options, and
seamlessly falling back to regular TCP on the loss of control data.
Both option and payload encoding may interfere with offloading of TCP
processing to high speed network interface cards, such as
segmentation, checksumming, and reassembly. For network cards
supporting MPTCP, signalling in TCP options should simplify
offloading due to the separate handling of MPTCP signalling and data.
5.5. Path Management 5.5. Path Management
Currently, the network does not expose multiple paths between hosts. Currently, the network does not expose multiple paths between hosts.
Multipath TCP will use multiple addresses at one or both hosts to In the typical case, MPTCP uses multiple addresses at one or both
infer different paths across the network. The hope is that these hosts to infer different paths across the network. It is expected
paths, whilst not necesarily entirely non-overlapping, will be that these paths, whilst not necesarily entirely non-overlapping,
sufficiently disjoint to allow multipath to achieve improved will be sufficiently disjoint to allow multipath to achieve improved
throughput and robustness. The use of multiple IP addresses is a throughput and robustness. The use of multiple IP addresses is a
simple mechanism that requires no additional features in the network. simple mechanism that requires no additional features 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. Each path will be identified by a TCP used as path selectors in most cases. Each path will be identified
4-tuple (i.e. source address, destination address, source port, by a TCP 4-tuple (i.e. source address, destination address, source
destination port), thus allowing the extension of MPTCP to use such port, destination port), however, which can allow the extension of
4-tuples as path selectors if the network will route different ports MPTCP to use such 4-tuples as path selectors. This will allow hosts
over different paths (which may be the case with technologies such as to use MPTCP to load balance to different ports, for example if the
Equal Cost MultiPath (ECMP) routing, e.g. [14]). network routes different ports over different paths (which may be the
case with technologies such as Equal Cost MultiPath (ECMP) routing
[16]).
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 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
Since an 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 addr and port, destination addr and port, protocol number) (source address and port, destination address and port, protocol
for the entirity of its existance, it is desirable to provide a new number) for the entirety of its existence, it is desirable to provide
mechanism for connection identification. This will be useful for a new mechanism for connection identification. This will be useful
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 a port number in regular TCP. The manifestation
and purpose of such an identifier is out of the scope of this and purpose of such an identifier is out of the scope of this
architecture document. 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
existance 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. In
the case of applications that have used an existing API call to bind 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 to a specific address or interface, the MPTCP extension MUST NOT be
used, since the applications are indicating a clear choice of path to used, since the applications are indicating a clear choice of path to
use and thus will have expectations of behaviour that must be use and thus will have expectations of behaviour that must be
maintained, in order to adhere to the application compatibility maintained, in order to adhere to the application compatibility
goals. 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 what the best behaviour is. It
will be an implementation-specific solution, however, and as such the will be an implementation-specific solution, however, and as such the
behaviour is expected to be chosen by implementors once more research behaviour is expected to be chosen by implementors once more research
has been undertaken to determine its impact. 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 an 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 use 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 [5]. congestion control algorithm is given in [6].
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 [9]. This focuses on flooding attacks and separate document [10]. 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.2.4, 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:
o Provide a mechanism to confirm that the parties in a subflow o Provide a mechanism to confirm that the parties in a subflow
handshake are the same as in the original connection setup (e.g. handshake are the same as in the original connection setup (e.g.
require use of a key exchanged in the initial handshake in the require use of a key exchanged in the initial handshake in the
subflow handshake, to limit the scope for hijacking attacks). subflow handshake, to limit the scope for hijacking attacks).
skipping to change at page 19, line 38 skipping to change at page 21, line 4
o Provide verification that the peer can receive traffic at a new o Provide verification that the peer can receive traffic at a new
address before adding it (i.e. verify that the address belongs to address before adding it (i.e. verify that the address belongs to
the other host, to prevent flooding attacks). the other host, to prevent flooding attacks).
o Provide replay protection, i.e. ensure that a request to add/ o Provide replay protection, i.e. ensure that a request to add/
remove a subflow is 'fresh'. remove a subflow is 'fresh'.
Additional mechanisms have been deployed as part of standard TCP Additional mechanisms have been deployed as part of standard TCP
stacks to provide resistance to Denial-of-Service attacks. For stacks to provide resistance to Denial-of-Service attacks. For
example, there are various mechanisms to protect against TCP reset example, there are various mechanisms to protect against TCP reset
attacks [15], and Multipath TCP should continue to support similar attacks [17], and Multipath TCP should continue to support similar
protection. In addition, TCP SYN Cookies [16] were developed to protection. In addition, TCP SYN Cookies [18] were developed to
allow a TCP server to defer the creation of session state in the allow a TCP server to defer the creation of session state in the
SYN_RCVD state, and remain stateless until the ESTABLISHED state had SYN_RCVD state, and remain stateless until the ESTABLISHED state had
been reached. Multipath TCP should, ideally, continue to provide been reached. Multipath TCP should, ideally, continue to provide
such functionality and, at a minimum, avoid significant computational such functionality and, at a minimum, avoid significant computational
burden prior to reaching the ESTABLISHED state (of the Multipath TCP burden prior to reaching the ESTABLISHED state (of the Multipath TCP
connection as a whole). connection as a whole).
It should be noted that aspects of the Multipath TCP design space It should be noted that aspects of the Multipath TCP design space
place constraints on the security solution: place constraints on the security solution:
o The use of TCP options significantly limits the amount of o The use of TCP options significantly limits the amount of
information that can be carried in the handshake. information that can be carried in the handshake.
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' approach to adding o The desire to support a 'break-before-make' (as well as a 'make-
subflows removes the ability to actively use a pre-existing before-break') approach to adding subflows implies that a host
subflow to support the addition of a new one. cannot rely on using a pre-existing subflow to support the
addition of a new one.
The MPTCP protocol design [4] aims to meet these security The MPTCP protocol will be designed with these security requirements
requirements, and the protocol specification will document how these in mind, and the protocol specification [4] will document how these
are met. are met.
6. Interactions with Applications 6. Interactions with Applications
Interactions with applications - incuding, but not limited to, Interactions with applications are presented in [7] - including, but
performances changes that may be expected, semantic changes, and new not limited to, performances changes that may be expected, semantic
features that may be requested of an API, are presented in [6]. changes, and new features that may be requested through an enhanced
API.
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 miriad of middleboxes are deployed just basic datagram delivery. A miriad 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 [11], Performance Enhancing NATs primarily address space shortage [13], Performance Enhancing
Proxies (PEPs) optimize TCP for different link characteristics [13], Proxies (PEPs) optimize TCP for different link characteristics [15],
firewalls [12] and intrusion detection systems try to block malicious firewalls [14] and intrusion detection systems try to block malicious
content from reaching a host, and traffic normalizers [17] ensure a content from reaching a host, and traffic normalizers [19] ensure a
consistent view of the traffic stream to IDSes and hosts. consistent view of the traffic stream to 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 [4] 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 with that which is seen in the wider Internet when the address (and, in the case of NAPTs, port) with that which is seen
packets are transmitted through a NAT. This adds complexity, and in the wider Internet when the packets are transmitted through a
reduces the chances of success, when signalling IP addresses. NAT. This adds complexity, and reduces the chances of success,
when signalling IP addresses.
o PEPs: Performance Enhancing Proxies, which aim to improve the o PEPs: Performance Enhancing Proxies, which aim to improve the
performance of protocols over low-performance (e.g. high latency performance of protocols over low-performance (e.g. high latency
or high error rate) links. As such, they may "split" a TCP or high error rate) links. As such, they may "split" a TCP
connection and behaviour such as proactive ACKing may occur. As connection and behaviour such as proactive ACKing may occur, and
with NATs, it is no longer guaranteed that one host is therefore it is no longer guaranteed that one host is
communicating directly with another. communicating directly with another. PEPs, firewalls or other
middleboxes may also change the declared receive window size.
o Traffic Normalizers: These aim to eliminate ambiguities and o Traffic Normalizers: These aim to eliminate ambiguities and
potential attacks at the network level, and amongst other things potential attacks at the network level, and amongst other things
are unlikely to permit holes in TCP-level sequence space. are unlikely to permit holes in TCP-level sequence space (which
has impact on MPTCP's retransmission and subflow sequence
numbering design choices).
o Firewalls: on top of preventing incoming connections, firewalls o Firewalls: on top of preventing incoming connections, firewalls
may also attempt additional protection such as sequence number may also attempt additional protection such as sequence number
randomization. randomization (so a sender cannot reliably know what TCP sequence
number the receiver will see).
o Intrusion Detection Systems: IDSs may look for traffic patterns to o Intrusion Detection Systems: IDSs may look for traffic patterns to
protect a network, and may have false positives with MPTCP and protect a network, and may have false positives with MPTCP and
drop the connections during normal operation. For future MPTCP- drop the connections during normal operation. Future MPTCP-aware
aware middleboxes, they will require the ability to correlate the middleboxes will require the ability to correlate the various
various paths in use. paths in use.
o Content-aware Firewalls: Some middleboxes may actively change data
in packets, such as re-writing URIs in HTTP traffic.
In addition, all classes of middleboxes may affect TCP traffic in the In addition, all classes of middleboxes may affect TCP traffic in the
following ways: following ways:
o TCP Options: many middleboxes are in a position to drop packets o TCP Options: some middleboxes may drop packets with unknown TCP
with unknown TCP options, or strip those options from the packets. options, or strip those options from the packets.
o Segmentation/Colescing: middleboxes (or even something as close to o Segmentation and Colescing: middleboxes (or even something as
the end host as TCP Segmentation Offloading) may change the packet close to the end host as TCP Segmentation Offloading (TSO) on a
boundaries from those which the sender intended. It may do this Network Interface Card (NIC)) may change the packet boundaries
by splitting packets, or coalescing them together. This leads to from those which the sender intended. It may do this by splitting
two major impacts: we cannot guarantee where a packet boundary packets, or coalescing them together. This leads to two major
will be, and we cannot say for sure what a middlebox will do with impacts: we cannot guarantee where a packet boundary will be, and
TCP options in these cases (they may be repeated, dropped, or sent we cannot say for sure what a middlebox will do with TCP options
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 Sebastien The authors would like to acknowledge the contributions of Andrew
Barre, 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, and Philip Eardley. Beijnum, Philip Eardley, and Michael Scharf.
9. Acknowledgements 9. Acknowledgements
Alan Ford, Costin Raiciu and Mark Handley are supported by Trilogy Alan Ford, Costin Raiciu, Mark Handley, and Sebastien Barre are
(http://www.trilogy-project.org), a research project (ICT-216372) supported by Trilogy (http://www.trilogy-project.org), a research
partially funded by the European Community under its Seventh project (ICT-216372) partially funded by the European Community under
Framework Program. The views expressed here are those of the its Seventh Framework Program. The views expressed here are those of
author(s) only. The European Commission is not liable for any use the author(s) only. The European Commission is not liable for any
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 [9] lists threats that can exist with a A separate threat analysis [10] 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.2.4, 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 [4].
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.
skipping to change at page 23, line 14 skipping to change at page 24, line 36
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] Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for
Multipath Operation with Multiple Addresses", Multipath Operation with Multiple Addresses",
draft-ietf-mptcp-multiaddressed-01 (work in progress), draft-ietf-mptcp-multiaddressed-02 (work in progress),
July 2010. October 2010.
[5] Raiciu, C., Handley, M., and D. Wischik, "Coupled Multipath- [5] Stewart, R., "Stream Control Transmission Protocol", RFC 4960,
September 2007.
[6] Raiciu, C., Handley, M., and D. Wischik, "Coupled Multipath-
Aware Congestion Control", draft-ietf-mptcp-congestion-00 (work Aware Congestion Control", draft-ietf-mptcp-congestion-00 (work
in progress), July 2010. in progress), July 2010.
[6] Scharf, M. and A. Ford, "MPTCP Application Interface [7] Scharf, M. and A. Ford, "MPTCP Application Interface
Considerations", draft-scharf-mptcp-api-02 (work in progress), Considerations", draft-ietf-mptcp-api-00 (work in progress),
July 2010. November 2010.
[7] 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.
[8] Carpenter, B., "Internet Transparency", RFC 2775, [9] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000. February 2000.
[9] Bagnulo, M., "Threat Analysis for Multi-addressed/Multi-path [10] Bagnulo, M., "Threat Analysis for Multi-addressed/Multi-path
TCP", draft-ietf-mptcp-threat-02 (work in progress), TCP", draft-ietf-mptcp-threat-06 (work in progress),
March 2010. December 2010.
[10] Ford, B. and J. Iyengar, "Breaking Up the Transport Logjam", [11] Becke, M., Dreibholz, T., Iyengar, J., Natarajan, P., and M.
Tuexen, "Load Sharing for the Stream Control Transmission
Protocol (SCTP)", draft-tuexen-tsvwg-sctp-multipath-00 (work in
progress), July 2010.
[12] Ford, B. and J. Iyengar, "Breaking Up the Transport Logjam",
ACM HotNets, October 2008. ACM HotNets, October 2008.
[11] Srisuresh, P. and K. Egevang, "Traditional IP Network Address [13] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001. Translator (Traditional NAT)", RFC 3022, January 2001.
[12] Freed, N., "Behavior of and Requirements for Internet [14] 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. [15] 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] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", [16] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm",
RFC 2992, November 2000. RFC 2992, November 2000.
[15] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's [17] 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.
[16] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", [18] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations",
RFC 4987, August 2007. RFC 4987, August 2007.
[17] Handley, M., Paxson, V., and C. Kreibich, "Network Intrusion [19] 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-01 A.1. Changes since draft-ietf-mptcp-architecture-02
o Responded to WG last call review comments. Included editorial
fixes, adding Section 2.4, and improving Section 5.4 and
Section 7.
A.2. 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.2. Changes since draft-ietf-mptcp-architecture-00 A.3. 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 (editor)
skipping to change at page 25, line 4 skipping to change at page 26, line 40
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
Gower Street Gower Street
London WC1E 6BT London WC1E 6BT
UK UK
Email: m.handley@cs.ucl.ac.uk Email: m.handley@cs.ucl.ac.uk
Sebastien Barre
Universite catholique de Louvain
Pl. Ste Barbe, 2
Louvain-la-Neuve 1348
Belgium
Phone: +32 10 47 91 03
Email: sebastien.barre@uclouvain.be
Janardhan Iyengar Janardhan Iyengar
Franklin and Marshall College Franklin and Marshall College
Mathematics and Computer Science Mathematics and Computer Science
PO Box 3003 PO Box 3003
Lancaster, PA 17604-3003 Lancaster, PA 17604-3003
USA USA
Phone: 717-358-4774 Phone: 717-358-4774
Email: jiyengar@fandm.edu Email: jiyengar@fandm.edu
 End of changes. 94 change blocks. 
246 lines changed or deleted 360 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/