Re: [multipathtcp] Bumping the MPTCP version number: some cons

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Tue, 21 June 2016 05:47 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
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 E81EA12D179 for <multipathtcp@ietfa.amsl.com>; Mon, 20 Jun 2016 22:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 j4vFnNoiedgB for <multipathtcp@ietfa.amsl.com>; Mon, 20 Jun 2016 22:47:31 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80EF512D590 for <multipathtcp@ietf.org>; Mon, 20 Jun 2016 22:47:31 -0700 (PDT)
Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7CCB02784C6 for <multipathtcp@ietf.org>; Tue, 21 Jun 2016 14:47:29 +0900 (JST)
Received: by mail-yw0-f171.google.com with SMTP id b72so4986978ywa.3 for <multipathtcp@ietf.org>; Mon, 20 Jun 2016 22:47:29 -0700 (PDT)
X-Gm-Message-State: ALyK8tJdYUWxIiSRM4Bj76cvSxFZnPOAXAtEgkr3q1YMHDPqLlxCPHEhsmZmcZsfLDwfrEOBkw3O0uHPoMpPfg==
X-Received: by 10.129.75.206 with SMTP id y197mr10819821ywa.312.1466488048076; Mon, 20 Jun 2016 22:47:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.196.3 with HTTP; Mon, 20 Jun 2016 22:47:27 -0700 (PDT)
In-Reply-To: <035BFB2F-FC6F-479E-B0CA-5D84D2D9BE87@gmail.com>
References: <8ED39350-21EE-43B6-9D30-8786A7709702@cs.pub.ro> <20160406214450.GA1732@dhcp-a286.meeting.ietf.org> <CAO249yd-ziWwjwt_g1F24k2=_uc0JV-oRp3csoSWnyq3_x0CuA@mail.gmail.com> <20160407173442.GJ1732@dhcp-a286.meeting.ietf.org> <035BFB2F-FC6F-479E-B0CA-5D84D2D9BE87@gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Mon, 20 Jun 2016 22:47:27 -0700
X-Gmail-Original-Message-ID: <CAO249ydkEP7cF4HrmF+tadwCQXUpFn4roaUkv=o6x8Rf8ub1-g@mail.gmail.com>
Message-ID: <CAO249ydkEP7cF4HrmF+tadwCQXUpFn4roaUkv=o6x8Rf8ub1-g@mail.gmail.com>
To: Alan Ford <alan.ford@gmail.com>
Content-Type: multipart/alternative; boundary="001a113f1ae62c50ba0535c35b39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/L6ZZ5FoUuDCEwHsGWHNgUYu0rBw>
Cc: MultiPath WG <multipathtcp@ietf.org>, Costin Raiciu <costin.raiciu@cs.pub.ro>
Subject: Re: [multipathtcp] Bumping the MPTCP version number: some cons
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Jun 2016 05:47:34 -0000

Hi Alan,

On Mon, Jun 20, 2016 at 12:57 PM, Alan Ford <alan.ford@gmail.com> wrote:

> Hi all,
>
> Costin re-visited the issue of version number bumping in today's interim.
> In order to clarify matters here, I think it's worth just going back over
> why working group consensus for -05 was to do this.
>
> The thread can be found here:
> http://www.ietf.org/mail-archive/web/multipathtcp/current/msg02572.html
>
> The benefits this has so far brought are:
>
> - Support for stateless servers:
>   - No need for key in initial SYN (saves option space)
>   - Reliability of third ACK (including carrying data)
> - Save 1 subtype (ADD_ADDR2 -> ADD_ADDR)
>
> And we can potentially make other protocol-level changes before finalising
> v1 for standards track, for example the keyless SYN makes the proposal in
> draft-paasch-mptcp-application-authentication simpler (although it could be
> done with discarded key whilst retaining compatibility with the SHA-1
> exchange).
>
> I guess support for stateless servers could be signalled in the flags,
> i.e. the client saying "I will echo this reliably in the ACK if you want me
> to" and the server also sets that flag if it wants the client do this.
>

Hmm. the signal you mentioned will be used for reliability of the third
ACK, but won't be used for keyless syn?
I am guessing keyless syn cannot be supported by the flags.

Thanks,
--
Yoshi