From nobody Wed Aug 1 10:26:47 2018 Return-Path: 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 B40D7130EC6 for ; Wed, 1 Aug 2018 10:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 U358Lwhlgopt for ; Wed, 1 Aug 2018 10:26:44 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 8D258130DD7 for ; Wed, 1 Aug 2018 10:26:44 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id w71HQNrQ014406; Wed, 1 Aug 2018 10:26:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : date : from : to : cc : subject : message-id : references : in-reply-to; s=20180706; bh=C/oxd8r8oFgJlobipTHizaUyf0npYLInC7G5YU7rbAo=; b=Bib00GWPCKQFFZscVSWAoKALP2V3G08ViEeSvJ4jIUl6b9X99h9shXyQkvLKZj0l96/8 K7w/mEDd1ReY7jk9fPZRMXLKOv4hi6ClRy1E67X/cIF1zLRVRMHKrCsa4XDCWkG3/jMk /TT9zkv6uGHrBAVnfARsctHYcxm6CLNqKHzEsHh6PLJkG1UtMmZrvKlb+qo9q8iSbNvK rHaOilNJTX283EUGSGliol5YTQ83bXJD3p5PmsAnh/uHtLAovxle66vWq5XOD0ViwI5G +3k/3JBIrSXxjbCa4X+wzmNAydDMrn5Ddul9b6iWlfrv9W/e6HGKYv3pMnhQh1150orp tA== Received: from relay3.asia.apple.com (relay-server.asia.apple.com [17.82.200.17]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2kgn15rkur-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 01 Aug 2018 10:26:40 -0700 X-AuditID: 1152c811-18bff70000006498-92-5b61ed4cbee5 Received: from sg3-mmpp-sz01.asia.apple.com ( [17.84.80.93]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay3.asia.apple.com (Apple Singapore relay) with SMTP id 74.2B.25752.C4DE16B5; Thu, 2 Aug 2018 01:26:36 +0800 (MYT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from localhost ([17.192.155.217]) by sg3-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PCS00ELDLSAZT00@sg3-mmpp-sz01.asia.apple.com>; Thu, 02 Aug 2018 01:26:36 +0800 (+08) Sender: cpaasch@apple.com Date: Wed, 01 Aug 2018 10:26:34 -0700 From: Christoph Paasch To: Alan Ford Cc: Rahul Arvind Jadhav , multipathtcp Message-id: <20180801172634.GB4738@MacBook-Pro-19.local> References: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> <92A53501-4728-4E02-816A-92CEE703AA49@gmail.com> <20754FD9-627F-4AAC-A1B5-6EF2BD09B2AD@gmail.com> <982B626E107E334DBE601D979F31785C5DC5D84B@BLREML503-MBS.china.huawei.com> <982B626E107E334DBE601D979F31785C5DC6884D@BLREML503-MBS.china.huawei.com> <2FB78E5E-961F-4077-815F-158142B8E7E2@gmail.com> In-reply-to: <2FB78E5E-961F-4077-815F-158142B8E7E2@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUiGBIQq+vzNjHaYMpkSYuV51YwW3xefZ3N Yv2LjSwOzB47Z91l92g58pbVY8mSn0wBzFFcNimpOZllqUX6dglcGUtuTWcu2ChacfRyO2sD 43uBLkZODgkBE4ljZ56wdzFycQgJLGOSeHuhixkkwSsgKPFj8j2WLkYODmYBeYkjl7JBwswC 0hKP/s5ghwirS0yZkgsSFhLoYZLYtzoJxBYWkJTovnMHbAqLgKpE59N9bCA2m4CWxNvb7awg rSICyhLLZ7FCTIyUmPF1DjNEq57Elp/HGCEOsJDY+vEaG8Rlu5klbn5tBiviFLCVmN+3AKxZ FGjOgW3HmSYwCs5CcvQshKNnITl6FsLRCxhZVjGKFqXmJFYa6yUWZybqJRYU5KTqJefnbmIE hXTQCcEdjB+mGh5iFOBgVOLh5XiQGC3EmlhWXJl7iFGCg1lJhHfOa6AQb0piZVVqUX58UWlO avEhRmkOFiVxXous2ighgfTEktTs1NSC1CKYLBMHp1QDo5Hj96t2X5eWcmX3f91RdVmHYZLH r85mqSmbap7HX7Riy79uKvEq/OX3S/9Z7v+cK3/61bPjpn+dUg9Vb9i8+8TLh586Z76cb620 S2Hmkg/bnHYoKtk4v3jvXs9+I5TlhPED4wp+u4nz5qotffy64Uwig/u8vVP+b1vJf8SEOWDD xcJZM/+FXuZXYinOSDTUYi4qTgQAr4+x8GUCAAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-01_06:, , signatures=0 Archived-At: Subject: Re: [multipathtcp] 6824bis -11 review X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 17:26:46 -0000 On 31/07/18 - 13:07:06, Alan Ford wrote: > Hi Rahul, all, > > > On 31 Jul 2018, at 01:21, Rahul Arvind Jadhav wrote: > > > > c) sending a new ADD_ADDR with same ID + address and different port is fine > > [RJ] again this is what the text already says, but I’m not still clear about this. Why ID + address has to match? Only ID should be enough. > > > > Consider: > > > > a) ADD_ADDR comes in saying ID=2, addr=10.0.0.1 (private) > > b) MP_JOIN comes in saying ID=2, addr=8.9.10.11 (public) > > c) ADD_ADDR comes in saying ID=2, addr=192.168.0.1 > > > > What does this mean? Is (c) an implicit REMOVE+ADD? And thus does this mean the subflow created in (b) is now no longer valid? > > > > By keeping the address / ID mapping, if an address is lost, then so is the subflow. > > > > [RJ2] Rather than viewing ( c) as an implicit REMOVE+ADD, can we see it as an UPDATE? Because ID remains same. Subflow created in (b) remains valid (not sure if I’m missing anything here, I see no reason to lose this subflow). > > In step ( c), the receiver can override Address field in context to ID=2 to the new addr (192.168.0.1) …… 8.9.10.11 is kept separately as the learnt actual rcvd IP (from MP_JOIN) in the same context ID=2. We have to agree that an implementation needs to maintain this IP separately in context to ID=2 anyways. > > So if we do an explicit REMOVE+ADD, the end result is the same as this UPDATE (but with much less overhead & impl ease). > > I would be interested in hearing from other implementers here… Is there an issue with “updating” using ADD_ADDR? > > Given we say that REMOVE_ADDR should not remove a subflow if it’s still alive, we have precedent for implying a subflow can exist to an address which does not have an Address ID - to - IP address mapping. > > So given that, does updating, as Rahul suggests, cause a problem? I haven't yet implemented MPTCP path-management in a way that both sides can trigger the creation of a subflow - which is the scenario we are concerned about here. If we would try to do this, I think we should always "believe" the latest information that we are receiving. In the above scenario, this would mean that (c) would update the Address-ID to IP mapping. Yes, it's a private IP and probably not routable - but that simply means that there is an implementation-bug on the client as he should not have announced the IP in the first place. Should (c) trigger a removal the subflow established in (b) ? I don't think so. As long as the subflow is working fine,... we should keep it. Only REMOVE_ADDR should trigger an explicit removal. That's just my opinion. Christoph From nobody Wed Aug 1 10:27:13 2018 Return-Path: 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 AF083130EC7 for ; Wed, 1 Aug 2018 10:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 o_6azAuJzujY for ; Wed, 1 Aug 2018 10:27:09 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 1E58A130EC6 for ; Wed, 1 Aug 2018 10:27:09 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.22/8.16.0.22) with SMTP id w71HQKKm024368; Wed, 1 Aug 2018 10:27:04 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : date : from : to : cc : subject : message-id : references : in-reply-to; s=20180706; bh=H7bCE0dCQAQxPNaf1dX0vLw/Xa9+Vro+xNqmgd1WomI=; b=ShH8u/rF70Oww4MfbwNqDSUwqFP79iWReaI5UcLmwtJArwvWy6vP9qE1ViBCCTRpoPZZ U//m7y8lMYXuNA23q50V7vZK2LYKoEdlmVBq6C9L1Sqc5Mu0ajwFZelwlZTc3PBuIgHH FrYuJq9VXsWIspvfD0IzFnLqroYIYp9nCZ1kf/l6e9RHKM/U0ilSirWw5Xno3QNLvG3v hCes/t0CoGdmvqD7e3RrEzvLRKdzy5kBKi0wGgNFynKtBSUAtUoVQMBirQsRFW2xUSqm J4rCpScs2yAXwzZpXE/3prf1wRwUWRlA+HEGoW1qfhr86BR6GljKXZipQ8cTqnJ4KxzS VQ== Received: from relay3.asia.apple.com (relay3.asia.apple.com [17.82.200.17]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2kgn2k9ctr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 01 Aug 2018 10:27:04 -0700 X-AuditID: 1152c811-1a3ff70000006498-9e-5b61ed64c0d3 Received: from sg3-mmpp-sz01.asia.apple.com ( [17.84.80.93]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay3.asia.apple.com (Apple Singapore relay) with SMTP id C6.2B.25752.46DE16B5; Thu, 2 Aug 2018 01:27:00 +0800 (MYT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from localhost ([17.192.155.217]) by sg3-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PCS00ELMLSYZT00@sg3-mmpp-sz01.asia.apple.com>; Thu, 02 Aug 2018 01:27:00 +0800 (+08) Sender: cpaasch@apple.com Date: Wed, 01 Aug 2018 10:26:58 -0700 From: Christoph Paasch To: Alan Ford Cc: Rahul Arvind Jadhav , multipathtcp Message-id: <20180801172658.GF1362@MacBook-Pro-19.local> References: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> <92A53501-4728-4E02-816A-92CEE703AA49@gmail.com> In-reply-to: <92A53501-4728-4E02-816A-92CEE703AA49@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUiGBIQq5vyNjHaYOoVE4uV51YwW3xefZ3N Yv2LjSwOzB47Z91l92g58pbVY8mSn0wBzFFcNimpOZllqUX6dglcGd/6fzAVtPJW9N/+wNrA OIeri5GTQ0LAROLH+dmsXYxcHEICy5gk/izuYwdJ8AoISvyYfI+li5GDg1lAXuLIpWyQMLOA tMSjvzPYIcLqElOm5EK09jBJPNu0lQ2kRlhAUqL7zh1mEJtFQFVi2qPDrCA2m4CWxNvb7awg vSICyhLLZ7FCjIyUmPF1DjNEq57Elp/HGCEusJD4/2MhG8T8LkaJize7wRo4BWwlzux+DNYg CjTnwLbjTBMYBWchuXoWwtWzkFw9C+HqBYwsqxhFi1JzEiuN9RKLMxP1EgsKclL1kvNzNzGC gjrohOAOxg9TDQ8xCnAwKvHwcjxIjBZiTSwrrsw9xCjBwawkwjvnNVCINyWxsiq1KD++qDQn tfgQozQHi5I4r0VWbZSQQHpiSWp2ampBahFMlomDU6qBMWvr9W/f2T66rGTa31yeqnzSaH3V Zq3SpXfy0nL3vG+ecNb894OKqO0++8wsBaYb7hCZ8SmLJ//dgWLZxgrh6u+FS3Y11c6p+VN/ MS1zx28vLb0p7BO42nya4kXz4mVLCg4v5ZyyW+VItkslW1RgyNmO/YqWns5nvzK33azRdcnu ShXbprhAiaU4I9FQi7moOBEA6GZbHWYCAAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-01_06:, , signatures=0 Archived-At: Subject: Re: [multipathtcp] 6824bis -11 review X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 17:27:11 -0000 On 28/07/18 - 18:19:16, Alan Ford wrote: > Hi Rahul, > > Thank you very much indeed for this review. > > > On 28 Jul 2018, at 08:38, Rahul Arvind Jadhav wrote: > > > > Hi, > > > > As promised in IETF102, here is my review for 6824bis-11. As Phil had suggested, I didn't take the trouble to check if my comments overlap with any of the previous discussions/comments. > > > > 1. Section 3.6: Subflow Reset > > [RJ]: Is MP_TCPRST a SHOULD or MUST to be included along with the TCP_RST ? Can this be stated explicitly in section 3.6? > > It’s a MAY :) We say: > > "These semantics are carried in the MP_TCPRST option that can be included on a TCP RST packet.” > > We should change that to “MAY be included”. > > > 2. Section 3.4.2. Remove Address > > "The sending and receipt (if no keepalive response was received) of > > this message SHOULD trigger the sending of RSTs by both hosts on the > > affected subflow(s) " > > [RJ]: Since a MP_TCPRST should be associated with this RST, what should be the corresponding Reason Code that can be used in MP_TCPRST for this case? I checked existing reason codes in section 3.6 and none of those made sense (may be except for 0x0 ?). > > That’s an interesting one. There may be some benefit (maybe for middleboxes, or maybe for security) to sharing this information in the RST with an explicit reason code. We could add one - but I would be interested in hearing other opinions. We could add one that indicates that the RST is upon a response of an incoming MPTCP-option (e.g., responding to a REMOVE_ADDR, a MP_FASTCLOSE,...). Christoph From nobody Wed Aug 1 10:44:12 2018 Return-Path: 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 7FF8D130EE2 for ; Wed, 1 Aug 2018 10:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 AQHxUimpfVHa for ; Wed, 1 Aug 2018 10:44:08 -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 27850130EEC for ; Wed, 1 Aug 2018 10:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1533145447; x=2397059047; 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=kWc3PrLU2m/1EMfr4/6K0I/Lzk5+G5AcdTmzVx8puC0=; b=gCoUdHSi4v616VO/9zaLWBOjE/gpTA+jcmMHdFPC/S2ITKN3+cy533QzYGV3xpxL GF1RAuZKkEydwT58D94ibsdcwmatOLIAw3Li9ODnRVA5brXx8/PDbhIlNgeCF4aZ czHAwH1Se/N61x3TZfjCHPraGkB222YNnNupq5XeeTgEBIn1K4nxRU3BzISLnDTv H1S+P0GB4P3N7cF3cjgqCt+b31GE4CKGEmG+KFbImHXyInAR0V/70LIL6LTEMBRr EVBRFsA56SYIxMGjgizySMQktAxk87DTzxtYwNMOq/outbnGD/1B69DoaFBRPkcG ekEj1EYu9KZvaEm5FX1Q+Q==; X-AuditID: 11ab0219-56fff70000004c1b-4a-5b61f167dc41 Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id 5E.29.19483.761F16B5; Wed, 1 Aug 2018 10:44:07 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from ma1-mmpp-sz09.apple.com (ma1-mmpp-sz09.apple.com [17.171.128.183]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PCS00KODMLJSF20@ma1-mtap-s01.corp.apple.com>; Wed, 01 Aug 2018 10:44:07 -0700 (PDT) Received: from process_viserion-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCS00E00M17K400@ma1-mmpp-sz09.apple.com>; Wed, 01 Aug 2018 10:44:07 -0700 (PDT) X-Va-A: X-Va-T-CD: 3e2137337759e4c980b0d14ecb116e8e X-Va-E-CD: 100259cb1eba463174300fddddea97b1 X-Va-R-CD: 85fa7f6fa91bf79d079176d0dd790740 X-Va-CD: 0 X-Va-ID: 049a28b9-b03e-43d1-960e-08195f0cbc50 X-V-A: X-V-T-CD: 3e2137337759e4c980b0d14ecb116e8e X-V-E-CD: 100259cb1eba463174300fddddea97b1 X-V-R-CD: 85fa7f6fa91bf79d079176d0dd790740 X-V-CD: 0 X-V-ID: 6feae772-69c4-43d4-987c-d843d834db5d Received: from process_milters-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCS00J00MEC4E00@ma1-mmpp-sz09.apple.com>; Wed, 01 Aug 2018 10:44:07 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-08-01_07:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp23.corp.apple.com-10000_instance1 Received: from localhost ([17.192.155.217]) by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PCS00JTAMLI3E10@ma1-mmpp-sz09.apple.com>; Wed, 01 Aug 2018 10:44:07 -0700 (PDT) Sender: cpaasch@apple.com Date: Wed, 01 Aug 2018 10:44:06 -0700 From: Christoph Paasch To: Xavier de Foy Cc: multipathtcp Message-id: <20180801174406.GC4738@MacBook-Pro-19.local> References: In-reply-to: User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsUiqOHDqpv+MTHa4NhWaYvPq6+zWZw9M5PR gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MpYPecqa8Ee04rHy6awNTBu1upi5OSQEDCR aH++lqmLkYtDSGA/k8SB3kssIAleAUGJH5PvAdkcHMwC8hJHLmWDhJkFpCUe/Z3BDhFWl5gy JReidSOTxL/vM9kgnC4mie/XvrBDLGCX+PNrBwuErS1x4/lrNhh7QncjK4z9/uN3KJtLYsHW 06wgCyQEdCUuLaiDCLNJrD+xhAnC1pJYd3UaM0SJlkR/mxJM+PKhJ1AlnBLnv0yEukBHou3Z T6gXO5kkJqx/zQiRyJbY8eUkVEOAxJqFP8HiQgJNTBLrzqqA2MICkhLdd+6A7WIRUJXYdV8T JMwGtOvt7Xawi0WA7OcLdjJCgkdD4vrDZjaI1nCJrgP/wCHIK2Ah8f68JMT0AInnR88wTmBU moUUzrMQ4TwLKZxnIcJ5ASPLKkbh3MTMHN3MPCNTvcSCgpxUveT83E2MoASxmklyB+PX14aH GAU4GJV4eAsqE6KFWBPLiitzDzFKc7AoifN+3CUWLSSQnliSmp2aWpBaFF9UmpNafIiRiYNT qoGx7Z2m7jelJn//mUEpO1kC57n9mu/os+p1XqG+9aWPx6M+qh5w1uJ53NRwU+ny8YSAu2+O KreUXXibOvvBpX8mnm4Hrxivd7C3LvDt81WaduPPjZ2bty7XLHWr1df5X/Vxh+bhMuNfsTEu NvwiLcsKVVtmLrXi2c3o8Fuj7O6y7kS/bMb7fepKLMUZiYZazEXFiQBtEAnE8QIAAA== Archived-At: Subject: Re: [multipathtcp] rfc6824bis discussion about 5G session continuity support X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 17:44:11 -0000 Hello, On 30/07/18 - 15:03:27, Xavier de Foy wrote: > Hi, > > As promised during the MPTCP meeting session at IETF 102, here is a summary > of our findings related to 5G session continuity support, as part of the > review of rfc6824bis. > > > > The root problem is the following: in 5G, a client may have IP addresses > provided by a mobile network, in association with a session continuity > service (SCC mode 1/fixed, 2/distributed anchor + BBM or 3/ distributed > anchor + MBB). Such an IP address can be replaced, or be complemented with, > another IP address, possibly multiple times during the lifetime of an > application session. If the MPTCP stack is not aware of this, it can’t make > the link between these addresses, and can’t make the correct or most > efficient decisions in some cases. > > > > I think there is at least a case for _local_ usage of session continuity > information by the 5G device MPTCP stack. Every new IP address can > (locally) be associated with a tuple (address type, original IP address), > using the DMM-defined “address types” which have a 1:1 relationship with > the 3GPP SCC modes. For example, using this information, a MPTCP local > stack can copy the backup priority property from one IP address to the next > when appropriate. > > > > **Rationale to send new information over MPTCP (and workarounds) ** > > > > In addition to the local usage of this information, here are possible > scenarios where sending the tuple (address type, original IP address ID) > over MPTCP signaling may help the remote peer making appropriate decisions: > > > > Case #1: the IP address in active use is over SSC mode 3/MBB, and there is > a MBB handover: > > - We want both MPTCP peers to start using new path(s) using the new IP > address, then wait for its bandwidth usage to ramp up, and, after some > time, cleanly remove the old IP address (cleanly = not losing/re-sending > packets). This is for a smooth transition in term of performance, and to > release network resources associated with the old IP address. If both peers > have access to the tuple (address type, original IP address), they can both > perform these actions. After a while, one side can close the now unused > subflow(s), and then remove the IP address. > > - Possible workaround/solution: there is no need to send the tuple over > MPTCP signaling, if the MPTCP client has the possibility to request a clean > shutdown of old paths/addresses. When discussing this with Christoph, he > proposed a quick way to implement a clean shutdown, if I recall correctly: > (1) set the priority of subflows using this address to “backup”, (2) wait > for in-flight TCP segments to arrive and be acked, (3) remove the IP > address. See below in conclusion for additional details on this. > > > > Case #2: on the client, the IP address in active use is over SSC mode > 2/BBM, and there is another backup IP address: > > - If no change is made, during the break before make, the peers will switch > to use the backup IP address. This may not be the desired outcome (e.g. > waking up a radio for a few packets, and changing the properties of the > path for a very short period of time). This here would basically mean that we want to add an additional "latency" to the backup-bit information. This latency would mean that even if there are no other paths available, a host should wait a bit more before sending on the subflow marked as backup. > Sending the tuple (address type, > original IP address) as above enables avoiding this situation. > > - Possible workaround/solution: in 5G systems, it may be possible to avoid > using SSC mode 2/BBM for applications that use MPTCP, by adjusting SSC > policies for those applications. (At this time it is not clear if will be > possible in all cases, e.g. applications may also request a specific > continuity service using setsc().) > > > > > > **Conclusion** > > > > A long term solution for cases #1, #2, and possibly other scenarios that > may emerge later, could be to send a tuple (address type, original IP > address ID) to the remote peer, over MPTCP. I think we should avoid exposing 5G-specific information in MPTCP and (if really needed) rather abstract those mechanics away into a more generic format. > This information would be > associated with options that can introduce a new IP address, like ADD_ADDR, > MP_JOIN, MP_CAPABLE. Nevertheless, experiments will be needed to determine > if it is really needed, or if a local usage of this information on the > client side is enough. Since 5G deployments are not yet common, it will > take time. Thus it may be best to rely on the experimental extension > mechanism, and possibly make sure some minimal support is in place in > rfc6824bis. It seems to me that those 5G constructs could be expressed in generic scheduling policies. In general, this is currently a missing piece in MPTCP. In the sense that a client connecting to a server has no fine-grained control over how the server is scheduling data. With today's special purpose deployments (where clients know exactly what server they are connecting to), it's not a big problem. But for a more generic deployment of MPTCP it would be useful to allow more fine-grained control. Maybe that would be a good work-item for the working-group's next steps (?). Christoph > > > > Proposal: > > > > (1) Document, in rfc6824bis, a “clean remove” of a live address – this will > enable dealing with the most obvious case #1 (SSC mode 3). > > - Basically, this can use the mechanism described above. Either now or in a > future version of the protocol, it could make sense to avoid corner cases > (e.g. use a new “inactive” priority for subflows, and possibly a new reason > code “inactive address” when closing the subflows). > > > > (2) Could we make sure that experimental extensions are available in the > new version of the MPTCP protocol? > > - Additional question: do you think it will be acceptable to mandate > sending an extension option within the same packet as another MPTCP option? > It would be convenient to place the address type extension within the same > packet used to transmit the option it extends (e.g. ADD_ADDR, MP_JOIN, > MP_CAPABLE). This would ensure that there is no sync issue between them, > due to timing issue or packet loss, and there will be no need to explicitly > deal with re-transmission of this particular extension option. > > > > Best Regards, > > > > Xavier. > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Wed Aug 1 11:47:19 2018 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A32E0130E46; Wed, 1 Aug 2018 11:47:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: multipathtcp@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153314923065.21822.15086575982355068433@ietfa.amsl.com> Date: Wed, 01 Aug 2018 11:47:10 -0700 Archived-At: Subject: [multipathtcp] IPR Disclosure Apple Inc.'s Statement about IPR related to draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 18:47:11 -0000 Dear Alan Ford, Costin Raiciu, Mark J. Handley, Olivier Bonaventure, Christoph Paasch: An IPR disclosure that pertains to your Internet-Draft entitled "TCP Extensions for Multipath Operation with Multiple Addresses" (draft-ietf-mptcp-rfc6824bis) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3242/). The title of the IPR disclosure is "Apple Inc.'s Statement about IPR related to draft-ietf-mptcp-rfc6824bis" Thank you IETF Secretariat From nobody Wed Aug 1 17:58:19 2018 Return-Path: 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 54A97130ECA for ; Wed, 1 Aug 2018 17:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 8JnwqBi3ReUa for ; Wed, 1 Aug 2018 17:58:16 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 9BEDE128CF3 for ; Wed, 1 Aug 2018 17:58:16 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4D01EDBC3B3C for ; Thu, 2 Aug 2018 01:58:11 +0100 (IST) Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 2 Aug 2018 01:58:12 +0100 Received: from BLREML503-MBS.china.huawei.com ([169.254.12.219]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0399.000; Thu, 2 Aug 2018 06:27:57 +0530 From: Rahul Arvind Jadhav To: "cpaasch@apple.com" , Alan Ford CC: multipathtcp Thread-Topic: [multipathtcp] 6824bis -11 review Thread-Index: AdQmJDYhfu15UAaeTxKUY+EC058bGgARMycAAMlvQQAAGrSboA== Date: Thu, 2 Aug 2018 00:57:56 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DC6A680@BLREML503-MBS.china.huawei.com> References: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> <92A53501-4728-4E02-816A-92CEE703AA49@gmail.com> <20180801172658.GF1362@MacBook-Pro-19.local> In-Reply-To: <20180801172658.GF1362@MacBook-Pro-19.local> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.157.44] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [multipathtcp] 6824bis -11 review X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 00:58:18 -0000 PiA+ID4gW1JKXTogU2luY2UgYSBNUF9UQ1BSU1Qgc2hvdWxkIGJlIGFzc29jaWF0ZWQgd2l0aCB0 aGlzIFJTVCwgd2hhdCBzaG91bGQNCj4gYmUgdGhlIGNvcnJlc3BvbmRpbmcgUmVhc29uIENvZGUg dGhhdCBjYW4gYmUgdXNlZCBpbiBNUF9UQ1BSU1QgZm9yIHRoaXMNCj4gY2FzZT8gSSBjaGVja2Vk IGV4aXN0aW5nIHJlYXNvbiBjb2RlcyBpbiBzZWN0aW9uIDMuNiBhbmQgbm9uZSBvZiB0aG9zZSBt YWRlDQo+IHNlbnNlIChtYXkgYmUgZXhjZXB0IGZvciAweDAgPykuDQo+ID4NCj4gPiBUaGF04oCZ cyBhbiBpbnRlcmVzdGluZyBvbmUuIFRoZXJlIG1heSBiZSBzb21lIGJlbmVmaXQgKG1heWJlIGZv cg0KPiBtaWRkbGVib3hlcywgb3IgbWF5YmUgZm9yIHNlY3VyaXR5KSB0byBzaGFyaW5nIHRoaXMg aW5mb3JtYXRpb24gaW4gdGhlIFJTVA0KPiB3aXRoIGFuIGV4cGxpY2l0IHJlYXNvbiBjb2RlLiBX ZSBjb3VsZCBhZGQgb25lIC0gYnV0IEkgd291bGQgYmUgaW50ZXJlc3RlZCBpbg0KPiBoZWFyaW5n IG90aGVyIG9waW5pb25zLg0KPiANCj4gV2UgY291bGQgYWRkIG9uZSB0aGF0IGluZGljYXRlcyB0 aGF0IHRoZSBSU1QgaXMgdXBvbiBhIHJlc3BvbnNlIG9mIGFuDQo+IGluY29taW5nIE1QVENQLW9w dGlvbiAoZS5nLiwgcmVzcG9uZGluZyB0byBhIFJFTU9WRV9BRERSLCBhDQo+IE1QX0ZBU1RDTE9T RSwuLi4pLg0KPiANCg0KU29tZSBtb3JlIHBvaW50cyBpbiBjb250ZXh0IHRvIE1QX1RDUFJTVDoN CjEuIFRoZXJlIGFyZSBzZXZlcmFsIGNhc2VzIG9mIE1QX1RDUFJTVCB3aGVyZSB0aGVyZSBpcyBu byBtZW50aW9uIG9mIFJlYXNvbiBDb2RlIHRvIGJlIHVzZWQuIENhbiB0aGUgUmVhc29uIENvZGUg YmUgZXhwbGljaXRseSBzdGF0ZWQgZm9yIGtub3duIGNhc2VzPyAgQ29uc2lkZXIgZm9sbCBzZWN0 aW9uczoNCglhLiBTZWN0aW9uIDMuMi4gU3RhcnRpbmcgYSBOZXcgU3ViZmxvdw0KCSJJZiB0aGUg dG9rZW4gaXMgdW5rbm93biwgb3IgdGhlIGhvc3Qgd2FudHMgdG8gcmVmdXNlDQoJc3ViZmxvdyBl c3RhYmxpc2htZW50IChmb3IgZXhhbXBsZSwgZHVlIHRvIGEgbGltaXQgb24gdGhlIG51bWJlciBv Zg0KICAgCXN1YmZsb3dzIGl0IHdpbGwgcGVybWl0KSwgdGhlIHJlY2VpdmVyIHdpbGwgc2VuZCBi YWNrIGEgcmVzZXQgKFJTVCkNCiAgIAlzaWduYWwsIGFuYWxvZ291cyB0byBhbiB1bmtub3duIHBv cnQgaW4gVENQLCBjb250YWluaW5nIGEgTVBfVENQUlNUDQogICAJb3B0aW9uIChTZWN0aW9uIDMu Nikgd2l0aCBhbiBhcHByb3ByaWF0ZSByZWFzb24gY29kZS4iDQoNCgktLS0tLVtUaGVyZSBpcyBh IGR1cGxpY2F0ZSBzZW50ZW5jZSBpbiB0aGUgc2FtZSBzZWN0aW9uXS0tLS0NCg0KCSJJZiB0aGUg dG9rZW4gcmVjZWl2ZWQgYXQgSG9zdCBCIGlzIHVua25vd24gb3IgbG9jYWwgcG9saWN5IHByb2hp Yml0cw0KICAgCXRoZSBhY2NlcHRhbmNlIG9mIHRoZSBuZXcgc3ViZmxvdywgdGhlIHJlY2lwaWVu dCBNVVNUIHJlc3BvbmQgd2l0aCBhDQogICAJVENQIFJTVCBmb3IgdGhlIHN1YmZsb3csIHdpdGgg YSBNUF9UQ1BSU1Qgb3B0aW9uIChTZWN0aW9uIDMuNikgd2l0aA0KICAgCWFuIGFwcHJvcHJpYXRl IHJlYXNvbiBjb2RlLiINCg0KCWIuICBTZWN0aW9uIDMuMy4yLg0KCSJJbiB0aGlzIGNhc2UsIHRo ZSBNUFRDUCBzZW5kZXIgY2FuIGRlY2lkZSB0byB0ZXJtaW5hdGUgdGhlIHN1YmZsb3cgDQoJdGhh dCBpcyBiZWhhdmluZyBiYWRseSBieSBzZW5kaW5nIGEgUlNULCB1c2luZyBhbiBhcHByb3ByaWF0 ZSBNUF9UQ1BSU1QgDQoJKFNlY3Rpb24gMy42KSBlcnJvciBjb2RlLiINCg0KCWMuIFNlY3Rpb24g My4zLjYuDQoJIkEgUlNUIGZvciB0aGlzIHB1cnBvc2UgU0hPVUxEIGJlIGFjY29tcGFuaWVkIHdp dGgNCglhbiBhcHByb3ByaWF0ZSBNUF9UQ1BSU1Qgb3B0aW9uIg0KDQoJZC4gU2VjdGlvbiAzLjcu DQoJIlRoaXMgUlNUIFNIT1VMRCBpbmNsdWRlIHRoZSBNUF9UQ1BSU1Qgb3B0aW9uDQoJIChTZWN0 aW9uIDMuNikgd2l0aCBhbiBhcHByb3ByaWF0ZSByZWFzb24gY29kZS4iDQoNCgllLiBTZWN0aW9u IDMuNw0KCSJUaGUgZGF0YSB3b3VsZCBub3QgYmUgREFUQV9BQ0tlZA0KICAgCShzaW5jZSB0aGVy ZSBpcyBubyBtYXBwaW5nIGZvciB0aGUgZGF0YSksIGFuZCB0aGUgc3ViZmxvdyBjYW4gYmUNCiAg IAljbG9zZWQgd2l0aCBhIFJTVCwgY29udGFpbmluZyBhIE1QX1RDUFJTVCBvcHRpb24gKFNlY3Rp b24gMy42KSB3aXRoDQogICAJYW4gYXBwcm9wcmlhdGUgcmVhc29uIGNvZGUuIg0KDQoyLiBDYW4g d2UgaGF2ZSBhbiB1c2VyLWRlZmluZWQgUmVhc29uLUNvZGUgYmxvY2sgZm9yIGltcGxlbWVudGF0 aW9ucyB0byBkZWZpbmUgdGhlaXIgb3duIFJlYXNvbi1jb2RlIHdpdGhpbiB0aGUgYmxvY2sgd2l0 aG91dCB3b3JyeWluZyBmb3IgZnV0dXJlIHJlYXNvbi1jb2RlIGFkZG9ucz8NCg0K From nobody Thu Aug 2 08:09:42 2018 Return-Path: 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 73520130EA0 for ; Thu, 2 Aug 2018 08:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NyEO4ThqF0yJ for ; Thu, 2 Aug 2018 08:09:35 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EF1130E8B for ; Thu, 2 Aug 2018 08:09:35 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id n6-v6so2672872qtl.4 for ; Thu, 02 Aug 2018 08:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3rZid6PjAReTdEQ3rksoWadC539PUFijlf/k4nXHW40=; b=smDpbBC2vvpgWXKmX3H5GSZHCBEn2s95Z52uKEUpbsovJ2qvpOJUZIOKESamHJf7pw zGaCfDVzmF93AqBonMpQ/pnjXBj5tm4J6GUAoUSjspeP89kcB8MGxoSW5eBFg3tWazrr eyPdG7RJSaOFWPVVo+Mdfu/BidSRqIg7X1cCHUfZSBnhp3frm784RlM5ySuh4Pr8961L 7kL96d4SxdlUux1h0jSBQgrHXnH975MM0YoRjIuLW/6xYmCRcY6XNf6KCp81qhG/q8Zn 1qKN08vuuPaE8m9tKXgiGG+p46RdIV71S7GfeztvqzCarB91NKQKxSjomUmm7E4bqCvL EoCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3rZid6PjAReTdEQ3rksoWadC539PUFijlf/k4nXHW40=; b=tehW0Y0yLs8DNxcomqtR6x13Jm1Gs/hOzcebqvphkKLesbhK/ebiqRCrR+rJP7xbc0 QsCHwRW8pg3tS2K0Mho6XYQeIhxIW/8kl+TDUQ3r/Gi95f+cdlE5ES68CpWaVObt+Y5m USVOr7a888MeWmf60fEh7e0xNLW3P+V7AJ6M4EfLDXWvH674ng82/7iIRzxywL7l+4MJ Z4xYFq3JtRFl1l6ZycBDCm9PCnifxU2d1R/63DIutm5/Jj+IGrWQIMgw1/zbkCFuhNj3 lRCj5aMibcMZgadyW3W922Zt98Q7sLa00szzoe3o4aViPdgj2MISwirs6hGQvf2gK6Ls 28zw== X-Gm-Message-State: AOUpUlGE2DPefA3Szf1A6yQ++rYLhFc0CFgUkYsfciBlCpcqW7Z5ForL D0k44DpNL7RIRD/GG/96UROSa0EUNJMSpQ5BaxWw2iL/ X-Google-Smtp-Source: AAOMgpcoqHmuyr67ED57D931xXSHgh0gzATg/rSF2X2JCDgukjmzBR2N1QxMJ9HjULNVSr3g1WxcGmVl/u4lKeCOy3g= X-Received: by 2002:a0c:f8ce:: with SMTP id h14-v6mr2919813qvo.163.1533222574457; Thu, 02 Aug 2018 08:09:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2ea2:0:0:0:0:0 with HTTP; Thu, 2 Aug 2018 08:09:33 -0700 (PDT) In-Reply-To: <20180801174406.GC4738@MacBook-Pro-19.local> References: <20180801174406.GC4738@MacBook-Pro-19.local> From: Xavier de Foy Date: Thu, 2 Aug 2018 11:09:33 -0400 Message-ID: To: Christoph Paasch Cc: multipathtcp Content-Type: multipart/alternative; boundary="000000000000e98de70572753297" Archived-At: Subject: Re: [multipathtcp] rfc6824bis discussion about 5G session continuity support X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 15:09:40 -0000 --000000000000e98de70572753297 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Christoph, On Wed, Aug 1, 2018 at 1:44 PM, Christoph Paasch wrote: > Hello, > > On 30/07/18 - 15:03:27, Xavier de Foy wrote: > > Hi, > > > > As promised during the MPTCP meeting session at IETF 102, here is a > summary > > of our findings related to 5G session continuity support, as part of th= e > > review of rfc6824bis. > > > > > > > > The root problem is the following: in 5G, a client may have IP addresse= s > > provided by a mobile network, in association with a session continuity > > service (SCC mode 1/fixed, 2/distributed anchor + BBM or 3/ distributed > > anchor + MBB). Such an IP address can be replaced, or be complemented > with, > > another IP address, possibly multiple times during the lifetime of an > > application session. If the MPTCP stack is not aware of this, it can=E2= =80=99t > make > > the link between these addresses, and can=E2=80=99t make the correct or= most > > efficient decisions in some cases. > > > > > > > > I think there is at least a case for _local_ usage of session continuit= y > > information by the 5G device MPTCP stack. Every new IP address can > > (locally) be associated with a tuple (address type, original IP address= ), > > using the DMM-defined =E2=80=9Caddress types=E2=80=9D which have a 1:1 = relationship with > > the 3GPP SCC modes. For example, using this information, a MPTCP local > > stack can copy the backup priority property from one IP address to the > next > > when appropriate. > > > > > > > > **Rationale to send new information over MPTCP (and workarounds) ** > > > > > > > > In addition to the local usage of this information, here are possible > > scenarios where sending the tuple (address type, original IP address ID= ) > > over MPTCP signaling may help the remote peer making appropriate > decisions: > > > > > > > > Case #1: the IP address in active use is over SSC mode 3/MBB, and there > is > > a MBB handover: > > > > - We want both MPTCP peers to start using new path(s) using the new IP > > address, then wait for its bandwidth usage to ramp up, and, after some > > time, cleanly remove the old IP address (cleanly =3D not losing/re-send= ing > > packets). This is for a smooth transition in term of performance, and t= o > > release network resources associated with the old IP address. If both > peers > > have access to the tuple (address type, original IP address), they can > both > > perform these actions. After a while, one side can close the now unused > > subflow(s), and then remove the IP address. > > > > - Possible workaround/solution: there is no need to send the tuple over > > MPTCP signaling, if the MPTCP client has the possibility to request a > clean > > shutdown of old paths/addresses. When discussing this with Christoph, h= e > > proposed a quick way to implement a clean shutdown, if I recall > correctly: > > (1) set the priority of subflows using this address to =E2=80=9Cbackup= =E2=80=9D, (2) wait > > for in-flight TCP segments to arrive and be acked, (3) remove the IP > > address. See below in conclusion for additional details on this. > > > > > > > > Case #2: on the client, the IP address in active use is over SSC mode > > 2/BBM, and there is another backup IP address: > > > > - If no change is made, during the break before make, the peers will > switch > > to use the backup IP address. This may not be the desired outcome (e.g. > > waking up a radio for a few packets, and changing the properties of the > > path for a very short period of time). > > This here would basically mean that we want to add an additional "latency= " > to the backup-bit information. This latency would mean that even if there > are no other paths available, a host should wait a bit more before sendin= g > on the subflow marked as backup. > [xdf] agreed. Having a finite latency parameter (instead of an "inactive priority", which would be equivalent to an infinite latency) would help handling cases where the BBM handover fails. It could also be used as a priority mechanism between multiple backup subflows. > > Sending the tuple (address type, > > original IP address) as above enables avoiding this situation. > > > > - Possible workaround/solution: in 5G systems, it may be possible to > avoid > > using SSC mode 2/BBM for applications that use MPTCP, by adjusting SSC > > policies for those applications. (At this time it is not clear if will = be > > possible in all cases, e.g. applications may also request a specific > > continuity service using setsc().) > > > > > > > > > > > > **Conclusion** > > > > > > > > A long term solution for cases #1, #2, and possibly other scenarios tha= t > > may emerge later, could be to send a tuple (address type, original IP > > address ID) to the remote peer, over MPTCP. > > I think we should avoid exposing 5G-specific information in MPTCP and (if > really needed) rather abstract those mechanics away into a more generic > format. > > [xdf] Yes, the solution should be as general as possible. By the way, the address types are DMM-specific, not 5G-specific, so maybe it's less of a problem. So far, the problem to solve is that "session continuity" supporting addresses behave as a single "logical address" that evolves over time (sometimes with a break, sometimes with an overlap, and sometimes with an additional temporary address). So using session-continuity specific parameters may be acceptable (although I agree it's possible MPTCP will only need more general mechanisms, in which case session-continuity specific mechanics will only be implemented on the client side). > > This information would be > > associated with options that can introduce a new IP address, like > ADD_ADDR, > > MP_JOIN, MP_CAPABLE. Nevertheless, experiments will be needed to > determine > > if it is really needed, or if a local usage of this information on the > > client side is enough. Since 5G deployments are not yet common, it will > > take time. Thus it may be best to rely on the experimental extension > > mechanism, and possibly make sure some minimal support is in place in > > rfc6824bis. > > It seems to me that those 5G constructs could be expressed in generic > scheduling policies. In general, this is currently a missing piece in > MPTCP. > In the sense that a client connecting to a server has no fine-grained > control over how the server is scheduling data. With today's special > purpose > deployments (where clients know exactly what server they are connecting > to), > it's not a big problem. But for a more generic deployment of MPTCP it wou= ld > be useful to allow more fine-grained control. > > Maybe that would be a good work-item for the working-group's next steps > (?). > > [xdf] It could be a good work item (session continuity support could be a use case of a more general problem). Btw, I hope that the rfc6824bis authors will consider the proposal below ("clean remove" documentation and support for extension). This would make it easier to experiment as part of the work item, in the future. The impact is minimal: proposal (1) does not require any change in the protocol, just document a practice, and proposal (2) is just to clarify what's happening with extensions. Xavier. > Christoph > > > > > > > > > Proposal: > > > > > > > > (1) Document, in rfc6824bis, a =E2=80=9Cclean remove=E2=80=9D of a live= address =E2=80=93 this > will > > enable dealing with the most obvious case #1 (SSC mode 3). > > > > - Basically, this can use the mechanism described above. Either now or > in a > > future version of the protocol, it could make sense to avoid corner cas= es > > (e.g. use a new =E2=80=9Cinactive=E2=80=9D priority for subflows, and p= ossibly a new > reason > > code =E2=80=9Cinactive address=E2=80=9D when closing the subflows). > > > > > > > > (2) Could we make sure that experimental extensions are available in th= e > > new version of the MPTCP protocol? > > > > - Additional question: do you think it will be acceptable to mandate > > sending an extension option within the same packet as another MPTCP > option? > > It would be convenient to place the address type extension within the > same > > packet used to transmit the option it extends (e.g. ADD_ADDR, MP_JOIN, > > MP_CAPABLE). This would ensure that there is no sync issue between them= , > > due to timing issue or packet loss, and there will be no need to > explicitly > > deal with re-transmission of this particular extension option. > > > > > > > > Best Regards, > > > > > > > > Xavier. > > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp > > --000000000000e98de70572753297 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Christoph,

