[MPTCP] Re: Cover letters for part1/part2 netdev patchsets

[MPTCP] Re: Cover letters for part1/part2 netdev patchsets

[Matthieu Baerts]

[-- Attachment #1: Type: text/plain, Size: 1900 bytes --]

Hi Mat,

On 06/12/2019 01:41, Mat Martineau wrote:
> 
> Hello everyone -
> 
> As we discussed earlier today, here are draft cover letters for patch 
> set parts 1 & 2. Feedback appreciated!
> 
> 
> ------
> Part 1
> 
> Subject: [PATCH net-next 0/0] Multipath TCP part 1: Prerequisites
> 
> The MPTCP upstreaming community has been collaborating on an
> upstreamable MPTCP implementation. David requested that we split this
> work in to multiple, smaller patch sets to build up MPTCP
> infrastructure. The scope of this first patch set is limited to
> prerequisite TCP core changes so we can get focused feedback in these
> areas.

Related to why I proposed on "Checklist before sending to netdev" ML, 
should we already introduce here the fact that we are going to send 3 
different patch sets and why we cannot send all in one or less patches?

Something like:

     - The protocol is what it is and having a minimal set of features 
already signifies a lot of code.
     - This minimal set of features includes: the possibility for the 
userspace to establish and properly terminate MPTCP connections but 
limited to one subflow while still being able to transfer data in both 
directions
     - We decided to split everything in 3 parts to ease the reviews:
         - Part 1: Prerequisite TCP core changes
         - Part 2: MPTCP minimal set of features including selftests
         - Part 3: a switch from MPTCPv0 (RFC 6824) to MPTCPv1 (new RFC 
8684 going to obsolete the previous one in the coming days)
     - The idea would be to apply everything in the same "merge window".

Feel free to improve this of course :)

For the rest, it looks good to me!

Cheers,
Matt
-- 
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium

[MPTCP] Re: Cover letters for part1/part2 netdev patchsets

[Matthieu Baerts]

