Hi Mat,

Thank you for this email! I am sure it is useful for people not participating to our public web conference calls.

I just added a link to your email in MPTCP's wiki: http://multipath-tcp.org/pmwiki.php/Developer/Upstreaming

Best regards,
Matthieu

On Sat, Mar 24, 2018 at 8:47 PM, Mat Martineau <mathew.j.martineau@linux.intel.com> wrote:

Hello everyone -

In our recent web conference call, we thought it would be helpful to summarize what is coming up for MPTCP upstreaming. To start, I'd like to review work that's already been done and is underway.

Previous work:

* Mat developed an extensible TCP option framework patch, and Christoph refactored upstream TCP-MD5 and SMC functionality to use it. The idea was to integrate some extensions in to TCP that had utility for existing functionality, but would also help integrate MPTCP. This RFC patch set was turned down by Dave Miller, but did give us useful guidance.

* Mat published a proposal for optionally extending sk_buff shared info to carry MPTCP metadata.


Ongoing work:

* Christoph keeps the multipath-tcp.org kernel merged with recent kernel releases as part of his maintainership role for the multipath-tcp.org project, and is refactoring parts of the MPTCP implementation to take advantage of newer kernel or TCP features and to align with upstreaming goals.

* Rao has published an RFC patch set based on the multipath-tcp.org MPTCP implementation and the current upstream kernel, with modifications to make the TCP implementation extensible in a way that's useful for MPTCP. It is currently under review by community members.

* Matthieu has sent a generic netlink patch set to mptcp-dev.

* Ossama shared a generic netlink path management API proposal. The Intel group developed this before we knew Matthieu would be sharing an implementation.

* Stephan shared a userspace path manager draft implementation at https://github.com/brenns10/pathmand

* Peter and Mat are preparing a patch set showing an MPTCP architecture with a separate socket type for the MPTCP connection and using in-kernel TCP sockets for subflows. The extended sk_buff structure patch is part of this.

* Ossama has made significant progress on a userspace path manager implementation with the goal to open source it

That gives us quite a bit to discuss and review on the list in the near term. The bigger and longer-term challenge is to take these pieces and develop a strategy and patches for upstream submissions.


There are a few things the MPTCP upstreaming community members on this list seem aligned on:

* MPTCP belongs in the upstream kernel

* The multipath-tcp.org implementation is not upstream-ready as-is

* Implementing 100% from scratch is not the preferred strategy


How do we get to upstreamable patch sets from here? I think if we can agree on what an upstreamable MPTCP architecture looks we can evaluate patch sets accordingly. I've proposed these design characteristics before, but the mailing list has expanded significantly since then:

* MPTCP is used when requested by the application, either through an IPPROTO_MPTCP parameter to socket() or by using the new ULP (Upper Layer Protocol) capability.

* Move away from meta-sockets, treating each subflow more like a regular TCP connection. The overall MPTCP connection is coordinated by an upper layer socket that is distinct from tcp_sock.

* Move functionality to userspace where possible, like tracking ADD_ADDRs received, initiating new subflows, or accepting new subflows.

* Avoid adding locks to coordinate access to data that's shared between subflows. Utilize capabilities like compare-and-swap (cmpxchg), atomics, and RCU to deal with shared data efficiently.

Are these the right place to start? Anyone want to expand the list?


Thanks,

--
Mat Martineau
Intel OTC
_______________________________________________
mptcp mailing list
mptcp@lists.01.org
https://lists.01.org/mailman/listinfo/mptcp



--
Tessares SAMatthieu Baerts | R&D Engineer
matthieu.baerts@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.