Re: [multipathtcp] brief summary for bumping version number discussion

Christoph Paasch <cpaasch@apple.com> Sat, 02 July 2016 07:33 UTC

Return-Path: <cpaasch@apple.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 BFC2C12B00E for <multipathtcp@ietfa.amsl.com>; Sat, 2 Jul 2016 00:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.518
X-Spam-Level:
X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=apple.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 kITjECUyrM-p for <multipathtcp@ietfa.amsl.com>; Sat, 2 Jul 2016 00:33:28 -0700 (PDT)
Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0168A12B038 for <multipathtcp@ietf.org>; Sat, 2 Jul 2016 00:33:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1467444807; x=2331358407; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YpyDySOgmKfrEHhKEx3Z9oBo104putFQeWOIQQUUtbs=; b=SQy9nq6E26oag+VLy4ifRmo5D543l4gBRYbYY2w0e4q52/VWEGQZL3086mzXRkCb WRQjevOBecCT2/isGO8J/HzXPpyrcW99ZgqINupMXCL1HrQu3IBbWy66YG+2CP8e UO/97PNPm+XR8/aZRy0kiNd7Shl8wDTe9ANy8za3qOph7vUrdV32tUX/OmwNIF4N Ycx8MayWVjiR6SLHcK/XMoxxYBglw9U97lafwi++Gy++2sKG2fVRmbnWzH2vn+c2 cfGuaEsPSeD+rlrWvcl+ISmwVBh67LSfyG/LPzFlM22gUfI/edQM7hvw6xx47sR5 KTOTYAeOK/wqTSi8egD5ew==;
Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 25.F9.07752.74E67775; Sat, 2 Jul 2016 00:33:27 -0700 (PDT)
X-AuditID: 11973e15-f798f6d000001e48-e1-57776e471a35
Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id A7.26.28504.74E67775; Sat, 2 Jul 2016 00:33:27 -0700 (PDT)
Received: from [17.149.238.46] (unknown [17.149.238.46]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O9O00I8EFNR1A40@nwk-mmpp-sz09.apple.com> for multipathtcp@ietf.org; Sat, 02 Jul 2016 00:33:27 -0700 (PDT)
Sender: cpaasch@apple.com
Content-type: text/plain; charset=us-ascii
MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Christoph Paasch <cpaasch@apple.com>
In-reply-to: <CAO249ydR1uhxA9Akawmgm7gOSJBKSpWBgVtvC_TAkCN8c-avRA@mail.gmail.com>
Date: Sat, 02 Jul 2016 00:33:27 -0700
Content-transfer-encoding: quoted-printable
Message-id: <7D01552D-AF37-4B69-8A2F-37CDA350AA44@apple.com>
References: <CAO249ydR1uhxA9Akawmgm7gOSJBKSpWBgVtvC_TAkCN8c-avRA@mail.gmail.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUi2FAYoeueVx5ucHKavsXn1dfZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcXxKeMEkoYqXx30bGJfxdTFyckgImEjcmbGYHcIWk7hwbz1b FyMXh5DAXkaJNf82scIUHWvcxgyRWMYkcfj0cXYIZymTxJ+GTrAqYQFJie47d5hBbGYBLYn1 O48zgdi8AnoSk482sEHU+Et8vbEQzGYDqnl7ux2sl1MgWKJv5mYwm0VAVeLqrClANRxAc4wl psw0ghipLfHk3QVWiJE2Es03O1hAbCGBAIl9rbvBPhABWvXh+0cmiKNlJZ6cXMQCcqeEwBw2 ieMb/jBPYBSZheS8WUjOm4VkxwJG5lWMQrmJmTm6mXlmeokFBTmpesn5uZsYQcE93U50B+OZ VVaHGAU4GJV4eB0+loULsSaWFVfmHmKU5mBREuedvRgoJJCeWJKanZpakFoUX1Sak1p8iJGJ g1OqgfFIssTnUCWjGX8U07riw9O3v2b9/dNKNju38Am/9GTNz9FPWna/+PVk9rmFKr+SP+0U 1/JcpyEjrsqx+PTkf0a/dry2sTr6vrCtOzYko7V8wtkJa0qdO7Z53PolG92Wyrrc1rrpVRVf Y+TdlEmyhn/y+sTY5+p06u9fs6A87uaxj9asi0xP5iixFGckGmoxFxUnAgBherPXTwIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUi2FAcoOueVx5ucKBFx+Lz6utsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOD4lvGCSUMXL474NjMv4uhg5OSQETCSONW5jhrDFJC7cW8/W xcjFISSwjEni8Onj7BDOUiaJPw2drCBVwgKSEt137oB1MAtoSazfeZwJxOYV0JOYfLSBDaLG X+LrjYVgNhtQzdvb7WC9nALBEn0zN4PZLAKqEldnTQGq4QCaYywxZaYRxEhtiSfvLrBCjLSR aL7ZwQJiCwkESOxr3c0OYosArfrw/SMTxNGyEk9OLmKZwCg4C8lFs5BcNAvJ2AWMzKsYBYpS cxIrTfUSCwpyUvWS83M3MYKDsTBiB+P/ZVaHGAU4GJV4eGd8LgsXYk0sK67MPcQowcGsJMLb llMeLsSbklhZlVqUH19UmpNafIgxGeiXicxSosn5wEjJK4k3NDExMDE2NjM2NjcxJ01YSZyX YxHQVoH0xJLU7NTUgtQimC1MHJxSDYz5FoEs6w8YBjF/nmdW/HSX363X2Q3bvczlK1lt7+Tt aTAq0HxrGH+PT+P34iPLVpef3738q674FN/16VIzVjm/0H0vO0/MaxN/w7bzjeyXdsTsanTx vtbyLM1l2gNd5jkzTtfd+r77vxiTC2tFx9vZv1ym56z2Ou5288bPi8p7uUSNjScLbfirxFKc kWioxVxUnAgA4xEmTYoCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/xg8EE3c_dYQdwbT-hkJRa2O458c>
Cc: MultiPath TCP - IETF WG <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] brief summary for bumping version number discussion
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: Sat, 02 Jul 2016 07:33:31 -0000