On Wed, Aug 1, 2018 at 1:44 PM, Chris= toph Paasch <cpaasch@apple.com> wrote:
Hello,

On 30/07/18 - 15:03:27, Xavier de Foy wrote:
> Hi,
>
> As promised during the MPTCP meeting session at IETF 102, here is a su= mmary
> of our findings related to 5G session continuity support, as part of t= he
> review of rfc6824bis.
>
>
>
> The root problem is the following: in 5G, a client may have IP address= es
> provided by a mobile network, in association with a session continuity=
> service (SCC mode 1/fixed, 2/distributed anchor + BBM or 3/ distribute= d
> anchor + MBB). Such an IP address can be replaced, or be complemented = with,
> another IP address, possibly multiple times during the lifetime of an<= br> > application session. If the MPTCP stack is not aware of this, it can= =E2=80=99t make
> the link between these addresses, and can=E2=80=99t make the correct o= r most
> efficient decisions in some cases.
>
>
>
> I think there is at least a case for _local_ usage of session continui= ty
> information by the 5G device MPTCP stack.=C2=A0 Every new IP address c= an
> (locally) be associated with a tuple (address type, original IP addres= s),
> using the DMM-defined =E2=80=9Caddress types=E2=80=9D which have a 1:1= relationship with
> the 3GPP SCC modes. For example, using this information, a MPTCP local=
> stack can copy the backup priority property from one IP address to the= next
> when appropriate.
>
>
>
> **Rationale to send new information over MPTCP (and workarounds) ** >
>
>
> In addition to the local usage of this information, here are possible<= br> > scenarios where sending the tuple (address type, original IP address I= D)
> over MPTCP signaling may help the remote peer making appropriate decis= ions:
>
>
>
> Case #1: the IP address in active use is over SSC mode 3/MBB, and ther= e is
> a MBB handover:
>
> - We want both MPTCP peers to start using new path(s) using the new IP=
> address, then wait for its bandwidth usage to ramp up, and, after some=
> time, cleanly remove the old IP address (cleanly =3D not losing/re-sen= ding
> packets). This is for a smooth transition in term of performance, and = to
> release network resources associated with the old IP address. If both = peers
> have access to the tuple (address type, original IP address), they can= both
> perform these actions. After a while, one side can close the now unuse= d
> subflow(s), and then remove the IP address.
>
> - Possible workaround/solution: there is no need to send the tuple ove= r
> MPTCP signaling, if the MPTCP client has the possibility to request a = clean
> shutdown of old paths/addresses. When discussing this with Christoph, = he
> proposed a quick way to implement a clean shutdown, if I recall correc= tly:
> (1) set the priority of subflows using this address to =E2=80=9Cbackup= =E2=80=9D, (2) wait
> for in-flight TCP segments to arrive and be acked, (3) remove the IP > address. See below in conclusion for additional details on this.
>
>
>
> Case #2: on the client, the IP address in active use is over SSC mode<= br> > 2/BBM, and there is another backup IP address:
>
> - If no change is made, during the break before make, the peers will s= witch
> to use the backup IP address. This may not be the desired outcome (e.g= .
> waking up a radio for a few packets, and changing the properties of th= e
> path for a very short period of time).

