Subject: [multipathtcp] MPTCP connection termination

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 31 Oct 2011 10:55:59 +0100

Hello,

During the last telco, we discussed briefly about the problem of
terminating an MPTCP connection.

Regular TCP supports two mechanisms to terminate a connection :
- graceful release with the utilisation of the FIN flags
- abrupt release with the utilisation of the RST flag

The current MPTCP draft supports the graceful release with the
utilisation of the DATA_FIN flags, but there is no equivalent of an
abrupt release since the reception of a segment with the RST flag on a
subflow only causes this particular subflow to be released and not the
entire MPTCP connection.

There are some applications, notably busy web servers, that abuse the
utilisation of the RST flag in order to avoid entering in the CLOSE_WAIT
state. A typical TCP connection with such as web server would end with a
RST after all data sent by the server has been acknowledged by the client.

MPTCP servers could probably also benefit from the ability to be able to
release an MPTCP connection (and the underlying subflows) without having
to maintain state in CLOSE_WAIT. The design of MPTCP is an opportunity
to solve this problem in a cleaner way than by abusing with the RST flag.

Our objective with this proposed modification is to allow the passive
opener (i.e. the host that received the first SYN segment) to close the
MPTCP connection without having to maintain any CLOSE_WAIT state. We
only allow the passive opener is allowed to close the connection this
way to avoid having to introduce a more complex state machine to deal
with collisions when the two hosts try to close the MPTCP connection at
the same time. We believe that avoiding CLOSE_WAIT is mainly of benefit
for the passive opener.

The proposed solution relies on an additional bit, let us call it the R
bit in the DSS option :

                          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) |F|m|M|a|A|
     +---------------+---------------+-------+----------------------+
     |           Data ACK (4 or 8 octets, depending on flags)       |
     +--------------------------------------------------------------+
     |   Data Sequence Number (4 or 8 octets, depending on flags)   |
     +--------------------------------------------------------------+
     |              Subflow Sequence Number (4 octets)              |
     +-------------------------------+------------------------------+
     |  Data-level Length (2 octets) |      Checksum (2 octets)     |
     +-------------------------------+------------------------------+

                Figure 9: Data Sequence Signal (DSS) option

The R bit can only be set when the F bit is set. If the R bit is clear,
then the DSS option that contains the F bit is a regular DATA_FIN that
is processed as explained in the current draft.

When sending a DSS with the F bit set, the passive opener, and only the
passive opener, can add the R bit to indicate that it requests the MPTCP
connection to be released but it does not want to maintain any
CLOSE_WAIT state. The DSS with both bits F and R set contains the
following information :
 - the last data sequence number that was sent by the passive opener.
The DATA_FIN+R indicates that the seerver will not send data beyond this
data sequence number
- the data acknowledgement number that corresponds to the last data that
was correctly received in sequence. The transmission of the DATA_FIN+R
indicates that the server will not accept new data from the client
beyond this data acknowledgement number

Upon reception of a DATA_FIN+R, the client should stop sending any new
data. When the DATA_FIN+R is acknowledged, the client should enter a
CLOSE_WAIT for the MPTCP connection and the server can send a RST on all
subflows to allow middleboxes to remove subflow state.

Note that this proposal is slightly different from the current
utilisation of RST on web servers. With regular TCP, web servers would
send all data, wait for the last ack and then send a RST to close the
connection. With DATA_FIN+R, a MPTCP server could send all data and then
immediately send a DATA_FIN+R after the last data. The reception of the
ack for the DATA_FIN+R will indicate that the data has been received
correctly and the MPTCP connection can be closed (and the RST will be
sent only to remove state in the middleboxes).

Let me know whether you agree with this proposed approach

Olivier

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Mon, 31 Oct 2011 09:06:50 -0500

Hi Oliver, all,

I think the introduction of a MP RST flag makes perfect sense. 

However, I wouldn't restrict this flag to the passive opener since such a restriction relies on certain assumptions about the application type (i.e. client-server content retrieval). In P2P applications, for instance, either side of the connection may decide to "hang up". Also for content upload, the client could the one who sends MP RST. Even for client-based content retrieval, MP RST could be sent by the client () when the user forcefully interrupts the application.

I'm not certain I fully understand the complexity of R+F-flag signaling. Why can't the MP RST signaling follow along the same lines as TCP RST for conventional TCP connections? MP RST by itself would simply mean: "Tear down this MP connection" and the receiver would act upon it in any state. What am I missing here?

Thanks.

Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Olivier Bonaventure
Sent: Monday, October 31, 2011 5:56 AM
To: multipathtcp
Subject: [multipathtcp] MPTCP connection termination

Hello,

                          1                   2                   3

Olivier
_______________________________________________
multipathtcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multipathtcp