Re: [multipathtcp] RFC6824bis edits based on implementation feedback

Christoph Paasch <cpaasch@apple.com> Thu, 02 January 2020 18:27 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 74CE612006F for <multipathtcp@ietfa.amsl.com>; Thu, 2 Jan 2020 10:27:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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, 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 SskOZ9m2komm for <multipathtcp@ietfa.amsl.com>; Thu, 2 Jan 2020 10:27:01 -0800 (PST)
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 BC8041200B4 for <multipathtcp@ietf.org>; Thu, 2 Jan 2020 10:27:01 -0800 (PST)
Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id 002INWQr065523; Thu, 2 Jan 2020 10:27:00 -0800
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=kebaxHQzIuGWP+6XFGdY8FgRQ9KnsRLBJUBsV49FpaY=; b=nwToFKuD1sEwykJTON4RVIT0vTFpjjI/KDjw4IIvAdX7N+UnXZcVZsoutwGhutdUdZnx k+otN8UikERo/0pPJKmMDJzUP1/bSXF4gtLrP8kKs8E2+XAexEsFdqiS2Sg6QxMdtsyI eRoRC/12y1yt0y6o204Uc4X+4mrGFZMj3RtBe/Fv+/V3YLLOgR1cHGTFdA6E2e0PI0YQ 4wJyGFeR4qaT7XLAAQ6ib/21jsBT+XxFqw7zhItF5GXAt9BOondJ00ION+l+7qC3Z83B 8il4DawyELQ30BDMmjOrzlI2xLn7Ob6doWrLEbY+atTkUKimruRwtksDEYwFssUwZozj +g==
Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2x6r5q9e1m-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 02 Jan 2020 10:26:59 -0800
Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q3H007HZSKW4B90@ma1-mtap-s01.corp.apple.com>; Thu, 02 Jan 2020 10:26:57 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q3H00E00SDW2000@nwk-mmpp-sz09.apple.com>; Thu, 02 Jan 2020 10:26:56 -0800 (PST)
X-Va-A:
X-Va-T-CD: 3617872cb080ac0182d9b2453d56adc6
X-Va-E-CD: ae422271a38913bbedae93e9e9d60fc7
X-Va-R-CD: a5d4677ae470b25e3a5d2ab1ded2428a
X-Va-CD: 0
X-Va-ID: d28185a6-b86d-4db4-a39a-1c15cd4b34f9
X-V-A:
X-V-T-CD: 3617872cb080ac0182d9b2453d56adc6
X-V-E-CD: ae422271a38913bbedae93e9e9d60fc7
X-V-R-CD: a5d4677ae470b25e3a5d2ab1ded2428a
X-V-CD: 0
X-V-ID: a2550360-87bb-4fae-8d5e-ed73cbd7fda4
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-02_06:,, signatures=0
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-disposition: inline
Content-type: text/plain; charset=utf-8
Received: from localhost ([17.192.155.241]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q3H00JQDSKVQN30@nwk-mmpp-sz09.apple.com>; Thu, 02 Jan 2020 10:26:55 -0800 (PST)
Sender: cpaasch@apple.com
Date: Thu, 02 Jan 2020 10:26:55 -0800
From: Christoph Paasch <cpaasch@apple.com>
To: Alan Ford <alan.ford@gmail.com>
Cc: MultiPath TCP - IETF WG <multipathtcp@ietf.org>, mptcp Upstreaming <mptcp@lists.01.org>
Message-id: <20200102182655.GB44237@MacBook-Pro-64.local>
References: <C36D742F-6D76-48FA-B6D8-44DE484A9E2C@gmail.com>
In-reply-to: <C36D742F-6D76-48FA-B6D8-44DE484A9E2C@gmail.com>
User-Agent: Mutt/1.12.2 (2019-09-21)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-02_06:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/bXgUsHKzdEulh-nT92ncW0Ab7CY>
Subject: Re: [multipathtcp] RFC6824bis edits based on implementation feedback
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: Thu, 02 Jan 2020 18:27:03 -0000

+ MPTCP upstreaming community


Hello,

On 01/01/20 - 22:51:32, Alan Ford wrote:
> Hi all,
> 
> We’d love to get this to a state of completion as soon as possible, and to this end I am starting a new thread on this topic. In discussion with the chairs, it is possible to make the desired changes in AUTH48 as long as there is WG consensus. The discussion so far has been fairly limited in terms of participation.
> 
> I would ask the chairs please if it was possible to specify a time bound for this discussion and a default conclusion.
> 
> Regarding the changes, in summary, there are two areas where changes have been requested by the implementation community. As we are the IETF we obviously have strong focus on “running code” and so ease of implementing standards-compliant code is strongly desirable. However, we do not wish to reduce functionality agreed by the IETF community if it is considered a required feature by the community.
> 
> 
> Change 1
> 
> 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).
> 
> What this means:
> 
> The current text is concerned only with ensuring a path is MPTCP capable, and so only cares that DSS option occurs on a data packet. However, the MP_CAPABLE option is defined to occupy the first octet of data sequence space and thus, if analogous to TCP, must be acknowledged. From an implementation point of view it would make sense not to have this hanging around forever and instead define it is acknowledged at the connection level as soon as received. This change ensures the first data packet also DATA_ACKs this MP_CAPABLE octet.
> 
> 
> Change 2
> 
> 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:
> 
>    The mapping provided by a Data Sequence Mapping MUST apply to some or all of the subflow sequence space in the TCP segment which carries the option. 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 this means:
> 
> The current text does not place any restrictions on where a mapping could appear. In theory a sender could define a thousand different mappings up front, send them all, and expect a receiver to store this and reassemble data according to these mappings as it arrives. Indeed, this was never explicitly disallowed since it “might have been useful”. The implementation community, however, has expressed concerns over the difficulty of implementing this open-endedly. How many mappings is it reasonable to store? Is there a DoS risk here? Instead, it has been requested that thee specification restricts the placement of the DSS option to being within the subflow sequence space to which it applies.
> 
> 
> Please can members of the WG express whether they are happy with these changes, or concerned.

As an implementor and having been the one kicking off this discussion, I fully
support this change.



Thanks,
Christoph