Subject: [multipathtcp] MPTCP Versioning in RFC 6824

From: Anumita Biswas <[email-masked]>
Date: Thu, 11 Dec 2014 13:50:39 -0800

Hi,

MPTCP Version 0 should include a solution for the backward compatibility problem that will exist once MPTCP has a version number higher than 0. 

The MPTCP header used in the MP_CAPABLE option has a 4bit field for the Version. The existing MPTCP spec RFC 6824 does not specify how clients and servers are to behave upon receiving a non-zero number in that field. 

"The first 4 bits of the first octet in the MP_CAPABLE option
   (Figure 4) define the MPTCP option subtype (see Section 8 <http://tools.ietf.org/html/rfc6824#section-8>; for
   MP_CAPABLE, this is 0), and the remaining 4 bits of this octet
   specify the MPTCP version in use (for this specification, this is 0).
“

Current implementations fall back to a regular TCP handshake when a non-zero version number is received. These implementations of version 0 should be modified to include a way to support higher versions of MPTCP. Otherwise we will be stuck with version 0 for future revs of the MPTCP standard.

Proposal:

When initiating a connection, a client requests a version number of its choice in the SYN + MP_CAPABLE segment. 

The server can accept by replying with that version number in the MP_CAPABLE response in SYN/ACK, OR The server can decline by replying with a version number lower than the version advertised by the client in its SYN.

The version negotiation is completed by having both client and server fall to the version that is the minimum of the versions advertised by the parties. This version is sent by the client in the ACK of the 3-way handshake. 

The client should also be able to fallback to regular TCP after the receipt of the SYN/ACK+MP_CAPABLE with lower version number, if it does not support the lower version or chooses to not use the lower version.

So for example, the client requests version number 1 in SYN+MP_CAPABLE. If the server supports only version 0, it replies with version 0. Client then falls back to the version 0 implementation thereby still having the benefits of using MPTCP version 0 for that connection rather than regular TCP.

Secondly, it would be fantastic if the support for experimental work was added to the bis spec as follows:

The standard allocates one version number for “experimental” purposes. Lets say we allocate 15, which is the highest allocatable version number in the MPTCP header. With this, both client and server can still fall back to version 0 if the server does not support version 15. However, if the server does support version 15, then both client and server are free to use extensions or additions to the base MPTCP spec with no guarantees given to either party that things will work as expected. But this allows room for experimentation on the Internet and if/when some extension proves to be useful and working well in the field, that extension can be ported back to a non experimental version like version 1 for instance. 

For all this to work, the current MPTCP implementers will have to add the following support in their version 0 implementation: 

a. A server must accept a SYN with any version number.
b. The server must reply with the version number it supports or wishes to use, provided it is equal to or lower than the client’s version number, and not fall back to a regular TCP handshake in SYN/ACK.
c. The client must echo the minimum of the versions advertised by the client and server in the ACK of the 3-way handshake or fallback to regular TCP if it does not support the server’s version. 

Please let me know your thoughts on this,

Thanks,
Anumita Biswas

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 12 Dec 2014 18:29:32 +0100

Anumita,
> b. The server must reply with the version number it supports or wishes
> to use, provided it is equal to or lower than the client’s version
> number, and not fall back to a regular TCP handshake in SYN/ACK.
> c. The client must echo the minimum of the versions advertised by the
> client and server in the ACK of the 3-way handshake or fallback to
> regular TCP if it does not support the server’s version.
>

Your proposal looks really good to me

Olivier

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 15 Dec 2014 09:33:10 +0100

Anumita,
> The standard allocates one version number for “experimental” purposes.
> Lets say we allocate 15, which is the highest allocatable version number
> in the MPTCP header. With this, both client and server can still fall
> back to version 0 if the server does not support version 15. However, if
> the server does support version 15, then both client and server are free
> to use extensions or additions to the base MPTCP spec with no guarantees
> given to either party that things will work as expected. But this allows
> room for experimentation on the Internet and if/when some extension
> proves to be useful and working well in the field, that extension can be
> ported back to a non experimental version like version 1 for instance.

This is also a very good idea. I'd suggest to encourage the implementors 
to document any planned usage of version 15 with an IETF draft published 
before the start of the experiment and report later about the results of 
the experiments.

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: Anumita Biswas <[email-masked]>
Date: Mon, 15 Dec 2014 09:50:03 -0800

Olivier,

> On Dec 15, 2014, at 12:33 AM, Olivier Bonaventure <[email-masked]> wrote:
> 
> Anumita,
>> 
> This is also a very good idea. I'd suggest to encourage the implementors to document any planned usage of version 15 with an IETF draft published before the start of the experiment and report later about the results of the experiments.
That makes sense.

Thanks!
Anumita