[-- Attachment #1: Type: text/plain, Size: 4230 bytes --]

On 13/12/2019 21:41, Mat Martineau wrote:
> On Fri, 13 Dec 2019, Matthieu Baerts wrote:
> 
>> Hi Mat,
>>
>> On 13/12/2019 20:19, Mat Martineau wrote:
>>>
>>> On Fri, 13 Dec 2019, Matthieu Baerts wrote:
>>>
>>>> Hi Mat,
>>>>
>>>> On 06/12/2019 01:41, Mat Martineau wrote:
>>>>>
>>>>> Hello everyone -
>>>>>
>>>>> As we discussed earlier today, here are draft cover letters for 
>>>>> patch set parts 1 & 2. Feedback appreciated!
>>>>>
>>>>>
>>>>> ------
>>>>> Part 1
>>>>>
>>>>> Subject: [PATCH net-next 0/0] Multipath TCP part 1: Prerequisites
>>>>>
>>>>> The MPTCP upstreaming community has been collaborating on an
>>>>> upstreamable MPTCP implementation. David requested that we split this
>>>>> work in to multiple, smaller patch sets to build up MPTCP
>>>>> infrastructure. The scope of this first patch set is limited to
>>>>> prerequisite TCP core changes so we can get focused feedback in these
>>>>> areas.
>>>>
>>>> Related to why I proposed on "Checklist before sending to netdev" 
>>>> ML, should we already introduce here the fact that we are going to 
>>>> send 3 different patch sets and why we cannot send all in one or 
>>>> less patches?
>>>>
>>>> Something like:
>>>>
>>>>    - The protocol is what it is and having a minimal set of features 
>>>> already signifies a lot of code.
>>>>    - This minimal set of features includes: the possibility for the 
>>>> userspace to establish and properly terminate MPTCP connections but 
>>>> limited to one subflow while still being able to transfer data in 
>>>> both directions
>>>>    - We decided to split everything in 3 parts to ease the reviews:
>>>>        - Part 1: Prerequisite TCP core changes
>>>>        - Part 2: MPTCP minimal set of features including selftests
>>>>        - Part 3: a switch from MPTCPv0 (RFC 6824) to MPTCPv1 (new 
>>>> RFC 8684 going to obsolete the previous one in the coming days)
>>>>    - The idea would be to apply everything in the same "merge window".
>>>>
>>>> Feel free to improve this of course :)
>>>
>>> Thanks Matthieu, good suggestion. Am I correct in thinking the plan 
>>> is to have part 4 in this window as well, just in January sometime?
>>>
>>> Updated draft:
>>>
>>> ----
>>> Subject: [PATCH net-next 0/0] Multipath TCP part 1: Prerequisites
>>>
>>> The MPTCP upstreaming community has been collaborating on an 
>>> upstreamable MPTCP implementation that complies with RFC 8684. A 
>>> minimal set of features to comply with the specification involves a 
>>> sizeable set of code changes, so David requested that we split this 
>>> work in to multiple, smaller patch sets to build up MPTCP 
>>> infrastructure.
>>>
>>> The minimal MPTCP feature set we are proposing for the v5.6 timeframe 
>>> is split in to these parts for review:
>>>
>>> Part 1 (this patch set): MPTCP prerequisites. Introduce some MPTCP 
>>> definitions, additional ULP and skb extension features, TCP option 
>>> space checking, and a few exported symbols.
>>>
>>> Part 2: Single subflow implementation and self tests.
>>>
>>> Part 3: Switch from MPTCP v0 (RFC 6824) to MPTCP v1 (new RFC 8684, 
>>> publication expected in the next few days).
>>>
>>> Part 4: Multiple subflow support.
>>
>> I would not mention Part 4 for the moment. Maybe better to wait and 
>> see how the other patches will be welcomed, no?
> 
> How about
> 
> """
> The minimal MPTCP feature set we are proposing for review in the v5.6 
> timeframe begins with these parts:
> """
> 
> and drop part 4?

Yes, sounds good but what about keeping this sentence and add this at 
the end instead of part 3:

   More commits are in preparation to add multiple subflow support, path 
management, active backup support and more but this will come later when 
these 3 previous parts are reviewed and applied.

I hope it is clear that we don't have to wait for any part 4 :)

And also:

   The part 2 is coming later today and part 3 over the next week.

Cheers,
Matt
-- 
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium

[MPTCP] Re: Cover letters for part1/part2 netdev patchsets

[Mat Martineau]

