[multipathtcp] MPTCP implementation feedback for RFC6824bis

Christoph Paasch <cpaasch@apple.com> Wed, 27 November 2019 19:30 UTC

Return-Path: <cpaasch@apple.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2F16B1209D1 for <multipathtcp@ietfa.amsl.com>; Wed, 27 Nov 2019 11:30:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Status: No, score=-7.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_HI=-5, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id S2iSQRr-cH13 for <multipathtcp@ietfa.amsl.com>; Wed, 27 Nov 2019 11:30:16 -0800 (PST)
Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com []) (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 993541208BA for <multipathtcp@ietf.org>; Wed, 27 Nov 2019 11:29:58 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com []) by ma1-aaemail-dr-lapp02.apple.com ( with SMTP id xARJR09q062051; Wed, 27 Nov 2019 11:29:43 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : mime-version : subject : message-id : date : cc : to; s=20180706; bh=uHDZQPU7GqgifRvWgo1VNJz8Sw0zYLt+BsVVGsljrUU=; b=n0Mw6nuNbyl6/0p8EtcQxRBgS/92lpJlx2mSN5amJa+jt8Ro2+3l4K7e2Wd9nHQM7/WH xRlJiBf99Mdxs/X7bHebU8J3icxNllVPAoE/rPN8768aITMe739RvOECVARvnLIQR+qu zgAohGnTyfGQQjPNV5+YU0X2ZZcdtTixo44sVM98HboowlOmoyCy8Jm4xZkTGyJOVOyk 9oapaFeetAO6dgi+GszK8aLAqLp6DYjXgae2ip/m3b1xWziofEWXxzt6110B2bHa3NRH n1ddGMUp4rYYost8lgLiCTFvTEXbt9rBVGfTY3cPhCIst9Sx7T8DxaGDzxmNHzViUMn8 4w==
Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com []) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2wf2ay5uju-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 27 Nov 2019 11:29:43 -0800
Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com []) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPS id <0Q1N00BBK7HJ9040@mr2-mtap-s01.rno.apple.com>; Wed, 27 Nov 2019 11:29:43 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 64bit (built May 7 2019)) id <0Q1N00H0073ZXQ00@nwk-mmpp-sz09.apple.com>; Wed, 27 Nov 2019 11:29:43 -0800 (PST)
X-Va-T-CD: 2b6045725d91cd89a861509c29962f96
X-Va-E-CD: 870ee97794533347ec4fb00997e6290f
X-Va-R-CD: 76dc9fccb79d969b645e107245a60a4b
X-Va-CD: 0
X-Va-ID: b5508dd7-b661-42b0-9d8d-283ad6a74b8a
X-V-T-CD: 2b6045725d91cd89a861509c29962f96
X-V-E-CD: 870ee97794533347ec4fb00997e6290f
X-V-R-CD: 76dc9fccb79d969b645e107245a60a4b
X-V-CD: 0
X-V-ID: e8c2bfff-d6ba-4ca7-828f-1006ba8af3b1
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-27_04:,, signatures=0
Received: from [] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPSA id <0Q1N00BTH7HH1E20@nwk-mmpp-sz09.apple.com>; Wed, 27 Nov 2019 11:29:42 -0800 (PST)
Sender: cpaasch@apple.com
From: Christoph Paasch <cpaasch@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_4B3674AD-59EB-4341-8223-26E30533688A"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Message-id: <17233788-D98B-4484-B785-2F58D43EA7CA@apple.com>
Date: Wed, 27 Nov 2019 11:29:41 -0800
Cc: mptcp Upstreaming <mptcp@lists.01.org>
To: MultiPath TCP - IETF WG <multipathtcp@ietf.org>, Yoshifumi Nishida <nsd.ietf@gmail.com>, Philip Eardley <philip.eardley@bt.com>, Alan Ford <alan.ford@gmail.com>, Mirja Kuehlewind <ietf@kuehlewind.net>
X-Mailer: Apple Mail (2.3601.0.10)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-27_04:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/DykO7LL6P1vY8264SxsOdv01uU8>
Subject: [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, 27 Nov 2019 19:30:18 -0000


as I mentioned during the meeting last week in Singapore, the team working on upstreaming MPTCP into the Linux Kernel has some feedback on RFC6824bis that would be good to be factored into the RFC before publication.

Here is the list of comments/changes the team is suggesting:

Section 3.1, page 19, "If B has data to send first,..."

The first phrase states that when A receives a DSS from B it indicates successful delivery of the MP_CAPABLE. However, it is not the DSS but rather the DATA_ACK that indicates this. Digging through some past e-mail exchanges I had with Alan I see that that was indeed the intention.

We are thus suggesting to change this text to:
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 a MPTCP Data Sequence Signal (DSS) option that includes a DATA_ACK (Section 3.3). Further, whenever A receives a DATA_ACK from B it is a signal of the reliable delivery of A's MP_CAPABLE. After this, A can send data to B with a regular DSS option.

Section 3.3.1, page 32 & 33, "A data sequence mapping does not need..."

This paragraph states that it is permissive to send a mapping in advance. Late-mapping is specified a bit higher around the sentence 
"Implementations MAY hold onto such unmapped data for a short while in the expectation that a mapping will arrive shortly"

This kind of early/late mapping announcements are difficult to handle in an implementation. The Linux Kernel implementation of multipath-tcp.org <http://multipath-tcp.org/> has always disallowed such kind of mappings. Meaning, whenever a DSS-option is received such that the range specified by the relative subflow-sequence number in the DSS-option and the data-length does not (partially) cover the TCP sequence number of the packet itself, the subflow will be killed with a TCP-RST. The problem around handling such early/late mappings is that it is unclear for how long the stack needs to remember these mappings (in the early-mapping case), or for how long he needs to hold on to the data (in the late-mapping case).

We thus suggest to change this to the following:
Whenever a DSS-option is received on a packet such that the mapping of the subflow-sequence space does not partially cover the TCP-sequence number of  the packet itself, the host MUST discard this mapping and MAY destroy the subflow with a TCP-RST. It should be noted that a DATA_FIN that does not come with data has a relative subflow-sequence number of 0 and thus should be handled separately.

Would it be possible to make these adjustments to the RFC?

Christoph (on behalf of the MPTCP upstreaming community)