MP_FASTCLOSE support (send part remaining)

[matttbe]

As defined in RFC8684:

Regular TCP has the means of sending a RST signal to abruptly close a connection. With MPTCP, a regular RST only has the scope of the subflow; it will only close the applicable subflow and will 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; this is done via the MP_FASTCLOSE option.

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 for triggering an MP_FASTCLOSE are implementation specific. Regular TCP does not allow the sending of 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 MP_FASTCLOSE. This option is illustrated in Figure 14.

                      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
 +---------------+---------------+-------+-----------------------+
 |     Kind      |    Length     |Subtype|      (reserved)       |
 +---------------+---------------+-------+-----------------------+
 |                      Option Receiver's Key                    |
 |                            (64 bits)                          |
 |                                                               |
 +---------------------------------------------------------------+

Figure 14: Fast Close (MP_FASTCLOSE) Option

If Host A wants to force the closure of an MPTCP connection, it can do so via two options:

• 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.
• 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 down the subflows and the connection immediately.

If Host A decides to force the closure by using Option A and sending an ACK with the MP_FASTCLOSE option, the connection shall proceed as follows:

• Upon receipt of an ACK with MP_FASTCLOSE by Host B, containing the valid key, Host B answers on the same subflow with a TCP RST and tears down all subflows also through sending TCP RST signals. Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state).
• As soon as Host A has received the TCP RST on the remaining subflow, it can close this subflow and tear down the whole connection (transition from FASTCLOSE_WAIT state to CLOSED state). If Host A receives an MP_FASTCLOSE instead of a TCP RST, both hosts attempted fast closure simultaneously. Host A should reply with a TCP RST and tear down the connection.
• 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. To keep this connection from being retained for a long time, the number of retransmissions SHOULD be limited; 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.

If, however, Host A decides to force the closure by using Option R and sending a RST with the MP_FASTCLOSE option, Host B will act as follows: upon receipt of a RST with MP_FASTCLOSE, containing the valid key, Host B tears down all subflows by sending a TCP RST. Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state).

https://www.rfc-editor.org/rfc/rfc8684.html#name-fast-close

If needed, new tickets can be created to track: receiver/sender side only and packetdrill support.

Note: there is a difference with MPTCPv0: https://www.rfc-editor.org/rfc/rfc8684.html#section-appendix.e-2.11

This document describes an additional way of performing a Fast Close -- by sending an MP_FASTCLOSE option on a RST on all subflows. This allows the host to tear down the subflows and the connection immediately.

mptcp.org implementation only support the other way. It is not recommended to support the other way not to create a new TCP status to be able to retransmit the MP_FASTCLOSE.

• Kernel: parse and act on incoming FASTCLOSE
• Kernel: send MP_FASTCLOSE
• Packetdrill tests incoming FC
• Packetdrill tests outgoing FC

(Feature from the initial roadmap)

[matttbe]

Florian is looking at this

[matttbe]

The receive side support has been added by Florian in the repository, see patches:

• 6766eaf: mptcp: hold mptcp socket before calling tcp_done
• 37a5360: tcp: parse mptcp options contained in reset packets
• 0b9d6f3: mptcp: parse and act on incoming FASTCLOSE option

[geliangtang]

"Kernel: send MP_FASTCLOSE" has done by Paolo's commit f284c0c ("mptcp: implement fastclose xmit path").
And a self test for incoming and outgoing FASTCLOSE has added by Geliang's commit 01542c9 ("selftests: mptcp: add fastclose testcase").

[matttbe]

The remaining point is:

Packetdrill tests for outgoing Fast Close

I guess I should better create a new ticket, right?

[matttbe]

I guess I should better create a new ticket, right?

Done: #273