This here would basically mean that we want to add an additiona= l "latency"
to the backup-bit information. This latency would mean that even if there are no other paths available, a host should wait a bit more before sending<= br> on the subflow marked as backup.

[xdf] = agreed. Having a finite latency parameter (instead of an "inactive pri= ority", which would be equivalent to an infinite latency) would help h= andling cases where the BBM handover fails. It could also be used as a prio= rity mechanism between multiple backup subflows.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
> Sending the tuple (address type,
> original IP address) as above enables avoiding this situation.
>
> - Possible workaround/solution: in 5G systems, it may be possible to a= void
> using SSC mode 2/BBM for applications that use MPTCP, by adjusting SSC=
> policies for those applications. (At this time it is not clear if will= be
> possible in all cases, e.g. applications may also request a specific > continuity service using setsc().)
>
>
>
>
>
> **Conclusion**
>
>
>
> A long term solution for cases #1, #2, and possibly other scenarios th= at
> may emerge later, could be to send a tuple (address type, original IP<= br> > address ID) to the remote peer, over MPTCP.

I think we should avoid exposing 5G-specific information in MPTCP an= d (if
really needed) rather abstract those mechanics away into a more generic
format.

[xdf] Yes, the solution shoul= d be as general as possible. By the way,=20 the address types are DMM-specific, not 5G-specific, so maybe it's less= of a problem.

