draft-ietf-mptcp-rfc6824bis-09.txt   draft-ietf-mptcp-rfc6824bis-10.txt 
Internet Engineering Task Force A. Ford Internet Engineering Task Force A. Ford
Internet-Draft Pexip Internet-Draft Pexip
Obsoletes: 6824 (if approved) C. Raiciu Obsoletes: 6824 (if approved) C. Raiciu
Intended status: Standards Track U. Politechnica of Bucharest Intended status: Standards Track U. Politechnica of Bucharest
Expires: January 29, 2018 M. Handley Expires: September 5, 2018 M. Handley
U. College London U. College London
O. Bonaventure O. Bonaventure
U. catholique de Louvain U. catholique de Louvain
C. Paasch C. Paasch
Apple, Inc. Apple, Inc.
July 28, 2017 March 4, 2018
TCP Extensions for Multipath Operation with Multiple Addresses TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-rfc6824bis-09 draft-ietf-mptcp-rfc6824bis-10
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 46 skipping to change at page 1, line 46
modifications primarily driven by deployment experience. modifications primarily driven by deployment experience.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). 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 https://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 29, 2018. This Internet-Draft will expire on September 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Design Assumptions . . . . . . . . . . . . . . . . . . . 4 1.1. Design Assumptions . . . . . . . . . . . . . . . . . . . 4
1.2. Multipath TCP in the Networking Stack . . . . . . . . . . 5 1.2. Multipath TCP in the Networking Stack . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. MPTCP Concept . . . . . . . . . . . . . . . . . . . . . . 6 1.4. MPTCP Concept . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Requirements Language . . . . . . . . . . . . . . . . . . 8 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 8
2. Operation Overview . . . . . . . . . . . . . . . . . . . . . 8 2. Operation Overview . . . . . . . . . . . . . . . . . . . . . 8
2.1. Initiating an MPTCP Connection . . . . . . . . . . . . . 8 2.1. Initiating an MPTCP Connection . . . . . . . . . . . . . 9
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 Address 9 2.3. Informing the Other Host about Another Potential Address 10
2.4. Data Transfer Using MPTCP . . . . . . . . . . . . . . . . 10 2.4. Data Transfer Using MPTCP . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . 12
2.7. Notable Features . . . . . . . . . . . . . . . . . . . . 12 2.7. Notable Features . . . . . . . . . . . . . . . . . . . . 12
3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . 12 3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 13 3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 14
3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . 20 3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . 20
3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 25 3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 25
3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 27 3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 27
3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . 30 3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . 30
3.3.3. Closing a Connection . . . . . . . . . . . . . . . . 31 3.3.3. Closing a Connection . . . . . . . . . . . . . . . . 31
3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 32 3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 32
3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 33 3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 33
3.3.6. Reliability and Retransmissions . . . . . . . . . . . 34 3.3.6. Reliability and Retransmissions . . . . . . . . . . . 34
3.3.7. Congestion Control Considerations . . . . . . . . . . 35 3.3.7. Congestion Control Considerations . . . . . . . . . . 35
3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . 36 3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . 36
3.4. Address Knowledge Exchange (Path Management) . . . . . . 37 3.4. Address Knowledge Exchange (Path Management) . . . . . . 37
3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 38 3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 38
3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . 42 3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . 42
3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . 43 3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . 43
3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 44 3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 44
3.7. MPTCP Experimental Option . . . . . . . . . . . . . . . . 46 3.7. MPTCP Experimental Option . . . . . . . . . . . . . . . . 46
3.8. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 47 3.8. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 47
3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . 51 3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . 51
3.10. Heuristics . . . . . . . . . . . . . . . . . . . . . . . 51 3.10. Heuristics . . . . . . . . . . . . . . . . . . . . . . . 52
3.10.1. Port Usage . . . . . . . . . . . . . . . . . . . . . 52 3.10.1. Port Usage . . . . . . . . . . . . . . . . . . . . . 52
3.10.2. Delayed Subflow Start and Subflow Symmetry . . . . . 52 3.10.2. Delayed Subflow Start and Subflow Symmetry . . . . . 52
3.10.3. Failure Handling . . . . . . . . . . . . . . . . . . 53 3.10.3. Failure Handling . . . . . . . . . . . . . . . . . . 53
4. Semantic Issues . . . . . . . . . . . . . . . . . . . . . . . 54 3.11. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 54
5. Security Considerations . . . . . . . . . . . . . . . . . . . 55 3.11.1. TFO cookie request with MPTCP . . . . . . . . . . . 54
6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 58 3.11.2. Data sequence mapping under TFO . . . . . . . . . . 55
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 61 3.11.3. Connection establishment examples . . . . . . . . . 56
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 4. Semantic Issues . . . . . . . . . . . . . . . . . . . . . . . 58
8.1. MPTCP Option Subtypes . . . . . . . . . . . . . . . . . . 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 59
8.2. MPTCP Handshake Algorithms . . . . . . . . . . . . . . . 63 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 62
8.3. MP_TCPRST Reason Codes . . . . . . . . . . . . . . . . . 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65
8.4. Experimental option registry . . . . . . . . . . . . . . 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 8.1. MPTCP Option Subtypes . . . . . . . . . . . . . . . . . . 66
9.1. Normative References . . . . . . . . . . . . . . . . . . 64 8.2. MPTCP Handshake Algorithms . . . . . . . . . . . . . . . 67
9.2. Informative References . . . . . . . . . . . . . . . . . 65 8.3. MP_TCPRST Reason Codes . . . . . . . . . . . . . . . . . 67
Appendix A. Notes on Use of TCP Options . . . . . . . . . . . . 68 8.4. Experimental option registry . . . . . . . . . . . . . . 68
Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 68
B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 68
B.1.1. Authentication and Metadata . . . . . . . . . . . . . 70 9.2. Informative References . . . . . . . . . . . . . . . . . 69
B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 70 Appendix A. Notes on Use of TCP Options . . . . . . . . . . . . 72
B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . 70 Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 73
B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . 71 B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 74
B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . 71 B.1.1. Authentication and Metadata . . . . . . . . . . . . . 74
B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . 71 B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 74
Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 71 B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . 75
B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . 75
B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . 75
Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
Multipath TCP (MPTCP) is a set of extensions to regular TCP [RFC0793] Multipath TCP (MPTCP) is a set of extensions to regular TCP [RFC0793]
to provide a Multipath TCP [RFC6182] service, which enables a to provide a Multipath TCP [RFC6182] service, which enables a
transport connection to operate across multiple paths simultaneously. transport connection to operate across multiple paths simultaneously.
This document presents the protocol changes required to add multipath This document presents the protocol changes required to add multipath
capability to TCP; specifically, those for signaling and setting up capability to TCP; specifically, those for signaling and setting up
multiple paths ("subflows"), managing these subflows, reassembly of multiple paths ("subflows"), managing these subflows, reassembly of
data, and termination of sessions. This is not the only information data, and termination of sessions. This is not the only information
skipping to change at page 15, line 14 skipping to change at page 15, line 23
o ACK (with first data) (A->B): A's Key followed by B's Key followed o ACK (with first data) (A->B): A's Key followed by B's Key followed
by Data-Level Length, and optional Checksum (Length = 22 or 24). by Data-Level Length, and optional Checksum (Length = 22 or 24).
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, along with the option's length field. For the diagram the packet, along with 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).
The initial SYN, containing just the MP_CAPABLE header, is used to The initial SYN, containing just the MP_CAPABLE header, is used to
define the version of MPTCP beign requested, as well as exchanging define the version of MPTCP being requested, as well as exchanging
flags to negotiate connection features, described later. flags to negotiate connection features, described later.
This option is used to declare the 64-bit keys that the end hosts This option is used to declare the 64-bit keys that the end hosts
have generated for this MPTCP connection. This key is used to have generated for this MPTCP connection. This key is used to
authenticate the addition of future subflows to this connection. authenticate the addition of future subflows to this connection.
This is the only time the key will be sent in clear on the wire This is the only time the key will be sent in clear on the wire
(unless "fast close", Section 3.5, is used); all future subflows will (unless "fast close", Section 3.5, is used); all future subflows will
identify the connection using a 32-bit "token". This token is a identify the connection using a 32-bit "token". This token is a
cryptographic hash of this key. The algorithm for this process is cryptographic hash of this key. The algorithm for this process is
dependent on the authentication algorithm selected; the method of dependent on the authentication algorithm selected; the method of
skipping to change at page 43, line 8 skipping to change at page 43, line 8
+---------------+---------------+-------+-------+---------------+ +---------------+---------------+-------+-------+---------------+
| Kind | Length = 3+n |Subtype|(resvd)| Address ID | ... | Kind | Length = 3+n |Subtype|(resvd)| Address ID | ...
+---------------+---------------+-------+-------+---------------+ +---------------+---------------+-------+-------+---------------+
(followed by n-1 Address IDs, if required) (followed by n-1 Address IDs, if required)
Figure 13: Remove Address (REMOVE_ADDR) Option Figure 13: Remove Address (REMOVE_ADDR) Option
3.5. Fast Close 3.5. Fast Close
Regular TCP has the means of sending a reset (RST) signal to abruptly Regular TCP has the means of sending a reset (RST) signal to abruptly
close a connection. With MPTCP, the RST only has the scope of the close a connection. With MPTCP, a regular RST only has the scope of
subflow and will only close the concerned subflow but not affect the the subflow and will only close the concerned subflow but not affect
remaining subflows. MPTCP's connection will stay alive at the data the remaining subflows. MPTCP's connection will stay alive at the
level, in order to permit break-before-make handover between data level, in order to permit break-before-make handover between
subflows. It is therefore necessary to provide an MPTCP-level subflows. It is therefore necessary to provide an MPTCP-level
"reset" to allow the abrupt closure of the whole MPTCP connection, "reset" to allow the abrupt closure of the whole MPTCP connection,
and this is the MP_FASTCLOSE option. and this is the MP_FASTCLOSE option.
MP_FASTCLOSE is used to indicate to the peer that the connection will MP_FASTCLOSE is used to indicate to the peer that the connection will
be abruptly closed and no data will be accepted anymore. The reasons be abruptly closed and no data will be accepted anymore. The reasons
for triggering an MP_FASTCLOSE are implementation specific. Regular for triggering an MP_FASTCLOSE are implementation specific. Regular
TCP does not allow sending a RST while the connection is in a TCP does not allow sending a RST while the connection is in a
synchronized state [RFC0793]. Nevertheless, implementations allow synchronized state [RFC0793]. Nevertheless, implementations allow
the sending of a RST in this state, if, for example, the operating the sending of a RST in this state, if, for example, the operating
skipping to change at page 43, line 37 skipping to change at page 43, line 37
+---------------+---------------+-------+-----------------------+ +---------------+---------------+-------+-----------------------+
| Kind | Length |Subtype| (reserved) | | Kind | Length |Subtype| (reserved) |
+---------------+---------------+-------+-----------------------+ +---------------+---------------+-------+-----------------------+
| Option Receiver's Key | | Option Receiver's Key |
| (64 bits) | | (64 bits) |
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 14: Fast Close (MP_FASTCLOSE) Option Figure 14: Fast Close (MP_FASTCLOSE) Option
If Host A wants to force the closure of an MPTCP connection, the If Host A wants to force the closure of an MPTCP connection, it has
MPTCP Fast Close procedure is as follows: two different options:
o Host A sends an ACK containing the MP_FASTCLOSE option on one o Option A (ACK) : Host A sends an ACK containing the MP_FASTCLOSE
subflow, containing the key of Host B as declared in the initial option on one subflow, containing the key of Host B as declared in
connection handshake. On all the other subflows, Host A sends a the initial connection handshake. On all the other subflows, Host
regular TCP RST to close these subflows, and tears them down. A sends a regular TCP RST to close these subflows, and tears them
Host A now enters FASTCLOSE_WAIT state. down. Host A now enters FASTCLOSE_WAIT state.
o Upon receipt of an MP_FASTCLOSE, containing the valid key, Host B o Option R (RST) : Host A sends a RST containing the MP_FASTCLOSE
answers on the same subflow with a TCP RST and tears down all option on all subflows, containing the key of Host B as declared
subflows. Host B can now close the whole MPTCP connection (it in the initial connection handshake. Host A can tear the subflows
transitions directly to CLOSED state). and the connection down immediately.
If a host receives a packet with a valid MP_FASTCLOSE option, it
shall process it as follows :
o Upon receipt of an ACK with MP_FASTCLOSE, containing the valid
key, Host B answers on the same subflow with a TCP RST and tears
down all subflows. Host B can now close the whole MPTCP
connection (it transitions directly to CLOSED state).
o As soon as Host A has received the TCP RST on the remaining o As soon as Host A has received the TCP RST on the remaining
subflow, it can close this subflow and tear down the whole subflow, it can close this subflow and tear down the whole
connection (transition from FASTCLOSE_WAIT to CLOSED states). If connection (transition from FASTCLOSE_WAIT to CLOSED states). If
Host A receives an MP_FASTCLOSE instead of a TCP RST, both hosts Host A receives an MP_FASTCLOSE instead of a TCP RST, both hosts
attempted fast closure simultaneously. Host A should reply with a attempted fast closure simultaneously. Host A should reply with a
TCP RST and tear down the connection. TCP RST and tear down the connection.
o If Host A does not receive a TCP RST in reply to its MP_FASTCLOSE o If Host A does not receive a TCP RST in reply to its MP_FASTCLOSE
after one retransmission timeout (RTO) (the RTO of the subflow after one retransmission timeout (RTO) (the RTO of the subflow
where the MPTCP_RST has been sent), it SHOULD retransmit the where the MP_FASTCLOSE has been sent), it SHOULD retransmit the
MP_FASTCLOSE. The number of retransmissions SHOULD be limited to MP_FASTCLOSE. The number of retransmissions SHOULD be limited to
avoid this connection from being retained for a long time, but avoid this connection from being retained for a long time, but
this limit is implementation specific. A RECOMMENDED number is 3. this limit is implementation specific. A RECOMMENDED number is 3.
If no TCP RST is received in response, Host A SHOULD send a TCP If no TCP RST is received in response, Host A SHOULD send a TCP
RST itself when it releases state in order to clear any remaining RST with the MP_FASTCLOSE option itself when it releases state in
state at middleboxes. order to clear any remaining state at middleboxes.
o Upon receipt of a RST with MP_FASTCLOSE, containing the valid key,
Host B tears down all subflows. Host B can now close the whole
MPTCP connection (it transitions directly to CLOSED state).
3.6. Subflow Reset 3.6. Subflow Reset
As discussed in Section 3.5 above, the MP_FASTCLOSE option provides a As discussed in Section 3.5 above, the MP_FASTCLOSE option provides a
connection-level reset roughly analagous to a TCP RST. Regular TCP connection-level reset roughly analagous to a TCP RST. Regular TCP
RST options remain used to at the subflow-level to indicate the RST options remain used to at the subflow-level to indicate the
receiving host has no knowledge of the MPTCP subflow or TCP receiving host has no knowledge of the MPTCP subflow or TCP
connection to which the packet belongs. connection to which the packet belongs.
However, in MPTCP, there may be many reasons for rejecting the However, in MPTCP, there may be many reasons for rejecting the
skipping to change at page 54, line 20 skipping to change at page 54, line 26
the ADD_ADDR option is informational only, and does not guarantee the the ADD_ADDR option is informational only, and does not guarantee the
other host will attempt a connection. other host will attempt a connection.
In addition, an implementation may learn, over a number of In addition, an implementation may learn, over a number of
connections, that certain interfaces or destination addresses connections, that certain interfaces or destination addresses
consistently fail and may default to not trying to use MPTCP for consistently fail and may default to not trying to use MPTCP for
these. Behavior could also be learned for particularly badly these. Behavior could also be learned for particularly badly
performing subflows or subflows that regularly fail during use, in performing subflows or subflows that regularly fail during use, in
order to temporarily choose not to use these paths. order to temporarily choose not to use these paths.
3.11. TCP Fast Open
TCP Fast Open, described in [RFC7413], has been introduced with the
objective of gaining one RTT before transmitting data. This is
considered a valuable gain as very short connections are very common,
especially for HTTP request/response schemes. It achieves this by
sending the SYN-segment together with data and allowing the server to
reply immediately with data after the SYN/ACK. [RFC7413] secures
this mechanism, by using a new TCP option that includes a cookie
which is negotiated in a preceding connection.
When using TCP Fast Open in conjunction with MPTCP, there are two key
points to take into account, detailed hereafter.
3.11.1. TFO cookie request with MPTCP
When a TFO client first connects to a server, it cannot immediately
include data in the SYN for security reasons [RFC7413]. Instead, it
requests a cookie that will be used in subsequent connections. This
is done with the TCP cookie request/response options, of resp. 2
bytes and 6-18 bytes (depending on the chosen cookie length).
TFO and MPTCP can be combined provided that the total length of their
options does not exceed the maximum 40 bytes possible in TCP:
o In the SYN: MPTCP uses a 4-bytes long MP_CAPABLE option. The
MPTCP and TFO options sum up to 6 bytes. With typical TCP-options
using up to 19 bytes in the SYN (24 bytes if options are padded at
a word boundary), there is enough space to combine the MP_CAPABLE
with the TFO Cookie Request.
o In the SYN+ACK: MPTCP uses a 12-bytes long MP_CAPABLE option, but
now TFO can be as long as 18 bytes. Since the maximum option
length may be exceeded, it is up to the server to solve this by
using a shorter cookie. As an example, if we consider that 19
bytes are used for classical TCP options, the maximum possible
cookie length would be of 7 bytes. Note that the same limitation
applies to subsequent connections, for the SYN packet (because the
client then echoes back the cookie to the server). Finally, if
the security impact of reducing the cookie size is not deemed
acceptable, the server can reduce the amount of other TCP-options
by omitting the TCP timestamps (as outlined in Appendix A).
3.11.2. Data sequence mapping under TFO
MPTCP uses, in the TCP establishment phase, a key exchange that is
used to generate the Initial Data Sequence Numbers (IDSNs). In
particular, the SYN with MP_CAPABLE occupies the first octet of the
data sequence space. With TFO, one way to handle the data sent
together with the SYN would be to consider an implicit DSS mapping
that covers that SYN segment (since there is not enough space in the
SYN to include a DSS option). The problem with that approach is that
if a middlebox modifies the TFO data, this will not be noticed by
MPTCP because of the absence of a DSS-checksum. For example, a TCP
(but not MPTCP)-aware middlebox could insert bytes at the beginning
of the stream and adapt the TCP checksum and sequence numbers
accordingly. With an implicit mapping, this would give to client and
server a different view on the DSS-mapping, with no way to detect
this inconsistency as the DSS checksum is not present.
To solve this, the TFO data should not be considered part of the Data
Sequence Number space: the SYN with MP_CAPABLE still occupies the
first octet of data sequence space, but then the first non-TFO data
byte occupies the second octet. This guarantees that, if the use of
DSS-checksum is negotiated, all data in the data sequence number
space is checksummed. We also note that this does not entail a loss
of functionality, because TFO-data is always sent when only one path
is active.
3.11.3. Connection establishment examples
The following shows a few examples of possible TFO+MPTCP
establishment scenarios.
Before a client can send data together with the SYN, it must request
a cookie to the server, as shown in Figure Figure 18. This is done
by simply combining the TFO and MPTCP options.
client server
| |
| S 0(0) <MP_CAPABLE>, <TFO cookie request> |
| -----------------------------------------------------------> |
| |
| S. 0(0) ack 1 <MP_CAPABLE>, <TFO cookie> |
| <----------------------------------------------------------- |
| |
| . 0(0) ack 1 <MP_CAPABLE> |
| -----------------------------------------------------------> |
| |
Figure 18: Cookie request
Once this is done, the received cookie can be used for TFO, as shown
in Figure Figure 19. In this example, the client first sends 20
bytes in the SYN. The server immediately replies with 100 bytes
following the SYN-ACK upon which the client replies with 20 more
bytes. Note that the last segment in the figure has a TCP sequence
number of 21, while the DSS subflow sequence number is 1 (because the
TFO data is not part of the data sequence number space, as explained
in Section Section 3.11.2.
client server
| |
| S 0(20) <MP_CAPABLE>, <TFO cookie> |
| -----------------------------------------------------------> |
| |
| S. 0(0) ack 21 <MP_CAPABLE> |
| <----------------------------------------------------------- |
| |
| . 1(100) ack 21 <DSS ack=1 seq=1 ssn=1 dlen=100> |
| <----------------------------------------------------------- |
| |
| . 21(0) ack 1 <MP_CAPABLE> |
| -----------------------------------------------------------> |
| |
| . 21(20) ack 101 <DSS ack=101 seq=1 ssn=1 dlen=20> |
| -----------------------------------------------------------> |
| |
Figure 19: The server supports TFO
In Figure Figure 20, the server does not support TFO. The client
detects that no state is created in the server (as no data is acked),
and now sends the MP_CAPABLE in the third ack, in order for the
server to build its MPTCP context at then end of the establishment.
Now, the tfo data, retransmitted, becomes part of the data sequence
mapping because it is effectively sent (in fact re-sent) after the
establishment.
client server
| |
| S 0(20) <MP_CAPABLE>, <TFO cookie> |
| -----------------------------------------------------------> |
| |
| S. 0(0) ack 1 <MP_CAPABLE> |
| <----------------------------------------------------------- |
| |
| . 1(0) ack 1 <MP_CAPABLE> |
| -----------------------------------------------------------> |
| |
| . 1(20) ack 1 <DSS ack=1 seq=1 ssn=1 dlen=20> |
| -----------------------------------------------------------> |
| |
| . 0(0) ack 21 <DSS ack=21 seq=1 ssn=1 dlen=0> |
| <----------------------------------------------------------- |
| |
Figure 20: The server does not support TFO
It is also possible that the server acknowledges only part of the TFO
data, as illustrated in Figure Figure 21. The client will simply
retransmit the missing data together with a DSS-mapping.
client server
| |
| S 0(1000) <MP_CAPABLE>, <TFO cookie> |
| -----------------------------------------------------------> |
| |
| S. 0(0) ack 501 <MP_CAPABLE> |
| <----------------------------------------------------------- |
| |
| . 501(0) ack 1 <MP_CAPABLE> |
| -----------------------------------------------------------> |
| |
| . 501(500) ack 1 <DSS ack=1 seq=1 ssn=1 dlen=500> |
| -----------------------------------------------------------> |
| |
Figure 21: Partial data acknowledgement
4. Semantic Issues 4. Semantic Issues
In order to support multipath operation, the semantics of some TCP In order to support multipath operation, the semantics of some TCP
components have changed. To aid clarity, this section collects these components have changed. To aid clarity, this section collects these
semantic changes as a reference. semantic changes as a reference.
Sequence number: The (in-header) TCP sequence number is specific to Sequence number: The (in-header) TCP sequence number is specific to
the subflow. To allow the receiver to reorder application data, the subflow. To allow the receiver to reorder application data,
an additional data-level sequence space is used. In this data- an additional data-level sequence space is used. In this data-
level sequence space, the initial SYN and the final DATA_FIN level sequence space, the initial SYN and the final DATA_FIN
skipping to change at page 58, line 35 skipping to change at page 62, line 38
presence of the SYN flag. presence of the SYN flag.
MPTCP SYN packets on the first subflow of a connection contain the MPTCP SYN packets on the first subflow of a connection contain the
MP_CAPABLE option (Section 3.1). If this is dropped, MPTCP SHOULD MP_CAPABLE option (Section 3.1). If this is dropped, MPTCP SHOULD
fall back to regular TCP. If packets with the MP_JOIN option fall back to regular TCP. If packets with the MP_JOIN option
(Section 3.2) are dropped, the paths will simply not be used. (Section 3.2) are dropped, the paths will simply not be used.
If a middlebox strips options but otherwise passes the packets If a middlebox strips options but otherwise passes the packets
unchanged, MPTCP will behave safely. If an MP_CAPABLE option is unchanged, MPTCP will behave safely. If an MP_CAPABLE option is
dropped on either the outgoing or the return path, the initiating dropped on either the outgoing or the return path, the initiating
host can fall back to regular TCP, as illustrated in Figure 18 and host can fall back to regular TCP, as illustrated in Figure 22 and
discussed in Section 3.1. discussed in Section 3.1.
Subflow SYNs contain the MP_JOIN option. If this option is stripped Subflow SYNs contain the MP_JOIN option. If this option is stripped
on the outgoing path, the SYN will appear to be a regular SYN to Host on the outgoing path, the SYN will appear to be a regular SYN to Host
B. Depending on whether there is a listening socket on the target B. Depending on whether there is a listening socket on the target
port, Host B will reply either with SYN/ACK or RST (subflow port, Host B will reply either with SYN/ACK or RST (subflow
connection fails). When Host A receives the SYN/ACK it sends a RST connection fails). When Host A receives the SYN/ACK it sends a RST
because the SYN/ACK does not contain the MP_JOIN option and its because the SYN/ACK does not contain the MP_JOIN option and its
token. Either way, the subflow setup fails, but otherwise does not token. Either way, the subflow setup fails, but otherwise does not
affect the MPTCP connection as a whole. affect the MPTCP connection as a whole.
skipping to change at page 59, line 23 skipping to change at page 63, line 23
Host A Host B Host A Host B
| SYN(MP_CAPABLE) | | SYN(MP_CAPABLE) |
|------------------------------------>| |------------------------------------>|
| Middlebox M | | Middlebox M |
| | | | | |
| SYN/ACK |SYN/ACK(MP_CAPABLE)| | SYN/ACK |SYN/ACK(MP_CAPABLE)|
|<----------------|-------------------| |<----------------|-------------------|
b) MP_CAPABLE option stripped on return path b) MP_CAPABLE option stripped on return path
Figure 18: Connection Setup with Middleboxes that Strip Options from Figure 22: Connection Setup with Middleboxes that Strip Options from
Packets Packets
We now examine data flow with MPTCP, assuming the flow is correctly We now examine data flow with MPTCP, assuming the flow is correctly
set up, which implies the options in the SYN packets were allowed set up, which implies the options in the SYN packets were allowed
through by the relevant middleboxes. If options are allowed through through by the relevant middleboxes. If options are allowed through
and there is no resegmentation or coalescing to TCP segments, and there is no resegmentation or coalescing to TCP segments,
Multipath TCP flows can proceed without problems. Multipath TCP flows can proceed without problems.
The case when options get stripped on data packets has been discussed The case when options get stripped on data packets has been discussed
in the Fallback section. If a fraction of options are stripped, in the Fallback section. If a fraction of options are stripped,
skipping to change at page 64, line 48 skipping to change at page 68, line 48
indicating the desired codepoint and providing a point of contact. A indicating the desired codepoint and providing a point of contact. A
short description or acronym for the use is desired but should not be short description or acronym for the use is desired but should not be
required. required.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
Iyengar, "Architectural Guidelines for Multipath TCP Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
<http://www.rfc-editor.org/info/rfc6182>. <https://www.rfc-editor.org/info/rfc6182>.
[SHS] National Institute of Science and Technology, "Secure Hash [SHS] National Institute of Science and Technology, "Secure Hash
Standard", Federal Information Processing Standard Standard", Federal Information Processing Standard
(FIPS) 180-4, August 2015, (FIPS) 180-4, August 2015,
<http://nvlpubs.nist.gov/nistpubs/FIPS/ <http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>. NIST.FIPS.180-4.pdf>.
9.2. Informative References 9.2. Informative References
[howhard] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M., [howhard] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M.,
skipping to change at page 65, line 41 skipping to change at page 69, line 41
[norm] Handley, M., Paxson, V., and C. Kreibich, "Network [norm] Handley, M., Paxson, V., and C. Kreibich, "Network
Intrusion Detection: Evasion, Traffic Normalization, and Intrusion Detection: Evasion, Traffic Normalization, and
End-to-End Protocol Semantics", Usenix Security 2001, End-to-End Protocol Semantics", Usenix Security 2001,
2001, 2001,
<http://www.usenix.org/events/sec01/full_papers/handley/ <http://www.usenix.org/events/sec01/full_papers/handley/
handley.pdf>. handley.pdf>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, DOI 10.17487/RFC1323, May for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
1992, <http://www.rfc-editor.org/info/rfc1323>. 1992, <https://www.rfc-editor.org/info/rfc1323>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996, DOI 10.17487/RFC2018, October 1996,
<http://www.rfc-editor.org/info/rfc2018>. <https://www.rfc-editor.org/info/rfc2018>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2979] Freed, N., "Behavior of and Requirements for Internet [RFC2979] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000,
<http://www.rfc-editor.org/info/rfc2979>. <https://www.rfc-editor.org/info/rfc2979>.
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000,
<http://www.rfc-editor.org/info/rfc2992>. <https://www.rfc-editor.org/info/rfc2992>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001, DOI 10.17487/RFC3022, January 2001,
<http://www.rfc-editor.org/info/rfc3022>. <https://www.rfc-editor.org/info/rfc3022>.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135, Mitigate Link-Related Degradations", RFC 3135,
DOI 10.17487/RFC3135, June 2001, DOI 10.17487/RFC3135, June 2001,
<http://www.rfc-editor.org/info/rfc3135>. <https://www.rfc-editor.org/info/rfc3135>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<http://www.rfc-editor.org/info/rfc4987>. <https://www.rfc-editor.org/info/rfc4987>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<http://www.rfc-editor.org/info/rfc5681>. <https://www.rfc-editor.org/info/rfc5681>.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961, Robustness to Blind In-Window Attacks", RFC 5961,
DOI 10.17487/RFC5961, August 2010, DOI 10.17487/RFC5961, August 2010,
<http://www.rfc-editor.org/info/rfc5961>. <https://www.rfc-editor.org/info/rfc5961>.
[RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for
Multipath Operation with Multiple Addresses", RFC 6181, Multipath Operation with Multiple Addresses", RFC 6181,
DOI 10.17487/RFC6181, March 2011, DOI 10.17487/RFC6181, March 2011,
<http://www.rfc-editor.org/info/rfc6181>. <https://www.rfc-editor.org/info/rfc6181>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled
Congestion Control for Multipath Transport Protocols", Congestion Control for Multipath Transport Protocols",
RFC 6356, DOI 10.17487/RFC6356, October 2011, RFC 6356, DOI 10.17487/RFC6356, October 2011,
<http://www.rfc-editor.org/info/rfc6356>. <https://www.rfc-editor.org/info/rfc6356>.
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
2012, <http://www.rfc-editor.org/info/rfc6528>. 2012, <https://www.rfc-editor.org/info/rfc6528>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>. <https://www.rfc-editor.org/info/rfc6824>.
[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application
Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, Interface Considerations", RFC 6897, DOI 10.17487/RFC6897,
March 2013, <http://www.rfc-editor.org/info/rfc6897>. March 2013, <https://www.rfc-editor.org/info/rfc6897>.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", [RFC6994] Touch, J., "Shared Use of Experimental TCP Options",
RFC 6994, DOI 10.17487/RFC6994, August 2013, RFC 6994, DOI 10.17487/RFC6994, August 2013,
<http://www.rfc-editor.org/info/rfc6994>. <https://www.rfc-editor.org/info/rfc6994>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.
[TCPLO] Ramaiah, A., "TCP option space extension", Work [TCPLO] Ramaiah, A., "TCP option space extension", Work
in Progress, March 2012. in Progress, March 2012.
Appendix A. Notes on Use of TCP Options Appendix A. Notes on Use of TCP Options
The TCP option space is limited due to the length of the Data Offset The TCP option space is limited due to the length of the Data Offset
field in the TCP header (4 bits), which defines the TCP header length field in the TCP header (4 bits), which defines the TCP header length
in 32-bit words. With the standard TCP header being 20 bytes, this in 32-bit words. With the standard TCP header being 20 bytes, this
leaves a maximum of 40 bytes for options, and many of these may leaves a maximum of 40 bytes for options, and many of these may
skipping to change at page 71, line 46 skipping to change at page 75, line 46
is expected on the subflow. This state variable is modified upon is expected on the subflow. This state variable is modified upon
reception of in-order segments. The value of RCV.NXT is copied to reception of in-order segments. The value of RCV.NXT is copied to
the SEG.ACK field of the next segments transmitted on the subflow. the SEG.ACK field of the next segments transmitted on the subflow.
RCV.WND (32 bits with RFC 1323, 16 bits otherwise): This is the RCV.WND (32 bits with RFC 1323, 16 bits otherwise): This is the
subflow-level receive window that is updated with the window field subflow-level receive window that is updated with the window field
from the segments received on this subflow. from the segments received on this subflow.
Appendix C. Finite State Machine Appendix C. Finite State Machine
The diagram in Figure 19 shows the Finite State Machine for The diagram in Figure 23 shows the Finite State Machine for
connection-level closure. This illustrates how the DATA_FIN connection-level closure. This illustrates how the DATA_FIN
connection-level signal (indicated as the DFIN flag on a DATA_ACK) connection-level signal (indicated as the DFIN flag on a DATA_ACK)
interacts with subflow-level FINs, and permits "break-before-make" interacts with subflow-level FINs, and permits "break-before-make"
handover between subflows. handover between subflows.
+---------+ +---------+
| M_ESTAB | | M_ESTAB |
+---------+ +---------+
M_CLOSE | | rcv DATA_FIN M_CLOSE | | rcv DATA_FIN
------- | | ------- ------- | | -------
skipping to change at page 72, line 32 skipping to change at page 76, line 32
| rcv DATA_FIN -------------- | -------------- | | rcv DATA_FIN -------------- | -------------- |
| ------- CLOSE all subflows | CLOSE all subflows | | ------- CLOSE all subflows | CLOSE all subflows |
| snd DATA_ACK[DFIN] V delete MPTCP PCB V | snd DATA_ACK[DFIN] V delete MPTCP PCB V
\ +-----------+ +---------+ \ +-----------+ +---------+
------------------------>|M_TIME WAIT|----------------->| M_CLOSED| ------------------------>|M_TIME WAIT|----------------->| M_CLOSED|
+-----------+ +---------+ +-----------+ +---------+
All subflows in CLOSED All subflows in CLOSED
------------ ------------
delete MPTCP PCB delete MPTCP PCB
Figure 19: Finite State Machine for Connection Closure Figure 23: Finite State Machine for Connection Closure
Authors' Addresses Authors' Addresses
Alan Ford Alan Ford
Pexip Pexip
EMail: alan.ford@gmail.com EMail: alan.ford@gmail.com
Costin Raiciu Costin Raiciu
University Politehnica of Bucharest University Politehnica of Bucharest
 End of changes. 51 change blocks. 
85 lines changed or deleted 275 lines changed or added

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