IETF Logo Mail Archive

Re: [multipathtcp] q about remove addr behavior

Christoph Paasch <cpaasch@apple.com> Thu, 22 June 2017 07:15 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 BBE38129B08 for <multipathtcp@ietfa.amsl.com>; Thu, 22 Jun 2017 00:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 HDaUUlIwnF2j for <multipathtcp@ietfa.amsl.com>; Thu, 22 Jun 2017 00:14:59 -0700 (PDT)
Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (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 C0ADC1296C9 for <multipathtcp@ietf.org>; Thu, 22 Jun 2017 00:14:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1498115698; 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=RUMUCvg+XmrNgx9ZOYi9hFzGt4Rojbfqe8Wry0zgByY=; b=GJGEV/5IozI4FpqMt+eRW30DGH+DqykX5IYXDkD50w+jVit0cRydQMVAfDQ15Pj9 JHt6B1hiaUzEKO7p62WOBPqOhtHIAKz5WUu6+diN60Y7Q+cXy0pGdHAApl2C/mVA yFtbcKuQ2hBffCC1MLCpBQyj0XDqwY+8kuI90pIcpdEOIqLbywHc6GUpUf7BM9UV 7C73EIEEQ3vOPWlutcGzVHi9sqAV1Aqb29lce3x0JdUeU5y0LbbsveCSZddhM0L6 8uG+F8cH/qidhVhsr/1gCTE4Uq5Aku/0hRCvc8aiU9KOkBb1tGRNnRjJpZoZAqM3 zBkV09sCZyjzCZjz7iEhRA==;
Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id 15.75.03314.27E6B495; Thu, 22 Jun 2017 00:14:58 -0700 (PDT)
X-AuditID: 11ab0215-aa5ff70000000cf2-1d-594b6e710c84
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay6.apple.com (Apple SCV relay) with SMTP id 7F.49.05199.17E6B495; Thu, 22 Jun 2017 00:14:57 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_gyBFbxBE1bneZUCok+t1HQ)"
Received: from [17.150.223.79] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORX005CDTGW4040@nwk-mmpp-sz12.apple.com>; Thu, 22 Jun 2017 00:14:57 -0700 (PDT)
Sender: cpaasch@apple.com
From: Christoph Paasch <cpaasch@apple.com>
Message-id: <0D08287D-1F1B-44CB-B937-EB38DF0DCA84@apple.com>
Date: Thu, 22 Jun 2017 00:14:57 -0700
In-reply-to: <CAO249ydwQgPr2t6n9dNJ=xa5ubXDB2meYdU6OK7ATNvrpCGA_g@mail.gmail.com>
Cc: MultiPath TCP - IETF WG <multipathtcp@ietf.org>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
References: <CAO249ydwQgPr2t6n9dNJ=xa5ubXDB2meYdU6OK7ATNvrpCGA_g@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FAYpVuU5x1psGificXn1dfZLDYuucHm wOSxZMlPJo+Lr68zBzBFcdmkpOZklqUW6dslcGWcXhZbcEm2YvOzmSwNjA8kuxg5OSQETCQ+ X5jP1MXIxSEksIZJYtP9KawwidUPz7FCJA4xSryYcI0RJMErICjxY/I9FhCbWSBM4tnHUywQ RV8ZJeZf+8IOkhAWkJTovnOHGcRmE9CSeHu7HWgSB1CzjcS04y4QJRYShxfeAytnEVCVmLhh BZjNKRAsse7oaSaQcmYBY4kpM41AwiICehIfvn9kArGFBAIkGmbPYIa4U1bi1uxLzCAnSAgc YZN493En4wRGoVlITp2F5FQIW0vi+6NWIBtkhbzEwfOyEGFNiWf3PrFD2NoST95dYF3AyLaK UTg3MTNHNzPPyFAvsaAgJ1UvOT93EyMoElYzie5gnP/K8BCjAAejEg+vRZ1XpBBrYllxZe4h RmkOFiVxXp/NnpFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGPs/9e+52MH2maEur2Kt3ZW/ x7+/E3RZ9iZ74W7RHR8neZ+r3+u7Zveh15++aE/6YDvPjce25OQh5rhlWx23H7gW96c9ff+9 9N7KxRa8PXKrOK7c+jGX792Jyaqnbx7NTpn9x+trY86cnUvLGHxPSigKK5T6FjPXdBsGnqlV LEx2Ejv68KDIwgwlluKMREMt5qLiRACT3FkhZQIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUi2FB8RrcwzzvSYNViNYvPq6+zWWxccoPN gcljyZKfTB4XX19nDmCK4rJJSc3JLEst0rdL4Mo4vSy24JJsxeZnM1kaGB9IdjFyckgImEis fniOtYuRi0NI4BCjxIsJ1xhBErwCghI/Jt9jAbGZBcIknn08xQJR9JVRYv61L+wgCWEBSYnu O3eYQWw2AS2Jt7fbgSZxADXbSEw77gJRYiFxeOE9sHIWAVWJiRtWgNmcAsES646eZgIpZxYw lpgy0wgkLCKgJ/Hh+0cmEFtIIECiYfYMZog7ZSVuzb7EPIGRfxaS62YhuQ7C1pL4/qgVyAaZ Ki9x8LwsRFhT4tm9T+wQtrbEk3cXWBcwsq1iFChKzUmsNNNLLCjISdVLzs/dxAgO28KoHYwN y60OMQpwMCrx8E5o8IoUYk0sK67MBQYRB7OSCK9QqnekEG9KYmVValF+fFFpTmrxIcaJjEA/ TmSWEk3OB0ZVXkm8oYmJgYmxsZmxsbmJOS2FlcR5e6Z7RgoJpCeWpGanphakFsEcxcTBKdXA 6Bux58/xW9ujVhnWv7b5WLBLsSjjl/KP5nSufpNJi/+lhTn5RUz+vP7RCwfhND/VSJOJ1+bm 7H1WsaCx1k7w7vX2paqOBWs/pReqKz3OKVy+KDYz+NTSDRaHv6YfveT17mFUpeK1nVYlMXuL Au/35S/XaFv/4tW2lfd590pJydx5ue6T5Cnmz0osxRmJhlrMRcWJAFRPzerOAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Rz0_ekllPSOt19cprIW6qDvjlaQ>
Subject: Re: [multipathtcp] q about remove addr behavior
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 22 Jun 2017 07:15:02 -0000

Hello,

> On Jun 21, 2017, at 9:04 PM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
> In the Chicago meeting, I remember Joseph mentioned an issue on linux which close all subflows that use an IP address when rem addr for it has been received.
> 
> (page 13 in https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-channel-bonding-of-low-rate-links-using-mptcp-for-airborne-flight-research-00.pdf <https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-channel-bonding-of-low-rate-links-using-mptcp-for-airborne-flight-research-00.pdf>)
> 
> As far as I read 6824bis draft, this behavior seems not to be recommended. But, do we need more specific guidance here?

true, in Linux we just close the subflow and do not send keepalives to check whether the subflow is really up or not.

I'm not sure if sending keepalives is the right thing to do. Basically, when the peer tells us that this subflow should be removed, why shouldn't a host trust its peer and do as as it says ?
The benefit of closing the subflow is that we can stop trying to send data on it and we free those resources. Lingering subflows is a serious problem on the server-side, when clients move away from a WiFi access-point.


Christoph

v2.23.0 | Report a Bug | By Email