So far, the problem to solve is= that "session continuity" supporting addresses behave as a singl= e "logical address" that evolves over time (sometimes with a brea= k, sometimes with an overlap, and sometimes with an additional temporary ad= dress). So using session-continuity specific parameters may be acceptable (= although I agree it's possible MPTCP will only need more general mechan= isms, in which case session-continuity specific mechanics will only be impl= emented on the client side).

=C2=A0
> This information would be
> associated with options that can introduce a new IP address, like ADD_= ADDR,
> MP_JOIN, MP_CAPABLE. Nevertheless, experiments will be needed to deter= mine
> if it is really needed, or if a local usage of this information on the=
> client side is enough. Since 5G deployments are not yet common, it wil= l
> take time. Thus it may be best to rely on the experimental extension > mechanism, and possibly make sure some minimal support is in place in<= br> > rfc6824bis.

It seems to me that those 5G constructs could be expressed in generi= c
scheduling policies. In general, this is currently a missing piece in MPTCP= .
In the sense that a client connecting to a server has no fine-grained
control over how the server is scheduling data. With today's special pu= rpose
deployments (where clients know exactly what server they are connecting to)= ,
it's not a big problem. But for a more generic deployment of MPTCP it w= ould
be useful to allow more fine-grained control.

Maybe that would be a good work-item for the working-group's next steps= (?).

[xdf] It could be a good work item (session continuit= y support could be a use case of a more general problem).
Btw, I hope that the=20 rfc6824bis authors will consider the proposal= below ("clean remove" documentation and support for extension).= =20 This would make it easier to experiment as part of the work item, in the fu= ture. The impact is minimal: proposal (1) does not require any change in th= e protocol, just document a practice, and proposal (2) is just to clarify w= hat's happening with extensions.

Xavier.


Christoph

>
>
>
> Proposal:
>
>
>
> (1) Document, in rfc6824bis, a =E2=80=9Cclean remove=E2=80=9D of a liv= e address =E2=80=93 this will
> enable dealing with the most obvious case #1 (SSC mode 3).
>
> - Basically, this can use the mechanism described above. Either now or= in a
> future version of the protocol, it could make sense to avoid corner ca= ses
> (e.g. use a new =E2=80=9Cinactive=E2=80=9D priority for subflows, and = possibly a new reason
> code =E2=80=9Cinactive address=E2=80=9D when closing the subflows). >
>
>
> (2) Could we make sure that experimental extensions are available in t= he
> new version of the MPTCP protocol?
>
> - Additional question: do you think it will be acceptable to mandate > sending an extension option within the same packet as another MPTCP op= tion?
> It would be convenient to place the address type extension within the = same
> packet used to transmit the option it extends (e.g. ADD_ADDR, MP_JOIN,=
> MP_CAPABLE). This would ensure that there is no sync issue between the= m,
> due to timing issue or packet loss, and there will be no need to expli= citly
> deal with re-transmission of this particular extension option.
>
>
>
> Best Regards,
>
>
>
> Xavier.

> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/mu= ltipathtcp


--000000000000e98de70572753297-- From nobody Mon Aug 6 15:25:38 2018 Return-Path: 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 33352124C04 for ; Mon, 6 Aug 2018 15:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ofxpQfkJh9yE for ; Mon, 6 Aug 2018 15:25:35 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E60A12DD85 for ; Mon, 6 Aug 2018 15:25:33 -0700 (PDT) Received: from mail-it0-f43.google.com (mail-it0-f43.google.com [209.85.214.43]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2BEB52782DE for ; Tue, 7 Aug 2018 07:25:31 +0900 (JST) Received: by mail-it0-f43.google.com with SMTP id v71-v6so20419582itb.3 for ; Mon, 06 Aug 2018 15:25:31 -0700 (PDT) X-Gm-Message-State: AOUpUlFpuEMWZ+leW2DM3GBQadDfXWmQWgG4kchib0HGKUxgZGf2HaT1 lLuBOPn97wsxiHuGhT8ypcd9GWG3OiTlOYY2dWY= X-Google-Smtp-Source: AAOMgpfn7P1ygiVFh6lRVW2WFoIew49rfjbq+GLjFJaJKKZvcGUrMB1e+JMV9AHT6cTv8sszE9tvLJ5ccT4ns0tntco= X-Received: by 2002:a02:1103:: with SMTP id 3-v6mr13863549jaf.144.1533594329963; Mon, 06 Aug 2018 15:25:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7599:0:0:0:0:0 with HTTP; Mon, 6 Aug 2018 15:25:29 -0700 (PDT) In-Reply-To: <2FB78E5E-961F-4077-815F-158142B8E7E2@gmail.com> References: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> <92A53501-4728-4E02-816A-92CEE703AA49@gmail.com> <20754FD9-627F-4AAC-A1B5-6EF2BD09B2AD@gmail.com> <982B626E107E334DBE601D979F31785C5DC5D84B@BLREML503-MBS.china.huawei.com> <982B626E107E334DBE601D979F31785C5DC6884D@BLREML503-MBS.china.huawei.com> <2FB78E5E-961F-4077-815F-158142B8E7E2@gmail.com> From: Yoshifumi Nishida Date: Mon, 6 Aug 2018 15:25:29 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Alan Ford Cc: Rahul Arvind Jadhav , Christoph Paasch , multipathtcp Content-Type: multipart/alternative; boundary="0000000000004465ac0572cbc121" Archived-At: Subject: Re: [multipathtcp] 6824bis -11 review X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 22:25:37 -0000 --0000000000004465ac0572cbc121 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 31, 2018 at 5:07 AM, Alan Ford wrote: > Hi Rahul, all, > > > On 31 Jul 2018, at 01:21, Rahul Arvind Jadhav > wrote: > > c) sending a new ADD_ADDR with same ID + address and different port is fi= ne > [RJ] again this is what the text already says, but I=E2=80=99m not still = clear > about this. Why ID + address has to match? Only ID should be enough. > > Consider: > > a) ADD_ADDR comes in saying ID=3D2, addr=3D10.0.0.1 (private) > b) MP_JOIN comes in saying ID=3D2, addr=3D8.9.10.11 (public) > c) ADD_ADDR comes in saying ID=3D2, addr=3D192.168.0.1 > > What does this mean? Is (c) an implicit REMOVE+ADD? And thus does this > mean the subflow created in (b) is now no longer valid? > > By keeping the address / ID mapping, if an address is lost, then so is th= e > subflow. > > [RJ2] Rather than viewing ( c) as an implicit REMOVE+ADD, can we see it a= s > an UPDATE? Because ID remains same. Subflow created in (b) remains valid > (not sure if I=E2=80=99m missing anything here, I see no reason to lose t= his > subflow). > In step ( c), the receiver can override Address field in context to ID=3D= 2 > to the new addr (192.168.0.1) =E2=80=A6=E2=80=A6 8.9.10.11 is kept sepa= rately as the > learnt actual rcvd IP (from MP_JOIN) in the same context ID=3D2. We have = to > agree that an implementation needs to maintain this IP separately in > context to ID=3D2 anyways. > So if we do an explicit REMOVE+ADD, the end result is the same as this > UPDATE (but with much less overhead & impl ease). > > > I would be interested in hearing from other implementers here=E2=80=A6 Is= there an > issue with =E2=80=9Cupdating=E2=80=9D using ADD_ADDR? > > Given we say that REMOVE_ADDR should not remove a subflow if it=E2=80=99s= still > alive, we have precedent for implying a subflow can exist to an address > which does not have an Address ID - to - IP address mapping. > > So given that, does updating, as Rahul suggests, cause a problem? > > Hmm.. I am wondering why we want to re-use the same address ID while we have 0-255 values for it? Do we have some advantage for it? I thought picking up a new ID would be safer and simpler.. As Alan mentioned, when we try to "update" the address ID, we will have to keep both addresses until we confirm that old one is not used anymore. Also, in the case described above, what will happen if (b) was delayed and arrived after (c)? Thanks, -- Yoshi --0000000000004465ac0572cbc121 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 31, 2018 at 5:07 AM, Alan Ford <alan.ford@gmail.com&= gt; wrote:
Hi Rahul, all,


On 31 Jul 2018, at 01:21, R= ahul Arvind Jadhav <rahul.jadhav@huawei.com> wrote:
=C2=A0
=
c) sending a new ADD_ADDR with same ID + address a= nd different port is fine
[RJ] again this is what the text already says, but I=E2= =80=99m not still clear about this. Why ID + address has to match? Only ID = should be enough.=C2=A0
=C2=A0
Consider:
=C2=A0
a) ADD_ADDR comes i= n saying ID=3D2, addr=3D10.0.0.1 (private)
b) MP_JOIN comes in saying ID=3D2, addr=3D8.9.10.11 = (public)
c) ADD_ADDR= comes in saying ID=3D2, addr=3D192.168.0.1
<= div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:"Times= New Roman",serif">=C2=A0
What does this mean? Is (c) an implicit REMOVE+ADD? And thus doe= s this mean the subflow created in (b) is now no longer valid?
=C2=A0
=
By keeping the address / ID mapping, if an ad= dress is lost, then so is the subflow.
=C2=A0
<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73= ,125)">[RJ2] Rather than viewing ( c) as an implicit REMOVE+ADD, can we see= it as an UPDATE? Because ID remains same. Subflow created in (b) remains v= alid (not sure if I=E2=80=99m missing anything here, I see no reason to los= e this subflow).
In step ( c), the receiver can override Address field in context to ID=3D2= to the new addr (192.168.0.1) =E2=80=A6=E2=80=A6=C2=A0=C2=A0 8.9.10.11 is = kept separately as the learnt actual rcvd IP (from MP_JOIN) in the same con= text ID=3D2. We have to agree that an implementation needs to maintain this= IP separately in context to ID=3D2 anyways.
So if we do an explicit REMOVE+ADD, the end re= sult is the same as this UPDATE (but with much less overhead & impl eas= e).

I= would be interested in hearing from other implementers here=E2=80=A6 Is th= ere an issue with =E2=80=9Cupdating=E2=80=9D using ADD_ADDR?

=
Given we say that REMOVE_ADDR should not remove a subflow if it= =E2=80=99s still alive, we have precedent for implying a subflow can exist = to an address which does not have an Address ID - to - IP address mapping.<= /div>

So given that, does updating, as Rahul suggests, c= ause a problem?


= Hmm.. I am wondering why we want to re-use the same address ID while we hav= e 0-255 values for it?
Do we have some advantage for it? I though= t picking up a new ID would be safer and simpler..=C2=A0
As Alan = mentioned, when we try to "update" the address ID, we will have t= o keep both addresses until we confirm that old one is not used anymore.
Also, in the case described above, what will happen if (b) was dela= yed and arrived after (c)?=C2=A0

Thanks,
--
Yoshi



=