[-- Attachment #1: Type: text/plain, Size: 3473 bytes --]

On Fri, 13 Dec 2019, Matthieu Baerts wrote:

> Hi Mat,
>
> On 13/12/2019 20:19, Mat Martineau wrote:
>> 
>> On Fri, 13 Dec 2019, Matthieu Baerts wrote:
>> 
>>> Hi Mat,
>>> 
>>> On 06/12/2019 01:41, Mat Martineau wrote:
>>>> 
>>>> Hello everyone -
>>>> 
>>>> As we discussed earlier today, here are draft cover letters for patch set 
>>>> parts 1 & 2. Feedback appreciated!
>>>> 
>>>> 
>>>> ------
>>>> Part 1
>>>> 
>>>> Subject: [PATCH net-next 0/0] Multipath TCP part 1: Prerequisites
>>>> 
>>>> The MPTCP upstreaming community has been collaborating on an
>>>> upstreamable MPTCP implementation. David requested that we split this
>>>> work in to multiple, smaller patch sets to build up MPTCP
>>>> infrastructure. The scope of this first patch set is limited to
>>>> prerequisite TCP core changes so we can get focused feedback in these
>>>> areas.
>>> 
>>> Related to why I proposed on "Checklist before sending to netdev" ML, 
>>> should we already introduce here the fact that we are going to send 3 
>>> different patch sets and why we cannot send all in one or less patches?
>>> 
>>> Something like:
>>>
>>>    - The protocol is what it is and having a minimal set of features 
>>> already signifies a lot of code.
>>>    - This minimal set of features includes: the possibility for the 
>>> userspace to establish and properly terminate MPTCP connections but 
>>> limited to one subflow while still being able to transfer data in both 
>>> directions
>>>    - We decided to split everything in 3 parts to ease the reviews:
>>>        - Part 1: Prerequisite TCP core changes
>>>        - Part 2: MPTCP minimal set of features including selftests
>>>        - Part 3: a switch from MPTCPv0 (RFC 6824) to MPTCPv1 (new RFC 8684 
>>> going to obsolete the previous one in the coming days)
>>>    - The idea would be to apply everything in the same "merge window".
>>> 
>>> Feel free to improve this of course :)
>> 
>> Thanks Matthieu, good suggestion. Am I correct in thinking the plan is to 
>> have part 4 in this window as well, just in January sometime?
>> 
>> Updated draft:
>> 
>> ----
>> Subject: [PATCH net-next 0/0] Multipath TCP part 1: Prerequisites
>> 
>> The MPTCP upstreaming community has been collaborating on an upstreamable 
>> MPTCP implementation that complies with RFC 8684. A minimal set of features 
>> to comply with the specification involves a sizeable set of code changes, 
>> so David requested that we split this work in to multiple, smaller patch 
>> sets to build up MPTCP infrastructure.
>> 
>> The minimal MPTCP feature set we are proposing for the v5.6 timeframe is 
>> split in to these parts for review:
>> 
>> Part 1 (this patch set): MPTCP prerequisites. Introduce some MPTCP 
>> definitions, additional ULP and skb extension features, TCP option space 
>> checking, and a few exported symbols.
>> 
>> Part 2: Single subflow implementation and self tests.
>> 
>> Part 3: Switch from MPTCP v0 (RFC 6824) to MPTCP v1 (new RFC 8684, 
>> publication expected in the next few days).
>> 
>> Part 4: Multiple subflow support.
>
> I would not mention Part 4 for the moment. Maybe better to wait and see how 
> the other patches will be welcomed, no?

How about

"""
The minimal MPTCP feature set we are proposing for review in the v5.6 
timeframe begins with these parts:
"""

and drop part 4?

--
Mat Martineau
Intel

[MPTCP] Re: Cover letters for part1/part2 netdev patchsets

[Matthieu Baerts]

