draft-ietf-mptcp-multiaddressed-04.txt   draft-ietf-mptcp-multiaddressed-05.txt 
Internet Engineering Task Force A. Ford Internet Engineering Task Force A. Ford
Internet-Draft Roke Manor Research Internet-Draft
Intended status: Experimental C. Raiciu Intended status: Experimental C. Raiciu
Expires: January 12, 2012 M. Handley Expires: July 15, 2012 University Politehnica of
Bucharest
M. Handley
University College London University College London
O. Bonaventure O. Bonaventure
Universite catholique de Universite catholique de
Louvain Louvain
July 11, 2011 January 12, 2012
TCP Extensions for Multipath Operation with Multiple Addresses TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-multiaddressed-04 draft-ietf-mptcp-multiaddressed-05
Abstract Abstract
TCP/IP communication is currently restricted to a single path per TCP/IP communication is currently restricted to a single path per
connection, yet multiple paths often exist between peers. The connection, yet multiple paths often exist between peers. The
simultaneous use of these multiple paths for a TCP/IP session would simultaneous use of these multiple paths for a TCP/IP session would
improve resource usage within the network, and thus improve user improve resource usage within the network, and thus improve user
experience through higher throughput and improved resilience to experience through higher throughput and improved resilience to
network failure. network failure.
skipping to change at page 1, line 47 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 January 12, 2012. This Internet-Draft will expire on July 15, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 37 skipping to change at page 2, line 40
2.2. Associating a new subflow with an existing MPTCP 2.2. Associating a new subflow with an existing MPTCP
connection . . . . . . . . . . . . . . . . . . . . . . . . 9 connection . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Informing the other Host about another potential 2.3. Informing the other Host about another potential
address . . . . . . . . . . . . . . . . . . . . . . . . . 9 address . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Data transfer using MPTCP . . . . . . . . . . . . . . . . 10 2.4. Data transfer using MPTCP . . . . . . . . . . . . . . . . 10
2.5. Requesting a change in a path's priority . . . . . . . . . 11 2.5. Requesting a change in a path's priority . . . . . . . . . 11
2.6. Closing an MPTCP connection . . . . . . . . . . . . . . . 11 2.6. Closing an MPTCP connection . . . . . . . . . . . . . . . 11
2.7. Notable features . . . . . . . . . . . . . . . . . . . . . 11 2.7. Notable features . . . . . . . . . . . . . . . . . . . . . 11
3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 12 3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 13 3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 13
3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . . 16 3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . . 17
3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 21 3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 21
3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 22 3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 23
3.3.2. Data Acknowledgements . . . . . . . . . . . . . . . . 25 3.3.2. Data Acknowledgements . . . . . . . . . . . . . . . . 26
3.3.3. Closing a Connection . . . . . . . . . . . . . . . . . 27 3.3.3. Closing a Connection . . . . . . . . . . . . . . . . . 27
3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 28 3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 28
3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 29 3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 29
3.3.6. Reliability and Retransmissions . . . . . . . . . . . 30 3.3.6. Reliability and Retransmissions . . . . . . . . . . . 30
3.3.7. Congestion Control Considerations . . . . . . . . . . 31 3.3.7. Congestion Control Considerations . . . . . . . . . . 31
3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . . 31 3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . . 32
3.4. Address Knowledge Exchange (Path Management) . . . . . . . 33 3.4. Address Knowledge Exchange (Path Management) . . . . . . . 33
3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 34 3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 34
3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . . 36 3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . . 37
3.5. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.5. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6. Error Handling . . . . . . . . . . . . . . . . . . . . . . 40 3.6. Error Handling . . . . . . . . . . . . . . . . . . . . . . 41
3.7. Heuristics . . . . . . . . . . . . . . . . . . . . . . . . 41 3.7. Heuristics . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7.1. Port Usage . . . . . . . . . . . . . . . . . . . . . . 41 3.7.1. Port Usage . . . . . . . . . . . . . . . . . . . . . . 41
3.7.2. Delayed Subflow Start . . . . . . . . . . . . . . . . 41 3.7.2. Delayed Subflow Start . . . . . . . . . . . . . . . . 42
3.7.3. Failure Handling . . . . . . . . . . . . . . . . . . . 42 3.7.3. Failure Handling . . . . . . . . . . . . . . . . . . . 42
4. Semantic Issues . . . . . . . . . . . . . . . . . . . . . . . 43 4. Semantic Issues . . . . . . . . . . . . . . . . . . . . . . . 43
5. Security Considerations . . . . . . . . . . . . . . . . . . . 44 5. Security Considerations . . . . . . . . . . . . . . . . . . . 45
6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 45 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 45
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.1. Normative References . . . . . . . . . . . . . . . . . . . 50 9.1. Normative References . . . . . . . . . . . . . . . . . . . 50
9.2. Informative References . . . . . . . . . . . . . . . . . . 50 9.2. Informative References . . . . . . . . . . . . . . . . . . 50
Appendix A. Notes on use of TCP Options . . . . . . . . . . . . . 51 Appendix A. Notes on use of TCP Options . . . . . . . . . . . . . 52
Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 53 Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 53
B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 53 B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 54
B.1.1. Authentication and Metadata . . . . . . . . . . . . . 53 B.1.1. Authentication and Metadata . . . . . . . . . . . . . 54
B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . . 54 B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . . 54
B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . . 54 B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . . 55
B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . . 54 B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . . 55
B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . . 55 B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . . 55
B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . . 55 B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . . 55
Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 55 Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 56
Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . . 56 Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . . 56
D.1. Changes since draft-ietf-mptcp-multiaddressed-03 . . . . . 56 D.1. Changes since draft-ietf-mptcp-multiaddressed-04 . . . . . 56
D.2. Changes since draft-ietf-mptcp-multiaddressed-02 . . . . . 56 D.2. Changes since draft-ietf-mptcp-multiaddressed-03 . . . . . 57
D.3. Changes since draft-ietf-mptcp-multiaddressed-01 . . . . . 57 D.3. Changes since draft-ietf-mptcp-multiaddressed-02 . . . . . 57
D.4. Changes since draft-ietf-mptcp-multiaddressed-00 . . . . . 57 D.4. Changes since draft-ietf-mptcp-multiaddressed-01 . . . . . 57
D.5. Changes since draft-ford-mptcp-multiaddressed-03 . . . . . 57 D.5. Changes since draft-ietf-mptcp-multiaddressed-00 . . . . . 57
D.6. Changes since draft-ford-mptcp-multiaddressed-02 . . . . . 58 D.6. Changes since draft-ford-mptcp-multiaddressed-03 . . . . . 57
D.7. Changes since draft-ford-mptcp-multiaddressed-02 . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
MPTCP is a set of extensions to regular TCP [2] to provide a MPTCP is a set of extensions to regular TCP [2] to provide a
Multipath TCP [3] service, which enables a transport connection to Multipath TCP [3] service, which enables a transport connection to
operate across multiple paths simultaneously. This document presents operate across multiple paths simultaneously. This document presents
the protocol changes required to add multipath capability to TCP; the protocol changes required to add multipath capability to TCP;
specifically, those for signalling and setting up multiple paths specifically, those for signaling and setting up multiple paths
("subflows"), managing these subflows, reassembly of data, and ("subflows"), managing these subflows, reassembly of data, and
termination of sessions. This is not the only information required termination of sessions. This is not the only information required
to create a Multipath TCP implementation, however. This document is to create a Multipath TCP implementation, however. This document is
complemented by three others: complemented by three others:
o Architecture [3], which explains the motivations behind Multipath o Architecture [3], which explains the motivations behind Multipath
TCP, contains a discussion of high-level design decisions on which TCP, contains a discussion of high-level design decisions on which
this design is based, and an explanation of a functional this design is based, and an explanation of a functional
separation through which an extensible MPTCP implementation can be separation through which an extensible MPTCP implementation can be
developed. developed.
skipping to change at page 7, line 15 skipping to change at page 7, line 15
o MPTCP identifies multiple paths by the presence of multiple o MPTCP identifies multiple paths by the presence of multiple
addresses at hosts. Combinations of these multiple addresses addresses at hosts. Combinations of these multiple addresses
equate to the additional paths. In the example, other potential equate to the additional paths. In the example, other potential
paths that could be set up are A1<->B2 and A2<->B2. Although this paths that could be set up are A1<->B2 and A2<->B2. Although this
additional session is shown as being initiated from A2, it could additional session is shown as being initiated from A2, it could
equally have been initiated from B1. equally have been initiated from B1.
o The discovery and setup of additional subflows will be achieved o The discovery and setup of additional subflows will be achieved
through a path management method; this document describes a through a path management method; this document describes a
mechanism by which a host can initiate new subflows by using its mechanism by which a host can initiate new subflows by using its
own additional addresses, or by signalling its available addresses own additional addresses, or by signaling its available addresses
to the other host. to the other host.
o MPTCP adds connection-level sequence numbers to allow the o MPTCP adds connection-level sequence numbers to allow the
reassembly of the in-order data stream from multiple subflows reassembly of segments arriving on multiple subflows with
which may deliver packets out-of-order due to differing network differing network delays.
delays.
o Subflows are terminated as regular TCP connections, with a four o Subflows are terminated as regular TCP connections, with a four
way FIN handshake. The MPTCP connection is terminated by a way FIN handshake. The MPTCP connection is terminated by a
connection-level FIN. connection-level FIN.
Host A Host B Host A Host B
------------------------ ------------------------ ------------------------ ------------------------
Address A1 Address A2 Address B1 Address B2 Address A1 Address A2 Address B1 Address B2
---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
| | | | | | | |
skipping to change at page 8, line 20 skipping to change at page 8, line 20
section - these are subtypes of the IANA-assigned MPTCP option (see section - these are subtypes of the IANA-assigned MPTCP option (see
Section 8), and their formats are defined in the detailed protocol Section 8), and their formats are defined in the detailed protocol
specification which follows in Section 3. specification which follows in Section 3.
A Multipath TCP connection provides a bidirectionnal bytestream A Multipath TCP connection provides a bidirectionnal bytestream
between two hosts communicating hosts like normal TCP and thus does between two hosts communicating hosts like normal TCP and thus does
not require any change to the applications. However, Multipath TCP not require any change to the applications. However, Multipath TCP
enables the hosts to use different paths with different IP addresses enables the hosts to use different paths with different IP addresses
to exchange packets belonging to the MPTCP connection. A Multipath to exchange packets belonging to the MPTCP connection. A Multipath
TCP connection appears like a normal TCP connection to an TCP connection appears like a normal TCP connection to an
application. However, to the network layer it appears as a set of application. However, to the network layer each MPTCP subflows looks
coordinated TCP subflows. These TCP subflows are coordinated by like a regular TCP flow whose segments carry a new TCP option type.
Multipath TCP. Multipath TCP manages the creation, removal and Multipath TCP manages the creation, removal and utilization of these
utilization of these subflows to send data. The number of subflows to send data. The number of subflows that are managed
coordinated TCP subflows that are managed within a Multipath TCP within a Multipath TCP connection is not fixed and it can fluctuate
connection is not fixed and it can fluctuate during the lifetime of during the lifetime of the Multipath TCP connection.
the Multipath TCP connection.
All MPTCP operations are signaled with a TCP option - a single All MPTCP operations are signaled with a TCP option - a single
numerical type for MPTCP, with "sub-types" for each MPTCP message. numerical type for MPTCP, with "sub-types" for each MPTCP message.
What follows is a summary of the purpose and rationale of these What follows is a summary of the purpose and rationale of these
messages. messages.
2.1. Initiating an MPTCP connection 2.1. Initiating an MPTCP connection
This is the same signalling as for initiating a normal TCP This is the same signaling as for initiating a normal TCP connection,
connection, but the SYN, SYN/ACK and ACK packets also carry the but the SYN, SYN/ACK and ACK packets also carry the MP_CAPABLE
MP_CAPABLE option. This is variable-length and serves multiple option. This is variable-length and serves multiple purposes.
purposes. Firstly, it verifies whether the remote host supports Firstly, it verifies whether the remote host supports Multipath TCP;
Multipath TCP; and secondly, the second and third instances of this and secondly, this option allows the hosts to exchange some
option allow the hosts to exchange some information that is used to information that is used to authenticate the establishment of
authenticating the establishment of additional subflows. Further additional subflows. Further details are given in Section 3.1.
details are given in Section 3.1.
Host-A Host-B Host-A Host-B
------ ------ ------ ------
MP_CAPABLE -> MP_CAPABLE ->
[A's key, flags]
<- MP_CAPABLE <- MP_CAPABLE
[B's key, flags] [B's key, flags]
ACK MP_CAPABLE -> ACK MP_CAPABLE ->
[A's key, flags] [A's key, B's key, flags]
2.2. Associating a new subflow with an existing MPTCP connection 2.2. Associating a new subflow with an existing MPTCP connection
The exchange of keys in the MP_CAPABLE handshake provides material The exchange of keys in the MP_CAPABLE handshake provides material
that can be used to authenticate the endpoints in a handshake setting that can be used to authenticate the endpoints when new subflows will
up a new subflow. Additional subflows begin in the same way as be setup. Additional subflows begin in the same way as initiating a
initiating a normal TCP connection, but the SYN, SYN/ACK and ACK normal TCP connection, but the SYN, SYN/ACK and ACK packets also
packets also carry the MP_JOIN option. carry the MP_JOIN option.
Host-A initiates a new subflow between one of its addresses and one Host-A initiates a new subflow between one of its addresses and one
of Host-B's addresses. The token - generated from the key - is used of Host-B's addresses. The token - generated from the key - is used
to identify which MPTCP connection it is joining, and the MAC is used to identify which MPTCP connection it is joining, and the MAC is used
for authentication. MP_JOIN also contains flags and an Address ID for authentication. MP_JOIN also contains flags and an Address ID
that can be used to refer to the source address without the sender that can be used to refer to the source address without the sender
needing to know if it has been changed by a NAT. Further details in needing to know if it has been changed by a NAT. Further details in
Section 3.2. Section 3.2.
Host-A Host-B Host-A Host-B
skipping to change at page 11, line 21 skipping to change at page 11, line 21
through the MP_PRIO signal to Host-B. Further details in through the MP_PRIO signal to Host-B. Further details in
Section 3.3.8. Section 3.3.8.
Host-A Host-B Host-A Host-B
------ ------ ------ ------
MP_PRIO -> MP_PRIO ->
2.6. Closing an MPTCP connection 2.6. Closing an MPTCP connection
When Host-A wants to inform Host-B that it has no more data to send, When Host-A wants to inform Host-B that it has no more data to send,
it signals this "Data FIN" as partof the Data Sequence Signal (see it signals this "Data FIN" as part of the Data Sequence Signal (see
above). It has the same semantics and behaviour as a regular TCP above). It has the same semantics and behaviour as a regular TCP
FIN, but at the connection level. Once all the data on the MPTCP FIN, but at the connection level. Once all the data on the MPTCP
connection has been successfully received, then this message is connection has been successfully received, then this message is
acknowledged at the connection level with a DATA ACK. Further acknowledged at the connection level with a DATA ACK. Further
details in Section 3.3.3. details in Section 3.3.3.
Host-A Host-B Host-A Host-B
------ ------ ------ ------
DATA_SEQUENCE_SIGNAL -> DATA_SEQUENCE_SIGNAL ->
[Data FIN] [Data FIN]
<- (MPTCP DATA ACK) <- (MPTCP DATA ACK)
2.7. Notable features 2.7. Notable features
MPTCP's signalling has been designed with several key requirements in It is worth highlighting that MPTCP's signaling has been designed
mind that are worth highlighting: with several key requirements in mind:
o To cope with NATs on the path, addresses are referred to by o To cope with NATs on the path, addresses are referred to by
Address IDs, in case the IP packetAs source address gets changed Address IDs, in case the IP packet's source address gets changed
by a NAT.An MP_JOIN may be blocked by a NAT in one direction but by a NAT. Setting up a new TCP flow is not possible if the
not the other; hence the MP-ADD-ADDR message improves the chances passive opener is behind a NAT; to allow subflows to be created
of being able to establish multiple paths. Data ACKs explicitly when either end is behind a NAT, MPTCP uses the MP-ADD-ADDR
acknowledge data at the MPTCP connection level. At the subflow message.
level, the sequence numbers (for data exchange) are identical to
TCPAs. A special Data Sequence Mapping indicates to fallback to
regular TCP for the remainder of the connection. All MPTCP's
signalling is done using TCP options.
o To fall back to ordinary TCP if MPTCP is not possible. For o MPTCP falls back to ordinary TCP if MPTCP operation is not
example if one host is not MPTCP capable, or if a middlebox does possible. For example if one host is not MPTCP capable, or if a
something strange to a MPTCP message (perhaps it alters the middlebox alters the payload.
content).
o To meet the threats identified [6], the following steps are taken: o To meet the threats identified in [6], the following steps are
keys are sent in the clear in the MP_CAPABLE messages; MP_JOIN taken: keys are sent in the clear in the MP_CAPABLE messages;
messages are secured with HMAC-SHA1 using those keys; and standard MP_JOIN messages are secured with HMAC-SHA1 using those keys; and
TCP validity checks are made on the other messages (ie ensuring standard TCP validity checks are made on the other messages (
sequence numbers are correct). ensuring sequence numbers are in-window).
3. MPTCP Protocol 3. MPTCP Protocol
This section describes the operation of the MPTCP protocol, and is This section describes the operation of the MPTCP protocol, and is
subdivided into sections for each key part of the protocol operation. subdivided into sections for each key part of the protocol operation.
All MPTCP operations are signalled using optional TCP header fields. All MPTCP operations are signalled using optional TCP header fields.
A single TCP option number ("Kind") will be assigned by IANA for A single TCP option number ("Kind") will be assigned by IANA for
MPTCP (see Section 8), and then individual messages will be MPTCP (see Section 8), and then individual messages will be
determined by a "sub-type", the values of which will also be stored determined by a "sub-type", the values of which will also be stored
skipping to change at page 12, line 44 skipping to change at page 12, line 39
| Kind | Length |Subtype| | | Kind | Length |Subtype| |
+---------------+---------------+-------+ | +---------------+---------------+-------+ |
| Subtype-specific data | | Subtype-specific data |
| (variable length) | | (variable length) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 3: MPTCP option format Figure 3: MPTCP option format
Those MPTCP options associated with subflow initiation must be Those MPTCP options associated with subflow initiation must be
included on packets with the SYN flag set. Additionally, there is included on packets with the SYN flag set. Additionally, there is
one MPTCP option for signalling metadata to ensure segmented data can one MPTCP option for signaling metadata to ensure segmented data can
be recombined for delivery to the application. be recombined for delivery to the application.
The remaining options, however, are signals that do not need to be on The remaining options, however, are signals that do not need to be on
a specific packet, such as those for signalling additional addresses. a specific packet, such as those for signaling additional addresses.
Whilst an implementation may desire to send MPTCP options as soon as Whilst an implementation may desire to send MPTCP options as soon as
possible, it may not be possible to combine all desired options (both possible, it may not be possible to combine all desired options (both
those for MPTCP and for regular TCP, such as SACK [7]) on a single those for MPTCP and for regular TCP, such as SACK [7]) on a single
packet. Therefore, an implementation may choose to send duplicate packet. Therefore, an implementation may choose to send duplicate
ACKs containing the additional signalling information. This changes ACKs containing the additional signaling information. This changes
the semantics of a duplicate ACK, these are usually only sent as a the semantics of a duplicate ACK, these are usually only sent as a
signal of a lost segment [8] in regular TCP. Therefore, an MPTCP signal of a lost segment [8] in regular TCP. Therefore, an MPTCP
implementation receiving a duplicate ACK which contains an MPTCP implementation receiving a duplicate ACK which contains an MPTCP
option MUST NOT treat it as a signal of congestion. Additionally, an option MUST NOT treat it as a signal of congestion. Additionally, an
MPTCP implementation SHOULD NOT send more than two duplicate ACKs in MPTCP implementation SHOULD NOT send more than two duplicate ACKs in
a row for signalling purposes, so as to ensure no middleboxes a row for signaling purposes, so as to ensure no middleboxes
misinterpret this as a sign of congestion. misinterpret this as a sign of congestion.
Furthermore, standard TCP validity checks (such as ensuring the Furthermore, standard TCP validity checks (such as ensuring the
Sequence Number and Acknowledgement Number are within window) MUST be Sequence Number and Acknowledgement Number are within window) MUST be
undertaken before processing any MPTCP signals, as described in [9]. undertaken before processing any MPTCP signals, as described in [9].
3.1. Connection Initiation 3.1. Connection Initiation
Connection Initiation begins with a SYN, SYN/ACK, ACK exchange on a Connection Initiation begins with a SYN, SYN/ACK, ACK exchange on a
single path. Each packet contains the Multipath Capable (MP_CAPABLE) single path. Each packet contains the Multipath Capable (MP_CAPABLE)
skipping to change at page 14, line 12 skipping to change at page 14, line 7
(Section 3.2) will ensure that new subflows only join the correct (Section 3.2) will ensure that new subflows only join the correct
connection, however, so in the worst case if there was a token connection, however, so in the worst case if there was a token
collision, the second connection cannot support multiple subflows, collision, the second connection cannot support multiple subflows,
but will otherwise provide a regular TCP service. but will otherwise provide a regular TCP service.
The MP_CAPABLE option is carried on the SYN, SYN/ACK, and ACK packets The MP_CAPABLE option is carried on the SYN, SYN/ACK, and ACK packets
that start the first subflow of an MPTCP connection. The data that start the first subflow of an MPTCP connection. The data
carried by each packet is as follows, where A = initiator and B = carried by each packet is as follows, where A = initiator and B =
listener. listener.
o SYN (A->B): no key, just capability signalling. o SYN (A->B): A's Key.
o SYN/ACK (B->A): B's Key. o SYN/ACK (B->A): B's Key.
o ACK (A->B): A's Key followed by B's Key. o ACK (A->B): A's Key followed by B's Key.
The contents of the option is determined by the SYN and ACK flags of The contents of the option is determined by the SYN and ACK flags of
the packet, verified by the option's length field. For the diagram the packet, verified by the option's length field. For the diagram
shown in Figure 4, "sender" and "receiver" refer to the sender or shown in Figure 4, "sender" and "receiver" refer to the sender or
receiver of the TCP packet (which can be either host). receiver of the TCP packet (which can be either host). If the SYN
flag is set, a single key is included; if only an ACK flag is set,
both keys are present.
B's Key is echoed in the ACK in order to allow the listener (host B) B's Key is echoed in the ACK in order to allow the listener (host B)
to act statelessly until the TCP connection reaches the ESTABLISHED to act statelessly until the TCP connection reaches the ESTABLISHED
state. If the listener acts in this way, however, it MUST generate state. If the listener acts in this way, however, it MUST generate
its key in a verifiable fashion, allowing it to verify that it its key in a verifiable fashion, allowing it to verify that it
generated the key when it is echoed in the ACK. generated the key when it is echoed in the ACK.
Furthermore, in order to ensure reliable delivery of the ACK As TCP when using SYN cookies, the MPTCP handshake would be
containing the MP_CAPABLE option, a server MUST respond with an ACK vulnerable if the third ACK (containing the MP_CAPABLE option) is
segment on receipt of this, which may contain data, or will be a pure lost. In order to ensure reliable delivery of the third ACK, a
ACK if it does not have any data to send immediately. If the server MUST respond with an ACK segment on receipt of this, which may
initiator does not receive this ACK within the RTO, it MUST re-send contain data, or will be a pure ACK if it does not have any data to
the ACK containing MP_CAPABLE. In effect, an MPTCP connection is in send immediately. If the initiator does not receive this ACK within
a "PRE_ESTABLISHED" state while awaiting this ACK, and only upon an RTO, it MUST re-send the ACK containing MP_CAPABLE.
receipt of the ACK will it move to the ESTABLISHED state.
In effect, an MPTCP connection is in a "PRE_ESTABLISHED" state while
awaiting this ACK, and only upon receipt of the ACK will it move to
the ESTABLISHED state. When in the PRE_ESTABLISHED state, a host can
send data, but MUST NOT attempt to create additional subflows. Only
in the ESTABLISHED state does it know that MPTCP options are
correctly passed in both directions on the path. If MPTCP options
fail to be passed, an implementation SHOULD undertake fallback as
documented in Section 3.5.
The first four bits of the first octet in the MP_CAPABLE option The first four bits of the first octet in the MP_CAPABLE option
(Figure 4) define the MPTCP option subtype (see Section 8; for (Figure 4) define the MPTCP option subtype (see Section 8; for
MP_CAPABLE, this is 0), and the remaining four bits of this octet MP_CAPABLE, this is 0), and the remaining four bits of this octet
specifies the MPTCP version in use (for this specification, this is specifies the MPTCP version in use (for this specification, this is
0). 0).
The second octet is reserved for flags. The leftmost bit - labeled C The second octet is reserved for flags. The leftmost bit - labeled C
- indicates "Checksum required", and SHOULD be set to 1 unless - indicates "Checksum required", and SHOULD be set to 1 unless
specifically overridden (for example, if the system administrator has specifically overridden (for example, if the system administrator has
skipping to change at page 15, line 12 skipping to change at page 15, line 17
assigned, and indicates the use of HMAC-SHA1 (as defined in assigned, and indicates the use of HMAC-SHA1 (as defined in
Section 3.2). An implementation that only supports this method MUST Section 3.2). An implementation that only supports this method MUST
set this bit to 1 and all other currently reserved bits to zero. If set this bit to 1 and all other currently reserved bits to zero. If
none of these flags are set, the MP_CAPABLE option MUST be treated as none of these flags are set, the MP_CAPABLE option MUST be treated as
invalid and ignored (i.e. it must be treated as a regular TCP invalid and ignored (i.e. it must be treated as a regular TCP
handshake). handshake).
These bits negotiate capabilities in similar ways. For the 'C' bit, These bits negotiate capabilities in similar ways. For the 'C' bit,
if either host requires the use of checksums, checksums MUST be used. if either host requires the use of checksums, checksums MUST be used.
In other words, the only way for checksums not to be used is if both In other words, the only way for checksums not to be used is if both
hosts in their SYNs set C=0. The decision whether to use checksums hosts in their SYNs set C=0. This decision is confirmed by the
will be stored by an implementation in a per-connection binary state setting of the 'C' bit in the third packet (the ACK) of the
variable. handshake. For example, if the initiator sets C=0 in the SYN, but
the responder sets C=1 in the SYN/ACK, checksums must be used and the
initiator will set C=1 in the ACK. The decision whether to use
checksums will be stored by an implementation in a per-connection
binary state variable.
For crypto negotiation, the responder has the choice. The initiator For crypto negotiation, the responder has the choice. The initiator
creates a proposal setting a bit for each algorithm it supports to 1 creates a proposal setting a bit for each algorithm it supports to 1
(in this version of the specification, there is only one proposal, so (in this version of the specification, there is only one proposal, so
S will be always set to 1). The responder responds with only one bit S will be always set to 1). The responder responds with only one bit
set - this is the chosen algorithm. The rationale for this behaviour set - this is the chosen algorithm. The rationale for this behaviour
is that the responder will typically be a server with potentially is that the responder will typically be a server with potentially
many thousands of connections, so it may wish to choose an algorithm many thousands of connections, so it may wish to choose an algorithm
with minimal computational complexity, depending on the load. If a with minimal computational complexity, depending on the load. If a
responder does not support (or does not want to support) any of the responder does not support (or does not want to support) any of the
skipping to change at page 15, line 39 skipping to change at page 16, line 11
connection, in order to identify the connection; all following connection, in order to identify the connection; all following
subflows will use the "Join" option (see Section 3.2) to join the subflows will use the "Join" option (see Section 3.2) to join the
existing connection. existing connection.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-------+-+-----------+-+ +---------------+---------------+-------+-------+-+-----------+-+
| Kind | Length |Subtype|Version|C| (reservd) |S| | Kind | Length |Subtype|Version|C| (reservd) |S|
+---------------+---------------+-------+-------+-+-----------+-+ +---------------+---------------+-------+-------+-+-----------+-+
| Option Sender's Key (64 bits) | | Option Sender's Key (64 bits) |
| (if option Length == 12 or 20) | | |
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Option Receiver's Key (64 bits) | | Option Receiver's Key (64 bits) |
| (if option Length == 20) | | (if option Length == 20) |
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 4: Multipath Capable (MP_CAPABLE) option Figure 4: Multipath Capable (MP_CAPABLE) option
If a SYN contains an MP_CAPABLE option but the SYN/ACK does not, it If a SYN contains an MP_CAPABLE option but the SYN/ACK does not, it
skipping to change at page 16, line 37 skipping to change at page 17, line 10
significant 64 bits of the SHA-1 hash of the key. The SYN with significant 64 bits of the SHA-1 hash of the key. The SYN with
MP_CAPABLE occupies the first octet of Data Sequence Space, although MP_CAPABLE occupies the first octet of Data Sequence Space, although
this does not need to be acknowledged at the connection level until this does not need to be acknowledged at the connection level until
the first data is sent (see Section 3.3). the first data is sent (see Section 3.3).
3.2. Starting a New Subflow 3.2. Starting a New Subflow
Once an MPTCP connection has begun with the MP_CAPABLE exchange, Once an MPTCP connection has begun with the MP_CAPABLE exchange,
further subflows can be added to the connection. Hosts have further subflows can be added to the connection. Hosts have
knowledge of their own address(es), and can become aware of the other knowledge of their own address(es), and can become aware of the other
host's addresses through signalling exchanges as described in host's addresses through signaling exchanges as described in
Section 3.4. Using this knowledge, a host can initiate a new subflow Section 3.4. Using this knowledge, a host can initiate a new subflow
over a currently unused pair of addresses. It is permitted for over a currently unused pair of addresses. It is permitted for
either host in a connection to initiate the creation of a new either host in a connection to initiate the creation of a new
subflow, but it is expected that this will normally be the original subflow, but it is expected that this will normally be the original
connection initiator (see Section 3.7 for heuristics). connection initiator (see Section 3.7 for heuristics).
A new subflow is started as a normal TCP SYN/ACK exchange. The Join A new subflow is started as a normal TCP SYN/ACK exchange. The Join
Connection (MP_JOIN) TCP option is used to identify the connection to Connection (MP_JOIN) TCP option is used to identify the connection to
be joined by the new subflow. It uses keying material that was be joined by the new subflow. It uses keying material that was
exchanged in the initial MP_CAPABLE handshake (Section 3.1), and that exchanged in the initial MP_CAPABLE handshake (Section 3.1), and that
skipping to change at page 17, line 32 skipping to change at page 18, line 4
replay attacks on the authentication method. replay attacks on the authentication method.
The MP_JOIN option includes an "Address ID". This is an identifier The MP_JOIN option includes an "Address ID". This is an identifier
that only has significance within a single connection, where it that only has significance within a single connection, where it
identifies the source address of this packet, even if the address identifies the source address of this packet, even if the address
itself has been changed in transit by a middlebox. This allows itself has been changed in transit by a middlebox. This allows
address removal without needing to know what the source address at address removal without needing to know what the source address at
the receiver is, thus this allows address removal through NATs. The the receiver is, thus this allows address removal through NATs. The
sender can signal this to the receiver via the REMOVE_ADDR option sender can signal this to the receiver via the REMOVE_ADDR option
(Section 3.4.2). It also allows correlation between new subflow (Section 3.4.2). It also allows correlation between new subflow
setup attempts and address signalling (Section 3.4.1), to prevent setup attempts and address signaling (Section 3.4.1), to prevent
setting up duplicate subflows on the same path. setting up duplicate subflows on the same path.
The Address IDs of the subflow used in the initial SYN exchange of The Address IDs of the subflow used in the initial SYN exchange of
the first subflow in the connection are implicit, and have the value the first subflow in the connection are implicit, and have the value
zero. A host MUST store the Address IDs associated with all zero. A host MUST store the Address IDs associated with all
established subflows. established subflows.
The MP_JOIN option on SYNs also includes 4 bits of flags, 3 of which The MP_JOIN option on SYNs also includes 4 bits of flags, 3 of which
are currently reserved and MUST be set to zero by the sender. The are currently reserved and MUST be set to zero by the sender. The
final bit, labelled 'B', indicates whether the sender of this option final bit, labelled 'B', indicates whether the sender of this option
skipping to change at page 21, line 47 skipping to change at page 22, line 16
following subsections define this behaviour in detail. following subsections define this behaviour in detail.
During normal MPTCP operation, the Data Sequence Signal (DSS) TCP During normal MPTCP operation, the Data Sequence Signal (DSS) TCP
option (shown in Figure 9) is used to signal the data required to option (shown in Figure 9) is used to signal the data required to
enable multipath transport. This data comprises: the Data Sequence enable multipath transport. This data comprises: the Data Sequence
Mapping, which defines how the sequence space on the subflow maps to Mapping, which defines how the sequence space on the subflow maps to
the connection level; and the Data ACK, for acknowledging receipt of the connection level; and the Data ACK, for acknowledging receipt of
data at the connection level. These functions are described in more data at the connection level. These functions are described in more
detail in the following two subsections. detail in the following two subsections.
Either or both of the Data Sequence Mapping or the Data ACK can be Either or both the Data Sequence Mapping and the Data ACK can be
signalled in the DSS option, dependent on the flags set. signalled in the DSS option, dependent on the flags set.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+----------------------+ +---------------+---------------+-------+----------------------+
| Kind | Length |Subtype| (reserved) |F|m|M|a|A| | Kind | Length |Subtype| (reserved) |F|m|M|a|A|
+---------------+---------------+-------+----------------------+ +---------------+---------------+-------+----------------------+
| Data ACK (4 or 8 octets, depending on flags) | | Data ACK (4 or 8 octets, depending on flags) |
+--------------------------------------------------------------+ +--------------------------------------------------------------+
| Data Sequence Number (4 or 8 octets, depending on flags) | | Data Sequence Number (4 or 8 octets, depending on flags) |
skipping to change at page 23, line 16 skipping to change at page 23, line 31
delivery to the application layer. Meanwhile, the subflow-level delivery to the application layer. Meanwhile, the subflow-level
sequence numbers (i.e. the regular sequence numbers in the TCP sequence numbers (i.e. the regular sequence numbers in the TCP
header) have subflow-only relevance. It is expected (but not header) have subflow-only relevance. It is expected (but not
mandated) that SACK [7] is used at the subflow level to improve mandated) that SACK [7] is used at the subflow level to improve
efficiency. efficiency.
The Data Sequence Mapping specifies a mapping from subflow sequence The Data Sequence Mapping specifies a mapping from subflow sequence
space to data sequence space. This is expressed in terms of starting space to data sequence space. This is expressed in terms of starting
sequence numbers for the subflow and the data level, and a length of sequence numbers for the subflow and the data level, and a length of
bytes for which this mapping is valid. This explicit mapping for a bytes for which this mapping is valid. This explicit mapping for a
range of data was chosen rather than per-packet signalling to assist range of data was chosen rather than per-packet signaling to assist
with compatibility with situations where TCP/IP segmentation or with compatibility with situations where TCP/IP segmentation or
coalescing is undertaken separately from the stack that is generating coalescing is undertaken separately from the stack that is generating
the data flow (e.g. through the use of TCP segmentation offloading on the data flow (e.g. through the use of TCP segmentation offloading on
network interface cards, or by middleboxes such as performance network interface cards, or by middleboxes such as performance
enhancing proxies). It also allows a single mapping to cover many enhancing proxies). It also allows a single mapping to cover many
packets, which may be useful in bulk transfer situations. packets, which may be useful in bulk transfer situations.
A mapping is fixed, in that the subflow sequence number is bound to A mapping is fixed, in that the subflow sequence number is bound to
the data sequence number after the mapping has been processed. A the data sequence number after the mapping has been processed. A
sender MUST NOT change this mapping after it has been declared; sender MUST NOT change this mapping after it has been declared;
skipping to change at page 26, line 15 skipping to change at page 26, line 30
standard TCP cumulative ACK in TCP SACK - indicating how much data standard TCP cumulative ACK in TCP SACK - indicating how much data
has been successfully received (with no holes). The Data ACK has been successfully received (with no holes). The Data ACK
specifies the next Data Sequence Number it expects to receive. specifies the next Data Sequence Number it expects to receive.
The Data ACK, as for the DSN, can be sent as the full 64 bit value, The Data ACK, as for the DSN, can be sent as the full 64 bit value,
or as the lower 32 bits. If data is received with a 64 bit DSN, it or as the lower 32 bits. If data is received with a 64 bit DSN, it
MUST be acknowledged with a 64 bit Data ACK. If the DSN received is MUST be acknowledged with a 64 bit Data ACK. If the DSN received is
32 bits, it is valid for the implementation to choose whether to send 32 bits, it is valid for the implementation to choose whether to send
a 32 bit or 64 bit Data ACK. a 32 bit or 64 bit Data ACK.
The rationale for the inclusion of the Data ACK includes the The Data ACK proves that the data, and all required MPTCP signaling,
existence of certain middleboxes that pro-actively ACK packets, and has been received and accepted by the remote end. One key use of the
thus might cause deadlock conditions if data were acked at the Data ACK signal is that it is used to indicate the left edge of the
subflow level but then fails to reach the receiver. This sort of bad advertised receive window. As explained in Section 3.3.4, the
interaction might be especially prevalent when the receiver is receive window is shared by all subflows and is relative to the Data
mobile. The Data ACK ensures the data has been delivered to the ACK. Because of this, an implementation MUST NOT use the RCV.WND
receiver. Furthermore, separating the connection-level field of a TCP segment at connection-level if it does not also carry
acknowledgements from the subflow-level allows processing to be done a DSS option with a Data ACK field. Furthermore, separating the
separately, and a receiver has the freedom to drop segments after connection-level acknowledgements from the subflow-level allows
acknowledgement at the subflow level, for example due to memory processing to be done separately, and a receiver has the freedom to
constraints when many segments arrive out-of-order. drop segments after acknowledgement at the subflow level, for example
due to memory constraints when many segments arrive out-of-order.
Another reason for including the Data ACK is that it indicates the
left edge of the advertised receive window. As explained in
Section 3.3.4, the receive window is shared by all subflows and is
relative to the Data ACK. Because of this, an implementation MUST
NOT use the RCV.WND field of a TCP segment at connection-level if it
does not also carry a DSS option with a Data ACK field.
An MPTCP sender MUST only free data from the send buffer when it has An MPTCP sender MUST only free data from the send buffer when it has
been acknowledged by both a Data ACK received on any subflow and at been acknowledged by both a Data ACK received on any subflow and at
the subflow level by any subflows the data was sent on. The former the subflow level by any subflows the data was sent on. The former
condition ensures liveness of the connection and the latter condition condition ensures liveness of the connection and the latter condition
ensures liveness and self-consistence of a subflow when data needs to ensures liveness and self-consistence of a subflow when data needs to
be restransmited. Note, however, that if some data needs to be be restransmited. Note, however, that if some data needs to be
retransmitted multiple times over a subflow, there is a risk of retransmitted multiple times over a subflow, there is a risk of
blocking the sending window. In this case, the MPTCP sender can blocking the sending window. In this case, the MPTCP sender can
decide to cancel the subflow that is behaving badly by sending a RST. decide to terminate the subflow that is behaving badly by sending a
RST.
The Data ACK MAY be included in all segments, however optimisations The Data ACK MAY be included in all segments, however optimisations
SHOULD be considered in more advanced implementations, where the Data SHOULD be considered in more advanced implementations, where the Data
ACK is present in segments only when the Data ACK value advances, and ACK is present in segments only when the Data ACK value advances, and
this behaviour MUST be treated as valid. This behaviour ensures the this behaviour MUST be treated as valid. This behaviour ensures the
sender buffer is freed, while reducing overhead when the data sender buffer is freed, while reducing overhead when the data
transfer is unidirectional. transfer is unidirectional.
3.3.3. Closing a Connection 3.3.3. Closing a Connection
skipping to change at page 33, line 39 skipping to change at page 33, line 49
This design makes use of two methods of sharing such information, This design makes use of two methods of sharing such information,
used simultaneously. The first is the direct setup of new subflows, used simultaneously. The first is the direct setup of new subflows,
already described in Section 3.2, where the initiator has an already described in Section 3.2, where the initiator has an
additional address. The second method, described in the following additional address. The second method, described in the following
subsections, signals addresses explicitly to the other host to allow subsections, signals addresses explicitly to the other host to allow
it to initiate new subflows. The two mechanisms are complementary: it to initiate new subflows. The two mechanisms are complementary:
the first is implicit and simple, while the explicit is more complex the first is implicit and simple, while the explicit is more complex
but is more robust. Together, the mechanisms allow addresses to but is more robust. Together, the mechanisms allow addresses to
change in flight (and thus support operation through NATs, since the change in flight (and thus support operation through NATs, since the
source address need not be known), and also allow the signalling of source address need not be known), and also allow the signaling of
previously unknown addresses, and of addresses belonging to other previously unknown addresses, and of addresses belonging to other
address families (e.g. both IPv4 and IPv6). address families (e.g. both IPv4 and IPv6).
Here is an example of typical operation of the protocol: Here is an example of typical operation of the protocol:
o An MPTCP connection is initially set up between address/port A1 of o An MPTCP connection is initially set up between address/port A1 of
host A and address/port B1 of host B. If host A is multihomed and host A and address/port B1 of host B. If host A is multihomed and
multi-addressed, it can start an additional subflow from its multi-addressed, it can start an additional subflow from its
address A2 to B1, by sending a SYN with a Join option from A2 to address A2 to B1, by sending a SYN with a Join option from A2 to
B1, using B's previously declared token for this connection. B1, using B's previously declared token for this connection.
skipping to change at page 35, line 26 skipping to change at page 35, line 35
and the length of the address will be 16 octets (instead of 4). and the length of the address will be 16 octets (instead of 4).
The presence of the final two octets, specifying the TCP port number The presence of the final two octets, specifying the TCP port number
to use, are optional and can be inferred from the length of the to use, are optional and can be inferred from the length of the
option. Although it is expected that the majority of use cases will option. Although it is expected that the majority of use cases will
use the same port pairs as used for the initial subflow (e.g. port 80 use the same port pairs as used for the initial subflow (e.g. port 80
remains port 80 on all subflows), as does the ephemeral port at the remains port 80 on all subflows), as does the ephemeral port at the
client, there may be cases (such as port-based load balancing) where client, there may be cases (such as port-based load balancing) where
the explicit specification of a different port is required. If no the explicit specification of a different port is required. If no
port is specified, MPTCP SHOULD attempt to connect to the specified port is specified, MPTCP SHOULD attempt to connect to the specified
address on the same port as is already in use by the signalling address on the same port as is already in use by the signaling
subflow, and this is discussed in more detail in Section 3.7. subflow, and this is discussed in more detail in Section 3.7.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-------+---------------+ +---------------+---------------+-------+-------+---------------+
| Kind | Length |Subtype| IPVer | Address ID | | Kind | Length |Subtype| IPVer | Address ID |
+---------------+---------------+-------+-------+---------------+ +---------------+---------------+-------+-------+---------------+
| Address (IPv4 - 4 octets / IPv6 - 16 octets) | | Address (IPv4 - 4 octets / IPv6 - 16 octets) |
+-------------------------------+---------------+---------------+ +-------------------------------+---------------+---------------+
| Port (2 octets, optional) | | Port (2 octets, optional) |
skipping to change at page 36, line 44 skipping to change at page 37, line 5
attempt on a previously advertised address/port combination can attempt on a previously advertised address/port combination can
therefore refresh ADD_ADDR information by sending the option again. therefore refresh ADD_ADDR information by sending the option again.
During normal MPTCP operation, it is unlikely that there will be During normal MPTCP operation, it is unlikely that there will be
sufficient TCP option space for ADD_ADDR to be included along with sufficient TCP option space for ADD_ADDR to be included along with
those for data sequence numbering (Section 3.3.1). Therefore, it is those for data sequence numbering (Section 3.3.1). Therefore, it is
expected that an MPTCP implementation will send the ADD_ADDR option expected that an MPTCP implementation will send the ADD_ADDR option
on separate ACKs. As discussed earlier, however, an MPTCP on separate ACKs. As discussed earlier, however, an MPTCP
implementation MUST NOT treat duplicate ACKs with MPTCP options as implementation MUST NOT treat duplicate ACKs with MPTCP options as
indications of congestion [8], and an MPTCP implementation SHOULD NOT indications of congestion [8], and an MPTCP implementation SHOULD NOT
send more than two duplicate ACKs in a row for signalling purposes. send more than two duplicate ACKs in a row for signaling purposes.
3.4.2. Remove Address 3.4.2. Remove Address
If, during the lifetime of an MPTCP connection, a previously- If, during the lifetime of an MPTCP connection, a previously-
announced address becomes invalid (e.g. if the interface disappears), announced address becomes invalid (e.g. if the interface disappears),
the affected host SHOULD announce this so that the peer can remove the affected host SHOULD announce this so that the peer can remove
subflows related to this address. subflows related to this address.
This is achieved through the Remove Address (REMOVE_ADDR) option This is achieved through the Remove Address (REMOVE_ADDR) option
(Figure 13), which will remove a previously-added address (or list of (Figure 13), which will remove a previously-added address (or list of
skipping to change at page 38, line 18 skipping to change at page 38, line 32
following rules. following rules.
A sender MUST include a DSS option with Data Sequence Mapping in A sender MUST include a DSS option with Data Sequence Mapping in
every segment until one of the sent segments has been acknowledged every segment until one of the sent segments has been acknowledged
with a DSS option containing a Data ACK. Upon reception of the with a DSS option containing a Data ACK. Upon reception of the
acknowledgement, the sender has the confirmation that the DSS option acknowledgement, the sender has the confirmation that the DSS option
passes in both directions and may choose to send fewer DSS options passes in both directions and may choose to send fewer DSS options
than once per segment. than once per segment.
If, however, an ACK is received for data (not just for the SYN) If, however, an ACK is received for data (not just for the SYN)
without a Data ACK in a DSS option, the sender determines the path is without a DSS option containing a Data ACK, the sender determines the
not MPTCP capable. In the case of this occurring on an additional path is not MPTCP capable. In the case of this occurring on an
subflow (i.e. one started with MP_JOIN), the host MUST close the additional subflow (i.e. one started with MP_JOIN), the host MUST
subflow with an RST. In the case of the first subflow (i.e. that close the subflow with an RST. In the case of the first subflow
started with MP_CAPABLE), it MUST drop out of an MPTCP mode back to (i.e. that started with MP_CAPABLE), it MUST drop out of an MPTCP
regular TCP. The sender will send one final Data Sequence Mapping, mode back to regular TCP. The sender will send one final Data
with the length value of 0 indicating an infinite mapping (in case Sequence Mapping, with the length value of 0 indicating an infinite
the path drops options in one direction only), and then revert to mapping (in case the path drops options in one direction only), and
sending data on the single subflow without any MPTCP options. then revert to sending data on the single subflow without any MPTCP
options.
Note that this rule essentially prohibits the sending of data on the Note that this rule essentially prohibits the sending of data on the
third packet of an MP_CAPABLE or MP_JOIN handshake, since both that third packet of an MP_CAPABLE or MP_JOIN handshake, since both that
option and a DSS cannot fit in TCP option space. If the initiator is option and a DSS cannot fit in TCP option space. If the initiator is
to send first, another segment must be sent that contains the data to send first, another segment must be sent that contains the data
and DSS. Note also that an additional subflow cannot be used until and DSS. Note also that an additional subflow cannot be used until
the initial path has been verified as MPTCP-capable. the initial path has been verified as MPTCP-capable.
These rules should cover all cases where such a failure could happen: These rules should cover all cases where such a failure could happen:
whether it's on the forward or reverse path, and whether the server whether it's on the forward or reverse path, and whether the server
skipping to change at page 39, line 45 skipping to change at page 40, line 21
+--------------------------------------------------------------+ +--------------------------------------------------------------+
: Data Sequence Number (continued) | : Data Sequence Number (continued) |
+--------------------------------------------------------------+ +--------------------------------------------------------------+
Figure 14: Fallback (MP_FAIL) option Figure 14: Fallback (MP_FAIL) option
Failed data will not be DATA_ACKed and so will be re-transmitted on Failed data will not be DATA_ACKed and so will be re-transmitted on
other subflows (Section 3.3.6). other subflows (Section 3.3.6).
A special case is when there is a single subflow and it fails with a A special case is when there is a single subflow and it fails with a
checksum error. Here, MPTCP should be able to recover and continue checksum error. If it is known that all unacknowledged data in
sending data. There are two possible mechanisms to support this. flight is contiguous, an infinite mapping can be applied to the
The first and simplest is to establish a new subflow as part of the subflow without the need to close it first, and essentially turn off
same MPTCP connection, and then close the original one with a RST. all further MPTCP signaling. In this case, if a receiver identifies
Since it is known that the path may be compromised, it is not a checksum failure when there is only one path, it will send back an
desirable to use MPTCP's segmentation on this path any longer. The MP_FAIL option on the subflow-level ACK. The sender will receive
new subflow will begin and will signal an infinite mapping (indicated this, and if all unacknowledged data in flight is contiguous, will
by length=0 in the Data Sequence Mapping option, Section 3.3) from signal an infinite mapping (if the data is not contiguous, the sender
the data sequence number of the segment that failed the checksum. MUST send an RST). This infinite mapping will be a DSS option
This connection will then continue to appear as a regular TCP (Section 3.3) on the first new packet, containing a Data Sequence
session, and a middlebox may change the payload without causing Mapping that acts retroactively, referring to the start of the
unintentional harm. subflow sequence number of the last segment that was known to be
delivered intact. From that point onwards data can be altered by a
An optimisation is possible, however. If it is known that all middlebox without affecting MPTCP, as the data stream is equivalent
unacknowledged data in flight is contiguous, an infinite mapping to a regular, legacy TCP session.
could be applied to the subflow without the need to close it first,
and essentially turn off all further MPTCP signalling. In this case,
if a receiver identifies a checksum failure when there is only one
path, it will send back an MP_FAIL option on the subflow-level ACK.
The sender will receive this, and if all unacknowledged data in
flight is contiguous, will signal an infinite mapping (if the data is
not contiguous, the sender MUST send an RST). This infinite mapping
will be a DSS option (Section 3.3) on the first new packet,
containing a Data Sequence Mapping that acts retroactively, referring
to the start of the subflow sequence number of the last segment that
was known to be delivered intact. From that point onwards data can
be altered by a middlebox without affecting MPTCP, as the data stream
is equivalent to a regular, legacy TCP session.
After a sender signals an infinite mapping it MUST only use subflow After a sender signals an infinite mapping it MUST only use subflow
ACKs to clear its send buffer. This is because Data ACKs may become ACKs to clear its send buffer. This is because Data ACKs may become
misaligned with the subflow ACKs when middleboxes insert or delete misaligned with the subflow ACKs when middleboxes insert or delete
data. The receive SHOULD stop generating Data ACKs after it receives data. The receive SHOULD stop generating Data ACKs after it receives
an infinite mapping. an infinite mapping.
When a connection is in fallback mode, only one subflow can send data When a connection is in fallback mode, only one subflow can send data
at a time. Otherwise, the receiver would not know how to reorder the at a time. Otherwise, the receiver would not know how to reorder the
data. However, subflows can be opened and closed as necessary, as data; in practice this means that all MPTCP subflows will have to be
long as a single one is active at any point. terminated except one. Once MPTCP falls back to regular TCP, it MUST
NOT revert to MPTCP later in the connection.
It should be emphasised that we are not attempting to prevent the use It should be emphasised that we are not attempting to prevent the use
of middleboxes that want to adjust the payload. An MPTCP-aware of middleboxes that want to adjust the payload. An MPTCP-aware
middlebox to provide such functionality could be designed that would middlebox could provide such functionality by also rewriting
re-write checksums if needed, and additionally would be able to parse checksums.
the data sequence mappings, and thus not hit false positives though
not knowing where data boundaries lie.
3.6. Error Handling 3.6. Error Handling
In addition to the fallback mechanism as described above, the In addition to the fallback mechanism as described above, the
standard classes of TCP errors may need to be handled in an MPTCP- standard classes of TCP errors may need to be handled in an MPTCP-
specific way. Note that changing semantics - such as the relevance specific way. Note that changing semantics - such as the relevance
of an RST - are covered in Section 4. Where possible, we do not want of an RST - are covered in Section 4. Where possible, we do not want
to deviate from regular TCP behaviour. to deviate from regular TCP behaviour.
The following list covers possible errors and the appropriate MPTCP The following list covers possible errors and the appropriate MPTCP
skipping to change at page 43, line 43 skipping to change at page 44, line 6
ACK: The ACK field in the TCP header acknowledges only the subflow ACK: The ACK field in the TCP header acknowledges only the subflow
sequence number, not the data-level sequence space. sequence number, not the data-level sequence space.
Implementations SHOULD NOT attempt to infer a data-level Implementations SHOULD NOT attempt to infer a data-level
acknowledgement from the subflow ACKs. Instead an explicit data- acknowledgement from the subflow ACKs. Instead an explicit data-
level ACK is used. This avoids possible deadlock scenarios when a level ACK is used. This avoids possible deadlock scenarios when a
non-TCP-aware middlebox pro-actively ACKs at the subflow level, non-TCP-aware middlebox pro-actively ACKs at the subflow level,
and separates subflow- and connection-level processing at an end and separates subflow- and connection-level processing at an end
host. host.
Duplicate ACK: A duplicate ACK that includes MPTCP signalling MUST Duplicate ACK: A duplicate ACK that includes MPTCP signaling MUST
NOT be treated as a signal of congestion. To avoid any non-MPTCP- NOT be treated as a signal of congestion. To avoid any non-MPTCP-
aware entities also mistakenly seeing duplicate ACKs in such aware entities also mistakenly seeing duplicate ACKs in such
cases, MPTCP SHOULD NOT send more than two duplicate ACKs cases, MPTCP SHOULD NOT send more than two duplicate ACKs
containing MPTCP signals in a row. containing MPTCP signals in a row.
Receive Window: The receive window in the TCP header indicates the Receive Window: The receive window in the TCP header indicates the
amount of free buffer space for the whole data-level connection amount of free buffer space for the whole data-level connection
(as opposed to for this subflow) that is available at the (as opposed to for this subflow) that is available at the
receiver. This is the same semantics as regular TCP, but to receiver. This is the same semantics as regular TCP, but to
maintain these semantics the receive window must be interpreted at maintain these semantics the receive window must be interpreted at
skipping to change at page 45, line 15 skipping to change at page 45, line 27
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 using it as part of a connection. address before using it as part of a connection.
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'.
In order to achieve these goals, MPTCP includes a hash-based In order to achieve these goals, MPTCP includes a hash-based
handshake algorithm documented in Section 3.1 and Section 3.2. handshake algorithm documented in Section 3.1 and Section 3.2.
The security of the MPTCP connection hangs on the use of keys that The security of the MPTCP connection hangs on the use of keys that
are shared once at the start of the first subflow, and never again in are shared once at the start of the first subflow, and are never sent
the clear. To ease demultiplexing whilst not giving away any again over the network. To ease demultiplexing whilst not giving
cryptographic material, future subflows use a truncated SHA-1 hash of away any cryptographic material, future subflows use a truncated
this key as the connection identification "token". The keys are SHA-1 hash of this key as the connection identification "token". The
combined and used as keys in a MAC, and this should verify that the keys are concatenated and used as keys for creating Message
Authentication Codes (MAC) used on subflow setup that verify that the
parties in the handshake are the same as in the original connection parties in the handshake are the same as in the original connection
setup. It also provides verification that the peer can receive setup. It also provides verification that the peer can receive
traffic at this new address. Replay attacks would still be possible traffic at this new address. Replay attacks would still be possible
when only keys are used, and therefore the handshakes use single-use when only keys are used, and therefore the handshakes use single-use
random numbers (nonces) at both ends - this ensures the MAC will random numbers (nonces) at both ends - this ensures the MAC will
never be the same on two handshakes. The use of crypto capability never be the same on two handshakes.
bits in the initial connection handshake to negotiate use of a
particular algorithm will allow the deployment of additional crypto The use of crypto capability bits in the initial connection handshake
mechanisms in the future. Note that this would be susceptible to to negotiate use of a particular algorithm will allow the deployment
bid-down attacks only if the attacker was on-path (and thus would be of additional crypto mechanisms in the future. Note that this would
able to modify the data anyway). The security mechanism presented in be susceptible to bid-down attacks only if the attacker was on-path
this draft should therefore protect against all forms of flooding and (and thus would be able to modify the data anyway). The security
hijacking attacks suggested in [6]. mechanism presented in this draft should therefore protect against
all forms of flooding and hijacking attacks discussed in [6].
6. Interactions with Middleboxes 6. Interactions with Middleboxes
Multipath TCP was designed to be deployable in the present world. Multipath TCP was designed to be deployable in the present world.
Its design takes into account "reasonable" existing middlebox Its design takes into account "reasonable" existing middlebox
behaviour. In this section we outline a few representative behaviour. In this section we outline a few representative
middlebox-related failure scenarios and show how multipath TCP middlebox-related failure scenarios and show how multipath TCP
handles them. Next, we list the design decisions multipath has made handles them. Next, we list the design decisions multipath has made
to accomodate the different middleboxes. to accomodate the different middleboxes.
skipping to change at page 47, line 27 skipping to change at page 47, line 52
though: most middleboxes will either strip all options or let them though: most middleboxes will either strip all options or let them
all through. all through.
We end this section with a list of middlebox classes, their behaviour We end this section with a list of middlebox classes, their behaviour
and the elements in the MPTCP design that allow operation through and the elements in the MPTCP design that allow operation through
such middleboxes. Issues surrounding dropping packets with options such middleboxes. Issues surrounding dropping packets with options
or stripping options were discussed above, and are not included here: or stripping options were discussed above, and are not included here:
o NATs [17] (Network Address (and Port) Translators) change the o NATs [17] (Network Address (and Port) Translators) change the
source address (and often source port) of packets. This means source address (and often source port) of packets. This means
that a host will not know its public-facing address for signalling that a host will not know its public-facing address for signaling
in MPTCP. Therefore, MPTCP permits implicit address addition via in MPTCP. Therefore, MPTCP permits implicit address addition via
the MP_JOIN option, and the handshake mechanism ensures that the MP_JOIN option, and the handshake mechanism ensures that
connection attempts to private addresses [15] do not cause connection attempts to private addresses [15] do not cause
problems. Explicit address removal is undertaken by an ID number problems. Explicit address removal is undertaken by an ID number
to allow no knowledge of the source address. to allow no knowledge of the source address.
o Performance Enhancing Proxies (PEPs) [18] might pro-actively ACK o Performance Enhancing Proxies (PEPs) [18] might pro-actively ACK
data to increase performance. Problems will occur if a PEP ACKs data to increase performance. Problems will occur if a PEP ACKs
data and then fails before sending it on to the receiver, or if data and then fails before sending it on to the receiver, or if
the receiver is mobile and moves away before proactively ACKed the receiver is mobile and moves away before proactively ACKed
skipping to change at page 48, line 6 skipping to change at page 48, line 30
o Traffic Normalizers [19] may not allow holes in sequence numbers, o Traffic Normalizers [19] may not allow holes in sequence numbers,
and may cache packets and retransmit the same data. MPTCP looks and may cache packets and retransmit the same data. MPTCP looks
like standard TCP on the wire, and will not retransmit different like standard TCP on the wire, and will not retransmit different
data on the same subflow sequence number. data on the same subflow sequence number.
o Firewalls [20] might perform initial sequence number randomization o Firewalls [20] might perform initial sequence number randomization
on TCP connections. MPTCP uses relative sequence numbers in data on TCP connections. MPTCP uses relative sequence numbers in data
sequence mapping to cope with this. Like NATs, firewalls will not sequence mapping to cope with this. Like NATs, firewalls will not
permit many incoming connections, so MPTCP supports address permit many incoming connections, so MPTCP supports address
signalling (ADD_ADDR) so that a multi-addressed host can invite signaling (ADD_ADDR) so that a multi-addressed host can invite its
its peer behind the firewall/NAT to connect out to its additional peer behind the firewall/NAT to connect out to its additional
interface. interface.
o Intrusion Detection Systems look out for traffic patterns and o Intrusion Detection Systems look out for traffic patterns and
content that could threaten a network. Multipath will mean that content that could threaten a network. Multipath will mean that
such data is potentially spread, so it is more difficult for an such data is potentially spread, so it is more difficult for an
IDS to analyse the whole traffic, and potentially increases the IDS to analyse the whole traffic, and potentially increases the
risk of false positives. However, for an MPTCP-aware IDS, tokens risk of false positives. However, for an MPTCP-aware IDS, tokens
can be read by such systems to correlate multiple subflows and re- can be read by such systems to correlate multiple subflows and re-
assemble for analysis. assemble for analysis.
skipping to change at page 48, line 49 skipping to change at page 49, line 25
sequence number instead of using the sequence number in the sequence number instead of using the sequence number in the
segment. In this way, the mapping is independent of the packets segment. In this way, the mapping is independent of the packets
that carry it. that carry it.
o The Receive Window may be shrunk by some middleboxes at the o The Receive Window may be shrunk by some middleboxes at the
subflow level. MPTCP will use the maximum window at data-level, subflow level. MPTCP will use the maximum window at data-level,
but will also obey subflow specific windows. but will also obey subflow specific windows.
7. Acknowledgements 7. Acknowledgements
The authors are supported by Trilogy The authors were supported by Trilogy
(http://www.trilogy-project.org), a research project (ICT-216372) (http://www.trilogy-project.org), a research project (ICT-216372)
partially funded by the European Community under its Seventh partially funded by the European Community under its Seventh
Framework Program. The views expressed here are those of the Framework Program. The views expressed here are those of the
author(s) only. The European Commission is not liable for any use author(s) only. The European Commission is not liable for any use
that may be made of the information in this document. that may be made of the information in this document.
Alan Ford was supported by Roke Manor Research.
The authors gratefully acknowledge significant input into this The authors gratefully acknowledge significant input into this
document from Sebastien Barre, Christoph Paasch, and Andrew McDonald. document from Sebastien Barre, Christoph Paasch, and Andrew McDonald.
The authors also wish to acknowledge reviews and contributions from The authors also wish to acknowledge reviews and contributions from
Iljitsch van Beijnum, Lars Eggert, Marcelo Bagnulo, Robert Hancock, Iljitsch van Beijnum, Lars Eggert, Marcelo Bagnulo, Robert Hancock,
Pasi Sarolahti, Toby Moncaster, Philip Eardley, Sergio Lembo, Pasi Sarolahti, Toby Moncaster, Philip Eardley, Sergio Lembo,
Lawrence Conroy, Yoshifumi Nishida, Bob Briscoe, Stein Gjessing, Lawrence Conroy, Yoshifumi Nishida, Bob Briscoe, Stein Gjessing,
Andrew McGregor, and Georg Hampel. Andrew McGregor, Georg Hampel, and Anumita Biswas.
8. IANA Considerations 8. IANA Considerations
This document will make a request to IANA to allocate a new TCP This document will make a request to IANA to allocate a new TCP
option value for MPTCP. This value will be the value of the "Kind" option value for MPTCP. This value will be the value of the "Kind"
field seen in all MPTCP options in this document. field seen in all MPTCP options in this document.
This document will also request IANA operates a registry for MPTCP This document will also request IANA operates a registry for MPTCP
option subtype values. The values as defined by this specification option subtype values. The values as defined by this specification
are as follows: are as follows:
skipping to change at page 50, line 30 skipping to change at page 51, line 6
9.2. Informative References 9.2. Informative References
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[3] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, [3] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar,
"Architectural Guidelines for Multipath TCP Development", "Architectural Guidelines for Multipath TCP Development",
RFC 6182, March 2011. RFC 6182, March 2011.
[4] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion [4] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion
Control for Multipath Transport Protocols", Control for Multipath Transport Protocols", RFC 6356,
draft-ietf-mptcp-congestion-05 (work in progress), June 2011. October 2011.
[5] Scharf, M. and A. Ford, "MPTCP Application Interface [5] Scharf, M. and A. Ford, "MPTCP Application Interface
Considerations", draft-ietf-mptcp-api-02 (work in progress), Considerations", draft-ietf-mptcp-api-03 (work in progress),
June 2011. November 2011.
[6] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath [6] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath
Operation with Multiple Addresses", RFC 6181, March 2011. Operation with Multiple Addresses", RFC 6181, March 2011.
[7] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [7] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996. Selective Acknowledgment Options", RFC 2018, October 1996.
[8] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion [8] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999. Control", RFC 2581, April 1999.
skipping to change at page 53, line 4 skipping to change at page 53, line 28
necessary to reduce the number of SACK blocks to accomodate the DATA necessary to reduce the number of SACK blocks to accomodate the DATA
ACK. However, the presence of the DATA ACK is unlikely to be ACK. However, the presence of the DATA ACK is unlikely to be
necessary in a case where SACK is in use, since until at least some necessary in a case where SACK is in use, since until at least some
of the SACK blocks have been retransmitted, the cumulative data-level of the SACK blocks have been retransmitted, the cumulative data-level
ACK will not be moving forward (or if it does, due to retransmissions ACK will not be moving forward (or if it does, due to retransmissions
on another path, then that path can also be used to transmit the new on another path, then that path can also be used to transmit the new
DATA ACK). DATA ACK).
The ADD_ADDR option can be between 8 and 22 bytes, depending on The ADD_ADDR option can be between 8 and 22 bytes, depending on
whether IPv4 or IPv6 is used, and whether the port number is present whether IPv4 or IPv6 is used, and whether the port number is present
or not. It is unlikely that such signalling would fit in a data or not. It is unlikely that such signaling would fit in a data
packet (although if there is space, it is fine to include it). It is packet (although if there is space, it is fine to include it). It is
recommended to use duplicate ACKs with no other payload or options in recommended to use duplicate ACKs with no other payload or options in
order to transmit these rare signals. Note this is the reason for order to transmit these rare signals. Note this is the reason for
mandating that duplicate ACKs with MPTCP options are not taken as a mandating that duplicate ACKs with MPTCP options are not taken as a
signal of congestion. signal of congestion.
Finally, there are issues with reliable delivery of options. As Finally, there are issues with reliable delivery of options. As
options can also be sent on pure ACKs, these are not reliably sent. options can also be sent on pure ACKs, these are not reliably sent.
This is not an issue for DATA_ACK due to their cumulative nature, but This is not an issue for DATA_ACK due to their cumulative nature, but
may be an issue for ADD_ADDR/REMOVE_ADDR options. Here, it is may be an issue for ADD_ADDR/REMOVE_ADDR options. Here, it is
skipping to change at page 56, line 39 skipping to change at page 56, line 46
------------ ------------
delete MPTCP PCB delete MPTCP PCB
Figure 16: Finite State Machine for Connection Closure Figure 16: Finite State Machine for Connection Closure
Appendix D. Changelog Appendix D. Changelog
This section maintains logs of significant changes made to this This section maintains logs of significant changes made to this
document between versions. document between versions.
D.1. Changes since draft-ietf-mptcp-multiaddressed-03 D.1. Changes since draft-ietf-mptcp-multiaddressed-04
o Reverted change to MP_CAPABLE from last revision.
o Clarifications in response to comments.
D.2. Changes since draft-ietf-mptcp-multiaddressed-03
o Removed Key from MP_CAPABLE on SYN (it is in the ACK). o Removed Key from MP_CAPABLE on SYN (it is in the ACK).
o Added optional Address ID to MP_PRIO. o Added optional Address ID to MP_PRIO.
o Responded to review comments. o Responded to review comments.
D.2. Changes since draft-ietf-mptcp-multiaddressed-02 D.3. Changes since draft-ietf-mptcp-multiaddressed-02
o Changed to using a single TCP option with a sub-type field. o Changed to using a single TCP option with a sub-type field.
o Merged Data Sequence Number, DATA ACK, and DATA FIN. o Merged Data Sequence Number, DATA ACK, and DATA FIN.
o Changed DATA FIN behaviour (separated from subflow FIN). o Changed DATA FIN behaviour (separated from subflow FIN).
o Added crypto agility and checksum negotiation. o Added crypto agility and checksum negotiation.
o Redefined MP_JOIN handshake to use only three TCP options. o Redefined MP_JOIN handshake to use only three TCP options.
o Added pseudo-header to checksum. o Added pseudo-header to checksum.
o Many clarifications and re-structuring. o Many clarifications and re-structuring.
o Added more discussion on heuristics. o Added more discussion on heuristics.
D.3. Changes since draft-ietf-mptcp-multiaddressed-01 D.4. Changes since draft-ietf-mptcp-multiaddressed-01
o Added proposal for hash-based security mechanism. o Added proposal for hash-based security mechanism.
o Added receiver subflow policy control (backup path flags and o Added receiver subflow policy control (backup path flags and
MP_PRIO option). MP_PRIO option).
o Changed DSN_MAP checksum to use the TCP checksum algorithm. o Changed DSN_MAP checksum to use the TCP checksum algorithm.
D.4. Changes since draft-ietf-mptcp-multiaddressed-00 D.5. Changes since draft-ietf-mptcp-multiaddressed-00
o Various clarifications and minor re-structuring in response to o Various clarifications and minor re-structuring in response to
comments. comments.
D.5. Changes since draft-ford-mptcp-multiaddressed-03 D.6. Changes since draft-ford-mptcp-multiaddressed-03
o Clarified handshake mechanism, especially with regard to error o Clarified handshake mechanism, especially with regard to error
cases (Section 3.2). cases (Section 3.2).
o Added optional port to ADD_ADDR and clarified situation with o Added optional port to ADD_ADDR and clarified situation with
private addresses (Section 3.4.1). private addresses (Section 3.4.1).
o Added path liveness check to REMOVE_ADDR (Section 3.4.2). o Added path liveness check to REMOVE_ADDR (Section 3.4.2).
o Added chunk checksumming to DSN_MAP (Section 3.3.1) to detect o Added chunk checksumming to DSN_MAP (Section 3.3.1) to detect
payload-altering middleboxes, and defined fallback mechanism payload-altering middleboxes, and defined fallback mechanism
(Section 3.5). (Section 3.5).
o Major clarifications to receive window discussion (Section 3.3.5). o Major clarifications to receive window discussion (Section 3.3.5).
o Various textual clarifications, especially in examples. o Various textual clarifications, especially in examples.
D.6. Changes since draft-ford-mptcp-multiaddressed-02 D.7. Changes since draft-ford-mptcp-multiaddressed-02
o Remove Version and Address ID in MP_CAPABLE in Section 3.1, and o Remove Version and Address ID in MP_CAPABLE in Section 3.1, and
make ISN be 6 bytes. make ISN be 6 bytes.
o Data sequence numbers are now always 8 bytes. But in some cases o Data sequence numbers are now always 8 bytes. But in some cases
where it is unambiguous it is permissible to only send the lower 4 where it is unambiguous it is permissible to only send the lower 4
bytes if space is at a premium. bytes if space is at a premium.
o Clarified behaviour of MP_JOIN in Section 3.2. o Clarified behaviour of MP_JOIN in Section 3.2.
o Added DATA_ACK to Section 3.3. o Added DATA_ACK to Section 3.3.
o Clarified fallback to non-multipath once a non-MP-capable SYN is o Clarified fallback to non-multipath once a non-MP-capable SYN is
sent. sent.
Authors' Addresses Authors' Addresses
Alan Ford Alan Ford
Roke Manor Research
Old Salisbury Lane
Romsey, Hampshire SO51 0ZN
UK
Phone: +44 1794 833 465 Email: alan.ford@gmail.com
Email: alan.ford@roke.co.uk
Costin Raiciu Costin Raiciu
University College London University Politehnica of Bucharest
Gower Street Splaiul Independentei 313
London WC1E 6BT Bucharest
UK Romania
Email: c.raiciu@cs.ucl.ac.uk
Email: costin.raiciu@cs.pub.ro
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
Olivier Bonaventure Olivier Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
Pl. Ste Barbe, 2 Pl. Ste Barbe, 2
Louvain-la-Neuve 1348 Louvain-la-Neuve 1348
Belgium Belgium
Email: olivier.bonaventure@uclouvain.be Email: olivier.bonaventure@uclouvain.be
 End of changes. 75 change blocks. 
204 lines changed or deleted 201 lines changed or added

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