Re: [MPTCP] MPTCP upstreaming introduction

Re: [MPTCP] MPTCP upstreaming introduction

[Mat Martineau]

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


Hi Christoph,

Rao and I talked with David Miller and Eric Dumazet. They aren't 
enthusiastic about MPTCP from a protocol perpective, and pointed to the 
example of kcm as something that builds on top of multiple TCP connections 
rather than modifying TCP itself. I think they're a little skeptical that 
there's a committment to put in the necessary effort to upstream.

A few specific points of our discussions:

* Intrusive changes to TCP are not acceptable, the code is already complex 
and they don't want to introduce bugs or create additional maintenance 
burden. Given the need to tie in to TCP for option parsing (and other 
changed behaviors), they're willing to look at adding hooks - but of 
course reserved judgment until there are actual patches to look at.

* Related to that, skb size cannot increase.

* Regular TCP connections should remain the default and should work like 
they do now.

* Expect the review process to take a while.

These points are what drives the goals I listed below. Identifying the 
right (limited) set of hooks in to the TCP code is going to be an 
important early step.

Best regards,
Mat


On Mon, 10 Apr 2017, Christoph Paasch wrote:

> Hi Mat,
>
> what was the feedback/info you got from netdev 2.1 ?
>
>
> Christoph
>
> On 09/04/17 - 13:12:26, Mat Martineau wrote:
>> Welcome to the MPTCP upstreaming mailing list!
>>
>> This list (mptcp(a)lists.01.org) is focused on integrating MPTCP (RFC 6824 /
>> RFC 6824bis) as part of the standard Linux kernel. In speaking with the
>> Linux networking / TCP maintainers, it is important that MPTCP does not
>> interfere with the performance or reliability of the TCP stack, or
>> complicate the existing TCP code.
>>
>> Given the Linux netdev maintainer's needs, we have the following high-level
>> design goals in mind:
>>
>> * Minimize changes to core TCP.
>>
>> * Favor atomic operations and RCU synchronization over more expensive
>> options like mutexes or spinlocks.
>>
>> * Implement features in userspace where latency isn't important and data
>> flow is not affected
>>
>> * TCP operates as "normal TCP" by default. Individual sockets may opt-in, or
>> systemwide configuration can be used to broadly enable MPTCP.
>>
>> The role of this list is to coordinate upstreaming efforts and share code
>> prior to upstream submission on netdev(a)lists.01.org . This list is separate
>> from the mptcp-dev list associated with the multipath-tcp.org kernel in
>> order to avoid confusion between netdev-focused efforts and work related to
>> multipath-tcp.org . Anyone interested in MPTCP for the upstream kernel is
>> welcome on mptcp(a)lists.01.org, we appreciate your expertise and
>> contributions!
>>
>> You can manage your subscription or view list archives at
>> https://lists.01.org/mailman/listinfo/mptcp
>>
>> Best regards,
>>
>> --
>> Mat Martineau
>> Intel OTC
>

--
Mat Martineau
Intel OTC

Re: [MPTCP] MPTCP upstreaming introduction

[Christoph Paasch]

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

Hello,