Hello,

> On Jul 1, 2016, at 12:14 AM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
> During the interim meeting, we found we still need some more discussions for bumping the version number.
> So, I am trying to summarize the point of the discussion for further discussions.
> 
> As far as I can think, there are several reasons we would like to bump the version number.
> 
>   1) As we are moving from experimental to standard, we want to change the version number so that we can distinguish both versions clearly.
> 
>   2) In order to support the features in the bis draft (especially initial handshake scheme), we need to change the version number. 
>        Otherwise we will have to have two initial handshake mechanisms in a single version, which will be complex and tricky. 

Besides the handshake, ADD_ADDR2 also adds complexity. If we don't change the version-number, hosts will have to do probing to see whether the peer supports ADD_ADDR2 or not. And when a host receives an ADD_ADDR, he won't be sure whether it is because the peer is RFC6824bis compliant and is just probing (and the ADD_ADDR2 has been lost) or whether the peer only supports RFC6824.

> 
> On the other hand, I guess the followings are the reasons for not bumping version number.
> 
>   A) As we're still in the middle of deployment process for mptcp, bumping version number may create confusions in the deployments.
>   
>   B) The new features in the bis draft are not critical. The use cases for them don't look major cases. We might want to see some statistics to confirm they are major cases.

I will present statistics in Berlin.


Christoph

>      
> Please point out if I miss something in the above. If you want to add something to them, please do so that we can clarify our discussion points more.
> 
> 
> BTW, while we might want to see some data for B), I am wondering if we could see some data about how much mptcp implementations are in the wild to think about A)
> Is there any way to see this sort of data? 
> 
> Thanks,
> --
> Yoshi
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp