[multipathtcp] brief summary for bumping version number discussion

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Fri, 01 July 2016 07:14 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 1988812D193 for <multipathtcp@ietfa.amsl.com>; Fri, 1 Jul 2016 00:14:52 -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 dQkSuiZkCW52 for <multipathtcp@ietfa.amsl.com>; Fri, 1 Jul 2016 00:14:49 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5AE012D106 for <multipathtcp@ietf.org>; Fri, 1 Jul 2016 00:14:49 -0700 (PDT)
Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7E7362784D4 for <multipathtcp@ietf.org>; Fri, 1 Jul 2016 16:14:47 +0900 (JST)
Received: by mail-qk0-f174.google.com with SMTP id t127so187629351qkf.1 for <multipathtcp@ietf.org>; Fri, 01 Jul 2016 00:14:47 -0700 (PDT)
X-Gm-Message-State: ALyK8tIhOb2RsSFSXG+sNpW8UYERD8ECwWwStfLSR4l2QYIGmRwHLpyzW1PoEexOVYNE0/4FzsQ3k1+k12Wf3g==
X-Received: by 10.37.14.11 with SMTP id 11mr8644349ybo.43.1467357286056; Fri, 01 Jul 2016 00:14:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.196.3 with HTTP; Fri, 1 Jul 2016 00:14:45 -0700 (PDT)
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Fri, 01 Jul 2016 00:14:45 -0700
X-Gmail-Original-Message-ID: <CAO249ydR1uhxA9Akawmgm7gOSJBKSpWBgVtvC_TAkCN8c-avRA@mail.gmail.com>
Message-ID: <CAO249ydR1uhxA9Akawmgm7gOSJBKSpWBgVtvC_TAkCN8c-avRA@mail.gmail.com>
To: multipathtcp <multipathtcp@ietf.org>
Content-Type: multipart/alternative; boundary="001a113fd74ecb4d6805368dbd67"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/KQDF5rXQWP1sCGqATTDcw2GecGc>
Subject: [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: Fri, 01 Jul 2016 07:14:52 -0000

Hi folks,

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.

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.

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