Re: [multipathtcp] RFC6824bis edits based on implementation feedback

Yoshifumi Nishida <nsd.ietf@gmail.com> Tue, 07 January 2020 08:41 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 4DE0112022D for <multipathtcp@ietfa.amsl.com>; Tue, 7 Jan 2020 00:41:53 -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 78c9lKCc8Lxz for <multipathtcp@ietfa.amsl.com>; Tue, 7 Jan 2020 00:41:50 -0800 (PST)
Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 6FC8F1200D5 for <multipathtcp@ietf.org>; Tue, 7 Jan 2020 00:41:50 -0800 (PST)
Received: by mail-ua1-x931.google.com with SMTP id y23so18179950ual.2 for <multipathtcp@ietf.org>; Tue, 07 Jan 2020 00:41:50 -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=R+CdB4jB0nPXTVeNJyaITZcoBMWRpS67g3DVXFMjv8g=; b=sbURF9llTZV+dxwMDriuRQyGbCx6eFIljEvXEz1HZBQixypLx0xgais4H6dLgfPa08 NTr6NnEeO7qqQ3c2oX0uQpiywNNTwrGen4Zroc7FbPP9D3WkKzVs7tk4Nigr7/4IfwTm 0EEzLzmLefp3BGcIq6jWlRatOynnSFn0pGLQpH5fTvJWC+Bo7KTbcFe9Bebki+h1CYV8 swtD3E7Rd2/VCLqKfFvolLZu2ByasbxgW4Z7g9PE6yMwQc8bfawwGrS/x/40jNGNY5ta /GPB7jsJk5lX68aypRU8alAoreFnLE2kIH9TsAFnXf5eb3lDpOgyTm1D96i8t9wTDsmh 5AiQ==
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=R+CdB4jB0nPXTVeNJyaITZcoBMWRpS67g3DVXFMjv8g=; b=WZv7TackrCRqXt6GzpowD0OG+G2O5W2ME2UOvR2hI2xlaZiG7oVAGoQt0BU6HmA7Hm 8k12YkgKT3itBE/H/6hEjHNoXhQK071+MSUd/PRficGb9CGDJAiXFeVtb57l0I4WsmUd cePPRz2gM45GwHm+GPYv0aY2DNF+sxeFyZ0zwKd2x2r+aYKBOnW2aK+ICvJcfTsm459D aILhAWz1GXD7UUqm36Yd6Zg+4grpWg7sefqSvhx+9RAoEYof+ASKhi0Tw5H9f//pxnnT nx7Stm8je5F96fntu0/3Y2pdi8luKTqn7g0d9lE1FvAyeaSebIAJ9Cv1SvF0lenB1+eg EnMg==
X-Gm-Message-State: APjAAAXy5nwHaeRHSHoIVNiY9qGM+RJ1SnpUNd9hdP9unVYvRRUG/CxA wkphpm1CgDp4GoprV9erLBdi/bmEur5tx90bCow=
X-Google-Smtp-Source: APXvYqyeru0njt1XuDbZFzGUMtWNgbKqom3qhNjm7GKAMK4uJz8JIXGiIqi9xjU8kC4slQhvneqxpx3VxpqIH7TldkU=
X-Received: by 2002:ab0:46c:: with SMTP id 99mr61971981uav.134.1578386509392; Tue, 07 Jan 2020 00:41:49 -0800 (PST)
MIME-Version: 1.0
References: <C36D742F-6D76-48FA-B6D8-44DE484A9E2C@gmail.com> <20200102182655.GB44237@MacBook-Pro-64.local>
In-Reply-To: <20200102182655.GB44237@MacBook-Pro-64.local>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Tue, 7 Jan 2020 00:41:38 -0800
Message-ID: <CAAK044SJERk4n0+9CsD46UHjC874tO9z-EtFVFyLsNtXVPpuFw@mail.gmail.com>
To: Christoph Paasch <cpaasch=40apple.com@dmarc.ietf.org>
Cc: Alan Ford <alan.ford@gmail.com>, MultiPath TCP - IETF WG <multipathtcp@ietf.org>, mptcp Upstreaming <mptcp@lists.01.org>
Content-Type: multipart/alternative; boundary="00000000000035ef0a059b88bf69"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/fCL7juwAtxyn_Cq5V2pX1744cUk>
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: Tue, 07 Jan 2020 08:41:54 -0000

Hi,
The texts look good to me. (as an individual contributor, just in case.)
Thanks for the efforts!
--
Yoshi

On Thu, Jan 2, 2020 at 10:27 AM Christoph Paasch <cpaasch=
40apple.com@dmarc.ietf.org> wrote:

> + 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
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>