--0000000000004465ac0572cbc121-- From nobody Wed Aug 8 08:20:42 2018 Return-Path: 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 D8B3312F1A6 for ; Wed, 8 Aug 2018 08:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 d5bf9dfZ2Iz7 for ; Wed, 8 Aug 2018 08:20:39 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 9AF9F130E12 for ; Wed, 8 Aug 2018 08:20:38 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6CBFA2A6619AA for ; Wed, 8 Aug 2018 16:20:34 +0100 (IST) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 8 Aug 2018 16:20:35 +0100 Received: from BLREML503-MBS.china.huawei.com ([169.254.12.219]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0399.000; Wed, 8 Aug 2018 20:50:22 +0530 From: Rahul Arvind Jadhav To: Yoshifumi Nishida , Alan Ford CC: Christoph Paasch , multipathtcp Thread-Topic: [multipathtcp] 6824bis -11 review Thread-Index: AdQmJDYhfu15UAaeTxKUY+EC058bGgARMycAAAG8pgAAHRK/4ABC3E6AAByWRxAADbbYAAFDWGaAAF8gGhA= Date: Wed, 8 Aug 2018 15:20:21 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DC70CFF@BLREML503-MBS.china.huawei.com> References: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> <92A53501-4728-4E02-816A-92CEE703AA49@gmail.com> <20754FD9-627F-4AAC-A1B5-6EF2BD09B2AD@gmail.com> <982B626E107E334DBE601D979F31785C5DC5D84B@BLREML503-MBS.china.huawei.com> <982B626E107E334DBE601D979F31785C5DC6884D@BLREML503-MBS.china.huawei.com> <2FB78E5E-961F-4077-815F-158142B8E7E2@gmail.com> In-Reply-To: Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.157.44] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DC70CFFBLREML503MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [multipathtcp] 6824bis -11 review X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 15:20:41 -0000 --_000_982B626E107E334DBE601D979F31785C5DC70CFFBLREML503MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIGZpbmQgbXkgcmVzcG9uc2UgW1JKM10gaW5saW5lLg0KDQpCZXN0LA0KUmFodWwNCg0K DQpPbiAzMSBKdWwgMjAxOCwgYXQgMDE6MjEsIFJhaHVsIEFydmluZCBKYWRoYXYgPHJhaHVsLmph ZGhhdkBodWF3ZWkuY29tPG1haWx0bzpyYWh1bC5qYWRoYXZAaHVhd2VpLmNvbT4+IHdyb3RlOg0K DQpjKSBzZW5kaW5nIGEgbmV3IEFERF9BRERSIHdpdGggc2FtZSBJRCArIGFkZHJlc3MgYW5kIGRp ZmZlcmVudCBwb3J0IGlzIGZpbmUNCltSSl0gYWdhaW4gdGhpcyBpcyB3aGF0IHRoZSB0ZXh0IGFs cmVhZHkgc2F5cywgYnV0IEnigJltIG5vdCBzdGlsbCBjbGVhciBhYm91dCB0aGlzLiBXaHkgSUQg KyBhZGRyZXNzIGhhcyB0byBtYXRjaD8gT25seSBJRCBzaG91bGQgYmUgZW5vdWdoLg0KDQpDb25z aWRlcjoNCg0KYSkgQUREX0FERFIgY29tZXMgaW4gc2F5aW5nIElEPTIsIGFkZHI9MTAuMC4wLjEg KHByaXZhdGUpDQpiKSBNUF9KT0lOIGNvbWVzIGluIHNheWluZyBJRD0yLCBhZGRyPTguOS4xMC4x MSAocHVibGljKQ0KYykgQUREX0FERFIgY29tZXMgaW4gc2F5aW5nIElEPTIsIGFkZHI9MTkyLjE2 OC4wLjENCg0KV2hhdCBkb2VzIHRoaXMgbWVhbj8gSXMgKGMpIGFuIGltcGxpY2l0IFJFTU9WRStB REQ/IEFuZCB0aHVzIGRvZXMgdGhpcyBtZWFuIHRoZSBzdWJmbG93IGNyZWF0ZWQgaW4gKGIpIGlz IG5vdyBubyBsb25nZXIgdmFsaWQ/DQoNCkJ5IGtlZXBpbmcgdGhlIGFkZHJlc3MgLyBJRCBtYXBw aW5nLCBpZiBhbiBhZGRyZXNzIGlzIGxvc3QsIHRoZW4gc28gaXMgdGhlIHN1YmZsb3cuDQoNCltS SjJdIFJhdGhlciB0aGFuIHZpZXdpbmcgKCBjKSBhcyBhbiBpbXBsaWNpdCBSRU1PVkUrQURELCBj YW4gd2Ugc2VlIGl0IGFzIGFuIFVQREFURT8gQmVjYXVzZSBJRCByZW1haW5zIHNhbWUuIFN1YmZs b3cgY3JlYXRlZCBpbiAoYikgcmVtYWlucyB2YWxpZCAobm90IHN1cmUgaWYgSeKAmW0gbWlzc2lu ZyBhbnl0aGluZyBoZXJlLCBJIHNlZSBubyByZWFzb24gdG8gbG9zZSB0aGlzIHN1YmZsb3cpLg0K SW4gc3RlcCAoIGMpLCB0aGUgcmVjZWl2ZXIgY2FuIG92ZXJyaWRlIEFkZHJlc3MgZmllbGQgaW4g Y29udGV4dCB0byBJRD0yIHRvIHRoZSBuZXcgYWRkciAoMTkyLjE2OC4wLjEpIOKApuKApiAgIDgu OS4xMC4xMSBpcyBrZXB0IHNlcGFyYXRlbHkgYXMgdGhlIGxlYXJudCBhY3R1YWwgcmN2ZCBJUCAo ZnJvbSBNUF9KT0lOKSBpbiB0aGUgc2FtZSBjb250ZXh0IElEPTIuIFdlIGhhdmUgdG8gYWdyZWUg dGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBuZWVkcyB0byBtYWludGFpbiB0aGlzIElQIHNlcGFyYXRl bHkgaW4gY29udGV4dCB0byBJRD0yIGFueXdheXMuDQpTbyBpZiB3ZSBkbyBhbiBleHBsaWNpdCBS RU1PVkUrQURELCB0aGUgZW5kIHJlc3VsdCBpcyB0aGUgc2FtZSBhcyB0aGlzIFVQREFURSAoYnV0 IHdpdGggbXVjaCBsZXNzIG92ZXJoZWFkICYgaW1wbCBlYXNlKS4NCg0KSSB3b3VsZCBiZSBpbnRl cmVzdGVkIGluIGhlYXJpbmcgZnJvbSBvdGhlciBpbXBsZW1lbnRlcnMgaGVyZeKApiBJcyB0aGVy ZSBhbiBpc3N1ZSB3aXRoIOKAnHVwZGF0aW5n4oCdIHVzaW5nIEFERF9BRERSPw0KDQpHaXZlbiB3 ZSBzYXkgdGhhdCBSRU1PVkVfQUREUiBzaG91bGQgbm90IHJlbW92ZSBhIHN1YmZsb3cgaWYgaXTi gJlzIHN0aWxsIGFsaXZlLCB3ZSBoYXZlIHByZWNlZGVudCBmb3IgaW1wbHlpbmcgYSBzdWJmbG93 IGNhbiBleGlzdCB0byBhbiBhZGRyZXNzIHdoaWNoIGRvZXMgbm90IGhhdmUgYW4gQWRkcmVzcyBJ RCAtIHRvIC0gSVAgYWRkcmVzcyBtYXBwaW5nLg0KDQpTbyBnaXZlbiB0aGF0LCBkb2VzIHVwZGF0 aW5nLCBhcyBSYWh1bCBzdWdnZXN0cywgY2F1c2UgYSBwcm9ibGVtPw0KDQoNCkhtbS4uIEkgYW0g d29uZGVyaW5nIHdoeSB3ZSB3YW50IHRvIHJlLXVzZSB0aGUgc2FtZSBhZGRyZXNzIElEIHdoaWxl IHdlIGhhdmUgMC0yNTUgdmFsdWVzIGZvciBpdD8NCkRvIHdlIGhhdmUgc29tZSBhZHZhbnRhZ2Ug Zm9yIGl0PyBJIHRob3VnaHQgcGlja2luZyB1cCBhIG5ldyBJRCB3b3VsZCBiZSBzYWZlciBhbmQg c2ltcGxlci4uDQoNCltSSjNdOiBUaGFua3MgZm9yIGNvdmVyaW5nIHRoaXMgYW5nbGUuIE5vdyBp ZiB3ZSBkbyBub3QgcmUtdXNlIHRoZSBzYW1lIGFkZHJlc3MgSUQgdGhlbiB0aGUgc2NlbmFyaW9z IGFyZSBkaWZmZXJlbnQuIFdoYXQgaGFwcGVucyB3aGVuIFJFTU9WRV9BRERSIHNlbnQgZm9yIHBy ZXZpb3VzIElEIGlzIGlnbm9yZWQgYmVjYXVzZSB0aGUgZmxvdyBpcyBhY3RpdmUgb24gdGhlIHJl Y2VpdmVyPyBUaGUgbmV3IEFERF9BRERSIHdpdGggbmV3IElEIHdpbGwgcmVzdWx0IGluIG5ldyBJ RCBnZXR0aW5nIGFkZGVkIG9uIHRoZSByZWNlaXZlci4gVGhpcyByZXF1aXJlcyBtb3JlIHN0YXRl IGFjcm9zcyBtdWx0aXBsZSBJRHMsIGFuZCByZXF1aXJlcyBtb3JlIG1lc3NhZ2luZyBzaW5jZSBS RU1PVkVfQUREUiBoYXMgdG8gZG9uZS4gQW5kIHRoZXJlIGlzIHN0aWxsIGFuIHVuY2VydGFpbnR5 IHJlZ2FyZGluZyB3aGF0IGhhcHBlbnMgaWYgdGhlIFJFTU9WRV9BRERSIGlzIGlnbm9yZWQgYmVj YXVzZSB0aGUgb2xkIGZsb3cgaXMgYWN0aXZlLiBUaHVzIHRoaXMgaXMgbm90IHNpbXBsZXIuDQpB RERfQUREUiBkb2luZyBhbiB1cGRhdGUgb24gZXhpc3RpbmcgSUQgaXMgZWFzaWVyIHRvIGltcGxl bWVudCBhbmQgcmVxdWlyZXMgbGVzcyBtZXNzYWdpbmcuDQpUaGVyZSBhcmUgYWR2YW50YWdlcyB3 aXRoIGFuIHVwZGF0ZSBvbiBleGlzdGluZyBJRCB1bmxlc3Mgb3RoZXIgaW1wbGVtZW50ZXJzIGhh dmUgc29tZSBvdGhlciBhbmdsZSB0byBjb3Zlci4NCg0KQXMgQWxhbiBtZW50aW9uZWQsIHdoZW4g d2UgdHJ5IHRvICJ1cGRhdGUiIHRoZSBhZGRyZXNzIElELCB3ZSB3aWxsIGhhdmUgdG8ga2VlcCBi b3RoIGFkZHJlc3NlcyB1bnRpbCB3ZSBjb25maXJtIHRoYXQgb2xkIG9uZSBpcyBub3QgdXNlZCBh bnltb3JlLg0KQWxzbywgaW4gdGhlIGNhc2UgZGVzY3JpYmVkIGFib3ZlLCB3aGF0IHdpbGwgaGFw cGVuIGlmIChiKSB3YXMgZGVsYXllZCBhbmQgYXJyaXZlZCBhZnRlciAoYyk/DQoNCltSSjNdIEni gJltIG5vdCBzdXJlIHdoYXQgaXMgbWVhbnQgYnksIOKAnGNvbmZpcm0gdGhhdCBvbGQgb25lIGlz IG5vdCB1c2VkIGFueW1vcmXigJ0uIEEgcmVjZWl2ZXIgYW55d2F5cyBpcyByZWFkeSB0byByZWNl aXZlIGFuIE1QX0pPSU4gZnJvbSBzb3VyY2UgYWRkcmVzcyBub3QgYWR2ZXJ0aXNlZCBpbiB0aGUg QUREX0FERFIuDQpDb25zaWRlcmluZyB1cGRhdGUgaXMgdXNlZCwuLiBpbiB0aGUgc2NlbmFyaW8g YWJvdmUsIGlmIE1QX0pPSU4gKGIpIGFycml2ZXMgYWZ0ZXIgQUREX0FERFIgdXBkYXRlIChjKSBp cyBpc3N1ZWQsIGl0IHdvdWxkIG5vdCByZXN1bHQgaW4gYW55IG1pc2hhcCBpbW8uDQoNCg== --_000_982B626E107E334DBE601D979F31785C5DC70CFFBLREML503MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlBsZWFzZSBmaW5kIG15 IHJlc3BvbnNlIFtSSjNdIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPkJlc3QsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJhaHVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiAzMSBKdWwgMjAxOCwgYXQgMDE6MjEsIFJhaHVsIEFydmluZCBKYWRoYXYgJmx0Ozxh IGhyZWY9Im1haWx0bzpyYWh1bC5qYWRoYXZAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJh aHVsLmphZGhhdkBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Yykgc2VuZGluZyBhIG5ldyBBRERf QUREUiB3aXRoIHNhbWUgSUQgJiM0MzsgYWRkcmVzcyBhbmQgZGlmZmVyZW50IHBvcnQgaXMgZmlu ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUkpdIGFn YWluIHRoaXMgaXMgd2hhdCB0aGUgdGV4dCBhbHJlYWR5IHNheXMsIGJ1dCBJ4oCZbSBub3Qgc3Rp bGwgY2xlYXIgYWJvdXQgdGhpcy4gV2h5IElEICYjNDM7IGFkZHJlc3MgaGFzIHRvIG1hdGNoPyBP bmx5IElEIHNob3VsZCBiZSBlbm91Z2guJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNvbnNpZGVyOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hKSBB RERfQUREUiBjb21lcyBpbiBzYXlpbmcgSUQ9MiwgYWRkcj0xMC4wLjAuMSAocHJpdmF0ZSk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmIpIE1QX0pPSU4gY29tZXMgaW4gc2F5aW5nIElEPTIsIGFkZHI9OC45LjEwLjExIChw dWJsaWMpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5jKSBBRERfQUREUiBjb21lcyBpbiBzYXlpbmcgSUQ9MiwgYWRkcj0x OTIuMTY4LjAuMTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGRvZXMgdGhpcyBtZWFu PyBJcyAoYykgYW4gaW1wbGljaXQgUkVNT1ZFJiM0MztBREQ/IEFuZCB0aHVzIGRvZXMgdGhpcyBt ZWFuIHRoZSBzdWJmbG93IGNyZWF0ZWQgaW4gKGIpIGlzIG5vdyBubyBsb25nZXIgdmFsaWQ/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ5IGtlZXBpbmcgdGhlIGFkZHJlc3MgLyBJRCBtYXBw aW5nLCBpZiBhbiBhZGRyZXNzIGlzIGxvc3QsIHRoZW4gc28gaXMgdGhlIHN1YmZsb3cuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPltSSjJdIFJhdGhlciB0aGFuIHZpZXdpbmcgKCBjKSBhcyBhbiBpbXBsaWNpdCBSRU1PVkUm IzQzO0FERCwgY2FuIHdlIHNlZSBpdCBhcyBhbiBVUERBVEU/IEJlY2F1c2UgSUQgcmVtYWlucyBz YW1lLiBTdWJmbG93IGNyZWF0ZWQgaW4gKGIpIHJlbWFpbnMgdmFsaWQgKG5vdCBzdXJlDQogaWYg SeKAmW0gbWlzc2luZyBhbnl0aGluZyBoZXJlLCBJIHNlZSBubyByZWFzb24gdG8gbG9zZSB0aGlz IHN1YmZsb3cpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiBzdGVwICggYyks IHRoZSByZWNlaXZlciBjYW4gb3ZlcnJpZGUgQWRkcmVzcyBmaWVsZCBpbiBjb250ZXh0IHRvIElE PTIgdG8gdGhlIG5ldyBhZGRyICgxOTIuMTY4LjAuMSkg4oCm4oCmJm5ic3A7Jm5ic3A7IDguOS4x MC4xMSBpcyBrZXB0IHNlcGFyYXRlbHkgYXMgdGhlIGxlYXJudCBhY3R1YWwNCiByY3ZkIElQIChm cm9tIE1QX0pPSU4pIGluIHRoZSBzYW1lIGNvbnRleHQgSUQ9Mi4gV2UgaGF2ZSB0byBhZ3JlZSB0 aGF0IGFuIGltcGxlbWVudGF0aW9uIG5lZWRzIHRvIG1haW50YWluIHRoaXMgSVAgc2VwYXJhdGVs eSBpbiBjb250ZXh0IHRvIElEPTIgYW55d2F5cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+U28gaWYgd2UgZG8gYW4gZXhwbGljaXQgUkVNT1ZFJiM0MztBREQsIHRoZSBlbmQgcmVz dWx0IGlzIHRoZSBzYW1lIGFzIHRoaXMgVVBEQVRFIChidXQgd2l0aCBtdWNoIGxlc3Mgb3Zlcmhl YWQgJmFtcDsgaW1wbCBlYXNlKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgd291bGQgYmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nIGZyb20gb3Ro ZXIgaW1wbGVtZW50ZXJzIGhlcmXigKYgSXMgdGhlcmUgYW4gaXNzdWUgd2l0aCDigJx1cGRhdGlu Z+KAnSB1c2luZyBBRERfQUREUj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+R2l2ZW4gd2Ugc2F5IHRoYXQgUkVNT1ZFX0FERFIgc2hvdWxkIG5v dCByZW1vdmUgYSBzdWJmbG93IGlmIGl04oCZcyBzdGlsbCBhbGl2ZSwgd2UgaGF2ZSBwcmVjZWRl bnQgZm9yIGltcGx5aW5nIGEgc3ViZmxvdyBjYW4gZXhpc3QgdG8gYW4gYWRkcmVzcyB3aGljaCBk b2VzIG5vdCBoYXZlIGFuIEFkZHJlc3MgSUQgLSB0byAtIElQIGFkZHJlc3MgbWFwcGluZy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gZ2l2 ZW4gdGhhdCwgZG9lcyB1cGRhdGluZywgYXMgUmFodWwgc3VnZ2VzdHMsIGNhdXNlIGEgcHJvYmxl bT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhtbS4uIEkgYW0gd29uZGVyaW5nIHdoeSB3ZSB3YW50 IHRvIHJlLXVzZSB0aGUgc2FtZSBhZGRyZXNzIElEIHdoaWxlIHdlIGhhdmUgMC0yNTUgdmFsdWVz IGZvciBpdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkRvIHdlIGhhdmUgc29tZSBhZHZhbnRhZ2UgZm9yIGl0PyBJIHRob3VnaHQgcGlja2luZyB1 cCBhIG5ldyBJRCB3b3VsZCBiZSBzYWZlciBhbmQgc2ltcGxlci4uJm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltSSjNdOiBUaGFua3MgZm9yIGNvdmVyaW5nIHRoaXMg YW5nbGUuIE5vdyBpZiB3ZSBkbyBub3QgcmUtdXNlIHRoZSBzYW1lIGFkZHJlc3MgSUQgdGhlbiB0 aGUgc2NlbmFyaW9zIGFyZSBkaWZmZXJlbnQuIFdoYXQgaGFwcGVucyB3aGVuIFJFTU9WRV9BRERS IHNlbnQgZm9yIHByZXZpb3VzDQogSUQgaXMgaWdub3JlZCBiZWNhdXNlIHRoZSBmbG93IGlzIGFj dGl2ZSBvbiB0aGUgcmVjZWl2ZXI/IFRoZSBuZXcgQUREX0FERFIgd2l0aCBuZXcgSUQgd2lsbCBy ZXN1bHQgaW4gbmV3IElEIGdldHRpbmcgYWRkZWQgb24gdGhlIHJlY2VpdmVyLiBUaGlzIHJlcXVp cmVzIG1vcmUgc3RhdGUgYWNyb3NzIG11bHRpcGxlIElEcywgYW5kIHJlcXVpcmVzIG1vcmUgbWVz c2FnaW5nIHNpbmNlIFJFTU9WRV9BRERSIGhhcyB0byBkb25lLiBBbmQgdGhlcmUgaXMNCiBzdGls bCBhbiB1bmNlcnRhaW50eSByZWdhcmRpbmcgd2hhdCBoYXBwZW5zIGlmIHRoZSBSRU1PVkVfQURE UiBpcyBpZ25vcmVkIGJlY2F1c2UgdGhlIG9sZCBmbG93IGlzIGFjdGl2ZS4gVGh1cyB0aGlzIGlz IG5vdCBzaW1wbGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BRERfQUREUiBkb2luZyBhbiB1cGRhdGUg b24gZXhpc3RpbmcgSUQgaXMgZWFzaWVyIHRvIGltcGxlbWVudCBhbmQgcmVxdWlyZXMgbGVzcyBt ZXNzYWdpbmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlcmUgYXJlIGFkdmFudGFnZXMgd2l0aCBh biB1cGRhdGUgb24gZXhpc3RpbmcgSUQgdW5sZXNzIG90aGVyIGltcGxlbWVudGVycyBoYXZlIHNv bWUgb3RoZXIgYW5nbGUgdG8gY292ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIEFs YW4gbWVudGlvbmVkLCB3aGVuIHdlIHRyeSB0byAmcXVvdDt1cGRhdGUmcXVvdDsgdGhlIGFkZHJl c3MgSUQsIHdlIHdpbGwgaGF2ZSB0byBrZWVwIGJvdGggYWRkcmVzc2VzIHVudGlsIHdlIGNvbmZp cm0gdGhhdCBvbGQgb25lIGlzIG5vdCB1c2VkIGFueW1vcmUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCBpbiB0aGUgY2FzZSBkZXNjcmli ZWQgYWJvdmUsIHdoYXQgd2lsbCBoYXBwZW4gaWYgKGIpIHdhcyBkZWxheWVkIGFuZCBhcnJpdmVk IGFmdGVyIChjKT8mbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUkozXSBJ4oCZbSBub3Qgc3VyZSB3aGF0 IGlzIG1lYW50IGJ5LCDigJxjb25maXJtIHRoYXQgb2xkIG9uZSBpcyBub3QgdXNlZCBhbnltb3Jl 4oCdLiBBIHJlY2VpdmVyIGFueXdheXMgaXMgcmVhZHkgdG8gcmVjZWl2ZSBhbiBNUF9KT0lOIGZy b20gc291cmNlIGFkZHJlc3Mgbm90IGFkdmVydGlzZWQNCiBpbiB0aGUgQUREX0FERFIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkNvbnNpZGVyaW5nIHVwZGF0ZSBpcyB1c2VkLC4uIGluIHRoZSBzY2VuYXJp byBhYm92ZSwgaWYgTVBfSk9JTiAoYikgYXJyaXZlcyBhZnRlciBBRERfQUREUiB1cGRhdGUgKGMp IGlzIGlzc3VlZCwgaXQgd291bGQgbm90IHJlc3VsdCBpbiBhbnkgbWlzaGFwIGltby48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_982B626E107E334DBE601D979F31785C5DC70CFFBLREML503MBSchi_-- From nobody Wed Aug 8 12:06:04 2018 Return-Path: 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 26A78130ECC for ; Wed, 8 Aug 2018 12:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Fprsp8Geu9sR for ; Wed, 8 Aug 2018 12:06:00 -0700 (PDT) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275F8130EE8 for ; Wed, 8 Aug 2018 12:06:00 -0700 (PDT) Received: by mail-qk0-x242.google.com with SMTP id c192-v6so2276361qkg.12 for ; Wed, 08 Aug 2018 12:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=HjCuY1Dt42SAnnX15p9itNfHHmH/fvGThTpM4hFLQfM=; b=oVXn69t2q7eIyaUCcqhJXLTcrie5XnuB0/dWMz2Kgdlrm1XIr7jUlhz9bfo976omq2 Bt0JSDh2rs/gRPIBmlUmDH580SBHXjgVkFWd2n34QwM7y24Tgq98vbs4o2CUJzCoJLmm pt4rQHXt3k2vnaA7YpNQNVzCsWb2TUGIMV6tcXhE4yTHNlzyndpoCs9mT/5zLlaeMTy5 aEP8PTW2n4kBPnxfsHqdQoBV7emhPxcFlVBz0E4PUlaCVqCM6pbrxK4btihnaJ1MORKV OO/LYG6vPWbjVuf2LzrEU3fhEG63WDf+QNtIfOsffVKzrN47/fmkRpNSxnVNSz1/NAxa wwJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HjCuY1Dt42SAnnX15p9itNfHHmH/fvGThTpM4hFLQfM=; b=e4zPjXp+jaTXg3la9g2heddJ5lpYwx8OQ6cQUeCv5IH8FLO4p0saNankNviZ9uVBA0 da4gTqaaqx2C1vLu7/AzrSs6n9sszgu5Qe90qJORER/rizyD+aMuafW57+f5iP7cyQoV qA66UBOiCgSvZbSQBWXgWikSswV/y7vpkPt0tKIqS1FouSI7rlAKW9sTFflPclMrS18M e4wtEbO4k8i7hf9oWpjZuC4psSAnV+GmC6FHPi1zorxTAq1fCAqBGqBcXqM0jv6HLA19 HlzxmobLehxJtQzzyf/labGa2AtbOEelZqMk/5uwnYsJPBP6h9ePyAY2sc1kD1qrixCj BCyA== X-Gm-Message-State: AOUpUlG3mw/s5Q95Ya/LjDWJyz2t7d9VVwn1Dxzw2kFhheT4rYaeFTqr 6cDn1CZ+ikU4gSWUKtq9MFoR2bPSr9OqNw7kE2X+RBtv X-Google-Smtp-Source: AA+uWPziINB1kaaflfb9CtgT+Ymw7UhhZxV5XXssQN6ijJf2P3n9leGrhwL66do3tSUUxJ6A3E+owJDKsCIyHqZgQFs= X-Received: by 2002:a37:c887:: with SMTP id t7-v6mr3733364qkl.300.1533755158843; Wed, 08 Aug 2018 12:05:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2ea2:0:0:0:0:0 with HTTP; Wed, 8 Aug 2018 12:05:58 -0700 (PDT) From: Xavier de Foy Date: Wed, 8 Aug 2018 15:05:58 -0400 Message-ID: To: multipathtcp Content-Type: multipart/alternative; boundary="0000000000006a573e0572f13350" Archived-At: Subject: [multipathtcp] 6824bis-11 review X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 19:06:03 -0000 --0000000000006a573e0572f13350 Content-Type: text/plain; charset="UTF-8" Hi, as promised at IETF 102, here is a review of the current working version of draft-ietf-mptcp-rfc6824bis-11, which is in very good shape in my opinion. Most of the comments are editorial in nature, or minor clarifications: for those I tried to propose some rewording, but these are for illustration only. There are a few higher level comments and questions as well. It is based on version 6091823... (Jul 30, 2018) of the live Github draft https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis I may not be able to participate in any email discussion for the next 2-3 weeks, but will answer back as soon as I can. Best Regards, Xavier. --- *General - The experimental extension mechanism was removed from the draft. What is the current plan for dealing with experiments? *1. Introduction Minor text cleanup/reorganization: (1) "This document is complemented by three others: [RFC6824]." could be replaced with " This document is complemented by three others: " + (bullet list could go here). And move "This document specifies MPTCP v1..." after the bullet list. (2) s/This document is an update to, and obsoletes, the v0 specification of Multipath TCP/ This document is an update to, and obsoletes, the v0 specification of Multipath TCP ([RFC6824])./ *1.3 Terminology s/similar/similarly/ *2. Operation Overview - s/-- a single numerical type /-- using a single numerical type/ *2.1. Initiating an MPTCP Connection - s/ is variable length / has a variable length / *2.3.Informing the Other Host about Another Potential Address - s/This option contains a HMAC/The ADD_ADDR option contains a HMAC/: (this clarification is proposed because MP_JOIN is mentioned in the previous sentence) *2.4. - In diagram (2.4 and 2.6): replace DATA_SEQUENCE_SIGNAL with DSS, which is the name of the option - s/The "Data Sequence Signal" carries/The Data Sequence Signal (DSS) option carries/ (since this is the first place where DSS is mentioned in the text) *2.7. Notable Features - This is the first mention of "passive opener". Even if it is a well-known concept, it could help to illustrate what is meant in context, e.g. s/passive opener/passive opener (i.e. host that can open a subflow or connection upon reception of initial SYN packet)/. *3.2. Starting a new subflow - Here and in 3 other places in the doc, we find the words "with an appropriate reason code.", while in some other places the exact codes are spelled out. You may want to spell out the appropriate reason codes in these 4 places. *3.3. General MPTCP Operation - " DATA_FIN exchange or a timeout ". Would it help to add a reference to where the timeout case is described? (I guess it is in section 3.3.3) *3.3.3. Closing a connection - "It is also encouraged to reduce the timeouts (Maximum Segment Life) on subflows at end hosts. ": would it make sense to precise: "... at end hosts after receiving a DATA_FIN acknowledgement. " *3.3.1. Data Sequence Mapping - s/analogous/analogously/ - s/for that sequence space ignored/for that sequence space should be ignored/ - s/ISN/Initial Sequence Number (ISN)/ *3.3.8. Subflow Policy - It may be useful to document a clean removal of an active IP address (this technique was suggested by Christoph to address a need for session continuity support). A peer who wish to remove the IP address would start with setting all subflows using this address to "Backup" with MP_PRIO setting the "B" bit. Then the peer wait for in-flight segments to be received and acked on both sides. After this, it can reset the subflow (a new bullet with a description of this technique could be added in section 3.6.) A new subflow reset reason code may also be added in section 8.3. to indicate that a peer took the decision to permanently remove a path, unless an existing one like "administratively prohibited" is deemed sufficient. (this technique is likely to be useful to support session continuity, to stop using the old address in make-before-break cases) - For future improvements of the "clean removal" above, I would suggest considering using another flag for "inactive". "Inactive" would be similar to backup, except that it would never become active, even if no other active subflow exist. I understand it is late for such a change though, which could have unforeseen consequences. *3.4.1. Address Advertisement - s/This is also used to identify MP_JOIN/The address ID is also used to identify MP_JOIN/ - "The Address ID MUST uniquely identify ...": could we precise if the address ID must be unique per peer, or across both peers (i.e. can a same address ID be used for an address on host A and another address on host B)? - "for avoiding the required mapping state": consider clarifying (do you mean that the receiver wish to avoid maintaining a mapping state? It does not look like a root cause, why would the receiver would like to avoid this?) - "In the unlikely event that the token is known": probably need to be qualified better, because if the token is known, that would mean that the MP_JOIN message is legitimate, right? - "If these conditions are not met, the receiver SHOULD silently ignore the ADD_ADDR.": in the next paragraph, it is said that a peer can re-trigger a new subflow attempt by sending an ADD_ADDR (I assume with same address and port), which seems to contradict this statement (" Port MUST be different " is too strict, since same port is a possible case to "refresh" an ADD_ADDR). *3.4.2. Remove Address - In relation with my first comment for section 3.3.8: there can be a use case to remove an IP address which is not yet invalid (e.g. to support session continuity). It could be useful to widen the range of application of REMOVE_ADDR: e.g. add a new sentence at the end of the first paragraph: "A host MAY also choose to announce that a still valid IP address should not be used any longer." In this case, "it must ensure the affected path(s) are no longer in use before it instigates closure. " could be rephrased as "it must ensure the affected active path(s) are no longer in use before it instigates closure (i.e. only active, not backup paths should be checked as follows). " *3.5. Fast Close - Would it make sense to clarify by adding "by sending a TCP RST" in: s/Upon receipt of an ACK with MP_FASTCLOSE by Host B, containing the valid key, Host B answers on the same subflow with a TCP RST and tears down all subflows./Upon receipt of an ACK with MP_FASTCLOSE by Host B, containing the valid key, Host B answers on the same subflow with a TCP RST and tears down all subflows by sending a TCP RST./ *3.6. Subflow Reset - " The "U", "V" and "W" flags are not defined by this specification and are reserved for future use. ": Should we add the same text used for other unused bits, stating these must be set to 0, and must be ignored by receiver? - In relation with my first comment for section 3.3.8: there could be a code for a voluntary decision by a peer to close a path (e.g. for session continuity purpose). For example, its name could be "Path Management Decision" or similar. *3.7. Fallback - In general, in this section I found the flow a bit confusing, mostly at the beginning. Maybe it evolved over time, and you may want to check how the text is organized ("these rules...", "the case described above..." seem to point to some specific cases but it is not obvious which one). For example, about "The case described above is a specialized case of fallback": the text above includes "subflow breaks during operation", which does not fall into the category of fallbacks "...before any data is acknowledged at the connection level on a subflow". - Consider clarifying what is meant by "there is the possibility that false positives could be hit across MPTCP segment boundaries, corrupting the data" - "It is not mandatory for the receiver of an MP_FAIL to also respond with an MP_FAIL" and "However, implementations MAY choose to send a MP_FAIL in the reverse direction and entirely revert to a regular TCP session.": Does an infinite mapping affect a subflow unidirectionally or bidirectionally? This paragraph can lead to some confusion on this point. It may be useful to precise this in section 3.3.1 (last paragraph). Assuming the effect of infinite mapping is bidirectional, the words "and entirely revert to a regular TCP session" are the confusing ones here (since we are reverting to TCP entirely anyway). Probably: the remote peer should (MUST?) send a MP_FAIL if some segments were received with a bad checksum, and otherwise should not (MAY?) send it. *3.8. Error Handling - Is the list of errors complete? (e.g. ADD_ADDR errors seem to belong to the same class as remove request) *3.9.1. Port Usage - s/Add Address/ADD_ADDRESS/ *3.9.2. - s/and thus never use MPTCP./and thus would never use MPTCP based on this heuristic alone./ *4. Semantic Issues - It would be informative to document shortly the reason why SYN and DATA_FIN both occupy 1 octet of data-level sequence space. E.g. "This is to ensure that they are acknowledged at the connection level in data acknowledgements." *6. Interaction with middleboxes - "and the handshake mechanism ensures that connection attempts to private addresses [RFC1918] do not cause problems": consider clarifying this sentence (which part of the handshake mechanism address which potential problems?). - s/However, for an MPTCP-aware IDS, tokens can be read by such systems/However, a MPTCP-aware IDS can read tokens/ - s/reassemble for analysis/reassemble them for analysis/ - s/If a fraction of options are stripped/If a fraction of options is stripped/ (or "if only some of the options are stripped") * Appendix C - s/MPTCP control block/MPTCP protocol control block (PCB)/ (This is to introduce the term MPTCP PCB, which is used in appendix D's diagram) * Appendix D - Consider detailing the text a bit more on the relation of the diagram with "interations with subflow level FINs", and some details on the states involved in "break-before-make" handovers. *Other Editorial comments - s/subfow/subflow/ - s/not longer/no longer/ - s/so long as/as long as/ - s/associated to/associated with/ - s/Lenght/Length/ - A couple of change was needed to generate draft from the github version (there was an extra and a missing reference), here is the diff: $ diff -c rfc6824bis.ori draft-rfc6824bis.xml *** rfc6824bis.ori 2018-08-06 09:39:16.608250000 -0400 --- draft-rfc6824bis.xml 2018-08-06 09:45:09.155126800 -0400 *************** *** 281,287 **** ACK + MP_CAPABLE (+ data) -> [A's key, B's key, flags, (data-level details)] ]]> - Retransmission of the ACK + MP_CAPABLE can occur if it is not known if it has been received. The following diagrams show all possible exchanges for the initial subflow setup to ensure this reliability. --- 281,286 ---- *************** *** 2217,2222 **** --- 2216,2222 ---- &RFC6824; &RFC7413; &RFC7430; + &RFC8174; --0000000000006a573e0572f13350 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=
Hi, as promised at IETF 102, here is a review of=20 the current working version of draft-ietf-mptcp-rfc6824bis-11, which is in very good shape in my opinion. Most of the comments are=20 editorial in nature, or minor clarifications: for those I tried to=20 propose some rewording, but these are for illustration only. There are a few higher level comments and questions as well.

It is based on version 6091823... (Jul 30, 201= 8) of the live Github draft https://github.com/multipath-t<= wbr>cp/draft-ietf-mptcp-rfc6824bis

I may = not be able to participate in any email discussion for the next 2-3 weeks, = but will answer back as soon as I can.

Best= Regards,

Xavier.

---

*General

- The experimental extension mechanism was removed from the draft. What is the current plan for dealing with experiments?


*1. Introduction

Minor text= cleanup/reorganization:

(1) "This docum= ent is complemented by three others: [RFC6824]." could be replaced with " This document is complemented by three others: " + (bullet list could = go here). And move "This document specifies MPTCP v1..." after the = bullet=20 list.
(2) s/This document is an update to, and obsoletes, th= e v0 specification of Multipath TCP/ This document is an update to, and obsoletes, the v0 specification of Multi= path TCP ([RFC6824])./


*1.3 Term= inology

s/similar/similarly/


*2. Operation Overview

- s/-- a single numerical type=20 /-- using a single numerical type/


*2.= 1. Initiating an MPTCP Connection
- s/ is variable length=20 / has a variable length=20 /



*2.3= .Informing the Other Host about Another Potential Address

- s/This option contains a HMAC/The ADD_ADDR option contains a HMAC= /: (this clarification is proposed because MP_JOIN is mentioned in t= he previous sentence)


*2.4.

- In diagram (2.4 and 2.6): = replace DATA_SEQUENCE_SIGNAL with DSS, which is the name of the option

- s/The "Data Sequence Signal" carrie= s/The=20 Data Sequence Signal (DSS) option carries/ (since this is the first place where DSS is mentioned in the text= )


*2.7. Notable Features
<= div>
- This is the first mention of "passive opener". Even if it is a= =20 well-known concept, it could help to illustrate what is meant in context, e= .g. s/passive opener/passive opener (i.e. host that can open = a subflow or connection upon reception of initial SYN packet)/.


*3.2. Starting a = new subflow

- Here and in 3 other places in the doc, we find the words "with an=20 appropriate reason code.", while in some other places the exact codes= =20 are spelled out. You may want to spell out the appropriate reason codes=20 in these 4 places.


*3.3. Genera= l MPTCP Operation

- " DATA_FIN exchange or a timeout ". Would it help to add a reference to where the timeout case is descr= ibed? (I guess it is in section 3.3.3)


*3.3.3. Closing a connection

- "It is also encouraged to reduce the timeouts (Maximum Segment Life) = on subflows at end hosts. ": would it make sense to precise: "... = at end hosts after receiving a DATA_FIN acknowledgement. "
<= /div>


*3.3.1. Data Sequence Mapping

- s/analogous/analogously/

- s/for that sequence space ignored/for that sequence space should be igno= red/

- s/ISN/Initial Sequence Number (ISN)/


*3.3.8. Subflow Policy
=
- It may be useful to document a clean removal of an active IP address=20 (this technique was suggested by Christoph to address a need for session continuity support). A peer who wish to remove the IP address would=20 start with setting all subflows using this address to "Backup" wi= th=20 MP_PRIO setting the "B" bit. Then the peer wait for in-flight seg= ments=20 to be received and acked on both sides. After this, it can reset the=20 subflow (a new bullet with a description of this technique could be=20 added in section 3.6.) A new subflow reset reason code may also be added in section 8.3. to indicate that a peer took the decision to=20 permanently remove a path, unless an existing one like "administrative= ly prohibited" is deemed sufficient.
= (this technique is likely to be useful to support session continuity, to st= op using the old address in make-before-break cases)

- For future improvements of the "clean removal" above, I would su= ggest=20 considering using another flag for "inactive". "Inactive&quo= t; would be=20 similar to backup, except that it would never become active, even if no=20 other active subflow exist. I understand it is late for such a change=20 though, which could have unforeseen consequences.


*3.4.1. Address Advertisement<= br>

- s/This is also used to identify MP_JOIN/The = address ID is also used to identify MP_JOIN/

- "The Address ID MUST uniquely identify ...": could we precise if= the=20 address ID must be unique per peer, or across both peers (i.e. can a=20 same address ID be used for an address on host A and another address on=20 host B)?

- "for avoiding the required mapping= =20 state": consider clarifying (do you mean that the receiver wish to avo= id maintaining a mapping state? It does not look like a root cause, why=20 would the receiver would like to avoid this?)

- "In the unlikely event that the token is known": probably need t= o be=20 qualified better, because if the token is known, that would mean that=20 the MP_JOIN message is legitimate, right?

- "= If these conditions are not met, the receiver SHOULD silently ignore the=20 ADD_ADDR.": in the next paragraph, it is said that a peer can re-trigg= er a new subflow attempt by sending an ADD_ADDR (I assume with same=20 address and port), which seems to contradict this statement (" Port MUST be different=20 " is too strict, since same port is a possible case to "refresh&q= uot; an=20 ADD_ADDR).


=
*3.4.2. Remove Address

- In relation with my first comment for section 3.3.8: there can be a use case to remove an IP address which is not yet invalid (e.g. to support=20 session continuity). It could be useful to widen the range of=20 application of REMOVE_ADDR: e.g. add a new sentence at the end of the=20 first paragraph: "A host MAY also choose to announce that a still vali= d=20 IP address should not be used any longer."

=
In this case, "it must ensure the affected path(s) are no longer in use= =20 before it instigates closure. " could be rephrased as "it must en= sure=20 the affected active path(s) are no longer in use before it instigates=20 closure (i.e. only active, not backup paths should be checked as=20 follows). "


*3.5. Fast Close

- Would it make sense to clarify by adding "by sending a TCP RST" = in:=20 s/Upon receipt of an ACK with MP_FASTCLOSE by Host B, containing the=20 valid key, Host B answers on the same subflow with a TCP RST and tears=20 down all subflows./Upon receipt of an ACK with MP_FASTCLOSE by Host B,=20 containing the valid key, Host B answers on the same subflow with a TCP=20 RST and tears down all subflows by sending a TCP RST./


*3.6. Subflow Reset

- &quo= t; The "U", "V" and "W" flags are not defined by= this specification and are reserved for future use. ": Should we add the same text used for other unused bits, stating the= se must be set to 0, and must be ignored by receiver?

= - In relation with my first comment for section 3.3.8: there could be a code for a voluntary decision by a peer to close a path (e.g. for session continuity purpose). For example, its name could be=20 "Path Management Decision" or similar.


*3.7. Fallback

- In general, in this section I found the flow a bit confusing, mostly at the beginning. Maybe it evolved over time, and you may want to check=20 how the text is organized ("these rules...", "the case descr= ibed=20 above..." seem to point to some specific cases but it is not obvious= =20 which one).
For example, about "The case describe= d=20 above is a specialized case of fallback": the text above includes=20 "subflow breaks during operation", which does not fall into the c= ategory of fallbacks "...before any data is acknowledged at the connection=20 level on a subflow".

- Consider clarifying what is meant by "there is the possibility that false positives could = be hit across MPTCP segment boundaries, corrupting the data"
<= br>
- "It is not mandatory for the receiver of an MP_FAIL to also respond= =20 with an MP_FAIL" and "However, implementations MAY choose to send= a=20 MP_FAIL in the reverse direction and entirely revert to a regular TCP=20 session.": Does an infinite mapping affect a subflow unidirectionally = or bidirectionally? This paragraph can lead to some confusion on this point. = It may be=20 useful to precise this in section 3.3.1 (last paragraph). Assuming the=20 effect of infinite mapping is bidirectional, the words "and entirely= =20 revert to a regular TCP session" are the confusing ones here (since we= are reverting=20 to TCP entirely anyway). Probably: the remote peer should (MUST?) send a MP_FAIL if some segments were received with a bad checksum, and=20 otherwise should not (MAY?) send it.


*3.8. Error Handling

- Is the list of errors complete? (e.g. ADD_ADDR errors seem to belong to= the same class as remove request)


<= div>*3.9.1. Port Usage

- s/Add Address/ADD_ADDRESS= /


*3.9.2.

- s/and thus never use MPTCP./and thus would never use MPTCP based= on this heuristic alone./


*4. Semantic Issues
- It would be informative to document shortly the reason why SYN and=20 DATA_FIN both occupy 1 octet of data-level sequence space. E.g. "This = is to ensure that they are acknowledged at the connection level in data=20 acknowledgements."


*6. Interaction with midd= leboxes

- "and the handshake mechanism ensures that connection attempts to=20 private addresses [RFC1918] do not cause problems": consider clarifyin= g=20 this sentence (which part of the handshake mechanism address which=20 potential problems?).

- s/However, for an MPTCP-aware IDS, tokens can be read by such sy= stems/However, a MPTCP-aware IDS can read tokens/
- s/reassemble for analysis/reassemble t= hem for analysis/
- s/If a fraction of options are strippe= d/If a fraction of options is stripped/ (or "if only some of the optio= ns are stripped")


*= Appendix C

- s/MPTCP control block/MPTCP protocol= control block (PCB)/
(This is to introdu= ce the term MPTCP PCB, which is used in appendix D's diagram)
=


* Appendix D

=
- Consider detailing the text a bit more on the relation of the diagram=20 with "interations with subflow level FINs", and some details on t= he=20 states involved in=20 = = "break-before-make" handovers.

=

*Other Editorial comments

- s/subfow/subflow/
- s/not longer/no longer/
- s/so long as/as long as/<= br>
- s/associated to/associated with/
- s/Lengh= t/Length/
<= br>
- A couple of change was needed to generate draft from the github version (there was an extra </section> and a missing reference), here is=20 the diff:

$ diff -c rfc6824bis.ori draft-rfc6824bi= s.xml
*** rfc6824bis.ori=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2018-08-06 09:39:= 16.608250000 -0400
--- draft-rfc6824bis.xml=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 2018-08-06 09:45:09.155126800 -0400
***************
*= ** 281,287 ****
=C2=A0=C2=A0=C2=A0=C2=A0 ACK + MP_CAPABLE (+ data) ->=
=C2=A0=C2=A0=C2=A0=C2=A0 [A's key, B's key, flags, (data-level = details)]
=C2=A0 ]]></artwork></figure>
- </section= >

=C2=A0 <t>Retransmission of the ACK + MP_CAPABLE can occur if it is not=20 known if it has been received. The following diagrams show all possible=20 exchanges for the initial subflow setup to ensure this=20 reliability.</t>

--- 281,286 ----
***************
*** 22= 17,2222 ****
--- 2216,2222 ----
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 &RFC6824;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &RFC= 7413;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &RFC7430;
+=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &RFC8174;


=C2=A0 <!--= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &TCPLO; draft-ananth-tcpm-tcpoptext-00; Expired-->

--0000000000006a573e0572f13350-- From nobody Fri Aug 10 11:49:47 2018 Return-Path: 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 C3715130E76 for ; Fri, 10 Aug 2018 11:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 dEpAkem4vnU5 for ; Fri, 10 Aug 2018 11:49:42 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EAC113108B for ; Fri, 10 Aug 2018 11:49:42 -0700 (PDT) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 950A42786A2 for ; Sat, 11 Aug 2018 03:49:40 +0900 (JST) Received: by mail-io0-f179.google.com with SMTP id l7-v6so8532331ioj.1 for ; Fri, 10 Aug 2018 11:49:40 -0700 (PDT) X-Gm-Message-State: AOUpUlGFs0Bpd7DbpHRstdMoyDYBuyUrATtIbIgNn+5JUIM+wDd/XAaj j1oEPy9r123LWIz3pf2DsQrbx3E9RXwhP5JSB00= X-Google-Smtp-Source: AA+uWPwidzMJeiN78Zt5IQtIGXn2jqUM0Nrq/wICi1KWsBQR6VEXqB5nVDYoRLxgZ4FiUi4s1eDtPrMgZQb61s1U3mQ= X-Received: by 2002:a6b:9cc1:: with SMTP id f184-v6mr6396936ioe.7.1533926978793; Fri, 10 Aug 2018 11:49:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7599:0:0:0:0:0 with HTTP; Fri, 10 Aug 2018 11:49:37 -0700 (PDT) In-Reply-To: <982B626E107E334DBE601D979F31785C5DC70CFF@BLREML503-MBS.china.huawei.com> References: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> <92A53501-4728-4E02-816A-92CEE703AA49@gmail.com> <20754FD9-627F-4AAC-A1B5-6EF2BD09B2AD@gmail.com> <982B626E107E334DBE601D979F31785C5DC5D84B@BLREML503-MBS.china.huawei.com> <982B626E107E334DBE601D979F31785C5DC6884D@BLREML503-MBS.china.huawei.com> <2FB78E5E-961F-4077-815F-158142B8E7E2@gmail.com> <982B626E107E334DBE601D979F31785C5DC70CFF@BLREML503-MBS.china.huawei.com> From: Yoshifumi Nishida Date: Fri, 10 Aug 2018 11:49:37 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Rahul Arvind Jadhav Cc: Yoshifumi Nishida , Alan Ford , Christoph Paasch , multipathtcp Content-Type: multipart/alternative; boundary="000000000000aeb71c057319344e" Archived-At: Subject: Re: [multipathtcp] 6824bis -11 review X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 18:49:46 -0000 --000000000000aeb71c057319344e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rahul, Thanks for bringing up an interesting point before we finalize the draft! I put my comments in lines. On Wed, Aug 8, 2018 at 8:20 AM, Rahul Arvind Jadhav wrote: > Please find my response [RJ3] inline. > > > > Best, > > Rahul > > > > > > On 31 Jul 2018, at 01:21, Rahul Arvind Jadhav > wrote: > > > > c) sending a new ADD_ADDR with same ID + address and different port is fi= ne > > [RJ] again this is what the text already says, but I=E2=80=99m not still = clear > about this. Why ID + address has to match? Only ID should be enough. > > > > Consider: > > > > a) ADD_ADDR comes in saying ID=3D2, addr=3D10.0.0.1 (private) > > b) MP_JOIN comes in saying ID=3D2, addr=3D8.9.10.11 (public) > > c) ADD_ADDR comes in saying ID=3D2, addr=3D192.168.0.1 > > > > What does this mean? Is (c) an implicit REMOVE+ADD? And thus does this > mean the subflow created in (b) is now no longer valid? > > > > By keeping the address / ID mapping, if an address is lost, then so is th= e > subflow. > > > > [RJ2] Rather than viewing ( c) as an implicit REMOVE+ADD, can we see it a= s > an UPDATE? Because ID remains same. Subflow created in (b) remains valid > (not sure if I=E2=80=99m missing anything here, I see no reason to lose t= his > subflow). > > In step ( c), the receiver can override Address field in context to ID=3D= 2 > to the new addr (192.168.0.1) =E2=80=A6=E2=80=A6 8.9.10.11 is kept sepa= rately as the > learnt actual rcvd IP (from MP_JOIN) in the same context ID=3D2. We have = to > agree that an implementation needs to maintain this IP separately in > context to ID=3D2 anyways. > > So if we do an explicit REMOVE+ADD, the end result is the same as this > UPDATE (but with much less overhead & impl ease). > > > > I would be interested in hearing from other implementers here=E2=80=A6 Is= there an > issue with =E2=80=9Cupdating=E2=80=9D using ADD_ADDR? > > > > Given we say that REMOVE_ADDR should not remove a subflow if it=E2=80=99s= still > alive, we have precedent for implying a subflow can exist to an address > which does not have an Address ID - to - IP address mapping. > > > > So given that, does updating, as Rahul suggests, cause a problem? > > > > > > Hmm.. I am wondering why we want to re-use the same address ID while we > have 0-255 values for it? > > Do we have some advantage for it? I thought picking up a new ID would be > safer and simpler.. > > > > [RJ3]: Thanks for covering this angle. Now if we do not re-use the same > address ID then the scenarios are different. What happens when REMOVE_ADD= R > sent for previous ID is ignored because the flow is active on the receive= r? > The new ADD_ADDR with new ID will result in new ID getting added on the > receiver. This requires more state across multiple IDs, and requires more > messaging since REMOVE_ADDR has to done. And there is still an uncertaint= y > regarding what happens if the REMOVE_ADDR is ignored because the old flow > is active. Thus this is not simpler. > > ADD_ADDR doing an update on existing ID is easier to implement and > requires less messaging. > > There are advantages with an update on existing ID unless other > implementers have some other angle to cover. > Yes, if we pick up a new ID, mptcp stack will maintain multiple IDs until we find the old path is not active anymore. But, I think this is ok as these are different paths. Please correct me if I'm wrong, but It seems to me that when we update the flow, it is expected to inherit the state of the flow in this approach. But, in this case, I'm not very sure if this is right thing to do. When address has been changed, I guess the state of the path might be changed as well.. Also, when we try to update an ID, what if the old flow with the ID is still active? I think we should not remove it and keep it until closed. > > As Alan mentioned, when we try to "update" the address ID, we will have t= o > keep both addresses until we confirm that old one is not used anymore. > > Also, in the case described above, what will happen if (b) was delayed an= d > arrived after (c)? > > > > [RJ3] I=E2=80=99m not sure what is meant by, =E2=80=9Cconfirm that old on= e is not used > anymore=E2=80=9D. A receiver anyways is ready to receive an MP_JOIN from = source > address not advertised in the ADD_ADDR. > > Considering update is used,.. in the scenario above, if MP_JOIN (b) > arrives after ADD_ADDR update (c) is issued, it would not result in any > mishap imo. > Sorry. I was not clear enough. "confirm" means that checking if the subflow is already closed or not by following what is described Section 3.4.2. This may take a certain time as we might need to wait for timeout. About race condition case, I am thinking about an example like this. (a) ADD_ADDR comes in saying ID=3D2, addr=3D10.0.0.1 (private) (b) MP_JOIN comes in saying ID=3D2, addr=3D8.9.10.11 (public) (internal 10.0.0.1) (c) ADD_ADDR comes in saying ID=3D2, addr=3D9.10.11.12 (public) In this case, when a node sent (b), ID=3D2 is associated with internal address 10.0.0.1 But, after that, the node learned he got new addr 9.10.11.12 which is public. So, he decided to replace ID=3D2 for some reasons. (because the current ID=3D2 has significant delay?) Now, because of significant delay in the ID=3D2 path, (b) has arrived after (c). How to handle this kind of case is not very clear to me yet. Thanks, -- Yoshi --000000000000aeb71c057319344e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rahul,