[-- Attachment #1: Type: text/plain, Size: 3347 bytes --]

Hi Mat,

On 13/12/2019 20:19, Mat Martineau wrote:
> 
> On Fri, 13 Dec 2019, Matthieu Baerts wrote:
> 
>> Hi Mat,
>>
>> On 06/12/2019 01:41, Mat Martineau wrote:
>>>
>>> Hello everyone -
>>>
>>> As we discussed earlier today, here are draft cover letters for patch 
>>> set parts 1 & 2. Feedback appreciated!
>>>
>>>
>>> ------
>>> Part 1
>>>
>>> Subject: [PATCH net-next 0/0] Multipath TCP part 1: Prerequisites
>>>
>>> The MPTCP upstreaming community has been collaborating on an
>>> upstreamable MPTCP implementation. David requested that we split this
>>> work in to multiple, smaller patch sets to build up MPTCP
>>> infrastructure. The scope of this first patch set is limited to
>>> prerequisite TCP core changes so we can get focused feedback in these
>>> areas.
>>
>> Related to why I proposed on "Checklist before sending to netdev" ML, 
>> should we already introduce here the fact that we are going to send 3 
>> different patch sets and why we cannot send all in one or less patches?
>>
>> Something like:
>>
>>    - The protocol is what it is and having a minimal set of features 
>> already signifies a lot of code.
>>    - This minimal set of features includes: the possibility for the 
>> userspace to establish and properly terminate MPTCP connections but 
>> limited to one subflow while still being able to transfer data in both 
>> directions
>>    - We decided to split everything in 3 parts to ease the reviews:
>>        - Part 1: Prerequisite TCP core changes
>>        - Part 2: MPTCP minimal set of features including selftests
>>        - Part 3: a switch from MPTCPv0 (RFC 6824) to MPTCPv1 (new RFC 
>> 8684 going to obsolete the previous one in the coming days)
>>    - The idea would be to apply everything in the same "merge window".
>>
>> Feel free to improve this of course :)
> 
> Thanks Matthieu, good suggestion. Am I correct in thinking the plan is 
> to have part 4 in this window as well, just in January sometime?
> 
> Updated draft:
> 
> ----
> Subject: [PATCH net-next 0/0] Multipath TCP part 1: Prerequisites
> 
> The MPTCP upstreaming community has been collaborating on an 
> upstreamable MPTCP implementation that complies with RFC 8684. A minimal 
> set of features to comply with the specification involves a sizeable set 
> of code changes, so David requested that we split this work in to 
> multiple, smaller patch sets to build up MPTCP infrastructure.
> 
> The minimal MPTCP feature set we are proposing for the v5.6 timeframe is 
> split in to these parts for review:
> 
> Part 1 (this patch set): MPTCP prerequisites. Introduce some MPTCP 
> definitions, additional ULP and skb extension features, TCP option space 
> checking, and a few exported symbols.
> 
> Part 2: Single subflow implementation and self tests.
> 
> Part 3: Switch from MPTCP v0 (RFC 6824) to MPTCP v1 (new RFC 8684, 
> publication expected in the next few days).
> 
> Part 4: Multiple subflow support.

I would not mention Part 4 for the moment. Maybe better to wait and see 
how the other patches will be welcomed, no?

Cheers,
Matt
-- 
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium

[MPTCP] Re: Cover letters for part1/part2 netdev patchsets

[Mat Martineau]

[-- Attachment #1: Type: text/plain, Size: 3018 bytes --]


On Fri, 13 Dec 2019, Matthieu Baerts wrote:

> Hi Mat,
>
> On 06/12/2019 01:41, Mat Martineau wrote:
>> 
>> Hello everyone -
>> 
>> As we discussed earlier today, here are draft cover letters for patch set 
>> parts 1 & 2. Feedback appreciated!
>> 
>> 
>> ------
>> Part 1
>> 
>> Subject: [PATCH net-next 0/0] Multipath TCP part 1: Prerequisites
>> 
>> The MPTCP upstreaming community has been collaborating on an
>> upstreamable MPTCP implementation. David requested that we split this
>> work in to multiple, smaller patch sets to build up MPTCP
>> infrastructure. The scope of this first patch set is limited to
>> prerequisite TCP core changes so we can get focused feedback in these
>> areas.
>
> Related to why I proposed on "Checklist before sending to netdev" ML, should 
> we already introduce here the fact that we are going to send 3 different 
> patch sets and why we cannot send all in one or less patches?
>
> Something like:
>
>    - The protocol is what it is and having a minimal set of features already 
> signifies a lot of code.
>    - This minimal set of features includes: the possibility for the 
> userspace to establish and properly terminate MPTCP connections but limited 
> to one subflow while still being able to transfer data in both directions
>    - We decided to split everything in 3 parts to ease the reviews:
>        - Part 1: Prerequisite TCP core changes
>        - Part 2: MPTCP minimal set of features including selftests
>        - Part 3: a switch from MPTCPv0 (RFC 6824) to MPTCPv1 (new RFC 8684 
> going to obsolete the previous one in the coming days)
>    - The idea would be to apply everything in the same "merge window".
>
> Feel free to improve this of course :)

Thanks Matthieu, good suggestion. Am I correct in thinking the plan is to 
have part 4 in this window as well, just in January sometime?

Updated draft:

----
Subject: [PATCH net-next 0/0] Multipath TCP part 1: Prerequisites

