Subject: [multipathtcp] Discussion /Consensus on incrementing the version number of MPTCP

From: <[email-masked]>
Date: Mon, 14 Sep 2015 14:45:40 +0000

Hi,

During our interim call last week, several discussion points touched on this topic. The implication would be that the MPTCP version number is 1 in the protocol bis (Standards track), and hence it would be incompatible with the current Experimental track protocol (version number is 0).

*         Making MP-CAPABLE reliable. There was a lot of support for this during the interim, with no-one against. One or two on-going questions were raised by Yoshi. This requires a new version number.

If it's agreed that the standards track RFC will be a different version number, then several other things have been raised

*         A new Proxy 'P' flag in MP_CAPABLE, https://tools.ietf.org/html/draft-wei-mptcp-proxy-mechanism-02  There was some support for this flag during the interim.

*         Replacing the IPver field in ADD_ADDR with a set of flags. Several people have supported this (though not yet have an agreed proposal /details).

*         Making the MPTCP token locally meaningful, in order that mptcp can work well with load balancers. See the discussion over the last few days prompted by https://datatracker.ietf.org/doc/draft-paasch-mptcp-loadbalancer/

*         The possibility of leveraging security off TLS (if TLS is being used)

The more general point is that - a new version number would mean that we have the opportunity to re-design MPTCP's signalling, based on the lessons learnt from the current implementations and deployments and the new requirements that have emerged.

So the first step is to make sure that we have consensus that in principle the protocol bis will have a new version number.
Since we didn't explicitly do a consensus call on this during the meeting, please send you views, positive or negative, to the list.

Thanks
Phil & Yoshi

---

From: Christoph Paasch <[email-masked]>
Date: Mon, 14 Sep 2015 10:13:56 -0700

Hello,

On 14/09/15 - 14:45:40, [email-masked] wrote:
> *         A new Proxy 'P' flag in MP_CAPABLE, https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwei-2Dmptcp-2Dproxy-2Dmechanism-2D02&d=BQIFAg&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=jjrPk64oS-oD6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=jvyGX0tWdV6396IQtsqvNJQ92kEGWhn-GWUmkWZwHpo&e=   There was some support for this flag during the interim.
> 
> *         Making the MPTCP token locally meaningful, in order that mptcp can work well with load balancers. See the discussion over the last few days prompted by https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dpaasch-2Dmptcp-2Dloadbalancer_&d=BQIFAg&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=jjrPk64oS-oD6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=29EQ9N7fXiZSGbwCqBFl-6bDFqOt0TrYNeVUVS1aKsQ&e= 
> 

as an author of two of the above drafts, I'm in favor of bumping the
version-number. It will allow to fix MPTCP wrt to the above mentioned issues
and bring MPTCP one step closer to wide-spread deployment.

Christoph

---

From: Anumita Biswas <[email-masked]>
Date: Mon, 14 Sep 2015 10:55:05 -0700

+ 1 for bumping the version number.

The proposed changes are big enough that they will cause backward compatibility issues with existing implementations if added on version 0.

Thanks,
Anumita

> On Sep 14, 2015, at 10:13 AM, Christoph Paasch <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_multipathtcp&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=is7V2j_77TQ8H500qPvC98gSLwj4K3agvCyq4ChpMmw&m=WM3tRORkrsC_jj-T7zcG_vDG4EP3Gmr6NiTZSiXyvgw&s=G0SQa7T3503a_SZbKUXpdyJ-zdj0w3SPs1ufDxu2QcM&e=

---

From: Nigel Williams <[email-masked]>
Date: Tue, 15 Sep 2015 10:11:58 +1000

I'm also for bumping the version number.

cheers,
nigel

On 15/09/2015 3:55 am, Anumita Biswas wrote:
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 14 Sep 2015 23:49:54 -0700

Hello folks,

I just would like to check a few points on increasing the version number.
I guess this means the followings. If I miss something or have different
views, please point it out.

1: The handshake method described in draft-paasch-mptcp-syncookies will be
included in 6824bis. This will be a single initial handshake method in
mptcp.
2: Version 0 won't be supported after 6824bis has been published.
3: We won't discuss backward compatible mechanisms such as fallback logics
(from version 1 to version 0)

Thanks,
--
Yoshi

On Mon, Sep 14, 2015 at 5:11 PM, Nigel Williams <[email-masked]>
wrote:

>> The proposed changes are big enough that they will cause backward
>> compatibility issues with existing implementations if added on version 0.
>>
>> Thanks,
>> Anumita
>>
>>>> During our interim call last week, several discussion points touched on
>>>> this topic. The implication would be that the MPTCP version number is 1 in
>>>> the protocol bis (Standards track), and hence it would be incompatible with
>>>> the current Experimental track protocol (version number is 0).
>>>>
>>>>
>>>> *         Making MP-CAPABLE reliable. There was a lot of support for
>>>> this during the interim, with no-one against. One or two on-going questions
>>>> were raised by Yoshi. This requires a new version number.
>>>>
>>>> If it's agreed that the standards track RFC will be a different version
>>>> number, then several other things have been raised
>>>>
>>>> *         A new Proxy 'P' flag in MP_CAPABLE,
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwei-2Dmptcp-2Dproxy-2Dmechanism-2D02&d=BQIFAg&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=jjrPk64oS-oD6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=jvyGX0tWdV6396IQtsqvNJQ92kEGWhn-GWUmkWZwHpo&e=
>>>>  There was some support for this flag during the interim.
>>>>
>>>> *         Replacing the IPver field in ADD_ADDR with a set of flags.
>>>> Several people have supported this (though not yet have an agreed proposal
>>>> /details).
>>>>
>>>> *         Making the MPTCP token locally meaningful, in order that
>>>> mptcp can work well with load balancers. See the discussion over the last
>>>> few days prompted by
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dpaasch-2Dmptcp-2Dloadbalancer_&d=BQIFAg&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=jjrPk64oS-oD6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=29EQ9N7fXiZSGbwCqBFl-6bDFqOt0TrYNeVUVS1aKsQ&e=
>>>>
>>>> The more general point is that - a new version number would mean that
>>>> we have the opportunity to re-design MPTCP's signalling, based on the
>>>> lessons learnt from the current implementations and deployments and the new
>>>> requirements that have emerged.
>>>>
>>>> So the first step is to make sure that we have consensus that in
>>>> principle the protocol bis will have a new version number.
>>>> Since we didn't explicitly do a consensus call on this during the
>>>> meeting, please send you views, positive or negative, to the list.
>>>>
>>>

