Code change:
performing subflows or subflows that regularly fail during use, in order to temporarily choose not to use these paths. <ins> 3.11. 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. 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: 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. 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). 3.11.2. 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. 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 fig_tfocookie.  This is done by simply combining the TFO and MPTCP options. 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. 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. 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. </ins> 4. In order to support multipath operation, the semantics of some TCP

Related discussion:
text: 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 MPFASTCLOSE option itself when it releases state in order to clear any remaining state at middleboxes. o Upon receipt of a RST with MPFASTCLOSE, 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). The burden of the MP_FASTCLOSE is on the host that decides to close the connection (typically the server, but not necessarily). The text above allows it to opt for either ACK or RST without adding complexity to the other side. Another point that might be discussed in RFC6824bis is how a host should react when there are all the subflows associates to a Multipath TCP connection are in the CLOSED state, but the connection is still alive. At this point, it is impossible to send or receive data over the connection. It should attempt to reestablish one subflow to keep the connection alive. Olivier