The MPTCP upstreaming community has been collaborating on an upstreamable 
MPTCP implementation that complies with RFC 8684. A minimal set of 
features to comply with the specification involves a sizeable set of code 
changes, so David requested that we split this work in to multiple, 
smaller patch sets to build up MPTCP infrastructure.

The minimal MPTCP feature set we are proposing for the v5.6 timeframe is 
split in to these parts for review:

Part 1 (this patch set): MPTCP prerequisites. Introduce some MPTCP 
definitions, additional ULP and skb extension features, TCP option space 
checking, and a few exported symbols.

Part 2: Single subflow implementation and self tests.

Part 3: Switch from MPTCP v0 (RFC 6824) to MPTCP v1 (new RFC 8684, 
publication expected in the next few days).

Part 4: Multiple subflow support.

<git tree references at github>

Thank you for your review. You can find us at mptcp(a)lists.01.org and
https://is.gd/mptcp_upstream



--
Mat Martineau
Intel

[MPTCP] Re: Cover letters for part1/part2 netdev patchsets

[Christoph Paasch]

[-- Attachment #1: Type: text/plain, Size: 2378 bytes --]

Thanks for catching these! Update:

=====


Subject: [PATCH net-next 0/0] Multipath TCP part 3: MPTCPv1 (RFC 8684) support

These patches depend on the "Multipath TCP part 2: Single subflow"
patch set sent earlier.

In this set we add the necessary code for the RFC8684-style handshake.
RFC8684 obsoletes the experimental RFC6824 and makes MPTCP move-on to
version 1.

The MPTCP patchset exclusively supports RFC 8684. Although all MPTCP
deployments are currently based on RFC 6824, future deployments will be
migrating to MPTCP version 1. 3GPP's 5G standardization also solely supports
RFC 8684. Also, we believe that this initial submission of MPTCP will be
cleaner by solely supporting RFC 8684. If later on support for the old
MPTCP-version is required it can always be added in the future.

The major difference between RFC 8684 and RFC 6824 is that it has a better
support for servers using TCP SYN-cookies by reliably retransmitting the
MP_CAPABLE option.

<git tree references at github>

Thank your for your review. You can find us at mptcp(a)lists.01.org <mailto:mptcp(a)lists.01.org> and
https://is.gd/mptcp_upstream <https://is.gd/mptcp_upstream>.


=====


Christoph

On 13/12/19 - 19:28:11, Matthieu Baerts wrote:
> Hi Christoph,
> 
> On 13/12/2019 19:19, Christoph Paasch wrote:
> > Sure, here is the update:
> > 
> > ====
> > 
> > Subject: [PATCH net-next 0/0] Multipath TCP part 3: MPTCPv1 (RFC 8684) support
> > 
> > These patches depend on the "Multipath TCP part 2: Single subflow"
> > patch set sent earlier.
> > 
> > In this set we add the necessary code for the RFC8684-style handshake.
> > RFC8684 obsoletes the experimental RFC6824 and makes MPTCP move-on the
> 
> I think a word is missing at the end here, maybe:
> 
>   (...) makes MPTCP move onto version 1.
> 
> or "move-on to version 1"?
> 
> > version 1.
> > 
> > The MPTCP patchset exclusively supports RFC 8684. Although all MPTCP
> > deploiments are currently based on RFC 6824, future deploiments will be
> 
> Small detail: s/deploiments/deployments/g (2 times)
> 
> The rest is good, thank you for the update! :)
> 
> Cheers,
> Matt
> -- 
> Matthieu Baerts | R&D Engineer
> matthieu.baerts(a)tessares.net
> Tessares SA | Hybrid Access Solutions
> www.tessares.net
> 1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium

[MPTCP] Re: Cover letters for part1/part2 netdev patchsets

[Matthieu Baerts]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

Hi Christoph,

