Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-12.txt

Rahul Jadhav <rahul.ietf@gmail.com> Tue, 09 October 2018 17:05 UTC

Return-Path: <rahul.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 1AF7A13135D for <multipathtcp@ietfa.amsl.com>; Tue, 9 Oct 2018 10:05:26 -0700 (PDT)
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_PASS=-0.001, URIBL_BLOCKED=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 QCQJQzRsabYM for <multipathtcp@ietfa.amsl.com>; Tue, 9 Oct 2018 10:05:22 -0700 (PDT)
Received: from mail-vk1-xa44.google.com (mail-vk1-xa44.google.com [IPv6:2607:f8b0:4864:20::a44]) (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 93795131332 for <multipathtcp@ietf.org>; Tue, 9 Oct 2018 10:05:21 -0700 (PDT)
Received: by mail-vk1-xa44.google.com with SMTP id b80-v6so566488vke.3 for <multipathtcp@ietf.org>; Tue, 09 Oct 2018 10:05:21 -0700 (PDT)
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=GL2msCZugJFswnnFFltL/YQGXG9hRhwad41NJF8wy3I=; b=PLXN0Opcak/uckc2jWJ/vl7mYh8dPHHiBhLfMB9aV4XLPtIRG6i5Ku6ru7/atpbqRl sdpomEhzwuIoBqu1RpFjK/Qje9cOpNM0XUtfi0TEiyFihUt8nHulTel0Us4TTJpiyVJV yTV6kJX/oNdhzpSAYea54vBWdcO7NBDMb8QQSXJzzUgffevedTSGkXheUBeswYja07JS r2CQ8otthLsE48BeuUP8FnKbepKRR23gJAwaKa3TbvhD+KHkP96Z7dijIqr+LZVrruKr gAUfO9pgpWcbeCyxDo3OadTm6xqh3JeRU+EOCbjbtw77z8Q3Kf+3V1gbJNjtbgAb2T2X P+7A==
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=GL2msCZugJFswnnFFltL/YQGXG9hRhwad41NJF8wy3I=; b=nIJRFd2LPmgJ3bGaU35gZuCwZNw+x6MljIuY0ict+xSxn3KuqPpgLwS7cOy0IzPTyc LhgBUamTCLzKzHTCsgDd3/IWTtd0UbqyDWJCeBQ+loW+KICaFGPfOjZHitGt4z293iPq FTvr29WRCt8tQCq15NtR2WyH1BQCzn4f6Pk/i7MblRfsRXCktHfYQXXE2mi81KV0frYV OjTR896FYyd7ReK3rB0OfZ1Y+ttRAjkhtJKL9YTUzLWFeUNzxJX7xFYXa8ZWDrGO3Yjt YDX83HvSq5vvGhwygHEQAYMFHkxRLh+3fTyDZByKlfJLCio+JixYtNk3ZimFkk2hY0Ci 3t8A==
X-Gm-Message-State: ABuFfojdo9CnpzLLNIctz0QiiWItoKWJJqm3hID5Xlagospsmu0gWUUb 8z+o0MlNKzkYAwL8qy2Owd9ZO79AJmxNYw02rmyF6g==
X-Google-Smtp-Source: ACcGV6014k38t7tQqu9TTNG9AqMyLsQWo6odK8Arqv0hnX1klHWnlnHySTmmkaoCg7GUggAFIpq4XTdtNXnZm4UJles=
X-Received: by 2002:a1f:1887:: with SMTP id 129mr1931788vky.92.1539104719578; Tue, 09 Oct 2018 10:05:19 -0700 (PDT)
MIME-Version: 1.0
References: <153857661587.9120.4590608359579290440@ietfa.amsl.com> <CC367F1F-06FC-4D12-83A2-81435191EA80@gmail.com> <982B626E107E334DBE601D979F31785C5DCBF6F0@BLREML503-MBX.china.huawei.com> <A3228CDD-E9AA-4BE8-857B-9BDC7F637E51@gmail.com>
In-Reply-To: <A3228CDD-E9AA-4BE8-857B-9BDC7F637E51@gmail.com>
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Tue, 9 Oct 2018 22:34:33 +0530
Message-ID: <CAO0Djp36VQ5f-Mr8HVdpX77Yzsvxb0x1A7h1EmOZSEfSd6Qj=A@mail.gmail.com>
To: Alan Ford <alan.ford@gmail.com>
Cc: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>, multipathtcp <multipathtcp@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001529f80577cebe8d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/LIcTFWXMS6sPYCY16WrGZVThAcA>
Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-12.txt
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, 09 Oct 2018 17:05:26 -0000

The suggested text looks good. I have no further comments.

Thanks,
Rahul

On Tue, 9 Oct 2018 at 2:28 AM, Alan Ford <alan.ford@gmail.com>; wrote:

> Hi Rahul,
>
> Thank you for double-checking, it is much appreciated!
>
> 1. Fixing text on Address ID, I hope the following is acceptable:
>
>         The MP_JOIN option includes an "Address ID".  This is an identifier
>         generated by the sender of the option, used to identify the source
> address
>         of this packet, even if the IP header has been changed in transit
> by a middlebox.
>         The numeric value of this field is generated by the sender and
> must map uniquely
>         to a source IP address for the sending host.
>
> 3. It was left for further comment, and no further comment was
> forthcoming. I personally am not sure of any need to add a MP_TCPRST here
> since both ends should know why the subflow is being torn down - one sent
> the REMOVE_ADDR, and the other acted on it. If the REMOVE_ADDR was spoofed,
> the safety nets should mean the subflow is not torn down. So I see no
> benefit in signalling the reason here.
>
> 4. At the first appearance of “make-before-break", we can add:
>
>         , where new subflows are added before the previously used ones are
> closed
>
> Regards,
> Alan
>
> > On 8 Oct 2018, at 14:49, Rahul Arvind Jadhav <rahul.jadhav@huawei.com>;
> wrote:
> >
> > Hello Alan,
> >
> > Most of my comments from [1] are handled. Thank you.
> >
> > Some comments based on the updated text:
> > 1. Accepted comment#8 in [1] does not seem to be handled. I think it is
> important to be clarified that the value of "Address ID" has significance
> not only within a single connection but also only on the peer who generates
> the ID. Thus it is possible for peers to generate the same Address ID
> within a connection as well.
> > 2. Thank you for removing the term "passive opener" throughout the
> document. The new text is much easier to understand.
> > 3. Looks like comment#2 for explicitly mentioning the Reason Code for
> MP_TCPRST was not accepted. I understand we haven’t really got any feedback
> from the WG on this point but then I feel it is necessary to do this.
> > 4. "make-before-break session" term is introduced after rewording ... I
> feel this term should be explained in terminology section.
> >
> > Best,
> > Rahul
> >
> > [1]
> https://mailarchive.ietf.org/arch/msg/multipathtcp/hpsqifbR00xRWJNZe-CYR7UtTyU
> >
> >
> >> -----Original Message-----
> >> From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of
> >> Alan Ford
> >> Sent: 03 October 2018 19:56
> >> To: multipathtcp <multipathtcp@ietf.org>;
> >> Subject: Re: [multipathtcp] I-D Action:
> draft-ietf-mptcp-rfc6824bis-12.txt
> >>
> >> Hi all,
> >>
> >> I believe this new version addresses all last call/review comments we
> >> received for rfc6824bis, with the exception of adding a possible
> “changes
> >> since RFC6824” section.
> >>
> >> Could all reviewers please check this new version and ensure we have
> >> handled your review comments appropriately?
> >>
> >> Many thanks,
> >> Alan
> >>
> >>> On 3 Oct 2018, at 15:23, internet-drafts@ietf.org wrote:
> >>>
> >>>
> >>> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >>> This draft is a work item of the Multipath TCP WG of the IETF.
> >>>
> >>>       Title           : TCP Extensions for Multipath Operation with
> Multiple
> >> Addresses
> >>>       Authors         : Alan Ford
> >>>                         Costin Raiciu
> >>>                         Mark Handley
> >>>                         Olivier Bonaventure
> >>>                         Christoph Paasch
> >>>     Filename        : draft-ietf-mptcp-rfc6824bis-12.txt
> >>>     Pages           : 80
> >>>     Date            : 2018-10-03
> >>>
> >>> Abstract:
> >>>  TCP/IP communication is currently restricted to a single path per
> >>>  connection, yet multiple paths often exist between peers.  The
> >>>  simultaneous use of these multiple paths for a TCP/IP session would
> >>>  improve resource usage within the network and, thus, improve user
> >>>  experience through higher throughput and improved resilience to
> >>>  network failure.
> >>>
> >>>  Multipath TCP provides the ability to simultaneously use multiple
> >>>  paths between peers.  This document presents a set of extensions to
> >>>  traditional TCP to support multipath operation.  The protocol offers
> >>>  the same type of service to applications as TCP (i.e., reliable
> >>>  bytestream), and it provides the components necessary to establish
> >>>  and use multiple TCP flows across potentially disjoint paths.
> >>>
> >>>  This document specifies v1 of Multipath TCP, obsoleting v0 as
> >>>  specified in RFC6824 [RFC6824] through clarifications and
> >>>  modifications primarily driven by deployment experience.
> >>>
> >>>
> >>> The IETF datatracker status page for this draft is:
> >>> https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/
> >>>
> >>> There are also htmlized versions available at:
> >>> https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-12
> >>> https://datatracker.ietf.org/doc/html/draft-ietf-mptcp-rfc6824bis-12
> >>>
> >>> A diff from the previous version is available at:
> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mptcp-rfc6824bis-12
> >>>
> >>>
> >>> Please note that it may take a couple of minutes from the time of
> >>> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >>>
> >>> Internet-Drafts are also available by anonymous FTP at:
> >>> ftp://ftp.ietf.org/internet-drafts/
> >>>
> >>> _______________________________________________
> >>> multipathtcp mailing list
> >>> multipathtcp@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/multipathtcp
> >>
> >> _______________________________________________
> >> multipathtcp mailing list
> >> multipathtcp@ietf.org
> >> https://www.ietf.org/mailman/listinfo/multipathtcp
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>