Re: [multipathtcp] MPTCP FAST_CLOSE

[Yoshifumi Nishida <[e-mail]>]

On Tue, Nov 14, 2017 at 3:12 AM, Alan Ford <[e-mail]> wrote:

> Hi Olivier,
>
> Can you clarify what issue we are trying to solve here? Is this a purely a
> matter of shutting down a connection rapidly without maintaining state?
>
> The minimum to be compliant as written requires RSTing every subflow bar
> one, then sending MP_FASTCLOSE on one subflow. The retransmit is only a
> SHOULD, so you could theoretically RST that subflow after a RTO too. Or is
> that RTO still too much to keep?
>
> I don’t have an issue with adding this methodology - it does not require
> any significant changes, just specifies how to behave when receiving RST +
> MP_FASTCLOSE.
>
> The acknowledged model was designed so that it was less likely that any
> state would be left at middleboxes and at the client. This does not ensure
> it was received at the client so in theory the client could sit there not
> knowing the connection had gone away. However, this is no worse than
> regular TCP so I don’t immediately see any problems here.
>
> I think there're situations where it get worse than regular TCP.
When the client send some data to the server due to new data or
retransmission, the server will respond with reset,which make the client
realize the connection has already gone.
However, in case of mptcp, even the client receives reset, it cannot be
sure if the mptcp session has gone or not.

--
Yoshi