---

From: Alan Ford <[email-masked]>
Date: Tue, 15 Sep 2015 10:23:13 +0100

Hi Yoshifumi, all,

I too am in favour of bumping the version number. I am in favour of
including the syncookies handshake mechanism (or something similar, in
order to facilitate the token signalling - for further discussion).

@Nigel - something you'd mentioned some time ago was a little hack on the
ISDN generation - zeroing the most significant bit - in order to remove any
chance of early sequence number wrapping. I don't know if this is something
you'd still like considered for 6824bis? Given a version number bump it's
entirely feasible to add this now.

As regards backward compatibility, we already discuss the fallback
mechanism in 6824bis - if a device supported both version numbers, it could
try both 1 and fall back to 0 if it wanted. But there's no expectation any
device will.

Regards,
Alan

On 15 September 2015 at 07:49, Yoshifumi Nishida <[email-masked]>
wrote:

>>>>> During our interim call last week, several discussion points touched
>>>>> on this topic. The implication would be that the MPTCP version number is 1
>>>>> in the protocol bis (Standards track), and hence it would be incompatible
>>>>> with the current Experimental track protocol (version number is 0).
>>>>>
>>>>>
>>>>> If it's agreed that the standards track RFC will be a different
>>>>> version number, then several other things have been raised
>>>>>

---

From: Nigel Williams <[email-masked]>
Date: Mon, 28 Sep 2015 13:37:02 +1000

Hi Alan,

Sorry, somehow I completely missed this...

On 15/09/15 19:23, Alan Ford wrote:
> @Nigel - something you'd mentioned some time ago was a little hack on
> the ISDN generation - zeroing the most significant bit - in order to
> remove any chance of early sequence number wrapping. I don't know if
> this is something you'd still like considered for 6824bis? Given a
> version number bump it's entirely feasible to add this now.
>

I did use a similar sequence number hack earlier on to help with some 
debugging, though I'm not using anything like that now. I haven't given 
it much thought since then however, so as of now I'm not sure how useful 
it might be.

cheers,
nigel

> mechanism in 6824bis - if a device supported both version numbers, it
> could try both 1 and fall back to 0 if it wanted. But there's no
> expectation any device will.
>
> Regards,
> Alan
>
> On 15 September 2015 at 07:49, Yoshifumi Nishida <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hello folks,
>
>     I guess this means the followings. If I miss something or have
>     different views, please point it out.
>
>     1: The handshake method described in draft-paasch-mptcp-syncookies
>     will be included in 6824bis. This will be a single initial handshake
>     method in mptcp.
>     3: We won't discuss backward compatible mechanisms such as fallback
>     logics (from version 1 to version 0)
>
>     Thanks,
>     --
>     Yoshi
>
>
>     On Mon, Sep 14, 2015 at 5:11 PM, Nigel Williams
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>             The proposed changes are big enough that they will cause
>             backward compatibility issues with existing implementations
>             if added on version 0.
>
>             Thanks,
>             Anumita
>
>                 On Sep 14, 2015, at 10:13 AM, Christoph Paasch
>                 <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 Hello,
>
>                 On 14/09/15 - 14:45:40, [email-masked]
>                 <mailto:[email-masked]> wrote:
>
>                     During our interim call last week, several
>                     discussion points touched on this topic. The
>                     implication would be that the MPTCP version number
>                     is 1 in the protocol bis (Standards track), and
>                     hence it would be incompatible with the current
>                     Experimental track protocol (version number is 0).
>
>
>                     *         Making MP-CAPABLE reliable. There was a
>                     lot of support for this during the interim, with
>                     no-one against. One or two on-going questions were
>                     raised by Yoshi. This requires a new version number.
>
>                     If it's agreed that the standards track RFC will be
>                     a different version number, then several other
>                     things have been raised
>
>                     *         Replacing the IPver field in ADD_ADDR with
>                     a set of flags. Several people have supported this
>                     (though not yet have an agreed proposal /details).
>
>                     *         Making the MPTCP token locally meaningful,
>                     in order that mptcp can work well with load
>                     balancers. See the discussion over the last few days
>                     prompted by
>                     The more general point is that - a new version
>                     number would mean that we have the opportunity to
>                     re-design MPTCP's signalling, based on the lessons
>                     learnt from the current implementations and
>                     deployments and the new requirements that have emerged.
>
>                     So the first step is to make sure that we have
>                     consensus that in principle the protocol bis will
>                     have a new version number.
>                     Since we didn't explicitly do a consensus call on
>                     this during the meeting, please send you views,
>                     positive or negative, to the list.
>
>
>                 [email-masked] <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>