Draft: draft-ietf-mptcp-rfc6824bis-10

Commentary: Adding Olivier 's proposed text about the Fast - Close ( cfr . , ) and integrated a shorter version of
Mailing list commentary: Hello , Sorry for being late with this , but the beginning of the fall semester is always too busy for me . During the summer , there was a discussion on the option that was triggered by Francois . The current text of RFC6824bis uses the option inside ACK packets , but deployment experience has shown that this results in additional complexity since the ACK must be retransmitted to ensure its reliable delivery . Here is a proposed update for section 3.5 that allows a sender to either send inside ACK or RST while a receiver must be ready to process both . Changes are marked with
Paragraph (version A):
The initial SYN, containing just the MP_CAPABLE header, is used to
define the version of MPTCP beign requested, as well as exchanging
flags to negotiate connection features, described later.
Paragraph (version B):
The initial SYN, containing just the MP_CAPABLE header, is used to
define the version of MPTCP being requested, as well as exchanging
flags to negotiate connection features, described later.
Paragraph (version A):
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
subflow and will only close the concerned subflow but not affect the
remaining subflows.  MPTCP's connection will stay alive at the data
level, in order to permit break-before-make handover between
subflows.  It is therefore necessary to provide an MPTCP-level
"reset" to allow the abrupt closure of the whole MPTCP connection,
and this is the MP_FASTCLOSE option.
Paragraph (version B):
Regular TCP has the means of sending a reset (RST) signal to abruptly
close a connection.  With MPTCP, a regular RST only has the scope of
the subflow and will only close the concerned subflow but not affect
the remaining subflows.  MPTCP's connection will stay alive at the
data level, in order to permit break-before-make handover between
subflows.  It is therefore necessary to provide an MPTCP-level
"reset" to allow the abrupt closure of the whole MPTCP connection,
and this is the MP_FASTCLOSE option.
Paragraph (version A):
Host A sends an ACK containing the MP_FASTCLOSE option on one
subflow, containing the key of Host B as declared in the initial
connection handshake.  On all the other subflows, Host A sends a
regular TCP RST to close these subflows, and tears them down.
Host A now enters FASTCLOSE_WAIT state.
Paragraph (version A):
Upon receipt of an 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).
Paragraph (version B):
Option A (ACK) : Host A sends an ACK containing the MP_FASTCLOSE
option on one subflow, containing the key of Host B as declared in
the initial connection handshake.  On all the other subflows, Host
A sends a regular TCP RST to close these subflows, and tears them
down.  Host A now enters FASTCLOSE_WAIT state.
Paragraph (version B):
Option R (RST) : Host A sends a RST containing the MP_FASTCLOSE
option on all subflows, containing the key of Host B as declared
in the initial connection handshake.  Host A can tear the subflows
and the connection down immediately.
Paragraph (version B):
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).
Paragraph (version A):
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
where the MPTCP_RST has been sent), it SHOULD retransmit the
MP_FASTCLOSE.  The number of retransmissions SHOULD be limited to
avoid this connection from being retained for a long time, but
this limit is implementation specific.  A RECOMMENDED number is 3.
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
state at middleboxes.
Paragraph (version B):
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
where the MP_FASTCLOSE has been sent), it SHOULD retransmit the
MP_FASTCLOSE.  The number of retransmissions SHOULD be limited to
avoid this connection from being retained for a long time, but
this limit is implementation specific.  A RECOMMENDED number is 3.
If no TCP RST is received in response, Host A SHOULD send a TCP
RST with the MP_FASTCLOSE option itself when it releases state in
order to clear any remaining state at middleboxes.
Paragraph (version B):
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).
Paragraph (version B):
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.
Paragraph (version B):
When using TCP Fast Open in conjunction with MPTCP, there are two key
points to take into account, detailed hereafter.
Paragraph (version B):
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).
Paragraph (version B):
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.
Paragraph (version B):
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 app_options).
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
The following shows a few examples of possible TFO+MPTCP
establishment scenarios.
Paragraph (version B):
Before a client can send data together with the SYN, it must request
a cookie to the server, as shown in Figure fig_tfocookie.  This is
done by simply combining the TFO and MPTCP options.
Paragraph (version B):
Once this is done, the received cookie can be used for TFO, as shown
in Figure fig_tfodata.  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 tfodata.
Paragraph (version B):
In Figure fig_tfofallback, 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.
Paragraph (version B):
It is also possible that the server acknowledges only part of the TFO
data, as illustrated in Figure fig_tfopartial.  The client will
simply retransmit the missing data together with a DSS-mapping.