Thanks for bringing up an int= eresting point before we finalize the draft!
I put my comments in= lines.

O= n Wed, Aug 8, 2018 at 8:20 AM, Rahul Arvind Jadhav <rahul.jadhav@hua= wei.com> wrote:

Please find my respons= e [RJ3] inline.

=C2=A0

Best,

Rahul

=C2=A0

=C2=A0

On 31 Jul 2018, at 01:21, Rahul Arvind Jadhav <rahul.jadhav@hua= wei.com> wrote:

=C2=A0

c) sending a new ADD_ADDR with same ID + address and= different port is fine

[RJ] again this is what the text alre= ady says, but I=E2=80=99m not still clear about this. Why ID + address has = to match? Only ID should be enough.=C2=A0

=C2=A0

Consider:

=C2=A0

a) ADD_ADDR comes in saying ID=3D2, addr=3D10.0.0.1 = (private)

b) MP_JOIN comes in saying ID=3D2, addr=3D8.9.10.11 = (public)

c) ADD_ADDR comes in saying ID=3D2, addr=3D192.168.0= .1

=C2=A0

What does this mean? Is (c) an implicit REMOVE+ADD? = And thus does this mean the subflow created in (b) is now no longer valid?<= u>

=C2=A0

By keeping the address / ID mapping, if an address i= s lost, then so is the subflow.

