Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

V Anil Kumar <anil@csir4pi.in> Wed, 11 December 2019 13:45 UTC

Return-Path: <prvs=241cd6842=anil@csir4pi.in>
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 679D6120820 for <multipathtcp@ietfa.amsl.com>; Wed, 11 Dec 2019 05:45:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 QxDS_4DZWB2G for <multipathtcp@ietfa.amsl.com>; Wed, 11 Dec 2019 05:45:24 -0800 (PST)
Received: from relayout32.nic.in (relayout32.nic.in [164.100.14.128]) (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 F3BC512011E for <multipathtcp@ietf.org>; Wed, 11 Dec 2019 05:45:22 -0800 (PST)
IronPort-PHdr: =?us-ascii?q?9a23=3AWixxABY+UwVdYZNZdKi0Dn7/LSx+4OfEezUN45?= =?us-ascii?q?9isYplN5qZoMy8bnLW6fgltlLVR4KTs6sC17ON9fmxBSdesd6oizMrSNR0TR?= =?us-ascii?q?gLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ?= =?us-ascii?q?/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCybL9vIhi6txjdu80ZjIdtK6s8yQ?= =?us-ascii?q?bCr2dVdehR2W5mP0+YkQzm5se38p5j8iBQtOwk+sVdT6j0fLk2QKJBAjg+PG?= =?us-ascii?q?87+MPktR/YTQuS/XQcSXkZkgBJAwfe8h73WIr6vzbguep83CmaOtD2TawxVD?= =?us-ascii?q?+/4apnVAPkhSEaPDM/7WrZiNF/jLhDrRyhuRJxwIDaboaIOvp6fKzdc8gXSn?= =?us-ascii?q?BdUsdeUyxMGJ+wYokJAuEcPehYtY79p14WoBSxGAKhGOXvyj5MhnTr2KM6zu?= =?us-ascii?q?EhHhvc3Ac9GN8BqnLUrNTxNKoJTe+116jIzS/MYvNO2Dfx8onIchY4rPyKQL?= =?us-ascii?q?l+ctLRxFEyGw7BkFmcs5HpMjKW2+gXrmSX9fRsWOK3h2I6pAx9uCWjy8koh4?= =?us-ascii?q?XTm44YxF/J+T9nzIopI9CzVVR1bsS+EJRKsiGXL452QsQ/TG52oCs60bgGuY?= =?us-ascii?q?KjfCgN1ZQn2wbTa/yZfIiM5RLuTOORLi15hHJhYr6/iBGy8Va6xu39UMm4yF?= =?us-ascii?q?dKrixbndnQrn0Byhje5tadRvdg/0qs2iyD2x3J5u1aIU04ja/bJIQgwr40mJ?= =?us-ascii?q?oTq0PDHirulUrsiq+Wd0Ek9/O05OT8Y7XmvJCRN5d1ig3kM6QunNSzAf4kPQ?= =?us-ascii?q?gWQ2ib5eO82aXm/U3kRLVKkvw2krHDv5DGJcQburK2AxdO34Yi9Rm/Ezmm3M?= =?us-ascii?q?4fnXkdI1IWMC6A2o30P03POPnkDeu0m3ytnStlgffcMe7PGJLIe0aLubHgef?= =?us-ascii?q?5e9ktV0kJnxNZe47pfEbAbfOryHE734o+LRiQlOhC5lr60QO520ZkTDDqC?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BhAADfoPBd/xkBqMBlGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF+gRyDIQqDeZEuiVuRVAkBAQIBAQEBATcBAYR?= =?us-ascii?q?AAoInOBMCAwEMAQEBBAEBAQEBBQMBAYVXIAYmDII7IoMCAQUjGg0IFSACAQo?= =?us-ascii?q?NCwkhAgIPDAY2EQgUhVUDrFqBMhoCg02EMA2CKwWBMYFlikcGggCBEYMTPoE?= =?us-ascii?q?EgReFPoJeBJdBiAqOVkOCOZFQhDuCQod2hBoUA4tSmSmPawGBeoF6TTiDJ1A?= =?us-ascii?q?RgySJboUTiRoJbI8uAQE?=
X-IPAS-Result: =?us-ascii?q?A2BhAADfoPBd/xkBqMBlGgEBAQEBAQEBAQMBAQEBEQEBA?= =?us-ascii?q?QICAQEBAYF+gRyDIQqDeZEuiVuRVAkBAQIBAQEBATcBAYRAAoInOBMCAwEMA?= =?us-ascii?q?QEBBAEBAQEBBQMBAYVXIAYmDII7IoMCAQUjGg0IFSACAQoNCwkhAgIPDAY2E?= =?us-ascii?q?QgUhVUDrFqBMhoCg02EMA2CKwWBMYFlikcGggCBEYMTPoEEgReFPoJeBJdBi?= =?us-ascii?q?AqOVkOCOZFQhDuCQod2hBoUA4tSmSmPawGBeoF6TTiDJ1ARgySJboUTiRoJb?= =?us-ascii?q?I8uAQE?=
X-IronPort-AV: E=McAfee;i="6000,8403,9467"; a="325436127"
X-IronPort-AV: E=Sophos;i="5.69,301,1571682600"; d="scan'208,217";a="325436127"
Received: from unknown (HELO mail.gov.in) ([192.168.1.25]) by vastu52internal.nic.in with ESMTP; 11 Dec 2019 14:06:37 +0530
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_8rk/t9SlqOHVWldl1iw8bA)"
Received: from nic.in ([192.168.1.25]) by msgfe32.nic.in (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Nov 28 2016)) with ESMTPA id <0Q2C00G80AL14100@msgfe32.nic.in> for multipathtcp@ietf.org; Wed, 11 Dec 2019 14:06:37 +0530 (IST)
Sender: anil@csir4pi.in
Received: from [192.168.1.25] (Forwarded-For: 14.139.134.20) by msgfe32.nic.in (mshttpd); Wed, 11 Dec 2019 14:06:37 +0530
From: V Anil Kumar <anil@csir4pi.in>
To: multipathtcp@ietf.org
Message-id: <fa3ec7bee28.5df0f7ed@nic.in>
Date: Wed, 11 Dec 2019 14:06:37 +0530
X-Mailer: Oracle Communications Messenger Express 7.0.5.38.0 64bit (built Nov 28 2016)
Content-language: en
X-Accept-Language: en
Priority: normal
In-reply-to: <6978C97F-24D5-4CF0-8CEB-2F58BE26D174@gmail.com>
References: <DEE3E51B-373C-40BE-A296-8517FB23A7B7@apple.com> <6978C97F-24D5-4CF0-8CEB-2F58BE26D174@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/va2Y0D6UKrxrjK9DtpbfWDd9nH0>
Subject: Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2019 13:45:29 -0000

