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

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

Return-Path: <cpaasch@apple.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD4D1294FE for <multipathtcp@ietfa.amsl.com>; Mon, 13 Mar 2017 09:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF8RLL83kLwC for <multipathtcp@ietfa.amsl.com>; Mon, 13 Mar 2017 09:00:55 -0700 (PDT)
Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484891297E7 for <multipathtcp@ietf.org>; Mon, 13 Mar 2017 09:00:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1489420849; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Kfz8s7MkSVm65lalG8KdxSujzrpSftwq2HgOxr43dnw=; b=aE+tLyfA5MqSDottfxkaeU09APstevNuf3TV2hI+BFU8ZiVo/NvO/RzTDTC5kQWG Z+Ug3GfeRNZP3S9QPhMbEEBbOJ7daGtmuvimVjRWNcAtFmeEuDD7v2CXVAfkkZuk /kQgWD9juW17usVSPPYBSKMvVl4gGtKLS4Gt9tnS0QN6TTVVV40JXmZqG8/h0oKh X0EJKuXwzdeMaVfCxDs4EUOi9WPAuSA5qBGITOVm9va+fXAsGA6bHAV5VPGzs5jS T0/6GUWKAE6NunxnOTfzkhcfPkJQdRVsxQC6/CjjEUwysbufBFzY8jFyeJWdl3Jh YfKrXMeV8W764pH9qDBwkA==;
Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id C4.F5.01140.032C6C85; Mon, 13 Mar 2017 09:00:49 -0700 (PDT)
X-AuditID: 11ab0219-e38b39a000000474-33-58c6c230fa25
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay4.apple.com (Apple SCV relay) with SMTP id D6.22.29758.032C6C85; Mon, 13 Mar 2017 09:00:48 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-disposition: inline
Content-type: text/plain; charset=utf-8
Received: from localhost ([17.153.59.193]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OMR0063WGHC7B00@nwk-mmpp-sz12.apple.com>; Mon, 13 Mar 2017 09:00:48 -0700 (PDT)
Sender: cpaasch@apple.com
Date: Mon, 13 Mar 2017 09:00:53 -0700
From: Christoph Paasch <cpaasch@apple.com>
To: =?utf-8?B?546L5biF?= <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)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FAYrmt46FiEQd9pfot7O9vZLT6vvs7m wOSxbOcGVo8lS34yBTBFcdmkpOZklqUW6dslcGXc3N7HXNDNUfH61GnmBsZVbF2MnBwSAiYS zx49Y+9i5OIQEtjHKHH+Zx87TGLzg3esEIlDjBITrn5jAUnwCghK/Jh8D8jm4GAWkJc4cikb JMwsIC3x6O8MdoiwusSUKbkQrY1MEqvvvQZbJiwgKdF95w4ziM0ioCqx4NVssJFsAloSb2+3 s4LYIgL6Ep1bZjJDzJSUWPH3EytEr6vEz1UfGSFOMJB42z0NrEZIwE3i2IKJYDdzCrhLvFuz CiwuKqAs8fcwyJlcQL9MYZNY37KVeQKjyCwkL8xCeGEWkhdmIbywgJFlFaNwbmJmjm5mnpGp XmJBQU6qXnJ+7iZGUCSsZpLcwfj1teEhRgEORiUe3hvzjkUIsSaWFVfmHmKU5mBREuc9M+Vw hJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGxs8Pwhu2Wax63zvxNrff+Qt3m2/+fd68eWZu xU+njN06ix9l8wqatAn1O3gdW1f4R9vUZNbUtL27P2jIfsziPJ/lPG8947Sqvrz/t1qsqtSl tr8UnVcU8GH5Zx2Gz48Uc19cKNLZt1ft8imhNQftHEUtb/63NLiwI6z837S1cx55BO1bsbf4 qRJLcUaioRZzUXEiAFeftdxlAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUi2FB8Rtfg0LEIgwW7jS3u7Wxnt/i8+jqb A5PHsp0bWD2WLPnJFMAUxWWTkpqTWZZapG+XwJVxc3sfc0E3R8XrU6eZGxhXsXUxcnJICJhI bH7wjrWLkYtDSOAQo8SEq99YQBK8AoISPybfA7I5OJgF5CWOXMoGCTMLSEs8+juDHSKsLjFl Si5EayOTxOp7r8FmCgtISnTfucMMYrMIqEoseDUbbCSbgJbE29vtrCC2iIC+ROeWmcwQMyUl Vvz9xArR6yrxc9VHRogTDCTedk8DqxEScJM4tmAiO4jNKeAu8W7NKrC4qICyxN/D91gmMArO QnL1LISrZyG5ehbC1QsYWVYxChSl5iRWmuglFhTkpOol5+duYgSHbWH4DsZ/y6wOMQpwMCrx 8N6YdyxCiDWxrLgyFxhCHMxKIrzv9wCFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8+rMOhwhJJCe WJKanZpakFoEk2Xi4JRqYLyRdCn3YsifunO7F1ztbxH+VBDt9XPaPwb5H08K5zCEnLl0z8o5 ziVTuvS76W4lNUuD/TvqmKQC9/my7BMIlma8mSuwd/PGJzd15B9N7N35wr/Y85dc+ctdvKs/ bfdee1O+9ujV2ZdKpStdZYzleb/pv/Oqex0U1HNh4VLOxtMXWLabvtu15ZoSS3FGoqEWc1Fx IgC3B2j+VwIAAA==
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
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Mar 2017 16:00:56 -0000

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