Subject: [multipathtcp] Connection management

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 06 Dec 2011 21:33:50 +0100

Hello,

Based on the discussions that we had recently concerning the abrupt
release of an MPTCP connection, I think that we should also have in the
MPTCP draft a short discussion on the maintenance of an MPTCP
connection. By maintenance, how should an MPTCP implementation react if
the subflows that it uses are RST ?

A first approach could be the following state machine

                    no subflow
               --------->----------------
   ESTABLISHED                              WAITING*
        |      <-------------------------      |
	|           one subflow                |
	|                                     /
     ABRUPT	                            /
     CLOSING                              /
        |                               /
        |                             /   Timeout
        |                           /
     CLOSED -----------------------+

MPTCP would enter the FSM state once one subflow has been established.
In this state, MPTCP may decide to add or remove subflows to the MPTCP
connection based e.g. on the achieved performance or other
implementation-dependant criteria.

MPTCP would enter the WAITING state if there is no active subflow for
the MPTCP connection. For this transition, do we want to distinguish
between subflows that have been terminated by using FINs and subflows
terminated by using RST ?

In the WAITING state, MPTCP should try to reestablish new subflows in an
implementation dependant manner.

MPTCP would enter the ESTABLISHED state as soon as one subflow has been
reestablished.

The WAITING state should be protected by an implementation dependant
timeout and enter the CLOSED state if there are no subflows anymore.

The transitions to and from the ABRUPT_CLOSING state is the ongoing
discussion.

In the CLOSED state, MPTCP can release state related to the MPTCP
connection.

Olivier

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Thu, 8 Dec 2011 06:43:04 -0600

Hi Olivier, all,

I agree that the draft should elaborate on this matter. In break-before-make scenarios, for instance, it is very likely that a middlebox resets the old subflow before the new one is established. How is this different from situations where the RST is not sent?

Here is my take on such situations:

We should pursue a philosophy of clean protocol layer separation. This means that the connection level should see no principal difference between "no-subflow-up" and "no end-to-end conductivity".

Therefore, MPTCP connection behavior to "no end-to-end conductivity" or "no-subflow-up" should be the same as "no end-to-end conductivity" for conventional TCP connections. Conventional TCP connections either hang in until the application closes or they send keepalives when those are activated via socket options.

If such keepalives are activated, MPTCP can send them along all available subflows. The "no-subflow-up" scenario is equivalent to no-subflow-conductivity where the keepalives timeout after some time interval. Hence the same timeout interval should be applied to "no-subflow-up".

Subflow management in case of "no subflow connectivity" should be outside the scope of the standard.

Regards,

Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Olivier Bonaventure
Sent: Tuesday, December 06, 2011 3:34 PM
To: multipathtcp
Subject: [multipathtcp] Connection management

Hello,

                    no subflow

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