=C2=A0

[RJ2] Rather than viewing ( c) as an = implicit REMOVE+ADD, can we see it as an UPDATE? Because ID remains same. S= ubflow created in (b) remains valid (not sure if I=E2=80=99m missing anything here, I see no reason to lose this subflow= ).

In step ( c), the receiver can overri= de Address field in context to ID=3D2 to the new addr (192.168.0.1) =E2=80= =A6=E2=80=A6=C2=A0=C2=A0 8.9.10.11 is kept separately as the learnt actual rcvd IP (from MP_JOIN) in the same context ID=3D2. We have to agree that a= n implementation needs to maintain this IP separately in context to ID=3D2 = anyways.

So if we do an explicit REMOVE+ADD, t= he end result is the same as this UPDATE (but with much less overhead &= impl ease).

=C2=A0

I would be interested in hearing from other implemen= ters here=E2=80=A6 Is there an issue with =E2=80=9Cupdating=E2=80=9D using = ADD_ADDR?

=C2=A0

Given we say that REMOVE_ADDR should not remove a su= bflow if it=E2=80=99s still alive, we have precedent for implying a subflow= can exist to an address which does not have an Address ID - to - IP addres= s mapping.

=C2=A0

So given that, does updating, as Rahul suggests, cau= se a problem?