Hi Alan,

Please see inline.

On 12/06/19 09:28 PM, Alan Ford  <alan.ford@gmail.com> wrote: 
> 
> 
> 
> 
> 
> Hi all,
> 
> 
> 
> 
> Following on from the discussion of implementation feedback with Christoph, I propose the following edits to RFC6824bis - which is currently in AUTH48 - as clarifications.
> 
> 
> 
> 
> ADs, please can you confirm you consider these edits sufficiently editorial to fit into AUTH48.
> 
> 
> 
> 
> WG participants, please speak up if you have any concerns.
> 
> 
> 
> 
> 
> 
> 
> Edit 1, clarifying reliability of MP_CAPABLE
> 
> 
> 
> 
> Change the sentence reading:
> 
> 
> 
> 
>  The SYN with MP_CAPABLE occupies the first octet of data sequence space, although this does not need to be acknowledged at the connection level until the first data is sent (see Section 3.3).
> 
> 
> 
> 
> To:
> 
> 
> 
> 
>  The SYN with MP_CAPABLE occupies the first octet of data sequence space, and this MUST be acknowledged at the connection level at or before the time the first data is sent or received (see Section 3.3).
> 
> 
> 
> 
> 
> 
> 
> Change the sentence reading:
> 
> 
> 
> 
>  If B has data to send first, then the reliable delivery of the ACK + MP_CAPABLE can be inferred by the receipt of this data with an MPTCP Data Sequence Signal (DSS) option (Section 3.3). 
> 
> 
> 
> 
> To:
> 
> 
> 
> 
>  If B has data to send first, then the reliable delivery of the ACK + MP_CAPABLE is ensured by the receipt of this data with an MPTCP Data Sequence Signal (DSS) option (Section 3.3) containing a DATA_ACK for the MP_CAPABLE (which is the first octet of the data sequence space).
> 
> 
> 
> 
> 
> 
> 
> In my personal opinion either one of these edits would be sufficient for making the point, however clearly this has caused some confusion amongst the implementor community so making both these changes should make it absolutely clear as to the expected behaviour here.
> 
> 
> 
> 
> 
> 
> 
> Edit 2, mapping constraint
> 
> 
> 
> 
> Change the sentence reading:
> 
> 
> 
> 
>  A Data Sequence Mapping does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver.
> 
> 
> 
> 
> To:
> 
> 
> 
> 
>  A Data Sequence Mapping MUST appear on a TCP segment which is covered by the mapping. It does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver.
> 
> 
> 
> 
>  
> 
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; color: #000000; background-color: #ffffff}p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; color: #000000; background-color: #ffffff; min-height: 13.0px}span.s1 {font-variant-ligatures: no-common-ligatures}
As far as I understand, the proposed change introduces a “MUST” to insist that the map in a segment must cover at least some data in the segment. But the document does not talk anything about the rational behind it. I guess it is purely an ease of implementation? 


 

I think the design/format of the Data Sequence Mapping permits the map to stand independent of the data being carried in a segment. So, as long as an implementation is willing to deal with the complexity of storing and processing late and early mappings (with respect to the data arrival), it could be permitted provided that the received map is for an in-window data. 

 

Anil    

> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Best regards,
> 
> Alan
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
-- 

V Anil Kumar
Senior Principal Scientist
CSIR Fourth Paradigm Institute (CSIR-4PI)
NAL Belur Campus
Bangalore - 560037
E-mail: anil@csir4pi.in
Phone: +91 80 2505 1355