Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

Yoshifumi Nishida <nsd.ietf@gmail.com> Tue, 10 December 2019 05:30 UTC

Return-Path: <nsd.ietf@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 A2DB41200EB for <multipathtcp@ietfa.amsl.com>; Mon, 9 Dec 2019 21:30:23 -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 6JlJ9hWs8WyC for <multipathtcp@ietfa.amsl.com>; Mon, 9 Dec 2019 21:30:21 -0800 (PST)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 9CC28120020 for <multipathtcp@ietf.org>; Mon, 9 Dec 2019 21:30:21 -0800 (PST)
Received: by mail-wr1-x429.google.com with SMTP id c14so18522309wrn.7 for <multipathtcp@ietf.org>; Mon, 09 Dec 2019 21:30:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bqNlT2gUQErM5NwlusSCiaSZ/Y2JnmZODs9zhRI1J0Y=; b=sf3DM2ml9BYu+CVBcJ6c6I6f0fi0g6Xa7/Tefw40Hv9vTX3cHuslMbZS5g6mXEa8p6 bRJglkcvK9h6MVFAL8kBn0iG+/aYdm8SI50oAvMofXdySOTdUjF+ytbcCB4SL6wKU+Wx Yg10aITIIc1P7nb5CyKFldtO9pXn87vjqFcOxw2LF/xSSGCI/8ZjT8R54lR6ZuJQ16ly UylWtAlKJ3ANlwm5kpN2TOsnbMMfdfG0/SSqeApJThJs3veUDJl21YNCDt+VULVOTAdi RzNczznGUlTPW0nECgvLiEOPv2/ZlBf/iM3OaBac6UNYkmTzVljnIxnhCih28Brc0Wn8 QzrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bqNlT2gUQErM5NwlusSCiaSZ/Y2JnmZODs9zhRI1J0Y=; b=J00mkJHz9mv4iVAAnd8EKva42URZnP96QnfC/wXi1whio9qJUbjWWA1HtpL7lXkBE9 3OmPnLU4yUfT1SQTimI5ZaGVG29xIsQiHlKOc0YB3lFvppGYjrHkZFuW/U5XIrdeKUav A0GQ830yO1vwQNSlAnNyTo5398ywDbiPOP4eK/hvheb0y3EKftZckM1pgFwJ9XlRRSbH 1K3c5QCdi2M0groaRXDI6a9TBsm6efShqqYoIYW1taqzG/cQ5/uqNEolNvauVZUiOm8X mycWzNRpgChL82zNp2e1VSx1gkWc/k1ZgDrzIpmByQ9KwufIsCrhOyCdtOa7ZSv3Gqkl rDig==
X-Gm-Message-State: APjAAAWCupeRbZx7Wc/+Yf1hvhgka/BfnmuyNgyzy5u4KHnWpKESG+Ui xwodxUJaTZCYhyynF3E25DVV9dlcCJWIzdQYNhQ=
X-Google-Smtp-Source: APXvYqwvC2FdhM29k/Q/xXGh+ePvTajbF91Rp96dT+rGrexE98LF/72qadlQH20Yb7gwhbH4AxVJpIyntA/pQY9F1sI=
X-Received: by 2002:adf:ee82:: with SMTP id b2mr918697wro.194.1575955820187; Mon, 09 Dec 2019 21:30:20 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <6978C97F-24D5-4CF0-8CEB-2F58BE26D174@gmail.com>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Mon, 09 Dec 2019 21:30:08 -0800
Message-ID: <CAAK044RLUJSZEcyuv1FmPGmOA0pCMKLBD8EzXZn9h23ZCfaYWA@mail.gmail.com>
To: Alan Ford <alan.ford@gmail.com>
Cc: Christoph Paasch <cpaasch@apple.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>
Content-Type: multipart/alternative; boundary="000000000000d81659059952ce2e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Su3VJ1ow8KA39jGXQh8tZEFGYZo>
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: Tue, 10 Dec 2019 05:30:23 -0000

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> 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?

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.
>
>
What implementations should do when a Data Sequence Mapping doesn't cover
the TCP segment that carries this option?
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."
--
Yoshi