Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

Alan Ford <alan.ford@gmail.com> Fri, 06 December 2019 15:58 UTC

Return-Path: <alan.ford@gmail.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 53A2D1200D7 for <multipathtcp@ietfa.amsl.com>; Fri, 6 Dec 2019 07:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EbxISZtdC5gE for <multipathtcp@ietfa.amsl.com>; Fri, 6 Dec 2019 07:58:22 -0800 (PST)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0A5120019 for <multipathtcp@ietf.org>; Fri, 6 Dec 2019 07:58:22 -0800 (PST)
Received: by mail-wr1-x42a.google.com with SMTP id b6so8361176wrq.0 for <multipathtcp@ietf.org>; Fri, 06 Dec 2019 07:58:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZhnCHvbnZ/2R81rumvEZpG9JNlbmTKAJqmj4qIF49D0=; b=uBi+E6dWiFyvgJJG1sqB6T9S6vhCEEK1aVlqYiPi4Yxasp0u/FXoxd0uiQ5P/NsjUE SlASztmuLGEVJz78Tfhy8/1nDrqMBvhuOeUVzzEz6RSp3akVkOfmUP+UbtFligl1e1He 80ZEPRP6++g+ptOvWFhSrQOe2AiJNnb5Wc1MvulfjibBEvsqo+AIREAzn/gH2R7U5l+u kwWiKoRN7kvRIJOwVdLnypBIhJbgCpzTm/4vvo2xMsJvyme5OAyr8Ag23crYsGhWdIVl RyU3jG3uztnrzEu1AtZ9HA9xaap7SvSQThmmBBl1jPcDkfKEtYefgB4ZX+YX1Ue2+cN3 nr6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ZhnCHvbnZ/2R81rumvEZpG9JNlbmTKAJqmj4qIF49D0=; b=tRUKUNCE/VBeEhZO+kjEiSoXONTcbNbdKise3n0zUdGHj+uPQIkD1xY7rorN5CTdXp qfalBxpo1P5f/sL7sF1IJzz3z6c4lAeCkejES13CjXFB54+SJhDLU/cUO2oNzNEaowG9 7q0f3vvIiQfsX2NhM3E36ikIUd/45Zi8jPp3vwbVX5N/bxI8YeS3JHlWTK9UFg8XevFP yFEKnuNdBDfoSiaVY8P1GtC69BQHh9cR/+0k6Xbv2rR6xhZpxdmzs2DvjWwbyuqbYA7h iesDeqJ7tQBgnA24OeF0/Y3bjvcDPIeEDbjS5yZ0K1UDg1FPsGroPL1o1MZ423O0I6aW V83A==
X-Gm-Message-State: APjAAAVhqhihGV7XdKr3m+DqOX6ITaKzJtf4/IrVq0blpRaBhgaxFcbA YT/qli4B5V2/aX0PTFH8kE8=
X-Google-Smtp-Source: APXvYqwQ4IIJrB2I6/xm75Lh1oAx3I8wDxTyp0Y38EtxkeAbY9CIf/X9DSyh/dvYBaBGBcN4J3GfWw==
X-Received: by 2002:adf:d850:: with SMTP id k16mr15730223wrl.96.1575647900521; Fri, 06 Dec 2019 07:58:20 -0800 (PST)
Received: from alan-mbp.lan (93.118.208.46.dyn.plus.net. [46.208.118.93]) by smtp.gmail.com with ESMTPSA id w20sm3880867wmk.34.2019.12.06.07.58.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Dec 2019 07:58:19 -0800 (PST)
From: Alan Ford <alan.ford@gmail.com>
Message-Id: <6978C97F-24D5-4CF0-8CEB-2F58BE26D174@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6218BAC8-F519-4760-9090-FF1C3FC7F4B2"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 6 Dec 2019 15:58:17 +0000
In-Reply-To: <DEE3E51B-373C-40BE-A296-8517FB23A7B7@apple.com>
Cc: MultiPath TCP - IETF WG <multipathtcp@ietf.org>, Yoshifumi Nishida <nsd.ietf@gmail.com>, Philip Eardley <philip.eardley@bt.com>, Mirja Kuehlewind <ietf@kuehlewind.net>, mptcp Upstreaming <mptcp@lists.01.org>
To: Christoph Paasch <cpaasch@apple.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>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/YwqA-9EYFxXosad1WVPRCULUdb8>
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, 06 Dec 2019 15:58:24 -0000

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.


Best regards,
Alan