On 18/04/17 - 10:59:28, Mat Martineau wrote:
> 
> Hi Christoph,
> 
> On Mon, 17 Apr 2017, Christoph Paasch wrote:
> 
> > Hello Mat,
> > 
> > On 11/04/17 - 15:52:06, Mat Martineau wrote:
> > > 
> > > Hi Christoph,
> > > 
> > > Rao and I talked with David Miller and Eric Dumazet. They aren't
> > > enthusiastic about MPTCP from a protocol perpective, and pointed to the
> > > example of kcm as something that builds on top of multiple TCP connections
> > > rather than modifying TCP itself. I think they're a little skeptical that
> > > there's a committment to put in the necessary effort to upstream.
> > > 
> > > A few specific points of our discussions:
> > > 
> > > * Intrusive changes to TCP are not acceptable, the code is already complex
> > > and they don't want to introduce bugs or create additional maintenance
> > > burden. Given the need to tie in to TCP for option parsing (and other
> > > changed behaviors), they're willing to look at adding hooks - but of course
> > > reserved judgment until there are actual patches to look at.
> > > 
> > > * Related to that, skb size cannot increase.
> > > 
> > > * Regular TCP connections should remain the default and should work like
> > > they do now.
> > 
> > That's good info. So we will have to make it opt-in through a socket-option
> > or even create a new socket-type.
> 
> I experimented with two approaches: AF_MPTCP and IPPROTO_MPTCP (the latter
> using either AF_INET or AF_INET6). IPPROTO_MPTCP worked a lot better with
> existing code (especially Python's socket module!). I'll tidy up the patch
> set and post it.

great! Looking forward to it.

> 
> > > 
> > > * Expect the review process to take a while.
> > > 
> > > These points are what drives the goals I listed below. Identifying the right
> > > (limited) set of hooks in to the TCP code is going to be an important early
> > > step.
> > 
> > sounds great! Do you have a public git repo where the development happens?
> > Might be good to set this up.
> 
> My plan is to share patches on this list, and I will publish a mptcp branch
> on my git.kernel.org repo:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/martineau/linux.git/
> 
> Since we'll be posting patches to netdev, I think it will work well to use
> the typical kernel mailing list 'git send-email' workflow.

Sounds good!


Christoph

Re: [MPTCP] MPTCP upstreaming introduction

[Mat Martineau]

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


Hi Christoph,

On Mon, 17 Apr 2017, Christoph Paasch wrote:

> Hello Mat,
>
> On 11/04/17 - 15:52:06, Mat Martineau wrote:
>>
>> Hi Christoph,
>>
>> Rao and I talked with David Miller and Eric Dumazet. They aren't
>> enthusiastic about MPTCP from a protocol perpective, and pointed to the
>> example of kcm as something that builds on top of multiple TCP connections
>> rather than modifying TCP itself. I think they're a little skeptical that
>> there's a committment to put in the necessary effort to upstream.
>>
>> A few specific points of our discussions:
>>
>> * Intrusive changes to TCP are not acceptable, the code is already complex
>> and they don't want to introduce bugs or create additional maintenance
>> burden. Given the need to tie in to TCP for option parsing (and other
>> changed behaviors), they're willing to look at adding hooks - but of course
>> reserved judgment until there are actual patches to look at.
>>
>> * Related to that, skb size cannot increase.
>>
>> * Regular TCP connections should remain the default and should work like
>> they do now.
>
> That's good info. So we will have to make it opt-in through a socket-option
> or even create a new socket-type.

I experimented with two approaches: AF_MPTCP and IPPROTO_MPTCP (the latter 
using either AF_INET or AF_INET6). IPPROTO_MPTCP worked a lot better with 
existing code (especially Python's socket module!). I'll tidy up the patch 
set and post it.

>>
>> * Expect the review process to take a while.
>>
>> These points are what drives the goals I listed below. Identifying the right
>> (limited) set of hooks in to the TCP code is going to be an important early
>> step.
>
> sounds great! Do you have a public git repo where the development happens?
> Might be good to set this up.

My plan is to share patches on this list, and I will publish a mptcp 
branch on my git.kernel.org repo:

https://git.kernel.org/pub/scm/linux/kernel/git/martineau/linux.git/

Since we'll be posting patches to netdev, I think it will work well to use 
the typical kernel mailing list 'git send-email' workflow.

--
Mat Martineau
Intel OTC

Re: [MPTCP] MPTCP upstreaming introduction

[Christoph Paasch]

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

Hello Mat,

On 11/04/17 - 15:52:06, Mat Martineau wrote:
> 
> Hi Christoph,
> 
> Rao and I talked with David Miller and Eric Dumazet. They aren't
> enthusiastic about MPTCP from a protocol perpective, and pointed to the
> example of kcm as something that builds on top of multiple TCP connections
> rather than modifying TCP itself. I think they're a little skeptical that
> there's a committment to put in the necessary effort to upstream.
> 
> A few specific points of our discussions:
> 
> * Intrusive changes to TCP are not acceptable, the code is already complex
> and they don't want to introduce bugs or create additional maintenance
> burden. Given the need to tie in to TCP for option parsing (and other
> changed behaviors), they're willing to look at adding hooks - but of course
> reserved judgment until there are actual patches to look at.
> 
> * Related to that, skb size cannot increase.
> 
> * Regular TCP connections should remain the default and should work like
> they do now.

That's good info. So we will have to make it opt-in through a socket-option
or even create a new socket-type.

> 
> * Expect the review process to take a while.
> 
> These points are what drives the goals I listed below. Identifying the right
> (limited) set of hooks in to the TCP code is going to be an important early
> step.

sounds great! Do you have a public git repo where the development happens?
Might be good to set this up.


Cheers,
Christoph

> 
> Best regards,
> Mat
> 
> 
> On Mon, 10 Apr 2017, Christoph Paasch wrote:
> 
> > Hi Mat,
> > 
> > what was the feedback/info you got from netdev 2.1 ?
> > 
> > 
> > Christoph
> > 
> > On 09/04/17 - 13:12:26, Mat Martineau wrote:
> > > Welcome to the MPTCP upstreaming mailing list!
> > > 
> > > This list (mptcp(a)lists.01.org) is focused on integrating MPTCP (RFC 6824 /
> > > RFC 6824bis) as part of the standard Linux kernel. In speaking with the
> > > Linux networking / TCP maintainers, it is important that MPTCP does not
> > > interfere with the performance or reliability of the TCP stack, or
> > > complicate the existing TCP code.
> > > 
> > > Given the Linux netdev maintainer's needs, we have the following high-level
> > > design goals in mind:
> > > 
> > > * Minimize changes to core TCP.
> > > 
> > > * Favor atomic operations and RCU synchronization over more expensive
> > > options like mutexes or spinlocks.
> > > 
> > > * Implement features in userspace where latency isn't important and data
> > > flow is not affected
> > > 
> > > * TCP operates as "normal TCP" by default. Individual sockets may opt-in, or
> > > systemwide configuration can be used to broadly enable MPTCP.
> > > 
> > > The role of this list is to coordinate upstreaming efforts and share code
> > > prior to upstream submission on netdev(a)lists.01.org . This list is separate
> > > from the mptcp-dev list associated with the multipath-tcp.org kernel in
> > > order to avoid confusion between netdev-focused efforts and work related to
> > > multipath-tcp.org . Anyone interested in MPTCP for the upstream kernel is
> > > welcome on mptcp(a)lists.01.org, we appreciate your expertise and
> > > contributions!
> > > 
> > > You can manage your subscription or view list archives at
> > > https://lists.01.org/mailman/listinfo/mptcp
> > > 
> > > Best regards,
> > > 
> > > --
> > > Mat Martineau
> > > Intel OTC
> > 
> 
> --
> Mat Martineau
> Intel OTC