Re: [multipathtcp] some questions about the closure of MPTCP

Christoph Paasch <cpaasch@apple.com> Mon, 13 March 2017 16:00 UTC

MIME-version: 1.0
Content-transfer-encoding: 8bit
Content-disposition: inline
Content-type: text/plain; charset="utf-8"
Sender: cpaasch@apple.com
Date: Mon, 13 Mar 2017 09:00:53 -0700
From: Christoph Paasch <cpaasch@apple.com>
To: 王帅 <13211134@bjtu.edu.cn>
Message-id: <20170313160053.GT6373@Chimay.local>
References: <34c9721e.38e9c.15ac6ddcba0.Coremail.13211134@bjtu.edu.cn>
In-reply-to: <34c9721e.38e9c.15ac6ddcba0.Coremail.13211134@bjtu.edu.cn>
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/G-XFWX0M5YtwOs-0m4YD3PRt2pE>
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] some questions about the closure of MPTCP
Precedence: list

Hello,

On 13/03/17 - 16:51:48, 王帅 wrote:
> Hi,
> 
>      I am doing a project about MPTCP, but I have some questions about the closure of MPTCP.
>      Why does the closure of subflows need FIN?  Is it necessary and compulsory?  When the sender has sent DATA_FIN to the receiver and received DATA_ACK from the receiver, doesn't the data have been transferred from the sender to the receiver completely? So, I wonder whether we can terminate all subflows by sending RST? It will be faster than the FIN, and it can free resources.

in theory you are right that the FIN in this scenario is no more needed for
the correctness of the data-stream.

However, this will also mean that if the RST got lost, there is a subflow on
the peer's side that will stay there for quite some time.
And it will not allow for re-use of the 5-tuple for a later connection in
that case.

So it probably depends on what you want. A RST is quick, but FINs are more
deterministic because they are retransmitted when lost.

Christoph

[multipathtcp] some questions about the closure o… 王帅
Re: [multipathtcp] some questions about the closu… Christoph Paasch