[MPTCP] LPC proposal draft

[MPTCP] LPC proposal draft

[Mat Martineau]

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


Hello -

Those of us in the weekly web conference yesterday discussed options for 
a Linux Plumber's Conference networking track talk 
(http://vger.kernel.org/lpc-networking.html). The deadline is coming up 
very soon, on Wednesday, 11 July.

Here's a draft proposal, please comment!

"""

Implementing Multipath TCP requires both adding a layer above TCP and 
modifying the core in a number of places. The layer additions are 
relatively straightforward: adding a new IPPROTO_MPTCP protocol type, 
overriding existing callbacks from the IP layer, and adding to TCP option 
handling. But even after extensive efforts to minimize changes to the TCP 
core there are a handful of modifications required in order to support 
MPTCP. Unlike protocols that layer cleanly entirely above TCP, MPTCP must 
integrate with low-level TCP operations involving receive windows, sending 
and receiving ACKs, and the RST and FIN signals. We will show where the 
TCP core will be affected, why the changes cannot be avoided, and what we 
have done to avoid impacting TCP performance.

"""

--
Mat Martineau
Intel OTC

Re: [MPTCP] LPC proposal draft

[Matthieu Baerts]

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

Hi Mat,

On Tue, Jul 10, 2018 at 12:44 AM Mat Martineau
<mathew.j.martineau(a)linux.intel.com> wrote:
>
>
> Here's the final version that I submitted this evening:
>
> Title: Multipath TCP integration with Linux TCP
>
> Submitters: Mat Martineau, Christoph Paasch, Mattheiu Baerts, Peter
> Krystad, Ossama Othman
>
> Implementing Multipath TCP (RFC-6824) requires both adding a layer above
> TCP and modifying the TCP core in select places. The layer additions are
> relatively straightforward: adding a new IPPROTO_MPTCP protocol type,
> overriding existing callbacks from the IP layer, and adding to TCP option
> handling. But even after extensive efforts by our MPTCP upstreaming
> community to minimize changes to the TCP core there are a handful of
> modifications required in order to support MPTCP. Unlike protocols that
> cleanly layer entirely above TCP, MPTCP must integrate with low-level TCP
> operations involving receive windows, sending and receiving ACKs, and the
> RST and FIN signals. We will show where the TCP core would be affected,
> make a case for why the changes are justified, and explain what we have
> done to avoid impacting TCP performance.

Thank you for the submission, that's a good description! :)

Regards,
Matthieu

>
>
> Regards,
> Mat
>
>
> On Mon, 9 Jul 2018, Mat Martineau wrote:
>
> >
> > On Mon, 9 Jul 2018, Matthieu Baerts wrote:
> >
> >> Hi Mat,
> >>
> >> On Fri, Jul 6, 2018 at 10:22 PM Mat Martineau
> >> <mathew.j.martineau(a)linux.intel.com> wrote:
> >>>
> >>>
> >>> Hello -
> >>>
> >>> Those of us in the weekly web conference yesterday discussed options for
> >>> a Linux Plumber's Conference networking track talk
> >>> (http://vger.kernel.org/lpc-networking.html). The deadline is coming up
> >>> very soon, on Wednesday, 11 July.
> >>>
> >>> Here's a draft proposal, please comment!
> >>>
> >
> > Minor edits to the proposal are inline here - see discussion below:
> >
> >>> """
> >>>
> >>> Implementing Multipath TCP (RFC-6824) requires both adding a layer above
> >>> TCP and modifying the core in a number of places. The layer additions are
> >>> relatively straightforward: adding a new IPPROTO_MPTCP protocol type,
> >>> overriding existing callbacks from the IP layer, and adding to TCP option
> >>> handling. But even after extensive efforts by our MPTCP upstreaming
> >>> community to minimize changes to the TCP core there are a handful of
> >>> modifications required in order to support MPTCP. Unlike protocols that
> >>> layer cleanly entirely above TCP, MPTCP must integrate with low-level TCP
> >>> operations involving receive windows, sending and receiving ACKs, and the
> >>> RST and FIN signals. We will show where the TCP core will be affected, why
> >>> the changes cannot be avoided, and what we have done to avoid impacting
> >>> TCP performance.
> >>>
> >>> """
> >>
> >> Thank you for this draft proposal! That's a very good work for me!
> >>
> >> Should we introduce what is MPTCP and who is behind? Maybe something
> >> very short like this?
> >>
> >> """
> >>
> >> A community project is underway to add Multipath TCP (RFC-6824) to the
> >> upstream Linux kernel. An existing implementation already adds MPTCP
> >> support in the Linux kernel but this version, even if it is used in
> >> production by different (specialised) companies all over the world,
> >> cannot be upstreamed as it is due to its intrusiveness that needs to
> >> be reduced.
> >>
> >> """
> >
> > I think we benefit from keeping the focus narrow (part of that is staying
> > differentiated from our Netdev talk too). I agree we should add the RFC-6824
> > reference, and note that it's a community effort.
> >
> >>
> >> Even if it is obvious for us, should we clearly mention at the end
> >> that we are looking for discussions after that? Maybe something like
> >> this to reuse David's words?
> >>
> >> """
> >>
> >> We will show an architecture design proposal where the TCP core will
> >> be affected, why the changes cannot be avoided, and what we have done
> >> to avoid impacting TCP performance. We are looking forward to have
> >> face-to-face discussions and debate.
> >>
> >> """
> >>
> >> What do you think about that? Note that it is fine for me to send it
> >> as it is, my additions are mainly linked to details!
> >
> > The discussion/debate part is assumed, I think :)
> >
> >>
> >> Christoph also told me this morning that this version is good for him
> >> and if we want, we can send it as it is without waiting for the last
> >> day!
> >>
> >
> > I'm uneasy about sending on the 11th: "Proposal submissions are due by July
> > 11th 2018" leaves it unclear whether they mean "due before July 11th begins"
> > or "due before end-of-day on July 11th". Sending today or tomorrow seems
> > best.
> >
> > Thanks,
> >
> > --
> > Mat Martineau
> > Intel OTC
> > _______________________________________________
> > mptcp mailing list
> > mptcp(a)lists.01.org
> > https://lists.01.org/mailman/listinfo/mptcp
> >
>
> --
> Mat Martineau
> Intel OTC
> _______________________________________________
> mptcp mailing list
> mptcp(a)lists.01.org
> https://lists.01.org/mailman/listinfo/mptcp



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

-- 


DISCLAIMER.
This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they 
are addressed. If you have received this email in error please notify the 
system manager. This message contains confidential information and is 
intended only for the individual named. If you are not the named addressee 
you should not disseminate, distribute or copy this e-mail. Please notify 
the sender immediately by e-mail if you have received this e-mail by 
mistake and delete this e-mail from your system. If you are not the 
intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on the contents of this information is 
strictly prohibited.

Re: [MPTCP] LPC proposal draft

[Mat Martineau]

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


Here's the final version that I submitted this evening:

Title: Multipath TCP integration with Linux TCP

Submitters: Mat Martineau, Christoph Paasch, Mattheiu Baerts, Peter 
Krystad, Ossama Othman

Implementing Multipath TCP (RFC-6824) requires both adding a layer above 
TCP and modifying the TCP core in select places. The layer additions are 
relatively straightforward: adding a new IPPROTO_MPTCP protocol type, 
overriding existing callbacks from the IP layer, and adding to TCP option 
handling. But even after extensive efforts by our MPTCP upstreaming 
community to minimize changes to the TCP core there are a handful of 
modifications required in order to support MPTCP. Unlike protocols that 
cleanly layer entirely above TCP, MPTCP must integrate with low-level TCP 
operations involving receive windows, sending and receiving ACKs, and the 
RST and FIN signals. We will show where the TCP core would be affected, 
make a case for why the changes are justified, and explain what we have 
done to avoid impacting TCP performance.


Regards,
Mat


On Mon, 9 Jul 2018, Mat Martineau wrote:

>
> On Mon, 9 Jul 2018, Matthieu Baerts wrote:
>
>> Hi Mat,
>> 
>> On Fri, Jul 6, 2018 at 10:22 PM Mat Martineau
>> <mathew.j.martineau(a)linux.intel.com> wrote:
>>> 
>>> 
>>> Hello -
>>> 
>>> Those of us in the weekly web conference yesterday discussed options for
>>> a Linux Plumber's Conference networking track talk
>>> (http://vger.kernel.org/lpc-networking.html). The deadline is coming up
>>> very soon, on Wednesday, 11 July.
>>> 
>>> Here's a draft proposal, please comment!
>>> 
>
> Minor edits to the proposal are inline here - see discussion below:
>
>>> """
>>> 
>>> Implementing Multipath TCP (RFC-6824) requires both adding a layer above 
>>> TCP and modifying the core in a number of places. The layer additions are 
>>> relatively straightforward: adding a new IPPROTO_MPTCP protocol type, 
>>> overriding existing callbacks from the IP layer, and adding to TCP option 
>>> handling. But even after extensive efforts by our MPTCP upstreaming 
>>> community to minimize changes to the TCP core there are a handful of 
>>> modifications required in order to support MPTCP. Unlike protocols that 
>>> layer cleanly entirely above TCP, MPTCP must integrate with low-level TCP 
>>> operations involving receive windows, sending and receiving ACKs, and the 
>>> RST and FIN signals. We will show where the TCP core will be affected, why 
>>> the changes cannot be avoided, and what we have done to avoid impacting 
>>> TCP performance.
>>> 
>>> """
>> 
>> Thank you for this draft proposal! That's a very good work for me!
>> 
>> Should we introduce what is MPTCP and who is behind? Maybe something
>> very short like this?
>> 
>> """
>> 
>> A community project is underway to add Multipath TCP (RFC-6824) to the
>> upstream Linux kernel. An existing implementation already adds MPTCP
>> support in the Linux kernel but this version, even if it is used in
>> production by different (specialised) companies all over the world,
>> cannot be upstreamed as it is due to its intrusiveness that needs to
>> be reduced.
>> 
>> """
>
> I think we benefit from keeping the focus narrow (part of that is staying 
> differentiated from our Netdev talk too). I agree we should add the RFC-6824 
> reference, and note that it's a community effort.
>
>> 
>> Even if it is obvious for us, should we clearly mention at the end
>> that we are looking for discussions after that? Maybe something like
>> this to reuse David's words?
>> 
>> """
>> 
>> We will show an architecture design proposal where the TCP core will
>> be affected, why the changes cannot be avoided, and what we have done
>> to avoid impacting TCP performance. We are looking forward to have
>> face-to-face discussions and debate.
>> 
>> """
>> 
>> What do you think about that? Note that it is fine for me to send it
>> as it is, my additions are mainly linked to details!
>
> The discussion/debate part is assumed, I think :)
>
>> 
>> Christoph also told me this morning that this version is good for him
>> and if we want, we can send it as it is without waiting for the last
>> day!
>> 
>
> I'm uneasy about sending on the 11th: "Proposal submissions are due by July 
> 11th 2018" leaves it unclear whether they mean "due before July 11th begins" 
> or "due before end-of-day on July 11th". Sending today or tomorrow seems 
> best.
>
> Thanks,
>
> --
> Mat Martineau
> Intel OTC
> _______________________________________________
> mptcp mailing list
> mptcp(a)lists.01.org
> https://lists.01.org/mailman/listinfo/mptcp
>

--
Mat Martineau
Intel OTC

Re: [MPTCP] LPC proposal draft

[Mat Martineau]

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


On Mon, 9 Jul 2018, Matthieu Baerts wrote:

> Hi Mat,
>
> On Fri, Jul 6, 2018 at 10:22 PM Mat Martineau
> <mathew.j.martineau(a)linux.intel.com> wrote:
>>
>>
>> Hello -
>>
>> Those of us in the weekly web conference yesterday discussed options for
>> a Linux Plumber's Conference networking track talk
>> (http://vger.kernel.org/lpc-networking.html). The deadline is coming up
>> very soon, on Wednesday, 11 July.
>>
>> Here's a draft proposal, please comment!
>>

Minor edits to the proposal are inline here - see discussion below:

>> """
>>
>> Implementing Multipath TCP (RFC-6824) requires both adding a layer 
>> above TCP and modifying the core in a number of places. The layer 
>> additions are relatively straightforward: adding a new IPPROTO_MPTCP 
>> protocol type, overriding existing callbacks from the IP layer, and 
>> adding to TCP option handling. But even after extensive efforts by our 
>> MPTCP upstreaming community to minimize changes to the TCP core there 
>> are a handful of modifications required in order to support MPTCP. 
>> Unlike protocols that layer cleanly entirely above TCP, MPTCP must 
>> integrate with low-level TCP operations involving receive windows, 
>> sending and receiving ACKs, and the RST and FIN signals. We will show 
>> where the TCP core will be affected, why the changes cannot be avoided, 
>> and what we have done to avoid impacting TCP performance.
>>
>> """
>
> Thank you for this draft proposal! That's a very good work for me!
>
> Should we introduce what is MPTCP and who is behind? Maybe something
> very short like this?
>
> """
>
> A community project is underway to add Multipath TCP (RFC-6824) to the
> upstream Linux kernel. An existing implementation already adds MPTCP
> support in the Linux kernel but this version, even if it is used in
> production by different (specialised) companies all over the world,
> cannot be upstreamed as it is due to its intrusiveness that needs to
> be reduced.
>
> """

I think we benefit from keeping the focus narrow (part of that is staying 
differentiated from our Netdev talk too). I agree we should add the 
RFC-6824 reference, and note that it's a community effort.

>
> Even if it is obvious for us, should we clearly mention at the end
> that we are looking for discussions after that? Maybe something like
> this to reuse David's words?
>
> """
>
> We will show an architecture design proposal where the TCP core will
> be affected, why the changes cannot be avoided, and what we have done
> to avoid impacting TCP performance. We are looking forward to have
> face-to-face discussions and debate.
>
> """
>
> What do you think about that? Note that it is fine for me to send it
> as it is, my additions are mainly linked to details!

The discussion/debate part is assumed, I think :)

>
> Christoph also told me this morning that this version is good for him
> and if we want, we can send it as it is without waiting for the last
> day!
>

I'm uneasy about sending on the 11th: "Proposal submissions are due by 
July 11th 2018" leaves it unclear whether they mean "due before July 11th 
begins" or "due before end-of-day on July 11th". Sending today or tomorrow 
seems best.

Thanks,

--
Mat Martineau
Intel OTC

Re: [MPTCP] LPC proposal draft

[Matthieu Baerts]

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

Hi Mat,

On Fri, Jul 6, 2018 at 10:22 PM Mat Martineau
<mathew.j.martineau(a)linux.intel.com> wrote:
>
>
> Hello -
>
> Those of us in the weekly web conference yesterday discussed options for
> a Linux Plumber's Conference networking track talk
> (http://vger.kernel.org/lpc-networking.html). The deadline is coming up
> very soon, on Wednesday, 11 July.
>
> Here's a draft proposal, please comment!
>
> """
>
> Implementing Multipath TCP requires both adding a layer above TCP and
> modifying the core in a number of places. The layer additions are
> relatively straightforward: adding a new IPPROTO_MPTCP protocol type,
> overriding existing callbacks from the IP layer, and adding to TCP option
> handling. But even after extensive efforts to minimize changes to the TCP
> core there are a handful of modifications required in order to support
> MPTCP. Unlike protocols that layer cleanly entirely above TCP, MPTCP must
> integrate with low-level TCP operations involving receive windows, sending
> and receiving ACKs, and the RST and FIN signals. We will show where the
> TCP core will be affected, why the changes cannot be avoided, and what we
> have done to avoid impacting TCP performance.
>
> """

Thank you for this draft proposal! That's a very good work for me!

Should we introduce what is MPTCP and who is behind? Maybe something
very short like this?

"""

A community project is underway to add Multipath TCP (RFC-6824) to the
upstream Linux kernel. An existing implementation already adds MPTCP
support in the Linux kernel but this version, even if it is used in
production by different (specialised) companies all over the world,
cannot be upstreamed as it is due to its intrusiveness that needs to
be reduced.

"""

Even if it is obvious for us, should we clearly mention at the end
that we are looking for discussions after that? Maybe something like
this to reuse David's words?

"""

We will show an architecture design proposal where the TCP core will
be affected, why the changes cannot be avoided, and what we have done
to avoid impacting TCP performance. We are looking forward to have
face-to-face discussions and debate.

"""

What do you think about that? Note that it is fine for me to send it
as it is, my additions are mainly linked to details!

Christoph also told me this morning that this version is good for him
and if we want, we can send it as it is without waiting for the last
day!

Have a good day!
Matthieu

>
> --
> Mat Martineau
> Intel OTC



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

-- 


DISCLAIMER.
This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they 
are addressed. If you have received this email in error please notify the 
system manager. This message contains confidential information and is 
intended only for the individual named. If you are not the named addressee 
you should not disseminate, distribute or copy this e-mail. Please notify 
the sender immediately by e-mail if you have received this e-mail by 
mistake and delete this e-mail from your system. If you are not the 
intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on the contents of this information is 
strictly prohibited.

Re: [MPTCP] LPC proposal draft

[Christoph Paasch]

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

Hello Mat,

this looks good to me! Let's discuss on Wednesday in Montreal before the
deadline.


Cheers,
Christoph

On 06/07/18 - 15:22:14, Mat Martineau wrote:
> 
> Hello -
> 
> Those of us in the weekly web conference yesterday discussed options for a
> Linux Plumber's Conference networking track talk
> (http://vger.kernel.org/lpc-networking.html). The deadline is coming up very
> soon, on Wednesday, 11 July.
> 
> Here's a draft proposal, please comment!
> 
> """
> 
> Implementing Multipath TCP requires both adding a layer above TCP and
> modifying the core in a number of places. The layer additions are relatively
> straightforward: adding a new IPPROTO_MPTCP protocol type, overriding
> existing callbacks from the IP layer, and adding to TCP option handling. But
> even after extensive efforts to minimize changes to the TCP core there are a
> handful of modifications required in order to support MPTCP. Unlike
> protocols that layer cleanly entirely above TCP, MPTCP must integrate with
> low-level TCP operations involving receive windows, sending and receiving
> ACKs, and the RST and FIN signals. We will show where the TCP core will be
> affected, why the changes cannot be avoided, and what we have done to avoid
> impacting TCP performance.
> 
> """
> 
> --
> Mat Martineau
> Intel OTC