Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

Christoph Paasch <cpaasch@apple.com> Wed, 11 December 2019 19: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 4FA501200EC for <multipathtcp@ietfa.amsl.com>; Wed, 11 Dec 2019 11:29:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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, 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=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 TrDA5KW4ol8P for <multipathtcp@ietfa.amsl.com>; Wed, 11 Dec 2019 11:29:08 -0800 (PST)
Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 7C773120052 for <multipathtcp@ietf.org>; Wed, 11 Dec 2019 11:29:08 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id xBBJRliw053632; Wed, 11 Dec 2019 11:28:54 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=/j4j257g3QYnkut97eSIgwYwBp7Zro307tqxl1dmQUY=; b=pnF2y26q48acpNW+hq0+NFGV9sA3czrDaSFA045EMqpGsIBDQOQS5bVbpxfsorPq5QO3 Gs3J5Zc/ouAZReBn/tKx+A/UbjGSSfSHWSGJzc9ZVBMr+XL+yO1NcyofvJRpbEg9vdpH NWzqfUm4+DXaypbu56H5wlc9jtmGQyeLiQ+D1P84lCY0gqUQOzfdkLtZlttXF5RIVFfY ioXAF92fWz/liMw2wCfQhT3uoLCvIdZpd9Em10/+2Nfc6puysE8bcTdBfb/iGmNxYTTf 5OjqB+fLI+G3uqjurwXNbH1E8n/dCb+LH5zMUb++fHIUrqypHoNgp0TZFYq3AVoGGcP4 jw==
Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2wrbm8pxn1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Dec 2019 11:28:54 -0800
Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q2D008L14S47990@ma1-mtap-s03.corp.apple.com>; Wed, 11 Dec 2019 11:28:54 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q2D00600496JP00@nwk-mmpp-sz13.apple.com>; Wed, 11 Dec 2019 11:28:54 -0800 (PST)
X-Va-A:
X-Va-T-CD:
X-Va-E-CD:
X-Va-R-CD:
X-Va-CD: 0
X-Va-ID: 3fd4ca66-3b7c-4376-a7e7-743cc9f42026
X-V-A:
X-V-T-CD: 3617872cb080ac0182d9b2453d56adc6
X-V-E-CD: 5a5a60e6f040669a01f467acbb8066aa
X-V-R-CD: 3858de275c7eacb246074420dbf98e80
X-V-CD: 0
X-V-ID: f0b48c9e-bbe6-465b-afa5-63deb1439092
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-12-11_06:,, signatures=0
Received: from [17.192.155.223] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q2D00JLT4S59U30@nwk-mmpp-sz13.apple.com>; Wed, 11 Dec 2019 11:28:54 -0800 (PST)
Sender: cpaasch@apple.com
From: Christoph Paasch <cpaasch@apple.com>
Message-id: <2689B456-2B1C-4D84-B36E-74FA0FFD2E3B@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_7B18A2FD-A5EF-46CB-A19E-8B0E70050476"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Wed, 11 Dec 2019 11:28:53 -0800
In-reply-to: <63E04612-7410-4E38-BE19-F2351C23C7F7@gmail.com>
Cc: Yoshifumi Nishida <nsd.ietf@gmail.com>, MultiPath TCP - IETF WG <multipathtcp@ietf.org>, Philip Eardley <philip.eardley@bt.com>, Mirja Kuehlewind <ietf@kuehlewind.net>, mptcp Upstreaming <mptcp@lists.01.org>, Matthieu Baerts <matthieu.baerts@tessares.net>, Paolo Abeni <pabeni@redhat.com>
To: Alan Ford <alan.ford@gmail.com>
References: <17233788-D98B-4484-B785-2F58D43EA7CA@apple.com> <D070F2D5-6E8C-4551-86DD-E50B4ADF11B7@gmail.com> <3F1F1135-D2C0-48E2-9B6E-A83DDC11DF4F@apple.com> <83BFBFD6-255E-4022-96D4-BE183B709CB2@gmail.com> <20191202172757.GA84163@MacBook-Pro-64.local> <CF3EBAFD-E24E-4233-8FCE-775396E747A2@gmail.com> <D784F90C-5027-4753-9088-00CF25D22DFD@apple.com> <3278EB11-686A-4E0F-9DE4-321B239F8913@gmail.com> <DEE3E51B-373C-40BE-A296-8517FB23A7B7@apple.com> <6978C97F-24D5-4CF0-8CEB-2F58BE26D174@gmail.com> <CAAK044RLUJSZEcyuv1FmPGmOA0pCMKLBD8EzXZn9h23ZCfaYWA@mail.gmail.com> <63E04612-7410-4E38-BE19-F2351C23C7F7@gmail.com>
X-Mailer: Apple Mail (2.3601.0.10)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-11_06:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/0BkrQoCgZrEiyfLxK3NoW9Dwu8I>
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 19:29:10 -0000

Hello Alan,

there is one more thing that came up from the implementation experience (thanks to Matthieu & Paolo in CC).

It is unclear in the draft (or at least, I didn't find the text ;-) ), what to do when the flags & version in the third ACK + MP_CAPABLE are inconsistent with what was negotiated in the SYN-SYN/ACK exchange.

It would be good to spell this out and say that if there are any inconsistencies, a host should simply fallback to regular TCP.


Christoph

> On Dec 10, 2019, at 8:09 AM, Alan Ford <alan.ford@gmail.com> wrote:
> 
> Hi Yoshifumi,
> 
>> On 10 Dec 2019, at 05:30, Yoshifumi Nishida <nsd.ietf@gmail.com <mailto:nsd.ietf@gmail.com>> wrote:
>> 
>> Hi Alan,
>> 
>> The texts look fine to me, but I have a few questions on them.
>> 
>> On Fri, Dec 6, 2019 at 7:58 AM Alan Ford <alan.ford@gmail.com <mailto: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).
>> 
>> What implementations should do when they receive the first data before MP_CAPABLE is acked?
>> They should terminate the connection or discard the data?
> 
> By asking this question you have made me realise that this text is in fact incompatible with the case when A (the initiator) is also the first sender of data.
> 
> Given the problem is only with B sending data first, let us forget this change, and revert to Christoph’s original problem text, and use only the below change:
> 
>> 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).
> 
> This will resolve the ambiguity in the case of B sending first.
> 
>> 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.
>> 
>> 
>> What implementations should do when a Data Sequence Mapping doesn't cover the TCP segment that carries this option?
> 
> There are a number of cases where the MUST does not have a consequence; it should be obvious from the text for similar failures that it can close it with a RST.
> 
>> BTW, This is not a strong opinion, but I may prefer a text like: "A Data Sequence Mapping MUST provide the mapping for the segment that carries this option.” 
> 
> OK how about: "A Data Sequence Mapping MUST provide the mapping which includes the segment that carries this option.” 
> 
> Regards,
> Alan
> 
>