Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

Christoph Paasch <cpaasch@apple.com> Fri, 13 December 2019 16:29 UTC

Return-Path: <cpaasch@apple.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0E012085A for <multipathtcp@ietfa.amsl.com>; Fri, 13 Dec 2019 08:29:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, 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 k3gzoRxY8kEY for <multipathtcp@ietfa.amsl.com>; Fri, 13 Dec 2019 08:29:46 -0800 (PST)
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 0572A12021D for <multipathtcp@ietf.org>; Fri, 13 Dec 2019 08:29:45 -0800 (PST)
Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id xBDGR96b026042; Fri, 13 Dec 2019 08:29:36 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=ccAUcN+viM9FgU27vwQi5MIxT3LQxIcvCUXifo1SNG8=; b=Nng9SzCxgj/Y9bn0T0qldHHCxRptrQgJwlmccmdEVJcnqkWHS9lnUelBiaJpMq2yVoXs SM2UIuoyll3vlSokDUdqDepNdttNNxgwVdxv0HZ2lP2f5qowDIKopATmJvu9h5CQdPCY HhE83LzkbH2hpvXH6eAa6X0aXFILSU51RJVHBwjbSh6II/52oXDG+lk7gJ8Njs1UrKnC IbFGa4ESTU1vnryERVJloAHe+fg8n3RViRnYx1Wkuv+DstHxZlFpZsHmE0hEdvcPHYj2 WnsGDXCuiUso1Rp8U3DyKmYgLAaeiooZouH141jM/BI46NdWoKy/D7cUVfZ8ojng2sOV Sg==
Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2wr9hsrejb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 13 Dec 2019 08:29:36 -0800
Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q2G0070KLTBU440@ma1-mtap-s01.corp.apple.com>; Fri, 13 Dec 2019 08:29:36 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q2G00900LRHRH00@nwk-mmpp-sz11.apple.com>; Fri, 13 Dec 2019 08:29:35 -0800 (PST)
X-Va-A:
X-Va-T-CD:
X-Va-E-CD:
X-Va-R-CD:
X-Va-CD: 0
X-Va-ID: f590936f-c8e3-4df0-9373-9118d5977494
X-V-A:
X-V-T-CD: 180e5e1b6a6fda3f9ba414022b920652
X-V-E-CD: 1267ad930a5510df15e8bf1401474564
X-V-R-CD: d1bec3bf3ba8d66d42ac99ad7d4c4b7f
X-V-CD: 0
X-V-ID: a95244e8-1cb7-40e0-9ed0-59f77a88c2d8
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-12-13_05:,, signatures=0
Received: from [17.234.118.58] (unknown [17.234.118.58]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q2G007C3LT92G90@nwk-mmpp-sz11.apple.com>; Fri, 13 Dec 2019 08:29:34 -0800 (PST)
Sender: cpaasch@apple.com
Content-type: multipart/alternative; boundary=Apple-Mail-51E1E2E6-E0C7-4290-950D-A070581526E4
Content-transfer-encoding: 7bit
From: Christoph Paasch <cpaasch@apple.com>
MIME-version: 1.0 (1.0)
Date: Fri, 13 Dec 2019 08:29:25 -0800
Message-id: <42684CE4-7B3E-4899-9706-7E3AAB39A9F7@apple.com>
References: <f97420243acd.5df3748a@nic.in>
Cc: Alan Ford <alan.ford@gmail.com>, MultiPath TCP - IETF WG <multipathtcp@ietf.org>, mptcp Upstreaming <mptcp@lists.01.org>, Mirja Kuehlewind <ietf@kuehlewind.net>
In-reply-to: <f97420243acd.5df3748a@nic.in>
To: V Anil Kumar <anil@csir4pi.in>
X-Mailer: iPhone Mail (18A181)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-13_05:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/cIs0ee6-nREvs-hhbjBz_wrwMlo>
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: Fri, 13 Dec 2019 16:29:48 -0000

Hello,

> On Dec 12, 2019, at 9:53 PM, V Anil Kumar <anil@csir4pi.in> wrote:
> 
> Hi Christoph,
> 
> Thanks for your reply. Please see inline.
> 
>> On 12/12/19 12:52 AM, Christoph Paasch <cpaasch@apple.com> wrote:
>> 
>> Hello,
>> 
>> 
>>> On Dec 10, 2019, at 12:04 PM, V Anil Kumar <anil@csir4pi.in> wrote:
>>> 
>>> 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.
>>>> 
>>> 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?
>> 
>> For two reasons:
>> 
>> 1. Ease of implementation
>> 2. If an implementation tries to "remember" early mappings, it is not clear how many of these an implementation can hold. Thus, the sender does not know how many early mappings he can send. So, it is hard for a sender to do the right thing.
>> 
>>> 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.
>> 
>> What is the concrete use-case for such early mappings? What are the benefits of it? I think that if we want to enable such implementation-complexity, we need a compelling use-case with a big benefit.
>> 
> Consider a case where a MPTCP connection consists of two subflows, and the data segments are scheduled for transmission in the order shown below below. 
> 
> Subflow-1:      segment-1                   segment-3                    segment-5                       segment-6
>                            bytes:1-100                bytes:201-300            bytes:401-500                bytes:501-600
>                            no map                         map for 1-100            map for 401-600            no map
> 
> 
> Subflow-2:       segment-2                  segment-4                       segment-7                     segment-8
>                            bytes: 101-200         bytes:301-400               bytes: 601-700             bytes:701-800   
>                            map for 101-200     map for 301-400           map for 601-800         no map
>                  
> In the above case, the map for data in segment-1 is included in segment-3.

The question here is why would the stack not put the mapping for segment 1 on segment 1 itself. And what is the benefit of doing so?


Christoph

> Further, segment-3 cannot combine/cover the data in segment-1 and segment-3 in a "single map", as the data sequence space is not continuous, i.e., some in between data (segment-2) is mapped and transmitted through subflow-2. Here,  the map in segment-3 does not even partially cover the data it carries.
> 
> Both RFC 6824 and the 6824-bis do not restrict the above scenario, and I guess the change proposed now does not permit this to happen.
> 
> Best regards,
> 
> Anil
> 
>> 
>> 
>> 
>> That's the reason why we (the MPTCP-upstreaming community) vouch to have this case restricted.
>> 
>> 
>> Cheers,
>> Christoph
>> 
>> 
>> 
>> 
>>> 
>>> Anil 
>>>> 
>>>> 
>>>> 
>>>> Best regards,
>>>> Alan
>>>> 
>>