Code change:
is running out of resources.  In these cases, MPTCP should send the MP_FASTCLOSE.  This option is illustrated in tcpm_fastclose. <del> If Host A wants to force the closure of an MPTCP connection, the MPTCP Fast Close procedure is as follows: </del> <ins> If Host A wants to force the closure of an MPTCP connection, it has two different options: </ins> <del> 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. </del> <ins> 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. </ins> <del> 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). </del> <ins> 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. If a host receives a packet with a valid MP_FASTCLOSE option, it shall process it as follows : 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). </ins> As soon as Host A has received the TCP RST on the remaining subflow, it can close this subflow and tear down the whole

Related discussion:
text: Adding Olivier's proposed text about the Fast-Close (cfr., URL) and integrated a shorter version of URL 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 FASTCLOSE option that was triggered by Francois. The current text of RFC6824bis uses the FASTCLOSE 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 FASTCLOSE inside ACK or RST while a receiver must be ready to process both. Changes are marked with Fast Close Regular TCP has the means of sending a reset (RST) signal to abruptly close a connection. With MPTCP, a reguler 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 MPFASTCLOSE option. MPFASTCLOSE is used to indicate to the peer that the connection will be abruptly closed and no data will be accepted anymore. The reasons for triggering an MPFASTCLOSE are implementation specific. Regular TCP does not allow sending a RST while the connection is in a synchronized state [RFC0793]. Nevertheless, implementations allow the sending of a RST in this state, if, for example, the operating system is running out of resources. In these cases, MPTCP should send the MPFASTCLOSE. This option is illustrated in Figure 14.