[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
- Re: [multipathtcp] brief summary for bumping vers… Christoph Paasch
- [multipathtcp] brief summary for bumping version … Yoshifumi Nishida
- Re: [multipathtcp] brief summary for bumping vers… Yoshifumi Nishida