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

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 1 Jul 2016 00:14:45 -0700

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

---

From: Christoph Paasch <[email-masked]>
Date: Sat, 02 Jul 2016 00:33:27 -0700

Hello,

> On Jul 1, 2016, at 12:14 AM, Yoshifumi Nishida <[email-masked]> 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)
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 14 Jul 2016 11:37:22 -0700

Hi Christoph,

On Sat, Jul 2, 2016 at 12:33 AM, Christoph Paasch <[email-masked]> wrote:

> >   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.
>

Yes, it's a way to do it, but it's not very simple as you mentioned.
Other ways I can think is to use a flag in their initial exchange to check
whether this is bis version or not.
But, either way, I think we will need more discussions.

If people prefer to not bump the number, it would be great if they can
describe how to handle features described in the bis draft as well.

> >   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

Thank you!
--
Yoshi