=C2=A0

=C2=A0

Hmm.. I am wondering why we want to re-use the same = address ID while we have 0-255 values for it?

Do we have some advantage for it? I thought picking = up a new ID would be safer and simpler..=C2=A0

=C2=A0

[RJ3]: Thanks for covering thi= s angle. Now if we do not re-use the same address ID then the scenarios are= different. What happens when REMOVE_ADDR sent for previous ID is ignored because the flow is active on the receiver? The new ADD_ADDR= with new ID will result in new ID getting added on the receiver. This requ= ires more state across multiple IDs, and requires more messaging since REMO= VE_ADDR has to done. And there is still an uncertainty regarding what happens if the REMOVE_ADDR is ignored = because the old flow is active. Thus this is not simpler.

ADD_ADDR doing an update on existing = ID is easier to implement and requires less messaging.

There are advantages with an update o= n existing ID unless other implementers have some other angle to cover.


Yes, if we pick up a new ID, mptcp stack will maintain multiple IDs = until we find the old path is not active anymore. But, I think this is ok a= s these are different paths.

Please correct me if = I'm wrong, but It seems to me that when we update the flow, it is expec= ted to inherit the state of the flow in this approach.
But, in th= is case, I'm not very sure if this is right thing to do. When address h= as been changed, I guess the state of the path might be changed as well..
Also, when we try to update an ID, what if the old flow with the I= D is still active? I think we should not remove it and keep it until closed= .

=C2=A0

As Alan mentioned, when we try to "update"= the address ID, we will have to keep both addresses until we confirm that = old one is not used anymore.

Also, in the case described above, what will happen = if (b) was delayed and arrived after (c)?=C2=A0

=C2=A0

[RJ3] I=E2=80=99m not sure wha= t is meant by, =E2=80=9Cconfirm that old one is not used anymore=E2=80=9D. = A receiver anyways is ready to receive an MP_JOIN from source address not a= dvertised in the ADD_ADDR.

Considering update is used,.. in the = scenario above, if MP_JOIN (b) arrives after ADD_ADDR update (c) is issued,= it would not result in any mishap imo.

<= /div>
=C2=A0
Sorry. I was not clear e= nough. "confirm" means that checking if the subflow is already cl= osed or not by following what is described Section 3.4.2. This may take a c= ertain time as we might need to wait for timeout.

About race conditi= on case, I am thinking about an example like this.
(a) ADD_ADDR comes in= saying ID=3D2, addr=3D10.0.0.1 (private)
(b) MP_JOIN comes in saying ID= =3D2, addr=3D8.9.10.11 (public) =C2=A0(internal 10.0.0.1)
(c) ADD_ADDR c= omes in saying ID=3D2, addr=3D9.10.11.12 (public)

In this case, when= a node sent (b), ID=3D2 is associated with internal address 10.0.0.1
=
But, after that, the node learned he got new add= r 9.10.11.12 which is public. So, he decided to replace ID=3D2 for some rea= sons. (because the current ID=3D2 has significant delay?)
Now, because of significant delay in the ID=3D2 path, (b) = has arrived after (c). How to handle this kind of case is not very clear to= me yet.

Thanks,
--
Yoshi


--000000000000aeb71c057319344e--