On 13/12/2019 19:19, Christoph Paasch wrote:
> Sure, here is the update:
> 
> ====
> 
> Subject: [PATCH net-next 0/0] Multipath TCP part 3: MPTCPv1 (RFC 8684) support
> 
> These patches depend on the "Multipath TCP part 2: Single subflow"
> patch set sent earlier.
> 
> In this set we add the necessary code for the RFC8684-style handshake.
> RFC8684 obsoletes the experimental RFC6824 and makes MPTCP move-on the

I think a word is missing at the end here, maybe:

   (...) makes MPTCP move onto version 1.

or "move-on to version 1"?

> version 1.
> 
> The MPTCP patchset exclusively supports RFC 8684. Although all MPTCP
> deploiments are currently based on RFC 6824, future deploiments will be

Small detail: s/deploiments/deployments/g (2 times)

The rest is good, thank you for the update! :)

Cheers,
Matt
-- 
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium

[MPTCP] Re: Cover letters for part1/part2 netdev patchsets

[Christoph Paasch]

[-- Attachment #1: Type: text/plain, Size: 2695 bytes --]

Sure, here is the update:

====

Subject: [PATCH net-next 0/0] Multipath TCP part 3: MPTCPv1 (RFC 8684) support

These patches depend on the "Multipath TCP part 2: Single subflow"
patch set sent earlier.

In this set we add the necessary code for the RFC8684-style handshake.
RFC8684 obsoletes the experimental RFC6824 and makes MPTCP move-on the
version 1.

The MPTCP patchset exclusively supports RFC 8684. Although all MPTCP
deploiments are currently based on RFC 6824, future deploiments will be
migrating to MPTCP version 1. 3GPP's 5G standardization also solely supports
RFC 8684. Also, we believe that this initial submission of MPTCP will be
cleaner by solely supporting RFC 8684. If later on support for the old
MPTCP-version is required it can always be added in the future.

The major difference between RFC 8684 and RFC 6824 is that it has a better
support for servers using TCP SYN-cookies by reliably retransmitting the
MP_CAPABLE option.

<git tree references at github>

Thank your for your review. You can find us at mptcp(a)lists.01.org <mailto:mptcp(a)lists.01.org> and
https://is.gd/mptcp_upstream <https://is.gd/mptcp_upstream>.

====



Christoph


On 13/12/19 - 12:04:24, Matthieu Baerts wrote:
> Hi Christoph,
> 
> On 13/12/2019 02:19, Christoph Paasch wrote:
> > for part 3:
> 
> Thank you for sharing this!
> 
> > Subject: [PATCH net-next 0/0] Multipath TCP part 3: MP_CAPABLE handshake
> 
> Should we call it:
> 
>   Multipath TCP part 3: MPTCPv1 (RFC 8684) support
> 
> > These patches depend on the "Multipath TCP part 2: Single subflow"
> > patch set sent earlier.
> > 
> > In this set we add the necessary code for the MP_CAPABLE exchange,
> > negotiating the MPTCP-version, keys and some flags. The handshake
> > has been specified such that it works reliably with servers using TCP
> > SYN-cookies
> > although the current implementation does not yet support SYN cookies.
> Should we give more details about MPTCPv1?
> - What it is: RFC 8684, obsoleting RFC 6824
> - Why we want to support it on drop the previous support: ease the code, RFC
> 6824 is obsolete and should not be used in new deployment, e.g. 5G, link to
> the 3GPP document
> - Why we did it like that: some deployments only support MPTCPv0 and didn't
> switch to the new version yet. If really needed, with this history it would
> be easier to re-add MPTCPv0 support in addition to the v1.
> 
> What do you think?
> 
> Cheers,
> Matt
> -- 
> Matthieu Baerts | R&D Engineer
> matthieu.baerts(a)tessares.net
> Tessares SA | Hybrid Access Solutions
> www.tessares.net
> 1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium

[MPTCP] Re: Cover letters for part1/part2 netdev patchsets

[Matthieu Baerts]

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

Hi Christoph,

On 13/12/2019 02:19, Christoph Paasch wrote:
> for part 3:

Thank you for sharing this!

> Subject: [PATCH net-next 0/0] Multipath TCP part 3: MP_CAPABLE handshake

Should we call it:

   Multipath TCP part 3: MPTCPv1 (RFC 8684) support

> These patches depend on the "Multipath TCP part 2: Single subflow"
> patch set sent earlier.
> 
> In this set we add the necessary code for the MP_CAPABLE exchange,
> negotiating the MPTCP-version, keys and some flags. The handshake
> has been specified such that it works reliably with servers using TCP 
> SYN-cookies
> although the current implementation does not yet support SYN cookies.
Should we give more details about MPTCPv1?
- What it is: RFC 8684, obsoleting RFC 6824
- Why we want to support it on drop the previous support: ease the code, 
RFC 6824 is obsolete and should not be used in new deployment, e.g. 5G, 
link to the 3GPP document
- Why we did it like that: some deployments only support MPTCPv0 and 
didn't switch to the new version yet. If really needed, with this 
history it would be easier to re-add MPTCPv0 support in addition to the v1.

What do you think?

Cheers,
Matt
-- 
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium

[MPTCP] Re: Cover letters for part1/part2 netdev patchsets

[Christoph Paasch]

[-- Attachment #1: Type: text/plain, Size: 2675 bytes --]

Hello,

for part 3:

=======


Subject: [PATCH net-next 0/0] Multipath TCP part 3: MP_CAPABLE handshake

These patches depend on the "Multipath TCP part 2: Single subflow"
patch set sent earlier.

In this set we add the necessary code for the MP_CAPABLE exchange,
negotiating the MPTCP-version, keys and some flags. The handshake
has been specified such that it works reliably with servers using TCP SYN-cookies
although the current implementation does not yet support SYN cookies.

<git tree references at github>

Thank your for your review. You can find us at mptcp(a)lists.01.org <mailto:mptcp(a)lists.01.org> and
https://is.gd/mptcp_upstream <https://is.gd/mptcp_upstream>.



======



Please let me know if something should be changed.


Christoph




> On Dec 5, 2019, at 4:41 PM, Mat Martineau <mathew.j.martineau(a)linux.intel.com> wrote:
> 
> 
> Hello everyone -
> 
> As we discussed earlier today, here are draft cover letters for patch set parts 1 & 2. Feedback appreciated!
> 
> 
> ------
> Part 1
> 
> Subject: [PATCH net-next 0/0] Multipath TCP part 1: Prerequisites
> 
> The MPTCP upstreaming community has been collaborating on an
> upstreamable MPTCP implementation. David requested that we split this
> work in to multiple, smaller patch sets to build up MPTCP
> infrastructure. The scope of this first patch set is limited to
> prerequisite TCP core changes so we can get focused feedback in these
> areas.
> 
> In this patch set we introduce some MPTCP definitions, additional ULP
> and skb extension features, TCP option space checking, and a few
> exported symbols.
> 
> <git tree references at github>
> 
> Thank you for your review. You can find us at mptcp(a)lists.01.org and
> https://is.gd/mptcp_upstream
> 
> 
> ------
> Part 2
> 
> Subject: [PATCH net-next 0/0] Multipath TCP part 2: Single subflow
> 
> These patches depend on the "Multipath TCP part 1: Prerequisites" patch
> set sent earlier.
> 
> This set adds MPTCP connection establishment, writing & reading MPTCP
> options on data packets, a sysctl to allow MPTCP per-namespace, and self
> tests. This is sufficient to establish and maintain a connection with a
> MPTCP peer, but will not yet allow or initiate establishment of
> additional MPTCP subflows.
> 
> <git tree references at github>
> 
> Thank you for your review. You can find us at mptcp(a)lists.01.org and
> https://is.gd/mptcp_upstream
> 
> 
> --
> Mat Martineau
> Intel
> _______________________________________________
> mptcp mailing list -- mptcp(a)lists.01.org
> To unsubscribe send an email to mptcp-leave(a)lists.01.org


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 4538 bytes --]